Kubernetes と Container Engine でより良いノード管理を
Google Cloud Japan Team
Google Container Engine マネージド サービスを使用すると、管理オーバーヘッドを最小限に抑えながら Kubernetes クラスタを実行することができます。このほど、ノードのアップグレードとメンテナンス機能の大幅な改善を図り、Container Engine で実行される Kubernetes クラスタの管理がさらに簡単になりました。
自動ノード管理
従来は、クラスタを立ち上げることこそ簡単でしたが、ノードを最新かつ健全な状態に保つのはお客様の責任で行っていました。クラスタを健全で新しい状態に保つためには、Kubernetes のリリースを追跡し、不健全な状態になったノードを監視するツールとアラートをセットアップして、そのノードを修復するためのプロセスを開発しなければなりませんでした。マスターを健全な状態に保つことは Google の仕事ですが、クラスタを構成するノード（特に大規模な場合）まで考えると、その管理は大変な量の作業になります。私たちの目標は、お客様が一般的な管理作業に関して注意しなければならないことを最小限に抑え、エンド ツー エンドの自動管理エクスペリエンスを提供することです。今回、この目標を達成するために、お客様の管理作業の負担軽減に役立つ 2 つの新機能を導入しました。
ノードの自動アップグレード
最新リリースが Google のエンジニアによってテストされ、安定していることが確認されたときは、ノードのアップグレードを手作業で行わなくても、ノードを自動的にアップグレードするオプションを選べるようになりました。このオプションは、新しいクラスタとノード プールの作成時に表示される UI の “Automatic upgrades” で有効にすることができます。
このオプションを CLI（コマンドライン インターフェース）を使って有効にするには、 “--enable-autoupgrade” フラグを追加します。
自動アップグレードを有効にすると、選択されたノード プールの各ノードは、ワークロードを徐々にドレインしてシャットダウンし、新しいノードが作られてクラスタに追加されます。ノードの健全性は、次のノードに進む前にチェックされます。
詳細はこちらのドキュメントを参照してください。
ノードの自動修復
他の本番システムと同様に、クラスタ リソースでもイシュー（Kubernetes バイナリのクラッシュ、ワークロードが引金になったカーネルのバグ、ディスクの使い切りなど）を監視し、仕様から外れたときには修復する必要があります。不健全な状態のノードは、クラスタのスケジューリング能力を低下させ、そのうちにワークロードはスケジューリングされなくなってしまいます。Google では、このような問題が発生した場合に備えて、以前から Kubernetes マスターの監視と修復を行っていますが、新しいノード自動修復機能を使用すれば、ノード プール内の各ノードも監視されます。
自動修復機能は、クラスタとノード プールの作成時に有効にすることができます。
この機能は、UI の “Automatic repair” で設定します。
CLI で有効にするには、次のようにコマンドを入力します。
自動修復機能を有効にすると、Container Engine は、クラスタ マスターからのノード健全性ステータスや、ノードの背後のマネージド インスタンス グループからの VM ステートを含む複数のシグナルを監視するようになります。健全性チェックの失敗があまりにも長く続く場合は（約 10 分）、ノード VM の再作成プロセスが実行されます。
詳細はこちらのドキュメントを参照してください。
ノード アップグレードの改善
これら 2 つの機能の実現には、水面下でかなりの作業が必要になりました。従来の Container Engine でのノード アップグレードでは、ノードの健全性ステータスは考慮されておらず、アップグレードの準備が整っていることの確認が十分ではありませんでした。本来は、ノードをオフラインにするときには先にドレインし、VM の立ち上げに成功したら健全性をチェックすべきです。ところが、以前の Container Engine はこれらのシグナルを確認せず、前のノードの準備が完了する前にクラスタの次のノードのアップグレードを開始し、小規模なクラスタではワークロードに影響を与える可能性がありました。
私たちは、自動アップグレードと自動修復を実装する過程で、アーキテクチャに複数の改良を加えました。できるかぎり無停止でアップグレードすることに重点を置き、アップグレードのロジックを作り直したのです。
また、ノードをオフラインにする前に（podTerminationGracePeriod によって制御されます）、ノードをコードン（cordon）、およびドレインするための適切なサポートを追加しました。Pods がコントローラ（たとえば ReplicaSets や Deployments）の管理下にある場合、それらは自動的に他のノードにスケジューリングし直されます。
さらに、各ノードのアップグレード後に、そのノードが健全でスケジューリングできる状態になっているかどうかを確認するステップも追加しました。もし健全でなければ、アップグレードを再試行することになります。
こうした改良により、混乱を招くようなアップグレードは大幅に減少しました。
アップグレードのキャンセル、再開、ロールバック
私たちはさらに、アップグレードを単なる二項演算以上のプロセスにしようと考えました。というのも、特に大規模なクラスタでは、アップグレードを中断したり、完全に取り消してロールバックしたりしなければならないことがよくあるからです。Container Engine は新たに、アップグレードのキャンセルとロールバック、再開をサポートすることになりました。アップグレードをキャンセルした場合、アップグレード プロセスは次のような状態になります。
- アップグレードされていないノードは旧バージョンのままです。
- 作業中のノードはアップグレード完了まで進みます。
- アップグレード済みのノードは新バージョンのままです。
キャンセルや失敗に終わったノードのアップグレードは、前の状態にロールバックすることも可能です。ロールフォワードと同様に、まだアップグレードされていないノードはロールバックされません。たとえば、最初のアップグレードで 5 つのノードのうち 3 つがアップグレードされた場合、ロールバックはその 3 ノードで行われ、残りの 2 ノードは影響を受けません。これにより、アップグレードはかなりクリーンになります。
注意 : ノードのアップグレードは、ローカルに格納されたデータが使えなくなる VM の再構築を必要とします。使用できなくなったローカル データは、ロールバックやロールフォワードでは復元されません。
| ノードの状態 / アクション | キャンセル | ロールフォワード | ロールバック |
| アップグレード中 | 最後まで実行 | － | － |
| アップグレード済み | そのまま | そのまま | ロールバック |
| アップグレード前 | そのまま | アップグレード | そのまま |
ぜひお試しを！
今回の改良で、Container Engine を Kubernetes の最も簡単な利用手段にするという私たちの取り組みは大きく前進しました。Container Engine を使用すれば、フレンドリーな分単位の課金やグローバルなロード バランサ、IAM 統合、クラスタの可用性と最新状態を維持する Google の信頼性エンジニアによる完全管理といった Google Cloud Platform（GCP）の強力なメリットを、純粋なオープンソースである Kubernetes のエクスペリエンスと一緒に享受できます。300 ドル分のクレジットが付いたお得な 12 か月無料トライアルも新たに開始され、今までになく簡単に Container Engine を使い始めることができます。今すぐ Container Engine をお試しください。
* この投稿は米国時間 4 月 4 日、Software Engineer である Maisem Ali によって投稿されたもの（投稿はこちら）の抄訳です。
- By Maisem Ali, Software Engineer
