前提条件カットオーバー移行 (Blue/Green) アップグレードインプレースアップグレード

クラスターのハイブリッドノードをアップグレードする

ハイブリッドノードのアップグレードに関するガイダンスは、Amazon EC2 で実行されるセルフマネージド Amazon EKS ノードと類似しています。ターゲットの Kubernetes バージョンで新しいハイブリッドノードを作成し、既存のアプリケーションを新しい Kubernetes バージョンのハイブリッドノードに円滑に移行し、古い Kubernetes バージョンのハイブリッドノードをクラスターから削除することが推奨されます。アップグレードを開始する前に、アップグレードに関する「Amazon EKS ベストプラクティス」を確認してください。Amazon EKS Hybrid Nodes には、標準サポートや拡張サポートなどの、クラウドノードを持つ Amazon EKS クラスターに対して同じ Kubernetes バージョンのサポートがあります。

Amazon EKS Hybrid Nodes は、アップストリーム Kubernetes と同じノードのバージョンスキューポリシーに従います。Amazon EKS Hybrid Nodes は、Amazon EKS コントロールプレーンよりも新しいバージョンにすることはできません。また、ハイブリッドノードは、Amazon EKS のコントロールプレーンのマイナーバージョンより、最大 3 つ前まで古い Kubernetes のマイナーバージョンである可能性があります。

カットオーバー移行のアップグレード戦略のためにターゲットの Kubernetes バージョンに新しいハイブリッドノードを作成する空き容量がない場合は、代わりに Amazon EKS Hybrid Nodes CLI (nodeadm) を使用してハイブリッドノードの Kubernetes バージョンをインプレースでアップグレードできます。

重要

nodeadm を使用してインプレースでハイブリッドノードをアップグレードしている場合、古いバージョンの Kubernetes コンポーネントがシャットダウンされ、新しい Kubernetes バージョンコンポーネントがインストールされて起動されるプロセス中に、ノードのダウンタイムが発生します。

前提条件

アップグレードする前に、以下の前提条件を満たしていることを確認してください。

ハイブリッドノードのアップグレードのターゲット Kubernetes バージョンは、Amazon EKS コントロールプレーンのバージョン以下である必要があります。
カットオーバー移行のアップグレード戦略に従う場合、ターゲット Kubernetes バージョンにインストールする新しいハイブリッドノードは、ハイブリッドノードの前提条件のセットアップ要件を満たしている必要があります。この要件には、Amazon EKS クラスターの作成時に渡した Remote Node Network CIDR 内に IP アドレスがあることが含まれます。
カットオーバー移行とインプレースアップグレードの両方について、ハイブリッドノードは、ハイブリッドノードの依存関係の新しいバージョンを取得するために必要なドメインにアクセスできる必要があります。
Amazon EKS Kubernetes API エンドポイントとのやり取りに使用するローカルマシンまたはインスタンスに kubectl をインストールしてる必要があります。
CNI のバージョンは、アップグレード先の Kubernetes バージョンをサポートしている必要があります。そうでない場合は、ハイブリッドノードをアップグレードする前に CNI バージョンをアップグレードします。詳細については「ハイブリッドノードの CNI を設定する」を参照してください。

カットオーバー移行 (Blue/Green) アップグレード

カットオーバー移行のアップグレードとは、ターゲット Kubernetes バージョンを使用して新しいホストに新しいハイブリッドノードを作成し、既存のアプリケーションをターゲット Kubernetes バージョンの新しいハイブリッドノードに円滑に移行し、クラスターから古い Kubernetes のバージョンのハイブリッドノードを削除するプロセスを指します。この戦略は Blue/Green 移行とも呼ばれます。

ハイブリッドノードを接続する手順に従って、新しいホストをハイブリッドノードとして接続します。nodeadm install コマンドを実行するときは、ターゲット Kubernetes バージョンを使用します。
ターゲット Kubernetes バージョンの新しいハイブリッドノードと古い Kubernetes バージョンのハイブリッドノード間の通信を有効にします。この設定により、ターゲット Kubernetes バージョンのハイブリッドノードにワークロードを移行している間に、ポッドが相互に通信できるようになります。
ターゲット Kubernetes バージョンのハイブリッドノードがクラスターに正常に参加しており、ステータスが Ready (準備完了) であることを確認します。
以下のコマンドを使用して、削除する各ノードをスケジュール不可としてマークします。これは、置き換えるノード上で新しいポッドがスケジュールまたは再スケジュールされないようにするためです。詳細については、Kubernetes のドキュメントの「kubectl cordon」を参照してください。NODE_NAME を古い Kubernetes バージョンのハイブリッドノードの名前に置き換えます。
```
kubectl cordon NODE_NAME
            
```
次のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は 1.28) のすべてのノードを識別して隔離できます。
```
K8S_VERSION=1.28
for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name')
do
    echo "Cordoning $node"
    kubectl cordon $node
done
```
現在のデプロイメントで、ハイブリッドノードで実行している CoreDNS レプリカが 2 つ未満の場合は、そのデプロイメントを少なくとも 2 つのレプリカにスケールアウトします。通常のオペレーションでは、回復力を高めるためにハイブリッドノードで少なくとも 2 つの CoreDNS レプリカを実行することが推奨されます。
```
kubectl scale deployments/coredns --replicas=2 -n kube-system
```
次のコマンドを使用して、クラスターから削除する古い Kubernetes バージョンのハイブリッドノードをそれぞれドレインします。ノードドレインのドレイン処理に関する詳細については、Kubernetes ドキュメントの「Safely Drain a Node」を参照してください。NODE_NAME を古い Kubernetes バージョンのハイブリッドノードの名前に置き換えます。
```
kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
```
以下のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は 1.28) のすべてのノードを識別してドレインすることができます。
```
K8S_VERSION=1.28
for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name')
do
    echo "Draining $node"
    kubectl drain $node --ignore-daemonsets --delete-emptydir-data
done
```
nodeadm を使用して、ホストからハイブリッドノードアーティファクトを停止および削除できます。root/sudo 権限を持つユーザーで nodeadm を実行する必要があります。デフォルトでは、ノードにポッドが残っている場合、nodeadm uninstall は続行されません。詳細については、「ハイブリッドノード nodeadm 参照」を参照してください。
```
nodeadm uninstall
```
ハイブリッドノードのアーティファクトを停止およびアンインストールしたら、クラスターからノードリソースを削除します。
```
kubectl delete node node-name
            
```
次のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は 1.28) のすべてのノードを識別および削除できます。
```
K8S_VERSION=1.28
for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name')
do
    echo "Deleting $node"
    kubectl delete node $node
done
```
CNI の選択によっては、上記のステップを実行した後にハイブリッドノードにアーティファクトが残っている場合があります。詳細については「ハイブリッドノードの CNI を設定する」を参照してください。

インプレースアップグレード

インプレースアップグレードプロセスとは、nodeadm upgrade を使用して、新しい物理ホストまたは仮想ホストやカットオーバー移行戦略を使用せずに、ハイブリッドノードの Kubernetes バージョンをアップグレードすることを指します。この nodeadm upgrade プロセスでは、ハイブリッドノードで実行されている既存の古い Kubernetes コンポーネントのシャットダウン、既存の古い Kubernetes コンポーネントのアンインストール、新しいターゲット Kubernetes コンポーネントのインストールを行い、新しいターゲット Kubernetes コンポーネントを起動します。ハイブリッドノードで実行されているアプリケーションへの影響を最小限に抑えるために、一度にアップグレードするノードは 1 つにすることを強くお勧めします。このプロセスの期間は、ネットワーク帯域幅とレイテンシーによって異なります。

アップグレードするノードをスケジュール不可としてマークするには、次のコマンドを使用します。これは、アップグレードするノード上で新しいポッドがスケジュールまたは再スケジュールされないようにするためです。詳細については、Kubernetes のドキュメントの「kubectl cordon」を参照してください。NODE_NAME をアップグレードするハイブリッドノードの名前に置き換える
```
kubectl cordon NODE_NAME
```
次のコマンドを使用して、アップグレードするノードをドレインします。ノードドレインのドレイン処理に関する詳細については、Kubernetes ドキュメントの「Safely Drain a Node」を参照してください。NODE_NAME をアップグレードするハイブリッドノードの名前に置き換えます。
```
kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
```
アップグレードするハイブリッドノードで nodeadm upgrade を実行します。root/sudo 権限を持つユーザーで nodeadm を実行する必要があります。ノードの名前は、AWS SSM と AWS IAM Roles Anywhere の両方の認証情報プロバイダーのアップグレードによって保持されます。アップグレードプロセス中に認証情報プロバイダーを変更することはできません。nodeConfig.yaml の設定値については、「ハイブリッドノード nodeadm 参照」を参照してください。K8S_VERSION を、アップグレード先のターゲット Kubernetes バージョンに置き換えます。
```
nodeadm upgrade K8S_VERSION -c file://nodeConfig.yaml
```
アップグレード後にノード上で Pod をスケジュールできるように、以下を入力します。NODE_NAME をノードの名前に置き換えます。
```
kubectl uncordon NODE_NAME
```
ハイブリッドノードのステータスを監視し、ノードがシャットダウンするのを待ち、Ready (準備完了) ステータスになったら新しい Kubernetes バージョンで再起動します。
```
kubectl get nodes -o wide -w
```

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Bottlerocket を実行しているハイブリッドノードの接続

ハイブリッドノードへのパッチの適用