本文の内容は、2024年4月15日に NIGEL DOUGLAS が投稿したブログ（https://sysdig.com/blog/whats-new-in-kubernetes-1-30/)を元に日本語に翻訳・再構成した内容となっております。
Kubernetes 1.30 が間もなく登場します。これには新鮮でエキサイティングな機能が満載です。では、この今後のリリースにおいて何が新しくなったのでしょうか？
Kubernetes 1.30 では、58 の新機能と改良された機能の組み合わせを含む、多数の機能強化が行われています。これらの中から、個々のコンテナのメトリクスに焦点を当てて horizontal Pod Autoscaler の機能を改良する、待望のContainer Resource Based Pod Autoscalerなど、いくつかの機能がステーブル版に段階的に移行しています。新しいアルファ機能もデビューしており、クラスター内でリソースを管理および割り当てる方法に革命をもたらすことが期待されています。
以前に実装されたダイナミックリソースアロケーションをより構造化されたわかりやすいアプローチで強化する、ダイナミックリソースアロケーションの構造化パラメーターの実装などの大きな変更に注意してください。これにより、Kubernetes コンポーネントはより多くの情報に基づいた決定を下せるようになり、サードパーティドライバーへの依存が軽減されます。
セキュリティをさらに強化するために、ポッドのユーザーネームスペースのサポートがベータ版に移行し、ユーザーネームスペースをサポートすることで脆弱性に対する洗練された分離と保護が提供され、ポッドのセキュリティを強化するカスタマイズされた UID/GID 範囲が可能になります。
また、ポッド リソース管理やネットワーク ポリシーの更新など、Kubernetes をよりユーザー フレンドリーで効率的にする傾向を継続する数多くの QOL の改善も行われています。
私たちはこのリリースに向けて興奮しています。解説すべき内容がたくさんあるので、Kubernetes 1.30 が提供する機能をさらに詳しく見てみましょう。
Kubernetes 1.30 – 編集者のおすすめ
このリリースで最も魅力的に見える機能は次のとおりです。
この機能強化では最も重要な見直しが行われ、Linux ノード上のスワップ メモリの動作を変更してメモリ使用量とシステム パフォーマンスをより適切に管理することにより、システムの安定性が向上します。Kubernetes は、スワップメモリの処理方法を最適化することで、さまざまな負荷条件下でアプリケーションをよりスムーズに動作させることができるため、システムクラッシュが減少し、全体的な信頼性が向上します。
Nigel Douglas – Sr. Open Source Security Advocate (Falco Security))
この機能強化はベータ版にも適用され、複数の Webhook やリクエスト検証のきめ細かな制御などの拡張機能を備えた認証チェーンの作成を合理化し、すべて構造化されたファイルを通じて構成されます。この機能により、複雑な構成と正確な認証メカニズムが可能になるため、セキュリティと管理効率が大幅に向上し、管理者がクラスタ全体でポリシー準拠を強制することが容易になります。
Mike Coleman –Staff Developer Advocate – Open Source Ecosystem
アドミッション コントロール用の Common Expression Language (CEL) の統合により、Kubernetes API を通じて直接、複雑で詳細なポリシーを適用する動的な方法が導入され、セキュリティとガバナンスの両方の機能が強化されます。この改善により、管理者はより微妙なポリシーを作成できるだけでなく、展開の進化するニーズに対応できるようになり、大規模な手動更新を必要とせずに、セキュリティ対策が変更に確実に対応できるようになります。
Thomas Labarussias –Sr. Developer Advocate & CNCF Ambassador
クラウド セキュリティでは、時間は最も貴重な通貨です。攻撃はわずか 10 分で評判を傷つける可能性があります。そのため、コンテナと Kubernetes の使用を拡大する際のセキュリティ戦略の指針となる包括的なチェックリストを作成しました。
Kubernetes Security Checklistの日本語版を読む 英語版を読む
Kubernetes 1.30におけるApps
#4443 Job PodFailurePolicyにおける詳細なフェイル理由
Stage: Net New to Alpha
Feature group: sig-apps
一般的な「PodFailurePolicy」の理由をジョブのフェイル条件に割り当てる現在のアプローチは、具体性を高めるために強化される可能性があります。これを実現する 1 つの方法は、カスタマイズ可能な Reason フィールドを PodFailurePolicyRule に追加することです。これにより、文字制限に従って、ルール トリガーごとに機械で可読できる個別の理由を許可できるようになります。この方法は、明確さのために推奨されており、特に特定のコンテナ終了コードに関連付けることにより、ジョブを利用する高レベルの API が障害により正確に応答できるようになります。
#3017 PodDisruptionBudgetのPodHealthyPolicy
Stage: Graduating to Stable
Feature group: sig-apps
Pod Disruption Budgets (PDB) は、主に 2 つの理由で利用されます。1 つは自発的な中断を制限することで可用性を維持するため、もう 1 つは重要なデータのレプリケーションが完了するまで eviction を回避することでデータ損失を防ぐためです。ただし、現在の PDB システムには制限があります。場合によっては、ノードのドレインや自動スケーリングを妨げる可能性があり、異常なポッドの削除を妨げることがあります。
さらに、データの安全性を目的とした PDB の使用は完全に信頼できるものではなく、API の誤用とみなされる可能性があります。これらの問題にもかかわらず、Kubernetes はこのユースケースに対する代替ソリューションを提供していないため、データ保護における PDB への依存度は非常に大きいため、PDB への変更は引き続きこの要件をサポートする必要があります。目標は、PDB を改良して、不健全なポッドによる eviction のブロックを回避し、データの安全性を確保する役割を維持することです。
#3998 Jobの成功/完了ポリシー
Stage: Net New to Alpha
Feature group: sig-apps
この Kubernetes 1.30 の機能強化では、特にインデックス付きジョブに対してジョブ API の拡張機能が提供され、事前定義された条件に基づいてジョブが成功したと宣言できるようになります。この変更は、MPI や PyTorch を使用するバッチ ワークロードなど、すべてのインデックスではなく特定の「リーダー」インデックスの完了によって成功が決まる、特定のバッチ ワークロードのニーズに対応します。
現在、ジョブは、すべてのインデックスが成功した場合にのみ完了としてマークされますが、これは一部のアプリケーションでは制限されています。Kubeflow Training Operator、Flux Operator、JobSet などのサードパーティフレームワークにすでに実装されている Successポリシーを導入することで、Kubernetes はさらなる柔軟性を提供することを目指しています。この機能強化により、ジョブが Successポリシーで指定された基準を満たした場合、システムは残りのポッドを終了できるようになります。
Kubernetes 1.30 における CLI
#4292 kubectl デバッグにおけるカスタムプロファイル
Stage: Net New to Alpha
Feature group: sig-cli
このマージされた機能強化により、kubectl debug に -custom フラグが追加され、ユーザーがデバッグ リソースをカスタマイズできるようになります。’kubectl debug’ 機能の強化により、運用チームのセキュリティ体制が大幅に改善される予定です。
これまで、ベースイメージにシェルが存在しないため、リアルタイム デバッグに課題が生じ、一部のチームはこれらの安全で最小限のコンテナを使用することを思いとどまりました。デバッグ コンテナ内にデータ ボリュームを接続できるようになったことで、エンドユーザーはセキュリティを損なうことなく詳細な分析とトラブルシューティングを実行できるようになりました。
この機能により、デバッグプロセスが簡素化され、シェルレスのベース イメージの使用がさらに魅力的になることが期待されます。
#2590 kubectl にサブリソースのサポートを追加
Stage: Graduating to Stable
Feature group: sig-cli
このプロポーザルでは、kubectl コマンドの get、patch、edit、replace に新しい –subresource=[subresource-name] フラグが実装されています。
この機能強化により、ユーザーは、ビルトイン リソースとカスタムリソース定義 (CRD) の両方を含む、互換性のあるすべての API リソースのサブリソースにアクセスしてステータスを変更し、スケールできるようになります。ステータス サブリソースの出力は、メイン リソースと同様にフォーマットされたテーブルで表示されます。
この機能は完全なリソースと同じ API 規則に従っており、コントローラーによる予期された調整動作が可能になります。ただし、指定されたサブリソースのないリソースでフラグが使用された場合は、「NotFound」エラー メッセージが返されます。
#3895 kubectl delete コマンドに対話型フラグを追加
Stage: Graduating to Stable
Feature group: sig-cli
このプロポーザルでは、重要なリソースの誤った削除に対するクラスター管理者の安全対策を強化するために、kubectl delete コマンドの対話モードを導入することを提案しています。
kubectl delete コマンドは強力かつ永続的であるため、タイプミスや性急な決定などのエラーによって予期せぬ結果が生じるリスクがあります。下位互換性の問題によりデフォルトの動作を変更することなく、このような事故の可能性に対処するために、プロポーザルでは新しい対話型 (-i) フラグを推奨しています。
このフラグは、削除を実行する前にユーザーに確認を促し、追加の保護層と意思決定の機会を提供して、重要なリソースが誤って削除されることを防ぎます。
インストゥルメンテイション
#647 API サーバートレース
Stage: Graduating to Stable
Feature group: sig-instrumentation
この Kubernetes 1.30 の機能強化は、構造化された詳細なトレース データに OpenTelemetry ライブラリを利用して、API サーバーでのトレースを強化することでデバッグの改善を目的としています。分散トレースを有効にすることで分析を容易にし、リクエストとコンテキストの伝播についての包括的な洞察を可能にします。
このプロポーザルでは、リクエストのトレース データを生成およびエクスポートするとともに、受信リクエストと送信リクエストの間でコンテキストを伝播することで、デバッグ機能を強化し、アドミッション Webhook などのプラグインがトレース データに貢献してリクエスト パスをより深く理解できるようにするという目標が概説されています。
#2305メトリクスカーディナリティの強制
Stage: Graduating to Stable
Feature group: sig-instrumentation
この機能強化では、 メトリクスラベル値に対して動的で実行時に構成可能なホワイトリストを実装することにより、計測されたコンポーネントでメモリの問題を引き起こす無制限のメトリクスディメンションの問題に対処します。
歴史的に、Kubernetes コミュニティは、問題のあるラベルやメトリクスを完全に削除したり、許容可能な値の遡及的なセットを定義したりするなど、一貫性のないさまざまなアプローチを通じて問題のあるメトリクスに対処してきました。これらの修正は手動で行われ、労力と時間がかかり、標準化されたソリューションがありません。
この機能強化は、コードのリリースとは関係なくメトリクスディメンションを事前定義された値のセットにバインドできるようにすることでこの問題を解決し、バイナリの即時リリースを必要とせずにプロセスを合理化し、メモリリークを防止することを目的としています。
#3077コンテキストログ
Stage: Graduating to Beta
Feature group: sig-instrumentation
このコンテキストログのプロポーザルでは、グローバル ロガーの使用から、context.Context 経由または直接関数を介して logr.Logger インスタンスを渡すように移行し、構造化ログの利点を活用します。このメソッドを使用すると、呼び出し元はキーと値のペアでログ メッセージを強化し、ログ コンポーネントまたは操作を示す名前を指定し、呼び出し先によって生成されるログの量を制御するために冗長性を調整できます。
主な利点は、必要な詳細がロガーインスタンス自体の中にカプセル化されているため、呼び出し先に追加の情報を供給する必要なくこれが実現されることです。
さらに、client-go などの Kubernetes パッケージを利用するサードパーティコンポーネントが klog ロギング フレームワークにテザリングされることから解放され、任意の logr.Logger 実装を採用し、好みに合わせて構成できるようになります。単体テストの場合、このモデルによりテストケースごとのログ出力の分離が容易になり、トレーサビリティと分析が強化されます。
主な目標は、klog の直接 API 呼び出しとパッケージ全体での強制的な実装を排除し、関数呼び出し元にロギングコントロールを提供し、パブリック API への影響を最小限に抑えながら、ロギングを単体テストに統合するためのガイダンスとツールを提供することです。
Kubernetes 1.30 におけるネットワーク
#3458 KCCMのサービスコントローラーから一時的なノード条件を削除
Stage: Graduating to Stable
Feature group: sig-network
サービスの性急な切断を軽減し、クラウドプロバイダーの API への負荷を最小限に抑えるために、新しいプロポーザルでは、Kubernetes クラウドコントローラーマネージャー (KCCM) がロードバランサーノード セットと対話する方法の変更を提案しています。
この機能強化は、ノードが一時的に準備ができなくなったり、ノードが終了されたりした場合に、即時ノードを削除する習慣を中止することを目的としています。代わりに、StableLoadBalancerNodeSet 機能ゲートを導入することで、接続ドレインを有効にすることでよりスムーズな移行が促進され、アプリケーションが正常なシャットダウンの恩恵を受けられるようになり、不必要なロードバランサーの再同期が削減されます。この変更は、クラウド プロバイダーシステムに過度の負担をかけることなく、アプリケーションの信頼性を高めることを目的としています。
#3836 Kube-Proxy の Ingress 接続の信頼性の向上
Stage: Graduating to Beta
Feature group: sig-network
この Kubernetes 1.30 の機能強化では、Kubernetes クラウドコントローラーマネージャーのサービスコントローラーに変更が実装されており、特にロードバランサーによって使用されるヘルスチェック (HC) を対象としています。これらの変更は、これらのチェックが Kubernetes によって管理されるサービスプロキシである kube-proxy と対話する方法を改善することを目的としています。主な改善点は 3 つあります。
1) kube-proxy が、ノードが削除対象としてマークされているときにヘルスチェックに失敗することにより、終端ノードでのコネクションドレインをサポートできるようにします。これは、クラスターのダウンサイジングシナリオ中に特に役立ちます。
2) 従来のヘルスチェックセマンティクスを維持する新しい /livez ヘルスチェックパスを kube-proxy に実装し、ノード終了時にサービスが中断されないようにします。
3) Kubernetes の公式 Web サイトの包括的なガイドを通じて、クラウドプロバイダー全体で標準化されたヘルスチェック手順を提唱します。
これらのアップデートは、サービスの正常なシャットダウンを保証し、特に終了のマークが付けられたノードを介してルーティングされるサービスに関して、クラウドプロバイダーと Kubernetes クラスターの全体的な統合を改善することを目指しています。
#1860 Kubernetes に LoadBalancer の動作を認識させる
Stage: Graduating to Beta
Feature group: sig-network
この機能強化は、LoadBalancer サービスの外部 IP を処理するための kube-proxy 構成の変更です。現在、ipvs や iptables を含む kube-proxy 実装は、ロード バランサーをバイパスしてサービスに直接最適なトラフィックルーティングを行うために、外部 IP を各ノードに自動的にバインドします。このプロセスは、一部のシナリオでは有益ですが、Scaleway や Tencent Cloud などの特定のクラウドプロバイダーにとっては問題が発生します。このようなバインドにより、ロードバランサーからの受信トラフィック、特にヘルスチェックが中断されます。
さらに、TLS 終端やロード バランサーレベルで実装された PROXY プロトコルなどの機能がバイパスされ、プロトコル エラーが発生します。この機能強化では、このバインディング動作をクラウドコントローラーレベルで構成可能にし、クラウドプロバイダーがインフラストラクチャーやサービスの機能に合わせてこのデフォルト設定を無効にしたり調整したりできるようにすることで、これらの問題に対処し、現在の回避策よりも堅牢なソリューションを提供できる可能性があることを提案しています。
Kubernetes 1.30 ノード
#3960 PreStop hookのスリープ アクションの実装
Stage: Graduating to Beta
Feature group: sig-node
この Kubernetes 1.30 の機能強化では、PreStop ライフサイクル Hookに ’スリープ’ アクションが実装され、コンテナのシャットダウンを管理するためのよりシンプルなネイティブオプションが提供されます。
終了を遅らせるためにスクリプトやカスタムソリューションに依存する代わりに、コンテナはこの組み込みのスリープを使用して操作を適切にラップし、ロードバランシングの移行を容易にし、外部システムの調整を可能にすることで、Kubernetes アプリケーションの信頼性と稼働時間を向上させることができます。
#2400ノードメモリスワップのサポート
Stage: Major Change to Beta
Feature group: sig-node
この機能強化により、スワップメモリのサポートが Kubernetes に統合され、パフォーマンスチューニングのためのノード管理者と、アプリのスワップを必要とするアプリケーション開発者の 2 つの主要なユーザー グループに対応します。
焦点は、ノード レベルでのスワップの使用コントロールを容易にすることであり、kubelet により Kubernetes ワークロードが特定の構成でスワップ スペースを利用できるようになります。最終的な目標は、スワップを使用して Linux ノードの運用を強化し、管理者がワークロードのスワップ使用量を決定できるようにすることです。当初は、個々のワークロードが独自のスワップ制限を設定することは許可されていませんでした。
#24 AppArmor のサポート
Stage: Graduating to Stable
Feature group: sig-node
AppArmor サポートを Kubernetes に追加すると、コンテナ化されたワークロードのセキュリティポスチャーが大幅に強化されます。AppArmor は、システム管理者が特定のアプリケーションまたはコンテナーに添付されたプロファイルを使用してプログラムの特定の機能を制限できるようにする Linux カーネル モジュールです。AppArmor を Kubernetes に統合することで、開発者はアプリ構成内で直接セキュリティ ポリシーを定義できるようになりました。
この機能の初期実装では、Kubernetes API 内で個々のコンテナまたはポッド全体に対して AppArmor プロファイルを指定できるようになります。このプロファイルは、定義されるとコンテナランタイムによって強制され、コンテナのアクションがプロファイルで定義されたルールに従って制限されるようになります。この機能は、侵害されたコンテナが他のワークロードや基盤となるホストに影響を与える可能性があるマルチテナント環境で、安全で制限されたアプリケーションを実行するために非常に重要です。
スケジューリング
#3633PodAffinity と PodAntiAffinity にMatchLabelKeysを実装
Stage: Graduating to Beta
Feature group: sig-scheduling
この Kubernetes 1.30 の機能強化では、PodAffinity と PodAntiAffinity を改良するために PodAffinityTerm の MatchLabelKeys が実装され、ローリングアップグレードなどのシナリオ中に ポッド の配置をより正確にコントロールできるようになります。
ユーザーが ポッド の共存を評価する範囲を指定できるようにすることで、特に飽和状態またはアイドル状態のクラスターで、新しいバージョンと古いバージョンの ポッド が同時に存在する場合に発生するスケジューリングの課題に対処します。この機能強化は、スケジューリングの効率とクラスター リソースの使用率を向上させることを目的としています。
#3902 NodeLifecycleController から TaintManager を切り離す
Stage: Graduating to Stable
Feature group: sig-scheduling
この機能強化により、NodeLifecycleController の役割が 2 つのコントローラに分離されました。現在、NodeLifecycleController は、健全でないノードに NoExecute の taint を付けることと、taintを付けられたノードからポッドをenvict することの両方を担当しています。
この提案では、特に NoExecute taint に基づいてポッドの envict を管理するための専用の TaintEvictionController が実装されていますが、NodeLifecycleController は引き続き不健全なノードに taint を適用することに重点を置きます。この分離の目的は、コードベースを合理化し、より直接的な機能強化とカスタムエビクション戦略の潜在的な開発を可能にすることです。
この変更の背後にある動機は、絡み合った機能を解きほぐし、ノードの健全性とポッドのエビクションプロセスを処理する際のシステムの保守性と柔軟性を向上させることです。
#3838ゲートされた場合の可変 Pod スケジューリングディレクティブ
Stage: Graduating to Stable
Feature group: sig-scheduling
#3521で実装された機能強化であるPodSchedulingReadiness は、拡張スケジューラーや動的クォータマネージャーなどの外部リソースコントローラーに、kube スケジューラーによるスケジューリングに対するポッドの適格性の最適なタイミングを決定できるようにすることを目的としています。
この基盤に基づいて、現在の拡張機能は、そのような更新によってポッドのスケジューリングオプションがさらに制限されるという条件の下で、ポッドのスケジューリング ディレクティブ、特にノードセレクターとノードアフィニティの変更可能性を許可することで柔軟性を拡張しようとしています。この機能により、外部リソースコントローラーはスケジュールのタイミングを決定するだけでなく、クラスター内のポッドの特定の配置にも影響を与えることができます。
このアプローチは、Kubernetes スケジューリングの新しいパターンを促進し、カスタムスケジューラーバイナリを維持する必要なく、kube スケジューラーのコア機能を補完する軽量な機能固有のスケジューラーの開発を促進します。このパターンは、カスタムスケジューラープラグインを必要とせずに実装できる機能に特に有利であり、Kubernetes エコシステム内のスケジューリング機能を強化する合理的な方法を提供します。
Kubernetes 1.30 ストレージ
#3141ボリューム復元時に不正なボリュームモード変換を防止する
Stage: Graduating to Stable
Feature group: sig-storage
この機能強化は、ボリュームスナップショットからの Persistent VolumeClaim (PVC) の作成中にボリュームモードでの不正な変更に対する保護手段を実装することにより、Kubernetes の VolumeSnapshot 機能の潜在的なセキュリティギャップに対処します。
これは、PVC の元のボリュームモードが確実に保持され、カーネルの脆弱性による悪用を防止しながら、効率化のためにボリュームモードの変換が必要となる可能性のある正当なバックアップおよび復元プロセスに対応するためのメカニズムの概要を示しています。このアプローチは、有効なバックアップと復元のワークフローを妨げることなくセキュリティを強化することを目的としています。
#1710再帰的な SELinux ラベル変更を高速化する
Stage: Net New to Beta
Feature group: sig-storage
この機能強化では、SELinux と Kubernetes の統合の改善が詳しく説明されており、SELinux が強制モードになっている Linux システム上で実行されているコンテナのセキュリティ対策の強化に重点が置かれています。この提案では、SELinux が各コンテナに一意の SELinux コンテキストを割り当て、それに応じてボリュームの内容にラベルを付けることで、エスケープされたコンテナユーザーがホスト OS リソースや他のコンテナにアクセスするのを防ぐ方法について概説しました。
この提案では、Kubernetes が SELinux コンテキストを処理する方法を改良することも目指しており、PodSpec 経由で SELinux コンテキストを手動で設定するか、コンテナランタイムに自動的に割り当てるオプションを提供します。主な進歩には、最初のマウント時に -o context= オプションを使用して特定の SELinux コンテキストでボリュームをマウントし、正しいセキュリティラベルを確実に付ける機能や、どのボリュームプラグインが SELinux をサポートしているかを認識する機能が含まれます。
これらの変更の背後にある動機には、大規模なファイルの再ラベル付けを回避することによるパフォーマンスの向上、ほぼフルのボリュームでのスペースの問題の防止、特に読み取り専用ボリュームと共有ボリュームのセキュリティの強化が含まれます。このアプローチは、特にCVE-2021-25741のような潜在的なセキュリティ違反からコンテナ化された環境を保護する際に、Kubernetes デプロイ全体での SELinux ポリシーの適用を合理化することを目的としています。
#3756 kubelet 再起動後の堅牢な VolumeManager の再構成
Stage: Graduating to Stable
Feature group: sig-storage
この機能強化は、再起動後の kubelet のマウントされたボリュームの処理に関する問題に対処します。現在、kubelet は実行中の Pod のボリュームを追跡できず、API サーバーとホスト OS からこの状態を再構成しようとします (このプロセスには欠陥があることが知られています)。
これは、このプロセスの再作業、つまり kubelet の機能の重要な部分に影響を与える実質的なバグ修正を提案しています。これらの変更は範囲が広いため、機能ゲートの背後で実装され、ユーザーは必要に応じて古いシステムに戻すことができます。この取り組みは、以前 v1.26 でアルファ版となった KEP 1790で築かれた基盤に基づいて構築されています。
この変更は、kubelet が起動時にボリュームが以前にどのようにマウントされたかをよりよく理解し、変更が必要かどうかを評価できるようにする方法を強化することを目的としています。さらに、kubelet の再起動後にボリュームが適切にクリーンアップされないというバグ#105536で文書化されているような問題に対処し、ボリューム管理とクリーンアップの全体的な堅牢性を向上させます。
その他の機能強化
#1610コンテナリソースベースのポッド自動スケーリング
Stage: Graduating to Stable
Feature group: sig-autoscaling
この機能強化では、水平ポッドオートスケーラー (HPA) 機能の強化の概要を説明し、特にポッド内の個々のコンテナの使用状況メトリクスに基づいてリソースをスケーリングできるようにします。現在、HPA はすべてのコンテナのリソース消費量を集計しますが、リソース使用量が均一に拡大されないコンテナを使用する複雑なワークロードには理想的ではない可能性があります。
提案された変更により、HPA は各コンテナのリソース需要を個別に評価することで、より正確に拡張できるようになります。
#2799シークレットベースのサービスアカウントトークンの削減
Stage: Graduating to Stable
Feature group: sig-auth
この改善により、Kubernetes 1.22 での BoundServiceAccountTokenVolume の一般提供に続いて、安全性の低いシークレットベースのサービスアカウント トークンへの依存を最小限に抑えるための対策の概要が示されています。この機能を使用すると、サービスアカウントトークンが TokenRequest API 経由で取得され、確保されるボリュームに保存されるため、シークレットベースのトークンの自動生成が不要になります。
これは、ユーザーが明示的に要求したトークンを保持しながら、これらのトークンの自動生成を停止し、未使用のものを削除することを目的としています。推奨されるアプローチには、サービスアカウントコントロールループを変更してトークンの自動作成を防止すること、TokenRequest API または手動で作成されたトークンの使用を促進すること、未使用の自動生成トークンのパージプロセスを実装することが含まれます。
#4008 CRDバリデーション・ラチェット
Stage: Graduating to Beta
Feature group: sig-api-machinery
このプロポーザルは、検証ロジックの “シフトレフト” を提唱し、可能な場合はコントローラーからフロントエンドに移動することで、Kubernetes の使いやすさを向上させることに重点を置いています。現在、カスタム リソース定義 (CRD) 内の変更されていないフィールドの検証を変更するプロセスは面倒で、検証の小さな変更であってもバージョンの増分が必要になることがよくあります。ユーザーのワークフローを中断するリスクが高いため、この複雑さにより、CRD 作成者と Kubernetes 開発者の両方による高度な検証機能の導入が妨げられています。このような制限はユーザーエクスペリエンスを低下させるだけでなく、Kubernetes 自体の進歩を妨げます。
たとえば、KEP-3937 は、既存のワークフローを混乱させる可能性がある、新しい形式タイプでの宣言的検証の導入を提案しています。この機能強化の目的は、CRD 作成者と Kubernetes が大きな混乱を引き起こすことなく、値の検証を拡大したり強化したりすることを妨げる障壁を取り除くことです。この提案は、機能が有効になっているクラスター内のすべての CRD に対してこれらの拡張機能を自動化し、最小限のオーバーヘッドでパフォーマンスを維持し、既知のスキーマに従って無効な値を防止することで正確性を確保することを目的としていました。
この記事が気に入った場合は、以前の「Kubernetes の新機能」エディションもチェックしてみてください。
- Kubernetes 1.27の新機能
- Kubernetes 1.26の新機能
- Kubernetes 1.25の新機能
- Kubernetes 1.24の新機能
- Kubernetes 1.23の新機能
- Kubernetes 1.22の新機能
- Kubernetes 1.21の新機能
- Kubernetes 1.20の新機能
- Kubernetes 1.19の新機能
- Kubernetes 1.18の新機能
- Kubernetes 1.17の新機能
- Kubernetes 1.16の新機能
- Kubernetes 1.15の新機能
- Kubernetes 1.14の新機能
- Kubernetes 1.13の新機能
- Kubernetes 1.12の新機能
Kubernetes プロジェクトに参加してください。
- プロジェクトのホームページにアクセスしてください。
- GitHub で Kubernetes プロジェクトを確認してください。
- Kubernetes コミュニティに参加してください。
- Kubernetes Slack でメンテナに会いましょう。
- Twitter で @KubernetesIO をフォローしてください。
また、Kubernetes エコシステムの最新情報を知りたい場合は、クラウドネイティブ エコシステムで起こっている最も興味深い情報を月次メールで配信するコンテナ ニュースレターを購読してください。