Kubernetes 1.23における新機能は?

本文の内容は、2021年11月30日にVíctor Jiménez Cerradaが投稿したブログ(https://sysdig.com/blog/kubernetes-1-23-whats-new/）を元に日本語に翻訳・再構成した内容となっております。

Kubernetes 1.23のリリースが間近に迫っており、斬新な要素が満載ですどこから始めましょうか？

今回のリリースでは、Kubernetes 1.22の56件、Kubernetes 1.21の50件と同様に、45件の機能強化が行われています。この45の機能強化のうち、11はステーブルへの移行、15は改善を続ける既存の機能、19は完全な新機能です。

このバージョンに含まれる新機能は、一般的に小さいものですが、非常に歓迎されています。例えば、kubectl eventsコマンド、OpenAPI v3のサポート、gRPCプローブなどです。また、CSIドライバーの着実な進化やWindowsのサポートなど、長期的なプロジェクトがどのように進化しているかを知ることができるのは素晴らしいことです。

しかし、今回のリリースでは、GA版に搭載されているすべての素晴らしい機能がケーキの上にのっています。どれをつまんでみても、そのリストは膨大です。例えば、CronJobs、IPv4/IPv6デュアルスタックのサポート、エフェメラルボリューム、HPA APIなどです。私たちはこのリリースをとても楽しみにしています。

また、今回のバージョンでは、非推奨事項や削除事項があることも忘れてはいけません。

それでは早速、Kubernetes 1.23の新機能を紹介していきましょう。

Kubernetes 1.23 – 編集者の精選：

今回のリリースで最もエキサイティングに見える機能は以下の通りです(ymmv)。

#2317 FSGroupをKubeletではなくCSI Driverに委ねる

CSIドライバをKubernetesのコアから外し、真のモジュール化を実現するための大きな努力がなされています。これは、Kubernetesチームがいかに明確なビジョンを持ち、それを数年に渡って構築し続けることができるかを物語っています。

より多くの機能をCSIドライバーに委ねることで、新しいプラットフォームへの対応が容易になります。これには、Portworx、Ceph RBD、AWS EBSなどのサービスだけでなく、Windowsなどの新しいOSも含まれます。

David de Torres – Manager of engineer at Sysdig

#1440 kubectl events

新しいkubectl eventsは、イベントには独自のワークフローがあり、kubectl get eventsコマンドだけでは不十分であるという事実に対応しています。これは、Kubernetesチームがいかにクラスター管理者の生活を楽にするかを常に考えていることを示している。

Miguel Hernández – Security Content Engineer at Sysdig

#1790 リサイズの失敗からの復旧

すべてのユーザー、特にKubernetesを新たに導入するユーザーにとって、生活をより快適にしてくれるもう一つのツールです。PVCのサイズ変更に失敗したような一般的なエラーから簡単に回復できる機会があることで、Kubernetesを使用する際のフラストレーションが軽減されます。

Jesús Ángel Samitier – DevOps Content Engineer at Sysdig

#2896 OpenAPI V3 + #2887 OpenAPI Enum Types

OpenAPI v3の拡張サポートは、Kubernetes APIに依存しているツールに新鮮な空気をもたらします。Enum型のサポートや適切な検証など、小さいながらも超越した内容が追加されます。UIでは、これらのフィールドにドロップダウンを表示できるようになります。小さなことですが、これこそが、技術的な知識を持たない人たちにも採用されるきっかけになるでしょう。

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

#2727 PodにgRPCプローブを追加

Kubernetesでは、サイト・リライアビリティ・エンジニアがサービスの可用性を高めるためにプローブを使用しています。普及が進んでいるプロトコルであるgRPCをサポートするプローブを追加することで、開発者は新しいクラウドネイティブアプリケーションの開発を簡素化し、耐障害性を向上させる強力なツールを手に入れることができます。

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

Kubernetes 1.23での非推奨事項

APIと機能の削除

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

apiserver_longrunning_gaugeメトリクスの代わりにapiserver_longrunning_requestsメトリクスを追加しました。
Controller-manager：–port および –address フラグは何の効果もなく、v1.24 で削除されます。
kube-scheduler：

kubescheduler.config.k8s.io/v1beta1 の metricsBindAddress および healthzBindAddress フィールドは、空であることが期待されます。
認証/認可を動作させるためには、–authorization-kubeconfig と –authentication-kubeconfig が正しく設定されていることが期待されます。
kube-scheduler への Liveness and readiness probes は HTTPS を使用しなければならなくなり、デフォルトのポートは 10259 に変更されました。
kube-schedulerからメトリクスを取得するアプリケーションは、専用のサービスアカウントを使用する必要があります。

scheduler_volume_scheduling_duration_secondsメトリクスを削除しました。
EgressSelectorConfiguration API：master は有効な EgressSelection タイプではなくなりました。
–experimental-bootstrap-kubeconfig フラグを削除しました。
VolumeSubpath機能のゲートを非推奨とし、無効にすることはできません。
kubeadm reset “の “update-cluster-status “を削除しました。
kubectl –dry-run オプションは、server、client、none のいずれかのみをサポートするようになりました。
kubeadm output/v1alpha1 API を非推奨としました (output/v1alpha2 に置き換えました)。

変更点の全リストは、Kubernetes 1.23のリリースノートで確認できます。また、今後のために非推奨のAPI移行ガイドをそばに置いておいてください。

#2845 Kubernetesコンポーネントにおけるklog固有のフラグの非推奨化

ステージ：非推奨

機能グループ： instrumentation

機能ゲート： NA

この機能拡張は、ロギングのコンポーネントを単純化するための大きな努力の一部です。最初の試みは、klogのいくつかのフラグを削除することです。

この変更の背景には、Kubernetesが誕生した当初、ロギングにglogライブラリを使用するという決定がありました。その後、より柔軟なソリューションが必要になったため、このライブラリはフォークされ、現在使用されているklogになりました。現在は、さらなる柔軟性が必要とされているため、以下のような新機能向けのライブラリを準備するために、いくつかのクリーンアップを行う時期になりました。

パフォーマンスの向上
Kubernetesのスケーラビリティ要件を満たす
不要になったglogの機能を削除する

#785 Schedulerコンポーネントのconfig APIをv1beta3にし、v1beta1を非推奨にする

ステージ：ベータへ移行

機能グループ: スケジューリング

機能ゲート： NA

ComponentConfigは、コンポーネントの設定をよりダイナミックにし、Kubernetes APIから直接アクセスできるようにするための継続的な取り組みです。

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

このバージョンでは、いくつかのプラグインが削除されました：

NodeResourcesLeastAllocated
NodeResourcesMostAllocated
RequestedToCapacityRatio
NodeLabel
ServiceAffinity
NodePreferAvoidPods

また、スケジューリングポリシーはサポートされていないので、代わりにScheduler Configurationを使用する必要があります。

詳しくはこちらのドキュメントPRをご覧ください。

Kubernetes 1.23 におけるAPI

#2876 CRD Validation Expression Language

ステージ：アルファへ移行

機能グループ:：api-machinery

機能ゲート： CustomResourceValidationExpressions Default value: false

この機能拡張では、Webhooksに基づいた既存の検証メカニズムを補完するために、Custom Resource Definitions (CRD)の検証メカニズムを実装します。

検証手順をCRD自体に含めることで、2つの主な利点が生まれます：

CRDのすべての情報を同じ場所に置くことができる（自己完結型）
Webhookを必要としないことで、開発を大幅に簡素化できる可能性があります

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

…
openAPIV3Schema:
  type: object
  properties:
    spec:
      type: object
      x-kubernetes-validation-rules:
        - rule: "self.replicas <= self.maxReplicas"
          message: "replicas should be smaller than or equal to maxReplicas."
      properties:
        …
        replicas:
          type: integer
        maxReplicas:
          type: integer
      required:
        - replicas
        - maxReplicas

このカスタムリソースを作成するためのリクエストを拒否します：

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  replicas: 20
  maxReplicas: 10

replicasの値がmaxReplicasよりも大きいため。

この機能についてはKubernetesのドキュメントをご覧ください。

#2885 サーバーサイドでのUnknown Field Validation KEPの追加

ステージ：アルファへ移行

機能グループ： api-machinery

機能ゲート： ServerSideFieldValidation Default value: false

現在、kubectl -validate=true を使って、オブジェクトの未知のフィールドを指定した場合にリクエストが失敗することを示すことができます。

この場合、検証はサーバー（kube-apiserver）ではなく、クライアントサイド（kubectl）で行われるため、いくつかの懸念があります。

各クライアントがバリデーションを実装する必要がある
各クライアントのアップデートに余計な手間がかかるため、バリデーションのバグフィックスのロールアウトが遅くなる

この機能強化は、kube-apiserverにバリデーションを実装するための作業をまとめたもので、いくつかのフェーズに分けて実施される予定です（まずサーバーにバリデーションを実装し、後にクライアントがサーバーサイドのバリデーションを使えるようにアップデートする）。計画と実装の詳細は KEP でお読みください。

#2887 OpenAPIのEnum型

ステージ：アルファへ移行

機能グループ: api-machinery

機能ゲート：OpenAPIEnum Default value: false

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

現在、これらのフィールドは文字列として定義されています：

type Protocol string
const (
	ProtocolTCP Protocol = "TCP"
	ProtocolUDP Protocol = "UDP"
	ProtocolSCTP Protocol = "SCTP"
)

+enumマーカーを追加することで

// +enum
type Protocol string

Kubernetes OpenAPIジェネレータは、受け入れられる値がTCP、UDP、SCTPのみであることを認識できます。

この情報は、将来的にこれらのフィールドを制限のないテキストフィールドではなくドロップダウンとして表示することができる他のツールで利用可能です。

#2896 OpenAPI V3

ステージ：アルファへ移行

機能グループ： api-machinery

機能ゲート：OpenApiv3 Default value: false

この機能は、kube-apiserverにKubernetesとタイプをOpenAPI v3オブジェクトとして提供するサポートを追加します。

現在は、$cluster/openapi/v2 clusterエンドポイントでOpenAPI v2オブジェクトとして提供されています。しかし、CRDはOpenAPIのv3を使って定義することができ、enum型のようなより複雑な定義が可能です。v2エンドポイントで提供されるように翻訳されると、型の定義が「accept anything」に変換されるなど、いくつかの情報が欠落します。

OpenApiv3機能ゲートが有効になると、新しい/openapi/v3/apis/{group}/{version}エンドポイントが利用可能になります。これは、すべてを1つに集約するのではなく、リソースごとに1つのスキーマを提供します。

#1040 APIサーバーリクエストのプライオリティとフェアネス

ステージ：ベータへメジャーチェンジ

機能グループ：api-machinery

機能ゲート：APIPriorityAndFairness Default value: true

APIPriorityAndFairness機能ゲートは、APIサーバーで新しいmax-in-flightリクエストハンドラーを有効にします。FlowSchemaオブジェクトで異なるタイプのリクエストを定義し、RequestPriorityオブジェクトでリソースを割り当てることで、KubernetesのAPIサーバーが高負荷時の管理・メンテナンス作業に確実に対応できるようになります。

詳しくは、「Kubernetes 1.18 – What’s new?」を参照ください。この機能には大幅な変更が加えられていますが、チームはステーブルへのグラデュエートに向けてすべてを終えることができませんでした。KEPでの計画についてはこちらをご覧ください。

Kubernetes 1.23におけるApps

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

ステージ：Alphaへ移行

機能グループ: apps

機能ゲート：StatefulSetAutoDeletePVC Default value: false

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

apiVersion: apps/v1
kind: StatefulSet
…
spec:
  persistentVolumeClaimRetentionPolicy:
    whenDeleted: Retain
    whenScaled: Delete
…

削除されたPod（whenDeleted）や、スケールダウンするPodレプリカ（whenScaled）に対して、PVCを保持するか削除するかを決めることができます。

#2879 ジョブステータスに準備完了のPodの数を追加

ステージ：アルファへ移行

機能グループ: apps

機能ゲート： JobReadyPods Default value: false

この機能拡張により、Job.status.readyフィールドが追加され、既存のactive、successful、failedフィールドと同様に、Ready条件を持つJob Podsの数がカウントされます。

新しいreadyフィールドはactiveフィールドとは異なり、activeにはRunningまたはPendingの両方のフェーズにあるJob Podが含まれます。これらのジョブはしばらくの間Pendingフェーズに留まる可能性があるため、activeフィールドはエンドユーザーや他のコントローラに進捗状況の誤った印象を与える可能性があります。

新しいreadyフィールドは、現在のステータスをより正確に把握するためにポッドの更新をリッスンする必要性を減らすことができます。

#19 CronJobs (旧ScheduledJobs)

ステージ：ステーブルへのメジャーチェンジ

機能グループ: apps

機能ゲート： CronJobControllerV2 Default value: true

Kubernetes 1.4で導入され、1.8からはベータとなっていたCronJobsが、ついにステーブルになりました。

CronJobsは、UNIX系システムのcronのように、Kubernetesクラスター内で定期的なタスクを実行します。

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

#592 終了後のTTL

ステージ：ステーブルへ移行

機能グループ: apps

機能ゲート：TTLAfterFinished Default value: true

この機能は、FinishedやCompleteのジョブを自動的にクリーンアップします。これらのジョブは通常、システム内では不要であり、それらを維持することでAPIサーバーの負荷が増大するため、これは便利です。

ttlSecondsAfterFinishedフィールドを設定することで、コントローラがこれらをクリーンアップすることができるようになりました。

詳しくは「What’s new in Kubernetes 1.12」の記事と、Jobsのドキュメントをご覧ください。

#2307 Podを長引かせないジョブトラッキング

ステージ：ベータへ移行

機能グループ: apps

機能ゲート： JobTrackingWithFinalizers Default value: true

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

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

#2599 StatefulsetsにminReadySecondsを追加

ステージ：ベータへ移行

機能グループ: apps

機能ゲート： StatefulSetMinReadySeconds Default value: true

この機能拡張は、Deployments、DaemonSets、ReplicasSets、およびReplication Controllersで既に利用可能なオプションのminReadySecondsフィールドをStatefulSetsにもたらします。

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

Kubernetes 1.23におけるインスツルメンテーション

#2845 Kubernetesコンポーネントにおけるklog固有のフラグの非推奨化

ステージ：アルファへ移行

機能グループ：インスツルメンテーション

機能ゲート：NA

この変更の背景には、Kubernetesが誕生した当初、ロギングにglogライブラリを使用するという決定がありました。その後、より柔軟なソリューションが必要になったため、このライブラリはフォークされ、現在使用されているklogになりました。現在は、さらなる柔軟性が必要とされているため、以下のような新機能のためにライブラリを準備するために、いくつかのクリーンアップを行う時期になりました：

パフォーマンスの向上
Kubernetesのスケーラビリティ要件を満たす
不要になったglogの機能を削除する

#1602 構造化ロギング

ステージ：ベータへ移行

機能グループ:：インスツルメンテーション

機能ゲート：NA

このエンハンスメントは、Kubernetesのログメッセージの標準的な構造を定義しています：

E1025 00:15:15.525108       1 controller_utils.go:114] "Failed to update pod status" err="timeout"

詳しくは「What’s new in Kubernetes 1.19? 」の記事、またはKubernetesのドキュメントをご覧ください。

Kubernetes 1.23におけるネットワーク

#563 IPv4/IPv6デュアルスタックサポートの追加

ステージ：ステーブルへ移行

機能グループ: ネットワーク

機能ゲート：IPv6DualStack Default value: true

この機能は、クラスター内でデュアルスタックモードをネイティブにサポートするために行われた作業をまとめたもので、指定されたポッドにIPv4とIPv6の両方のアドレスを割り当てることができます。

1.20のリリースについては、What’s new in Kubernetesシリーズで詳しくご紹介しています。

#2365 ネームスペースにスコープされたIngressクラスのパラメータ

ステージ：ステーブルへ移行

機能グループ: ネットワーク

機能ゲート：IngressClassNamespacedParams Default value: true

この機能強化により、Namespaceスコープを持つIngressClassのパラメータを指定できるようになりました。

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

#2433 トポロジーを意識したヒント

ステージ：ベータへ移行

機能グループ: ネットワーク

機能ゲート： TopologyAwareHints Default value: true

Kubernetes 1.21リリースの記事でも紹介しましたが、#2433 Topology Aware Hintsの機能拡張は、Kubernetes 1.17で導入されたServiceTopologyの機能ゲートを置き換えるものです。

Kubernetes 1.23におけるノード

#2371 cAdvisor-less, CRI-full Container と Pod stats

ステージ：アルファへ移行

機能グループ: ノード

機能ゲート： PodAndContainerStatsFromCRI Default value: false

この機能強化は、実行中のコンテナとポッドに関するすべての統計情報をContainer Runtime Interface（CRI）から取得するための取り組みをまとめたもので、cAdvisorからの依存関係を取り除きます。

現在、summary APIおよび/metrics/cadvisorエンドポイントによって提供されるメトリクスは、主にcAdvidorによって収集され、CRIによって完成されます。2 つのソースを持つことで、明確性が失われ、努力が重複します。

CRIを改良して、必要なメトリクスをすべて提供することにしました。これ以上 cAdvisor を使用しない理由のいくつかは以下の通りです。

cAdvisor は、基礎となるコンテナ・ランタイムを認識する必要があります。これは、fully-pluggableなコンテナランタイムを実現するという CRI の目標を無効にします
コンテナのランタイムは、コンテナの動作について cAdvisor よりもよく知っています
cAdvisor は、仮想マシンのような一部のランタイムをサポートしません
cAdvisor は Windows コンテナをサポートしません

実装の詳細については、KEP をご覧ください。

#2712 PriorityClassValueBasedGracefulShutdown

ステージ：アルファへ移行

機能グループ: ノード

機能ゲート： GracefulNodeShutdownBasedOnPodPriority Default value: false

今後は、ノートのグレースフルシャットダウン時に、優先度の高いポッドに対して停止までの時間を長くすることができます。

GracefulSutdown（#2000）の機能強化により、Kubeletはシャットダウン時にノードで動作しているPodを円満に終了させようとします。

この機能拡張により、ポッドの優先クラスの値に応じて、ポッドの停止時間が異なる可能性が追加されます：

shutdownGracePeriodByPodPriority:
  - priority: 100000
    shutdownGracePeriodSeconds: 10
  - priority: 10000
    shutdownGracePeriodSeconds: 180
  - priority: 1000
    shutdownGracePeriodSeconds: 120
  - priority: 0
    shutdownGracePeriodSeconds: 60

優先度が100001のPodは10秒、優先度が1001のPodは120秒で停止することになります。

#2727 PodにgRPCプローブを追加

ステージ：アルファへ移行

機能グループ: ノード

機能ゲート：GRPCContainerProbe Default value: false

この機能拡張により、ポッドにgRPC（HTTP/2 over TLS）のlivenessプローブを設定できるようになりました。

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

今回、既存のHTTPとTCPのオプションに加えて、gRPCプロトコルを使用するプローブを設定できるようになります。

readinessProbe:
      grpc:
        port: 9090
        service: my-service
      initialDelaySeconds: 5
      periodSeconds: 10

#2902 CPUManagerのポリシーオプションでCPUをNUMAノードに分散させる

ステージ：アルファへ移行

機能グループ: ノード

機能ゲート： CPUManagerPolicyExperimentalOptions Default value: false

この機能拡張では、新しいCPUManagerポリシーオプションとしてdistribute-cpus-across-numaが追加され、CPUの割り当てがNUMAノードに均等に分散されるようになります。

この機能拡張は、「#2625 新しいCPUマネージャポリシー」を基にしています。

#2625 SMTに沿っていないワークロードを拒否するオプションの追加

ステージ：ベータへ移行

機能グループ: ノード

機能ゲート： CPUManagerPolicyOptions Default value: false

この機能拡張により、CPU マネージャーは特定の CPU コアに排他的なワークロードを割り当てることができます。CPUコアごとにワークロードを分離することで、コンテキストやキャッシュの切り替えを回避でき、これはレイテンシーに敏感なアプリケーションにとって非常に重要です。

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

#277 エフェメラルコンテナ

ステージ：ベータへ移行

機能グループ: ノード

機能ゲート： EphemeralContainers Default value: true

エフェメラルコンテナは、実行中のポッドをデバッグするのに最適な方法です。作成後のポッドに通常のコンテナを追加することはできませんが、kubectl debugでエフェメラルコンテナを実行することができます。

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

#2040 KubeletのCRIサポート

ステージ：ベータへ移行

機能グループ: ノード

機能ゲート：NA

コンテナ・ランタイム・インターフェース（CRI）は、Kubeletが再コンパイルすることなく、さまざまなコンテナ・ランタイムを使用できるようにするプラグインインターフェースです。これには、CRI-OやcontainerdのようなDockerの代替品も含まれます。

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

#2403 podresources APIを拡張して割り当て可能なリソースをレポートする

ステージベータ版へ移行中

機能グループ: ノード

機能ゲート：KubeletPodResourcesGetAllocatable Default value: true

kubelet pod resources エンドポイント (pod resources API) へのこの追加により、サードパーティのコンシューマーは Pod に割り当てられたコンピュートリソースについて知ることができます。その結果、ノードのキャパシティを評価することが容易になります。

詳しくは、「Kubernetes 1.21 – What’s new?」

Kubernetes 1.23におけるスケジューリング

#785 スケジューラコンポーネントのconfig APIをv1beta3へ、そして、v1beta1を非推奨とする

ステージ：ベータへ移行

機能グループ：スケジューリング

機能ゲート：NA

ComponentConfigは、コンポーネントの設定をよりダイナミックにし、Kubernetes APIから直接アクセスできるようにするための継続的な取り組みです。

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

このバージョンでは、いくつかのプラグインが削除されました：

NodeResourcesLeastAllocated
NodeResourcesMostAllocated
RequestedToCapacityRatio
NodeLabel
ServiceAffinity
NodePreferAvoidPods

また、スケジューリングポリシーはサポートされていないので、代わりにScheduler Configurationを使用する必要があります。

詳しくはこちらのドキュメントPRをご覧ください。

#2891 スケジューラーのマルチポイントプラグイン設定の簡略化

ステージ：ベータへ移行

機能グループ: スケジューリング

機能ゲート： NA

この機能拡張は、複数の拡張ポイントのプラグインを同時に登録できるようにすることで、スケジューラープラグインの設定を簡素化します。

つまり、次のように書く代わりに：

apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: non-multipoint-scheduler
    plugins:
      preScore:
        enabled:
        - name: MyPlugin
      score:
        enabled:
        - name: MyPlugin
      preFilter:
        enabled:
        - name: MyPlugin
      filter:
        enabled:
        - name: MyPlugin

preScore、score、preFilter、filterをmultiPointに置き換えることができます。

apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: MyPlugin

#2926 サスペンドしたジョブのノードアフィニティ制約の更新を許可する

ステージ：ベータへ移行

機能グループ: スケジューリング

機能ゲート： JobMutableNodeSchedulingDirectives Default value: true

この機能強化は、Kubernetes 1.21の「#2232 Stopped Job」をベースにしており、ジョブを一時停止するための.spec.suspendフィールドが追加されています。

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

Kubernetes 1.23におけるストレージ

#1790 リサイズの失敗からの復旧

ステージ：アルファへ移行

機能グループ: ストレージ

機能ゲート： RecoverVolumeExpansionFailure Default value: false

現在、Persistent Volume Claim（PVC）を基礎となるストレージプロバイダーがサポートしていないサイズに拡張した場合、エラーが発生し、修正するのが容易ではない状況になっています。

この問題を解決するため、今回の機能拡張では、ユーザーがPVCのサイズを縮小できるようになりました。また、システムを悪用から守るために、いくつかの対策を施しました。

サイズの縮小（pvc.Status.AllocatedResourcesに反映）は、以前の拡張要求が失敗した場合にのみ行われます。
新しい要求サイズは、pvc.Status.Capacityよりも大きくなければなりません。
有効な割り当て量は、pvc.Status.Capacityとpvc.Status.AllocatedResourcesのうち大きい方です。

#2644 リクレームポリシーを常に尊重する

ステージ：アルファへ移行

機能グループ：ストレージ

機能ゲート： HonorPVReclaimPolicy Default value: false

この機能拡張により、一部のバインドされた永続的ボリューム（PV）と永続的ボリュームクレーム（PVC）のペアで、PV-PVC削除の順序によってPV削除の再要求ポリシーが尊重されるかどうかが決まるという問題が修正されます。

大まかには、Bound PVを削除すると次のようになります：

PVにdeletionTimestampが追加され、更新のトリガーとなります。
PVCが削除される前にこの更新が処理された場合、削除は無視されます。

この処理がどのように機能するかの詳細な説明と、修正に関する実装の詳細については、KEPを確認してください。

#2317 KubeletではなくCSI DriverにFSGroupを委ねる

ステージ：アルファへ移行

機能グループ：ストレージ

機能ゲート：DelegateFSGroupToCSIDriver Default value: false

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

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

#2589 Portworx file in-treeからCSIドライバへ移行

ステージ：アルファへ移行

機能グループ:：ストレージ

機能ゲート： CSIMigrationPortworx Default value: false

Portworx Container Storage Interface (CSI)ドライバのすべてのプラグイン操作は、アウトオブツリーの　’pxd.portworx.com’ ドライバーにリダイレクトされるようになりました。

この機能強化は、CSIドライバをKubernetesの外に移行する(in-treeからout-of-treeに移行する)大きな取り組みの一部です(#178, #625, #1490, #1491を参照)。

#2923 Ceph RBD in-treeプロビジョナーからCSIドライバーへ移行

ステージは：アルファへ移行

機能グループ:：ストレージ

機能ゲート： CSIMigrationRBD Default value: false

RBD Container Storage Interface (CSI)ドライバーのすべてのプラグイン操作は、アウトオブツリーの ‘rbd.csi.ceph.com’ ドライバーにリダイレクトされるようになりました。

この機能強化は、CSIドライバをKubernetesの外に移行する(in-treeからout-of-treeに移行する)大きな取り組みの一部です(#178, #625, #1490, #1491を参照)。

#1487 AWS EBS in-treeからCSIドライバーへ移行

ステージ：ステーブルへ移行

機能グループ: ストレージ

機能ゲート：CSIMigrationAWS Default value: false

AWS EBS Container Storage Interface (CSI) ドライバーのすべてのプラグイン操作は、アウトオブツリーの ‘ebs.csi.aws.com’ ドライバーにリダイレクトされるようになりました。

この機能強化は、CSI ドライバーを Kubernetes の外に移行する (in-tree から out-of-tree に移行する) 大きな取り組みの一部です(#178, #625, #1490, #1491を参照)。

#695 非再帰的ボリュームオーナーシップ (FSGroup)

ステージ：ステーブルへ移行

機能グループ: ストレージ

機能ゲート： ConfigurableFSGroupPolicy Default value: true

ボリュームがコンテナ内にバインドマウントされる前に、そのボリュームのすべてのファイルパーミッションが、指定された fsGroup 値に変更されます。これは、非常に大きなボリュームの場合には処理が遅くなり、また、データベースのようなパーミッションに敏感なアプリケーションも壊れてしまいます。

Kubernetes 1.18で導入されたFSGroupChangePolicyフィールドは、この動作を変更することができます。Always に設定すると、現在の動作が維持されます。しかし、OnRootMismatchに設定すると、トップレベルのディレクトリが期待されるfsGroupの値と一致しない場合にのみ、ボリュームのパーミッションを変更します。

#1682 CSIドライバーオブジェクトにFSグループポリシーを設定する

ステージ：ステーブルへ移行

機能グループ: ストレージ

機能ゲート：CSIVolumeFSGroupPolicy Default value: true

すべてのボリュームが、NFSのように、前の機能拡張（#695）で言及されたfsGroup操作をサポートするわけではありません。このため、ユーザーにエラーが報告されることがあります。

今回の改善では、CSIDriver.Spec.SupportsFSGroupという新しいフィールドが追加され、ドライバーがfsGroupによるボリュームオーナーシップの変更をサポートするかどうかを定義できるようになりました。

詳しくは、「Kubernetes 1.19 – What’s new?」

#1698 汎用インラインエフェメラルボリューム

ステージ：ステーブルへ移行

機能グループ: ストレージ

機能ゲート： GenericEphemeralVolume Default value: true

この機能拡張は、ダイナミックプロビジョニングをサポートするあらゆるストレージドライバーで動作するインラインエフェメラルボリュームを定義するためのシンプルなAPIを提供します。

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

Kubernetes 1.23におけるWindowsサポート

#2802 APIサーバーアドミッション時にPodのOSを識別する

ステージ：アルファへ移行

機能グループ： Windows

機能ゲート： IdentifyPodOS Default value: false

この機能強化により、PodSpecにOSフィールドが追加され、ポッドが実行されるべきOSを定義できるようになりました。

これにより、Kubernetesは以下のようなコンテキストを持つことになります：

kubeletで実装されたノードで実行すべきでないPodを拒否する
スケジューラで実装される、適切なノードでのポッドのスケジューリング
適切なセキュリティ制約を適用する（アドミッションプラグインで実装）

#1981 Windows 特権コンテナのサポート

ステージ：ベータへ移行

機能グループ:：Windows

機能ゲート： WindowsHostProcessContainers Default value: true

この機能拡張は、Linux で利用可能な特権コンテナ機能を Windows ホストにもたらします。

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

詳しくは、「Kubernetes 1.22 – What’s new?」

その他

#1440 kubectl events

ステージ：アルファへ移行

機能グループ:：cli

機能ゲート： NA

現在のkubectl get eventsの機能を強化する新しいkubectl eventsコマンドが利用できます。

現在のkubectl get eventsコマンドに機能を追加する必要があります。しかし、それを拡張するにはいくつかの課題があり、結局のところ、いかなる変更もkubectl getコマンド全体に影響を与えます。

新しいkubectl eventsコマンドは、イベントを扱うことに特化したエクスペリエンスを提供します。この最初のバージョンでは、kubectl get eventsコマンドの現在の機能をすべてサポートすることに加えて、kubectl get events –watchがイベントを適切にソートしない問題を解決しています。

#2915 kubeadm: レガシー kubelet-config-x.y ネーミングの置き換え

ステージ：アルファへ移行

機能グループ： cluster-lifecycle

機能ゲート： UnversionedKubeletConfigMap Default value: false

この機能拡張により、kubelet-config-x.y ConfigMapsおよびRBACルールの名前の付け方が変更され、-x.yバージョンの参照が削除されました(例: -1.23)。

この変更の理由：

x.y バージョニングリファレンスはコントロールプレーンから取得していますが、kubelet から取得した方がより意味があります
アップグレードの際、新しいConfigMapとRBACルールは新しいバージョニングで作成されますが、古いものは削除されません

kube-system/kubelet-configを真実のソースとして維持し、このバージョニングがもたらす複雑さを取り除くことが目標です。

#2702 HPA APIをGAに移行

ステージ：ステーブルへ移行

機能グループ：autoscaling

機能ゲート： NA

Horizontal Pod Autoscaler（HPA）APIのv2は、2016年11月に登場しました。5年前！かなり安定していますが、公式にそう言えるようになるまでには、いくつかのマイナーな問題があります。

このエンハンスメントでは、このAPIをゴールまで持っていくために、以下のような作業をまとめています：

エンドツーエンドのテストを完了する
古いバージョンのAPIを非推奨とする
コンテナリソースのターゲット：Resourceの名前をPodResourceに変更しました
値「Disabled」を「ScalingDisabled」にリネーム
ビヘイビアの名称変更：ビヘイビアセレクトポリシーの値がMinからMinChange、MaxからMaxChangeに変更されました。

HPAに興味のある方は、こちらの「PrometheusのメトリクスでKubernetes HPAをトリガーする」の記事をご覧ください。

#1933 静的解析によるロギングシークレットの防御

ステージ：ステーブルへ移行

機能グループ：セキュリティ

機能ゲート： NA

#1753の準備中に行われた静的解析により、機密データが使用されている場所についての洞察が得られます。

詳しくは、「Kubernetes 1.20 – What’s new?」

#2420 Kubernetesのビルドメンテナンスを軽減

ステージ：ステーブルへ移行

機能グループ：テスト

機能ゲート：NA

この機能強化は、すべてのビルドスクリプトをmake buildに移行し、bazel buildを削除するために行われた作業をまとめたものです。

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

#2464 kubetest2 CIマイグレーション

ステージ：ベータへ移行

機能グループ:：テスト

機能ゲート： NA

この機能強化は、エンドツーエンドテストを起動・実行するためのインターフェイスである kubetest のすべての使用方法を kubetest2 に更新するために行われたすべての作業をまとめたものです。また、シナリオと呼ばれる一連のスクリプトの更新も含まれており、一般的なユースケースの実行に使用されます。

#2579 PodSecurity アドミッション(PodSecurityPolicyの置き換え)

ステージ：ベータへ移行

機能グループ:：auth

機能ゲート： PodSecurity Default value: true

Kubernetes 1.21で非推奨となったPod Security Policiesの代わりに、新しいPodSecurityアドミッションコントローラがデフォルトで有効になりました。

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

以上、Kubernetes 1.23についてご紹介しました。これらの機能のいずれかを使用するつもりであれば、クラスターのアップグレードの準備をしてください。

もしこの記事が気に入ったら、以前の「Kubernetesの新機能」もチェックしてみてください。

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

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

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