Kubernetes 1.26における新機能は?

By 清水 孝郎 - DECEMBER 4, 2022
Topics: コンテナ、Kubernetes、ホストのセキュリティ

SHARE:

本文の内容は、2022年11月30日に DEVID DOKASHが投稿したブログ（https://sysdig.com/blog/kubernetes-1-26-whats-new/)を元に日本語に翻訳・再構成した内容となっております。

Kubernetes 1.26がリリースされようとしています。どこから始めましょうか？

今回のリリースでは、Kubernetes 1.25の40、Kubernetes 1.24の46と同レベルの37の機能強化が行われました。この37の機能強化のうち、11がStableへの移行、10が既存の機能で改善を続けているもの、16が全く新しいもの、そして1が非推奨の機能となっています。

このバージョンでは、すべての非推奨と削除に注目してください！

今回のリリースでは、ユーザーのKubernetesとの関わり方を変える可能性を秘めた、2つの新機能が目立ちます。他のネームスペースからのスナップショットでボリュームをプロビジョニングできるようになりました。

また、科学研究や機械学習のようなハイパフォーマンスワークロードを対象とした新機能もあります。ワークロードがどの物理CPUコアで実行されるかをより明確にします。

また、OpenAPIv3のサポートなど、クラスター管理者の生活をより快適にする機能もあります。

私たちは、このリリースにとても興奮しています！

話すことがたくさんあるので、Kubernetes 1.26で何が新しくなったのか、さっそく見ていきましょう。

Kubernetes 1.26 – エディターのおすすめ：

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

#3294 クロスネームスペーススナップショットからボリュームをプロビジョニングする
VolumeSnapshot機能は、Kubernetesユーザーがボリュームスナップショットからボリュームをプロビジョニングすることを可能にし、データベース管理者が重要な操作の前にデータベースをスナップショットしたり、バックアップソリューションを開発および実装する能力を可能にするなど、ユーザーやアプリケーションに大きな利点を提供します。

Kubernetes 1.26からAlpha機能として、ユーザーはVolumeSnapshotからネームスペースを越えてPersistentVolumeClaimを作成できるようになり、両方のオブジェクトが同じネームスペースにあるという最初の制約が解消されます。

この機能強化により、アプリケーションとサービスが異なるネームスペースにある場合、ユーザーやアプリケーションがデータベースのチェックポイントを保存するような基本的なタスクを実行できないような制約が解消されます。

Víctor Hernando – Sr. Technical Marketing Manager at Sysdig

#3488 CELによるアドミッションコントロール
ついに、Kubernetes 1.25の検証式言語の実用的な実装が登場しました!

アドミッションコントローラーのルールをKubernetesオブジェクトとして定義することで、Webhookの管理を忘れて、クラスターのセットアップを簡素化することができるのです。それだけでなく、Kubernetesのセキュリティの実装も少し簡単になりました。

私たちは、このようなユーザーフレンドリーな改良を見るのが大好きです。これらは、Kubernetesの採用を拡大し続けるための鍵なのです。

Víctor Jiménez Cerrada – Content Engineering Manager at Sysdig

#3466 KubernetesコンポーネントのヘルスSLI
Kubernetes 1.26以降、Kubernetesコンポーネントバイナリに対してService Level Indicator（SLI）メトリクスを設定することができるようになりました。これを有効にすると、KubernetesはSLIメトリクスを/metrics/slisエンドポイントで公開するので、Prometheusエクスポーターが不要になります。これにより、Kubernetesの監視を別のレベルに引き上げることができ、ヘルスダッシュボードの作成や、クラスターの安定性を保証するためのPromQLアラートの設定が容易になります。

Jesús Ángel Samitier – Integrations Engineer at Sysdig

#2371 cAdvisor-less、CRI-full コンテナと Pod の統計情報
現在、消費されたCPUやメモリなどのメトリクスをコンテナから収集するために、KubernetesはcAdvisorに依存しています。この機能は、コンテナからすべてのメトリクスを提供するためにCRI APIをリッチ化し、より柔軟でより良い精度を可能にする代替案を提示します。結局のところ、コンテナの挙動を最もよく知っているのはコンテナランタイムなのです。

この機能は、KubernetesのコードからcAdvisorを取り除くためのロードマップのもう1つのステップを意味します。しかし、この移行期間中、cAdvisorはCRI APIに追加されたメトリクスを生成しないように修正され、異なる支離滅裂な値を持つ可能性のある重複したメトリクスを回避することができるようになります。

David de Torres Huerta – Engineer Manager at Sysdig

#3063 ダイナミックなリソース割り当て
この新しいKubernetesのリリースは、高度なハードウェアのための拡張リソース管理を提供する新しいAlpha機能を導入しています。さらに、リソースリクエストを記述するためのユーザーフレンドリーなAPIが付属しています。GPUやFPGAのような異なるハードウェアコンポーネントを処理する需要が高まり、初期化やクリーンアップを設定する必要がある中、この新機能は科学研究やエッジコンピューティングなどの分野でのKubernetes採用を加速させるでしょう。

Javier Martínez – Devops Content Engineer at Sysdig


#3545 Topology Managerにおけるmulti-numaアライメントの改善
これは、科学的コンピューティングに関わるような高性能ワークロードを対象とした、もう一つの機能です。Kubernetes 1.22と1.23から新しいCPUマネージャーが形になってきており、開発者がワークロードをデータがメモリに保存されている場所の近くに保つことができ、パフォーマンスを向上させることができるようになっています。Kubernetes 1.26では、さらに一歩進んで、この機能のさらなるカスタマイズへの扉を開いています。結局のところ、すべてのワークロードとCPUアーキテクチャが同じというわけではないのです。

Kubernetes上でのHPCの未来は、実に有望と言えるでしょう。

Vicente J. Jiménez Miras – Security Content Engineer at Sysdig

#3335 StatefulSetでレプリカの開始序数を制御できるようにする
KubernetesのStatefulSetは、クラスター化されたデータベースやメッセージキューのような、重要なバックエンドサービスであることがよくあります。
この機能強化は、一見すると些細な番号の変更ですが、より柔軟性を高め、ダウンタイムなしでStatefulSetのレプリカのロールクロスネームスペース、あるいはクロスクラスター移行を行うための新しい手法を可能にするものです。このプロセスは、PodDisruptionBudgetの慎重な定義と、移行するレプリカに対するリソースの移動を伴い、少し不便に思えるかもしれませんが、現在可能なコールドマイグレーション戦略（シャットダウン-バックアップ-リストア）とは全く対照的に、これらの操作を自動化するツール（または既存のオペレータの拡張）を想定して、シームレスに移行することができることは間違いないでしょう。

Daniel Simionato – Security Content Engineer at Sysdig

#3325 Auth APIによるセルフユーザー属性の取得
アルファ版で登場するこの新機能は、クラスター管理者の仕事、特に複数のクラスターを管理している場合の作業を簡素化します。また、複雑な認証フローを支援し、ユーザーがクラスター内のユーザー情報や権限をクエリーできるようになります。

また、プロキシを使用しているか（すべての認証メカニズムが適用された後にKubernetes APIサーバーがuserInfoを埋める）、なりすましを行っているか（なりすましを行っているユーザーの詳細とプロパティを受け取る）にも対応しており、非常に簡単にユーザー情報を入手することができるようになります。

Miguel Hernández – Security Content Engineer at Sysdig

#3352 Aggregated Discovery
これはユーザーにとっては小さな変更ですが、Kubernetesの内部をきれいにしてパフォーマンスを向上させる上で一歩前進したものです。APIコールを集約することでその数を減らす（少なくともディスカバリーの部分については）ことは、大きくなりつつある問題に対する素晴らしい解決策です。うまくいけば、これがクラスター管理者に小さな休憩を提供することになります。

Devid Dokash – Content Engineering Intern at Sysdig

非推奨事項

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

非推奨のAPIバージョンは、もはや提供されないので、より新しいものを使用する必要があります。
  • CRI v1alpha2、v1を使用してください（containerdバージョン1.5以前はサポートされていません）。
  • flowcontrol.apiserver.k8s.io/v1beta1, v1beta2 を使ってください。
  • autoscaling/v2beta2, v2 を使ってください。

非推奨：次のリリースが出る前に代替を実装してください：
  • インツリーのGlusterFSドライバー。
  • kubectl –prune-whitelist, 代わりに –prune-allowlist を使ってください。
  • kube-apiserver –master-service-namespace.
  • kubectl runのいくつかの未使用オプション：–cascade, –filename, –force, –grace-period, –kustomize, –recursive, –timeout, –wait.
  • CLIフラグのpod-eviction-timeout。
  • apiserver_request_slo_duration_seconds メトリクスでは、apiserver_request_sli_duration_seconds を使用します。
削除：アップグレードの前に代替手段を実装してください：
  • Azure と Google Cloud のレガシー認証は非推奨です。
  • ユーザースペースのプロキシモード。
  • 動的な kubelet 設定。
  • ロギングに関連するいくつかのコマンドライン引数。
  • in-tree OpenStack (cinder volume type)では、CSIドライバーを使用します。
Configを適応させる必要があるその他の変更:
  • Pod Security admission: pod-security warn レベルは、enforce レベルにデフォルトで設定されるようになりました。
  • kubelet：cpuCFSQuotaPeriod フラグを有効にした場合のデフォルトの cpuCFSQuotaPeriod 値は、100ms ではなく 100µs に変更されました。
  • kubelet： –container-runtime-endpoint フラグは、もう空にはできません。
  • kube-apiserver:：gzip 圧縮がレベル 4 からレベル 1 に変更されました。
  • メトリクス：preemption_victims を LinearBuckets から ExponentialBuckets に変更しました。
  • メトリクス： etcd_db_total_size_in_bytes は apiserver_storage_db_total_size_in_bytes にリネームされました。
  • メトリクス： kubelet_kubelet_credential_provider_plugin_duration は kubelet_credential_provider_plugin_duration にリネームされました。
  • メトリクス： kubelet_kubelet_credential_provider_plugin_errors は kubelet_credential_provider_plugin_errors に名称が変更されました。
  • 様々なコンテナイメージから Windows Server, Version 20H2 のフレーバーを削除しました。
  • e2e.test バイナリは、進捗状況を記録するための JSON 構造体を生成しなくなりました。
Kubernetes 1.26のリリースノートで変更点の全リストを確認できます。また、Kubernetes Removals and Deprecations In 1.26 の記事、および非推奨のAPI移行ガイドを今後のために近くに置いておくことをお勧めします。

#281 動的なKubeletの設定

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


この機能は1.21で非推奨とされ、その後1.24でKubeletから削除されました。そして今回1.26で、Kubernetesから完全に削除されました。

Kubernetes 1.26 API

#3352 Aggregated discovery

Stage: Net new to Alpha
Feature group: api-machinery
Feature gate: AggregatedDiscoveryEndpoint Default value: false

kubectlのようなKubernetesクライアントは、kubernetes-apiserverでどのAPIとそのバージョンが利用可能かを把握する必要があります。そのためには、各APIとバージョンごとにリクエストを行う必要があり、リクエストの嵐を引き起こします。

今回の機能強化は、これらの呼び出しをすべて2つに減らすことを目的としています。

クライアントは、/apiと/apisエンドポイントへのリクエストのAcceptフィールドに、as=APIGroupDiscoveryListを含めることができます。そうすると，サーバーは利用可能なすべてのAPIとそのバージョンを集約したドキュメント(APIGroupDiscoveryList)を返します．

#3488 アドミッションコントロールのためのCEL

Stage: Net new to Alpha
Feature group: api-machinery
Feature gate: ValidatingAdmissionPolicy Default value: false

Kubernetes 1.25の#2876 CRD validation expression languageをベースに、この機能拡張では新しいアドミッションコントローラータイプ（ValidatingAdmissionPolicy）を提供し、Webhooksに依存せずにいくつかの検証を実装できるようにしました。

これらの新しいポリシーは、次のように定義することができます：
apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"
Spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: ["apps"]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
    resources: ["deployments"]
  validations:
    - expression: "object.spec.replicas <= 5"

このポリシーは、レプリカが5個以下の一部のデプロイに対するリクエストを拒否します。

この機能の全容はdocsでご確認ください。

#1965 kube-apiserver identity

Stage: Graduating to Beta
Feature group: api-machinery
Feature gate: APIServerIdentity Default value: true

高可用性クラスターにおいて、どのkube-apiserversが生きているかをよりよく制御するために、新しいlease / heartbeatシステムが実装されました。

詳しくは、“What’s new in Kubernetes 1.20” 記事をご覧ください。

Kubernetes 1.26 アプリケーション

#3017 PodHealthyPolicy for PodDisruptionBudget

Stage: Net new to Alpha
Feature group: apps
Feature gate: PDBUnhealthyPodEvictionPolicy Default value: false

PodDisruptionBudgetを使うと、クラスター管理者に「これ以上壊すな」とか「これのうち最低2つは生かせ」というように、メンテナンス作業をしやすくするための最低ラインを伝えることができます。

ただし、これはPodが動作しているかどうかだけを考慮したものであり、健常であるかどうかは考慮されていません。PodがRunningであってもReadyでなく、PodDisruptionBudgetがそのevictionを防いでいる場合があります。

今回の機能拡張では、これらのバジェット定義にstatus.currentHealthy, status.desiredHealthy, spec.unhealthyPodEvictionPolicy という追加フィールドを追加して、不健全なPodの管理方法を定義できるようにしました。
$ kubectl get poddisruptionbudgets example-pod
apiVersion: policy/v1
kind: PodDisruptionBudget
[...]
status:
  currentHealthy: 3
  desiredHealthy: 2
  disruptionsAllowed: 1
  expectedPods: 3
  observedGeneration: 1
  unhealthyPodEvictionPolicy: IfHealthyBudget

#3335 StatefulSet がレプリカの開始番号を制御できるようにした

Stage: Net new to Alpha
Feature group: apps
Feature gate: StatefulSetStartOrdinal Default value: false

KubernetesのStatefulSetは現在、序数を使用してPodに番号を付けており、最初のレプリカは0、最後のレプリカはspec.replicasとなっています。

今回の機能強化では、StatefulSetマニフェストspecにspec.ordinals.startという1つのフィールドを持つ新しい構造体を追加し、StatefulSetが制御するレプリカの開始番号を定義できるようにしました。

これは、StatefulSetのクロスネームスペースまたはクロスクラスター移行において、PodDistruptionBudget（およびマルチクラスタサービス）を巧みに利用して、StatefulSetのダウンタイムを回避しながらレプリカのローリング移行を制御できるようにする場合などに有用です。

#3329 ジョブにおけるPodフェイルのRetriableとnon-retriable

Stage: Graduating to Beta
Feature group: apps
Feature gate: JobPodFailurePolicy Default value: true
Feature gate: PodDisruptionsCondition Default value: true

この機能拡張により、ジョブが失敗した場合に再試行されるべきかどうかを決定する、ジョブのスペックにおける .spec.podFailurePolicy を設定することができるようになりました。こうすることで、Kubernetesはインフラストラクチャー障害やアプリケーションエラーの際にバックオフ時間の増加を回避し、早期にジョブを終了させることができるようになります。

詳しくは“What’s new in Kubernetes 1.25” の記事でご覧ください。

#2307 ポッドを長引かせずにジョブを追跡する

Stage: Graduating to Stable
Feature group: apps
Feature gate: JobTrackingWithFinalizers Default value: true

この機能強化により、ジョブが完了したPodを早期に削除できるようになり、クラスターのリソースが解放されます。

詳しくは、“Kubernetes 1.22 – What’s new?”の記事をご覧ください。


Kubernetes 1.26 Auth

#3325 Auth API による自己ユーザー属性の取得

Stage: Net new to Alpha
Feature group: auth
Feature gate: APISelfSubjectAttributesReview Default value: false

この新機能は、Kubernetesクラスターで複雑な認証フローを使用しており、すべての認証メカニズムが適用された後に、すべてのuserInfoを知りたい場合に非常に便利です。

kubectl alpha auth whoamiを実行すると、以下のような出力が得られます：
apiVersion: authentication.k8s.io/v1alpha1
kind: SelfSubjectReview
status:
  userInfo:
    username: jane.doe
    uid: b79dbf30-0c6a-11ed-861d-0242ac120002
    groups:
    - students
    - teachers
    - system:authenticated
    extra:
      skills:
      - reading
      - learning
      subjects:
      - math
      - sports


まとめると、クラスター内で認証されると、典型的な /me to know 自分のパーミッションができるようになったということです。

#2799 シークレットベースのサービスアカウントトークンの削減

Stage: Graduating to Beta
Feature group: auth
Feature gate: LegacyServiceAccountTokenNoAutoGeneration Default value: true

API認証情報はTokenRequest APIを通じて取得されるようになり、Kubernetes 1.22以降stableで、projectedボリュームを使用してPodにマウントされるようになりました。関連するPodが削除されると自動的に無効化されます。

詳しくは、“Kubernetes 1.24 – What’s new?”の記事をご覧ください。

Kubernetes 1.26 ネットワーク

#3453 iptables-restore の入力サイズを最小にする

Stage: Net new to Alpha
Feature group: network
Feature gate: MinimizeIPTablesRestore Default value: false

この機能拡張は、kube-proxyのパフォーマンスを向上させることを目的としています。ルールセット全体ではなく、iptables-restoreの呼び出しで変更されたルールのみを送信することでこれを実現します。

#1669 プロキシー終端ポイント

Stage: Graduating to Beta
Feature group: network
Feature gate: ProxyTerminatingEndpoints Default value: true

この機能拡張は、すべての外部トラフィックを準備完了と未完了の両方の終端エンドポイントに送信する（準備完了のものを優先する）ことにより、ローリングアップデート中のトラフィック低下を防止します。

詳しくは“Kubernetes 1.22 – What’s new?” の記事をご覧ください。

#2595 DNS設定の機能拡張

Stage: Graduating to Beta
Feature group: network
Feature gate: ExpandedDNSConfig Default value: true

この機能拡張により、Kubernetesは最近のDNSリゾルバに対応するため、検索パスで最大32のDNSを許可し、検索パスの文字数も増加（最大2048文字）しています。

詳しくは、“Kubernetes 1.22 – What’s new?”の記事をご覧ください。

#1435 type=LoadBalancer のサービスにおける混合プロトコルのサポート

Stage: Graduating to Stable
Feature group: network
Feature gate: MixedProtocolLBService Default value: true

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

詳しくは “Kubernetes 1.20 – What’s new?” の記事をご覧ください。

#2086 サービスインターナルトラフィックポリシー

Stage: Graduating to Stable
Feature group: network
Feature gate: ServiceInternalTrafficPolicy Default value: true

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

  • Clusterに設定すると、ルーティングは通常通り動作します。
  • Topologyに設定すると、トポロジーを考慮したルーティングが使用されます。
  • PreferLocalに設定すると、同じノードにあるサービスにトラフィックをリダイレクトします。
  • Localに設定すると、同じノードにあるサービスにのみトラフィックを送信します。
詳しくは“Kubernetes 1.21 – What’s new?”をご覧ください。

#3070 ダイナミックおよびスタティックIP割り当てのためのサービスIPレンジの予約

Stage: Graduating to Stable
Feature group: network
Feature gate: ServiceIPStaticSubrange Default value: true

この –service-cluster-ip-range フラグの更新により、静的および動的な IP 割り当てを使用するサービス間で IP の競合が発生するリスクが低下し、同時に互換性が後方へ維持されます。

詳しくは、“What’s new in Kubernetes 1.24”記事をご覧ください。



Kubernetes 1.26 Nodes

#2371 cAdvisor-less、CRI-fullコンテナとPodの統計情報

Stage: Major change to Alpha
Feature group: node
Feature gate: PodAndContainerStatsFromCRI Default value: false

この機能拡張は、Container Runtime Interface (CRI)から実行中のコンテナとPodに関するすべての統計情報を取得し、cAdvisorからの依存を取り除くための取り組みをまとめたものです。

1.26から、/metrics/cadvisor上のメトリクスは、cAdvisorの代わりにCRIによって収集されるようになりました。

詳しくは“Kubernetes 1.23 – What’s new?”の記事をご覧ください。

#3063 動的なリソース割り当て

Stage: Net new to Alpha
Feature group: node
Feature gate: DynamicResourceAllocation Default value: false

従来、Kubernetesのスケジューラーは、CPUとメモリのリミットとリクエストしか考慮できませんでした。その後、スケジューラはストレージやその他のリソースも考慮するように拡張されました。しかし、これでは多くのシナリオで限界があります。

例えば、FPGAのようにデバイスの初期化やクリーンアップが必要な場合、あるいは共有GPUのようにリソースへのアクセスを制限したい場合はどうでしょうか。

この新しいAPIは、新しいResourceClaimTemplateとResourceClassオブジェクト、そしてPod内の新しいresourceClaimsフィールドを使って、リソースの割り当てと動的検出のこれらのシナリオをカバーしています。

apiVersion: v1
kind: Pod
[...]
 spec:
  resourceClaims:
  - name: resource0
    source:
      resourceClaimTemplateName: resource-claim-template
  - name: resource1
    source:
      resourceClaimTemplateName: resource-claim-template
[...]

スケジューラはこれらのリソースクレームを追跡し、十分なリソースが利用可能なノードにのみPodをスケジュールすることができます。

#3386 Kubelet のイベント化された PLEG でパフォーマンス向上

Stage: Net new to Alpha
Feature group: node
Feature gate: EventedPLEG Default value: false

この機能拡張の目的は、すべてのPodの状態を追跡する際のkubeletのCPU使用率を減らすことです。

これにより、kubeletが実行する定期的なポーリングが部分的に削減され、代わりにContainer Runtime Interface (CRI) からの通知に可能な限り依存するようになります。

実装の詳細に興味がある場合は、KEP を見てみるとよいでしょう。

#3545 トポロジーマネージャーにおける複数 NUMA のアライメントの改善

Stage: Net new to Alpha
Feature group: node
Feature gate: TopologyManagerPolicyOptions Default value: false
Feature gate: TopologyManagerPolicyBetaOptions Default value: false
Feature gate: TopologyManagerPolicyAlphaOptions Default value: false

これは、TopologyManager が Non-Uniform Memory Access (NUMA) ノードをより良く処理するための改良です。一部の高性能なワークロードでは、どの物理 CPU コアで実行するかを制御することが非常に重要です。同じチップのキャッシュ間やソケット間のメモリジャンピングを避けることができれば、パフォーマンスを大幅に向上させることができます。

kubeletの新しいtopology-manager-policy-optionsフラグにより、オプションを渡してトポロジーマネージャーの挙動を変更することができます。

現在のところ、1つのアルファオプションのみが利用可能です。

  • prefer-closest-numa-nodes=true が渡されると、トポロジーマネージャーは、単一の NUMA ノードまたは可能な最小数の NUMA ノードのいずれかでリソースを整列させます。
将来的に新しいオプションが追加される可能性があるため、いくつかの機能ゲートが追加されており、安定したものだけに焦点を当てるように選択することができます。
  • TopologyManagerPolicyOptions：TopologyManager-policy-optionsフラグと安定したオプションを有効にします。
  • TopologyManagerPolicyBetaOptions：ベータ版オプションも有効にします。
  • TopologyManagerPolicyAlphaOptions： アルファ オプションを有効にします。Alpha オプションも有効にします。
関連項目： #2902 CPUManager ポリシーオプションで、Kubernetes 1.23 の NUMA ノードに CPU を分散させることができます。
関連項目 ：#2625 Kubernetes 1.22 の新しい CPU Manager ポリシー。

#2133 Kubeletクレデンシャルプロバイダー

Stage: Graduating to Stable
Feature group: node
Feature gate: KubeletCredentialProviders Default value: true

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

詳しくは“Kubernetes 1.20 – What’s new?”　をご覧ください。

#3570 CPUManager が GA へグラデュエート

Stage: Graduating to Stable
Feature group: node
Feature gate: CPUManager Default value: true
CPUManagerは、ローカルノード上のCPUのセットにPodコンテナを割り当てることを担当するKubeletコンポーネントです。

Kubernetes 1.8で導入され、リリース1.10でベータ版に移行しました。1.26では、コアのCPUManagerが安定したと見なされ、そのポリシーに関する追加作業で実験が続けられています。

関連項目： #3545 Kubernetes 1.26 の Topology Manager で multi-numa のアライメントが改善されました
関連項目：#2625 Kubernetes 1.22 の 新しい CPU Manager ポリシー

#3573 DeviceManagerがGAへグラデュエート

Stage: Graduating to Stable
Feature group: node
Feature gate: DevicePlugins Default value: true

KubeletのDeviceManagerは、異なるDevice Pluginとのインタラクションを管理するコンポーネントです。

Kubernetes 1.8で導入され、リリース1.10でベータ版に移り、Device Pluginフレームワークは広く採用され、1.26でついにGAに移行します。

このフレームワークにより、Kubernetesのコアコンポーネントを変更することなく、外部デバイス（NVIDIA GPU、AMD GPUS、SR-IOV NICなど）を使用することができます。

Kubernetes 1.26 スケジューリング

#3521 ポッドスケジューリング準備状況

Stage: Net new to Alpha
Feature group: scheduling
Feature gate: PodSchedulingReadiness Default value: false

この機能拡張は、Podに、それらが本当にスケジュールされる準備ができたときを定義させることによって、スケジューリングを最適化することを目的としています。

すべてのペンディングPodがスケジュールする準備ができているわけではありません。一部のPodはmiss-essential-resourcesの状態がしばらく続き、スケジューラーに余分な作業をさせることになります。

Podの新しい.spec.schedulingGatesは、Podがいつスケジューリングの準備ができたかを識別することを可能にします：

apiVersion: v1
kind: Pod
[...]
 spec:
  schedulingGates:
  - name: foo
  - name: bar
[...]

何らかのスケジューリングゲートが存在する場合、Podはスケジューリングされません。

以下のように状態を確認することができます：

$ kubectl get pod test-pod
NAME      READY   STATUS           RESTARTS   AGE
test-pod  0/1     SchedulingGated  0          7s

#3094 PodTopologySpread のスキューを計算するときにテイント/トレランスを考慮する

Stage: Graduating to Beta
Feature group: scheduling
Feature gate: NodeInclusionPolicyInPodTopologySpread Default value: true

“Kubernetes 1.16 – What’s new?” の記事で説明したように、topologySpreadConstraints フィールドは maxSkew と共に、ノード間でワークロードを分散させることを可能にします。新しいNodeInclusionPoliciesフィールドは、このPodトポロジースプレッドスキューを計算する際に、NodeAffinityとNodeTaintを考慮することを可能にします。

詳しくは、“What’s new in Kubernetes 1.25” の記事でご覧ください。

Kubernetes 1.26 ストレージ

#3294 クロスネームスペーススナップショットからのプロビジョニングボリューム

Stage: Net new to Alpha
Feature group: storage
Feature gate: CrossNamespaceVolumeDataSource Default value: false

Kubernetes 1.26以前は、VolumeSnapshot機能により、スナップショットからボリュームをプロビジョニングすることができました。これは非常に便利な機能ですが、PersistentVolumeClaimを他のネームスペースからのVolumeSnapshotsにバインドできないなど、いくつかの制限がありました。

今回の機能強化ではこの制限を解消し、Kubernetesユーザーがネームスペースをまたいでスナップショットからボリュームをプロビジョニングできるようになりました。

ネームスペースをまたぐVolumeSnapshot機能を使用する場合、まずReferenceGrantオブジェクトを作成し、次にVolumeSnapshotへのPersistentVolumeClaimバインディングを作成する必要があります。ここでは、学習用に両方のオブジェクトの簡単な例を紹介します。

---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: ReferenceGrant
metadata:
  name: test
  namespace: default
spec:
  from:
  - group: ""
    kind: PersistentVolumeClaim
    namespace: nstest1
  to:
  - group: snapshot.storage.k8s.io
    kind: VolumeSnapshot
    name: testsnapshot
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: testvolumeclaim
  namespace: nstest1
spec:
  storageClassName: mystorageclass
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
  dataSourceRef2:
    apiGroup: snapshot.storage.k8s.io
      kind: VolumeSnapshot
      name: testsnapshot
      namespace: default
  volumeMode: Filesystem

#2268 ノングレースフルノードシャットダウン

Stage: Graduating to Beta
Feature group: storage
Feature gate: NodeOutOfServiceVolumeDetach Default value: true

この機能拡張により、ノードのシャットダウンが正しく検出されず、StatefulSetの一部であるPodがシャットダウンノード上で終了状態から抜け出せず、新しい実行中のノードに移り変わることができないケースが修正されました。

この場合、Podは強制的に削除され、VolumeAttachmentsの削除がトリガーされ、別の実行ノードに新しいPodが作成され、アプリケーションが引き続き機能するようになります。

詳しくは、“Kubernetes 1.24 – What’s new?”　をご覧ください。

#3333 デフォルトのStorageClassの割り当てを遡及的に変更する

Stage: Graduating to Beta
Feature group: storage
Feature gate: RetroactiveDefaultStorageClass Default value: false

この機能拡張は、クラスター管理者がデフォルトのストレージクラスを変更した場合の管理を支援します。変更中に作成されたStorageClassを持たないすべてのPVCは、新しいデフォルトのStorageClassに遡及して設定されます。

詳しくは、“What’s new in Kubernetes 1.25”の記事でご確認ください。

#1491 vSphere インツリーから CSI ドライバーへの移行

Stage: Graduating to Stable
Feature group: storage
Feature gate: CSIMigrationvSphere Default value: false

“What’s new in Kubernetes 1.19”の記事で取り上げたように、vSphere用のCSIドライバーは以前からstableになっています。現在、vspherevolume に対するすべてのプラグイン操作は、アウトオブツリーの ‘csi.vsphere.vmware.com’ ドライバーにリダイレクトされるようになりました。

この機能強化は、#625 In-tree storage plugin to CSI Driver Migration の取り組みの一部です。

#1885 Azure ファイルのインツリーから CSI ドライバーへの移行

Stage: Graduating to Stable
Feature group: storage
Feature gate: InTreePluginAzureDiskUnregister Default value: true

この機能強化は、Azure FileのコードをメインのKubernetesバイナリから（out-of-tree）移すための作業についてまとめたものです。

詳しくは、 “Kubernetes 1.21 – What’s new?”をご覧ください。

#2317 Kubernetesがマウント時にPodのfsgroupをCSIドライバーに供給できるようにする

Stage: Graduating to Stable
Feature group: storage
Feature gate: DelegateFSGroupToCSIDriver Default value: false

この機能拡張は、CSIドライバーに明示的なフィールドとしてPodのfsgroupを提供し、CSIドライバーがマウント時にこれをネイティブで適用できるようにすることを提案しています。

詳しくは、“Kubernetes 1.22 – What’s new?”の記事をご覧ください。

Kubernetes 1.26 その他の強化点

#3466 KubernetesコンポーネントのヘルスSLI

Stage: Net new to Alpha
Feature group: instrumentation
Feature gate: ComponentSLIs Default value: false

Kubernetesコンポーネントのヘルスデータをクエリーするための標準的なフォーマットは存在しません。

Kubernetes 1.26から、各コンポーネントで新しいエンドポイント/metrics/slisが利用可能になり、Prometheus形式でサービスレベルインジケータ（SLI）メトリクスが公開されます。

各コンポーネントについて、2つのメトリクスが公開されます。
  • ゲージ：ヘルスチェックの現在の状態を表します。
  • カウンター：各ヘルスチェックの状態について観測された累積カウントを記録します。
この情報を使って、Kubernetes内部のovertimeステータスを確認することができます：

kubernetes_healthcheck{name="etcd",type="readyz"}

そして、何かあったときのためのアラートを作成する、例えば：

kubernetes_healthchecks_total{name="etcd",status="error",type="readyz"} > 0

#3498 メトリクスの安定性を高める

Stage: Net new to Alpha
Feature group: instrumentation
Feature gate: N/A

Kubernetesのメトリクスは、alphaとstableに分類されます。stableはメンテナンスが保証されており、クラスターをアップグレードしたときに予期せず壊れてしまわないようにダッシュボードを準備するための情報を提供します。

Kubernetes 1.26では、新たに2つのクラスが追加されています：

  • beta：ベータ機能に関連するメトリクス用。変更されたり消えたりする可能性がありますが、アルファ版のものよりも高度な開発状態にあります。
  • interna：クラスター管理者にとって有益な情報を提供しないか、予告なく変更される可能性があるため、気にする必要はない内部使用のメトリクスです。
利用可能なメトリクスの全リストは、ドキュメントで確認できます。

関連項目 #1209 Kubernetes 1.21でのメトリクスの安定性強化

#3515 OpenAPI v3 for kubect explain

Stage: Net new to Alpha
Feature group: cli
Environment variable: KUBECTL_EXPLAIN_OPENAPIV3 Default value: false

この機能拡張により、kubectlのexplainがv2ではなくOpenAPIv3からデータを収集することができるようになりました。

OpenAPIv3では、CustomResourceDefinitions (CDR) のような、より良い方法でデータを表現することができます。

また、kubectl explainの出力方法を改善するための内部作業も行われています。

関連項目: #2896 OpenAPI v3 in Kubernetes 1.24.

#1440 kubectl events

Stage: Graduating to Beta
Feature group: cli
Feature gate: N/A

新しい kubectl events コマンドが利用可能になり、現在の kubectl get events の機能が強化されます。

詳細は“Kubernetes 1.23 – What’s new?” をご覧ください。

#3031 リリースアーティファクトへの署名

Stage: Graduating to Beta
Feature group: release
Feature gate: N/A

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

詳しくは“Kubernetes 1.24 – What’s new?”の記事をご覧ください。

#3503 Windowsポッドのホストネットワークのサポート

Stage: Net new to Alpha
Feature group: windows
Feature gate: WindowsHostNetwork Default value: false

WindowsのPodには、hostNetwork=trueを設定しても何も変わらないという奇妙な状況があります。プラットフォーム的に支障があるわけではなく、実装が抜けていただけです。

Kubernetes 1.26から、KubeletはWindowsポッドに対して、新しいポッドネットワークネームスペースを作成する代わりに、ホストのネットワークネームスペースを使用するよう要求できるようになりました。

これは、大量のサービスがある場合に、ポートの枯渇を避けるために便利です。

#1981 Windows 特権コンテナへの対応

Stage: Graduating to Stable
Feature group: windows
Feature gate: WindowsHostProcessContainers Default value: true

この機能拡張により、Linuxで利用可能な特権コンテナ機能がWindowsホストにも提供されます。

特権コンテナは、あたかもホスト上で直接実行しているかのように、ホストにアクセスすることができます。ほとんどのワークロードでは推奨されませんが、管理、セキュリティ、および監視の目的では非常に便利です。

詳しくは、“Kubernetes 1.22 – What’s new?”の記事をご覧ください。

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

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


Kubernetesのコミュニティに参加してみませんか？


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