アップグレード時にクラッシュします。K8s には LTS バージョンが必要です。

著者 |ヤン・ジェン

制作 | 51CTO テクノロジースタック (WeChat ID: blog)

Kubernetes クラスターはアップグレード中か、アップグレードされる予定です。 K8s クラスターを保守するチームにとって、最大の懸念は、K8s のアップグレードによりシステムが大規模なサーバークラッシュを引き起こすことです。

ある夜に K8s のアップグレードが行われ、突然クラスターが強制的に更新され、すべてのサーバーがクラッシュし、迅速に回復する方法がないと想像してください。損失は​​どれほど大きいでしょうか?

写真

したがって、古いバージョンの安定性が特に重要になります。そうだとしたら、なぜ Kubernetes は LTS バージョンをリリースしないのでしょうか?

1. アップグレードが速すぎて会社が追いつけない

企業が安定性を期待するのは、保守主義や惰性からではなく、顧客とサプライヤー間の契約、規制や法律の要件、テクノロジーリスクポリシーの制限など、さまざまな実際的な理由によるものです。

しかし、柔軟性のために作成された K8s は、インフラストラクチャ レベルでは十分に安定したパートナーではないようです。更新速度は非常に速く、ビジネスの反復をはるかに超えています。

K8s コミュニティのサポートは、ユーザーがコミュニティ内で同様の質問に対する回答を見つけるのに十分なほど深く幅広いものであり、ほとんどの組織が K8s の導入の苦労に耐えられるにもかかわらず、頻繁なアップグレード操作に多くのユーザーが不満を抱いています。

ある開発者によると、K8s 上で GKE アップグレードを実行すると、数週間にわたってサービスが停止することがよくあります。コントロール プレーンとノード プールを修復またはアップグレードする方法のデフォルト値オプションも非常に抽象的です。知らないうちにクラスタがアップグレードされ、サービスが勝手に中断され、人々はパニックに陥ります。

小規模から中規模のチームでは、常に書き直すことはほぼ不可能です。

2. K8s バージョンのリリースペースに追いつくのはどれくらい難しいですか?

Kubernetes は、「N-2」サポート ポリシー (最新の 3 つのマイナー バージョンでセキュリティとバグの修正が行われます) と「15 週間」のリリース サイクルに従います。したがって、バージョンは 14 か月間サポートされます (12 か月間のサポートと 2 か月間のアップグレード)。

写真

これを Debian のサポート サイクルと比較すると、すぐに違いがわかります。

写真

たとえば、RedHat は組織が頻繁にアップグレードできないという前提で構築されており、一部の組織が大規模な変更を展開できる頻度をユーザーに示しています。

しかし、最新の状態を維持する能力を持つクラウド プロバイダーであっても、顧客がこのような非常に厳しい時間枠を順守することを許可しません。 Google の GCP は多くの Kubernetes メンテナーにアクセスでき、プロジェクトと緊密に連携していますが、顧客にこれらのタイムラインを強制することはありません。

AWS や Azure も同様です。

現実には、安定こそがすべてです。企業が K8s のリリースペースに追いつくことができるとは誰も予想していませんでした。維持するには費用がかかるため:

まず、クラスターがアップグレード可能で安全であることを検証するには、サードパーティのツールを使用するか、どの API がいつ廃止されるかを十分に理解する必要があります。

第二に、一時的な環境で検証を実行するために必要な時間と、Kubernetes クラスターのアップグレードを維持するために必要なかなりの時間によって、明らかな問題が発生します。

最後に、これらのコンポーネントとモジュールは、セキュリティと安定性を確保するために継続的に保守および更新する必要があります。

そのため、LTS バージョンを提供することで、ユーザーに安定した基盤が提供され、頻繁にアップグレードすることなく Kubernetes を長期的に使用できるようになります。

3. K8sクラスタをアップグレードする代わりに、新しいクラスタを作成する方が良い

K8s クラスターを手動でアップグレードしたことがない人は、当然ながらそれに伴う苦労を知りません。大まかなリストは以下のとおりです。

• ネットワークやストレージプラグインなどのサードパーティの拡張機能をすべてチェックする
• etcd を更新する (すべてのインスタンス)
• kube-apiserver を更新する (すべてのコントロール プレーン ホスト)
• kube-controller-manager を更新する
• kube-scheduler を更新する
• クラウド コントローラー マネージャーを更新する (使用している場合)
• kubectlを更新する
• 各ノードをドレインし、ノードを交換またはアップグレードし、読み取りと監視を行って、引き続き動作することを確認します。
• マニフェストの要件に従ってkubectl convertを実行します。

確かに、上記のどれもロケット科学ではなく、すべて自動化できますが、それでもこれらのバージョンに熟練した人が必要です。さらに、新しいクラスターを作成するよりも簡単ではありません。

アップグレードが、新しいクラスターの作成（通常ははるかに困難）よりもわずかに簡単なだけであったとしても、チームは行き詰まり、正しい行動方針が不明瞭になります。ただし、リリースのペースが速いため、新しいバージョンごとに新しいクラスターを立ち上げ、そのクラスターにサービスを移行するのは、ロジスティック的に困難な場合があります。

チームが K8s バージョンの .0 (通常は 0.2) を使いたくないことを考慮すると、標準を待つのにかなりの 14 か月かかることになります。次に、新しいクラスターを起動し、サービスの移行を開始します。ほとんどのチームにとって、これには多くの重複とリソースの無駄が伴います。少なくとも一定期間は、実行されるノードの数が 2 倍になる可能性が高いためです。 CI/CD パイプラインを変更し、ドキュメントを変更し、DNS エントリを交換する必要があります。

状況によってはそれほど難しくないかもしれませんが、細部まですべてが非常に重要であるため、自動化しても、1 つのステップでサイレント エラーが発生するリスクは、それを実行しようとする人を一日中不安にさせるほど高くなります。その結果、ある日、アップグレードの進行状況を把握することが組織にもたらす「重要な価値」であるということがチームに知らされない限り、クラスターは継続的に遅延している状態にあるように見えます。

多くの人が同様の経験をしています。インフラストラクチャ チームのクラスターが長期間アイドル状態になっており、メンテナーはクラスターを安全にアップグレードできるかどうか心配しています。そのため、既存のシステム全体に深刻な問題が発生するのを避けるために、通常は古いクラスターを稼働させてから最初の 3 か月間は、経営陣に次のように伝えました。「予算を少し超えて新しいクラスターを立ち上げ、名前空間ごとに切り替えていく必要があります。」

このプロセスがあまり穏やかではないように見えても。

4. K8sにLTSバージョンがある場合

もちろん、アップグレードせずに永久にバージョンを使い続けることはできません。そのため、K8s にはアップグレード パスのない「行き止まり」バージョンが存在する可能性があると示唆する人もいました。この LTS バージョンは正式リリース後 24 か月間のサポートを提供し、Kubernetes チームは次の LTS へのアップグレードを提供しません。

このアプローチは、多くの組織の現在のセキュリティ アップグレードの状況と一致しているようです。その後、運用チームのワークフローは、クラスターを 24 か月間実行することになり、その後、組織はクラスターを移行して新しいクラスターを作成する必要がありました。

そして、このワークフローは非常に理にかなっています。まず、組織が基盤となる Linux オペレーティング システムとハイパーバイザーをアップグレードできるように、定期的に新しいノードを作成することがベスト プラクティスになります。この頻度は明らかに 2 年ごとのアップグレードよりも少ないですが、良いチェックポイントになります。

次に、インフラストラクチャ運用チームは、新しい ETCD と新しいバージョンの Ingress コントローラーから始めて、スタック全体を再度確認する必要があります。これまでのように確認するのではなく、組織は絶対に必要な場合を除いて、すべての重要な部分に触れることを躊躇する可能性があります。

そうすると、このアプローチは商用製品や OSS ツールへの良い入り口にもなるかもしれません。現在、多くのクラウドベンダーが同様の K8s の有料バージョン (ホスティング プラットフォーム) を提供しています。たとえば、Google の GKE (Google Kubernetes Engine) では、バージョン 1.24 を 584 日間、バージョン 1.26 を 572 日間使用できます。 Microsoft Azure の LTS 期間はより緩やかで、公式リリース日から 2 年間続きますが、AWS の EKS はより長く、バージョンのサポートはリリースから LTS 終了まで約 800 日間続きます。

K8s コミュニティは、LTS バージョンのアップグレードに関する多くのガイダンスを提供することで、これらの製品やツールを支援できます。これにより、メンテナーがアップグレード プロジェクトに縛られることもありません。

5. K8s には LTS バージョンが必要ですか?

業界関係者の中には、K8s（および関連ソフトウェア）では定期的に大きな変更が導入され、開発者は仕事でアップグレードを完了するために多くの時間と労力を必要とすると考える人もいます。したがって、LTS バージョンを提供する必要があります。

他の多くのオープンソース ソフトウェアでは、複数年のサポートが付いた LTS バージョンが提供されています。たとえば、Ubuntu/Debian では 5 年間の LTS バージョンが提供され、NodeJS では 2.5 年間のサポートが提供されます。大企業にとっては 2 年間のサポート期間でも十分ではないと考える人もいます。

要約すると、このアイデアを支持する専門家は、K8s は多くの可動部分を持つ複雑なソフトウェアの集合体であり、テストの現状を維持し続けるのは非常に困難になっていると考えています。ほとんどの人にとって、キャリア全体において考慮する必要のない規模に達していると言えます。このような複雑なアップグレード タスクを同じグループのメンテナーに割り当てるのは不公平です。

世界中のホスティング プラットフォームと OSS スタックの間に、より適切な中間点を作ります。これは、既存のクラスターを絶えずアップグレードするという「忙しくて落ち着かない」状態に陥る必要がなくなるため、世界中の K8s オペレーターにとって大きなメリットとなります。

これにより、サードパーティのエコシステムが簡素化され、しばらくの間存在する既知の安定したターゲットに対する検証が容易になります。

同時に、これにより、クラスター オペレーターは、より優れたワークフローを採​​用し、アップグレードのためにクラスターを永続的に保持したり、クラスターが「クラッシュ」したりするのではなく、定期的に新しいクラスターを作成する習慣を身に付けるようになります。

しかし、反対意見を無視するのは容易ではありません。「LTS はオペレーターに利便性をもたらしますが、開発者がセキュリティ修正をバックポートする際に潜在的な複雑さが増し、LTS サポートを取得するためのコストも高くなります。」

彼らの見解では、K8s は柔軟性のために生まれたものであり、90 年代のソフトウェア開発プロセスを使用したい大企業には適していません。

「頻繁にアップグレードとリリースを行うことで、スタック内のすべてが十分に理解され、スタックが硬直化することが防止されます。また、アップグレードを積み重ねるよりも早めに行う方が、扱いやすくなることがよくあります。」

6. 妥協案

上記 2 つの見解に対して、K8s ディストリビューションの元開発者は妥協案として、「さまざまな理由からサポート期間を延長したいという顧客もいます。本当の問題は、LTS をディストリビューションに任せるべきかどうかです」と述べました。

多くのディストリビューションは、アップストリームよりも長期的なリリースを提供しないことを選択しますが、顧客が支払う価値があるほど重要な、より商用の製品をいくつか提供します。 「Kubernetes の作者が LTS を担当すると、プロジェクトのスピードが大きく犠牲になります。そのため、LTS は K8s ディストリビューターに任せる方が適切です。」

コンテナ思考が支配的な開発パラダイムの下では、好むと好まざるとにかかわらず、コンテナ オーケストレーションの王様である Kubernetes が業界で広く採用されている標準プラットフォームになっていることは否定できません。では、K8s のバージョンアップグレードが速すぎる問題についてはどう思いますか?

参考リンク:

https://matduggan.com/author/mathew/