Kubernetes 1.24における新機能は?

本文の内容は、2022年4月12日にVicente Javier Jiménez Mirasが投稿したブログ(https://sysdig.com/blog/kubernetes-1-24-whats-new/）を元に日本語に翻訳・再構成した内容となっております。

Kubernetes 1.24がリリースされようとしています。どこから始めましょうか？
アップデート：Kubernetes 1.24のリリース日が5月3日に変更されました(4月19日から)今回のリリースでは、Kubernetes 1.23の45、Kubernetes 1.22の56と同程度の46の機能強化が行われました。この46の機能強化のうち、13がStableへの移行、14が改善を続ける既存機能、13が完全な新規機能、そして6が非推奨機能です。

今回のリリースの大きな箇所は、Dockershimの削除です。Kubernetesプロジェクトの将来を確実なものにするために必要なステップです。このバージョンでは、すべての非推奨と削除に注意してください!

このバージョンに含まれる新機能は概して小さなものですが、Kubernetesとの付き合い方を変える可能性を持っています。新しいネットワークポリシーステータスフィールド、新しいCSIボリュームヘルスモニタリング、またはCronJobsのTimeZoneサポートのようなものです。また、他の機能は、StatefulSetsのmaxUnavailableや、非グレースフルノードシャットダウンのように、クラスター管理者の生活をより簡単にします。

最後に、このリリースのケーキの上のアイシングは、GA状態に達しているすべての素晴らしい機能です。長い歴史を持つ次のような機能が含まれています。CSIボリューム拡張、PodOverhead、ストレージ容量追跡、Service Type=LoadBalancerクラスなど、長い歴史を持つ機能が含まれています。私たちは、このリリースにとても興奮しています。

では、Kubernetes 1.24の新機能をご紹介しましょう。

Kubernetes 1.24 – 編集者のおすすめ：

このリリースで最もエキサイティングに見える機能は、以下の通りです（ymmv）。

#2221 Dockershimの削除
プロジェクトが成長するにつれ、その将来を保証するためにレガシー機能を手放す必要があります。DockershimはKubernetesのコンテナランタイムでしたが、より優れたCRI pluggableシステムに取って代わられました。Dockershimが削除された今、多くの開発者やクラスター管理者は、不便ではあるが必要な移行を行わなければならないだろう。

Víctor Jiménez Cerrada – Sysdig社コンテンツマネージャーエンジニア

#1432 CSIボリュームのヘルスモニタリング
永続ボリュームの健全性をチェックするサイドカーをロードできるようになったことは、歓迎すべきことです。これでクラスター管理者は、Kubernetesの外部で永続ボリュームが削除されたようなイベントに対して、より適切かつ迅速に対応することができるようになります。これによって、Kubernetesクラスターの信頼性が向上することは間違いないです。

Vicente J. Jiménez Miras – Sysdig社セキュリティコンテンツエンジニア

#2943 ネットワークポリシーステータス
そうですね、このようなユーザーフレンドリーな機能をもっと増やしてください。ゼロ・トラスト・アプローチに従ったネットワーク・ポリシーを作成することは、コンテナ・セキュリティのベスト・プラクティスです。しかし、時にはデバッグが困難なエラーが発生し、ポリシーを望ましい以上に変更してしまうことがあります。このような状況をデバッグできるようになれば、Kubernetesクラスターの安全性はより高まるでしょう。

Miguel Hernández – Sysdig社セキュリティコンテンツエンジニア

#2578 Windows運用準備の定義とツールの収束
Kubernetes 1.14で導入されて以来、Windowsのサポートはリリースごとに増え続け、そうでなければ検討しなかったような幅広い企業にKubernetesを開放しています。

Kubernetes 1.24が定義するこの標準によって、Kubernetesベンダー間のWindowsサポートを比較することが容易になることでしょう。これで、こうした環境でのKubernetesの採用が、少しでも不確実性を減らすことができればと思います。

Daniel Simionato – Sysdig社セキュリティコンテンツエンジニア

#108004 kubelet: OOM メトリクスの公開
これはエンハンスメントとは呼べないような小さな改善ですが、大きな反響を呼ぶでしょう。1.24から、kubeletはコンテナで発生したOutOfMemoryイベントの数を記録する新しいPrometheusメトリクスを提供します。これにより、Kubernetesの運用において、メモリ制限がコンテナの使用量やニーズを満たさない場合に繰り返し発生する問題を、より可視化することができます。

この新しいメトリクスにより、SREは問題の最終的な原因をより深く理解し、それが繰り返し発生する問題なのか、エッジケースなのかをより的確に判断することができます。トラブルシューティングの迅速化により、ユーザーはより幸せになります。

David de Torres – Sysdig社 エンジニアリングマネージャー

非推奨事項

APIおよび機能の削除

Kubernetes 1.24では、以下のようないくつかのベータ版APIと機能が削除されました。

• Dockershimを削除しました。
• 実験的な動的ログサニタイズ機能を削除しました。
• ダッシュボードのクラスターアドオンを削除しました。
• cloud-controller-managersがコンシュームするcloud-providerパッケージから、安全でないサービング設定を削除しました。
• 7.0u2 未満の VSphere リリースを非推奨としました。
• in-tree azure プラグインを非推奨としました。
• metadata.clusterName フィールドを非推奨としました。
• Client.authentication.k8s.io/v1alpha1 ExecCredential を削除しました。
• node.k8s.io/v1alpha1 RuntimeClass APIは提供されなくなったので、/v1を使用してください。
• Service の tolerate-unready-endpoints アノテーションを削除し、代わりに Service.spec.publishNotReadyAddresses を使用するようにしました。
• Service.Spec.LoadBalancerIP を非推奨としました。
• CSIStorageCapacity API バージョン v1beta1 を非推奨とし、v1 を使用するようにしました。
• VolumeSnapshot v1beta1 を削除し、v1 を使用します。
• フィーチャーゲート：
  • ValidateProxyRedirectsを削除しました。
  • StreamingProxyRedirects を削除しました。
• Kube-apiserver：
  • Kube-apiserver: –master-count flag と –endpoint-reconciler-type=master-count reconciler を非推奨とし、lease reconciler を優先させました。
  • アドレスフラグ –address、–insecure-bind-address、–port、–insecure-port を削除しました。
• Kubeadm：
  • UnversionedKubeletConfigMap 機能ゲートはデフォルトで有効です。
  • kubeadm.k8s.io/v1beta2 は非推奨となりました。新しいクラスターには v1beta3 を使ってください。
  • node-role.kubernetes.io/masterのラベルを削除しました。
• Kube-controller-manager：
  • フラグ –address と –port を削除しました。
• Kubelet：
  • フラグ –pod-infra-container-image を非推奨とした。
  • DynamicKubeletConfigを削除。

変更点の全リストは、Kubernetes 1.24のリリースノートで確認できます。また、Kubernetes Removals and Deprecations In 1.24 の記事、および非推奨のAPI移行ガイドを今後のために近くに置いておくことをお勧めします。


#2221 Dockershimの削除
ステージ ：ステーブルへのメジャー変更
機能グループ: ノード

Dockershim は、kubelet コードベースのビルトインコンテナランタイムの一つです。しかし、Container Runtime Interface (CRI) の導入により、コンテナランタイムをkubeletコードベースから切り離すことが可能になりました。

さらに、このデカップリングは、開発者とクラスターメンテナーの両方にとってメンテナンスを簡素化するグッドプラクティスです。

代替手段が存在するので、これはKubernetesの機能を失うことを意味するものではありません。以下のリソースが参考になるかもしれません。

• Migrating from dockershim
• Kubernetes is Moving on From Dockershim
• Dockershim removal FAQ
• Is Your Cluster Ready for v1.24?

#281 DynamicKubeletConfig
ステージ ：削除されました
機能グループ：ノード

Kubernetes 1.11からベータ版として提供されてきたDynamicKubeletConfigですが、Kubernetesチームは開発を継続する代わりに非推奨とすることを決定したそうです。

#3136 Beta APIはデフォルトでオフ
ステージ ：ステーブルへの移行
機能グループ：アーキテクチャー

ステーブルと見なされていないBeta APIは、デフォルトで有効になっています。これは、これらの機能の採用を加速させるという、良い面もありました。しかし、これはいくつかの問題の門を開くことになります。例えば、Beta APIにバグがあった場合、デプロイされたクラスターの90%にバグが存在することになります。

Kubernetes 1.24からは、新しいBeta APIはデフォルトで無効化されます。

この変更は、フィーチャーゲートには影響しません。

さらなる論理的根拠と実装の詳細については、KEPを確認するとよいでしょう。

#1164 SelfLinkの非推奨と削除
ステージ： ステーブルへの移行
機能グループ：api-machinery
フィーチャーゲート: RemoveSelfLink Default value: true

この機能を有効にすると、.metadata.selfLinkフィールドはKubernetes APIの一部として残りますが、常にunsetされた状態になります。

詳しくは、「Kubernetes 1.20における新機能は？」

#1753 Kubernetesシステムコンポーネントのログサニタイゼーション
ステージ： 削除されました
機能グループ：インスツルメンテーション

ログのサニタイズは、Kubernetes 1.20でアルファ版として導入されました。いくつかのバージョンで評価した後、Instrumentation SIGは、Kubernetes 1.23でStableになった静的分析がより良いアプローチであると判断しました。

#2845 Kubernetes コンポーネントにおける klog 固有のフラグを非推奨とする
ステージ： ベータへの移行
機能グループ：インスツルメンテーション

この機能強化は、コンポーネントにおけるロギングを簡素化するための大きな努力の一部です。最初の布石は、klogのいくつかのフラグを削除することです。

詳しくは「Kubernetes 1.23における新機能は?」の記事をご覧ください。

Kubernetes 1.24 API

#1904 効率的なwatchの再開
ステージ：ステーブル への移行
機能グループ：api-machinery
フィーチャーゲート: EfficientWatchResumption Default value: true

今後、kube-apiserverは再起動後のウォッチキャッシュの初期化をより高速に行えるようになります。

詳しくは、「Kubernetes 1.20における新機能は？」

#2885 フィールドバリデーションのベータへの移行基準
ステージ：ベータへの移行
フィーチャーグループ：api-machinery
フィーチャーゲート: ServerSideFieldValidation Default value: true

現在、kubectl -validate=trueを使用すると、オブジェクトの不明なフィールドを指定した場合、リクエストが失敗することを示すことができます。この機能拡張は、kube-apiserverにバリデーションを実装するための作業をまとめたものです。

詳しくは「Kubernetes 1.23における新機能は?」の記事をご覧ください。

#2887 openapiのenum型がベータに
ステージ ：ベータへの移行
フィーチャーグループ：api-machinery
フィーチャーゲート: OpenAPIEnum Default value: true

この機能強化により、Kubernetes OpenAPIジェネレーターは、+enumでマークされたタイプを認識し、enumの可能な値を自動検出できるようになりました。

詳しくは「Kubernetes 1.23における新機能は?」の記事をご覧ください。

#2896 OpenAPI v3
ステージ ：ベータへの移行
フィーチャーグループ：api-machinery
フィーチャーゲート: OpenApiv3 Default value: true

この機能は、KubernetesとタイプをOpenAPI v3オブジェクトとして提供するためのサポートを、kube-apiserverに追加します。新しい/openapi/v3/apis/{group}/{version}エンドポイントが利用可能です。これは、すべてを1つに集約するのではなく、リソースごとに1つのスキーマを提供します。

詳しくは「Kubernetes 1.23における新機能は?」の記事をご覧ください。

Kubernetes 1.24のApps

#961 StatefulSetsのmaxUnavailable
ステージ： アルファ
機能グループ：Apps
フィーチャーゲート: MaxUnavailableStatefulSet Default value: false

ステートフルセットはステートフルなアプリケーションをサポートします。その理由は、安定した永続的ストレージ、一意のネットワーク識別子、順序付けられたローリングアップデートなど、いくつかのユースケースを挙げることができます。

この最後のケースでは、ローリングアップデートを実行するときに、Podは一度に1つずつ削除され、再作成されます。これにより、アプリケーションのインスタンスが失われるリスクを最小限に抑え、可用性と何か問題が発生した場合のロールバックの可能性を最大化することができます。

サブリソースmaxUnavailableは、今後、一度にいくつのアプリケーションPodを削除し、再作成するかを制御するようになり、アプリケーションのローリングアップデートを高速化することができます。

驚かないように、ステートフルアプリケーションのローリングアップデートを行う前に、この新しいパラメータの値を確認することを忘れないでください。非常に高い値は、ローリングデプロイメントを再作成するものに切り替える可能性があり、サービスを完全に失うことを心に留めておいてください。

#3140 CronJobのタイムゾーンのサポート
ステージ：アルファ
機能グループ：Apps
フィーチャーゲート: CronJobTimeZone Default value: false

この機能は、CronJobリソースでタイムゾーンをサポートするために遅れていたリクエストに対応するものです。これまで、CronJobsによって作成されたジョブは、kube-controller-managerのプロセスがベースとしていたタイムゾーンと同じに設定されていました。

ジョブが開始する必要がある時刻を計算する作業は終了です。正しいタイムゾーンを見つけることは、あなたの新しい挑戦となるかもしれません。

#2214 Job APIにおけるIndexed Jobセマンティクス
ステージ：ステーブルへの移行
機能グループ：Apps
フィーチャーゲート: IndexedJob Default value: true

インデックスジョブはKubernetes 1.21で導入され、高度に並列化可能なジョブのスケジューリングが容易になりました。

この機能拡張は、固定完了カウントを持つジョブのPodに完了インデックスを追加し、あきれるほどの並列プログラムの実行をサポートします。

詳しくは「Kubernetes 1.22における新機能は?」の記事をご覧ください。

#2232 batch/v1: Jobs APIにサスペンドフィールドを追加
ステージ：ステーブルへの移行
機能グループ：Apps
フィーチャーゲート: JobReadyPods Default value: true

Kubernetes 1.21 以降、ジョブの .spec.suspend フィールドを true に設定することでジョブを一時的に中断し、後で false に戻すことで再開することができるようになりました。

詳しくは「Kubernetes 1.21における新機能は？」の記事をご覧ください。

#2879 ジョブステータスでReady Podを追跡する
ステージ： ベータ版への移行
機能グループ：Apps
フィーチャーゲート: JobReadyPods Default value: true

この機能強化により、既存の active、succeeded、failed フィールドと同様に、Ready 状態の Job Pods の数をカウントする Job.status.ready フィールドが追加されました。このフィールドは、現在の状態をより正確に把握するために、Podの更新をリッスンする必要性を減らすことができます。

詳しくは「Kubernetes 1.23における新機能は?」の記事をご覧ください。

Kubernetes 1.24 Auth

#2784 CSR Duration
ステージ ：ステーブルへの移行
機能グループ：auth
フィーチャーゲート: CSRDuration Default value: true

CertificateSigningRequestSpecにExpirationSecondsフィールドが追加され、最小値として600秒（10分）を受け入れるようになりました。これにより、クライアントは証明書の有効期間をデフォルトの1年よりも短く定義することができます。

詳しくは「Kubernetes 1.22における新機能は?」の記事をご覧ください。

#2799 シークレットベースのサービスアカウントトークンの削減
ステージ ベータ版への移行
機能グループ：auth
フィーチャーゲート: LegacyServiceAccountTokenNoAutoGeneration Default value: true

Kubernetes 1.22以降、TokenRequest APIが安定したため、いくつかのクリーンアップを行い、古いトークンよりもこのAPIの使用を促進する時期に来ています。

これまでKubernetesはPodを作成する際に、自動的にサービスアカウントのSecretを作成していました。そのトークンであるSecretには、APIにアクセスするための認証情報が含まれていました。

現在は、APIの認証情報はTokenRequest APIを通じて直接取得され、projected ボリュームを使用してPodにマウントされます。また、これらのトークンは関連するPodが削除されると自動的に無効化されます。必要であれば、手動でトークンシークレットを作成することもできます。

既存のトークンを追跡してクリーンアップする機能は、Kubernetesの将来のバージョンで追加される予定です。

Kubernetes 1.24のネットワーク

#2943 ネットワークポリシーステータス
ステージ ：アルファ
機能グループ：ネットワーク
フィーチャーゲート: NetworkPolicyStatus Default value: false

ネットワークポリシーリソースは、CNIプロバイダーによって実装が異なります。また、異なる順序で機能が実装されるかもしれません。このため、現在のCNIプロバイダーによってネットワークポリシーが尊重されず、最悪の場合、その状況についてユーザーに通知されないということが起こり得ます。

新しいStatusサブリソースは、NetworkPolicyとその機能が適切にパースされたかどうかのフィードバックを受け取り、特定の機能が動作しない理由を理解するのに役立つようにします。

これは、次のような問題のトラブルシューティングに役立つでしょう：

• プロバイダーがまだ実装していないEgress Network Policyのポート範囲。
• 新しく発表された機能でネットワークポリシーを作成したが、動作しないようだ。
• ステージング環境で開発されたネットワークポリシーが、少し古いリリースバージョンで動作している可能性のある本番環境では、異なる動作をするようだ。

全体として、Kubernetesネットワークの問題のトラブルシューティングをより苦痛のないものにする1つの前進と言えるでしょう。

この新機能についてもっと知りたい方は、KEPをチェックしてみてください。

#3070 ダイナミックおよびスタティックIP割り当てのためのサービスIPレンジの予約
ステージ ：アルファ
機能グループ：ネットワーク
フィーチャーゲート: ServiceIPStaticSubrange Default value: false

Kubernetesサービスは、Podのセット上で動作するアプリケーションを公開するための抽象的な方法です。サービスには仮想的なClusterIPがあり、異なるPod間でトラフィックをロードバランスすることができます。このClusterIPは割り当てることができます：

• 動的に、クラスターは構成されたサービスIPの範囲内で1つを選びます。
• 静的には、ユーザが設定されたサービスIPの範囲内で1つのIPを設定します。

Service に固定 IP アドレスを設定することは、非常に便利ですが、かなり危険でもあります。現在のところ、既存のサービスにIPアドレスが動的に割り当てられているかどうかを事前に知る方法はありません。

この機能は、静的および動的なIP割り当てを使用しているサービス間でIPの競合が発生するリスクを下げ、同じタイプで後方互換性を維持します。

この機能の実装は、現在サービスに IP アドレスを割り当てるために使用されている –service-cluster-ip-range フラグに文字列パラメータとして渡される、サービスネットワークの 2 つのバンドへの分割に基づいています。

下部は静的IPアドレスに優先的に使用され、上部は動的に割り当てられたIPアドレスに優先的に使用されます。ただし、上側の帯域を使い切った場合は、下側の帯域を継続して使用します。

これらの値を計算する公式はKEPに記載されていますが、ここでは、静的バンドには少なくとも16個のIPが含まれるが、256個を超えることはない、と要約しておきます。

#1435 type=LoadBalancer のサービスにおける混合プロトコルのサポート
ステージ： ベータへの移行
機能グループ：ネットワーク
フィーチャーゲート: MixedProtocolLBService Default value: true

この機能拡張により、LoadBalancerサービスは同じポート（UDP、TCP）で異なるプロトコルに対応できるようになります。例えば、DNSやSIPサーバーに対するUDPとTCPの両方のリクエストを同じポートで提供することができます。

詳しくは、「Kubernetes 1.20における新機能は？」をご覧ください。

#2086 サービスインターナルトラフィックポリシー
ステージ ：ベータへの移行
機能グループ：ネットワーク
フィーチャーゲート: ServiceInternalTrafficPolicy Default value: true

Serviceオブジェクトにspec.trafficPolicyフィールドを設定し、クラスタートラフィックを最適化できるようになりました：

• Clusterの場合、ルーティングは通常通り動作します。
• Topologyに設定すると、トポロジーを考慮したルーティングが使用されます。
• PreferLocalに設定すると、同じノードにあるサービスにトラフィックをリダイレクトします。
• Localを指定すると、同一ノード上のサービスにのみトラフィックを送信します。

詳しくは「Kubernetes 1.21における新機能は？」をご覧ください。

Kubernetes 1.24 ノード

#688 PodOverhead
ステージ：ステーブルへの移行
機能グループ: ノード
フィーチャーゲート: PodOverhead Default value: true

要求されたリソースに加えて、ポッドはそのランタイム環境を維持するために余分なリソースを必要とします。

この機能を有効にすると、Kubernetesはポッドをスケジューリングする際にこのオーバーヘッドを考慮します。Podオーバーヘッドはアドミッション時に計算されて固定され、PodのRuntimeClassに関連付けられます。

詳しくは、「Kubernetes 1.16 – What’s new?」をご覧ください。

#2133 Kubeletクレデンシャル・プロバイダー
ステージ： ベータへの移行
機能グループ: ノード
フィーチャーゲート: DisableKubeletCloudCredentialProviders Default value: true

この機能拡張は、インツリーコンテナイメージレジストリのクレデンシャルプロバイダを、外部でプラグイン可能な新しいメカニズムに置き換えるものです。

詳しくは、「Kubernetes 1.20における新機能は？」をご覧ください。

#2712 PriorityClassValueBasedGracefulShutdown
ステージ： ベータへの移行
機能グループ: ノード
フィーチャーゲート: GracefulNodeShutdownBasedOnPodPriority Default value: false

今後、ノートがグレースフルシャットダウンする際に、優先度の高いPodに対してより多くの停止時間を提供することができます。この機能拡張により、Podの優先度クラスの値に応じて、Podに異なる停止時間を提供する可能性が追加されました。

詳しくは「Kubernetes 1.23における新機能は?」の記事をご覧ください。

Kubernetes 1.24では、ノードのシャットダウンを監視するためにgraceful_shutdown_start_time_secondsとgraceful_shutdown_end_time_secondsというメトリクスが利用可能です。

#2727 gRPCプローブ
ステージ： ベータへの移行
機能グループ：ノード
フィーチャーゲート: GRPCContainerProbe Default value: true

この機能拡張により、PodにgRPC (HTTP/2 over TLS) livenessプローブを設定できるようになります。

Kubernetes 1.16で追加されたlivenessプローブにより、アプリケーションがまだ生きているかどうかを定期的にチェックできるようになりました。

Kubernetes 1.23では、gRPCプロトコルのサポートが追加されました。

Kubernetes 1.24のスケジューリング

#3022 minDomains in PodTopologySpread
ステージ： アルファ
機能グループ：スケジューリング
フィーチャーゲート: MinDomainsInPodTopologySpread Default value: false

新しいPodがノードに割り当てられるとき、PodTopologySpreadサブリソースは、maxSkewパラメータを介して、Podの分布がどの程度不均一になることができるかを定義します。利用可能なリソースの数によっては、maxSkewの要件を満たすことができない場合があります。これは、WhenUnsatisfiable=DoNotScheduleパラメータを使用する場合、利用可能なリソースが十分でないため、スケジューラーから新しいPodを割り当てることが否定されることにつながります。

一方、リソースの無駄遣いを防ぐために、Cluster Autoscalerは利用状況に応じてドメインをスケールアップ/スケールダウンすることができます。しかし、ドメインが0にスケールダウンされると、スケジューラーが実行する計算に含まれるドメインの数は、利用可能なリソースの総数を正直に反映しない可能性があります。つまり、0にスケールダウンされたドメインはスケジューラーから見えなくなります。

新しいminDomainsサブリソースは、新しいPodをスケジューリングする時点では存在しないかもしれないにもかかわらず、利用可能としてカウントされるべきドメインの最小数を確立します。したがって、必要なときにドメインはスケールアップされ、そのドメイン内の新しいノードがクラスタオートスケーラによって自動的に要求されることになります。

詳細については、この機能のKEPをためらわずに調べてください。

#902 Non-preempting Priority を GAへ
ステージ：ステーブル への移行
機能グループ：スケジューリング
フィーチャーゲート: NonPreemptingPriority Default value: true

現在、PreemptionPolicy のデフォルトは PreemptLowerPriority で、優先度の高いポッドが優先度の低いポッドを先取りすることを許可しています。

この拡張により、PreemptionPolicy が追加されます。Neverオプションが追加され、Podは優先度の低いPodよりも先にスケジューリングキューに入れられるようになりましたが、他のPodを先取りすることはできません。

詳しくは、「Kubernetes 1.15 – What’s new?」をご覧ください。

#2249 Pod affinity NamespaceSelector を GA へ
ステージ ：ステーブルへの移行
機能グループ：スケジューリング
フィーチャーゲート: PodAffinityNamespaceSelector Default value: true

デプロイメントでノードアフィニティを定義することで、自分のポッドがどのノードでスケジュールされるかを制限できます。たとえば、example-label の label-value を持つ ポッドをすでに実行しているノードにデプロイします。

今回の機能強化では、namespaceSelector フィールドが追加され、名前ではなくラベルでネームスペースを指定できるようになりました。このフィールドを使用すると、ネームスペースのセットを動的に定義することができます。

詳しくは、「Kubernetes 1.21における新機能は？」をご覧ください。

Kubernetes 1.24 ストレージ

#2268 Non-graceful node shutdown
ステージ： アルファ
機能グループ：ストレージ
フィーチャーゲート: NonGracefulFailover Default value: false

ノードがシャットダウンされたがKubeletのノードシャットダウンマネージャーによって検出されなかった場合、StatefulSetの一部であるポッドはシャットダウンしたノード上でターミネーション状態に陥り、新しい実行ノードに移動できなくなります。

この機能は、正しく検出されないノードシャットダウンのケースに対応します。この場合、ポッドは強制的に削除され、VolumeAttachmentsの削除がトリガーされ、新しいポッドが新しい実行中のノード上に作成されるので、アプリケーションは引き続き機能することができます。

これは、ハードウェア障害やOSの故障など、ノードが復旧不可能な状態に陥った場合にも適用できます。

この機能を実現するためには、ノードがシャットダウンまたは回復不可能な状態にあることを確認した後、ユーザーによって一度だけTaint Out-of-Serviceが適用される必要があります。out-of-service=nodeshutdown:NoExecute や out-of-service=hardwarefailure:NoExecute のように、以前のTaintに NoExecute 効果を追加すると、ポッドが退避し、他のノードで起動されるようになります。

ノードを復活させるには、ポッドを新しいノードに移動させた後、ユーザが手動でout-of-service taintを削除する必要があります。

#3141 ソースとターゲットPVC間のボリュームモード変換を制御する
ステージ ：アルファ
機能グループ：ストレージ
フィーチャーゲート: N/A

Kubernetes 1.20でGAされたVolumeSnapshot機能を活用し、以前取得したVolumeSnapshotから変換してPersistentVolumeClaimまたはPVCを作成することができます。残念ながら、ボリュームモード変換の検証はありません。

この機能は、そのような操作中にボリュームモードを不正に変換することを防止します。カーネルには悪意のあるユーザーが悪用できるような既知のCVEはありませんが、この機能は念のためその可能性を排除することを目的としています。

詳細な実装を知るために、ここに KEP を残しておきます。

#1432 CSIボリュームのヘルスモニタリング
ステージ： アルファ
機能グループ：ストレージ
フィーチャーゲート: CSIVolumeHealth Default value: false

CSIドライバーは、ボリュームの健全性をチェックするサイドカーとして外部コントローラをロードできるようになり、Kubeletがすでにボリュームの情報を収集するために使用しているNodeGetVolumeStats関数で追加の情報を提供できるようにもなりました。

詳しくは「Kubernetes 1.21における新機能は？」の記事をご覧ください。

Kubernetes 1.24では、Volume Healthの情報はkubelet VolumeStatsメトリクスとして公開されています。kubelet_volume_stats_health_status_abnormal メトリクスは、ボリュームが不健康な場合は 1、それ以外は 0 の値を持つ persistentvolumeclaim ラベルを持ちます。

#284 CSI ボリューム拡張
ステージ ：ステーブルへの移行
機能グループ：ストレージ
フィーチャーゲート:  ExpandPersistentVolumes Default value: true
フィーチャーゲート:  ExpandInUsePersistentVolumes Default value: true
フィーチャーゲート: ExpandCSIVolumes Default value: true

この一連の機能は、Kubernetes 1.11、1.15、1.16からそれぞれベータ版として提供されています。Kubernetes 1.24で、ようやくPersistent Volumeのサイズを変更する機能が安定したと見なされます。

#1472 ストレージ容量のトラッキング
ステージ：ステーブルへの移行
機能グループ：ストレージ
フィーチャーゲート: CSIMigrationAzureFile Default value: true
フィーチャーゲート: CSIMigration Default value: true

この機能拡張は、十分な空き容量がないCSIボリュームに接続されたノードでポッドがスケジュールされることを防止しようとするものです。

詳しくは、「Kubernetes 1.19 – What’s new?」の記事をご覧ください。

#1489 OpenStackのインツリーからCSIドライバへのマイグレーション
ステージ ：ステーブルへの移行
機能グループ：ストレージ
フィーチャーゲート: CSIMigrationOpenStack Default value: true

この機能強化は、OpenStack CinderのコードをメインのKubernetesバイナリから移動させる作業（アウトオブツリー）をまとめたものです。

#1490 Azure ディスクのインツリーから CSI ドライバへの移行
ステージ ：ステーブルへの移行
機能グループ：ストレージ
フィーチャーゲート: CSIMigrationAzureDisk Default value: true

この機能強化は、Azure DiskのコードをメインのKubernetesバイナリから移動する（アウトオブツリー）ための作業をまとめたものです。

詳しくは、「Kubernetes 1.19 – What’s new?」の記事をご覧ください。

#1885 AzureファイルのインツリーからCSIドライバへの移行
ステージ ：ベータへの移行
機能グループ：ストレージ
フィーチャーゲート: InTreePluginAzureDiskUnregister Default value: true

この機能強化は、Azure FileのコードをメインのKubernetesバイナリから移動する（アウトオブツリー）ための作業をまとめたものです。

詳しくは、「Kubernetes 1.21における新機能は？」の記事をご覧ください。

#1495 ボリュームポピュレーター
ステージ： ベータへの移行
機能グループ：ストレージ
フィーチャーゲート: AnyVolumeDataSource Default value: true

Kubernetes 1.18で導入されたこの機能拡張は、ユーザーが事前に入力されたボリュームを作成できるようにするための基礎を確立するものです。例えば、OSイメージを持つ仮想マシンのディスクを事前に作成したり、データのバックアップと復元を可能にしたりすることができます。

これを実現するために、永続ボリュームのDataSourceフィールドに対する現在のバリデーションは解除され、任意のオブジェクトを値として設定できるようになります。ボリュームに値を設定する方法についての実装の詳細は、専用のコントローラに委ねられます。

#2644 リクレイムポリシーを常に尊重する
ステージ ：ベータへの移行
機能グループ：ストレージ
フィーチャーゲート: HonorPVReclaimPolicy Default value: true

この機能拡張により、一部の Bound Persistent Volume (PV) –Persistent Volume Claim (PVC) ペアにおいて、PV-PVC削除の順序によってPV削除リクレイムポリシーが尊重されるかどうかが決定される問題が修正されます。

詳しくは「Kubernetes 1.23における新機能は?」の記事をご覧ください。

Kubernetes 1.24のその他の強化点

#2551 kubectlのリターンコードの正規化
ステージ ：アルファ
機能グループ：cli
フィーチャーゲート: N/A

これは機能というよりも、kubectlがサポートする様々なサブコマンドのリターンコードを標準化する試みであり、今後サポートする予定です。これは、タスクの自動化を促進し、コマンドの結果をよりよく理解することを目的としています。

#2590 kubectlのサブリソースサポートの追加
ステージ ：アルファ
機能グループ：cli
フィーチャーゲート: N/A

get、patch、edit、replaceなどの一部のkubectlコマンドに新しいフラグ –subresource=[subresource-name] が追加され、すべてのAPIリソースのステータスおよびスケールのサブリソースを取得および更新できるようになりました。

これにより、サブリソースを直接更新するために複雑なcurlコマンドを使用する必要がなくなりました。

#1959 Service Type=LoadBalancer クラス
ステージ：ステーブル への移行
機能グループ：cloud-provider
フィーチャーゲート: ServiceLoadBalancerClass Default value: true

この機能拡張により、クラスター内で複数のService Type=LoadBalancerの実装を利用できるようになります。

詳しくは、「Kubernetes 1.21における新機能は？」の記事をご覧ください。

#2436 leader migration が GAへ
ステージ：ステーブル への移行
機能グループ：cloud-provider
フィーチャーゲート: ControllerManagerLeaderMigration Default value: true

以前から議論されているように、クラウドプロバイダー特有のコードをKubernetesのコアコードの外に（インツリーからアウトオブツリーに）移動させようという動きが活発になっています。

この機能強化により、コントロールプレーンの可用性に厳しい要件を持つクラスター向けの移行プロセスが確立されます。

詳しくは、「Kubernetes 1.21における新機能は？」の記事をご覧ください。

#3077 Contextual logging
ステージ： アルファ
機能グループ：インスツルメンテーション
フィーチャーゲート: StructuredLogging Default value: false

この機能強化は、Kubernetesのロギングライブラリであるklogへの依存とその制限を取り除くための進行中の取り組みの1つです。これは、Kubernetes 1.19の構造化ロギングの取り組みの上に構築されています。

Contextual loggingには、開発者を対象とした2つの変更が含まれています：

• 依存関係を逆転させ、ライブラリはグローバルなLoggerを使用せず、渡されたインスタンスを使用するようになりました。
• ライブラリは、WithValues および WithName 関数を使用して、Logger（およびログ出力）に追加のコンテキスト情報を追加することができます。

たとえば、新しいLoggerは WithName を使用して作成できます：

 logger := klog.FromContext(ctx).WithName("foo")

このLoggerが渡されて使われると：

 logger.Info("Done")

接頭辞として “foo “を含むことになります。

関連するユースケースのひとつはユニットテストで、開発者は各テストケースに独自のLoggerを提供して出力を区別することができます。これは、ライブラリのコードを変更することなく行うことができます。

また、この依存関係の逆転は、klog への依存を取り除く道を開くものです。グローバルLoggerは、任意の logr.Logger の実装で置き換えることができます。

KEPでもっと面白い使用例を見つけ、次のブログ記事を見てください。

#3031 リリースアーティファクトへの署名
ステージ： アルファ
フィーチャーグループ：リリース
フィーチャーゲート: N/A

サプライチェーン攻撃の回避を支援するために、エンドユーザーはKubernetesバイナリのようなダウンロードしたリソースの完全性を検証できるようにする必要があります。

この機能拡張は、アーティファクトに署名するための統一された方法を導入します。これは、sigstoreプロジェクトのツールに依存し、より具体的にはcosignに依存します。新しい機能は追加されませんが、私たちのクラスターをより保護するのに役立つことは間違いないでしょう。

さらに、署名キーやそのインフラへの不正アクセスなどのリスクを避けるために、他の対策も実施することをお勧めします。例えば、キーレス署名を用いて鍵の使用状況を公開監査などです。

#2578 A Windows-[operational readiness] の定義とツールの収束
ステージ ：アルファ
機能グループ：windows
フィーチャーゲート: N/A

Kubernetes 1.14以降、Windowsのコンテナオーケストレーションはエンタープライズでの採用が可能になりました。しかし、WindowsのConformanceテストは、Linuxほど信頼できるものではありません。

このため、Windows Kubernetesクラスターの運用レディネスを評価するために、以下の領域をカバーする特定のテストを開発する予定です：

• 基本的なネットワーキング
• サービスアカウントとローカルストレージの基本
• 基本的なスケジューリング
• 基本的な並列処理機能
• Windows HostProcess オペレーショナルレディネス
• Active Directory
• ネットワークポリシー
• Windowsアドバンストネットワーキングとサービスプロキシー
• Windows Workerの設定

このような行動のためのツールを提供することになります：

• Kubernetesで頼りにしている機能が、特定のWindows Kubernetesクラスタでサポートされているかどうかを確認する。
• Windowsクラスター用のKubernetesサポートマトリックスの完全性を評価する。
• 現在のバージョンのKubernetesが特定のWindows機能をサポートしているかどうかを知ること。

Windows環境におけるKubernetesの安定したエコシステムを構築するための努力は、Windowsに特化したアプリケーションを持つすべての組織にとって新しい機会を生み出しているのです。コンテナはもうLinux専用ではないのです。

この広範なトピックについては、KEPで詳細をご覧ください。

#2802 WindowsポッドをAPIアドミッションレベルで権威的に識別する
ステージ： ベータへの移行
機能グループ：windows
フィーチャーゲート: IdentifyPodOS Default value: true

この機能拡張により、PodSpecにOSフィールドが追加され、ポッドが実行されるべきオペレーティングシステムを定義できるようになりました。これにより、Kubernetesはポッドを管理するためのより良いコンテキストを持つことができます。

詳しくは「Kubernetes 1.23における新機能は?」の記事をご覧ください。

---

以上、Kubernetes 1.24についてでした。これらの機能のいずれかを使用する予定がある場合は、クラスターのアップグレードの準備をしてください。

もしこれが気に入ったのであれば、以前の「Kubernetesの新機能」編もチェックしてみてください：

• Kubernetes 1.23の新機能
  Kubernetes 1.22の新機能
• Kubernetes 1.21の新機能
• Kubernetes 1.20の新機能
• Kubernetes 1.19の新機能
• Kubernetes 1.18の新機能
• Kubernetes 1.17の新機能
• Kubernetes 1.16の新機能
• Kubernetes 1.15の新機能
• Kubernetes 1.14の新機能
• Kubernetes 1.13の新機能
• Kubernetes 1.12の新機能

• プロジェクトのホームページをご覧ください。
• GitHubでKubernetesプロジェクトをチェックする。
• Kubernetesコミュニティに参加しましょう。
• Kubernetes Slackでメンテナに会いましょう。
• Twitterで@KubernetesIOをフォローする。

また、Kubernetesエコシステムの最新情報を楽しみたい方は、クラウドネイティブエコシステムで起こっている最もクールなものを毎月お届けするコンテナニュースレターを購読してください。