根据 Daniel Simionato 于 2022 年 8 月 16 日发布的博客（https://sysdig.com/blog/kubernetes-1-25-whats-new/）的内容，本文是对其进行了翻译和重构而成的。Kubernetes 1.25 即将发布。从哪里开始呢？本次发布中进行了与 Kubernetes 1.24 的 46 个功能增强和 Kubernetes 1.23 的 45 个功能增强相当的 40 个功能增强。这 40 个功能增强中，13 个已转为稳定状态，10 个是对现有功能的改进，15 个是全新功能，还有 2 个是不推荐使用的功能。本次发布的亮点是 PodSecurityPolicies 最终被删除，被 PodSecurity admission 取代，并最终实现了稳定状态的转移。在这个版本中，请注意所有废弃和删除的内容！新增了一些真正值得欢迎的新安全功能，如用户命名空间支持、用于取证分析的检查点、在挂载卷时 SELinux 的改进、NodeExpansion Secret、官方 CVE 订阅的改进等。此外，其他功能还可以简化集群管理员的生活。例如，不可恢复的 Pod Failure、KMS v2 的改进、更干净的 IPTables 链所有权、PVC 上默认 StorageClass 的更好处理等。最后，这个版本的蛋糕上的装饰是所有达到 GA 状态的出色功能。CSI 的迁移是一个持续了三年多的过程，现在终于进入了最后阶段，因此受到了很大的赞赏。此外还有 NetworkPolicies 的端口范围、Ephemeral Volume 和 Cgroups v2 的支持。由于有很多需要谈论的内容，让我们开始了解 Kubernetes 1.25 的最新情况吧。

Kubernetes 1.25 – 编辑之选：

 

#127 添加对用户命名空间的支持

米格尔·埃尔南德斯 – Sysdig的安全内容工程师

#2008 反欺诈容器检查点

哈维尔·马丁内斯 – Sysdig的DevOps内容工程师

#3329 关于作业的可重试和不可重试的 Pod 失败

失败

丹尼尔·西莫纳托- Sysdig的安全内容工程师

#625 CSI迁移 – 核心

超过3年以上

维克多·希梅内斯·塞拉达 – Sysdig的内容管理工程师

#3299 KMS v2改进

戴维德·多卡什——Sysdig公司的DevOps内容工程师

5号PodSecurityPolicy + 2579号Pod安全控制

Vicente J. Miras是Sysdig的安全内容工程师。

不推荐的事项

API和功能的删除

 

• 提供されなくなった非推奨APIバージョン（より新しいもの）:

 

• CronJob batch/v1beta1

EndpointSlice discovery.k8s.io/v1beta1

Event events.k8s.io/v1beta1

HorizontalPodAutoscaler autoscaling/v2beta1

PodDisruptionBudget policy/v1beta1

PodSecurityPolicy policy/v1beta1

RuntimeClass node.k8s.io/v1beta1

その他のAPIの変更:
k8s.io/component-base は、 k8s.io/component-base/logs/api/v1 （ログ設定用のGo API）へ移動しました。

その他の変更点:
1.21 から非推奨のBeta版  PodSecurityPolicy admission プラグインは削除されました。
いくつかのインツリーボリュームプラグインのサポートが削除されました。
GlusterFS
flocker
quobyte
storageos

kubectl run コマンドから未使用のフラグを削除しました。
エンドツーエンドのテストが Ginkgo v1 から v2 に移行されました。

Ginkgo.Measure は非推奨になりました。代わりに  gomega/gmeasure を使ってください。
いくつかのapiserverメトリクスが変更されました。
APIサーバーの  –service-account-api-audiences フラグを非推奨とし、代わりに  –api-audiencesを採用しました。

seccompのアノテーションを一部削除しました。
コマンドラインフラグ  enable-taint-managerを非推奨としました。
最近再び実装されたschedulability predicateを削除しました。
Kube-scheduler  ComponentConfig  v1beta2 を非推奨としました。
kubeletは、cAdvisorを介したアクセラレータメトリクスの収集をサポートしなくなりました。

Kubernetes 1.25版本的发布说明Kubernetes 1.25版本中的移除和废弃功能处理不推荐的API迁移指南

第5个Pod安全策略

舞台：
特征组：

Pod Security Policies (PSP) 是一种出色的Kubernetes原生工具，用于限制部署。

Kubernetes 1.23 – 有哪些新功能？要使用内置的PodSecurity admission插件，请参考此指南。

3446号通知中，我们决定从可用的InTree驱动程序中不推荐使用GlusterFS插件。

阶段:
功能组：

离开者Quobyte 可以被简述为什么？存储操作系统

在Kubernetes 1.25版本中的应用程序

#3329 设置可恢复/不可恢复对于作业的Pod故障问题。

舞台：
特性组:
功能门：工作回退策略默认值：错误的

.spec.backoffLimit 可以被翻译成以下方式之一：

– 回退限制 (huí tuì
– 倒退次数限制
– 重试限制
– 重试次数上限

退避限制 (tuì bì

工作.spec.backoffPolicy翻译成中文的一个选项：.spec.backoff策略

为了提高工作负载的可用性，DaemonSets需要支持MaxSurge。

舞台:
功能组：
功能开关DaemonSet更新激增默认值:真实的

滚动更新滚动更新策略的最大浮动数量：ec.strategy.rollingUpdate.maxSurge

Kubernetes 1.22的最新资讯

#2599 我们在 Statefulsets 中添加了 minReadySeconds。

舞台：
特性组：
功能组：
功能门：
特性门控：StatefulSetMinReadySeconds 的默认值为真。

部署DaemonSetsReplicaSets 的同义词准备时间秒数有状态集合

Kubernetes 1.22的最新资讯

#3140 CronJob的时区支持

阶段:
特征组: 特性群组
功能當道：定时任务的时区默认值：真的

CronJob定时任务kube-controller-manager
Kubernetes控制管理器

Kubernetes 1.24的最新消息

Kubernetes 1.25 认证

#3299 KMS v2 的升级改进

舞台
特征组：
特性开关KMSv2: KMS第二版本默认值:错误的

旋转钥匙。

KEP (Knowledge Extraction and Profiling) is a technology used to extract and profile information.

#2579 Pod 安全性审批（Pod 安全性策略的替代）

阶段：
特性组：
Feature gate:PodSecurity（Pod 安全）默认值:真的

在Kubernetes 1.21版本中，Pod Security Policies被标记为不推荐使用。PodSecurity验证控制器

Kubernetes 1.22 – 有什么新功能？

• クラスターレベルでPodのセキュリティ標準を適用する

 

ネームスペースレベルでPodセキュリティ標準を適用する

 

Kubernetes 1.25版本中的网络配置

#2593 多个ClusterCIDR

阶段:
功能组:
功能门:
集群CIDR配置默认值：false

PodCIDR 转为中文的同义句：PodCIDR。

• セグメントを使い果たし、クラスターをスケールアップすることになった場合に備えて、クラスターにさらにPod IPを追加する。

将来のノードで割り当て可能な最大Pod数を2倍にするなど、より高いまたはより低い機能を持つノードを追加する。

不連続な範囲のプロビジョニング。ネットワークセグメントが均等に分配されておらず、新しいノードをデプロイするためにそれらの多くをグループ化する必要がある場合に便利です。

群集CIDR配置节点IP地址管理

整理清理具有IPTables链的所有权

阶段:
特性组：

特性组
特性门：清理IPTables所有权默认值:错误

kubelet - Kubernetes节点上的一个系统组件，负责管理容器运行时环境和容器的生命周期。容器适配器kube-proxy: Kubernetes代理删除Dockershim

在这里，我们提供了以下选项的中文简述：

– 酷比代理kube-proxy 翻译成中文可以是 "容器网络代理"kube-proxy --> Kube代理kubelet 可以 paraphrase 为 "kubelet 节点代理"。kube-proxy 可以被改为：Kubernetes 代理

#2079 网络策略的端口范围

场景：
特性组合：
特性门：网络策略结束端口默认值：真实

spec:
egress:

• ports:

protocol: TCP
port: 32000
endPort: 32768詳細はKubernetes 1.21 – What’s new?をご覧ください。
#3070 ダイナミックおよびスタティックなIP割り当てのためのサービスIPレンジの確保
Stage: Betaへ移行Feature group: NetworkFeature gate: ServiceIPStaticSubrange Default value: trueこの  –service-cluster-ip-range  フラグのアップデートにより、静的および動的な IP 割り当てを使用しているサービス間で IP が競合するリスクが低下し、同じタイプで後方互換性が保たれます。詳しくは、What’s new in Kubernetes 1.24をご覧ください。
Kubernetes 1.25 Nodes

#127 ユーザーネームスペースのサポート追加
Stage: Alphaへ移行Feature group: nodeFeature gate: UserNamespacesSupport Default value: false非常に待ち望まれていた機能です。Podに与えられた過剰な特権のために、ホストが侵害される脆弱性はたくさんあります。ユーザーネームスペースは、以前からLinux Kernelでサポートされています。さまざまなコンテナランタイムを通じて、それらをテストすることが可能です。Kubernetesエコシステムに導入することで、新たな可能性が開けることは間違いありません。例えば、あまりにも要求レベルの高いコンテナに対して特権モードで動作していると思わせたり、コンテナイメージのサーフェイスアタックを軽減することなどは、多くの人にとってまだ課題のようです。最後に誰かが CAP_SYS_ADMIN 機能を要求した時のことを覚えていますか？もしあなたが私たちのような人なら、それを与えることを躊躇したことでしょう。さて、今回の機能強化により、これらのパーミッションはPodでは利用できますが、ホストでは利用できなくなります。FUSEファイルシステムをマウントしたり、コンテナ内でVPNを起動したりするのが頭痛の種でなくなるのです。まだイメージできていないのであれば、もっとわかりやすい言葉で言いましょう。コンテナ内のプロセスは、2つのID（UID/GID）を持つことになります。1つはPodの内部で、もう1つは外部の、より有害な可能性を秘めたホスト上でです。もう使い始めたいですか？Feature gate  UserNamespacesSupport を有効にし、Pod内部の spec.hostUsers の値をfalse に設定します（true またはunsetの場合は、現在のKubernetesと同様にホストユーザが使用されます）。ただし、この機能はまだ実運用には適していません。この機能の詳細については、KEPに追加情報と、この機能がないことで影響を受けるCVEの網羅的なリストがあります。
#2008 フォレンジックコンテナチェックポインティング
Stage: Alpha へ移行Feature group: nodeFeature gate: ContainerCheckpointRestore Default value: falseコンテナチェックポインティングは、実行中のコンテナのスナップショットを取ることを可能にします。このスナップショットは、フォレンジック調査を開始する別のノードに転送することができます。解析は影響を受けるコンテナのコピーで行われるため、オリジナルにアクセスできる攻撃者は、このような解析に気づくことはありません。この機能は、新しく導入されたCRI APIを使用しているため、kubeletはチェックポイントを作成するための1回限りの呼び出しを要求することができます。スナップショットの作成は /checkpoint エンドポイント経由で要求され、  –root-dir (デフォルトは  /var/lib/kubelet/checkpoints) の下に .tar 形式 (i.e., checkpoint—.tar) で格納されることになります。
#2831 Kubelet OpenTelemetry トレース
Stage: Alpha へ移行Feature group: nodeFeature gate: KubeletTracing Default value: falseAPIServer の KEP-647 と同様に、この機能拡張では、 kubeletで行われる GRPc コールに OpenTelemetry トレースが追加されます。これらのトレースにより、ノードレベル、たとえば、kubelet  とコンテナランタイム間の相互作用に関する洞察を得ることができます。これは、管理者が Pod の作成または削除、コンテナへのボリュームのアタッチなどの際にノード レベルで発生する待ち時間の問題を調査するのに役立ちます。
#3085 pod sandbox ready condition
Stage: Alphaへ移行Feature group: nodeFeature gate: PodHasNetworkCondition Default value: falsePodサンドボックスが作成され、CRIランタイムがそのネットワークを構成したことをKubeletに示させるために、新しい条件、 PodHasNetworkがPod定義に追加されました。この条件は、 ContainersReadyや Ready 条件と同様に、Podのライフサイクルにおける重要なマイルストーンとなります。これまでは、たとえばPodが正常にスケジュールされてPodScheduled条件がトリガーされると、ネットワークの初期化に関する他の特定の条件は存在しませんでした。この新しい条件は、CSIプラグイン、CRIランタイム、CNIプラグインなどのような、Podサンドボックスの作成でコンポーネントを設定するクラスターオペレーターに有益です。
#3327 CPU Manager ポリシー: ソケットアライメント
Stage: Alpha への新規追加Feature group: nodeFeature gate: CPUManagerPolicyAlphaOptions Default value: falseこれにより、新しい静的ポリシーである  align-by-socket が CPUManager に追加され、NUMA境界でCPUの割り当てを調整すると、異なるソケットからCPUを割り当てることになる場合、予測可能なパフォーマンスを達成することができます。これは、ワークロードが本当に実行される CPU コアをより制御できるようにするためのこれまでの取り組みを補完するものです。
#2625 新しい CPU マネージャーポリシー
#2902 NUMA ノードに CPU を分散する CPUManager ポリシーオプション

#2254 cgroup v2
Stage: Stableへ移行Feature group: nodeFeature gate: N/Aこの機能拡張は、Kubernetes を Cgroups v2 と互換性を持たせるために行われた作業をカバーしており、まず設定ファイルから始まります。値の範囲にいくつかの変更があるため、新しい設定値を確認してください。例えば、 cpu.weight の値は[2-262144]から[1-10000]に変更される予定です。詳しくは、 “What’s new in Kubernetes 1.22” の記事をご覧ください。
#277 エフェメラルコンテナ
Stage: Stableへ移行Feature group: nodeFeature gate: EphemeralContainers Default value: trueエフェメラルコンテナは、実行中のPodをデバッグするのに最適な方法です。作成後のPodに通常のコンテナを追加することはできませんが、kubectl debugでエフェメラルコンテナを実行することは可能です。詳しくは Kubernetes 1.16 – What’s new? の記事をご覧ください。
#1029 エフェメラルストレージクォータ
Stage: Betaへ移行Feature group: nodeFeature gate: LocalStorageCapacityIsolationFSQuotaMonitoringDefault value: trueエフェメラルボリュームを定期的にスキャンするよりも効率的で正確なクォータを計算するための新しいメカニズムです。詳しくは Kubernetes 1.15 – What’s new? の記事でご確認ください。
#2238 プローブに設定可能なgrace periodを追加
Stage: BetaにおけるメジャーチェンジFeature group: nodeFeature gate: ProbeTerminationGracePeriod Default value: trueこの機能拡張は、2つの状況を区別するために、livenessProbeオブジェクトの内部に2番目の terminationGracePeriodSeconds フィールドを導入します。Kubernetesは、通常の状況下でコンテナをkillするためにどれくらい待つべきか、そしてlivenessProbeの失敗が原因でkillされるのはいつか？詳しくは Kubernetes 1.21 – What’s new? をご覧ください。
#2413 デフォルトでseccomp
Stage: Betaへ移行Feature group: nodeFeature gate: SeccompDefault Default value: trueKubernetesはコンテナのセキュリティを向上させ、デフォルトでSeccompプロファイルを使用してコンテナを実行するようになりました。詳しくは、What’s new in Kubernetes 1.22 の記事をご覧ください。
Kubernetes 1.25におけるスケジューリング

#3094 PodTopologySpread Skewの計算時にテイント/トレランスを考慮するようになりました
Stage: Alphaへ移行Feature group: schedulingFeature gate: NodeInclusionPolicyInPodTopologySpread Default value: falseKubernetes 1.16 – What’s new? の記事で説明したように、 topologySpreadConstraintsフィールドでは、ノード間でワークロードを分散できます。これは maxSkewと一緒に行われ、2つの与えられたトポロジードメイン間のPod数の最大差を表します。新しく追加されたフィールド NodeInclusionPolicies では、 NodeAffinity とNodeTaint（値： Respect/Ignore）の両方の値を設定して、このPodトポロジー スプレッド skew の計算時にテイントとトレランスを考慮することができます。

NodeAffinity: Respect は、 nodeAffinity と nodeSelector に一致するノードがskew プロセスに含まれることを意味します。

NodeAffinity: Ignore (default) は、すべてのノードが含まれることを意味します。

NodeTaint: Respect は、incoming Podを許容するテイントノードと、通常のノードがskew プロセスに含まれることを意味します。

NodeTaint: Ignore (default) は、すべてのノードが含まれることを意味します。
これにより、一部のPodが予期しないPending状態になることを防ぎます。なぜなら、skew 制約が、テイントまたはトレランスを持つノードにそれらを割り当てているからです。
#3243 ローリングアップグレード後のPodTopologySpreadの尊重(レビュー)
Stage: Alpha への新規追加Feature group: schedulingFeature gate: MatchLabelKeysInPodTopologySpread Default value: falsePodTopologySpread は、互いに関連するPodがどのように均等に分散されるかをよりよく制御することを容易にします。しかし、新しいPodのセットをデプロイするとき、既存の（すぐになくなる）Podが計算に含まれるため、将来のPodの分布が不均一になる可能性があります。今回の機能強化では、Podの仕様とその計算アルゴリズムに新しいフィールドを追加し、Podの定義に含まれる任意のラベルを考慮する柔軟性を持たせ、コントローラーがより正確なPodのセットを作成してからスプレッド計算を行うことを可能にしました。以下の構成では、labelSelectorとmatchLabelKeysという2つの関連フィールドを見ることができます。これまで、labelSelectorだけがトポロジー・ドメイン内のPodの数を決定していました。既知のpod-template-hashのような1つ以上のキーをmatchLabelKeysに追加することで、コントローラーは同じデプロイの下にある異なるReplicaSetからのPodを区別し、より正確な方法でスプレッドを計算することができるようになります。apiVersion: v1
kind: Pod
Metadata:
name: example-pod
Spec:

配置拓扑分布约束

拓扑分布约束:

• maxSkew:

 

• minDomains: # optional; alpha since v1.24

 

• topologyKey:

 

• whenUnsatisfiable:

 

• labelSelector: