本文の内容は、2021年11月30日にVíctor Jiménez Cerradaが投稿したブログ(https://sysdig.com/blog/kubernetes-1-23-whats-new/)を元に日本語に翻訳・再構成した内容となっております。
Kubernetes 1.23のリリースが間近に迫っており、斬新な要素が満載です どこから始めましょうか?
このバージョンに含まれる新機能は、一般的に小さいものですが、非常に歓迎されています。例えば、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ドライバーに委ねることで、新しいプラットフォームへの対応が容易になります。これには、Portworx、Ceph RBD、AWS EBSなどのサービスだけでなく、Windowsなどの新しいOSも含まれます。
David de Torres - Manager of engineer at Sysdig
#1440 kubectl events
新しいkubectl eventsは、イベントには独自のワークフローがあり、kubectl get eventsコマンドだけでは不十分であるという事実に対応しています。これは、Kubernetesチームがいかにクラスター管理者の生活を楽にするかを常に考えていることを示している。
#1790 リサイズの失敗からの復旧
すべてのユーザー、特にKubernetesを新たに導入するユーザーにとって、生活をより快適にしてくれるもう一つのツールです。PVCのサイズ変更に失敗したような一般的なエラーから簡単に回復できる機会があることで、Kubernetesを使用する際のフラストレーションが軽減されます。
#2896 OpenAPI V3 + #2887 OpenAPI Enum Types
OpenAPI v3の拡張サポートは、Kubernetes APIに依存しているツールに新鮮な空気をもたらします。Enum型のサポートや適切な検証など、小さいながらも超越した内容が追加されます。UIでは、これらのフィールドにドロップダウンを表示できるようになります。小さなことですが、これこそが、技術的な知識を持たない人たちにも採用されるきっかけになるでしょう。
#2727 PodにgRPCプローブを追加
Kubernetesでは、サイト・リライアビリティ・エンジニアがサービスの可用性を高めるためにプローブを使用しています。普及が進んでいるプロトコルであるgRPCをサポートするプローブを追加することで、開発者は新しいクラウドネイティブアプリケーションの開発を簡素化し、耐障害性を向上させる強力なツールを手に入れることができます。
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 に置き換えました)。
#2845 Kubernetesコンポーネントにおけるklog固有のフラグの非推奨化
ステージ :非推奨
機能グループ: instrumentation
機能ゲート: NA
この変更の背景には、Kubernetesが誕生した当初、ロギングにglogライブラリを使用するという決定がありました。その後、より柔軟なソリューションが必要になったため、このライブラリはフォークされ、現在使用されているklogになりました。現在は、さらなる柔軟性が必要とされているため、以下のような新機能向けのライブラリを準備するために、いくつかのクリーンアップを行う時期になりました。
#785 Schedulerコンポーネントのconfig APIをv1beta3にし、v1beta1を非推奨にする
ステージ :ベータへ移行
機能グループ: スケジューリング
機能ゲート: NA
ComponentConfigは、コンポーネントの設定をよりダイナミックにし、Kubernetes APIから直接アクセスできるようにするための継続的な取り組みです。
このバージョンでは、いくつかのプラグインが削除されました:
Kubernetes 1.23 におけるAPI
#2876 CRD Validation Expression Language
ステージ :アルファへ移行
機能グループ::api-machinery
機能ゲート: CustomResourceValidationExpressions Default value: false
この機能拡張では、Webhooksに基づいた既存の検証メカニズムを補完するために、Custom Resource Definitions (CRD)の検証メカニズムを実装します。
検証手順をCRD自体に含めることで、2つの主な利点が生まれます:
...
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よりも大きいため。
#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.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クラスター内で定期的なタスクを実行します。
ステージ: ステーブルへ移行
機能グループ: apps
機能ゲート:TTLAfterFinished Default value: true
この機能は、FinishedやCompleteのジョブを自動的にクリーンアップします。これらのジョブは通常、システム内では不要であり、それらを維持することでAPIサーバーの負荷が増大するため、これは便利です。
ttlSecondsAfterFinishedフィールドを設定することで、コントローラがこれらをクリーンアップすることができるようになりました。
#2307 Podを長引かせないジョブトラッキング
ステージ :ベータへ移行
機能グループ: apps
機能ゲート: JobTrackingWithFinalizers Default value: true
この機能強化により、ジョブは完了したポッドを早期に削除できるようになり、クラスター内のリソースを解放できるようになります。
#2599 StatefulsetsにminReadySecondsを追加
ステージ: ベータへ移行
機能グループ: apps
機能ゲート: StatefulSetMinReadySeconds Default value: true
この機能拡張は、Deployments、DaemonSets、ReplicasSets、およびReplication Controllersで既に利用可能なオプションのminReadySecondsフィールドをStatefulSetsにもたらします。
Kubernetes 1.23におけるインスツルメンテーション
#2845 Kubernetesコンポーネントにおけるklog固有のフラグの非推奨化
ステージ: アルファへ移行
機能グループ:インスツルメンテーション
機能ゲート:NA
この変更の背景には、Kubernetesが誕生した当初、ロギングにglogライブラリを使用するという決定がありました。その後、より柔軟なソリューションが必要になったため、このライブラリはフォークされ、現在使用されているklogになりました。現在は、さらなる柔軟性が必要とされているため、以下のような新機能のためにライブラリを準備するために、いくつかのクリーンアップを行う時期になりました:
ステージ :ベータへ移行
機能グループ::インスツルメンテーション
機能ゲート:NA
このエンハンスメントは、Kubernetesのログメッセージの標準的な構造を定義しています:
E1025 00:15:15.525108 1 controller_utils.go:114] "Failed to update pod status" err="timeout"
Kubernetes 1.23におけるネットワーク
#563 IPv4/IPv6デュアルスタックサポートの追加
ステージ :ステーブルへ移行
機能グループ: ネットワーク
機能ゲート:IPv6DualStack Default value: true
この機能は、クラスター内でデュアルスタックモードをネイティブにサポートするために行われた作業をまとめたもので、指定されたポッドにIPv4とIPv6の両方のアドレスを割り当てることができます。
#2365 ネームスペースにスコープされたIngressクラスのパラメータ
ステージ :ステーブルへ移行
機能グループ: ネットワーク
機能ゲート:IngressClassNamespacedParams Default value: true
この機能強化により、Namespaceスコープを持つIngressClassのパラメータを指定できるようになりました。
#2433 トポロジーを意識したヒント
ステージ :ベータへ移行
機能グループ: ネットワーク
機能ゲート: TopologyAwareHints Default value: true
Kubernetes 1.23におけるノード
#2371 cAdvisor-less, CRI-full Container と Pod stats
ステージ :アルファへ移行
機能グループ: ノード
機能ゲート: PodAndContainerStatsFromCRI Default value: false
現在、summary APIおよび/metrics/cadvisorエンドポイントによって提供されるメトリクスは、主にcAdvidorによって収集され、CRIによって完成されます。2 つのソースを持つことで、明確性が失われ、努力が重複します。
CRIを改良して、必要なメトリクスをすべて提供することにしました。これ以上 cAdvisor を使用しない理由のいくつかは以下の通りです。
-
cAdvisor は、基礎となるコンテナ・ランタイムを認識する必要があります。これは、fully-pluggableなコンテナランタイムを実現するという CRI の目標を無効にします
-
コンテナのランタイムは、コンテナの動作について cAdvisor よりもよく知っています
-
cAdvisor は、仮想マシンのような一部のランタイムをサポートしません
-
cAdvisor は Windows コンテナをサポートしません
#2712 PriorityClassValueBasedGracefulShutdown
ステージ :アルファへ移行
機能グループ: ノード
機能ゲート: GracefulNodeShutdownBasedOnPodPriority Default value: false
今後は、ノートのグレースフルシャットダウン時に、優先度の高いポッドに対して停止までの時間を長くすることができます。
この機能拡張により、ポッドの優先クラスの値に応じて、ポッドの停止時間が異なる可能性が追加されます:
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プローブを設定できるようになりました。
今回、既存の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コアごとにワークロードを分離することで、コンテキストやキャッシュの切り替えを回避でき、これはレイテンシーに敏感なアプリケーションにとって非常に重要です。
#277 エフェメラルコンテナ
ステージ :ベータへ移行
機能グループ: ノード
機能ゲート: EphemeralContainers Default value: true
エフェメラルコンテナは、実行中のポッドをデバッグするのに最適な方法です。作成後のポッドに通常のコンテナを追加することはできませんが、kubectl debugでエフェメラルコンテナを実行することができます。
#2040 KubeletのCRIサポート
ステージ:ベータへ移行
機能グループ: ノード
機能ゲート:NA
コンテナ・ランタイム・インターフェース(CRI)は、Kubeletが再コンパイルすることなく、さまざまなコンテナ・ランタイムを使用できるようにするプラグインインターフェースです。これには、CRI-OやcontainerdのようなDockerの代替品も含まれます。
#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から直接アクセスできるようにするための継続的な取り組みです。
このバージョンでは、いくつかのプラグインが削除されました:
#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.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を削除すると次のようになります:
この処理がどのように機能するかの詳細な説明と、修正に関する実装の詳細については、
KEPを確認してください。
#2317 KubeletではなくCSI DriverにFSGroupを委ねる
ステージ:アルファへ移行
機能グループ:ストレージ
機能ゲート:DelegateFSGroupToCSIDriver Default value: false
この機能拡張は、CSIドライバーにポッドのfsgroupを明示的なフィールドとして提供することを提案しています。これにより、マウント時にCSIドライバーがこれをネイティブに適用することができます。
#2589 Portworx file in-treeからCSIドライバへ移行
ステージ: アルファへ移行
機能グループ::ストレージ
機能ゲート: CSIMigrationPortworx Default value: false
この機能強化は、CSIドライバをKubernetesの外に移行する(in-treeからout-of-treeに移行する)大きな取り組みの一部です(
#178,
#625,
#1490,
#1491を参照)。
#2923 Ceph RBD in-treeプロビジョナーからCSIドライバーへ移行
ステージは:アルファへ移行
機能グループ::ストレージ
機能ゲート: CSIMigrationRBD Default value: false
この機能強化は、CSIドライバをKubernetesの外に移行する(in-treeからout-of-treeに移行する)大きな取り組みの一部です(
#178,
#625,
#1490,
#1491を参照)。
#1487 AWS EBS in-treeからCSIドライバーへ移行
ステージ:ステーブルへ移行
機能グループ: ストレージ
機能ゲート:CSIMigrationAWS Default value: false
この機能強化は、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によるボリュームオーナーシップの変更をサポートするかどうかを定義できるようになりました。
#1698 汎用インラインエフェメラルボリューム
ステージ:ステーブルへ移行
機能グループ: ストレージ
機能ゲート: GenericEphemeralVolume Default value: true
この機能拡張は、ダイナミックプロビジョニングをサポートするあらゆるストレージドライバーで動作するインラインエフェメラルボリュームを定義するためのシンプルなAPIを提供します。
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 ホストにもたらします。
特権コンテナは、ホスト上で直接実行されているかのように、ホストにアクセスできます。ほとんどのワークロードでは推奨されませんが、管理、セキュリティ、監視などの目的では非常に便利です。
その他
#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)。
この変更の理由:
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に変更されました。
#1933 静的解析によるロギングシークレットの防御
ステージ:ステーブルへ 移行
機能グループ: セキュリティ
機能ゲート: NA
#1753の準備中に行われた静的解析により、機密データが使用されている場所についての洞察が得られます。
#2420 Kubernetesのビルドメンテナンスを軽減
ステージ :ステーブルへ移行
機能グループ:テスト
機能ゲート:NA
この機能強化は、すべてのビルドスクリプトをmake buildに移行し、bazel buildを削除するために行われた作業をまとめたものです。
#2464 kubetest2 CIマイグレーション
ステージ: ベータへ移行
機能グループ::テスト
機能ゲート: NA
この機能強化は、エンドツーエンドテストを起動・実行するためのインターフェイスである kubetest のすべての使用方法を kubetest2 に更新するために行われたすべての作業をまとめたものです。また、
シナリオと呼ばれる一連のスクリプトの更新も含まれており、一般的なユースケースの実行に使用されます。
#2579 PodSecurity アドミッション(PodSecurityPolicyの置き換え)
ステージ :ベータへ移行
機能グループ::auth
機能ゲート: PodSecurity Default value: true
以上、Kubernetes 1.23についてご紹介しました。これらの機能のいずれかを使用するつもりであれば、クラスターのアップグレードの準備をしてください。
もしこの記事が気に入ったら、以前の「Kubernetesの新機能」もチェックしてみてください。
Kubernetesのコミュニティに参加してみませんか?
Sysdigに関するお問い合わせはこちらから