Kubernetes 1.25における新機能は?

本文の内容は、2022年8月16日にDaniel Simionatoが投稿したブログ(https://sysdig.com/blog/kubernetes-1-25-whats-new/)を元に日本語に翻訳・再構成した内容となっております。<br /><br /><strong>Kubernetes 1.25</strong>がリリースされようとしています。どこから始めましょうか？<br /><br />今回のリリースでは、<a href="https://sysdig.jp/blog/kubernetes-1-24-whats-new/">Kubernetes 1.24の46</a>、<a href="https://sysdig.jp/blog/kubernetes-1-23-whats-new/">Kubernetes 1.23の45</a>と同レベルの40の機能強化が行われました。この40の機能強化のうち、13はStableへ移行、10は改善を続ける既存機能、15は完全な新規機能、そして2つは非推奨の機能となっています。<br /><br />このリリースのハイライトは、<a href="https://sysdig.jp/blog/kubernetes-1-25-whats-new/#5">PodSecurityPoliciesが最終的に削除され</a>、<a href="https://sysdig.com/blog/kubernetes-1-25-whats-new/#2579">PodSecurity admission</a>に置き換えられ、最終的にStableへの移行が行われることです。このバージョンでは、すべての非推奨と削除に注意してください！<br /><br />ユーザーネームスペースのサポート、フォレンジック分析のためのチェックポイント、ボリュームマウント時のSELinuxの改善、NodeExpansion シークレット、公式CVEフィードの改善など、本当に歓迎すべき新しいセキュリティ機能がいくつか追加されています。また、他の機能はクラスター管理者の生活を楽にします。例えば、復帰不可能なPodフェイル、KMS v2の改善、よりクリーンなIPTablesチェーンの所有、PVC上のStorageClassデフォルトのより良い処理などです。<br /><br />最後に、このリリースの<strong>ケーキの上のトッピング</strong>は、GAステートに到達しているすべての素晴らしい機能です。CSI の移行は、3 年以上続いてきたプロセスであり、ついに最終段階に入ったということで大きな賞賛を浴びています。また、NetworkPolicies のポートレンジ、Ephemeral ボリューム、そして Cgroups v2 のサポートです。<br /><br />話すことがたくさんあるので、Kubernetes 1.25の最新情報をはじめましょう。<br /><br /><h2>Kubernetes 1.25 - エディターズピック:</h2>今回のリリースで最もエキサイティングに見える機能は、以下の通りです（<span class="ILfuVd" lang="ja"><span class="hgKElc">人によって違うかもしれません</span></span>）:<br /><br /><h3>#127 ユーザーネームスペースのサポート追加</h3>この機能強化は、約6年前に初めてKubernetesに要求されたものです。Kubernetes 1.5で<span>alpha</span>版をターゲットにしていました。この機能を実装するために必要な技術は、しばらく前から存在していました。そしてついに、少なくとも<span>alpha</span>版ではありますが、ここに登場しました。<br /><br />Kubernetesのユーザーネームスペースは、ワークロードに課される制約の多くを緩和するのに役立ち、この機能がなければとても安全ではないと考えられている機能を使用できるようになります。願わくば、これによって攻撃者の生活がより困難なものになることも期待しています。<br /><br /><em>Miguel Hernández – Security Content Engineer at Sysdig</em><br /><br /><h3>#2008 フォレンジック・コンテナ・チェックポインティング</h3>コンテナチェックポインティングは、特定のコンテナからスナップショットを作成し、そのコピーに対して分析や調査を行うことができるようにします。潜在的な攻撃者に通知することなく、コンテナが破壊される前にキャプチャーすることができれば、これはコンテナのフォレンジック分析にとって素晴らしいツールとなるでしょう。<br /><br />これは、Kubernetesのフォレンジックを永遠に変えるだけでなく、Kubernetesのセキュリティとインシデントレスポンスを提供するすべてのツールを変えることになるでしょう。<br /><br /><em>Javier Martínez – DevOps Content Engineer at Sysdig</em><br /><br /><h3>#3329 ジョブに対するRetriableおよびNon-RetriableのPodフェイル</h3>これはKubernetesのJobsに必要な改善点です。現在、ジョブがフェイルし、そのrestartPolicyが<span> </span><code>OnFailure</code>に設定されている場合、Kubernetesは最大のバックオフ制限まで、そのジョブの再実行を試みます。しかし、フェイルの原因がアプリケーションのエラーであり、それ自体では修正されない場合、これは意味を成しません。<br /><br />今回の機能強化により、フェイルの原因別にポリシーを設定できるようになることで、フェイルすることが決まっているものを無駄に実行することなく、Kubernetesをより効率的に利用できるようになります。また、ジョブが pod <span>eviction</span>に対してより信頼できるようになり、リソースに制約のあるクラスターにおいて管理者が調査しなければならないフェイルしたジョブの数を劇的に減らすことができるようになるのです。<br /><br /><em><a rel="noopener nofollow noreferrer" target="_blank" href="https://twitter.com/weseven">Daniel Simionato</a><span> </span>– Security Content Engineer at Sysdig</em><br /><br /><h3>#625 CSIマイグレーション - コア</h3>全く新しい機能ではありませんが、ストレージSIGはこのマイグレーションについて大きな賞賛を受けるに値します。彼らは<a href="https://sysdig.com/blog/whats-new-kubernetes-1-15/#625">3年以上にわたって</a>KubernetesコアからCSIドライバーを精力的に移行しており、私たちはリリースに次ぐリリースで彼らのアップデートを追ってきました。そして今、ようやく移行が終わりに近づきました。<br /><br />長期的には、Kubernetesのコードがよりメンテナンスしやすくなり、ストレージ周りの機能がよりクールになることを意味します。次に何が出てくるか、楽しみですね。<br /><br /><em><a rel="noopener nofollow noreferrer" target="_blank" href="https://twitter.com/capitangolo">Víctor Jiménez Cerrada</a><span> </span>– Content Manager Engineer at Sysdig</em><br /><br /><h3>#3299 KMS v2 の改善</h3>この機能強化により、暗号化キーの管理が容易になり、手作業が少なくなります。同時に、暗号鍵のオペレーションも高速化されます。このようなセキュリティの改善は、私たちが望むところです。セキュリティの向上、パフォーマンスの改善、そして管理者の負担軽減です。<br /><br /><em>Devid Dokash – DevOps Content Engineer at Sysdig</em><br /><br /><h3>#5 PodSecurityPolicy + #2579 Pod Security Control</h3>PodSecurityPolicyは、特別で最後の言及に値すると私は思います。おそらくKubernetesのエコシステムで最も誤解されているコンポーネントの1つでしたが、ついにそれがなくなりました。<br /><br />上流のプロジェクト、この場合はKubernetesの変更は、Red Hat OpenShiftのような他のKubernetesディストリビューションにも影響することを忘れてはなりません。そのため、新しい<span> </span>admission controller Pod Security Control の進め方を説明するアップデートを公開していますが、おそらく複数のエンジニアに頭痛の種がもたらされることでしょう。<br /><br />PSP、ありがとうございました。<br /><br /><em><a rel="noopener nofollow noreferrer" target="_blank" href="https://twitter.com/vjjmiras">Vicente J. Jiménez Miras</a><span> </span>– Security Content Engineer at Sysdig</em><br /><br /><br /><h2>非推奨事項</h2><h3>APIと機能の削除</h3>Kubernetes 1.25では、以下のようないくつかのBeta APIと機能が削除されました。<br /><br /><ul><li>提供されなくなった非推奨<a href="https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-25">APIバージョン</a>（より新しいもの）:<ul><li>CronJob<span> </span><code>batch/v1beta1</code></li><li>EndpointSlice<span> </span><code>discovery.k8s.io/v1beta1</code></li><li>Event<span> </span><code>events.k8s.io/v1beta1</code></li><li>HorizontalPodAutoscaler<span> </span><code>autoscaling/v2beta1</code></li><li>PodDisruptionBudget<span> </span><code>policy/v1beta1</code></li><li>PodSecurityPolicy<span> </span><code>policy/v1beta1</code></li><li>RuntimeClass<span> </span><code>node.k8s.io/v1beta1</code></li></ul></li><li>その他のAPIの変更:<ul><li><code>k8s.io/component-base</code><span> </span>は、<span> </span><code>k8s.io/component-base/logs/api/v1</code><span> </span>（ログ設定用のGo API）へ移動しました。</li></ul></li><li>その他の変更点:<ul><li>1.21 から非推奨のBeta版 <span> </span><code>PodSecurityPolicy</code><span> admission </span>プラグインは削除されました。</li><li>いくつかのインツリーボリュームプラグインのサポートが削除されました。<ul><li><a rel="noopener nofollow noreferrer" target="_blank" href="https://github.com/kubernetes/enhancements/issues/3446">GlusterFS</a></li><li><a rel="noopener nofollow noreferrer" target="_blank" href="https://github.com/kubernetes/kubernetes/pull/111618">flocker</a></li><li><a rel="noopener nofollow noreferrer" target="_blank" href="https://github.com/kubernetes/kubernetes/pull/111619">quobyte</a></li><li><a rel="noopener nofollow noreferrer" target="_blank" href="https://github.com/kubernetes/kubernetes/pull/111620">storageos</a></li></ul></li></ul></li><li><span> </span><code>kubectl run</code><span> </span>コマンドから<a href="https://github.com/kubernetes/kubernetes/pull/110668">未使用のフラグを削除</a>しました。</li><li>エンドツーエンドのテストが <a href="https://github.com/kubernetes/kubernetes/pull/109111">Ginkgo v1 から v2</a> に移行されました。</li><li><code>Ginkgo.Measure</code><span> </span>は<a href="https://github.com/kubernetes/kubernetes/pull/111065">非推奨になりました</a>。代わりに <span> </span><code>gomega/gmeasure</code><span> </span>を使ってください。</li><li>いくつかのapiserverメトリクスが<a href="https://github.com/kubernetes/kubernetes/pull/110104">変更されました</a>。</li><li>APIサーバーの <span> </span><code>--service-account-api-audiences</code><span> </span>フラグを非推奨とし、代わりに <span> </span><code>--api-audiences</code>を採用しました。</li><li><a href="https://github.com/kubernetes/kubernetes/pull/109819">seccompのアノテーションを一部</a>削除しました。</li><li>コマンドラインフラグ <span> </span><code>enable-taint-manager</code>を非推奨としました。</li><li>最近再び実装された<a rel="noopener nofollow noreferrer" target="_blank" href="https://github.com/kubernetes/kubernetes/pull/109706">schedulability predicate</a>を削除しました。</li><li>Kube-scheduler <span> </span><code>ComponentConfig</code><span> </span> v1beta2 を非推奨としました。</li><li>kubeletは、cAdvisorを介したアクセラレータメトリクスの収集を<a href="https://github.com/kubernetes/kubernetes/pull/110940">サポートしなくなりました</a>。</li></ul><br />変更点の全リストは、<a href="https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.md">Kubernetes 1.25のリリースノート</a>で確認することができます。また、<a href="https://kubernetes.io/blog/2022/08/04/upcoming-changes-in-kubernetes-1-25/">Kubernetes Removals and Deprecations In 1.25</a> の記事、および<a href="https://kubernetes.io/docs/reference/using-api/deprecation-guide/">非推奨のAPI移行ガイド</a>を今後のために近くに置いておくことをお勧めします。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/5">#5</a> PodSecurityPolicy</h3><strong>Stage:</strong> 非推奨<br /><strong>Feature group:</strong> auth<br /><br /><a href="https://sysdig.com/blog/psp-in-production/">Pod Security Policies (PSP) は、デプロイを制限するための素晴らしいKubernetesネイティブツールで</a>す。例えば、実行をユーザーリストに制限したり、ネットワークやボリュームなどのリソースへのアクセスを制限したりできます。<br /><br /><img src="https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation.png" alt="PSP are being removed in Kubernetes 1.25" width="1930" height="978" class="img-lightbox aligncenter size-full wp-image-36586 u-no-shadow entered lazyloaded" data-lazy-srcset="https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation.png 1930w, https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation-350x177.png 350w, https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation-1170x593.png 1170w, https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation-768x389.png 768w, https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation-1536x778.png 1536w, https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation-175x89.png 175w, / 1w" data-lazy-sizes="(max-width: 1930px) 100vw, 1930px" data-lazy-src="https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation.png" data-ll-status="loaded" sizes="(max-width: 1930px) 100vw, 1930px" srcset="https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation.png 1930w, https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation-350x177.png 350w, https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation-1170x593.png 1170w, https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation-768x389.png 768w, https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation-1536x778.png 1536w, https://sysdig.com/wp-content/uploads/Kubernetes-1.21-01-psp-deprecation-175x89.png 175w, / 1w" /><br /><a href="https://sysdig.jp/blog/kubernetes-1-23-whats-new/#5">Kubernetes 1.23 - What's new?</a> の記事で取り上げたように、この機能は非推奨となり、#2579 PodSecurity admissionに置き換えられます。<a href="https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/">ビルトインのPodSecurity admissionプラグインに移行するには、こちらのガイド</a>をご確認ください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/3446">#3446</a> 利用可能なインツリードライバーからGlusterFSプラグインを非推奨にしました</h3><strong>Stage:</strong> 非推奨<br /><strong>Feature group:</strong> ストレージ<br /><br />#625 CSI migration - coreに続き、Kubernetesコア（in-tree）に含まれていたいくつかのCSIプラグインは、別プロジェクト（out-of-tree）に移行されます。この移行が進むにつれて、インツリーの対応するプラグインも非推奨となります。<br /><br />GlusterFS以外では、<a href="https://github.com/kubernetes/kubernetes/pull/111618">flocker</a>、<a href="https://github.com/kubernetes/kubernetes/pull/111619">quobyte</a>、<a href="https://github.com/kubernetes/kubernetes/pull/111620">storageos</a>のサポートも終了しています。<br /><br /><h2>Kubernetes 1.25におけるApps</h2><h3><a href="https://github.com/kubernetes/enhancements/issues/3329">#3329</a> ジョブのPod障害に対する復帰可能・不可能の設定</h3><strong>Stage:</strong> Alpha への新規追加<br /><strong>Feature group:</strong>apps<br /><strong>Feature gate:</strong><span> </span><code>JobBackoffPolicy</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br />現在、ジョブの再試行を制限するために利用できる唯一のオプションは<span> </span><code>.spec.backoffLimit</code>を使うことです。このフィールドはジョブの最大再試行回数を制限し、それ以降は失敗したとみなされます。<br /><br />しかし、これではコンテナの失敗の原因を特定することができません。もし回復不可能なエラーを示す既知の終了コードがあれば、失敗する運命にあるものを再実行するために計算時間を浪費する代わりに、そのジョブを失敗とマークすることが望ましいでしょう。一方、インフラストラクチャーのイベント（Podの先取り、メモリープレッシャーの回避、ノードの消耗など）によりコンテナが失敗した場合、<span> </span><code>backoffLimit</code>にカウントされることも好ましくありません。<br /><br />この機能拡張により、<a href="https://kubernetes.io/docs/concepts/workloads/controllers/job/">Jobs</a> の spec に<span> </span><code>.spec.backoffPolicy</code><span> </span> を設定し、失敗した場合に再試行するかどうかを決定できるようになりました。障害の原因によって異なる動作をさせることで、Kubernetesはインフラストラクチャー障害やアプリケーションエラーの場合にバックオフ時間の増加を避け、早期にジョブを終了させることができます。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/1591">#1591</a> DaemonSetsは、ワークロードの可用性を向上させるためにMaxSurgeをサポートする必要があります</h3><strong>Stage:</strong> Stableへの移行<br /><strong>Feature group:</strong> apps<br /><strong>Feature gate:</strong><span> </span><code>DaemonSetUpdateSurge</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br /><a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment">ローリングアップデート</a>を行う際に、<span> </span><code>ec.strategy.rollingUpdate.maxSurge</code><span> </span>フィールドで、古いPodを置き換えるために新しいPodをいくつ作成するか指定できるようになりました。<br /><br />詳しくは「<a href="https://sysdig.jp/blog/kubernetes-1-22-whats-new/">Kubernetes 1.22の最新情報</a>」の記事でご確認ください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/2599">#2599</a> StatefulsetsにminReadySecondsを追加しました</h3><strong>Stage:</strong> Stableへの移行<br /><strong>Feature group:</strong> apps<br /><strong>Feature gate:</strong><span> </span><code>StatefulSetMinReadySeconds<span> </span><strong>Default value:<span> </span></strong>true</code><br /><br />この機能強化により、<span> </span><code>Deployments</code><span>、 </span><code>DaemonSets</code><span>、 </span><code>ReplicasSets</code>、レプリケーションコントローラーですでに利用可能なオプションの<span> </span><code>minReadySeconds</code><span> </span>フィールドが<span> </span><code>StatefulSets</code><span> </span>に追加されます。<br /><br />詳しくは「<a href="https://sysdig.jp/blog/kubernetes-1-22-whats-new/">Kubernetes 1.22の最新情報</a>」の記事でご確認ください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/3140">#3140</a> CronJobのTimeZoneサポート</h3><strong>Stage:</strong> Betaへの移行<br /><strong>Feature group:</strong> apps<br /><strong>Feature gate:</strong><span> </span><code>CronJobTimeZone</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br />この機能は、<span> </span><code>CronJob</code><span> </span>リソースでタイムゾーンをサポートするという、遅れていたリクエストに対応するものです。これまで、<span> </span><code>CronJobs</code>によって作成されたジョブは、<span> </span><code>kube-controller-manager</code>のプロセスが基づいていたタイムゾーンと同じに設定されていました。<br /><br />詳しくは「<a href="https://sysdig.jp/blog/kubernetes-1-24-whats-new/#3140">Kubernetes 1.24の最新情報</a>」記事でご確認ください。<br /><br /><br /><h2>Kubernetes 1.25 Auth</h2><h3><a href="https://github.com/kubernetes/enhancements/issues/3299">#3299</a> KMS v2 の改善</h3><strong>Stage:</strong> Net Alpha への新規追加<br /><strong>Feature group:</strong> Auth<br /><strong>Feature gate:</strong><span> </span><code>KMSv2</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br />この新機能は、Key Management Systemのパフォーマンスとメンテナンス性を向上させることを目的としています。<br /><br />この機能拡張が対処する主な問題の1つは、オブジェクトごとに異なるDEK（Data Encryption Key）を管理しなければならないことによるパフォーマンスの低さです。特に、キャッシュを空にするkube-apiserverプロセスを再起動した後、すべてのシークレットをLISTする操作を行った場合に深刻です。解決策は、ローカルKEKを生成し、KMSのレート制限に当たるのを遅らせることです。<br /><br />現在、<a href="https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#rotating-a-decryption-key">キーをローテート</a>させるようなタスクは、各kube-apiserverインスタンスの複数回の再起動を伴います。これは、すべてのサーバーが新しいキーを使用して暗号化および復号化できるようにするために必要です。さらに、クラスター内のすべてのシークレットを無差別に再暗号化することは、クラスターを数秒間サービス停止させたり、古い鍵に依存させたりする、リソースを消費するタスクです。本機能により、最新の鍵の自動ローテーションが可能になります。<br /><br />また、この機能により、現時点ではリソースの暗号化・復号化によって行われるためクラウド環境ではコストのかかる観測可能性やヘルスチェック操作を向上させる機能が追加されます。<br /><br />クラスターのセキュリティ確保に少しでも貢献できる、とてもエキサイティングな変更です。<br /><br />詳しくはその<a href="https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements">KEP</a>から。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/2579">#2579</a> PodSecurity admission(PodSecurityPolicyの置き換え)</h3><strong>Stage:</strong> Stableへの移行<br /><strong>Feature group:</strong> auth<br /><strong>Feature gate:</strong><span> </span><code>PodSecurity</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br /><a href="https://sysdig.jp/blog/whats-new-kubernetes-1-21/">Kubernetes 1.21で非推奨となったPod Security Policies</a>に代わり、新しい<span> </span><a rel="noopener nofollow noreferrer" target="_blank" href="https://kubernetes.io/docs/concepts/security/pod-security-admission/">PodSecurity admission controller</a><span> </span>がデフォルトで有効化されるようになりました。<br /><br />詳細は<a href="https://sysdig.jp/blog/whats-new-kubernetes-1-21/">Kubernetes 1.22 - What's new?</a>の記事で、さらに詳しい情報は新しいチュートリアルをご覧ください。<br /><br /><ul><li><a href="https://kubernetes.io/docs/tutorials/security/cluster-level-pss/">クラスターレベルでPodのセキュリティ標準を適用する</a></li><li><a href="https://kubernetes.io/docs/tutorials/security/ns-level-pss/">ネームスペースレベルでPodセキュリティ標準を適用する</a></li></ul><br /><h2>Kubernetes 1.25におけるNetwork</h2><h3><a href="https://github.com/kubernetes/enhancements/issues/2593">#2593</a> 複数のClusterCIDR</h3><strong>Stage:</strong> Alphaへ移行<br /><strong>Feature group:</strong> Network<br /><strong>Feature gate:</strong><span> </span><code>ClusterCIDRConfig</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br />Kubernetesクラスターを作成した後のスケーリングは、本当に難しいものです。ネットワークがオーバーディメンションであれば、多くのIPアドレスを無駄にすることになります。逆に、クラスターをアンダーディメンションにすると、ある時点でクラスターを廃止して、より新しいクラスターを作成しなければならなくなります。<br /><br />今回の機能強化により、クラスター管理者はより柔軟な方法でネットワーク範囲（<code>PodCIDR</code><span> </span>セグメント）を追加してKubernetesクラスターを拡張することができるようになります。KEPでは、3つの明確なユーザーストーリーを定義しています。<br /><br /><ul><li>セグメントを使い果たし、クラスターをスケールアップすることになった場合に備えて、<strong>クラスターにさらにPod IPを追加する。</strong></li><li>将来のノードで割り当て可能な最大Pod数を2倍にするなど、<strong>より高いまたはより低い機能を持つノードを追加する。</strong></li><li><strong>不連続な範囲のプロビジョニング</strong>。ネットワークセグメントが均等に分配されておらず、新しいノードをデプロイするためにそれらの多くをグループ化する必要がある場合に便利です。</li></ul>新しいリソース <span> </span><code>ClusterCIDRConfig</code> を作成することで、ノードアロケータで CIDR セグメントを制御できるようになります。この設定は、すでにプロビジョニングされたクラスターに影響を与えたり、再設定したりしないことに注意してください。目標は、Kubernetesに含まれる<span> </span><code>NodeIPAM</code><span> </span>の機能を拡張することであり、変更することではありません。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/3178">#3178</a> IPTables チェーンの所有権をクリーンアップする</h3><strong>Stage:</strong> Alphaへ移行<br /><strong>Feature group:</strong> Network<br /><strong>Feature gate:</strong><span> </span><code>IPTablesOwnershipCleanup</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br />クリーンアップは常に、特にあなたのコードにおいて推奨されます。<span> </span><code>kubelet</code><span> </span>は歴史的に、<span> </span><code>dockershim</code><span> </span>や<span> </span><code>kube-proxy</code>などのコンポーネントをサポートするためにIPTablesにチェーンを作成してきました。<a href="https://sysdig.jp/blog/kubernetes-1-24-whats-new/#2221">Dockershimの削除</a>はKubernetesにおける大きな一歩でしたが、今はその背後を掃除する時期なのです。<br /><br /><code>kube-proxy</code><span> </span>はまた別の話です。<span> </span><code>kube-proxy</code><span> </span>が作成したチェーンは、その<span> </span><code>kube-proxy</code><span> </span>の所有物ではなく、<span> </span><code>kubelet</code>の所有物であると言えるでしょう。あるべきところにあるべきものを置き、kubeletが不要なリソースを作るのを止め、<span> </span><code>kube-proxy</code><span> </span>がそれらを自分で作るようにする時期が来たのです。<br /><br />機能的には大きな変化はありませんが、よりクリーンなクラスターを管理できるようになります。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/2079">#2079</a> NetworkPolicyのポート範囲</h3><strong>Stage:</strong> Stableへ移行<br /><strong>Feature group: </strong>Network<br /><strong>Feature gate:</strong><span> </span><code>NetworkPolicyEndPort</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br />この機能拡張により、NetworkPolicyのすべてのポートを範囲として定義できるようになります：<br /><pre class="prettyprint">spec:
  egress:
  - ports:
    - protocol: TCP
      port: 32000
      endPort: 32768</pre><br />詳細は<a href="https://sysdig.jp/blog/whats-new-kubernetes-1-21/">Kubernetes 1.21 - What's new?</a>をご覧ください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/3070">#3070</a> ダイナミックおよびスタティックなIP割り当てのためのサービスIPレンジの確保</h3><strong>Stage:</strong> Betaへ移行<br /><strong>Feature group:</strong> Network<br /><strong>Feature gate:</strong><span> </span><code>ServiceIPStaticSubrange</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br />この <span> </span><code>--service-cluster-ip-range</code><span> </span> フラグのアップデートにより、静的および動的な IP 割り当てを使用しているサービス間で IP が競合するリスクが低下し、同じタイプで後方互換性が保たれます。<br /><br />詳しくは、<a target="_blank" href="https://sysdig.jp/blog/kubernetes-1-24-whats-new/#3070" rel="noopener">What’s new in Kubernetes 1.24</a>をご覧ください。<br /><br /><br /><h2>Kubernetes 1.25 Nodes</h2><h3><a href="https://github.com/kubernetes/enhancements/issues/127">#127</a> ユーザーネームスペースのサポート追加</h3><strong>Stage:</strong> Alphaへ移行<br /><strong>Feature group:</strong> node<br /><strong>Feature gate:</strong><span> </span><code>UserNamespacesSupport</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br />非常に待ち望まれていた機能です。Podに与えられた過剰な特権のために、ホストが侵害される脆弱性はたくさんあります。<br /><br />ユーザーネームスペースは、以前からLinux Kernelでサポートされています。さまざまなコンテナランタイムを通じて、それらをテストすることが可能です。Kubernetesエコシステムに導入することで、新たな可能性が開けることは間違いありません。例えば、あまりにも要求レベルの高いコンテナに対して特権モードで動作していると思わせたり、コンテナイメージのサーフェイスアタックを軽減することなどは、多くの人にとってまだ課題のようです。<br /><br />最後に誰かが<span> </span><code>CAP_SYS_ADMIN</code><span> </span>機能を要求した時のことを覚えていますか？もしあなたが私たちのような人なら、それを与えることを躊躇したことでしょう。さて、今回の機能強化により、これらのパーミッションはPodでは利用できますが、ホストでは利用できなくなります。FUSEファイルシステムをマウントしたり、コンテナ内でVPNを起動したりするのが頭痛の種でなくなるのです。<br /><br />まだイメージできていないのであれば、もっとわかりやすい言葉で言いましょう。コンテナ内のプロセスは、2つのID（UID/GID）を持つことになります。1つはPodの内部で、もう1つは外部の、より有害な可能性を秘めたホスト上でです。<br /><br />もう使い始めたいですか？Feature gate <span> </span><code>UserNamespacesSupport<span> </span></code>を有効にし、Pod内部の<span> </span><code>spec.hostUsers</code><span> </span>の値を<code>false</code><span> </span>に設定します（<code>true</code><span> </span>またはunsetの場合は、現在のKubernetesと同様にホストユーザが使用されます）。ただし、この機能はまだ実運用には適していません。<br /><br />この機能の詳細については、<a href="https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/127-user-namespaces/README.md">KEP</a>に追加情報と、この機能がないことで影響を受けるCVEの網羅的なリストがあります。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/2008">#2008</a> フォレンジックコンテナチェックポインティング</h3><strong>Stage:</strong> Alpha へ移行<br /><strong>Feature group:</strong> node<br /><strong>Feature gate:</strong><span> </span><code>ContainerCheckpointRestore</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br />コンテナチェックポインティングは、実行中のコンテナのスナップショットを取ることを可能にします。<br /><br />このスナップショットは、フォレンジック調査を開始する別のノードに転送することができます。解析は影響を受けるコンテナのコピーで行われるため、オリジナルにアクセスできる攻撃者は、このような解析に気づくことはありません。<br /><br />この機能は、新しく導入されたCRI APIを使用しているため、kubeletはチェックポイントを作成するための1回限りの呼び出しを要求することができます。<br /><br />スナップショットの作成は <code>/checkpoint</code><span> </span>エンドポイント経由で要求され、 <span> </span><code>--root-dir</code> (デフォルトは <span> </span><code>/var/lib/kubelet/checkpoints</code>) の下に .tar 形式 (<span>i.e., </span><code>checkpoint-&lt;podFullName&gt;-&lt;containerName&gt;-&lt;timestamp&gt;.tar</code>) で格納されることになります。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/2831">#2831</a> Kubelet OpenTelemetry トレース</h3><strong>Stage:</strong> Alpha へ移行<br /><strong>Feature group:</strong> node<br /><strong>Feature gate:</strong><span> </span><code>KubeletTracing</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br /><a href="https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/647-apiserver-tracing">APIServer の KEP-647</a> と同様に、この機能拡張では、<span> </span><code>kubelet</code>で行われる GRPc コールに OpenTelemetry トレースが追加されます。<br /><br />これらのトレースにより、ノードレベル、たとえば、<code>kubelet</code><span> </span> とコンテナランタイム間の相互作用に関する洞察を得ることができます。<br /><br />これは、管理者が Pod の作成または削除、コンテナへのボリュームのアタッチなどの際にノード レベルで発生する待ち時間の問題を調査するのに役立ちます。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/3085">#3085</a> pod sandbox ready condition</h3><strong>Stage:</strong> Alphaへ移行<br /><strong>Feature group:</strong> node<br /><strong>Feature gate:</strong><span> </span><code>PodHasNetworkCondition</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br />Podサンドボックスが作成され、CRIランタイムがそのネットワークを構成したことをKubeletに示させるために、新しい条件、<span> </span><code>PodHasNetwork</code>がPod定義に追加されました。この条件は、<span> </span><code>ContainersReady</code>や<span> </span><code>Ready</code><span> </span>条件と同様に、Podのライフサイクルにおける重要なマイルストーンとなります。<br /><br />これまでは、たとえばPodが正常にスケジュールされてPodScheduled条件がトリガーされると、ネットワークの初期化に関する他の特定の条件は存在しませんでした。<br /><br />この新しい条件は、CSIプラグイン、CRIランタイム、CNIプラグインなどのような、Podサンドボックスの作成でコンポーネントを設定するクラスターオペレーターに有益です。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/3327">#3327</a> CPU Manager ポリシー: ソケットアライメント</h3><strong>Stage:</strong> Alpha への新規追加<br /><strong>Feature group:</strong> node<br /><strong>Feature gate:</strong><span> </span><code>CPUManagerPolicyAlphaOptions</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br />これにより、新しい静的ポリシーである <span> </span><code>align-by-socket</code> が<a href="https://kubernetes.io/blog/2018/07/24/feature-highlight-cpu-manager/"> CPUManager</a> に追加され、NUMA境界でCPUの割り当てを調整すると、異なるソケットからCPUを割り当てることになる場合、予測可能なパフォーマンスを達成することができます。<br /><br />これは、ワークロードが本当に実行される CPU コアをより制御できるようにするためのこれまでの取り組みを補完するものです。<br /><br /><ul><li><a href="https://sysdig.jp/blog/kubernetes-1-22-whats-new/#2625">#2625 新しい CPU マネージャーポリシー</a></li><li><a href="https://sysdig.jp/blog/kubernetes-1-23-whats-new/#2902">#2902 NUMA ノードに CPU を分散する CPUManager ポリシーオプション</a></li></ul><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/2254">#2254</a> cgroup v2</h3><strong>Stage:</strong> Stableへ移行<br /><strong>Feature group:</strong> node<br /><strong>Feature gate:</strong><span> N/A</span><br /><br />この機能拡張は、Kubernetes を Cgroups v2 と互換性を持たせるために行われた作業をカバーしており、まず設定ファイルから始まります。<br /><br />値の範囲にいくつかの変更があるため、<a href="https://github.com/kubernetes/enhancements/blob/5b4d3d5ec07b8e2ee7d231c6f99c09b0da04a48a/keps/sig-node/20191118-cgroups-v2.md#phase-1-convert-from-cgroups-v1-settings-to-v2">新しい設定値</a>を確認してください。例えば、<span> </span><code>cpu.weight</code><span> </span>の値は[2-262144]から[1-10000]に変更される予定です。<br /><br />詳しくは、<span> “</span><a target="_blank" href="https://sysdig.jp/blog/kubernetes-1-22-whats-new/#2254" rel="noopener">What’s new in Kubernetes 1.22</a><span>” </span>の記事をご覧ください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/277">#277</a> エフェメラルコンテナ</h3><strong>Stage:</strong> Stableへ移行<br /><strong>Feature group:</strong> node<br /><strong>Feature gate:</strong><span> </span><code>EphemeralContainers<span> </span><strong>Default value:<span> </span></strong>true</code><br /><br />エフェメラルコンテナは、実行中のPodをデバッグするのに最適な方法です。作成後のPodに通常のコンテナを追加することはできませんが、kubectl debugでエフェメラルコンテナを実行することは可能です。<br /><br />詳しくは<span> </span><a target="_blank" href="https://sysdig.com/blog/whats-new-kubernetes-1-16/#277" rel="noopener">Kubernetes 1.16 – What’s new? </a>の記事をご覧ください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/1029">#1029</a> エフェメラルストレージクォータ</h3><strong>Stage:</strong> Betaへ移行<br /><strong>Feature group:</strong> node<br /><strong>Feature gate:</strong><span> </span><code>LocalStorageCapacityIsolationFSQuotaMonitoring</code><br /><strong>Default value:</strong><span> </span><code>true</code><br /><br />エフェメラルボリュームを定期的にスキャンするよりも効率的で正確なクォータを計算するための新しいメカニズムです。<br /><br />詳しくは<span> </span><a target="_blank" href="https://sysdig.com/blog/whats-new-kubernetes-1-15/#1029" rel="noopener">Kubernetes 1.15 – What’s new? </a>の記事でご確認ください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/2238">#2238</a> プローブに設定可能なgrace periodを追加</h3><strong>Stage:</strong> Betaにおけるメジャーチェンジ<br /><strong>Feature group:</strong> node<br /><strong>Feature gate:</strong><span> </span><code>ProbeTerminationGracePeriod</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br />この機能拡張は、2つの状況を区別するために、livenessProbeオブジェクトの内部に2番目の<span> </span><code>terminationGracePeriodSeconds</code><span> </span>フィールドを導入します。Kubernetesは、通常の状況下でコンテナをkillするためにどれくらい待つべきか、そしてlivenessProbeの失敗が原因でkillされるのはいつか？<br /><br />詳しくは <a href="https://sysdig.jp/blog/whats-new-kubernetes-1-21/">Kubernetes 1.21 - What's new?</a> をご覧ください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/2413">#2413</a> デフォルトでseccomp</h3><strong>Stage:</strong> Betaへ移行<br /><strong>Feature group:</strong> node<br /><strong>Feature gate:</strong><span> </span><code>SeccompDefault</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br />Kubernetesはコンテナのセキュリティを向上させ、デフォルトでSeccompプロファイルを使用してコンテナを実行するようになりました。<br /><br />詳しくは、<a target="_blank" href="https://sysdig.jp/blog/kubernetes-1-22-whats-new/#2413" rel="noopener">What’s new in Kubernetes 1.22 </a>の記事をご覧ください。<br /><br /><br /><h2>Kubernetes 1.25におけるスケジューリング</h2><h3><a href="https://github.com/kubernetes/enhancements/issues/3094">#3094</a> PodTopologySpread Skewの計算時にテイント/トレランスを考慮するようになりました</h3><strong>Stage:</strong> Alphaへ移行<br /><strong>Feature group:</strong><span> scheduling</span><br /><strong>Feature gate:</strong><span> </span><code>NodeInclusionPolicyInPodTopologySpread</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br /><a href="https://sysdig.com/blog/whats-new-kubernetes-1-16/#895">Kubernetes 1.16 - What's new?</a> の記事で説明したように、<span> </span><code>topologySpreadConstraints</code>フィールドでは、ノード間でワークロードを分散できます。これは<span> </span><code>maxSkew</code>と一緒に行われ、2つの与えられたトポロジードメイン間のPod数の最大差を表します。<br /><br />新しく追加されたフィールド<span> </span><code>NodeInclusionPolicies</code><span> </span>では、<span> </span><code>NodeAffinity</code><span> </span>と<code>NodeTaint</code>（値：<span> </span><code>Respect</code><span>/</span><code>Ignore</code>）の両方の値を設定して、このPodトポロジー スプレッド <span>skew </span>の計算時にテイントとトレランスを考慮することができます。<br /><br /><ul><li><code>NodeAffinity: Respect</code><span> </span>は、<span> </span><code>nodeAffinity</code><span> </span>と<span> </span><code>nodeSelector</code><span> </span>に一致するノードが<span>skew </span><span>プロセス</span>に含まれることを意味します。</li><li><code>NodeAffinity: Ignore</code><span> (default) </span>は、すべてのノードが含まれることを意味します。</li><li><code>NodeTaint: Respect</code><span> </span>は、<span>incoming </span>Podを許容するテイントノードと、通常のノードが<span>skew </span><span>プロセス</span>に含まれることを意味します。</li><li><code>NodeTaint: Ignore</code><span> (default) </span>は、すべてのノードが含まれることを意味します。</li></ul>これにより、一部のPodが予期しないPending状態になることを防ぎます。なぜなら、<span>skew </span>制約が、テイントまたはトレランスを持つノードにそれらを割り当てているからです。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/3243">#3243</a> ローリングアップグレード後のPodTopologySpreadの尊重(レビュー)</h3><strong>Stage:</strong> Alpha への新規追加<br /><strong>Feature group:</strong><span> scheduling</span><br /><strong>Feature gate:</strong><span> </span><code>MatchLabelKeysInPodTopologySpread</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br /><code>PodTopologySpread</code><span> </span>は、互いに関連するPodがどのように均等に分散されるかをよりよく制御することを容易にします。しかし、新しいPodのセットをデプロイするとき、既存の（すぐになくなる）Podが計算に含まれるため、将来のPodの分布が不均一になる可能性があります。<br /><br />今回の機能強化では、Podの仕様とその計算アルゴリズムに新しいフィールドを追加し、Podの定義に含まれる任意のラベルを考慮する柔軟性を持たせ、コントローラーがより正確なPodのセットを作成してからスプレッド計算を行うことを可能にしました。<br /><br />以下の構成では、labelSelectorとmatchLabelKeysという2つの関連フィールドを見ることができます。これまで、labelSelectorだけがトポロジー・ドメイン内のPodの数を決定していました。既知のpod-template-hashのような1つ以上のキーをmatchLabelKeysに追加することで、コントローラーは同じデプロイの下にある異なるReplicaSetからのPodを区別し、より正確な方法でスプレッドを計算することができるようになります。<br /><br /><pre class="prettyprint">apiVersion: v1
kind: Pod
Metadata:
 name: example-pod
Spec:
 # Configure a topology spread constraint
 topologySpreadConstraints:
   - maxSkew: &lt;integer&gt;
     minDomains: &lt;integer&gt; # optional; alpha since v1.24
     topologyKey: &lt;string&gt;
     whenUnsatisfiable: &lt;string&gt;
     labelSelector: &lt;object&gt;
     matchLabelKeys: &lt;list&gt; # optional; alpha since v1.25
 ### other Pod fields go here</pre><br />この機能によってあなたの生活が変わることはないかもしれませんし、クラスターのパフォーマンスが変わることもないかもしれません。しかし、もしあなたが自分のPodが思い通りに分散されないことを不思議に思ったなら、ここにその答えがあります。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/785">#785</a> kube-scheduler ComponentConfigをGAに移行する</h3><strong>Stage:</strong> Stableへ移行<br /><strong>Feature group:</strong><span> scheduling</span><br /><strong>Feature gate:</strong><span> NA</span><br /><br /><a href="https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/kubelet-integration/#configure-kubelets-using-kubeadm">ComponentConfig</a>は、コンポーネント設定をよりダイナミックにし、Kubernetes APIを通じて直接到達できるようにするための継続的な取り組みです。<br /><br />詳しくは<span> </span><a target="_blank" href="https://www.linkedin.com/pulse/whats-new-kubernetes-119-takao-shimizu/?trackingId=SWhZOtcISlGEnDKT6yCZdw%3D%3D" rel="noopener">Kubernetes 1.19 – What’s new?</a><span>  </span>の記事をご覧ください。<br /><br />このバージョンでは、いくつかのプラグインが削除されました：<br /><br /><ul><li>KubeSchedulerConfiguration <span> </span><code>v1beta2</code><span> </span>は非推奨となりますので、<span> </span><code>v1beta3</code> または <code><span> </span>v1</code>に移行してください。</li><li>スケジューラープラグインの<span> </span><code>SelectorSpread</code><span> </span>が削除されましたので、代わりに<span> </span><code>PodTopologySpread</code>を使用してください。</li></ul>以前の非推奨情報については、<span> </span><a target="_blank" href="https://sysdig.jp/blog/kubernetes-1-23-whats-new/#785" rel="noopener">What’s new in Kubernetes 1.23 </a>記事をご覧ください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/3022">#3022</a> PodTopologySpreadの最小ドメイン数</h3><strong>Stage:</strong> Betaへ移行<br /><strong>Feature group:</strong><span> scheduling</span><br /><strong>Feature gate:</strong><span> </span><code>MinDomainsInPodTopologySpread</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br />新しい<span> </span><code>minDomains</code><span> </span>サブリソースは、新しいPodをスケジューリングする時点では存在しないかもしれないけれども、利用可能としてカウントすべきドメインの最小数を確立します。したがって、必要なときにドメインはスケールアップされ、そのドメイン内の新しいノードがクラスターオートスケーラによって自動的に要求されます。<br /><br />詳しくは、<span> </span><a target="_blank" href="https://sysdig.jp/blog/kubernetes-1-24-whats-new/#3022" rel="noopener">What’s new in Kubernetes 1.24</a><span> </span>の記事でご覧ください。<br /><br /><br /><h2>Kubernetes 1.25 ストレージ</h2><h3 id="1710"><a rel="noopener nofollow noreferrer" target="_blank" href="https://github.com/kubernetes/enhancements/issues/1710">#1710</a><span> マウントオプションによるSELinuxの再ラベリング</span></h3><strong>Stage:</strong> Alphaへ移行<br /><strong>Feature group:</strong><span> storage</span><br /><strong>Feature gate:</strong><span> </span><code>SELinuxMountReadWriteOncePod</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br />この機能は、SELinuxを使用した<span> </span><code>PersistentVolumes</code><span> </span>のマウントを高速化するためのものです。マウント時に<span> </span><code>context</code>オプションを使用することで、Kubernetesはファイル上で再帰的にコンテキストを変更するのではなく、ボリューム全体にセキュリティコンテキストを適用します。この実装にはいくつかの注意点があり、最初のフェーズでは、<span> </span><code>ReadWriteOncePod</code>を持つ<code>PersistentVolumeClaims</code><span> </span>によってバックアップされたボリュームにのみ適用されます。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/3107">#3107</a> NodeExpansion シークレット</h3><strong>Stage:</strong> Alphaへ移行<br /><strong>Feature group:</strong><span> storage</span><br /><strong>Feature gate:<span> </span><code>CSINodeExpandSecret</code></strong><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br />ストレージはステートフルなアプリケーションだけでなく、クラスターノードにも必要なものです。クレデンシャルを使用してボリュームを拡張することは、StorageClasses Secretsを使用してKubernetesの以前のバージョンですでに可能でした。しかし、ノードにストレージをマウントして、<span> </span><code>NodeExpandVolume</code><span> </span>操作を行う際にそれらのクレデンシャルを渡すメカニズムがありませんでした。<br /><br />これらの新しい機能拡張は、StorageClass 定義の 2 つの新しいアノテーションを活用することで、CSI ドライバに <span> </span><code>secretRef</code><span> </span>フィールドを渡すことを可能にします。<br /><br /><pre class="prettyprint">apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-storage-sc
parameters:
  csi.storage.k8s.io/node-expand-secret-name: secret-name
  csi.storage.k8s.io/node-expand-secret-namespace: mysecretsns</pre><br />近日中にKubernetesのサイトでより詳細な情報を記載したブログ記事を掲載する予定ですので、ご期待ください。それまでは、<a href="https://github.com/kubernetes/enhancements/pull/3173">KEP</a>を参照して詳細を確認してください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/3333">#3333</a> PersistentVolumeClaims (PVCs) のデフォルト StorageClass を調整する</h3><strong>Stage:</strong> Alpha への新規追加<br /><strong>Feature group:</strong><span> storage</span><br /><strong>Feature gate:</strong><span> </span><code>RetroactiveDefaultStorageClass</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br />この機能拡張は、PVCがStorageClassなしで作成された場合の動作を統合し、デフォルト・クラスを使用するPVCに明示的なアノテーションを追加するものです。これにより、クラスター管理者がデフォルトのストレージクラスを変更し、古いストレージクラスを削除してから新しいストレージクラスを設定するまでの間に、デフォルトのストレージクラスがない状態がしばらく続く場合、その管理に役立ちます。<br /><br />この機能を有効にすると、新しいデフォルトが設定されたときに、 StorageClass を持たないすべての PVC は、デフォルトの StorageClass に遡及的に設定されます。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/361">#361</a> ローカルエフェメラルストレージリソース管理</h3><strong>Stage:</strong> Stableへ移行<br /><strong>Feature group:</strong><span> storage</span><br /><strong>Feature gate:</strong><span> </span><code>LocalStorageCapacityIsolation</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br />Kubernetes 1.7のAlphaで初めて導入されて以来、長い間待ち望まれていたこの機能は、CPUとメモリに対して行われたのと同様の方法で<span> </span><code>requests.ephemeral-storage</code><span> </span>と<code>limits.ephemeral-storage</code><span> </span>を設定することにより、Podが使用するエフェメラルストレージを制限できるようにするものです。<br /><br />Kubernetesは、設定した<a href="https://www.linkedin.com/pulse/%25E4%25BE%258B%25E3%2582%2592%25E4%25BA%25A4%25E3%2581%2588%25E3%2581%25A6kubernetes%25E3%2581%25AE%25E3%2583%25AA%25E3%2583%259F%25E3%2583%2583%25E3%2583%2588%25E3%2581%25A8%25E3%2583%25AA%25E3%2582%25AF%25E3%2582%25A8%25E3%2582%25B9%25E3%2583%2588%25E3%2582%2592%25E7%2590%2586%25E8%25A7%25A3%25E3%2581%2599%25E3%2582%258B-takao-shimizu/?trackingId=WMPVHOM3Tx64%2FS7o55ufYA%3D%3D">リミットやリクエスト</a>を超えたコンテナを持つ<a href="https://sysdig.com/blog/kubernetes-pod-evicted/">Podをevict</a>させます。CPUとメモリについては、ノード上でPodをスケジューリングする前に、スケジューラーがPodのストレージ要件を利用可能なローカルストレージと照らし合わせてチェックします。さらに、管理者はResourceQuotasを設定してネームスペースの総リクエスト/リミットを制限したり、LimitRangesを設定してPodのデフォルトリミットを設定したりすることができます。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/625">#625</a> CSIマイグレーション - コア</h3><strong>Stage:</strong> Stableへ移行<br /><strong>Feature group:</strong><span> storage</span><br /><strong>Feature gate:</strong><span> </span><code>CSIInlineVolume</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br /><span>“</span><a target="_blank" href="https://sysdig.com/blog/whats-new-kubernetes-1-15/#625" rel="noopener">Kubernetes 1.15 – What’s new?</a><span>”</span>の記事で取り上げたように、ストレージプラグインはもともとKubernetesコードベース内のインツリーであり、ベースコードの複雑さを増し、拡張性の妨げになっていました。<br /><br />このコードをすべて、Container Storage Interfaceを通じてKubernetesと対話できるローダブルプラグインに移行する取り組みが進行中です。<br /><br /><span> </span><code>PersistentVolume</code><span> </span>タイプのほとんどは非推奨となり、以下のものが残っています。<br /><br /><ul><li>cephfs</li><li>csi</li><li>fc</li><li>hostPath</li><li>iscsi</li><li>local</li><li>nfs</li><li>rbd</li></ul><br />この作業はいくつかのタスクに分割されています<span>: </span><a target="_blank" href="https://sysdig.com/blog/whats-new-in-kubernetes-1-13/#178" rel="noopener">#178</a><span>, </span><a rel="noopener nofollow noreferrer" target="_blank" href="https://sysdig.com/blog/kubernetes-1-25-whats-new/#1487">#1487</a><span>, </span><a rel="noopener nofollow noreferrer" target="_blank" href="https://sysdig.com/blog/kubernetes-1-25-whats-new/#1488">#1488</a><span>, </span><a target="_blank" href="https://sysdig.com/blog/whats-new-kubernetes-1-19/#1490" rel="noopener">#1490</a><span>, </span><a target="_blank" href="https://sysdig.com/blog/whats-new-kubernetes-1-19/#1491" rel="noopener">#1491</a><span>, </span><a rel="noopener nofollow noreferrer" target="_blank" href="https://sysdig.com/blog/kubernetes-1-25-whats-new/#1491">#1491</a><span>, </span><a rel="noopener nofollow noreferrer" target="_blank" href="https://sysdig.com/blog/kubernetes-1-25-whats-new/#2589">#2589</a><br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/1488">#1488</a> CSI マイグレーション - GCE</h3><strong>Stage:</strong> <span>Stable</span>へ移行<br /><strong>Feature group:</strong><span> storage</span><br /><strong>Feature gate:</strong><span> </span><code>CSIMigrationGCE</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br />GCE (Google Container Engine) の Persistent Disk サポートをアウトオブツリーの <code><a rel="noopener nofollow noreferrer" target="_blank" href="https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver">pd.csi.storage.gke.io Container Storage Interface (CSI) Driver</a></code><span> </span>(これはクラスターにインストールする必要があります) に移動します。<br /><br />この機能拡張は、<span> </span><a rel="noopener nofollow noreferrer" target="_blank" href="https://sysdig.com/blog/kubernetes-1-25-whats-new/#625">#625 In-tree storage plugin to CSI Driver Migration</a><span> </span> の一部として行われます。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/596">#596</a> CSI エフェメラルボリューム</h3><strong>Stage:</strong> <span>Stable</span>へ移行<br /><strong>Feature group:</strong><span> storage</span><br /><strong>Feature gate:</strong><span> </span><code>CSIInlineVolume</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br />CSIボリュームは現在、PV/PVC経由でのみ参照できます。これは、リモートの永続的なボリュームのためにうまく機能します。この機能により、CSIボリュームをローカルのエフェメラルボリュームとして使用する可能性が出てきました。<br /><br />詳細は、<a target="_blank" href="https://sysdig.com/blog/whats-new-kubernetes-1-14/#596" rel="noopener">What’s new in Kubernetes 1.14</a><span> </span>記事をご覧ください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/1487">#1487</a> CSIマイグレーション - AWS</h3><strong>Stage:</strong> Stableへ移行<br /><strong>Feature group:</strong><span> storage</span><br /><strong>Feature gate:</strong><span> </span><code>CSIMigrationAWS</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br /><span>“</span><a target="_blank" href="https://sysdig.jp/blog/kubernetes-1-23-whats-new/#1487" rel="noopener">What’s new in Kubernetes 1.23</a><span>”</span>でも取り上げましたが、AWS EBS Container Storage Interface (CSI) ドライバに対するすべてのプラグイン操作は、<a href="https://github.com/kubernetes-sigs/aws-ebs-csi-driver">アウトオブツリーの 'ebs.csi.aws.com' ドライバー</a>にリダイレクトされるようになりました。<br /><br />この機能強化は、<span> </span><a rel="noopener nofollow noreferrer" target="_blank" href="https://sysdig.com/blog/kubernetes-1-25-whats-new/#625">#625 In-tree storage plugin to CSI Driver Migration</a><span> </span> の取り組みの一部です。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/1491">#1491</a> CSI マイグレーション - vSphere</h3><strong>Stage:</strong> Betaへ移行<br /><strong>Feature group:</strong><span> storage</span><br /><strong>Feature gate:</strong><span> </span><code>CSIMigrationvSphere</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br /><span>“</span><a target="_blank" href="https://www.linkedin.com/pulse/whats-new-kubernetes-119-takao-shimizu/?trackingId=6EHbmVGRQuGIfpx%2FhmtrLg%3D%3D" rel="noopener">What’s new in Kubernetes 1.19</a><span>”</span>の記事で取り上げたように、vSphere用のCSIドライバは以前からstableです。現在、<span> </span><code>vspherevolume</code><span> </span> に対するすべてのプラグイン操作は、<a href="https://github.com/kubernetes-sigs/vsphere-csi-driver">アウトオブツリーの 'csi.vsphere.vmware.com' ドライバー</a>にリダイレクトされるようになりました。<br /><br />この機能強化は、<span> </span><a rel="noopener nofollow noreferrer" target="_blank" href="https://sysdig.com/blog/kubernetes-1-25-whats-new/#625">#625 In-tree storage plugin to CSI Driver Migration</a><span> </span> の取り組みの一部です。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/2589">#2589</a> CSI マイグレーション - Portworx</h3><strong>Stage:</strong> Betaへ移行<br /><strong>Feature group:</strong><span> storage</span><br /><strong>Feature gate:</strong><span> </span><code>CSIMigrationPortworx</code><span> </span><strong>Default value:</strong><span> </span><code>false</code><br /><br /><span>“</span><a target="_blank" href="https://sysdig.jp/blog/kubernetes-1-23-whats-new/#2589" rel="noopener">What’s new in Kubernetes 1.23</a><span>” </span>の記事で取り上げたように、Portworx Container Storage Interface（CSI）ドライバのすべてのプラグイン操作は、<a href="https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/csi/">アウトオブツリーの 'pxd.portworx.com' ドライバー</a>にリダイレクトされるようになった。<br /><br />この機能強化は、<span> </span><a rel="noopener nofollow noreferrer" target="_blank" href="https://sysdig.com/blog/kubernetes-1-25-whats-new/#625">#625 In-tree storage plugin to CSI Driver Migration</a><span> </span>の取り組みの一部です。<br /><br /><br /><h2>Kubernetes 1.25のその他の強化点</h2><h3><a href="https://github.com/kubernetes/enhancements/issues/2876">#2876</a> CRD validation expression language</h3><strong>Stage:</strong> Betaへ移行<br /><strong>Feature group:</strong><span> api-machinery</span><br /><strong>Feature gate:</strong><span> </span><code>CustomResourceValidationExpressions</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br />この機能拡張は、Webhooksに基づく既存のものを補完する形で、Custom Resource Definitions (CRD)の検証メカニズムを実装しています。<br /><br />これらの検証ルールは <a href="https://opensource.google/projects/cel">Common Expression Language (CEL)</a> を使用し、<span> </span><code>x-kubernetes-validations extension</code>を使用して <code>CustomResourceDefinition</code><span> </span>スキーマに含まれます。<br /><br />コンパイルと評価の時間を追跡するために、<code>cel_compilation_duration_seconds</code><span> </span> と <span> </span><code>cel_evaluation_duration_seconds</code>という 2 つの新しいメトリクスが提供されます。<br /><br />詳細は <a target="_blank" href="https://sysdig.jp/blog/kubernetes-1-23-whats-new/#2876" rel="noopener">What’s new in Kubernetes 1.23 </a>記事でご確認ください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/2885">#2885</a> サーバーサイドunknown field validation</h3><strong>Stage:</strong> Betaへ移行<br /><strong>Feature group:</strong><span> api-machinery</span><br /><strong>Feature gate:</strong><span> </span><code>ServerSideFieldValidation</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br />現在、<span> </span><code>kubectl –validate=true</code><span> </span>を使用すると、リクエストがオブジェクト上の未知のフィールドを指定した場合に失敗することを示すことができます。この機能拡張は、<span> </span><code>kube-apiserver</code>にバリデーションを実装するための作業をまとめたものです。<br /><br />詳しくは <span> </span><a target="_blank" href="https://sysdig.jp/blog/kubernetes-1-23-whats-new/#2885" rel="noopener">Kubernetes 1.23 – What’s new?</a><span> </span>の記事をご覧ください。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/3203">#3203</a> 公式CVEフィードの自動更新(レビュー)</h3><strong>Stage:</strong> Alphaへ移行<br /><strong>Feature group:</strong><span> security</span><br /><strong>Feature gate:</strong><span> N/A</span><br /><br />例えば、Kubernetesに関する関連情報を持つCVEsのリストが必要で、それをプログラム的に取得したいとしましょう。あるいは、安心感を保つために、K8sの公式チームが公開していることを知っていて、修正された脆弱性のリストを閲覧したいとします。<br /><br />さらに一歩進んで、最近発表されたCVEや修正が必要なCVEなどをお客様にお知らせしたいKubernetesプロバイダーの方もいるかもしれません。<br /><br />いずれにせよ、この機能拡張はクラスターで有効にするものではなく、Webリソースを介してコンシュームするものです。脆弱性の発表の中から <span> </span><code>official-cve-feed</code><span> </span>というラベルを探せばいいだけです。<br /><br />この成果を説明した<a href="https://github.com/kubernetes/enhancements/tree/master/keps/sig-security/3203-auto-refreshing-official-cve-feed">KEP</a>はこちらです。すぐに読みに行く必要はありませんが、いつか役に立つ日が来るかもしれません。<br /><br /><h3><a href="https://github.com/kubernetes/enhancements/issues/2802">#2802</a> API アドミッション レベルで Windows ポッドを正式に識別する</h3><strong>Stage:</strong> Stable へ移行<br /><strong>Feature group:</strong><span> windows</span><br /><strong>Feature gate:</strong><span> </span><code>IdentifyPodOS</code><span> </span><strong>Default value:</strong><span> </span><code>true</code><br /><br />この機能拡張は、PodSpecに<span> </span><code>OS</code>フィールドを追加し、PodがどのOS上で実行されるべきかを定義できるようにします。そうすることで、KubernetesはPodを管理するためのより良いコンテキストを持つことができます。<br /><br />詳しくは <a target="_blank" href="https://sysdig.jp/blog/kubernetes-1-23-whats-new/#2802" rel="noopener">Kubernetes 1.23 – What’s new?</a><span>  </span>の記事をご覧ください。<br /><br /><hr />以上、Kubernetes 1.25についてでした。これらの機能のいずれかを使用する予定がある場合は、クラスターのアップグレードの準備をしておいてください。<br /><br />もしこの記事が気に入ったのであれば、以前の「Kubernetesの新機能」編もチェックしてみてください：<br /><br /><ul><li><div><a href="https://sysdig.jp/blog/kubernetes-1-24-whats-new">Kubernetes 1.24の新機能</a><br /><a href="https://sysdig.jp/blog/kubernetes-1-23-whats-new/#2845">Kubernetes 1.23の新機能</a><br /><a href="https://sysdigjpstg.wpengine.com/blog/kubernetes-1-22-whats-new/">Kubernetes 1.22の新機能</a></div></li><li><div><a href="https://sysdigjpstg.wpengine.com/blog/whats-new-kubernetes-1-21/" rel="noopener" rev="en_rl_none"><span>Kubernetes 1.21の新機能</span></a></div></li><li><div><a href="https://www.scsk.jp/sp/sysdig/blog/kubernetes/kubernets_120.html" rev="en_rl_none"><span>Kubernetes 1.20の新機能</span></a></div></li><li><div><a href="https://www.scsk.jp/sp/sysdig/blog/kubernetes/whats_new_in_kubernetes_119.html" rev="en_rl_none"><span>Kubernetes 1.19の新機能</span></a></div></li><li><div><a href="https://www.scsk.jp/sp/sysdig/blog/kubernetes/whats_new_in_kubernetes_118.html" rev="en_rl_none"><span>Kubernetes 1.18の新機能</span></a></div></li><li><div><a href="https://www.scsk.jp/sp/sysdig/blog/kubernetes/kubernetes_117.html" rev="en_rl_none"><span>Kubernetes 1.17の新機能</span></a></div></li><li><div><a href="https://sysdig.com/blog/whats-new-kubernetes-1-16/" rev="en_rl_none"><span>Kubernetes 1.16の新機能</span></a></div></li><li><div><a href="https://sysdig.com/blog/whats-new-kubernetes-1-15/" rev="en_rl_none"><span>Kubernetes 1.15の新機能</span></a></div></li><li><div><a href="https://sysdig.com/blog/whats-new-kubernetes-1-14/" rev="en_rl_none"><span>Kubernetes 1.14の新機能</span></a></div></li><li><div><a href="https://sysdig.com/blog/whats-new-in-kubernetes-1-13" rev="en_rl_none"><span>Kubernetes 1.13の新機能</span></a></div></li><li><div><a href="https://sysdig.com/blog/whats-new-in-kubernetes-1-12" rev="en_rl_none"><span>Kubernetes 1.12の新機能</span></a></div></li></ul><br /><div>Kubernetesのコミュニティに参加してみませんか？<br /><br /></div><ul><li><div><a href="https://kubernetes.io/">プロジェクトのホームページ</a>をご覧ください。</div></li><li><div><a href="https://github.com/kubernetes/">GitHubでKubernetesプロジェクト</a>をチェックする。</div></li><li><div><a href="https://kubernetes.io/community/">Kubernetesコミュニティ</a>に参加しましょう。</div></li><li><div><a href="https://slack.k8s.io/">Kubernetes Slack</a>でメンテナに会いましょう。</div></li><li><div><a href="https://twitter.com/kubernetesio">Twitterで@KubernetesIO</a>をフォローする。</div></li></ul><br /><span>また、Kubernetesエコシステムの最新情報を楽しみたい方は、クラウドネイティブエコシステムで起こっている最もクールなトピックを毎月お届けする</span><a href="https://go.sysdig.com/container-newsletter-signup.html">コンテナニュースレターを購読</a>してください。<nav class="navigation post-navigation" role="navigation"><div class="nav-links"></div></nav>