このページの改善にご協力ください
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。
Kubernetes kube-proxy セルフマネージドアドオンの更新
重要
セルフマネージド型のアドオンを使用する代わりに、アマゾン EKS タイプのアドオンをクラスターに追加することをお勧めします。タイプの違いがよくわからない場合は「Amazon EKS アドオン」を参照してください。アマゾン EKS アドオンをクラスターに追加する方法については「Amazon EKS アドオンを作成する」を参照してください。Amazon EKS アドオンを使用できない場合は、その理由に関する問題をコンテナロードマップ GitHub リポジトリ
前提条件
-
既存の Amazon EKS クラスター。デプロイするには「Amazon EKS の使用を開始する」を参照してください。
考慮事項
-
Amazon EKS クラスターの
Kube-proxyは、Kubernetes と同じ互換性およびスキューポリシーが適用されます。Amazon EKS アドオンバージョンのクラスターとの互換性の検証について説明します。 -
クラスターにインストールされているアドオンがセルフマネージド型であることを確認します。
マイクラスターの部分は自分のクラスター名に置き換えます。aws eks describe-addon --cluster-name my-cluster --addon-name kube-proxy --query addon.addonVersion --output textエラーメッセージが返された場合、クラスターにセルフマネージド型のアドオンがインストールされています。このトピックの残りの手順は、セルフマネージド型のアドオンを更新することです。バージョン番号が返された場合、クラスターに Amazon EKS タイプのアドオンがインストールされています。Amazon EKS タイプのアドオンを更新するには、このトピックの手順を使用するのではなく、「Amazon EKS アドオンの更新」の手順を使用してください。アドオンタイプの違いがよくわからない場合は、「Amazon EKS アドオン」を参照してください。
-
クラスターに現在インストールされているコンテナイメージのバージョンを確認します。
kubectl describe daemonset kube-proxy -n kube-system | grep Image出力例は次のとおりです。
Image: 602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.29.1-eksbuild.2出力例では、
v1.29.1-eksbuild.2がクラスターにインストールされているバージョンです。 -
602401143452およびregion-codeを、前のステップの出力の値に置き換えて、kube-proxyアドオンを更新します。v1.30.6-eksbuild.3を、「Amazon EKS クラスターの各バージョンで使用可能な最新のセルフマネージド kube-proxy コンテナイメージバージョン」の表に記載されているkube-proxyバージョンに置き換えます。重要
各イメージタイプのマニフェストは異なり、デフォルトまたは最小のイメージタイプ間で互換性がありません。エントリポイントと引数が一致するように、前のイメージと同じイメージタイプを使用する必要があります。
kubectl set image daemonset.apps/kube-proxy -n kube-system kube-proxy=602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.30.6-eksbuild.3出力例は次のとおりです。
daemonset.apps/kube-proxy image updated -
新しいバージョンがクラスターにインストールされたことを確認します。
kubectl describe daemonset kube-proxy -n kube-system | grep Image | cut -d ":" -f 3出力例は次のとおりです。
v1.30.0-eksbuild.3 -
同じクラスターで
x86ノードとArmノードを使用しており、クラスターが 2020 年 8 月 17 日より前にデプロイされている場合。以下のコマンドによりkube-proxyマニフェストを編集して、複数のハードウェアアーキテクチャにノードセレクターを含めます。このオペレーションを行うのは 1 回限りです。マニフェストにセレクタを追加した後、アドオンを更新するたびに追加する必要はありません。クラスターが 2020 年 8 月 17 日以降にデプロイされている場合、kube-proxyは既にマルチアーキテクチャに対応しています。kubectl edit -n kube-system daemonset/kube-proxyエディタを使用して、次のノードセレクターをファイルに追加し、その内容を保存します。エディタ上で、このテキストを挿入する場所の例については、GitHub のCNI マニフェスト
ファイルをご覧ください。これにより、Kubernetes はノードのハードウェアアーキテクチャに基づいて、正しいハードウェアイメージを取得できるようになります。 - key: "kubernetes.io/arch" operator: In values: - amd64 - arm64 -
クラスターを最初に作成したのが Kubernetes バージョン
1.14以降である場合は、既にこのAffinity Ruleがkube-proxyに含まれているため、この手順をスキップできます。Amazon EKS クラスターを最初に作成したのが Kubernetes1.13以前のバージョンであり、今後そのクラスターで Fargate ノードを使用する場合は、kube-proxyマニフェストを編集してNodeAffinityルールを含め、kube-proxyPod が Fargate ノードでスケジュールしないようにしてください。この編集を行うのは 1 回限りです。Affinity Ruleをマニフェストに一度追加したら、アドオンを更新するたびに追加する必要はありません。kube-proxyDaemonSet を編集します。kubectl edit -n kube-system daemonset/kube-proxyエディタで、次の
Affinity Ruleをファイルの DaemonSetspecセクションに追加して、ファイルを保存します。エディタ上で、このテキストを挿入する場所の例については、GitHub のCNI マニフェストファイルをご覧ください。 - key: eks.amazonaws.com/compute-type operator: NotIn values: - fargate
-