Kubernetes 1.19: SIG-Apps の変更内容

はじめに

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

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

ここに記載されていないものは別のまとめで記載されていると思いますので、 Kubernetes 1.19: 変更点まとめも合わせて参照してみてください。

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

Changes by kind

Deprecation　(非推奨)

kube-apiserver: componentstatus APIが非推奨になりました。このAPIはetcd, kube-scheduler, kube-controller-managerのステータスを提供するものでしたが、kube-schedulerとkube-controller-managerがローカルに対してunsecureなエンドポイントを公開したときのみ有効でした。このAPIの代わりに、kube-apiserverのhealth checkにetcdも含まれるようになりました。また、kube-scheduler/kube-controller-managerのhealth checkエンドポイントにより、コンポーネントに対して直接確認できるようになりました。 (#93570, @liggitt) [SIG API Machinery, Apps and Cluster Lifecycle]

API Change（API の変更）

非推奨となったアノテーションを新しいAPIサーバーのフィールドと同期するために、seccomp profileのpod version skew strategyが追加されました。(#91408, @saschagrunert) [SIG Apps, Auth, CLI and Node]
- podの作成/更新、PSPの作成/更新のそれぞれの場合に応じての戦略がこちらのKEPの方で定義されていますので、詳細について知りたい方はご参照ください。
CertificateSigningRequest APIのconditionが変更されました
- statusフィールドが追加されました。フィールドにはデフォルトでTrueが設定され、 conditionがApproved, Denied, Failedのみ、Trueが設定可能です。
- lastTransitionTimeフィールドが追加されました。
- 署名者が永続的に失敗となるFailedのconditionが追加されました。このconditionはcertificatesigningrequests/statusのサブリソースを介して追加することができます。
- Approved と Deniedのconditionは相互に排他となります。
- Approved, Denied, FailedのconditionはCSRから除去できなくなります。
(#90191, @liggitt) [SIG API Machinery, Apps, Auth, CLI and Node]
Custom Endpointsが新しいEndpointSliceMirroringによって、EndpointSlicesにミラーされるようになりました。 (#91637, @robscott) [SIG API Machinery, Apps, Auth, Cloud Provider, Instrumentation, Network and Testing]
- custom Endpointに関しては、こちらの方にも記載があるので、興味のある方はご参照ください。
EnvVarSourceに記載されているとおりに、動作しない件についてAPI側が修正されました。(#91194, @wawa0210) [SIG Apps]
- 具体的な内容としては、こちらに書かれているmetadata.labelsとmetadata.annotationsについて、['<KEY>']が使用できるように修正が加えられました。
ログのtimestampの長さが固定長になるように修正が加えられました。 (#91207, @iamchuckss) [SIG Apps and Node]
- これは、ログのtimestampの末尾の0がつめられてしまうことにより、運用時に負担を強いられる等の申告に対応したものになります。
  - 修正前
    2020-05-11T00:59:53.112926311Z INFO log output 1 2020-05-11T00:59:53.11319083Z INFO log output 2 2020-05-11T00:59:53.262609142Z WARN log output x
  - 修正後
    2020-05-11T00:59:53.112926311Z INFO log output 1 2020-05-11T00:59:53.113190830Z INFO log output 2 2020-05-11T00:59:53.262609142Z WARN log output x
Generic ephemeral volumesがalphaとして新しく提供されます。この機能はfeature gateのGenericEphemeralVolumeで提供され、EmptyDirの代わりとなるような機能になります。EmptyDirと同様にKubernetesが自動でpodにたいして、volumeを作成、削除します。しかしEmptyDirと異なり、プロビジョニングにPersistentVolumeClaimを使用しているのでthird-partyのストレージを使用することができ、volumeを空にする必要もありません。スナップショットからのリストアもサポートされています。(#92784, @pohly) [SIG API Machinery, Apps, Auth, CLI, Instrumentation, Node, Scheduling, Storage and Testing]
- 現時点では、alphaなので積極的に使用するということはないと思いますが、EmptyDirの代替となる可能性のある機能なので注目していきたいと思います。
- Generic ephemeral volumesの詳細を知りたい方はこちらのKEPを参照ください。
scheme.Convert()は明示的に登録されたconversionで使用できるようになりました。デフォルトでのreflectionでのconversionは使用できなくなります。+k8s:conversion-genのtagを使って、k8s.io/code-generatorでconversionを生成することができます。(#90018, @wojtek-t) [SIG API Machinery, Apps and Testing]
Immutable Secrets/ConfigMapsがベータに昇格しました。 (#89594, @wojtek-t) [SIG Apps and Testing]
- VolumeとしてマウントされたSecrets/ConfigMapsは、kubeletが定期的にkube-apiserverに変更を確認しにいき、更新を行いますが(defaultではkubeletの--sync-frequencyに基づき60秒間隔)、Secrets/ConfigMapsの誤った更新からアプリケーションを保護することができません。そのため、Secrets/ConfigMapsのImmutable tureと定義することで、kubectl apply等での変更を拒否するように設定することができます。
- ImmutableなSecrets/ConfigMapsについては、kubeletがkube-apiserverに対して変更を確認しにいかないので、性能面の向上が見込めるケースがあります。
- 詳細な使い方については、こちらを参照下さい。
Schedulerのオプション機能として、unboundなvolumeを持つpodがスケジュールされる際に、事前にストレージの容量の空きを確認します。（この機能はalphaであるCSIStorageCapacity有効になっており、CSI driverのみで使用でき、CSI driver deploymentのサポートに依存します。)(#92387, @pohly) [SIG API Machinery, Apps, Auth, Scheduling, Storage and Testing]
- ストレージの容量とpodのスケジュールに関しては、興味のある方はこちらのKEPを参照されると面白いと思います。
SeccompのサポートがGAになりました。新しくseccompProfileフィールドがpodとcontainer securityContext追加されました。seccomp.security.alpha.kubernetes.io/pod と container.seccomp.security.alpha.kubernetes.io/...のannotationは非推奨となり、Kubernetesのversionが1.22になった時に削除されます。 (#91381, @pjbgf) [SIG Apps, Auth, Node, Release, Scheduling and Testing]
ServiceAppProtocolの機能がbetaとなり、defaultで使用できるようになります。AppProtocolのフィールドがServicesとEndpointに追加されます。(#90023, @robscott) [SIG Apps and Network]
- Application protocolの詳細については、こちらをご参照ください。
SetHostnameAsFQDNがPodSpecの新しいフィールドとして追加されます。この値をtrueに設定すると、コンテナのホスト名がFQDNとして設定されます。Linuxコンテナでは、FQDNにカーネルのホスト名を設定することに相当します。Windowsコンテナでは、registry keyのHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parametersで取得したホスト名をFQDNに設定することに相当します。(#91699, @javidiaz) [SIG Apps, Network, Node and Testing]
- SetHostnameAsFQDNの詳細については、こちらをご参照ください。
Kubeletから--bootstrap-checkpoint-pathが削除されました。(#91577, @knabben) [SIG Apps and Node]
kube-controller-managerで管理された署名者は、個別の鍵と証明書を持つことができるようになります。詳しくは --cluster-signing-[signer-name]-{cert,key}-fileのヘルプを参照ください。まだ、defaultでは--cluster-signing-{cert,key}-fileが使用されます。(#90822, @deads2k) [SIG API Machinery, Apps and Auth]
1.14から非推奨だったseries.state が events.k8s.io/v1beta1 と v1 から削除されました。 (#90449, @wojtek-t) [SIG Apps]
dual-stack機能がGAになるまでは、Service.Spec.IPFamilyのAPI documentationに大きな変更が発生する可能性があることを警告します。ユーザは存在するserviceが IPv4,IPv6,dual-stackのいずれかであるか確認するためには、IPFamilyではなくClusterIPかEndpointsを確認する必要があります。(#91527, @danwinship) [SIG Apps and Network]
- この変更では機能自体には何も変更がなく、ソースコードの中にコメントが追記されただけになります。
IngressとIngressClassがGAとなり、リソースがnetworking.k8s.io/v1になります。extensions/v1beta1 と networking.k8s.io/v1beta1については非推奨となり、Kubernetesの1.22以降で削除予定になります。v1beta1からv1に変更されるにあたってのIngressのフィールドの変更は以下になります。
- spec.backend -> spec.defaultBackend
- serviceName -> service.name
- servicePort -> service.port.name (文字列用)
- servicePort -> service.port.number (数値用)
- pathTypeのdefault値はなくなり"Exact", "Prefix" "ImplementationSpecific"のいずれかを設定する必要があります。
- backendにresourceもしくはservice backendsを使用できます。
- pathは有効な正規表現を使用しなくてもよくなりました。

(#89778, @cmluciano) [SIG API Machinery, Apps, CLI, Network and Testing]

IngressClassの登場もあり、ついにIngressがGAになりました。こちらのKEPを確認すると2015年の秋からIngressが登場していることが確認でき、５年越しにGAになったかと思うと感慨深いものがあります。

Feature（機能）

ノードレベルで複数サイズのhuge pageを割り当てる機能に対するサポートの追加 (#89252, @odinuge) [SIG Apps and Node]
- huge pageに関する背景や機能について詳しく知りたい方は、こちらのKEPを参照ください。
Cloud node-controllerがInstancesV2を使用するようになります。 (#91319, @gongguan) [SIG Apps, Cloud Provider, Scalability and Storage]
EndpointSlice controllerが同期に失敗した際のリトライまでの時間が長くなります。(#89438, @robscott) [SIG Apps and Network]
- この変更で、ベースでのバックオフが5msから1sに変更になるため、api serverへの負荷が軽減することが期待されます。
Service controllerは関連するノードのフィールドが変更された時だけ、LB node poolsと同期するようになります。 (#90769, @andrewsykim) [SIG Apps and Network]

Bug or Regression（バグまたはリグレッション）

GCP cloud-controller-managerがクラスタ外の新しいノードを初期化できないバグが修正されました。(#90057, @ialidzhikov) [SIG Apps and Cloud Provider]
GCE cloud providerがNode objectにIP alisesを追加、反映する時に不要なGCE APIをコールすることを抑止する修正。(#90242, @wojtek-t) [SIG Apps, Cloud Provider and Network]
CloudNodeLifecycleControllerがノードを監視する際にshutdown statusの前にnode existenceをチェックするようになります。 (#90737, @jiahuif) [SIG Apps and Cloud Provider]
EndpointSliceMirroring controllerはEndpointsからEndpointSlicesへlabelの情報をコピーするように修正されました。(#93442, @robscott) [SIG Apps and Network]
- こちらの機能の背景等の詳細についてはこちらのKEPに記載されています。
Podに対して、退避のリクエストを送った際に、対象のPodが削除予定（DeletionTimestampの値が0以外）のときに、必ずリクエストが成功になるように修正が加えられました。(#91342, @michaelgugino) [SIG Apps]
- これは、drainでnodeからPodを退避しようとしたした際に、対象のPodが削除されているにも関わらず、drainが延々とpodの退避の結果を待ち続けるbugに対する修正になります。
endpoint sliceのアップデート時に、誤って古いオブジェクトを新しい方として使用するバグが修正されました。 (#92339, @fatkun) [SIG Apps and Network]
endpointSliceTrackerがメモリリークするバグが修正されました。(#92838, @tnqn) [SIG Apps and Network]
feature gateでIPv6DualStackを有効化したクラスタで、serviceを作成/更新した際にIPFamilyフィールドで生じるいくつかのバグに関する修正

IPFamilyフィールドの動作はまだ一貫性がなく、dual-stackがGAになるまでに変更が加えられる可能性があります。
ユーザがIPFamilyフィールドを使用する際は、write-onlyで使うようにし、IPFamilyフィールドの値に基づくサービス使わないでください(#91400, @danwinship) [SIG Apps and Network]
EndpointControllerがIPv6のみのendpointを作成する際に正しく動作するように修正しました。
IPv6DualStackの有効化されたクラスタで、serviceにipFamily: IPv6を設定することにより、IPv6 headless servicesが使用できるようにEndpointControllerが修正されました。（この内容はすでにEndpointSliceControllerでは実装されています。）(#91399, @danwinship) [SIG Apps and Network]
CSI volumeにアタッチする際にスケールしない問題を、informerを使うよう修正しました。(#91307, @yuga711) [SIG API Machinery, Apps, Node, Storage and Testing]
- クラスタ内のCSI volumeへの同時アタッチ数が100や200など多くなるとapi serverがbusyになり、podの生成が遅くなるというissueがいくつか報告されていましたが、Informer/Cache使用するように変更したことで、パフォーマンスが改善しました。
- 遅くなる原因については、こちらのissueに詳しく書かれているので、興味がある方はこちらをご参照ください。
ディレクトリ以外のhostpathがHostPathFileと認識するバグが修正され、e2eテストに追加されました。(#64829, @dixudx) [SIG Apps, Storage and Testing]
EndpointSlice controllerがガベージコレクションをする際に競合するバグが修正されました。(#91311, @robscott) [SIG Apps, Network and Testing]
- この変更により、EndpointSliceコントローラーは、削除予定のservice(deletionTimestampに0以外の値が設定されている)のEndpointSliceを作成されなくなります。
Kube-apiserverのscaleのsubresourceに対するpatchに関して、不必要な409 Conflict errorをclientが受け取らないようにしました。(#90342, @liggitt) [SIG Apps, Autoscaling and Testing]
Podのステータスの更新時にstatus.podIP と status.podIPs に対して、validateされるように修正が加えられました。(#90628, @liggitt) [SIG Apps and Node]
退避しようとしたPodのstateがPendingだった場合に、PodDisruptionBudgetのチェックを無視して退避されるように修正されました。 (#83906, @michaelgugino) [SIG API Machinery, Apps, Node and Scheduling]
- これは、drain等でPodを退避しようとした際に、stateがPendingのPodがPodDisruptionBudgetでminAvailable等のカウントに含まれてしまい、Podの退避が上手くいかないことに対する修正になります。

Other (その他の修正)

nodeipam range allocatorをリファクタリングし、割り当てられたCIDRsの情報が記録されるcidrsetに対して、以下のメトリクスが追加されました。(#90288, @aojea) [SIG Apps, Instrumentation, Network and Scalability]
- cidrset_cidrs_allocations_total
- cidrset_cidrs_releases_total
- cidrset_usage_cidrs
- cidrset_allocation_tries_per_request
nodeMask.Size()に対する呼び出しを減らすために、nodeMaskSizeが追加されたり、細かい内容ですが使いやすくするための工夫がされています。
PVとPVC関する失敗時のログメッセージが新たに追加されました。これにより、失敗時の解析が以前によりしやすくなることが期待できます。(#89845, @yuga711) [SIG Apps]
- 追加されたメッセージは以下の2つです。
  - PVCが要求するPVが既にBoundであり、PVCがPendingとなる場合
    "volume %q already bound to a different claim.", volume.Name
  - PVがretainされているが、参照元のPVCが既に存在しない場合
    "PersistentVolume[%s] references a claim %q (%s) that is not found", volume.Name, claimrefToClaimKey(volume.Spec.ClaimRef), volume.Spec.ClaimRef.UID)
beta.kubernetes.io/osとbeta.kubernetes.io/archのノードラベルが非推奨となります。今後はkubernetes.io/os と kubernetes.io/arch　使用するようにしてください。(#91046, @wawa0210) [SIG Apps and Node]

所感

今回の登場した大きな変更は以下になるかなと思います。

いずれの変更もSIG-Appsが主体というわけではなく、SIG-Network, SIG-Node, SIG-Storageで主体で行われている変更に関連しているという形で、SIG-Appsが主体となった大きな変更は今回なかったと思われます。

ただ、Kubernetesの利用者の視点でどれか一つSIGをチェックするなら、SIG-Appsをチェックしていると俯瞰して全体を見ることができるのではないかと思います。

細かな修正だと、削除予定のオブジェクト(deletionTimestampに0以外の値が設定されている)に対して、何か処理をしようとした際に競合する事象に対する対応が多かったかなと感じました。

Kubernetesは、それぞれのコンポーネントが独立して動いているので、この辺りの競合はいろいろなユースケースで使っていかないと発見が難しいので、今後も増えていくかなと思います。