Amazon Web Services ブログ
Amazon EKS での Kubernetes アップグレードの計画
この記事は Planning Kubernetes Upgrades with Amazon EKS (記事公開日: 2021 年 5 月 3 日) を翻訳したものです。
2021 年 2 月、Amazon Elastic Kubernetes Service (Amazon EKS) は Kubernetes バージョン 1.19 のサポートを開始しました。これは、What’s New の投稿や Amazon EKS ドキュメントの更新など、通常のメカニズムを通じて発表されました。社内やお客様とのいくつかの会話の結果、AWS は Amazon EKS の Kubernetes バージョンリリースに合わせて、AWS Containers ブログ記事の投稿を行うことにしました。これらの記事では、新機能のハイライトとともに、クラスターのアップグレードを計画する際に注意する必要がある特定の変更点を紹介します。
AWS もまた、Kubernetes のバージョンアップグレードは、最初に考えるべき重要なことと考えています。そこで、社内では次の Kubernetes バージョンのリリースに取り組んでいるので、Amazon EKS でのバージョンリリースに関する一般的な考えを共有するとともに、EKS でのバージョンアップグレードの計画と実行に関するガイダンスを提供したいと思います。Kubernetes の各バージョンについて記事を書くという計画に則り、Kubernetes バージョン 1.19 について、まだアップグレードしていない人のために、いくつかの所見で締めくくります。今後は、Kubernetes バージョンをリリースするたびにこのようにしていきます。
Amazon EKS と Kubernetes の バージョン
Kubernetes は、速いペースで進化しているオープンソースプロジェクトです。大規模なオープンソースコミュニティの貢献により、アップストリームの各リリースには、何千もの変更が加えられています。AWS の開発者とエンジニアは、Kubernetes のエコシステム内の複数のプロジェクトに貢献し、プロジェクトをまたがる長期的な機能開発にも積極的に参加しています。AWS は、プロジェクト全体の変更を注意深く監視し、特にそれらがどのように相互作用するかをテストして、Kubernetes バージョンの最終的な EKS でのリリースに備えています。AWS は、コンポーネントがサービス内でうまく連携していることを確認し、お客様のクラスターの可用性の高いアップグレードパスを確実にするためのテストも行っています。お客様は Amazon EKS が Kubernetes インフラストラクチャをお客様に代わって管理することを信頼してくださっていますが、それがお客様にとって透過的な体験となるためには、多くの可動部品がうまく連携する必要があります。
Amazon EKS では、クラスターのマネージドコントロールプレーンを提供するととももに、マネージドノードの機能や、コンテナ向けサーバーレスコンピューティングエンジンである AWS Fargate との統合により、Kubernetes アプリケーションのデプロイとスケーリングをより簡単に行うことができます。昨年の re:Invent では、EKS がクラスターの運用をサポートするアドオンソフトウェアの管理にも対応したことを発表しました。今後数週間のうちに EKS add-ons に関するニュースを共有する予定です (訳注: EKS のアドオンで、CoreDNS と kube-proxy のサポートを開始) 。EKS のコア機能としての運用アドオンの管理は、クラスターのライフサイクル管理のスコープ内の Undifferentiated Heavy Lifting (差別化につながらない重労働) を取り除くという我々の目標を拡大するものです。
マネージドサービスの特徴として、これらの機能はすべて連携しており、AWS の中で完全に統合されているため、Kubernetes クラスターは安全で可用性が高く、ニーズに合わせてスケールすることができます。これらの機能はすべて、特にクラスターのアップグレード操作を通じて、Kubernetes のバージョンへの関連を強く意識して構築されています。Amazon EKS は、クラスターのコントロールプレーン、マネージド型ノードグループ、および一部の運用アドオンに対して可用性の高いアップグレードを提供します。
EKS のクラスターを構成する要素が数多くあるように、アップストリームの Kubernetes バージョンにも様々な要素が追加されてきます。Kubernetes のバージョンリリースは、実のところ、複数の個別のソフトウェアにまたがって、足並みをそろえるポイントです。API サーバー、コントローラーマネージャー、スケジューラーなどのコントロールプレーンコンポーネントから、kubelet などのノードのソフトウェアコンポーネントまで、これらの複数のソフトウェアピースは時間をかけて改良、保守、テストされ、バージョンリリースを形成します。
Kubernetes のリリースを通じて、新しい機能が導入され、アルファ版からベータ版、そして最終的には安定版へとステージを進んでいきます。あるマイナーバージョンのリリースでは、そのリリースの期間中、機能のステージは固定されます。EKS で使用可能な Kubernetes のバージョンがリリースされると、Kubernetes のすべての安定版の機能だけでなく、アップストリームでデフォルトで有効になっているすべてのベータ機能もサポートされます。EKS ではアルファ機能をサポートしていません。アルファ機能は開発が非常に活発になる傾向があり、しばしばマージされたり他の機能に置き換わったりするからです。EKS でアルファ機能を有効にしないのは、お客様がバージョン間でより一貫した体験ができるようにとの考えからです。これは時間の経過とともに発展する可能性があります。例えば、アルファ機能が時間の経過とともに安定してきたら、新しい Kubernetes バージョンの安定版の機能を、EKS の古い Kubernetes バージョンで有効にすることを検討しています。
時間の経過とバージョンに関して言うと、Kubernetes プロジェクトでは最新の 3 つのマイナーリリースのリリースブランチを管理しています。歴史的には、これらのマイナーバージョンはリリースから 9 ヶ月間サポートされてきました。1.19 からは、プロジェクトはマイナーリリースを 1 年間サポートすることになりました。これは、より多くの Kubernetes ユーザーにサポートされたバージョンを使ってもらいたいという思いがモチベーションの 1 つとなっており、クラスター管理者が時間をかけてアップグレードを計画するための時間を確保するのに役立ちます。
EKS でリリースされた Kubernetes バージョンは、14 ヶ月間サポートされます。これは、非常に大規模なクラスターフリートをお持ちのお客様が多いことを考慮したもので、アップストリームのサポート期間を上回るものです。このサポート期間中は、必要に応じてセキュリティ修正をバックポートし、そのバージョンの使用をサポートします。現在サポートされているリリースとサポートの詳細については、Amazon EKS ユーザーガイドを参照してください。
Amazon EKS での Kubernetes のバージョンアップグレードの計画と実行
これらをすべてまとめると、Kubernetes のバージョンリリースには多くの要素が含まれており、EKS チームは、バージョンをリリースする際に、それがプロダクションレディであること、そしてアップグレードがお客様とお客様のワークロードにとって可能な限りシームレスな体験であることを保証するために、多大な努力をしています。ここは、AWS とお客様が責任共有モデルで出会う場所です。Amazon EKS はお客様のためにコンポーネントをアップグレードしますが、物事がスムーズに進むようにするためには、お客様がやるべきことがいくつかあります。これからアップグレードのプロセスについて簡単に説明し、アップグレードの準備と管理に役立つハイレベルのアップグレードガイドラインをいくつか提供します。
EKS はアップストリームの Kubernetes よりも長い期間のサポートを提供しますが、そのサポートには限界があります。時間の経過とともに新しいバージョンを追加していくと同時に、古いバージョンを非推奨にしていきます。バージョンが非推奨になるということは、そのバージョンがサポートされなくなり、EKS でそのバージョンがメンテナンスされなくなり、そのバージョンで新しいクラスタを作ることができなくなることを意味します。
EKS では、クラスターの継続的なアップグレード計画が不可欠です。Kubernetes はペースの速いプロジェクトであり、最新バージョンで提供される革新的な機能は、クラスターをアップグレードするのに十分な理由となることがよくあります。そうでない場合でも、速いペースの開発が API の変更を誘発し、しばしば非推奨や破壊的な変更を伴うことを考慮してください。このような変更はアップストリームで常に十分に文書化されていますが、設定や仕様の変更が多ければ多いほど、最新のリリースにアップグレードする際には多くの問題が発生します。
とはいえ、最新のリリースに一貫してアップグレードするのは普通のことではありません。AWS はこれを理解しています。ベーシックなワークロードを実行している小規模なクラスターをアップグレードするのはまあまあ簡単な作業ですが、複雑なネットワーク構成や永続的なストレージを持つ大規模なクラスターのフリートを管理するのははるかに複雑です。
その上、ターゲットリリースから数リリース遅れている場合もあります。インプレースアップグレードは、Kubernetes の次のマイナーバージョンへのインクリメンタルアップグレードであるため、現在のバージョンとターゲットバージョンの間にいくつかのリリースがある場合、それぞれのリリースを順番に進めていく必要があります。このシナリオでは、Blue/Green インフラストラクチャデプロイメント戦略を検討するのが最善かもしれませんが、これはそれ自体が複雑な作業です。
そのため、アップグレードの計画と定期的なアップグレードのサイクルが重要です。私たちは、このプロセスを支援するための機能を継続的に開発していますが、Kubernetes のアップグレードを成功させるためには、徹底した計画とテストが不可欠です。
Kubernetes クラスターのインプレースアップグレードは、最もシンプルな形では、以下のフェーズで構成されます。
- クラスターのコントロールプレーンのアップグレード
- クラスターのノードのアップグレード
- 必要に応じて、Kubernetes のアドオンやカスタムコントローラーのアップデート
- 必要に応じて、Kubernetes のマニフェストのアップデート
これらのフェーズは、本番クラスターでのアップグレード作業に先立って、クラスター構成やアプリケーションマニフェストの問題を発見できるように、完了するまでテスト環境で行うのがベストです。現在の Kubernetes のバージョンを持つクラスターと、アドオン、アプリケーション、その他テストが必要なものすべての本番バージョンから始めます。そして、アップグレード、デプロイメント、テストの各フェーズを実行し、必要に応じて変更を加えます。
理想的には、クラスターの仕様、アドオン構成のカスタマイズ、アプリケーションマニフェストのすべてが、バージョン管理下のソースコードリポジトリで管理されます。これにより、インフラストラクチャとアプリケーションの管理にコントロールされバージョン管理されたアプローチが提供され、イミュータブルなアーティファクトを活用して、任意の数のクラスターの管理とデプロイに使用することができます。クラスターのアップグレードプロセスは、テスト環境から始まり、必要な変更をソースリポジトリにコミットしていきます。完了すると、そこからすべてを本番環境にデプロイすることができます。
EKS でクラスターを運用する大きなメリットの 1 つは、1 回の操作でコントロールプレーンをアップグレードできることです。これらのアップグレードは完全に自動化された 1 回の操作であり、新しいコントロールプレーンのリソースのプロビジョニングとテストの間、クラスターは利用可能な状態に保たれます。もし何か問題が発生した場合、アップグレードはロールバックされますが、アプリケーションは引き続き稼働し利用可能です。詳細については、Amazon EKS ユーザーガイドを参照してください。
同様に、マネージド型ノードグループのアップグレードも完全に自動化されており、インクリメンタルなローリングアップデートとして実装されています。新しいノードは EC2 でプロビジョニングされてクラスターに参加し、古いノードは cordon され、drain され、削除されます。新しいノードは、デフォルトでは EKS optimized Amazon Linux 2 AMI を使用しますが、オプションでカスタム AMI を使用することもできます。独自のカスタム AMI を使用する場合は、独自のアップデートされたイメージを作成する必要があり、ノードグループのアップグレードの一環として、アップデートされた起動テンプレートバージョンが必要になります。ノードグループのアップデートの詳細については、Amazon EKS ユーザーガイドを参照してください。
これは、クラスターのアップグレードの最初の 2 つのフェーズを処理するもので、非常に多くの負荷を軽減します。複数のコンピュートリソース上で動作する様々なソフトウェアコンポーネントのバージョンアップレードや、設定のマージや、コンピュートインスタンスへのパッチ適用や再インストールをまとめて、それを API コールや CLI の呼び出しのセットにまで減らすことは、とても良い開始方法です。しかし、‘アップデート’ ボタンをクリックするだけではなく、さらに多くのやるべき作業があります。
複雑性のハンドリングと成功のためのテスト
3 つめフェーズを支援するために、EKS は現在、一部のアドオンのライフサイクル管理も提供しています。この記事を書いている時点では、VPC CNI コントローラーが唯一サポートされているアドオンであり、kube-proxy と CoreDNS もサポートが予定されています (訳注: 前述の通りサポートが開始されています) 。また、今年後半にはさらに多くのアドオンをリリースする予定です。しかし、お客様は複数のアドオンや、独自のカスタムリソース定義を持つカスタムコントローラーや、その他多くの運用ソフトウェアやカスタマイズされたソフトウェアをクラスター内で実行しているかもしれません。これらのコンポーネントはすべてテストする必要があり、場合によってはアップデートする必要があります。理想的には、新しい Kubernetes バージョンをサポートする最新の利用可能なリリースにアップデートする必要があります。
運用ソフトウェアのアップデートフェーズの大部分は、依存関係を把握し、ツールを更新し、カスタマイズした設定が有効であることを確認することです。いくつかの更新を行う必要があるかもしれませんが、テスト環境はこれを発見する場所です。ターゲットの Kubernetes のバージョンを使用してテストクラスターを作成し、すべてのものを、一度に 1 つずつデプロイします。これは、複雑さが問題となる場面ですので、緻密に作業できるように十分な時間を確保してください。
前述のように、設定ファイルや Helm チャートを、他の Kubernetes マニフェストと一緒にバージョン管理下に保存するのは良い習慣です。そうすることで、テストが完了して変更がコミットされると、本番環境にロールアウトするためのイミュータブルなアーティファクトのフルセットを手に入れることができます。
これにより、アップグレードの最も重要な側面である、マニフェストのテストにたどり着きます。Amazon EKS は可用性の高いクラスターのインプレースアップグレードを提供し、Kubernetes はその過程でオブジェクト仕様を移行するために最善を尽くします。しかし、自動的に行うことができないいくつかの変更があるため、API バージョンの変更や潜在的な非推奨事項を回避するためにお客様が手を入れる必要があります。繰り返しになりますが、このような変更は常に十分に文書化されていますので、計画の一部として、準備の際には API の変更点をメモしておきましょう。Kubernetes のリリースに互換性を破る変更が含まれる場合、AWS は注意を呼びかけますが、アップストリームのドキュメントは常に優れたリソースとなります。
これで、テストクラスターがターゲットの Kubernetes バージョンで動作し、運用アドオンのセットが装備され、Kubernetes アプリケーションがデプロイされたので、テストと観察を行うことができます。すべてが適切に作成および設定されていることを確認します。テストを実行し、エラーをチェックして、問題があれば対処します。ここで、アプリケーションマニフェスト、アドオンの構成、およびシステムの他のコンポーネントをソース管理しておくことが、よく整備されたアップグレード計画の中心となります。テストに合格し、設定がすべて正しく行われると、コミットによってフリート全体にデプロイするために必要なアーティファクトが提供されます。
もちろん、これはすべて非常に単純化されています。多くのアプリケーションがあり、あるアプリケーションは数十または数百ものマイクロサービスで構成されているかもしれません。あるサービスは独自のユニークで複雑な構成を持ち、カスタムリソース定義に依存する場合があり、そのカスタムリソース定義はカスタムコントローラーに依存します。このようなモジュール性と拡張性は Kubernetes のパワーの一部ですが、アップグレード計画にはさらなる注意を必要とします。繰り返しになりますが、テストが必要なものを徹底的にテストするための時間を十分に確保してください。何百ものマイクロサービスを運用している人なら誰でも同意すると思いますが、自動化はここで大いに役立ちます。アップグレードの味方として、時間に勝るものはありません。そのため、計画は非常に重要です。
Amazon EKS と Kubernetes バージョン 1.19
さて、最新のリリースである Kubernetes バージョン 1.19 について考えてみましょう (訳注: 2021 年 7 月時点では、EKS で Kubernetes バージョン 1.20 がサポートされています)。EKS がサポートする新しい Kubernetes バージョンが発表されると、このバージョンの新しいクラスターを作成したり、既存のクラスターをこのバージョンにアップグレードしたりできるようになります。さらに、Amazon EKS Distro のビルドが、ECR Public Gallery や GitHub から入手できるようになります。
EKS での Kubernetes バージョンのリリースと同様に、考慮すべきことが複数あります。新しく有効になった Kubernetes の機能、既存の機能の変更や非推奨化、EKS での変更は、すべてがこれまで議論してきたアップグレード計画に関わってきます。そこで、テストクラスターを立ち上げて、コンポーネントのアップグレードを始める準備をしましょう。
どの Kubernetes のバージョンリリースでも、まずアップストリームのアナウンスメントから始めるのが良いでしょう。ここに 1.19 の公式リリースアナウンスメントへのリンクがあります。これらのアナウンスメントは、リリースの概要、モチベーション、主要なテーマを提供し、対応を計画する必要のある非推奨事項を常に呼びかけます。また、そのリリースの変更履歴にもリンクされており、これにはパッチバージョンの更新も含まれています。EKS での特定のバージョンを検討し、そのリリースにロールアップされる具体的な変更点を確認するのが最善です。例えば、Kubernetes のバージョン 1.19 を EKS で使用する場合、この記事を書いている時点では、ユーザーガイドではバージョン 1.19.8 が指定されています。
Kubernetes バージョン 1.19 の機能
Kubernetes バージョン 1.19 を使用する場合、Amazon EKS でサポートされている Kubernetes 機能がいくつかあります。あるバージョンからあるバージョンへ移行するとき、EKS での新機能は、アルファからベータに移行してデフォルトで有効になった機能や、ベータ機能で以前はデフォルトで無効になっていたものが有効になったり安定版に移行した機能である可能性があります。
Ingress API が Kubernetes の安定版の機能になりました。これはこの時点ですでに長い間使われているので、ベータ機能とは考えていなかったかもしれません。Ingress を使用すると、外部からのアクセスリクエストに対して、クラスター内部のリソースへのアクセスを設定することができます。負荷分散、SSL 終端、名前ベースのバーチャルホストなどとともに使用されることがあります。このリリースでは、機能は同じままで、apiVersion が networking.k8s.io/v1beta1 から networking.k8s.io/v1 に変更されていることに注意して、必ずマニフェストを更新するようにしてください。
EndpointSlice はベータ機能で、デフォルトで有効になりました。これは、多くのサービスエンドポイントを持つクラスターのスケーラビリティに大きな影響を与える機能です。Endpoint は Pod と 1 対 1 でマッピングされています。Service を支える Pod の数が増えると、Pod の数に応じて Endpoint の数も増えるため、コントロールプレーンに負担がかかる可能性があります。EndpointSlice の導入はほとんど透過的な機能で、コントロールプレーンは自動的に Endpoint のセットを EndpointSlice にまとめ、それぞれが最大 100 の Endpoint を参照できるようになります。これにより、スケーリングプレッシャーが軽減され、Topology Aware Routing のような将来のより高度な機能への道が開かれます。
トポロジーに関連して、Pod Topology Spread が安定版の機能になりました。これは、リージョン、ゾーン、その他のノードのグループといったトポロジードメイン内で、クラスター全体で Pod をどのようにスケジュールするかを制御するために使用します。Topology Spread の設定は、各ノードが属するトポロジードメインを識別するためにノードラベルに依存します。EKS によってすでに作成されているノードラベルを使用することもできますし、独自のラベルを選択してトポロジーを任意に定義することもできます。これらのラベルは、PodSpec の一部である topologySpreadConstraints 仕様で、トポロジーキーとして使用することができます。これにより、高可用性構成においてより詳細な制御が可能となり、また、リソースの利用効率を高めることができます。
Immutable Secret と Immutable ConfigMap がデフォルトで有効になりました。これにより、マニフェストでオプションの immutable フィールドを使用して、イミュータブルな Secret と ConfigMap を作成することができます。イミュータブルな Secret/ConfigMap が作成されると、オブジェクトとそのコンテンツは、その存在期間中不変となります。通常、Secret/ConfigMap オブジェクトは kubelet によって変更がないか常に監視されますが、この機能を使用すると、イミュータブルなオブジェクトでは監視が不要になるため、パフォーマンス上のメリットがあります。また、不用意な設定変更によるアプリケーションの停止などの影響を軽減できます。これらのオブジェクトは不変であるため、構成を変更する唯一の方法は、オブジェクトを明示的に削除して新しいオブジェクトを作成することです。
ExtendedResourceToleration アドミッションコントローラーが有効になりました。これは、GPU や FPGA、および Kubernetes が他の方法では認識しないその他の特殊な拡張リソースを持つノードを構成することで、ノードの Taint や Pod の Toleration をより透過的に管理できるようにするプラグインです。このコントローラーは、拡張リソースを要求する Pod に、そのような Taint に対する Toleration を自動的に追加するため、ユーザーは手動で Toleration を追加する必要がありません。拡張リソースの設定についての詳細は、Kubernetes のドキュメントを参照してください。
Amazon EKS のお客様および AWS 上で Kubernetes を実行しているお客様向けに、in-tree の Kubernetes Service コントローラーによってプロビジョニングされた Elastic Load Balancer が、インスタンスターゲットとして含めるノードのフィルタリングをサポートするようになりました。これにより、大規模なクラスターでターゲットグループの制限に達することを防ぐことができます。詳細については、Kubernetes ドキュメントの service.beta.kubernetes.io/aws-load-balancer-target-node-labels アノテーションを参照してください。なお、in-tree コントローラーは推奨されなくなったことに注意してください。AWS Load Balancer Controller の次のリリースでは NLB インスタンスモードのサポートを提供し、いくつかの特定のユースケースのための最後のブロッカーを取り除きます (訳注: AWS Load Balancer Controller バージョン 2.2 が利用可能になり、NLB インスタンスターゲティングのサポートの提供を開始) 。
前述のように、このリリースでのすべての変更点については、完全な Kubernetes 1.19 の変更履歴を参照することができます。EKS でどの機能がサポートされているかを判断する際には、上述の機能のステージを念頭に置いてください。
Kubernetes バージョン 1.19 に関連する Amazon EKS の変更点
Kubernetes の新しいバージョンが出ると、EKS の構成要件にもいくつかの変更がある場合があります。Kubernetes 1.19 に関連するいくつかの変更点がありますので、ここではそれについて説明します。
Kubernetes バージョン 1.19 以降向けの Amazon EKS optimized Amazon Linux 2 AMI では、Linux カーネルバージョン 5.4 を搭載するようになりました。これはモダナイゼーションであり、以前の 4.14 カーネルから更新されています。特に、これによってマネージド型ノードグループで EKS optimized AMI を使用する場合、Kubernetes ノードで eBPF を使用できるようになります。
Kubernetes 1.19 以降、EKS はクラスター作成時にサブネットに kubernetes.io/cluster/<cluster-name> タグを追加しなくなります。このサブネットタグはオプションで、Kubernetes Service コントローラーや AWS Load Balancer Controller が Elastic Load Balancer を配置する場所に影響を与えたい場合にのみ必要となります。クラスター作成に必要なサブネットの要件の詳細については、Amazon EKS ユーザーガイドの Cluster VPC considerations の更新を参照してください。
IAM Roles for Service Accounts で使用するための Web Identity Token ファイルにアクセスする必要がある非 root コンテナに、Security Context を提供する必要がなくなりました。詳細については、Kubernetes の機能拡張および Amazon EKS のドキュメントを参照してください。
Pod Identity Webhook が更新され、Startup Probe が設定されないという Issue に対応しました。また、トークンの有効期限を管理するアノテーションにも対応しました。
CoreDNS バージョン 1.8.0 が Amazon EKS 1.19 クラスターでの推奨バージョンです。新しい EKS 1.19 クラスターでは、このバージョンがデフォルトでインストールされます。詳細については、Amazon EKS ユーザーガイドの Installing or upgrading CoreDNS を参照してください。
いつものように、クラスターの構成と要件の完全なリファレンスについては、Amazon EKS ユーザーガイドを参照してください。
Kubernetes 1.15 を使用している Amazon EKS のお客様へのお願い
Kubernetes のバージョン 1.15 は、2021 年 5 月 3 日に EKS でのサポートが終了します。このバージョンのクラスターを新たに作成することはできなくなり、最終的にはすべてのクラスターがバージョン 1.16 にアップデートされます。現在 1.15 を使用している場合は、アップグレードの計画を開始し、できるだけ早く少なくとも 1.16 にアップグレードすることが非常に重要です。
サポートされているバージョンの Kubernetes を実行しているクラスターをデプロイすることが常にベストです。1.15 のクラスターには、セキュリティ、安定性、および機能のパッチは提供されなくなります。また、1.15 から 1.16 への移行では、いくつかの非推奨 API が削除されるため、もし適切なテストを行わずにクラスターが最終的にアップグレードされた場合、アプリケーションやサービスが動作しなくなる可能性があります。
非推奨 API の削除に関する詳細は、アップストリームのドキュメントを参照してください。いくつかのオープンソースツールを使って対応を開始するための追加ガイダンスについては、この最近のブログ記事をご覧ください。
まとめと今後の展望
Kubernetes は複雑なソフトウェアのセットであり、それを使用する他の複雑なシステムと同様に、定期的なメンテナンスと慎重な計画が必要です。Amazon EKS は、可用性の高いコントロールプレーンのアップデートから、アプリケーションの稼働を維持したノードグループの自動化されたアップデートまで、このプロセスの多くの側面を支援します。
この記事では、責任共有モデルで考慮する必要のあるいくつかの重要な側面を説明させていただきました。何かのお役に立てば幸いです。今後は、冒頭で述べたように、EKS での Kubernetes のバージョンリリースに合わせて、よりストーリー性のある記事を公開していきます (訳注: EKS 1.20 のリリースに合わせて公開された記事)。より詳細が必要な場合や、クラスターアップグレードプロセスの特定の側面で特別な注意が必要な場合は、AWS にお知らせください。
AWS は、アップグレードのいくつかの側面をより自動化し、シームレスにするための追加機能に取り組んでいます。AWS がどのように改善できるかについて、常に皆様からのご意見をお待ちしています。いつでも AWS に連絡してください。GitHub の AWS Containers Roadmap で現在の計画を確認してください。Issue をオープンして新機能をリクエストしたり、気に入った提案に賛成票を投じたりしてください。
翻訳はプロフェッショナルサービスの杉田が担当しました。原文はこちらです。