Amazon EKS アドオンでのお客様による変更内容の保持

この記事は Amazon EKS add-ons preserve customer edits (記事公開日: 2022 年 10 月 14 日) を翻訳したものです。

はじめに

AWS re:Invent 2020 の一環として、Amazon Elastic Kubernetes Service (Amazon EKS) チームは、Amazon EKS アドオンのリリースを発表しました。アドオンの追加は、お客様からのフィードバックと、一般的に使用されている運用ソフトウェアの管理を簡素化したいという要望によって推進されました。アドオンを使用すると、Kubernetes アプリケーションをサポートするための重要な機能を提供する運用ソフトウェアを、構成、デプロイ、および更新できます。アドオンには、Amazon VPC CNI などのクラスターネットワーキングのための重要なツールや、オブザーバビリティ、ストレージ、管理、およびセキュリティのための運用ソフトウェアが含まれています。アドオンを使用することで、コマンド 1 つで Amazon EKS を設定してクラスター上でアドオンソフトウェアを起動したり、アドオンの新しいバージョンをデプロイしたりできます。

すべてのアドオンには、最新のセキュリティパッチとバグ修正が含まれており、Amazon EKS で動作することが AWS によって検証されています。これにより、本番環境に対応した Kubernetes クラスターを起動、管理、アップグレードするために必要な作業が削減され、クラスターの安定性と安全性を維持するのに役立ちます。

現在、Amazon EKS アドオンは以下のソフトウェアをサポートしています。

Server-Side Apply と編集の上書き

Amazon EKS アドオンは、Kubernetes バージョン 1.18 で利用可能になった、Server-Side Apply と呼ばれる機能を使用しています。Server-Side Apply は、kubectl apply の機能を Kubernetes API サーバーに移行し、設定変更時に起こりうる競合の解決に関するきめ細かな制御を提供します。Server-Side Apply では、Kubernetes コントロールプレーン内で、設定をマージする新しいアルゴリズムと、フィールドの管理者を追跡する仕組みが導入されます。これにより、Kubernetes は競合を自動的に検出し、解決できます。

Amazon EKS クラスターにアドオンが追加されたら、Kubernetes API を介してそれぞれのマネージドソフトウェアの設定を変更できます。ただし、これまで EKS アドオンは、15 分ごとに自動的に設定を上書きすることで、設定のドリフトを防いでいました。つまり、アドオン作成後に Kubernetes API を介して行われた EKS アドオンへの変更は、自動化されたドリフト防止プロセスによって上書きされます。ドリフトを防止することは望ましい目標ですが、アドオンによって管理されるソフトウェアに対するその後の編集を上書きすることは、お客様がアドオン管理下の Kubernetes リソースに対して意図的で必要な変更することを妨げることにもなります。

ソリューションの概要

Amazon EKS アドオンの動作の更新: お客様による変更内容の保持

Amazon EKS アドオンの最新リリースでは、アドオンによって管理されるソフトウェアに対するお客様の編集を保持する機能が追加されました。15 分ごとにソフトウェアの設定を上書きする代わりに、アドオンによって管理されるソフトウェアのヘルスチェックを行います。すなわち、アドオンは定常状態の運用中にクラスター上で何かを書き込んだり、上書きしなくなりました。アドオンがクラスターに書き込むのは、お客様によってトリガーされるアドオンの作成、更新、および削除の操作のときだけです。

15 分ごとに設定を上書きしなくなったことに加え、Amazon EKS API に新しい resolveConflicts オプションである PRESERVE が追加されました。この新しい PRESERVE オプションは、Kubernetes API を介してアドオンソフトウェアに対して行われたクラスター内の設定を、アドオンの範囲外として保持します。以下のアドオン更新のワークフロー例で示すように、aws eks update-addon AWS CLI コマンドで --resolve-conflicts PRESERVE パラメータと引数を使用して、最初の作成後にアドオンソフトウェアに対して行われた編集をアドオン更新操作で上書きしないようにできます。

アドオン更新のワークフロー例

ステップ 1 – クラスターにアドオンを作成します。

aws eks create-addon --cluster-name <CLUSTER_NAME> \
　　--addon-name coredns --addon-version v1.8.4-eksbuild.1 \
　　--resolve-conflicts OVERWRITE

注: 構成設定が失われることを避けるため、アドオンの作成プロセスが完了するまで、アドオンの編集を待つ必要があります。次の AWS CLI コマンドを使用して、アドオンのステータスを確認できます。

aws eks describe-addon --cluster-name <CLUSTER_NAME> --addon-name coredns | grep status
"status": "CREATING",

ステップ 2 – Kubernetes API を介して、クラスター内のアドオンの目的の設定を変更します。

kubectl -n kube-system edit configmap coredns

...
Corefile: |
...
  cache 15 // updated cache value
...

注: Kubernetes リソースの Server-Side Apply の managed fields を表示するには、以下に示すように、--show-managed-fields パラメータを使用します。

kubectl -n kube-system get configmap coredns -o yaml --show-managed-fields

ステップ 3 – アドオンの更新を実行する際に、--resolve-conflicts PRESERVE パラメータと引数を指定します。

aws eks update-addon --cluster-name <CLUSTER_NAME> \
　　--addon-name coredns --addon-version v1.8.5-eksbuild.1 \
　　--resolve-conflicts PRESERVE

ステップ 4 – 更新が成功し、編集した設定が保持されていることを確認します。

aws eks describe-addon --cluster-name <CLUSTER_NAME> --addon-name coredns
{
  "addon": {
    "addonName": "coredns",
    "clusterName": <CLUSTER_NAME>,
    "status": "ACTIVE",
    "addonVersion": "v1.8.5-eksbuild.1",
    "health": {
      "issues": []
    },...

kubectl -n kube-system get deployment coredns -o yaml

...
  image: <IMAGE_REGISTRY>/eks/coredns:v1.8.5-eksbuild.1
... 

kubectl -n kube-system get configmap coredns -o yaml

...
Corefile: |
...
  cache 15 // updated cache value
...

アドオンの更新操作を実行する際に PRESERVE オプションを指定すると、クラスター上に現在存在するものとアドオンが期待するものとを比較し、異なるフィールドや外部で変更されたフィールドを識別します。識別されると、関連するアドオンの更新操作を実行する際に、変更されたフィールドはそのままとし、他のすべてが更新されます。これにより、Kubernetes API を介して直接行われた設定が、アドオンを更新する際に保持されます。作成と更新のデフォルトの動作 (操作中の競合で失敗する) は変更されていません。

注: Amazon EKS アドオンでは、すべての変更されたフィールドを更新操作中に保持できます。すなわち、PRESERVE オプションを使用すると、保持されるフィールドを変更できます。一方で、変更されたフィールドは、アドオンの別のバージョンで互換性があるとは限りません。そのため、ベストプラクティスに従って、本番クラスターに変更を加える前に、非本番クラスターで必要な特定の設定変更を加えて更新をテストし、更新が意図通りに動作することを確認することをお勧めします。

作成および更新操作における競合の防止

当初から、Amazon EKS API は、アドオンの作成および更新操作中の競合の検出、防止、または上書きをサポートしています。この機能は、変更されていません。それぞれのアドオンによって管理されている、または管理される予定のフィールドを編集した後に管理されたアドオンを作成または更新しようとし、OVERWRITE オプションを指定しない場合、以下のように、既存の競合によって操作が失敗します。

kubectl -n kube-system edit configmap kube-proxy-config

...
    iptables:
...
      syncPeriod: 40s
...

aws eks create-addon --cluster-name <CLUSTER_NAME> --addon-name kube-proxy

aws eks describe-addon --cluster-name <CLUSTER_NAME> --addon-name kube-proxy

{
    "addon": {
        "addonName": "kube-proxy",
        "clusterName": "<CLUSTER_NAME>",
        "status": "CREATE_FAILED",
        "addonVersion": "v1.22.6-eksbuild.1",
        "health": {
            "issues": [
                {
                    "code": "ConfigurationConflict",
                    "message": "Conflicts found when trying to apply. Will not continue due to resolve conflicts mode. Conflicts:\nConfigMap kube-proxy-config - .data.config"
                }
            ]
        },
        "addonArn": "arn:aws:eks:<REGION>:<AWS_ACCOUNT>:addon/addons/kube-proxy/26c11eb4-819b-f299-7909-74c887051e48",
        "createdAt": "2022-07-26T22:07:49.300000-04:00",
        "modifiedAt": "2022-07-26T22:08:01.229000-04:00",
        "tags": {}
    }
}

潜在的な競合を回避するために、aws eks create-addon コマンドでは、以下に示すように、create 操作では OVERWRITE オプション、update 操作では OVERWRITE または PRESERVE オプションを使用できます。

aws eks create-addon --cluster-name <CLUSTER_NAME> --addon-name kube-proxy \
　　--resolve-conflicts OVERWRITE

競合が検出されたため操作に失敗した場合でも、前に示したステータスの確認コマンドを使用できます。

aws eks describe-addon --cluster-name <CLUSTER_NAME> --addon-name kube-proxy | grep status
        "status": "ACTIVE",

アドオン作成後、Kubernetes API を介してアドオンリソースを編集できます。そしてアドオン更新操作で PRESERVE オプションを使用すると、編集内容を保持したままアドオンを更新することできます。

OVERWRITE オプションのもう 1 つのユースケースは、Kubernetes リソースの設定をリセットすることです。アドオンによって管理されている、または管理できるソフトウェアの Kubernetes リソースを変更する場合、作成または更新操作の OVERWRITE オプションを使用して、アドオンによって規定された既知の適切な構成に設定をリセットできます。

アドオン削除後の Kubernetes リソースの保持

クラスターで Amazon EKS アドオンが必要なくなった場合、アドオンを削除できますが、その際に、Kubernetes リソースを保持するかどうかを選択できます。以下に示すように、delete-addon コマンドで --preserve フラグを使用すると、ソフトウェアからアドオン管理を削除しながら、Kubernetes リソースを保持できます。

aws eks delete-addon --cluster-name <CLUSTER_NAME> --addon-name <ADDON_NAME> --preserve

注: 本番環境の設定を変更する場合、バックアップとリストア、または GitOps などのソリューションを介して、必要なときに設定を再適用できるようにすることがベストプラクティスです。

まとめ

この記事では、Amazon EKS アドオンが、クラスター内の一般的な運用ソフトウェアを管理するために必要な重労働をどのように軽減するかを説明しました。この記事の最初のセクションで述べたように、すべてのアドオンには最新のセキュリティパッチとバグ修正が含まれており、Amazon EKS で動作することが AWS によって検証されています。アドオンはコントロールプレーン (マネージドアップグレード) とデータプレーン (マネージドノードグループ) の管理から始まった Amazon EKS の進化であり、一般的なクラスター運用ソフトウェア (Amazon EKS アドオン) の管理に進歩しています。Amazon EKS API のアドオン更新操作に最新の PRESERVE オプションを利用することで、アドオン管理下のソフトウェアの設定を、特定の編集を失うことなく変更できます。ソフトウェアの管理の支援のためにアドオンを利用しながら、個々のユースケースに合わせてソフトウェアをカスタマイズできます。

すぐにやって欲しいこと

Amazon EKS アドオンを試してください！

Amazon EKS を運用していて、まだアドオンを試していないのなら、今がその時です。もしかしたら、前述のドリフト保護のために、Kubernetes リソースの編集が上書きされるのが嫌で控えていたかもしれませんね。アドオン更新の新しい --resolve-conflicts PRESERVE オプションと、アドオンの削除の既存の --preserve オプションを使用すれば、編集内容を保持したままアドオンを使用できます。将来的には、Amazon EKS アドオンのより堅牢な構成管理システムを開発するための取り組みが進行中です。今後の発表にご期待ください！

Containers Roadmap をチェックしてください！

Amazon EKS アドオンやその他のコンテナサービスの改善についてアイデアをお持ちの方は、Containers Roadmap を利用してフィードバックを提供し、既存のロードマップアイテムをレビューしてください。

翻訳はプロフェッショナルサービスの杉田が担当しました。原文はこちらです。

Amazon Web Services ブログ