More than 1 year has passed since last update.

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

kubernetes

Last updated at 2023-05-16Posted at 2023-04-14

はじめに

このエントリは、Kubernetes 1.27 の CHANGELOG 及びKubernetes v1.27: Chill Vibes | KubernetesからWhat's new!とアップグレード時の注意事項、各変更点についてまとめたページへのリンクです。
詳細については各まとめページを参照してください。

What's New (Major Themes)

2023年の最初のKubernetesのリリースであるv1.27がリリースされました
このリリースは60のエンハンスメントを含みます。このうち18のエンハンスメントはalphaへ、29はBetaへ昇格し、13はStableへ昇格しました。

Freeze k8s.gcr.io image registry

古いイメージレジストリであるk8s.gcr.ioを数ヶ月前GAとなったregistry.k8s.ioへ置き換えます。Kubernetesプロジェクトはコミュニティーにより完全にコントロールされるregistry.k8s.ioイメージレジストリを作成し、運営しています。
これは古いレジストリであるk8s.gcr.ioは凍結される予定であり、これ以上Kubernetesや関連するサブプロジェクトのためのイメージは古いレジストリへ公開されないことを意味しています。

この変更がコントリビュータにとって何を意味するのか？

サブプロジェクトのメンテナーである場合、マニフェストとHelmチャートを新しいレジストリを利用するように更新してください。詳細は、このプロジェクトを確認してください。

この変更はエンドユーザにとって何を意味するのか？

Kubernetesv1.27のリリースはk8s.gcr.ioレジストリで公開されません。
v1.24, v1.25, そしてv1.26のためのパッチリリースは4月以降古いレジストリへ公開されなくなります。
v1.25からデフォルトイメージレジストリはregistry.k8s.ioへセットされます。この値はkubeadmやkubeletでk8s.gcr.ioへ上書きすると、4月以降の新しいリリースでは古いレジストリに存在しないため失敗します。
クラスタの信頼性を向上させるためコミュニティが所有するレジストリへの依存を排除したい場合、または外部トラフィックが制限されたネットワークでKubernetesを運用している場合、ローカルのイメージレジストリーのミラーを検討すべきです。いくつかのクラウドベンダーはこのためにホスティングソリューションを提供している場合があります。

`SeccompDefault` graduates to stable

seccomp profile defaultingを利用するには、kubeletで--seccomp-defaultコマンドラインフラグを利用したいそれぞれのノードで有効化しなければなりません。
有効化された場合、kubeletはUnconfined(seccompが無効)を利用する代わりに、コンテナランタイムにより定義されているRuntimeDefault seccomp profileをデフォルトで利用します。デフォルトのプロファイルの目的はワークロードの機能は維持しつつ、強固なセキュリティのデフォルトを提供することです。デフォルトのプロファイルはコンテナランタイムやそれらのリリースバージョンにより異なる可能性があります。

可能なアップグレードやダウングレードの方法については、関連するKubernetes Enhancement Proposal (KEP)であるEnable seccomp by defaultで詳細情報を確認できます。

v1.24まではPSPによりRuntimeDefaultがPodのSpecへMutatingすることで、この機能を実現できていました。PSPの廃止されたv1.25でSeccompDefaultがbetaとなりましたが、v1.27でstableになりました。
SeccompDefaultの詳細を知りたい方は、KubernetesのSeccompDefaultを試した - Qiitaも併せてご確認ください。

Mutable scheduling directives for Jobs graduates to GA

これはv1.22で導入されbetaレベルとして開始され、現在それはstableです。多くの場合、並列ジョブはポッドを同じゾーンで動作させるか、GPUモデルのxかyのどちらかで動作させ、両方を混在させないといった制約が必要です。suspendフィールドはこれらのセマンティクスを達成するための最初のステップです。suspendはカスタムキューコントローラがいつJobをスタートすべきか決定できるようにします。しかしながら、一度Jobがsuspendを解除されると、カスタムキューコントローラはJobのPodが実際に起動される場所に影響を与えることができません。

この機能はJobのスタート前にスケジューリングディレクティブを更新できるようにし、実際のPodをノードへアサインはkube-schedulerへオフロードしますが、カスタムキューコントローラがPodの配置に影響を与えることができるようにします。これはsuspendされ一度もsuspendを解除されていないJobだけに許されています。
Jobのpod templateのフィールドでnode affinity, node selector, toleration, label, annotation, scheduling gatesが更新可能です。
詳細はKEPをご確認ください: Allow updating scheduling directives of jobs.

DownwardAPIHugePages graduates to stable

Kubernetes v1.20でrequests.hugepages-<pagesize>とlimits.hugepages-<pagesize>がサポートされ、他のcpu, memory, ephemeral storageのようなリソースと整合性を取るためにdownward APIへ追加されました。この機能はこのリリースでstableへ昇格しました。
詳細はKEPをご確認ください:
Downward API HugePages.

Pod Scheduling Readiness goes to beta

Podを作成すると、Podはスケジュールできる状態となる。Kubernetes schedulerは全てのpendingのPodを配置するためのノードを見つけるために努力します。しかしながら、現実の場合、いくつかのPodはしばらくの間必要不可欠なリソースの不足の状態のままとなっていることがあります。これらのPodは不必要な方法でスケジューラ(やCluster Autoscalerのような下流のインテグレータ)を混乱させます。

Podの.spec.schedulingGatesを指定・削除することで、Podがスケジュールされても良いタイミングをコントロールできます。

schedulingGates フィールドは文字列のリストを含み、それぞれの文字列リテラルはPodがスケジューラブルと考慮される前に満たされなければならない基準として認知されます。このフィールドはPod作成時にのみ初期化できます(クライアントもしくはadmissionの間の変更されます)。作成後、schedulingGateの中身は任意の順序で削除可能ですが追加は許可されていません。

Node log access via Kubernetes API

この機能はクラスタ管理者がサービスのログのクエリを許可することにより、ノード上に稼働するサービスの問題をデバッグします。この機能を利用するために、NodeLogQuery feature gateがノード上で有効化され、kubeletの設定でenableSystemLogHandlerとenableSystemLogQueryがtrueへセットされている必要があります。
Linux上ではjounald経由でサービスログが利用可能であることを想定しています。Windows上ではapplication log providerで利用可能なサービスログを想定しています。またLinuxでは/var/log、WindowsではC:\var\logディレクトリからログを取得できます。

クラスタ管理者はクラスタの全て、またはそのサブセットのノードでこのアルファ機能を試すことができます。

さらっとノードのログを確認したい時に便利そうですね！

ReadWriteOncePod PersistentVolume access mode goes to beta

Kubernetes v1.22でPersistentVolumes(PV)とPersistentVolumeClaims(PVC)のための新しいアクセスモードであるReadWriteOncePodを導入しました。このアクセスモードでは、クラスター内の単一のPodにボリュームアクセスを制限し、一度に1つのPodのみがボリュームに書き込めるようにします。これは、ストレージへのシングルライター・アクセスを必要とするステートフルなワークロードに特に有用です。

ReadWriteOncePodのbetaではReadWriteOncePodのPVCを利用するPodのscheduler preemptionのサポートを追加しました。
Scheduler preemptionはより高いプライオリティのPodがより低いプライオリティのPodをpreemptionできるようにします。例えば、ReadWriteOncePodのPVCを持つPod(A)スケジュールされる時、他のPod(B)が同じPVCを利用があり、かつPod(A)の方がプライオリティが高い場合、schedulerはUnschedulableステータスを返し、Pod(B)をpreemptionしようと試みます。
詳細はKEPをご参照ください: ReadWriteOncePod PersistentVolume AccessMode

Respect PodTopologySpread after rolling upgrades

matchLabelKeysはPodのラベルキーのリストで拡散を計算するPodを選択するために利用されます。それらのキーはPodラベルから値を調べるために利用されます。これらのキーと値のラベルは labelSelector とANDして、これから作成されるPodに対して拡散を計算する対象となる既存のPodのグループを選択します。キーを持たないPodは無視されます。nullまたは空のリストはlabelSelectorに対してのみマッチすることを意味します。

matchLabelKeysを用いると、異なるリビジョン間でユーザはpod.specを更新する必要がありません。controllerやoperatorは異なるリビジョンで同じlabelキーに異なる値をセットすることだけが求められます。例えば、ユーザーがDeploymentを使用する場合、Deploymentコントローラによって自動的に追加されるpod-template-hashをキーとするラベルを使用して、1つのDeploymentの異なるリビジョンを区別することができます。

これによりローリングアップグレード時にskewが発生する問題が解消しそうですね！嬉しい！

Faster SELinux volume relabeling using mounts

このリリースで、Podが利用するボリュームへSELinuxラベルを適用する方法がbetaへ昇格しました。この機能は再帰的のボリューム上のそれぞれのファイルを変更する代わりに、正しいSELinuxラベルマウントすることでコンテナの起動の高速化します。SELinuxをサポートするLinux kernelは、初回のボリュームマウントで-o context=マウントオプションを利用することでボリューム全体へSELinuxラベルをセットできるようにあします。この方法により、全てのファイルは与えられたラベルを一定の時間で割り当てられ、ボリューム全体を通して再帰的に処理する必要がなくなりました。

contextマウントオプションはbind mountまたはすでにマウントされたボリュームの再マウントには適用できません。
CSIストレージでは、CSI driverはボリュームの初回マウントを実施するため、このマウントオプションをCSI driverが適用しなければなりません。新しいフィールドであるSELinuxMountをCSIDriverオブジェクトへ追加され、driverが-o contextマウントオプションをサポートしているかどうかをアナウンスできます。

KubernetesがPodのSELinuxラベルを知っており、Podのボリュームに責任を持つCSI driverがSELinuxMount: trueをアナウンスしており、ボリュームがReadWriteOncePodのアクセスモードを持つ場合、KubernetesはCSI driverへcontext=マウントオプションを付与した状態でボリュームをマウントするようリクエストし、コンテナランタイムがボリュームのコンテンツを再ラベルしないように伝えます(なぜなら全てのファイルはすでに正しいラベルをもつため)。
より詳細を確認したい場合はKEPをご参照ください: Speed up SELinux volume relabeling using mounts

Robust VolumeManager reconstruction goes to beta

これはvolume managerのリファクタリングで、kubeletが起動中に既存のボリュームがマウントされている方法の追加情報を入手できるようにするものです。一般的に、この変更はボリュームのcleanupをより強固にします。
NewVolumeManagerReconstruction feature gateがノード上で有効化されている場合、kubelet起動時にマウントされたボリュームの検出が強化されます。

Kubernetes v1.25より前では、kubeletは起動中にマウントされたボリュームを検出するために異なるデフォルト動作を利用していました。
このfeature gateが無効化されると(デフォルトは有効)、古いディスカバリの動作を選択することとなります。

Kubernetes v1.25とv1.26では、この動作の切り替えはSELinuxMountReadWriteOncePod feature gateの一部となっていました。

Mutable Pod Scheduling Directives goes to beta

これによりscheduling readiness gateでブロックされたPodをより制約の多いノードのaffinity/selectorでmutatingできるようになります。Podがスケジュールされるのを許可される前に、Podのスケジューリングディレクティブを変更できるようになり、kube-schedulerがPodをNodeへ割り当てる時、外部のリソースコントローラがPodの配置へ影響を与えることができるようになりました。

これはKubernetesへ新しいスケジューリング機能のパターンの扉を開くものです。特に、アップストリームの全ての機能をサポートし、PodをNodeへのバインディングを処理する既存のkube-schedulerへ依存しながら、kube-schedulerによってサポートされていない機能を実装した軽量なスケジューラを構築できます。カスタムのkube-schedulerバイナリのリビルドやメンテナンスを伴うschedule pluginの実装を必要としない場合、このパターンは好ましい方法となるでしょう。

Feature graduations and deprecations in Kubernetes v1.27

Graduations to stable

このリリースでは合計9つのエンハンスメントがStableへ昇格しました。

Deprecations and removals

このリリースではいくつかの機能の削除も含みます。

Known Issues

The PreEnqueue extension point doesn't work for Pods going to activeQ through backoffQ

1.27.0において、私たちはPreEnqueue拡張ポイントがbackoffQを経由してactiveQに移行するPodに対して機能しないバグを発見しました。これは、バニラKubernetesの動作には影響を与えませんが、カスタムPreEnqueueプラグインを壊す可能性があります。

原因のPull Requestはv1.27.1によって元に戻されました。

Urgent Upgrade Notes

(No, really, you MUST read this before you upgrade)

external cloud providerのためのIPv6DualStack feature gateは削除されました。

(この機能はv1.23でGAとなり、他の全てのコンポーネントについては数リリース前にゲートが削除されました。)
もし手動で有効にしているなら、すぐに止めなければなりません。(#116255, @danwinship)
再起動されない全てのPodへ正しくterminal phaseを与えます。

特に、Pending中に削除されたPodへFailed phaseを割り当てます。また、terminal phase(SucceededまたはFailed, Podのコンテナのexit statusに依存)をrunning中に削除されたPodへ割り当てます。
これはpod failure policy(JobPodFailurePolicyとPodSDisruptionConditions feature gateの有効な場合)を利用するJobにおいて、Podが削除時にpending phaseでスタックする問題を修正します。
RestartPolicy=Alwaysが設定されたPodは決してSucceeded phaseへ入らないという事実に依存しているコントローラをメンテナンスしているユーザは、それらのコントローラを対応する必要があるかもしれません。これは、RestartPolicy=Alwaysを使用するPodが、Pod削除とgraceful node shutdownの2つのシナリオでSucceededフェーズに入る可能性があるためです。(#115331, @mimowo) [SIG Cloud Provider, Node and Testing]

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up