Kubernetes 1.24 の新機能

5月4日にKubernetesバージョン1.24が正式にリリースされました。以前のバージョンと同様に、Kubernetes には大小さまざまな変更が数十個も加えられました。インフラストラクチャ、運用と保守、アプリケーション開発に関わる側面は数十あります。これらすべてを理解するのは誰にとっても難しいかもしれません。この記事では、それらを一つずつ列挙するつもりはありません。私自身の経験に基づいて、アプリケーション開発者がさらに注意を払うべきいくつかのポイントについてお話ししたいと思います。

最初に影響を受けるのは、dockershim サポートの公式削除です。 1年以上前、Kubernetes バージョン 1.20 では、Docker のサポートが「非推奨」に設定され、今後は進化せず、「将来のバージョンで削除される」ことが発表されました。今回リリースされたバージョン1.24は、いわゆる「Dockerサポートの公式削除」バージョンです。しかし、Docker 社は、Docker は Kubernetes 環境で引き続き使用できると主張しており、同社の Docker Desktop 製品のユーザーは、Kubernetes の最新リリース バージョンをシームレスに使用できるとのことです。どうしたの？

実際、公式の Kubernetes 1.24 変更ログを注意深く読むと、Docker サポートの説明が 1 年前のバージョン 1.20 と微妙に異なることがわかります。

バージョン 1.20 変更ログ スクリーンショット

バージョン 1.24 変更ログ スクリーンショット

Kubernetes が Docker を削除した主な理由は、Docker が長い間 Kubernetes が推進する CRI コンテナ ランタイム インターフェース標準をサポートしていなかったためです。そのため、Kubernetes コミュニティは Docker に接続するための dockershim コンポーネントを維持してきました。

Docker が独占していたときには、これは非常に必要でした。 containerd や kata などのコンテナ ランタイムが成熟し、特に containerd が実稼働環境で広く使用されるようになったため、Kubernetes コミュニティは dockershim をメンテナンスしないことに決定しました。

しかし、過去 2 年間、Mirantis (2019 年 11 月に Docker Enterprise 部門を買収) と Docker は Kubernetes のサポートに投資を続けています。現在、コミュニティには Kubernetes から独立し、CRI をサポートする「shim」である cri-dockerd がすでに存在しており、Kubernetes と Docker の接続を実現し続けています。

Docker Desktop は、その優れたユーザー エクスペリエンスにより、多くの開発者に好まれています。 Kubernetes 1.20 のリリース以来、私は Docker Desktop の代替品を探していて、いろいろ試してきましたが、まだそれに匹敵する製品を見つけていません。 cri-dockerd により、Kubernetes 1.24 は引き続き Docker コンテナ ランタイムに接続できるようになります。つまり、ユーザーはこれまでと同様にワンクリックで最新バージョンの Kubernetes を Docker Desktop にシームレスにインストールして使用できることになります。これは開発者にとって間違いなく朗報です。

同時に、Docker イメージはさまざまなコンテナ ランタイムで使用される標準イメージ形式になったため、開発には Docker を使用し、本番環境や顧客環境へのリリースには他のコンテナ ランタイムを使用するという現象が長期的には一般的になってくる可能性があります。

2 番目にお話ししたいのは、Kubernetes ジョブです。バッチ処理アプリケーションの負荷に対して、Kubernetes はそれをサポートするジョブ リソースを提供します。ただし、並列処理や分散コンピューティング ジョブを実行したい場合、問題が発生します。Kubernetes のポッドは動的に作成およびリサイクルされます。これは、Kubernetes ジョブに基づいてバッチ ワークロードを実行する利点の 1 つでもあります。リソースは必要なときにのみ占有され、使用後はすぐにリサイクルできるためです。ただし、これにより、さまざまな Pod にタスクを割り当てるための基盤が不足することになります (マシンベースの並列コンピューティング システムでは、タスク スケジューリングの入力として、ホスト名などの比較的固定された識別子が必要になることがよくあります)。

以前のバージョンでは、Kubernetesはこの問題を解決するために、ジョブの各ポッドに番号を割り当てるメッセージキューまたはインメモリデータベースを導入することを公式に推奨していました[1]。これにより、アプリケーションの複雑さが増し、サードパーティ コンポーネントの運用と保守に関する問題が発生したことは間違いありません。 Kubernetes バージョン 1.24 には、ベータ段階から正式な機能に昇格された「Indexed Job」という機能があります。この機能は、同じジョブの各ポッドの環境変数に数値インデックスを挿入します。アプリケーションはこの番号に基づいて各ポッドに特定のタスクを割り当てることができます。

昨年、この機能がまだベータ段階だったとき、著者は、Kubernetes Job に基づくクラウドネイティブの分散グラフ コンピューティング アプリケーションを、外部メッセージ キューに依存してインデックス ジョブにタスクを割り当てる方法から変更しようとしました。アプリケーションの保守性、安定性、リソース消費が大幅に改善されました。

開発者が注目することを推奨する 3 番目の機能は、gPRC ヘルス ステータス プローブがすでにベータ ステータスになっていることです。これは期待する価値のある機能です。 gRPC プロトコルは、クラウドネイティブ アプリケーションでますます広く使用されるようになっています。しかし、Kubernetes にはこれまで gRPC のネイティブ ヘルス ステータス プローブのサポートが欠けていたため、gRPC サービスの起動、存続、準備ステータスのチェックには他の手段に頼る必要がありました。公式サイトにはこれらの技術的手段を紹介する記事がある[2]。この記事から、これらの方法が Kubernetes 上のアプリケーション移行のコストとクラウドネイティブ アプリケーションの保守性と可用性に一定の影響を与えることは容易にわかります。 Kubernetes が gRPC プローブをネイティブにサポートするようになってから、これらの問題は効果的に解決されました。 gRPC プロトコルを使用してクラウドネイティブ アプリケーションを構築する同僚は、この機能がベータ ステータスから将来正式に利用可能になることを期待できます。

最後に、非常に興味深いアップデートを思いつきました。バージョン 1.24 以降では、kubeadm が Kubernetes クラスターをインストールするときに、コントロール プレーン コンポーネントを実行しているノードを「マスター」としてマークしなくなりました。これは、この単語が「不快」であると見なされるためです。近年、マスタースレーブノードを表すためにマスタースレーブを使用していた一部のコンピュータシステムでは、用語が変更されました。スレーブは2年前に姿を消し、現在はマスターも使用できなくなっているようです。