Kubernetes kube-proxy セルフマネージドアドオンの更新 - Amazon EKS

このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

Kubernetes kube-proxy セルフマネージドアドオンの更新

重要

セルフマネージド型のアドオンを使用する代わりに、アマゾン EKS タイプのアドオンをクラスターに追加することをお勧めします。タイプの違いがよくわからない場合は「Amazon EKS アドオン」を参照してください。アマゾン EKS アドオンをクラスターに追加する方法については「Amazon EKS アドオンを作成する」を参照してください。Amazon EKS アドオンを使用できない場合は、その理由に関する問題をコンテナロードマップ GitHub リポジトリに送信することをお勧めします。

前提条件

考慮事項

  • Amazon EKS クラスターの Kube-proxy は、Kubernetes と同じ互換性およびスキューポリシーが適用されます。Amazon EKS アドオンバージョンのクラスターとの互換性の検証について説明します。

    1. クラスターにインストールされているアドオンがセルフマネージド型であることを確認します。マイクラスター の部分は自分のクラスター名に置き換えます。

      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 アドオン」を参照してください。

    2. クラスターに現在インストールされているコンテナイメージのバージョンを確認します。

      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 がクラスターにインストールされているバージョンです。

    3. 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
    4. 新しいバージョンがクラスターにインストールされたことを確認します。

      kubectl describe daemonset kube-proxy -n kube-system | grep Image | cut -d ":" -f 3

      出力例は次のとおりです。

      v1.30.0-eksbuild.3
    5. 同じクラスターで 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
    6. クラスターを最初に作成したのが Kubernetes バージョン 1.14 以降である場合は、既にこの Affinity Rulekube-proxy に含まれているため、この手順をスキップできます。Amazon EKS クラスターを最初に作成したのが Kubernetes 1.13 以前のバージョンであり、今後そのクラスターで Fargate ノードを使用する場合は、kube-proxy マニフェストを編集して NodeAffinity ルールを含め、kube-proxy Pod が Fargate ノードでスケジュールしないようにしてください。この編集を行うのは 1 回限りです。Affinity Rule をマニフェストに一度追加したら、アドオンを更新するたびに追加する必要はありません。kube-proxy DaemonSet を編集します。

      kubectl edit -n kube-system daemonset/kube-proxy

      エディタで、次の Affinity Rule をファイルの DaemonSet spec セクションに追加して、ファイルを保存します。エディタ上で、このテキストを挿入する場所の例については、GitHub のCNI マニフェストファイルをご覧ください。

      - key: eks.amazonaws.com/compute-type operator: NotIn values: - fargate