Kubernetes 1.27における新機能は?

By 清水 孝郎 - APRIL 13, 2023
Topics: オープンソース

SHARE:

Kubernetes 1.27における新機能は?

本文の内容は、2023年4月4日に VÍCTOR JIMÉNEZ CERRADA が投稿したブログ（https://sysdig.com/blog/kubernetes-1-27-whats-new）を元に日本語に翻訳・再構成した内容となっております。

Kubernetes 1.27がリリースされようとしていますが、目新しいものが満載です！何から始めましょうか？

今回のリリースでは、Kubernetes 1.26の37、Kubernetes 1.25の40から大幅に増えて、60の機能強化が行われました。この60の機能強化のうち、12はStableへの移行、29は改善を続ける既存機能、18は完全に新しい機能、そして1つは非推奨の機能となっています。

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

このリリースの主なハイライトは、実際はKubernetesの外側にあります。イメージレジストリは、データセンターに近い分散型システムに移り、どのクラウドプロバイダーを使っていても、「関係なく」利用できるようになりました。

また、セキュリティのハイライトもいくつかあります。kubeletのデフォルトでのSeccompが安定し、新しいアカウントトークンやアドミッションコントロールの新しいルールなどの機能が進化を続けています。また、VolumeGroupSnapshotのような新しい追加機能は、たとえディザスタリカバリーを念頭に置いて考えられたものであっても、フォレンジック調査員にとって大きな助けとなるはずです。

最後に、最新のリリースに見られる傾向に従って、見出しにはなりませんが、みんなの仕事を楽にするようなQOL（クオリティ・オブ・ライフ）の変更もたくさんあります。例えば、Podを再起動せずにリソースを更新できるようになったり、内部IPがサービスに割り当てられる方法が改善されたり、プラグインによる新しいkubectlサブコマンドが追加されたりしています。

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

話すべきことはたくさんあるので、早速、Kubernetes 1.27 の新機能を紹介していきましょう。

Kubernetes 1.27 – エディターズピック：

このリリースで最もエキサイティングに見えるのは、これらの機能です（ymv）：

#3720 k8s.gcr.ioイメージレジストリのフリーズ

Kubernetesはこの動きでGoogle Cloudへの依存を取り除き、最も身近なクラウドプロバイダーからイメージを提供できるようにしました。”これはgoogleのプロジェクトではない” と称する大きな表明であり、このプロジェクトをもう少し誰にでも開かれたものにするものです。また、いろいろなところで効果を発揮する施策だと思います： イメージのダウンロードが速くなり、データセンター間で移動されるデータが少なくなり、その結果、わずかにクラウド環境に優しくなります。

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

#3476 VolumeGroupSnapshot

Podの全ボリュームで一貫したスナップショットを取得できることは、ディザスタリカバリーにとって画期的なことです。ボリュームが数秒の差でバックアップされたために、アプリが正しく動作しなくなるという心配がなくなります。

さらに言えば、これはセキュリティ調査にも大きな変化をもたらすでしょう。フォレンジック調査を行う際、スナップショットがPodの状態を忠実に表していることを確認することができるようになったのです。

Miguel Hernández – Security Content Engineer at Sysdig

#1287 PodリソースのIn-Placeアップデート

これは長い間続いている機能で、元の提案は2019年のものです。これでようやく、Podを必ずしも再起動しなくても、Podのコンテナリソースを更新できるようになります。

この機能は、CRI仕様の更新が必要でしたが、再起動にうまく対応できず、時々リソースのチューニングが必要になるようなワークロード（データベースクラスタなど）を扱うオペレータにはきっと喜ばれるでしょう。

しかし、その影響についても考える必要があるでしょう： Kubernetesのスケジューラーや監視ツールも、ノードで利用可能なリソースを適切に評価するために、PodStatusの新しいフィールドを見る必要が出てくるでしょう。

Daniel Simionato – Security Content Engineer at Sysdig

#1880 マルチプルサービスCIDR

制限を好む人はいません。多くのサービスを持つ大きなクラスターで作業している場合はなおさらです。クラスターの内部IPの任意の制限を管理しなければならないのは、楽しいことではありません。

内部IPの割り当て方法を全面的に見直すことで、いくつかの制限がなくなり、クラスターリソースをクエリーする際により良いインサイトを提供するようになりました。これは、すべてのクラスター管理者にとって非常に歓迎すべき変化です。

良いものを本当に素晴らしいものにするのに時間がかかると、プロジェクトが成熟していることを感じることができます。

Javier Martínez – Devops Content Engineer at Sysdig

#3638 シャドウイングしないサブコマンドのkubectlプラグイン解決を改善する

機能性を提供することとコードベースの保守性を保つことの間には、常にバランスが必要です。Kubernetes 1.27から、開発者はプラグインを介してkubectlのサブコマンドを提供できるようになりました。これは、コードベースを濁すことなく、私たちが知っているkubectlコマンドを使えるようになるため、より良いユーザー体験を意味します。これはWin-Winなのです。

Devid Dokash – Devops Content Engineer at Sysdig

非推奨

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

もう提供されない（新しいものを使うべき）非推奨のAPIバージョン：

  • Kubeadm  v1beta2, kubeadm config migrate は v1beta3への移行に使用することができます。
  • resource.k8s.io/v1alpha1.PodScheduling: resource.k8s.io/v1alpha2.PodSchedulingContext を使用します。
  • DynamicResourceManagement  v1alpha1:  v1alpha2を使用します。
  • CSIStorageCapacity:  Storage.k8s.io/v1beta1:  v1を使用します。


非推奨：次のリリースが出る前に代替案を実装してください：

  • seccomp.security.alpha.kubernetes.io/pod  と  container.seccomp.security.alpha.kubernetes.io annotations:代わりに  securityContext.seccompProfile  フィールドを使用します。
  • SecurityContextDeny のアドミッションプラグイン。
  • service.kubernetes.io/topology-aware-hints  アノテーション:  service.kubernetes.io/topology-mode を使用します。

削除されました：アップグレード前に代替案を実装してください：

  •  k8s.gcr.io レジストリ: 代わりに registry.k8s.io を使用します[#3720]。
  • Feature gate：
    • IPv6DualStack
    • ExpandCSIVolumes
    • ExpandInUsePersistentVolumes
    • ExpandPersistentVolumes
    • ControllerManagerLeaderMigration
    • CSI Migration
    • CSIInlineVolume
    • EphemeralContainers
    • LocalStorageCapacityIsolation
    • ¨C26C
    • ¨C27C
    • ¨C28C
    • ¨C29C
  • appProtocol:  kubernetes.io/grpc
  • Kube-apiserver flag: --master-service-namespace
  • CLI Flags: --enable-taint-manager と --pod-eviction-timeout
  • Kubelet flags: --container-runtime, --master-service-namespace
  • Azure disk in-tree storageプラグイン。
  • AWS kubeletのクレデンシャルプロバイダー： ecr-credential-providerを使用します。
  • メトリクス：
    • node_collector_evictions_number  を  node_collector_evictions_total に置き換えられました。
    • scheduler_e2e_scheduling_duration_seconds は scheduler_scheduling_attempt_duration_secondsに置き換えられました。

その他の変更点については、各自の設定に合わせる必要があります：

  • Kubelet:  --container-runtime-endpoint と --image-service-endpoint  は、 kubelet  に移行されました。
  • StatefulSet名は、サブドメインではなく、DNSラベルでなければなりません。
  •  resourceClaims  フィールドが set から map に変更されました。
  • NodeAffinity Filter プラグイン：  PreFilter  が  Skip を返した場合、 Filter  が実行されません。
  • Scheduler： 特定のメソッドが不要なときに実行しないようにしました：
    • NodeAffinityの Filter
    • InterPodAffinityの Filter
    • Score
  • resource.k8s.io/v1alpha1/ResourceClaim  が再利用された UID を拒否するようになりました。
  • Kubelet： 特定のレガシー  iptables s ルールをデフォルトで作成しないようになりました。
  • Kubelet：  MemoryThrottlingFactor  のデフォルト値が  0.9になりました。
  • Pod API：  .spec.schedulingGates[*].name  フィールドは、修飾名を必要とします。これは、.spec.readinessGates[*].nameの検証ルールを反映するようになりました。
  • PodSpec： 無効な ResourceClaim と ResourceClaimTemplate の名前を拒否するようになりました。
  • resource.k8s.io  API：  AllocationResult 構造体のブレークチェンジを行いました。

#3720 k8s.gcr.ioのイメージレジストリをフリーズ

Stage: Stable
Feature group: sig-k8s-infra

Kubernetesの公式イメージレジストリが registry.k8s.ioに移りましょう。

以前のレジストリである k8s.gcr.ioは、Google Cloudでホストされていました。昨今のマルチクラウドの世界で単一のクラウドプロバイダに頼るのは、少し古いやり方でした。

新しいレジストリによって、Kubernetesプロジェクトはより高い可用性を提供できるようになり、また、密接にミラーリングすることができるようになりました。今、あなたは自分がいるのと同じデータセンターからイメージをダウンロードしているかもしれません。すごいですね！

k8s.gcr.io レジストリは2023年4月3日にフリーズされる予定です。そして、その状態のままとなります：

  • k8s.gcr.ioの最後の1.23リリースは1.23.18です（1.23はフリーズ前にEoL化されます）。
  • k8s.gcr.io の最後の 1.24 リリースは 1.24.12 となります。
  • k8s.gcr.ioでの最後の1.25リリースは1.25.8となる予定です。
  • k8s.gcr.ioでの最後の1.26リリースは1.26.3です。
  • 1.27は2023年4月12日にリリースされる予定です（そのため、利用できません）。

自分のクラスターが古いイメージレジストリに依存しているかどうかは、以下のコマンドを実行することで確認できます：

kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -cCode language: PHP (php)

詳細は、Kubernetesの公式アナウンスでご確認ください。

Kubernetes 1.27 API

#3488 アドミッションコントロールにおけるCEL

Stage: Alpha
Feature group: sig-api-machinery
Feature gate:ValidatingAdmissionPolicyDefault value:false

この機能拡張は、#2876 CRD検証式言語をビルドして、Kubernetes 1.26以降、新しいアドミッションコントローラタイプ(ValidatingAdmissionPolicy) を提供し、Webhooksに依存せずにいくつかの検証を実装できるようにします。

例えば、以下のようなものです： “レプリカが5つ以下のデプロイに対するリクエストを拒否する”

Kubernetes 1.27では、次のような新機能が追加されています：

  • ポリシーが拒否されたときにメッセージを返すためのメッセージ表現。
  • 新しい validationActions フィールドは、リクエストを拒否、警告、および/または監査するかどうかを定義します。
  • 新しい auditAnnotations で、監査イベントに追加情報を追加します。

詳しくは「Kubernetes 1.26の最新情報」記事をご覧ください。

#3716 CELベースのアドミッションWebhookのマッチング条件

Stage: Net New to Alpha
Feature group: sig-api-machinery
Feature gate:AdmissionWebhookMatchConditionsDefault value:false

#3488 アドミッションコントロールにおけるCELに関連して、きめ細かいリクエストフィルタリングが必要な場合に備えて、新しい matchConditions フィールドが追加されました。

例えば、 ValidatingWebhookConfigurationに以下のような条件を追加することで実現できます：

matchConditions:
  - name: 'exclude-kubelet-requests'
    expression: '!("system:nodes" in request.userInfo.groups)'
Code language: JavaScript (javascript)

これにより、ノードから来る（kubeletからの）リクエストは除外されます。

#3157 チャンキングではなく、データのストリームを取得するためのインフォーマーを許可する

Stage: Net New to Alpha
Feature group: sig-api-machinery
Feature gate:WatchListDefault value:false

大規模なKubernetesクラスターに対してOOM攻撃を可能にするエッジケースが存在します。クライアントがLISTリクエスト（データの一貫したスナップショット）を実行すると、メモリ消費量が予測不可能で高くなります。

このエンハンスメントでは、LISTリクエストの代替としてWATCHリクエストを提供します。メモリ使用量を削減する最適化の実装に加え、データはイベントベースでフェッチされる際にストリーミングされます。

この新しい方法は、メモリ使用量を数桁削減することができます。しかし、クライアントは新しいパラダイムのリストに適応する必要があります。

実装の詳細に興味がある方は、KEPをご覧ください。包括的な情報があります。

#2885 サーバーサイドでのUnknownフィールド検証

Stage: Graduating to Stable
Feature group: sig-api-machinery
Feature gate:ServerSideFieldValidationDefault value:true

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

詳しくは「Kubernetes 1.23の最新情報」記事をご覧ください。

#2896 OpenAPI v3

Stage: Graduating to Stable
Feature group: sig-api-machinery
Feature gate:OpenApiv3Default value:true

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

詳しくは、「Kubernetes 1.23 – 最新情報」の記事をご覧ください。

#3352 Aggregated Discovery

Stage: Graduating to Beta
Feature group: sig-api-machinery
Feature gate:AggregatedDiscoveryEndpointDefault value:true

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

今回のエンハンスメントでは、これらの呼び出しをわずか2回に減らすことを目的としています。

詳しくは「Kubernetes 1.26の最新情報」記事をご覧ください。

#2876 CRDバリデーション式言語

Stage: Graduating to Beta
Feature group: sig-api-machinery
Feature gate:CustomResourceValidationExpressionsDefault value:true

このエンハンスメントは、Webhooksに基づく既存のものを補完するものとして、Custom Resource Definition（CRD）のための検証メカニズムを実装します。

これらの検証ルールはCommon Expression Language（CEL）を使用し、 x-kubernetes-validations extensionを使用して CustomResourceDefinitionスキーマに含まれます。

詳しくは「Kubernetes 1.23の最新情報」記事をご覧ください。

Kubernetes 1.27 Apps

#3140 CronJob で TimeZone をサポート

Stage: Graduating to Stable
Feature group: sig-apps
Feature gate:CronJobTimeZoneDefault value:true

このFeatureは、 CronJob リソースでタイムゾーンをサポートするという、遅れていたリクエストに応えるものです。これまで、CronJobs で作成された Jobs は、kube-controller-managerプロセスのベースとなったタイムゾーンと同じタイムゾーンに設定されました。

詳しくは「Kubernetes 1.24の最新情報」の記事でご確認ください。

#3017 PodHealthyPolicyにおけるPodDisruptionBudget

Stage: Graduating to Beta
Feature group: sig-apps
Feature gate:PDBUnhealthyPodEvictionPolicyDefault value:true

PodDisruptionBudgetを使用すると、クラスター管理者にいくつかの最小値を伝え、メンテナンス作業を容易にすることができます。”Do not destroy more of these” や “Keep at least two of these alive” などのように。

新しいPodHealthyPolicyでは、これらのヒントを不健全なPodに拡大することができます。たとえば、「Running but not Ready」のPodなどです。

詳しくは「Kubernetes 1.26の最新情報」記事をご覧ください。

#3715 Elastic Indexed Jobs

Stage: Net New to Beta
Feature group: sig-apps
Feature gate:ElasticIndexedJobDefault value:true

インデックス付きジョブは、Kubernetes 1.21で導入され、並列性の高いジョブのスケジューリングが容易にできるようになりました。

ただし、一度作成すると、ジョブの数 (spec.completions) や、いくつ並列に実行するか (spec.parallelism) を変更することはできません。これは、深層学習のような一部のワークロードではかなり問題になっています。

今回のエンハンスメントにより、これらのフィールド (spec.completions と spec.parallelism) をいくつかの制限付きで変更可能になります（両者は等しくなければなりません）。

#3335 StatefulSetでレプリカの開始順序を制御できるようにする

Stage: Graduating to Beta
Feature group: sig-apps
Feature gate:StatefulSetStartOrdinalDefault value:true

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

今回のエンハンスメントでは、StatefulSetのマニフェスト仕様に1つのフィールドを持つ新しい構造体,<span> </span>spec.ordinals.startを追加し、StatefulSetが制御するレプリカの開始番号を定義できるようにしました。

詳しくは「Kubernetes 1.26の最新情報」記事をご覧ください。

#3329 Jobs における Retriable と Non Retriable Pod フェイル

Stage: Major Change to Beta
Feature group: sig-apps
Feature gate:JobPodFailurePolicyDefault value:true<br /><strong>Feature gate:</strong>PodDisruptionsConditionDefault value:true

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

詳しくは「Kubernetes 1.25の最新情報」の記事でご確認ください。

#1847 StatefulSetで作成されたPVCを自動削除する

Stage: Graduating to Beta
Feature group: sig-apps
Feature gate:StatefulSetAutoDeletePVC<span> </span><strong>Default value:<span> </span></strong>true

StatefulSetのライフサイクル中にPersistent Volume Claims（PVC）を削除するかどうか、またどのように削除するかを制御する、新しいオプション  .spec.persistentVolumeClaimRetentionPolicy  フィールドが追加されました。

詳しくは「Kubernetes 1.23の最新情報」の記事でご確認ください。

Kubernetes 1.27 Auth

#3299 KMS v2 の改良

Stage: Graduating to Beta
Feature group: sig-auth
Feature gate:KMSv2Default value:true

この新機能は、鍵管理システムのパフォーマンスとメンテナンス性を向上させることを目的としています。

現在、鍵のローテーションなどの作業には、各 kube-apiserver インスタンスの再起動が複数回必要です。これは、すべてのサーバーが新しい鍵を使用してすべてのシークレットを暗号化および復号化できるようにするために必要です。これはリソースを消費するタスクであり、クラスターを数秒間サービス停止に追い込む可能性があります。

この機能により、最新の鍵の自動ローテーションが可能になります。

注意： Kubernetes 1.27にアップグレードする前に、このバージョンを無効にしてください。実装が大きく変わったため、1.25と互換性がなく、この機能を有効にしたままアップグレードすると、データが失われる可能性があります。

詳しくは「Kubernetes 1.25の最新情報」記事でご確認ください。

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

Stage: Graduating to Beta
Feature group: sig-auth
Feature gate:LegacyServiceAccountTokenNoAutoGenerationDefault value:true

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

詳しくは「Kubernetes 1.24 – 最新情報」記事をご覧ください。

#3325 セルフユーザー属性を取得するAuth API

Stage: Graduating to Beta
Feature group: sig-auth
Feature gate:APISelfSubjectAttributesReviewDefault value:true

kubectl alpha auth whoamiを実行してクラスターで認証されると、通常の /me を実行して自分のアクセス許可を確認できるようになりました。

詳しくは「Kubernetes 1.26の最新情報」記事をご覧ください。

Kubernetes 1.27 CLI

#3638 シャドウイングしないサブコマンドのkubectlプラグイン解決を改善

Stage: Net New to Alpha
Feature group: sig-cli
Environment variable:KUBECTL_ENABLE_CMD_SHADOWDefault value:false

この機能拡張により、開発者は kubectl の機能を拡張し、管理者がサブコマンドを介してプラグインを使用できるようになります。

これは例えば、増え続ける CustomResourceDefinition を管理するのに便利です。同時に、この機能をプラグインで実装することで、 kubectl のコードに集中させ、保守を容易にすることができます。

新しいサブコマンドは既存のサブコマンドを上書きすることはできません。例えば、実行時に：

$ kubectl create foo

すると、 create foo  サブコマンドが存在しないため、kubectl は  kubectl-create-foo  プラグインを探し出して実行しようとします。

#3659 ApplySet: kubectl apply -prune リデザインとグラデュエーション戦略

Stage: Alpha
Feature group: sig-cli
Environment variable:KUBECTL_APPLYSETDefault value:0

kubectl apply コマンドは、deployment yamlファイルからオブジェクトを作成または更新することを可能にします。deployment の一部でなくなったオブジェクトを破棄したい場合は、 --pruneを使用すると、kubectlはそれらを削除するために最善の努力をします。

しかし、このプロセスは完璧ではなく、オブジェクトのリークにつながることがよくあります。

この機能拡張は、現在の --prune フラグを非推奨とし、より良いパフォーマンスで驚きを少なくする新しいアプローチに置き換えることを目的としています。

deployment 内のオブジェクトをApplySetグループにまとめることができるようになり、実際にどのオブジェクトを刈り込まなければならないか、 kubectlに明示的なヒントを提供できるようになりました。

これらのヒントは、 applyset.k8s.io をプレフィックスとするラベルで提供されます。例えば、 applyset.k8s.io/part-of ラベルは、オブジェクトがどのApplySetの一部であるかを定義することができます。

さらに興味があれば、KEPにpruneの問題点と、新しく提案されたラベルについての詳しい説明があります。

#2227 kubectl で使用されるデフォルトのコンテナアノテーション 

Stage: Graduating to Stable
Feature group: sig-cli

Podに新しい kubectl.kubernetes.io/default-container アノテーションが追加され、デフォルトコンテナを定義できるようになりました。

これにより、サイドカーコンテナを持つPodで kubectl logs や kubectl exec などのツールの使用が簡素化されます。

詳しくは「Kubernetes 1.21の最新情報」記事をご覧ください。

#2590 kubectlにサブリソースのサポートを追加

Stage: Graduating to Beta
Feature group: sig-cli

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

詳しくは「Kubernetes 1.24の最新情報」記事をご覧ください。

#3515 OpenAPI v3 における kubectl explain

Stage: Graduating to Beta
Feature group: sig-cli
Environment variable:KUBECTL_EXPLAIN_OPENAPIV3Default value:false

このエンハンスメントにより、 kubectl explain でv2ではなくOpenAPIv3からデータを収集することができるようになりました。

詳しくは「Kubernetes 1.26の最新情報」の記事でご確認ください。

Kubernetes 1.27 Instrumentation

#1748 Podモデルを表現するリソースリクエストとリミットに関するメトリクスを公開

Stage: Graduating to Stable
Feature group: sig-instrumentation

kube-scheduler は、実行中のすべてのPodのリクエストリソースと望ましいリミットに関するより多くのメトリクスを公開するようになりました。これにより、クラスター管理者はキャパシティをより適切に計画し、エラーをトリアージすることができるようになります。

1.20のリリースについては、「Kubernetesの最新情報」シリーズで詳しくご紹介しています。

#647 APIサーバーのトレース

Stage: Graduating to Beta
Feature group: sig-instrumentation
Feature gate:APIServerTracingDefault value:true

このエンハンスメントでは、APIサーバーが改善され、OpenTelemetryライブラリとOpenTelemetryフォーマットを使用したリクエストをトレースできるようになりました。

詳しくは「Kubernetes 1.22の最新情報」記事でご確認ください。

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

Stage: Graduating to Beta
Feature group: sig-instrumentation
Feature gate:ComponentSLIsDefault value:true

Kubernetes 1.26から、各コンポーネントに新しいエンドポイント /metrics/slis が用意され、Service Level Indicator (SLI) メトリクスが Prometheus 形式で公開されます。

各コンポーネントについて、2つのメトリクスが公開されます：

  • ゲージ、ヘルスチェックの現在の状態を表します。
  • カウンター、各ヘルスチェックの状態で観測された累積カウントを記録します。

詳しくは「Kubernetes 1.26の最新情報」記事をご覧ください。

#3498 メトリクスの安定性を拡張

Stage: Graduating to Beta
Feature group: sig-instrumentation

Kubernetes 1.26では、2つの新しいクラスのメトリクスが追加されました：

  • beta: ベータ機能に関連するメトリクス。変更されたり、なくなったりすることもありますが、Alphaのものよりも開発が進んでいる状態です。
  • internal: クラスター管理者にとって有益な情報を提供しません。予告なく変更される可能性があるため、気にする必要はない内部使用向けのメトリクスです。

詳しくは「Kubernetes 1.26の最新情報」の記事でご確認ください。

関連情報：Kubernetes 1.21 #1209 メトリクスの安定性向上

Kubernetes 1.27 Network

#3705 クラウドデュアルスタック -node-ip の取り扱いについて

Stage: Net New to Alpha
Feature group: sig-network
Feature gate:CloudDualStackNodeIPsDefault value:false

このエンハンスメントにより、クラウドプロバイダー（ --cloud-provider フラグを使用）内のクラスターに対して kubelet の --node-ip 引数を実装します。

1つのIPv4アドレス、1つのIPv6アドレス、またはその両方を指定することができるようになります。これは、クラスターがノードと通信するために使用するIPです。

もちろん、クラウドプロバイダーもこのオプションをサポートしている必要があります。 kubelet が行うのは、クラウドプロバイダーが実装方法を選択できる kubernetes.io/provided-node-ip ラベルを設定することだけです。

#3668 動的および静的な割り当てのためのノードポート範囲の予約

Stage: Net New to Alpha
Feature group: sig-network
Feature gate:ServiceNodePortStaticSubrangeDefault value:false

NodePortタイプのサービスを使用してPodをクラスターの外部に公開する場合、Staticな特定のポートを使用するか、クラスターがポートを選択するようにするかのいずれかを選択することができます。

しかし、特定のポートを選択したときに、そのポートがすでに使用されている場合は、エラーが発生します。

このエンハンスメントにより、「フェイルセーフ」範囲が可能になりました。選択したポートが使用中であれば、well-known 範囲の別のポートが使用されます。この範囲は、 kube-apiserverの service-node-port-range 引数で定義することができます。デフォルトは：

--service-node-port-range 30000-32767

#1880 マルチプルサービスCIDR

Stage: Net New to Alpha
Feature group: sig-network
Feature gate:MultiCIDRServiceAllocatorDefault value:false

このエンハンスメントは、内部IPアドレスがサービスに割り当てられる方法を改良するために行われる作業で構成されています。これにより、現在のIP範囲 (service-cluster-ip-range)に対する制限がなくなります。また、 kubectl を使用してサービスに割り当てられた IP アドレスを検査できるようになります：

$ kubectl get services
NAME         TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   2001:db8:1:2::1   <none>        443/TCP   3d1h
$ kubectl get ipaddresses
NAME              PARENTREF
2001:db8:1:2::1   services/default/kubernetes
2001:db8:1:2::a   services/kube-system/kube-dns
Code language: JavaScript (javascript)

これは、現在の etcd の割り当てマップを、各Serviceオブジェクトから参照されるIPAddressオブジェクトの使用に置き換えることで実装されています。

#3178 IPTablesチェーンの所有権のクリーンアップ

Stage: Graduating to Beta
Feature group: sig-network
Feature gate:IPTablesOwnershipCleanupDefault value:false

Dockershimの削除に伴い、いくつかの余分なクリーンアップが行われています。特に、 kubelet と kube-proxy はリファクタリングされ、IPTablesチェーンを作成するのは kubelet ではなくなりました。

詳しくは「Kubernetes 1.25の最新情報」記事をご覧ください。

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

Stage: Graduating to Beta
Feature group: sig-network
Feature gate:MinimizeIPTablesRestoreDefault value:true

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

詳しくは「Kubernetes 1.26の最新情報」記事をご覧ください。

#3458 KCCMのサービスコントローラからtransient node predicatesを削除
Stage: Net New to Beta
Feature group: sig-network
Feature gate:StableLoadBalancerNodeSetDefault value:true

Kubernetesクラウドコントローラーマネージャー（KCCM）は、「ロードバランサーのノードセット」からノードを削除すると、そのノードへのすべての接続を即座に終了させることができます。

今回のエンハンスメントにより、「ロードバランサーのノードセット」は常に更新されるわけではなく、クラウドプロバイダーがロードバランサーでより適切なシャットダウンを実施できるようになりました。

Kubernetes 1.27 Nodes

#3673 Kubeletによる並列イメージプルの制限

Stage: Net New to Alpha
Feature group: sig-node
Kubelet config option:serializeImagePullsDefault value:true<br /><strong>Kubelet config option:</strong>maxParallelImagePullsDefault value:0

現在、 kubelet の設定で serializeImagePulls を false に設定することで、コンテナイメージを並行してダウンロードすることを許可することができます。しかし、同時にダウンロードされるイメージの数に制限を設定する方法はありませんでした。

このため、ネットワークやディスクの使用量が急増し、クラスターのパフォーマンスに影響を与える可能性がありました。

現在では、 kubelet の設定で maxParallelImagePulls に 0 とは異なる数値を設定することで、イメージの並列ダウンロード数を制限することができます。

#1287 Podリソースのインプレースアップデート

Stage: Net New to Alpha
Feature group: sig-node
Feature gate:InPlacePodVerticalScalingDefault value:false

この機能により、Podを再起動することなく、コンテナリソースのリクエストやリミットを変更することができます。

Pod Specの現在のフィールド、 Pod.Spec.Containers[i].Resourcesは、Podリソースの望ましい状態の宣言となります。一方、 Pod.Status sub-resourceに新しいフィールドが追加されます：

  • .ContainerStatuses[i].ResourcesAllocated:  コンテナに割り当てられているリソースを記述する。
  • .ContainerStatuses[i].Resources:  コンテナが実際に保持しているリソースについて。
  • .Resize:  リソースのサイズ変更操作の進行状況の詳細。

Podのコンテナスペックでは、CPUとメモリの ResizePolicy を指定することもでき、 Restart とRestartNotRequiredという値があり、新しい値を適切に適用するためにコンテナの再起動が必要かどうかが詳細に説明されています。

#2570 Cgroups v2でメモリQoSのサポート

Stage: Alpha
Feature group: sig-node
Feature gate:MemoryQoSDefault value:false

Cgroupsv2を使用して、メモリ使用量に応じてプロセスをkillおよびthrottleするMemory QoSを設定することが可能になりました。

詳しくは「Kubernetes 1.22の最新情報」記事をご覧ください。

#3695 PodResourcesを拡張して、Dynamic Resource Allocation (DRA)からのリソースを含めることができるようになりました

Stage: Net New to Alpha
Feature group: sig-node
Feature gate:KubeletPodResourcesGetDefault value:false<br /><strong>Feature gate:</strong>KubeletPodResourcesDynamicResourcesDefault value:false

今回のエンハンスメントにより、「#3063 ダイナミックリソースアロケーション」で追加された新しいリソースが、kubeletによってAPIに公開されるようになりました。

#3063 ダイナミックリソースアロケーション

Stage: Alpha
Feature group: sig-node
Feature gate:DynamicResourceAllocationDefault value:false

スケジューラーは、FPGA や共有 GPU などのリソース要求を追跡し、十分なリソースが利用可能なノードでのみ Pod をスケジュールできるようになりました。

詳しくは「Kubernetes 1.26の最新情報」記事をご覧ください。

#127 ステートレス Podでのユーザーネームスペースのサポート

Stage: Alpha
Feature group: sig-node
Feature gate:UserNamespacesSupportDefault value:false

Kubernetesのエコシステムにユーザーネームスペースを導入することで、セキュリティを向上させるための新たな可能性が広がります。たとえば、あまりにも要求の厳しいコンテナが特権モードで動作していると思い込むことを許可することができるようになりました。

詳しくは「Kubernetes 1.25の最新情報」記事をご覧ください。

#2053 hugepage の下位 API サポートを追加

Stage: Graduating to Stable
Feature group: sig-node
Feature gate:DownwardAPIHugePagesDefault value:true

Podは、downward APIを介して、hugepageのリクエストとリミットに関する情報をフェッチできるようになりました。これにより、CPU、メモリ、ephemeral-storageなどの他のリソースと一貫性を保つことができます。

詳しくは「Kubernetes 1.20の最新情報」記事をご覧ください。

#2413 Kubeletオプションにおいてseccompがデフォルトで有効

Stage: Graduating to Stable
Feature group: sig-node
Feature gate:SeccompDefaultDefault value:true

Kubernetesでは、コンテナのセキュリティを強化し、デフォルトでSeccompプロファイルを使用してコンテナを実行するようになりました。

詳しくは「Kubernetes 1.22の最新情報」の記事でご確認ください。

#693ノードトポロジーマネージャー

Stage: Graduating to Stable
Feature group: sig-node
Feature gate:TopologyManagerDefault value:true

機械学習、科学計算、金融サービスなどは、計算量が多く、超低レイテンシーを必要とするシステムの例です。このようなワークロードでは、コア間を飛び越えたり、他のプロセスと時間を共有したりするのではなく、1つのCPUコアにプロセスを隔離することが有効です。

ノードトポロジーマネージャーは、ハードウェアリソースの割り当てを一元管理するkubeletコンポーネントです。現在のアプローチでは、このタスクを複数のコンポーネント（CPUマネージャー、デバイスマネージャー、CNI）に分割しているため、最適化されていない割り当てが発生することがあります。

1.16のリリースについては、「Kubernetesの最新情報」シリーズで詳しくご紹介しています。

#2727 Pod.Spec.Container.{Liveness,Readiness,Startup}Probe に gRPC プローブを追加

Stage: Graduating to Stable
Feature group: sig-node
Feature gate:GRPCContainerProbe<span> </span><strong>Default value:<span> </span></strong>true

このエンハンスメントにより、gRPC（HTTP/2 over TLS）のliveness probesをPodに設定することが可能になりました。

Kubernetes 1.16で追加されたliveness probesは、アプリケーションがまだ生きているかどうかを定期的にチェックすることを可能にします。

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

#2238 プローブに設定可能な猶予時間を追加

Stage: Graduating to Stable
Feature group: sig-node
Feature gate:ProbeTerminationGracePeriodDefault value:true

今回のエンハンスメントでは、2つの状況を区別するために、 livenessProbe オブジェクト内に2番目の terminationGracePeriodSeconds フィールドを導入しました： Kubernetesは通常の状況下でコンテナをkillするためにどのくらい待つべきで、killが livenessProbeの失敗によるものである場合はいつでしょうか？

詳しくは「Kubernetes 1.21 – 最新情報」記事をご覧ください。

#3386 パフォーマンス向上のための Kubelet Evented PLEG
Stage: Graduating to Beta
Feature group: sig-node
Feature gate:EventedPLEGDefault value:true

このエンハンスメントにより、すべてのPodの状態を追跡する際の kubelet のCPU使用量が削減されます。これは、Container Runtime Interface（CRI）からの通知に可能な限り依存することで実現されています。

詳しくは、「Kubernetes 1.26の最新情報」の記事でご確認ください。

Kubernetes 1.27  Scheduling

#3838 ゲート時の変更可能な Pod スケジューリング ディレクティブ

Stage: Graduating to Beta
Feature group: sig-scheduling
Feature gate:PodSchedulingReadinessDefault value:true

“#3521 Pod scheduling readiness “以降、Podはスケジューリングの準備が整ったタイミングを定義できるようになりました。

この機能では、これらのスケジューリングゲートをミュータブルにして、カスタムスケジューリングコントローラのような他のコンポーネントが、 kube-schedulerの機能を拡張するためにこれらを使用できるようにしています。例えば、アドミッションコントローラーでこれらのスケジューリングゲートを1つ追加し、利用可能なリソースがある時点で削除することができます。

この変更可能性には、いくつかの制限があります：

  • .spec.nodeSelector: 追加のみ受け付けます。
  • .spec.affinity.nodeAffinity: nilの場合のみ設定可能です。
  • NodeSelectorTerms: nilの場合、設定できます。nilでない場合は、特定の追加のみを受け付けます。
  • .preferredDuringSchedulingIgnoredDuringExecution:  すべての更新を受け入れます。

#3521 Pod scheduling readiness

Stage: Graduating to Beta
Feature group: sig-scheduling
Feature gate:PodSchedulingReadinessDefault value:true

このエンハンスメントは、実際にスケジューリングする準備が整ったタイミングをPodに定義させることで、スケジューリングを最適化することを目的としています。

詳しくは「Kubernetes 1.26の最新情報」記事をご覧ください。

#3243 ローリングアップグレード後にPodTopologySpreadをリスペクトする

Stage: Graduating to Beta
Feature group: sig-scheduling
Feature gate:MatchLabelKeysInPodTopologySpreadDefault value:true

PodTopologySpread は、互いに関連するPodをどれだけ均等に分散させるかをよりよく制御することを容易にします。しかし、新しいPodのセットを展開する場合、既存のPod（すぐになくなるPod）も計算に含まれるため、将来のPodの分布が不均一になる可能性があります。

今回のエンハンスメントでは、Podの定義に含まれる任意のラベルを考慮できるよう、Pod仕様とその計算アルゴリズムに新しいフィールドを追加し、コントローラーがより正確なPodのセットを作成してからスプレッドを計算できるようにしました。

詳しくは「Kubernetes 1.25の最新情報」記事をご覧ください。

#2926 停止したジョブのスケジューリングディレクティブを変更できるようになりました

Stage: Graduating to Stable
Feature group: sig-scheduling
Feature gate:JobMutableNodeSchedulingDirectives<span> </span><strong>Default value:<span> </span></strong>true

Kubernetes 1.23以降、JobのPodテンプレートのノードアフィニティ、ノードセレクタ、トレランス、ラベル、アノテーションフィールドを開始前に更新することができるようになりました。これにより、すべてのPodが同じゾーンで実行されたり、同じGPUモデルを持つノードで実行されたりするなど、Podの実行場所に影響を与えることができます。

詳しくは、「Kubernetes 1.23の最新情報」の記事をご覧ください。

Kubernetes 1.27  storage

#3476 VolumeGroupSnapshot

Stage: Graduating to Alpha
Feature group: sig-storage
Flag:enable-volume-group-snapshot

このエンハンスメントにより、Kubernetes APIで、複数のボリュームをまとめたスナップショットを一貫性のある形で作成し、データ損失を防ぐためのサポートが追加されます。

例えば、データ用とログ用など、異なるボリュームを使用しているアプリケーションを例にとってみましょう。両方のボリュームのスナップショットを異なるタイミングで作成すると、ディザスターリカバリを実行する際に、アプリケーションの動作が一貫しない可能性があります。

VolumeGroupSnapshotを実行するには、CSIドライバーが CREATE_DELETE_GET_VOLUME_GROUP_SNAPSHOT 能力をサポートしている必要があります。

#3756 kubelet 再起動後にロバストな VolumeManager の再作成

Stage: Net New to Beta
Feature group: sig-storage
Feature gate:NewVolumeManagerReconstructionDefault value:true

このエンハンスメントは、「#1710 マウントオプションによるSELinuxの再ラベリング」の一部で、 kubelet が再起動した後にマウントしたボリュームの再トラッキングにかかる時間を短縮するものです。

kubelet が再起動されると、実行中のPodのためにマウントしたボリュームがわからなくなります。APIサーバーからの情報とホストのOSからのデータを掛け合わせることで、この状態を復元することができます。実行されているはずのPodと、実際にマウントされているボリュームを確認するのです。

しかし、このプロセスは完璧ではなく、一部のボリュームのクリーンアップに失敗することもあります。また、以前の kubelet がボリュームのマウントに使用したマウントオプションなど、いくつかの重要な情報も欠けています。

つまり、結局のところ、このエンハンスメントはバグフィックスのようなものなのです： “期待通りに動くようにする “ということです。かなりのリファクタリングが必要で、動作も現在とは変わってしまいます。そのため、別のエンハンスメントに分割し、管理者が以前の動作にロールバックできるよう、独自のFeatureフラグを設けています。

#2485 ReadWriteOncePod PersistentVolumeアクセスモード

Stage: Graduating to Beta
Feature group: sig-storage
Feature gate:ReadWriteOncePodDefault value:true

今回のエンハンスメントにより、PersistenVolumesにReadWriteOncePodモードでアクセスし、1つのノード上の1つのPodにアクセスを制限することができるようになりました。

詳しくは「Kubernetes 1.22の最新情報」記事をご覧ください。

#3107 CSI PVソースにnodeExpandSecretを導入

Stage: Graduating to Beta
Feature group: sig-storage
Feature gate: CSINodeExpandSecretDefault value:true

これらの新しいエンハンスメントにより、 NodeExpandVolumeオペレーションを行う際に、CSIドライバに secretRef フィールドを渡すことが可能になりました。

詳しくは「Kubernetes 1.25の最新情報」記事をご覧ください。

#3141 ボリューム復元中の無許可のボリューム モード変換を防止

Stage: Graduating to Beta
Feature group: sig-storage

本機能は、Kubernetes 1.20でGAされた VolumeSnapshot 機能にセキュリティ層を追加するものです。このような操作の際に、ボリュームモードが不正に変換されることを防止するものです。カーネルには悪意のあるユーザーに悪用されるような既知のCVEはありませんが、この機能は万が一に備えてその可能性を排除することを目的としています。

このバージョンでは、アノテーション snapshot.storage.kubernetes.io/allowVolumeModeChange がsnapshot.storage.kubernetes.io/allow-volume-mode-changeに変更されています。

詳しくは「Kubernetes 1.24の最新情報」の記事でご確認ください。

#1710 再帰的なSELinuxのラベル変更を高速化

Stage: Graduating to Beta
Feature group: sig-storage
Feature gate:SELinuxMountReadWriteOncePodDefault value:true

この機能は、SELinuxを使用した PersistentVolumes のマウントを高速化するためのものです。マウント時に context オプションを使用することで、Kubernetesはファイルに対して再帰的にコンテキストを変更するのではなく、ボリューム全体にセキュリティコンテキストを適用します。

詳しくは「Kubernetes 1.25の最新情報」の記事でご確認ください。

Kubernetes 1.27 その他エンハンスメント

#2699 Webhook ホスティング機能を CCM フレームワークに追加するための KEP

Stage: Net New to Alpha
Feature group: sig-cloud-provider
Feature gate:CloudWebhookServerDefault value:false

このエンハンスメントは、クラウドプロバイダーがPersistentVolumeLabel（PVL）アドミッション・コントローラーをWebhookに置き換えることを可能にするための作業で構成されています。

クラウドコントローラー・マネージャー（CCM）は、クラウドプロバイダーが自分のクラウド上でKubernetesクラスターを正しく動作させるために調整するバイナリです。

PLVアドミッションコントローラーが行うような一部のオペレーションは時間的制約があり、パフォーマンスを確保するために特別な設定が必要な場合があります。このような場合、クラウドプロバイダーによっては、このコードをWebhooksに切り離すことを好む場合もあります。

#2258 ノード ログ クエリー

Stage: Net New to Alpha
Feature group: sig-windows
Feature gate:NodeLogQueryDefault value:false

このエンハンスメントにより、ノード上で動作するシステムのログを表示するためのkubelet APIが追加されます。

例えば、あるノードからkubeletのログを取得するには、以下のように実行します：

kubectl get --raw "/api/v1/nodes/node-1/proxy/logs/?query=kubelet"Code language: JavaScript (javascript)

#1731 コミュニティインフラストラクチャーでKubernetesのパッケージを公開

Stage: Net New to Alpha
Feature group: sig-release

このエンハンスメントでは、Googleが所有するパッケージリポジトリからコミュニティが管理するOpen Build Service（OBS）リポジトリに移りましょうという最終目標に向けて、リリースプロセスやパッケージビルドインフラストラクチャーに加えられた取り組みや進行中の変更について詳しく説明します。

#3744 サポートされているgoのバージョンにとどまる

Stage: Graduating to Stable
Feature group: sig-release

Kubernetesはgoで書かれています。マイナーバージョンでは、Kubernetesはgoのバージョンを更新しないようにして、破壊的な変更を導入しないようにしています。しかし、これはライフサイクルの終わりには、Kubernetesがgoに実装されたセキュリティパッチに遅れをとる可能性があることを意味します。

今回のエンハンスメントは、Kubernetesの開発者が、私たちユーザーに壊れるような変更を導入することなく、goの最新バージョンに対応できるようなプロセスやガイドラインを設定することです。

これらのガイドラインの詳細に興味がある方は、KEPにアクセスしてください。

#3203 公式 CVE フィードの自動更新

Stage: Graduating to Beta
Feature group: sig-security

Kubernetesに関する情報を持つCVEのフィードをプログラムで取得できるようになりました。これはクラスターで有効にするエンハンスメントではなく、Web リソース経由で使用する機能です。脆弱性の発表の中から official-cve-feed というラベルを探せばいいだけです。

詳しくは「Kubernetes 1.25の最新情報」記事をご覧ください。

#1610 コンテナリソースベースのPod Autoscaling

Stage: Graduating to Beta
Feature group: sig-autoscaling
Feature gate:HPAContainerMetricsDefault value:true

現在のHorizontal Pod Autoscaler（HPA）は、そのPodが使用するリソースに基づいてワークロードをスケールさせることができます。これは、Pod内のすべてのコンテナからの使用量を集約したものです。

この機能により、HPAは個々のコンテナのリソース使用量に基づいてそれらのワークロードをスケーリングすることができます。

詳しくは、「Kubernetes 1.20の最新情報」の記事でご確認ください。

Kubernetes 1.27の紹介は以上となります！いつもながらエキサイティングです。これらの機能を使用する予定がある場合は、クラスターをアップグレードする準備をしましょう。

この記事が気に入ったら、以前の「Kubernetesの最新情報」編もチェックしてみてください：

Kubernetesプロジェクトに参加する：

また、Kubernetesエコシステムの最新情報を楽しみたい方は、コンテナ・ニュースレターをご購読ください。