Amazon EKS バージョンライフライクルの更新

本投稿は Nathan Taber と Michael Hausenblas による寄稿を翻訳したものです

re:Invent 2017で、私たちは Amazon Elastic Container Service for Kubernetes(Amazon EKS) を紹介しました。当時発表した次の tenets(信条) は、現在に至るまで引き続き確かなものであると考えています。

• EKS はプロダクションレベルのワークロードを動かすためのプラットフォームである。これはセキュリティと信頼性が私たちの最優先事項であることを意味します。次いで、私たちはバージョンアップグレードのようなライフサイクル管理に関連するものを含め、コントロールプレーンにおける重労働の削減に焦点を当てます。
• EKS はネイティブかつアップストリームの Kubernetes 体験を提供する。これは EKS が純粋なフォークされていない Kubernetes を提供することを意味します。もちろん、最初の tenet に挙げたとおり、サポートされている Kubernetes バージョンに対しては、たとえ古いバージョンであっても、可能な限り素早くセキュリティ関連パッチの適用を確実に行います。しかし、ポータビリティの観点ではいかなる特別なソースもロックインも存在しません。
• ユーザが追加の AWS サービスを使う際に、そのインテグレーションを可能なかぎりシームレスにする。
• AWS の EKS チームは、良いプラクティスの共有や、SIGs(Special Interest Groups)、ワーキンググループへの参加まで、テクニカルとコミュニティの両面においてアップストリームの Kubernetes プロジェクトに対して積極的に貢献する。

最初の2つの tenets が強調されているのには理由があります： 私たちは SIG PM や LTS ワーキンググループの成果も含めつつ、可能な限りアップストリームのリリース頻度に足並みを揃えていくことを狙っています。プロダクションアプリケーション用のサービスを実行することは私たちの主な焦点であり、その観点において、私たちがあなたのために動かしている Kubernetes を、あなたが信頼できることを確実にしたいと考えています。これにはコミュニティにおける進行中のバグ修正についてのセキュリティ上の考慮事項や、重大な脆弱性や危険性(CVEs)に対するパッチを含みますが、これらに限定されるわけではありません。

この記事では、まずは Amazon EKS が Kubernetes のバージョンライフサイクルを管理するプロセス全体を説明してから、今後予定されている変更についてお知らせします。その後、具体的な例として Kubernetes バージョン 1.10 を見ていきます。このバージョンは Amazon EKS において最初に廃止される予定のバージョンとなります。

でもなぜ今なのでしょうか？

質問してくれて嬉しいです。これは全面的にセキュリティに関するものです。ある時点(通常1年)を過ぎると、Kubernetes コミュニティはバグ修正や CVE パッチのリリースを停止します。加えて、Kubernetes プロジェクトは廃止予定のバージョンに対する CVE 登録を推奨しません。これは、古いバージョンの Kubernetes に固有の脆弱性が報告すらされず、脆弱性が存在した場合のアナウンスは無く、ユーザは脆弱性を抱えたまま放置されることを意味しします。私たちは、これは私たちのお客様にとって受け入れられないセキュリティ体制だと考えます。

今年の初めに、私たちは EKS における Kubernetes 1.12 のサポートをアナウンスしました。そして、どの時点においても3つの Kubernetes バージョンをサポートするという私たちのコミットメントと、EKSにおいて 1.13 がまもなくサポートされるという事実は、1.11、1.12、そして(あなたの推測通り)1.13 という3つのバージョンをサポートし、1.10 を廃止しなければならないという事を意味します。ここでは、あなたが Amazon EKS を使用して最新の Kubernetes バージョンに移行する上での選択肢を確認し、更新(update)と廃止(deprecation)のプロセスについて詳しく説明していきます:

• 理想的には、3つのサポートバージョンのうちどれか1つをテストし、期間内に(詳細は後述)そのバージョンに移行します。
• 廃止予定バージョンを利用し続けている場合、しばらくした後に自動的にアップデートされます(こちらも詳細は後述)。
• ある時点を超えて廃止されたバージョンを利用していて、私たちがアップグレード出来ない場合、私たちはクラスターの動作を停止させるでしょう。

Kubernetes そのもののリリースサイクルについての簡単な再講座

一言で言えば、Kubernetes バージョニングとリリースは、各バージョンごとに70日から130日の間隔で、年間に4つ程度のリリースを行うパターンに従って実施されます。これは、アップグレードという観点における次のような想定に基づいて計画されています：

私たちは利用者がプロダクションで利用しているKubernetesのバージョンを合理的に最新の状態に保つ事を期待していますが、特にプロダクションで重要なコンポーネントの場合、アップグレードに時間がかかることを理解しています。

正式なAPIバージョン管理では、安定版(GA)APIサポートは12ヶ月もしくは3リリースのどちらか長い方という厳密な廃止ポリシーが存在します。

ここまでで、私たちはアップストリームの Kubernetes がどの様にリリースが管理されているかについての前提知識を共有しました。次に AWS がどのようにして同様のプロセスを EKS に実装しているか見ていきましょう。

EKS におけるリリース管理プロセス

Kubernetes バージョンについての Kubernettes コミュニティサポートに沿って、Amazon EKS では少なくともある時点における3つのプロダクションレディなバージョンと1つの廃止予定のバージョンの Kubernetes を実行できることを約束しています。新しい一般利用可能(GA)な Kubernetes バージョンは、Kubernetes プロジェクトによって70日から130日ごとにリリースされます(簡単のため、ここでは平均90日とします)。新しい GA バージョンは GA リリースからしばらくすると EKS でサポートされます(典型的には最初のパッチバージョンリリース – 1.XX.1 ですが、そのより後になる場合もあります)。これは EKS のプロダクションにおける1つのバージョンの利用可能な期間がおおよそ270日となることを意味します。

私たちは、特定の Kubernetes バージョン(n)について廃止予定日の少なくとも60日前に廃止予定であることをアナウンスします。また、Kubernetes プロジェクトがアップストリームのバージョンのサポートを停止した日付以降に EKS での Kubernetes バージョンの廃止を調整します。

例えば、私たちは EKS において 1.12 を利用可能にする一方でバージョン 1.10の廃止予定をアナウンスし、1.13 を利用可能にしたのちに 1.10 の廃止プロセスを完了させます。同様に、1.13 を利用可能にするとともに 1.11 の廃止予定をアナウンスし、1.14 を利用可能にしたのちに 1.11 の廃止プロセスを完了させます。

次の表はこの流れを整理したものです：

廃止をアナウンス時には、廃止のターゲットとなっているバージョンのクラスター作成が無効化される特定の日を通知します。この特定の日から、廃止ターゲットとなっているバージョンが動いている EKS クラスターは EKS がサポートしている次の Kubernetes バージョンへのアップデートが開始されます。これは仮に廃止バージョンが 1.10 である場合、クラスターは自動的にバージョン 1.11 にアップデートされることを意味しています。クラスターが EKS により自動アップデートされた場合、お客様はアップデートの完了後にワーカノードをアップデートする必要があるでしょう。Kubernetes には、少なくとも 2 バージョン違いまではマスターとワーカー間に互換性を維持するため、1.10 のワーカーは 1.11 のコントロールプレーンとも動作し続けるでしょう。

予定されている EKS における Kubernetes 1.10 の廃止について

Amazon EKS は2019年7月22日に Kubernetes バージョン 1.10 を廃止する予定です。この日より、新しい 1.10 のクラスターは作成できなくなり、Kubernetes バージョン 1.10 で動いている全ての EKS クラスターは、Kubernetes バージョン 1.11 の最新の利用可能なプラットフォームバージョンにアップデートされるでしょう。

私たちは、全ての Amazon EKS カスタマーに 1.10 クラスターを可能な限り素早く Kubernetes バージョン 1.11 もしくは 1.12 にアップデートする事を推奨します。

まとめ

準備のために今日からできることはなんでしょうか？そうですね、まずは Kubernetes のリリースサイクルと EKS のリリース管理プロセスを学び、内部プロセスをそれらに合わせることを試みましょう。私たちのドキュメントには EKS における Kubernetes バージョンの廃止プロセスとEKS クラスターでの Kubernetes バージョン更新に関するより多くの情報が記載されています。何か質問があれば、GitHub 上の公開コンテナロードマップ上のバージョン廃止 issue にコメントください。

翻訳はソリューションアーキテクト浅野が担当しました。原文はこちらです