Go to Qiita Advent Calendar 2024 Top
LoginSignup
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@yosshi_

Kubernetes 1.31: SIG-Apps の変更内容

Last updated at Posted at 2024-09-03

はじめに

このページではKubernetes v1.31 における SIG-Apps に関連する変更内容をまとめています。

SIG-AppsはKubernetesのワークロードの扱いなどの変更を主に扱っているため、他のSIGと関係する変更が多くなっております。

SIG / SIG-Apps とは？

  • SIGとは？

    • Special Interest Groups の略称
    • 各 SIG には Subproject が与えられていて、 Subproject に対して独立して開発できるようになっています。
    • Kubernetes は巨大なプロジェクトなので、各SIG 毎に担当(Subproject)が割り当てられていて、各SIG は独立して開発をしています。
    • SIG 間を跨って話し合いをする必要が生じた場合は Working Groups が一時的に作られ、その枠組みの中で話し合うことになります。

  • SIG-Appsとは？

    • Apps Special Interest Group の略称
    • Kubernetes に対して、application を deploy したりすることに関することが対象。具体的には Pod, ReplicaSet, Deployments, DaemonSet, StatefulSet, Jobs, CronJob が対象。
      Kubernetes基礎_-_Google_Slides.png
    • 詳細について知りたい方はこちらをご参照ください。

SIG-Apps 以外の SIG に関する変更は以下にまとめてありますので、合わせてご参照下さい。

注目の変更

Feature Gatesの中で今回Stageに変更のあったSig-Appsに関連する機能は以下になります。

1.30 で導入された JobSuccessPolicy が Beta となり、デフォルトで有効化されました。
1.31 を Alpha リリースのターゲットにしていたいくつかの機能は今回間に合わなかったので新機能はありません。代わりに、今まで Beta になっていた多くの機能が今回 GA になりました。

1.32 のリリースでは以下の機能が Alpha で導入されるかもしれません。

v1.31 Release Notes

v1.31 Release Notes の中で SIG-Apps に関するものについて以下に和訳したものを記載します。

:pencil: がついた文章は、CHANGELOGの公式内容ではなく筆者の補足です。

:wastebasket: Deprecation(非推奨)

なし

:earth_asia: API Changes（変更）

  • UserNamespaces field が NodeRuntimeHandlerFeatures に追加されました。(#126034, @sohankunkerkar)

  • Coordinated Leader Election が Alpha として CoordinatedLeaderElection feature gate が追加されました。有効化すると, control plane は LeaseCandidate objects (coordination.k8s.io/v1alpha1 API group) に参加して leader election を実施するようになり、 kube-apiserver はなんらかの戦略に基づいて最適な instance を選択するようになります。 (#124012, @Jefftree)

  • .status.features.supplementalGroupsPolicy field がノードに追加されました。このフィールドは CRI implementation (KEP-3619)　が実装されている場合 true になります。 (#125470, @everpeace)

  • allocatedResourcesStatus が container status に追加されました。これは device plugin　が出力する health status を示します。 (#126243, @SergeyKanzhelev)

  • Dynamic Resource Allocation (DRA): ResourceClaim のオブジェクト数を namespace 毎に制限し、 v1.ResourceQuota メカニズムを介して特定のクラスを通じて要求されたデバイスの数によって制限できる機能を追加しました。 (#120611, @pohly)

  • Dynamic Resource Allocation (DRA): client-side での ResourceHandle の validation で誤った DriverName 許可されていたが、server-side validation でエラーになります。 (#124075, @pohly)

  • Dynamic Resource Allocation (DRA): pod.spec.recourceClaims の配列では, source の間接的な参照は不要となりました。代わりe.g. source: resourceClaimTemplateName: my-template や resourceClaimTemplateName: my-template のように書くことができます。 (#125116, @pohly)

  • Dynamic Resource Allocation (DRA) が resource.k8s.io API group のアップデートにより強化されました。 主にユーザが利用する type は ResourceClaim で大幅な変更が入っているため、以前のバージョンと互換性がないので新しいバージョンである v1alpha3 を使用してください (#125488, @pohly)

  • コードジェネレーター client-gen が、api/v1 のようなパッケージ構造で動作するように修正されました。(#125162, @sttts)

  • Job's managedBy field のコメントが修正されました。 (#124793, @mimowo)

  • Pod の securityContext の procMount のデフォルト値に関するドキュメントを修正しました。ドキュメントの以前の記述では内部的に使われていた DefaultProcMount と記載されていましたが、実際の値である Default と記述するようにしました。 (#125782, @aborrero)

    • :pencil: コード上のコメントが修正されただけで、実装上の変更はありません。

  • PodDisruptionConditions GA となりロックされました (#125461, @mimowo)

  • PodAffinity/PodAntiAffinity　の MatchLabelKeys/MismatchLabelKeys 機能が Beta になりました。 (#123638, @sanposhiho)

  • JobPodFailurePolicy が GA となり、default でロックされました。 (#125442, @mimowo)

  • successPolicy field が beta になりました。
    jobs_finished_total のメトリクスに新しい reason label SuccessPolicy と CompletionsReached が追加されました。 JobSuccessPolicy 機能が有効化されていると、succeeded Job Pods (.status.succeeded) が desired completions (.spec.completions) に達した場合に、Job は SuccessCriteriaMet の CompletionsReached reason と Complete condition type を得るようになります。 (#126067, @tenzen-y)

    • :pencil: JobSuccessPolicy がベータとなりデフォルトで有効化されました。jobs_finished_total のメトリクスの reason label に SuccessPolicy と CompletionsReached が追加された以外は特に変更はないです。

  • KEP-1880: 新機能を使って複数のサービス CIDR を追加するのユーザは、偏った kube-apiservers が異なる allocator を使用しする際にService に重複する IP が割り当てられる問題を回避するため、デフォルトで異なる allocators を使用して偏った kube-apiservers を実行するときに Service に重複する IP が割り当てられる問題を回避するために、新しい ClusterIP allocator に dual-write strategy をデフォルトで使用するようにします。(#122047, @aojea)

  • Kube-apiserver: ControllerRevision objects は data field に有効な JSON データが含まれているか検証するようになりました。 (#125549, @liggitt)

  • Kube-controller-manager: horizontal-pod-autoscaler-upscale-delay と horizontal-pod-autoscaler-downscale-delay flags 削除されました。 (v1.12 から非推奨となっており、動作してません). (#124948, @SataQiu)

  • PersistentVolumeLastPhaseTransitionTime 機能が stable となり、デフォルトで有効化されます。 (#124969, @RomanBednar)

  • LocalStorageCapacityIsolation が betaになりました ; この動作はデフォルトで有効になります。この機能が有効になっていて、特定の Pod で user namespace を使用している場合に、kubelet で storage capacity isolation 有効になります。 (#126014, @PannagaRao)

  • StatefulSetStartOrdinal が stable になりました。 kube-apiserver と kube-controller-manager のバイナリから --feature-gates=StatefulSetStartOrdinal=true は必要なくなり、将来的にはポリシーに基づき削除されます。 (#125374, @pwschuurman)

  • VolumeAttributesClass 機能が beta になりました。(default では無効化されています)。ユーザがこの機能を有効化した場合 storage.k8s.io/v1beta1 API group でこの機能を利用できます。
    Promoted the VolumeAttributesClass API to beta. (#126145, @carlory)

  • 非推奨となっていた --volume-host-cidr-denylist と --volume-host-allow-local-loopback が kube-controller-manager から削除されました。
    (#124017, @carlory)

  • Pod API は OCI artifacts から派生したボリュームの Alpha support を開始しました。この機能は ImageVolume feature gate に含まれています。 (#125660, @saschagrunert)

  • fine-grained supplemental groups policy (KEP-3619) をサポートしました。この機能により first container processes の supplementary groups を細かく制御できるようになります。これにより　container image (/etc/groups)　に container の primary UID
    を含めたり、含めないことができるようになります。(#117842, @everpeace)

  • MultiCIDRServiceAllocator を beta に更新しました。(default では無効化されています). ユーザはこの機能を有効化すると networking v1beta1 group でこの機能を使用できるようになり、Service CIDR ranges で動的に再設定ができるようになります。(#125021, @aojea)

  • optional な Job Pod Failure Policy のフィールドを omitempty にしました。 (#126046, @mimowo)

    • :pencil: Job Pod Failure Policy の ContainerName, OnExitCodes, OnPodConditions が omitempty になりました。

:sparkle: Feature（機能追加）

  • pv_collector_bound_pvc_count と pv_collector_unbound_pvc_count のメトリクスに storage_class と volume_attributes_class のメトリクスが追加されました。 (#126166, @AndrewSirenko)

  • 全ての Pod が終了するまで、terminal Job conditions の設定を遅らせます。
    加えて Job が失敗すると(backoffLimit に達した、maxFailedIndexes、activeDeadlineSeconds に達した)すぐに最初の job status の更新で FailureTarget condition が追加されます。
    同様に、pod completions 数に到達するとすぐに、SuccessCriteriaMet condition が追加されます。
    また、JobManagedBy が有効になっている場合は、ジョブステータスに次の検証ルールを導入します:

    1. ready pods 数が active pods 数以下であること
    2. Job が終了フェイズに移行する際に terminating pods の数が 0 であること
    3. 終了 Job conditions (Failed と Complete) になる前に対応する interim conditions (FailureTarget と SuccessCriteriaMet) が追加されている必要があります。

    (#125510, @mimowo)

    • :pencil: Job が Failed になっている時に、ready と terminating が 0 でない状態があると、Job の状態を見ている上位のコントローラーがある場合に期待した動作にならないというのが問題のようです

        status:
    conditions:
    - lastProbeTime: "2024-03-07T08:38:21Z"
      lastTransitionTime: "2024-03-07T08:38:21Z"
      message: Job has reached the specified backoff limit
      reason: BackoffLimitExceeded
      status: "True"
      type: Failed  <- job は失敗
    failed: 4
    ready: 2  <- !=0
    startTime: "2024-03-07T08:37:08Z"
    terminating: 1 <- !=0

      terminating 中の Pod がある状態で Kueue などの上位のコントローラーが新たに Job が作成した際に、Cluster Autoscaler 等が terminating の Pod のリソースも考慮して、ノード数を増やしたりすると課金額が増える恐れがあるというのが具体的な問題の例のようです。
      ref https://github.com/kubernetes/kubernetes/issues/123775#issuecomment-1983043931

      JobManagedBy か JobPodReplacementPolicy のどちらかが有効になっているときに、変更点に記載した内容が有効になるようですが、 JobPodReplacementPolicy が 1.31 からデフォルトで有効化されるので実質デフォルト挙動の変更になリます。
      Job が fail になったタイミングで、status が更新されて、利用者が fail になったことを早期に知れて、裏で terminating の処理になるのはそれはそれでいいと思うので、上記の変更はオプショナルなものでも良かったのかなと思いました。
      公式ドキュメントに反映されていないので個人的には以下の部分が難しいなと思いました。

      • terminating の Pod が問題なら、既にある JobPodReplacementPolicy の中で解決するというアプローチも対応方法としてはありそうだなと思いました。
        job.Spec.PodFailurePolicy が Failed の時にだけ変更点の挙動ならわかりやすそうだと思ったが、現状だと条件が TerminatingOrFailed(未指定の場合のデフォルト動作) の時も実行されそうで動作を理解するのが難しい。

        func delayTerminalCondition() bool {
  return feature.DefaultFeatureGate.Enabled(features.JobManagedBy) ||
    feature.DefaultFeatureGate.Enabled(features.JobPodReplacementPolicy)
}

      　ref https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/job/job_controller.go#L998-L1001

      • JobManagedBy が有効化されていることが条件になっているが、対象の機能を利用する場合は Job コントローラーが対象の Job リソースに対して操作しなくなるので、この機能が有効になる条件に含まれている理由がわからなかった。JobManagedBy でこの課題の解決を目指すなら、Job コントローラーの実装は変更せずに、上位のコントローラーで解決するアプローチでも良さそうに思った。

  • Kubernetes の AppArmor サポートが GA になりました。AppArmor feature gate の無効化ができなくなります。 (#125257, @vinayakankugoyal)

  • VolumeAttributesClass feature-gate が有効化になっている際に、claim に適した persistent volume を探す場合に kube-controller-manager は PVC と PV の volumeAttributesClassName フィールドを認識します。 volumeAttributesClassName フィールドは VolumeAttributesClass を参照し、それには volume の変更可能な属性情報の key-value のペアが含まれます。PVC が PV に bound されるまでの間、PVC の volumeAttributesClassName フィールドの変更は禁止されています。バインド中に PVC に volumeAttributesClassName フィールドが存在する場合、controller は同じ volumeAttributesClassName を持つ PVC のみを考慮します。 もし volumeAttributesClassName フィールドが設定されていない、もしくは empty の場合は volumeAttributesClassName が empty の volume のみを考慮します。(#121902, @carlory)

  • LogarithmicScaleDown が GA になりました。 (#125459, @MinpengJin)

  • HonorPVReclaimPolicy が beta となり、デフォルトで有効化されます。 (#124842, @carlory)

  • Services に ClusterIP と Type fields の field selector が実装されました。Kubelet がこの field selector を使用することで、Headless Service のモニタリングを避けることができ、メモリ使用量の削減に寄与します。(#123905, @aojea)

  • PodDisruptionBudget の spec.unhealthyPodEvictionPolicy フィールドが GA になりました。 このフィールドに AlwaysAllow を設定することで、 PodDisruptionBudget の対象となる unhealthy な pod についていつでも evict できるようになります。 (#123428, @atiratree)

  • ジョブの終了時間を計算するときに、サイドカーの終了時間も考慮されるようになりました。 (#124942, @AxeZhan)

  • ElasticIndexedJob が GA になりました。 (#125751, @ahg-g)

:bug: Bug or Regression(バグ修正)

  • ResourceClaim controller が podSchedulingSynced と templatesSynced を待機し忘れる不具合を修正しました。 (#124589, @carlory)

  • active な Pod が削除された場合に .status.terminating フィールドへの反映が早くなりました。特に Job が失敗した時、suspended になった時、active な pods 多い時に早くなります。 (#125175, @dejanzele)

    • :pencil: JobPodReplacementPolicy の有効化時の修正。1.28 以降ではデフォルト true なので、1.31 では有効化されている修正になります。

  • Pod が Job オブジェクトでそうされていないコーナーケースの場合(custom CRD で pod が管理されている場合など)に、"batch.kubernetes.io/job-tracking" finalizer を Pod から削除しないでください。(#124798, @mimowo)

    • :pencil: コード上のコメントが修正されただけで、実装上の変更はありません。

  • daemonset controller が old unhealthy pods を max unavailable budget に含むようにします。 (#123233, @marshallbrekka)

  • 急な pod state の変更が発生した場合に、endpoints status が out-of-sync になる不具合を修正しました。 (#125675, @tnqn)

  • e2e flag "-kube-test-repo-list" が動作しないことがある不具合を修正しました。 (#123587, @huww98)

  • 移行中にリソースが削除された場合に、不具合の原因になっていた storage-version-migrator-controller の不具合を修正しました。 (#126107, @enj)

  • Service LoadBalancer controller が service.Status new IPMode フィールドを正しく考慮せず、ステータスが変更されたかどうかを確認するときにポートを除外していたため、変更されたフィールドが service.Status を正しく更新しない可能性がある問題を修正しました。(#125225, @aojea)

  • EndpointSliceMirroring controller によって Endpoints から Endpointslices ミラーリングされた際に、reconcile によって更新されてないことがある不具合を修正しました。 (#124131, @zyjhtangtang)

  • kube-controller-manager が再起動中に、対応する Endpoints リソースが手動で削除され、再生成された場合に endpointslice の作成が失敗する不具合を修正しました。 (#125359, @yangjunmyfm192085)

  • 静的に PV がプロビジョニングした場合に、volume source が CSI type の場合かマイグレートされた annotation がついている場合に、該当の PV が削除されたとき、PersisentVolume controller は phase を Failed state に変更しません。このパッチを適応した場合に external provisioner は次の reconcile loop で finalizer を削除することができます。残念ながら、既存の PV が既に Failed state に遷移している場合は、このパッチは機能しません。ユーザが finalizer を削除する必要があります。 @carlory)

  • active な Pod が削除された場合に .status.ready フィールドへの反映が早くなりました。特に Job ば失敗した時、suspended になった時、active な pods 多い時に早くなります。 (#125546, @dejanzele)

  • StatefulSet の autodelete は、https://github.com/kubernetes/enhancements/pull/4375 で説明されているように、PVC claims の owner の制御を尊重します。 (#122499, @mattcary)

    • :pencil: ownerReferences を参照して、StetefulSet のもののみをこの機能の対象に絞りました。RabbitMq, crunchy postgres Neo4jCluster 等のカスタムコントローラー達が PVC を操作するケースがあるので、意図しない削除による事故防止のために追加されました

  • RecreatingFailedPod の emission と RecreatingTerminatedPod events は StatefulSet の lifecycle から削除されました。 (#123809, @atiratree)

  • Job: successPolicy の featureGate の有効化に関係なく、 Job に SuccessCriteriaMet が追加される不具合を修正しました。(#125429, @tenzen-y)

  • cronjobs に確実に lastSuccessfullTime が追加されるようになります。 (#122025, @lukashankeln)

:microscope: Other (その他の修正)

  • initial generic controlplane の kube-apiserver のリファクタリングが完了しました。 container orchestration のリソースなしで Kubernetes-like な control plane のバイナリを提供します。 (#124530, @sttts)

  • Job-controller: the JobReadyPods feature flag has been removed (deprecated since v1.31). (#125168, @kaisoz)

  • Job-controller から JobReadyPods feature flag が削除されました、 (v1.31 から非推奨です。) (#125168, @kaisoz)

    • :pencil: 1.29 から GA になっていた機能の有効・無効を切り替えるフラグが削除されました。非推奨というよりは、1.31 から該当のフラグが削除予定だったというの正確な変更点の表記かと思います。

  • 最後に残っていた in-tree gcp cloud provider と credential provider を削除しました。代わりに https://github.com/kubernetes/cloud-provider-gcp の cloud provider と credential provider を使用してください。(#124519, @dims)

  • "DefaultHostNetworkHostPortsInPodTemplates" feature gate 削除されます。v1.28 から非推奨になってから、該当する issue の報告もありません。(#124417, @thockin)

  • The feature gate "SkipReadOnlyValidationGCE" has been removed. This gate has been active for 2 releases with no reports of issues (and was such a niche thing, we didn't expect any). (#124210, @thockin)

  • "SkipReadOnlyValidationGCE" feature gate が削除されました。この機能が active になってから 2 releases 経過しましたが、issue による報告はありません。 (非常にニッチな機能だったので、我々も何も起こらないと思っていました). (#124210, @thockin) [sig/apps]

    • :pencil: Changelog の文章に作り手の感想が書かれているのは珍しいなと思いました。(and was such a niche thing, we didn't expect any)

所感

今回は新機能のリリースもなく、代わりに Beta となっていた 6 つの機能が GA となりました。一度に 6 つも GA になるのは、sig-apps では過去最高の数になるので、今回のリリースは今までで一番安定化に力を入れたリリースになったと思います。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?