Kubernetes 1.24 リリース — 新機能

Kubernetes 1.24 は、当初 4 月 19 日にリリースされる予定でしたが、5 月 3 日まで延期されました。このリリースでは 46 の機能強化が行われ、そのうち 13 は安定バージョンにアップグレードされ、14 は既存の機能の改善、13 はまったく新しい機能、6 つは非推奨の機能です。

主なアップデート内容は以下のとおりです。

Dockershimを完全に削除する

dockershim コンポーネントは、v1.20 で非推奨とマークされた後、kubelet から削除されました。 v1.24 以降では、サポートされている他のランタイム (containerd や CRI-O など) のいずれかを使用するか、コンテナーランタイムとして Docker エンジンに依存している場合は cri-dockerd を使用する必要があります。

CSI ボリュームヘルスモニタリング

永続ボリュームの健全性をチェックするサイドカーをロードできる機能は、歓迎すべき追加機能です。これにより、管理者は Kubernetes 外部の永続ボリュームの削除などのイベントに対してより適切かつ迅速に対応できるようになり、Kubernetes クラスターの信頼性が必然的に向上します。

kubelet: OOM メトリックを公開する

1.24 以降、kubelet はコンテナ内で発生する OOM (OutOfMemory) イベントの数を記録するための新しい Prometheus メトリックを提供します。これにより、メモリ制限がコンテナの使用状況とニーズに追いつかない場合に、Kubernetes 操作で繰り返し発生する問題をより詳細に把握できるようになります。

この新しいメトリックを使用すると、SRE は問題の根本的な原因をより深く理解し、それが繰り返し発生する問題なのか、それともエッジケースなのかをより適切に判断できるようになります。トラブルシューティングが速くなり、ユーザーの満足度が高まります。

ベータAPIはデフォルトで無効になっています

以前のバージョンでは、不安定であると見なされたベータ API がデフォルトで有効になっていたため、これらの機能の導入が加速しましたが、問題も発生しました。たとえば、ベータ API にバグがある場合、デプロイされたクラスターの 90% でそのバグが発生します。

Kubernetes 1.24 以降では、新しいベータ API はデフォルトで無効になります。

必要なロードバランサーのタイプを選択します

Kubernetes 1.24 では、Service.Spec.LoadBalancerClass が GA になりました。

マネージド Kubernetes クラスターで LoadBalancer タイプのサービスを作成すると、ロードバランサーが作成されます。このロードバランサーの作成は、Kubernetes サービスプロバイダーの責任です。

この LoadBalancerClass フィールドを通じて、ユーザーは必要なロードバランサーのタイプを指定でき、これによりクラウドプロバイダーはさまざまな種類のロードバランサーをネイティブに提供できるようになります。これまで、これは主にアノテーションやカスタムコントローラーに依存していましたが、これは扱いにくく、直感に反する可能性があります。アノテーションは、プロバイダー固有のコントローラーのバージョンごとに異なることが多く、これにより、マネージド Kubernetes サービスのユーザーにとってネットワークが容易になることを期待しています。

Service.Spec.LoadBalancerIP フィールドは非推奨です

アノテーションに関して言えば、Kubernetes チームは Service.Spec.LoadBalancerIP フィールドを非推奨にすることを決定しました。その理由は、IPv4 アドレスと IPv6 アドレスの両方を必要とするデュアルスタックサービスがサポートされていないため、指定されていないためです。

プロバイダーはこのフィールドではなくアノテーションに依存することが公式に推奨されています。

オープンAPIv3

Kubernetes 1.24 では、OpenAPI v3 形式で API を公開するためのベータサポートが提供されます。

ストレージ容量とボリューム拡張が一般提供開始

ストレージ容量追跡サポートは、CSIStorageCapacity オブジェクトを通じて現在使用可能なストレージ容量を公開し、遅延バインディングで CSI ボリュームを使用するポッドのスケジュールを強化します。

ボリューム拡張により、既存の永続ボリュームのサイズ変更のサポートが追加されます。

gRPC プローブがベータ版にアップグレードされました

Kubernetes 1.24 では、gRPC プローブがベータ版となり、デフォルトで利用可能になりました。 HTTP エンドポイントを公開したり、追加の実行可能ファイルを使用したりすることなく、Kubernetes でネイティブに gRPC アプリケーションの起動、生存、準備プローブを構成できるようになりました。

サービスアカウントには、デフォルトでは Secret がありません。

これは、Kubernetes の Secrets に保存されている長期サービスアカウントトークンを使用する Kubernetes ユーザーにのみ影響します。

Kubernetes 1.23 より前では、クラスターにサービスアカウントを作成すると、Kubernetes によってそのサービスアカウントのトークンを含む Secret が自動的に作成されていました。このトークンは期限切れにならないため便利ですが、セキュリティ上の問題もあります。 Kubernetes 1.24 以降では、これらの Secret は自動的に作成されなくなりました。

次のような疑問が湧くかもしれません: トークンは、サービスアカウントを使用する Pod にインストールされていませんか?いいえ。新しい Pod が作成されると、kubelet は TokenRequest API を使用して Pod のトークンを生成し、それが投影されたボリュームとしてマウントされます。トークンは、1 時間後またはポッドが削除された時点のいずれか早い方で期限切れになります。 Kubelet はトークンを定期的に更新し、Pod が常に有効なトークンをマウントできるようにします。

期限切れにならないトークンを Secret に保存することが絶対に必要な場合は、自分で Secret を作成し、特別なコメントを追加することでトークンを取得できます。すると、Kubernetes がトークンを Secret に追加します。

RuntimeClass.Overhead フィールド GA

デフォルトのコンテナランタイム以外のものを使用する理由は多数あります。たとえば、信頼できないワークロードや GPU を必要とするワークロードを実行する場合などが挙げられます。 Kubernetes は、これらのユースケース向けのカスタムランタイムクラスの定義をネイティブにサポートします。

これらのカスタムランタイムでは、オーバーヘッドが発生する可能性があります。CPU とメモリは、ランタイム内で実行されているコンテナーではなく、ランタイム自体によって使用されます。 RuntimeClass.Overhead フィールドは Kubernetes 1.24 で一般提供され、クラスターオペレーターがこのオーバーヘッドを指定できるようになり、Kubernetes はスケジュールの決定時にこれを考慮に入れるようになりました。

その他の注目すべきアップデート: