Kubernetes 1.28 版本： SIG-Apps 的变更内容

首先

本页面总结了与Kubernetes v1.28中的SIG-Apps相关的变更内容。

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.28.md

由于SIG-Apps主要处理Kubernetes工作负载的变更，因此与其他SIG相关的变更较多。

• 直近での過去の変更内容は以下になります。

Kubernetes 1.27: SIG-Apps の変更内容
Kubernetes 1.26: SIG-Apps の変更内容
Kubernetes 1.25: SIG-Apps の変更内容

请参考以下整理的与 SIG-Apps 以外的 SIG 相关的变更。

Kubernetes 1.28: 変更点まとめ(What’s new!)とアップグレード時の注意事項

重点的改变

以下是与Sig-Apps相关的在Feature Gates中目前已更改为Stage的功能。

Pod

PodIndexLabel：Beta https://github.com/kubernetes/enhancements/issues/4017

Job

JobBackoffLimitPerIndex：Alpha https://github.com/kubernetes/enhancements/issues/3850

JobPodReplacementPolicy：Alpha https://github.com/kubernetes/enhancements/issues/3939

CronJob

CronJobsScheduledAnnotation：Beta https://github.com/kubernetes/enhancements/issues/4026

補充：這次的4個項目都是在1.28版中新增的新功能，但由於以下的默認狀態不同，請注意。

# 1.28 で初めて追加されましたが Beta で追加されています
PodIndexLabel: {Default: true, PreRelease: featuregate.Beta},

JobBackoffLimitPerIndex: {Default: false, PreRelease: featuregate.Alpha},
JobPodReplacementPolicy: {Default: false, PreRelease: featuregate.Alpha},

# 1.28 で初めて追加されましたが Beta で追加されています
CronJobsScheduledAnnotation: {Default: true, PreRelease: featuregate.Beta},

参考 https://github.com/kubernetes/kubernetes/blob/v1.28.0/pkg/features/kube_features.go

播客

PodIndexLabel – 部分标签

使用 Job 和 StatefulSet 创建的 Pod 的标签将附加索引号。
这是从 1.28 版本开始的新功能，作为 Beta 版本添加，因此默认情况下将启用。

関連情報

点击以查看详细说明。对于 Job 的情况：

使用 Indexed 创建 Job。
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
completionMode: Indexed
template:
spec:
containers:
– name: pi
image: perl:5.34.0
command: [“perl”, “-Mbignum=bpi”, “-wle”, “print bpi(2000)”]
restartPolicy: Never

创建 Pod 并确认相应的标签。
$ kubectl apply -f job.yaml

$ kubectl get po -l job-name=pi -o yaml
apiVersion: v1
items:
– apiVersion: v1
kind: Pod
metadata:
annotations:
+ batch.kubernetes.io/job-completion-index: “0”
creationTimestamp: “2023-08-24T08:18:11Z”
generateName: pi-0-
labels:
batch.kubernetes.io/controller-uid: 96180273-f2f0-4bf0-ba99-0bfd527b3320
+ batch.kubernetes.io/job-completion-index: “0”
batch.kubernetes.io/job-name: pi
controller-uid: 96180273-f2f0-4bf0-ba99-0bfd527b3320
job-name: pi

以前只有在注释中才有索引号，现在在标签中也有相同的内容。

对于 StatefulSet：

创建 StatefulSet。
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx
serviceName: “nginx”
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
– name: nginx
image: nginx

创建 Pod 并确认相应的标签。
$ kubectl apply -f sts.yaml
statefulset.apps/web created

kubectl get po -l app=nginx -o yaml
apiVersion: v1
items:
– apiVersion: v1
kind: Pod
metadata:
creationTimestamp: “2023-08-24T08:23:26Z”
generateName: web-
labels:
app: nginx
+ apps.kubernetes.io/pod-index: “0”
controller-revision-hash: web-5d85c59ddf
statefulset.kubernetes.io/pod-name: web-0
name: web-0
:

可以确认标签中包含索引号。
不同于 Job，这里的注释中没有附加索引号。

工作

单个索引的工作重试限制

现在可以使用索引来控制每个作业的 backoffLimit，以前设置 Job 时只能在整个作业中设置一次。

関連情報

当创建带有Index的作业（completionMode=Indexed）时，可以通过以下两个参数来设置每个Index单位创建的作业Pod可以失败的次数。

backoffLimitPerIndex : Index 単位での Pod が失敗した際の backoffLimit の数。Index 毎の Pod の失敗を許容する数を制御します。

maxFailedIndexes : Job に対して許容する Index の失敗数。失敗した Index 数がこの値に達した時点で Job が新規に Pod を作成しなくなります。この値を completions の値より大きくした場合は全ての Index 付きの Pod が作成されます。

点击进行详细说明创建作业。

apiVersion: batch/v1
kind: Job
metadata:
name: job-backoff-limit-per-index-example
spec:
completions: 4
parallelism: 1 #设置并行数为1，以便更容易观察状态的变化。
completionMode: Indexed #需要此功能
backoffLimitPerIndex: 1 #索引的最大失败次数
maxFailedIndexes: 2 #作业执行终止前失败索引的最大数量
template:
spec:
restartPolicy: Never #需要此功能
containers:
– name: example
image: python
command:
– python3
– -c
– |
import os, sys
print(“Hello world”)
if int(os.environ.get(“JOB_COMPLETION_INDEX”)) % 2 == 0: ＃根据索引号设置失败
sys.exit(1)

$ kubectl apply -f job.yaml
job.batch/job-backoff-limit-per-index-example created

$ kubectl get job,po
名称 完成次数 持续时间 年龄
job.batch/job-backoff-limit-per-index-example 2/4 4m11s 4m11s

名称 就绪状态 状态 重启次数 年龄
pod/job-backoff-limit-per-index-example-0-8qvgm 0/1 错误 0 3m58s
pod/job-backoff-limit-per-index-example-0-rpjlk 0/1 错误 0 4m11s
pod/job-backoff-limit-per-index-example-1-cbqdl 0/1 已完成 0 3m53s
pod/job-backoff-limit-per-index-example-2-jv56w 0/1 错误 0 3m48s
pod/job-backoff-limit-per-index-example-2-ndjqx 0/1 错误 0 3m35s
pod/job-backoff-limit-per-index-example-3-tgkq8 0/1 已完成 0 3m30s

由于 backoffLimitPerIndex = 1，可以看到当带有索引的 Pod 失败时，将只创建一个具有相同索引的 Pod。
由于 maxFailedIndexes = 2，在达到 backoffLimitPerIndex 限制的索引数量为2时，将停止创建新的 Pod。在这个例子中，由于 parallelism = 1，失败的索引数恰好是2个，但如果并行数增加，失败的索引数可能会超过2个。这个功能只是在达到条件时停止作业执行。

检查作业状态。

$ kubectl get job -l job-name=job-backoff-limit-per-index-example -o yaml
apiVersion: v1
items:
– apiVersion: batch/v1
kind: Job
:
status:
+ completedIndexes: 1,3
conditions:
– lastProbeTime: “2023-08-24T09:40:58Z”
lastTransitionTime: “2023-08-24T09:40:58Z”
+ message: 作业具有失败的索引
+ reason: 失败的索引
status: “True”
type: 失败
+ failed: 4
+ failedIndexes: 0,2
ready: 0
startTime: “2023-08-24T09:40:11Z”
+ succeeded: 2
terminating: 0
uncountedTerminatedPods: {}

通过观察 status，我们可以看到 failedIndexes 增加，可以从上述状态中了解作业的当前状态。
在这个例子中，failed = 4，因此未达到默认值 backoffLimit = 6，所以没有因 BackoffLimitExceeded 失败。然而，backoffLimit 的限制仍然存在，因此在使用 backoffLimitPerIndex 时需要注意。
在这个例子中，添加了两个参数，分别是 FailedIndexes 和 MaxFailedIndexesExceeded 错误消息，用于作业失败时的错误消息。

职位Pod更换政策

只有在Job已经创建的Pod正在终止（Pod上有删除时间戳）或者失败（status.phase=Failed）时，我们立即创建了一个替代的Pod。但是，通过设置.spec.podReplacementPolicy=Failed，我们现在只在出现失败时才能创建替代的Pod。

関連情報

终止的Pod并不是指进程完全停止了，如下图所示，它执行了与preStop和SIGTERM相关的处理。在这种状态下，如果创建新的Pod，则会有多个Pod同时运行，而不仅仅是.spec.parallelism所指定的数量。这是为了解决使用有限资源（例如GPU）的Pod无法产生预期动作而添加的功能。

谈到 Kubernetes：深入了解Pod的终止

为了在Job中实现类似于StatefulSet的podManagementPolicy=OrderedReady和DaemonSet的maxSurge=0的状态，这种功能将被使用。然而，由于Deployment中没有相应的功能，所以在KEP-3973中正在考虑中。

只需使用现有的以下功能，就可以一直执行直到成功为止。

backoffLimit
失敗の許容回数を決めれるので、成功するまで繰り返すようにできますが、 Job の faild のカウント数は上昇します。

Pod failure policy
特定の Exit Code を指定して faild にカウントされないようにすることが可能です。ただし、アプリケーション側で失敗時の Exit Code を管理する必要があるのと、Pod の失敗自体を抑制はできません。

使用JobPodReplacementPolicy时，其特点在于可以抑制所指定的 Pod 在启动时可能发生的失败。

详细内容说明（点击以展开）podReplacementPolicy=TerminatingOrFailed（默认行为）

创建作业
apiVersion: batch/v1
kind: Job
metadata:
name: busybox
spec:
completions: 3
+ parallelism: 1# 为了更容易观察到状态的变化，将并行度设置为1。
+ podReplacementPolicy: TerminatingOrFailed# 默认值，与现有操作相同，如果未指定。
template:
metadata:
deletionGracePeriodSeconds: 70
spec:
containers:
– name: busybox
image: busybox
command: [“sleep”, “60”]
+ lifecycle:
+ preStop:
+ exec:
+ command: [“sleep”, “60”]# 设置以便易于验证
restartPolicy: Never

通过删除正在运行的Pod来故意引发Terminating状态并进行确认。
#创建作业
$ kubectl apply -f job.yaml
job.batch/busybox created

#确认Pod正在运行
$ kubectl get job, po
NAME COMPLETIONS DURATION AGE
job.batch/busybox 0/3 14s 14s

NAME READY STATUS RESTARTS AGE
pod/busybox-lkqgn 1/1 Running 0 14s

#通过删除Pod故意设置为Terminating状态
kubectl delete po -l job-name=busybox
pod “busybox-lkqgn” deleted

#现有Pod是Terminating的，但可以确认出现了新的Pod
$ kubectl get job, po
NAME COMPLETIONS DURATION AGE
job.batch/busybox 0/3 36s 36s

NAME READY STATUS RESTARTS AGE
+ pod/busybox-fgh6g 0/1 ContainerCreating 0 1s
– pod/busybox-lkqgn 1/1 Terminating 0 36s

busybox-lkqgn处于Terminating状态，但由于正在执行preStop操作，存在多个Pod同时运行，其数量大于parallelism=1。

podReplacementPolicy=Failed

创建作业
apiVersion: batch/v1
kind: Job
metadata:
name: busybox
spec:
completions: 3
+ parallelism: 1# 为了更容易观察到状态的变化，将并行度设置为1。
+ podReplacementPolicy: Failed# 这是一个新添加的功能。
template:
metadata:
deletionGracePeriodSeconds: 70
spec:
containers:
– name: busybox
image: busybox
command: [“sleep”, “60”]
+ lifecycle:
+ preStop:
+ exec:
+ command: [“sleep”, “60”]# 设置以便易于验证
restartPolicy: Never

通过删除正在运行的Pod来故意引发Terminating状态并进行确认。
#创建作业
$ kubectl apply -f job.yaml
job.batch/busybox created

#确认Pod正在运行
$ kubectl get job, po
NAME COMPLETIONS DURATION AGE
job.batch/busybox 0/3 9s 9s

NAME READY STATUS RESTARTS AGE
pod/busybox-cvztl 1/1 Running 0 9s

#通过删除Pod故意设置为Terminating状态
kubectl delete po -l job-name=busybox
pod “busybox-cvztl” deleted

#现有Pod是Terminating的，但新的Pod不会被创建
$ kubectl get job, po
NAME COMPLETIONS DURATION AGE
job.batch/busybox 0/3 42s 42s

NAME READY STATUS RESTARTS AGE
+ pod/busybox-cvztl 1/1 Terminating 0 42s

#在现有Pod被删除后，可以确认新的Pod被创建
$ kubectl get job, po
NAME COMPLETIONS DURATION AGE
job.batch/busybox 0/3 66s 66s

NAME READY STATUS RESTARTS AGE
+ pod/busybox-b9pk5 1/1 Running 0 6s

CronJob 定时任务

CronJobsScheduledAnnotation 计划批处理注释

在CronJob通过创建的Job的注释中，将包含CronJob所调度的时间。
这是自1.28版本以来的新功能，但由于作为Beta功能添加，因此默认是启用的。

関連情報

在这个例子中，我们可以通过检查 `batch.kubernetes.io/cronjob-scheduled-timestamp` 的注释来确认由 CronJob 调度的 Job 的时间戳。

v1.28更新说明

下面是有关 SIG-Apps 的 v1.28 版本发布说明的中文翻译。

这个句子是作者补充的，而不是CHANGELOG的官方内容。

弃用

Kube-controller-manager の –volume-host-cidr-denylist と –volume-host-allow-local-loopback のフラグが非推奨になりました。 (#118128, @carlory) [SIG API Machinery, Apps, Network, Node, Storage and Testing] [sig/network,sig/storage,sig/node,sig/api-machinery,sig/apps,sig/testing]

tracking annotation が validation と defaulting が削除されました。 (#117633, @kannon92) [sig/apps]

JobTrackingWithFinalizers の機能が GA になるまでの間は Job のアノテーションに batch.kubernetes.io/job-tracking が付与されていましたがそれが付かなくなるという話になります。
https://qiita.com/yosshi_/items/95b8a38ad1c44a0266bd#job-tracking-with-finalizers

NetworkPolicyStatus に関する feature 削除されました。 (#115843, @rikatz) [sig/network,sig/api-machinery,sig/apps,sig/testing,sig/architecture]

Indexed Job の completions 数が 10^5 以上で parallelism 数が 10^4 となる巨大な Indexed Job が失敗した場合に Kubernetes が Job の終了を正しくトラッキングできない可能性があります。それらの制限を超過する Job の manifest を作成する際に警告を出すようにしました。 (#118420, @alculquicondor) [SIG Apps] [sig/apps]

completions=100000 かつ parallelism=10000 の Indexed Job というのは中々ないと思います。変更の理由自体もそういうユースケースがあったというのではなく、理論上発生しうるので警告しましたという形で追加されいます。

API更改

Indexed Job の completions 数が 10^5 以上で parallelism 数が 10^4 となる巨大な Indexed Job が失敗した場合に Kubernetes が Job の終了を正しくトラッキングできない可能性があります。それらの制限を超過する Job の manifest を作成する際に警告を出すようにしました。 (#118420, @alculquicondor) [SIG Apps] [sig/apps]

loadbalancer status ingress に IP mode フィールドが追加されました。 (#118895, @RyanAoh) [sig/network,sig/api-machinery,sig/apps,sig/testing,sig/cloud-provider]

service.status.loadBalancer.ingress に IP mode が増えて VIP とか Proxy のような値がはいるようになります。
詳細についてはKEP-1860を参照ください。

CronJobs でスケジュールされた Job のオブジェクトに batch.kubernetes.io/cronjob-scheduled-timestamp のアノテーションが追加されるようになりました。 (#118137, @helayoty) [sig/apps]

Job API に BackoffLimitPerIndex alpha として追加されました。 (#119294, @mimowo) [sig/api-machinery,sig/apps]

cgroups v2 利用する際に、 memory.oom.group 経由で container cgroups の cgroup aware OOM killer が有効化されます。これにより cgroup ないのプロセスは1つの unit として扱われ、OOM kill が発生した際に、cgroup 内のプロセスが同時に kill されるようになります。 (#117793, @tzneal) [SIG Apps, Node and Testing] [sig/node,sig/apps,sig/testing]

Indexed Job pods に completion index の label が追加されます。 (#118883, @danielvegamyhre) [SIG Apps] [sig/apps]

PersistentVolumes に新しく LastPhaseTransitionTime フィールドが追加されました。このフィールドはボリュームが最後に phase を移行した時刻が記録されます。 (#116469, @RomanBednar) [sig/storage,sig/node,sig/api-machinery,sig/auth,sig/apps,sig/testing,sig/release]

Pods に hostNetwork: true が設定され ports が宣言されている場合に hostPort フィールドが自動で設定されます。以前の挙動は Deployment, DaemonSet その他の workload API の PodTemplate に hostPort が設定されている場合に実際の Pod が作成されていました。もしこの状態で問題が発生した場合は DefaultHostNetworkHostPortsInPodTemplates feature gate を true にすると元の挙動に戻ります。その際には kubernetes の bug として報告してください。(#117696, @thockin) [SIG Apps] [sig/apps]

ValidatingAdmissionPolicy と ValidatingAdmissionPolicyBinding の API が v1beta1 に昇格しました。(#118644, @alexzielenski) [SIG API Machinery, Apps and Testing] [sig/api-machinery,sig/apps,sig/testing]

ValidtaingAdmissionPolicy feature gate が beta になりました。これにデフォルトで有効化されるようになります。 (#119409, @alexzielenski) [sig/storage,sig/node,sig/api-machinery,sig/auth,sig/apps,sig/instrumentation,sig/testing,sig/release]

pvc.Status から resizeStatus enum が削除され AllocatedResourceStatus にリプレイスされます。 (#116335, @gnufied) [SIG API Machinery, Apps, Auth, Node, Storage and Testing] [sig/storage,sig/node,sig/api-machinery,sig/auth,sig/apps,sig/testing]

WindowsHostProcessContainers feature-gate が削除されました。(#117570, @marosset) [SIG API Machinery, Apps, Auth, Node and Windows] [sig/node,sig/api-machinery,sig/auth,sig/apps,sig/windows]

PodFailurePolicy feature-gate level のコメントが alpha から beta に変わるので修正されました。 (#117802, @kerthcet) [SIG API Machinery and Apps] [sig/api-machinery,sig/apps]

StatefulSet pods に pod index が label に statefulset.kubernetes.io/pod-index として付与されるようになりました。 (#119232, @danielvegamyhre) [SIG Apps] [sig/apps]

local apiserver が version skew や local apiserver で無効化されている api のリクエストの問題で serve できない時、peer kube-apiserver へのリクエストを proxy でサポートします。(#117740, @Richabanker) [SIG API Machinery, Apps, Auth, Cloud Provider, Network, Node and Testing] [sig/network,sig/node,sig/api-machinery,sig/auth,sig/apps,sig/testing,sig/cloud-provider]

Job で BackoffLimitPerIndex がサポートされました。 (#118009, @mimowo) [sig/api-machinery,sig/apps,sig/testing]

ResourceClaims の名前は ResourceClaimTemplate から作られます。 ベースの名前はまだ – ですが衝突を避けるためにランダムで suffix がつくようになります。 (#117351, @pohly) [SIG API Machinery, Apps, Auth, Node, Scheduling and Testing] [sig/scheduling,sig/node,sig/api-machinery,sig/auth,sig/apps,sig/testing]

新しく “SidecarContainers” の feature gate が利用できるようになります。 この機能により sidecar containers が導入されます。 新しいタイプの init container は他の containers の前に開始されますが、Pod の lifecycle の全期間で動き続け、pod の termination をブロックしません。(#116429, @gjkim42) [SIG API Machinery, Apps, Node, Scheduling and Testing] [sig/scheduling,sig/node,sig/api-machinery,sig/apps,sig/testing]

PodFailurePolicy の feature-gate のコメントが修正されました。 (#118278, @mimowo) [sig/apps]

kube-controller-manager: LegacyServiceAccountTokenCleanUp feature gate が alpha で利用できるようにあります。(デフォルトではオフ) 有効化した場合は legacy-service-account-token-cleaner が –legacy-service-account-token-clean-up-period (デフォルト1年) で指定した期間を過ぎた service account token secrets をループして削除します。ServiceAccount オブジェクトのリストの .secrets から参照され、pods からは参照されません。(#115554, @yt2985) [sig/api-machinery,sig/auth,sig/apps,sig/testing,sig/release]

功能增加

kube-controller-manager に –concurrent-cron-job-syncs フラグを追加して、cron job controller の workers 数を指定できるようになります。 (#117550, @borgerli) [sig/apps]

デフォルトの cron job controller の workers 数は5に設定されていますが、クラスタ内で5000を超える CronJob を実行するケースで処理が出てきたので変更できるようになりました。

#117138で job controller に–concurrent-job-syncsも増えたので以下の 2 つのフラグが Job の Controller 用にkube-controller-managerに追加されました。

–concurrent-cron-job-sync　(default 5)
–concurrent-job-syncs　(default 5)

Pods の podgc を PodReplacementPolicy か PodDisruption でハンドリングできるようになります。 (#118772, @kannon92) [sig/apps,sig/testing]

attach detach controller の attachdetach_controller_forced_detaches のメトリクスに reason が追加されました。(#119185, @xing-yang) [sig/storage,sig/apps]

pod hostNetwork field selector のサポートが追加されました。 (#110477, @halfcrazy) [SIG Apps and Node] [sig/node,sig/apps]

PodRecreationPolicy が実装されてことにより、既に存在している Pod が完全に終了するまで、新しい Pod の作成を待つことができるようになります。 (#117015, @kannon92) [sig/api-machinery,sig/apps,sig/testing]

Dynamic resource allocation: claim が wait for first consumer allocation (デフォルトの動作) を使用している場合、 pod が使用した後に割り当てが解除されるようになります。次のポッドが以前のスケジュール決定の影響を受けず、本当に必要でない限りリソースが割り当てられたままにならないことが保証されます。 claim への割り当てを継続したい場合は “immediate allocation.” を使用します。 (#118936, @pohly) [sig/node,sig/apps,sig/testing]

Kube-controller-manager: dynamic resource controller は pod が作成されると scheduler が無視するように処理し(spec.nodeName がセットされる) し、delayed resource claim allocation を実施し pod の要求を予約します。 (#118209, @pohly) [SIG API Machinery, Apps, Auth, Node and Testing] [sig/node,sig/api-machinery,sig/auth,sig/apps,sig/testing]

pod-security-admission は contextual logging を使うように移行しました。(#114471, @Namanl2001) [SIG Apps and Auth] [sig/auth,sig/apps]

Job controller (kube-controller-manager に含まれる)は contextual logging を使うように移行しました。(#116910, @fatsheep9146) [SIG API Machinery, Apps and Testing] [sig/api-machinery,sig/apps,sig/testing]

EndpointSlice と EndpointSliceMirroring controllers (kube-controller-manager に含まれる)は contextual logging を使うように移行しました。(#115295, @Namanl2001) [SIG API Machinery, Apps, Network and Testing] [sig/network,sig/api-machinery,sig/apps,sig/testing]

non-graceful node shutdown は GA になりました。 (#118228, @carlory) [sig/storage,sig/apps,sig/testing]

EndpointSlice reconciler の新しい staging repo が作成されました。 (#118953, @mskrocki) [sig/network,sig/apps,sig/release]

Scheduler は scheduling cycle が始まるまで、handlers の同期完了を待つようになりました。 (#116729, @AxeZhan) [sig/scheduling,sig/apps,sig/testing]

webhook authorizers に送られる SubjectAccessReview のリクエストの spec.resourceAttributes.version が未設定の場合はデフォルトで * 設定されるようになりました。 (#116937, @AxeZhan) [SIG Apps and Auth] [sig/auth,sig/apps]

ExpandedDNSConfig feature が GA になりました。 ‘ExpandedDNSConfig’ feature がデフォルトでロックされ v1.30 で
削除予定になります。これを明示的に有効化していた場合はその設定を削除してください。(#116741, @gjkim42) [SIG Apps, Network and Node] [sig/network,sig/node,sig/apps]

scheduler interface と cache methods が contextual logging を利用するように更新されました。 (#116849, @mengjiao-liu) [sig/scheduling,sig/apps,sig/instrumentation,sig/testing]

pod が完了もしくは実行されなくなった場合に ResourceClaims は他の Pod が再利用するか削除されます。 (#118817, @pohly) [sig/node,sig/api-machinery,sig/auth,sig/apps,sig/testing]

RetroactiveDefaultStorageClass feature が stable にデフォルトで有効化されます。 (#118102, @RomanBednar) [sig/storage,sig/apps,sig/testing]

全ての Pod の delete の挙動をカウントする force_delete_pods_total と force_delete_pod_errors_total のメトリクスが追加されました。 (#118480, @carlory) [sig/apps]

文件（文档改进）

ボリューム作成を待機中の時のエラーメッセージを明確化しました。(#118262, @torredil) [SIG Apps and Storage] [sig/storage,sig/apps]

错误或回归 (Bug or Regression)

削除された pod の backoff delay をより正確に計算するようになりました。 (#118413, @mimowo) [SIG Apps] [sig/apps]

孤立した Pod が発生することを避けるために、全ての Pod の finalizers が削除されたときに Job が完了するようになりました。 (#119159, @alculquicondor) [sig/apps,sig/testing]

Job status 更新が 1s でバッチで更新されることを保証します。この修正により即時に完了したPodがトリガーとなり、 non-batched Jobのステータスが更新される不運なシナリオが修正されました。 (#118470, @mimowo) [SIG Apps] [sig/apps]

Parallel モードが有効化されている時の StatefulSet の作成が早くなります。 (#117865, @aleksandra-malinowska) [sig/apps]

AddHints と SetNodes が同時に呼び出されたときの TopologyCache の競合が修正されました。(#117249, @tnqn) [SIG Apps and Network] [sig/network,sig/apps]

ノード作成後に topology.kubernetes.io/zone のラベルが追加された場合に Topology Aware Hints がうまく機能しない件を修正しました。 (#117245, @tnqn) [sig/network,sig/apps]

node 作成後に cloud provider とかが topology.kubernetes.io/zone のラベルを後で追加した時に kube-controller-manager のリスタートか、Node events が更新されるまで TopologyAwareHint に反映されていなかった問題になります。これは他のマイナーバージョンにもバックポートされています。

Job pod failure policy を利用した際の backoff delay の計算を修正しました。これにより、 backoffLimit counter から無視されるようになった失敗した Pod が backoff delay の計算に含まれるようになりました。(#119434, @mimowo) [sig/apps]

30 6-16/4 * * 1-5 のように複雑なスケジュールを設定した際に cronjob controller ハンドリングできるように修正しました。(#118724, @soltysh) [sig/apps]

Daemonset controller は terminal Pod (Failed/Succeeded のフェイズ) のついて、VM preemptions と明らかな場合か Pod finalizers に代わりの Pod を作成できるようになりました。 (#118716, @alculquicondor) [sig/node,sig/apps,sig/testing]

其他修正

Job controller のバッチの同期呼び出しを無条件で有効化しました。(以前は JobReadyPods feature が有効の時だけでした) また、Job controller のデフォルトの backoff と最大の backoff の定数がそれぞれ 10s から 1s と 6min から 1min に引き下げされました。これらの数値は Job controller がリクエストが失敗した場合に次の backoff delay を決定するために使用します。(#118615, @mimowo) [SIG Apps and Testing] [sig/apps,sig/testing]

backoff のところの変更内容が分かりにくいので補足を追加します。Job で管理してる Pod が失敗した時に新しい Pod を再作成するときの backoff と Queue を取りにいく時に失敗したときの backoff を同じ定数で管理していたのでそれぞれが別で管理されるようになりますという話になります。Queue を取りにいく時のリトライが最低で 10s になっているのはちょっと長かったので改善しましたという内容です。

## 元々、JobBackOff の定数が一種類だった
// DefaultJobBackOff is the default backoff period. Exported for tests.
– DefaultJobBackOff = 10 * time.Second
// MaxJobBackOff is the max backoff period. Exported for tests.
– MaxJobBackOff = 360 * time.Second

## ApiBackOff と FailureBackOff でそれぞれ別に定義されるようになりました。
// DefaultJobApiBackOff is the default backoff period. Exported for tests.
+ DefaultJobApiBackOff = 1 * time.Second
// MaxJobApiBackOff is the max backoff period. Exported for tests.
+ MaxJobApiBackOff = 60 * time.Second
// DefaultJobPodFailureBackOff is the default backoff period. Exported for tests.
+ DefaultJobPodFailureBackOff = 10 * time.Second
// MaxJobPodFailureBackOff is the max backoff period. Exported for tests.
+ MaxJobPodFailureBackOff = 360 * time.Second

disruption controller (kube-controller-manager　に含まれる) は contextual logging を使うようになりました。 (#119147, @mengjiao-liu) [SIG API Machinery, Apps, Instrumentation and Testing] [sig/api-machinery,sig/apps,sig/instrumentation,sig/testing]

podgc controller と他の残りのログコール (kube-controller-manager　に含まれる)を contextual logging に移行しました。 kube-controller-manager の移行は完了しました。 (#119250, @pohly) [SIG API Machinery, Apps, Cloud Provider, Instrumentation, Network, Storage and Testing] [sig/network,sig/storage,sig/api-machinery,sig/apps,sig/instrumentation,sig/testing,sig/cloud-provider]

一時的な API エラーの後の Job のプロセスの遅延を軽減しました。 (#118759, @mimowo) [sig/apps]

感受

这次主要对 Job 进行了几项较大的更改。通过调查添加了相关 KEP 的原因，似乎是由于在 Tensorflow 等使用案例中出现了问题。可能的背景是，需要在 Kubernetes 上运行需要 GPU 的 Job 的使用案例增加了，所以相关问题也增加了。我认为这种趋势将会继续下去，所以我认为在 Job 方面还会继续添加新功能。