Kubernetes 1.22 の SIG-Network の変更内容をまとめました。SIG-Network に限りませんが、Kubernetes v1.22 では networking.k8s.io/v1beta1 の Ingress など様々なベータ API が削除されているため、アップデートの際はご注意ください。
過去の SIG-Network の変更内容
What's New (主な変更)
様々なベータ Kubernetes API の削除
いくつかの API は、GA (General Availability) になったことでベータ版の提供がされなくなります。この削除には次の API のベータバージョンが含まれています。ValidatingWebhookConfiguration, MutatingWebhookConfiguration, CustomResourceDefinition, APIService, TokenReview, SubjectAccessReview, CertificateSigningRequest, Lease, Ingress, IngressClass。完全なリストは Deprecated API Migration Guide とブログ記事 Kubernetes API and Feature Removals In 1.22: Here’s What You Need To Know を参照してください。
Ingress, IngressClass を含む、deprecated (非推奨) になっていたベータ版 API が、今回一気に廃止されています。Ingress, IngressClass のケースでは、networking.k8s.io/v1beta1 と extensions/v1beta1 の API が廃止され、Kubernetes v1.19 から導入された networking.k8s.io/v1 に移行する必要があります。
参考までに、以下は Ingress バージョンの歴史を簡単にまとめたものです。
| リリース時期 | Kubernetes のサポート開始 | Ingress バージョン |
|---|---|---|
| 2015年9月 | Kubetnetes v1.1.0 | experimental/v1alpha1 |
| 2016年3月 | Kubernetes v1.2.0 | extensions/v1beta1 |
| 2019年5月 | Kubernetes v1.14.0 | networking.k8s.io/v1beta1 |
| 2020年8月 | Kubernetes v1.19.0 | networking.k8s.io/v1 |
Ingress v1beta1 vs. v1
Ingress networking.k8s.io/v1beta1 と networking.k8s.io/v1 では、データの構造の一部も変わっているためご注意ください。主な違いは次の通りです。詳細は、公式ドキュメントの Deprecated API Migration Guide や、Kong のドキュメント Ingress v1 and v1beta1 Differences が参考になります。
-
spec.backendがspec.defaultBackendに変更 -
spec.rules.http.paths.backendの変更-
serviceNameがservice.nameに変更 -
servicePortが数値の場合service.port.numberに変更 -
servicePortが文字列の場合service.port.nameに変更
-
-
spec.rules.http.paths.pathTypeが必須になった-
Prefix,Exact,ImplementationSpecificのいずれかを指定
-
以下は、一つの rule だけを持つ同一内容の Ingress を networking.k8s.io/v1beta1 と networking.k8s.io/v1 で表現した場合の差分です。
--- ingress-v1beta1.yaml 2021-08-24 11:57:02.000000000 +0900
+++ ingress-v1.yaml 2021-08-24 11:48:36.000000000 +0900
@@ -1,4 +1,4 @@
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myingress
@@ -9,5 +9,7 @@
- path: /hello
pathType: Prefix
backend:
- serviceName: myservice
- servicePort: 80
+ service:
+ name: myservice
+ port:
+ number: 80
networking.k8s.io/v1beta1 の例
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: myingress
spec:
rules:
- http:
paths:
- path: /hello
pathType: Prefix
backend:
serviceName: myservice
servicePort: 80
networking.k8s.io/v1 の例
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myingress
spec:
rules:
- http:
paths:
- path: /hello
pathType: Prefix
backend:
service:
name: myservice
port:
number: 80
マニフェストの API バージョンの変換 (kubectl-convert)
マニフェストの場合、kubectl の公式プラグインとして kubectl-convert という、API バージョン間の変換プラグインが用意されているので、これを利用して変換することができます。公式ドキュメントにインストール手順 (Mac、Linux) が用意されています。
例えば、Ingress の場合は、以下のように --output-version に networking.k8s.io/v1 を指定して変換します。
kubectl convert -f ingress-v1beta1.yaml --output-version networking.k8s.io/v1
client-go で API バージョンの変換はできない
client-go を使って Kubernetes API にアクセスするアプリケーションを開発している場合、後方互換性のために API バージョン間の変換をしたいことがあります。しかし、自分の知る限りはライブラリとしてサポートされない Kubernetes の内部パッケージ k8s.io/kubernetes/...を利用しない限りは、API バージョン間の変換はできません。
自分が Prometheus の Ingress 用 Service Discovery で、v1beta1, v1 両方の Ingress をサポートする PR (Kubernetes SD: Support networking.k8s.io/v1 Ingress #9205) を出したときは以下のように対応しました。
- サーバーの Kubernetes のバージョンを見てどちらの API を使うか判定
- Kubernetes v1.19 以上であれば
v1Ingress を使用。それ以外はv1beta1Ingress を使用
- Kubernetes v1.19 以上であれば
- 一部のフィールドしか見ていなかったため、
v1beta1,v1のアダプタを作成して型の差分を吸収
前述の kubectl-convert も、元々 kubectl のサブコマンドでしたが、kubectl が Kubernetes の内部パッケージに依存しないように、プラグインとして分離されたようです (以下の kubectl convert: add deprecation warning for 1.13 #70820 のコメントを参照)。kubectl-convert プラグイン自体は Kubernetes レポジトリの内部で管理されています。
// Convert must be removed from kubectl, since kubectl can not depend on
// Kubernetes "internal" dependencies. These "internal" dependencies can
// not be removed from convert. Another way to convert a resource is to
Kubernetes 1.21 と 1.22 の API 差分 (diff)
以下は、Kubernetes API (/api/, /apis/) から取得した、Kubernetes v1.21 と v1.22 の API リストの差分です。末尾に D がつくものは deprecated であることを表します (Warning ヘッダで判別可能)。Kubernetes 1.22 で多くの API が削除されたことが確認できます。
参考までに、今までの各 Kubernetes の API バージョン対応表についても以下の記事にまとめました。
API の確認に使ったスクリプトと API リスト元データは、こちらの gist に置きました。
--- k8s-1.21.list 2021-08-24 10:45:51.000000000 +0900
+++ k8s-1.22.list 2021-08-24 10:44:22.000000000 +0900
@@ -1,50 +1,36 @@
admissionregistration.k8s.io/v1/mutatingwebhookconfigurations
admissionregistration.k8s.io/v1/validatingwebhookconfigurations
-admissionregistration.k8s.io/v1beta1/mutatingwebhookconfigurations D
-admissionregistration.k8s.io/v1beta1/validatingwebhookconfigurations D
apiextensions.k8s.io/v1/customresourcedefinitions
-apiextensions.k8s.io/v1beta1/customresourcedefinitions D
apiregistration.k8s.io/v1/apiservices
-apiregistration.k8s.io/v1beta1/apiservices D
apps/v1/controllerrevisions
apps/v1/daemonsets
apps/v1/deployments
apps/v1/replicasets
apps/v1/statefulsets
authentication.k8s.io/v1/tokenreviews
-authentication.k8s.io/v1beta1/tokenreviews
authorization.k8s.io/v1/localsubjectaccessreviews
authorization.k8s.io/v1/selfsubjectaccessreviews
authorization.k8s.io/v1/selfsubjectrulesreviews
authorization.k8s.io/v1/subjectaccessreviews
-authorization.k8s.io/v1beta1/localsubjectaccessreviews
-authorization.k8s.io/v1beta1/selfsubjectaccessreviews
-authorization.k8s.io/v1beta1/selfsubjectrulesreviews
-authorization.k8s.io/v1beta1/subjectaccessreviews
autoscaling/v1/horizontalpodautoscalers
-autoscaling/v2beta1/horizontalpodautoscalers
+autoscaling/v2beta1/horizontalpodautoscalers D
autoscaling/v2beta2/horizontalpodautoscalers
batch/v1/cronjobs
batch/v1/jobs
batch/v1beta1/cronjobs D
certificates.k8s.io/v1/certificatesigningrequests
-certificates.k8s.io/v1beta1/certificatesigningrequests D
coordination.k8s.io/v1/leases
-coordination.k8s.io/v1beta1/leases D
discovery.k8s.io/v1/endpointslices
discovery.k8s.io/v1beta1/endpointslices D
events.k8s.io/v1/events
-events.k8s.io/v1beta1/events
-extensions/v1beta1/ingresses D
+events.k8s.io/v1beta1/events D
flowcontrol.apiserver.k8s.io/v1beta1/flowschemas
flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations
networking.k8s.io/v1/ingressclasses
networking.k8s.io/v1/ingresses
networking.k8s.io/v1/networkpolicies
-networking.k8s.io/v1beta1/ingressclasses D
-networking.k8s.io/v1beta1/ingresses D
node.k8s.io/v1/runtimeclasses
-node.k8s.io/v1beta1/runtimeclasses
+node.k8s.io/v1beta1/runtimeclasses D
policy/v1/poddisruptionbudgets
policy/v1beta1/poddisruptionbudgets D
policy/v1beta1/podsecuritypolicies D
@@ -52,21 +38,12 @@
rbac.authorization.k8s.io/v1/clusterroles
rbac.authorization.k8s.io/v1/rolebindings
rbac.authorization.k8s.io/v1/roles
-rbac.authorization.k8s.io/v1beta1/clusterrolebindings D
-rbac.authorization.k8s.io/v1beta1/clusterroles D
-rbac.authorization.k8s.io/v1beta1/rolebindings D
-rbac.authorization.k8s.io/v1beta1/roles D
scheduling.k8s.io/v1/priorityclasses
-scheduling.k8s.io/v1beta1/priorityclasses D
storage.k8s.io/v1/csidrivers
storage.k8s.io/v1/csinodes
storage.k8s.io/v1/storageclasses
storage.k8s.io/v1/volumeattachments
-storage.k8s.io/v1beta1/csidrivers D
-storage.k8s.io/v1beta1/csinodes D
storage.k8s.io/v1beta1/csistoragecapacities
-storage.k8s.io/v1beta1/storageclasses D
-storage.k8s.io/v1beta1/volumeattachments D
v1/bindings
v1/componentstatuses D
v1/configmaps
Deprecation (非推奨)
- Service の
topologyKeysフィールド (alpha) のサポートと、そのkube-proxyの実装が削除されました。このフィールドは数サイクル前から deprecated となっていました。この機能は、Endpoint ごとの自動のトポロジーヒントと、Service のinternalTrafficPolicyフィールド(alpha) の組み合わせで置き換えられます。(#102412, @andrewsykim) - ( Ingress e2e で) Ingress
v1beta1が廃止されました (#102030, @aojea)
API Change (API の変更)
-
service.kubernetes.io/topology-aware-hintsアノテーションで、Autoが有効な値となりました。(#100728, @robscott)-
もともと
autoだったのが、Kubernetes でのネーミングルールに合わせて、Autoが有効になったようです。(autoも有効)
-
-
EndpointSlices Mirroring controllerはkubectlによって作られるlast-applied-configurationアノテーションをEndpointSlices更新時にミラーしなくなりました。(#102731, @sharmarajdaksh) -
NetworkPolicyEndPortがベータに昇格し、デフォルトで有効になりました。(#102834, @rikatz)-
NetworkPolicy の
endPortフィールドは、portフィールドと合わせて、ポートの範囲を表現できるものです。詳細は KEP-2079: Network Policy to support Port Ranges をご覧ください。
-
Feature (機能追加)
- Kubelet のユーザ空間での実行をサポートする、フィーチャーゲート
KubeletInUserNamespaceが追加されました。- ユーザ空間は kubelet の実行前に作成される必要があります。CRI などの全てのノードコンポーネントは、ユーザ空間で実行される必要があります。このフィーチャーゲートが有効なとき、kubelet は次の sysctl の値の設定時のエラーは無視します。
vm.overcommit_memory,vm.panic_on_oom,kernel.panic,kernel.panic_on_oops,kernel.keys.root_maxkeys,kernel.keys.root_maxbytes. (これらはコンテナではなく、ホスト向けの systectl の値です)。また kubelet は/dev/kmsgオープン時のエラーも無視します。また、このフィーチャーゲートによって、kube-proxy がRLIMIT_NOFILE設定時のエラーを無視するようになります。 - このフィーチャーゲートは、
kindまたはminikubeを使って、Rootless Docker/Podman 内で Kubernetes を実行するようなときに便利です。 (#92863, @AkihiroSuda) [SIG Network, Node and Testing]
- ユーザ空間は kubelet の実行前に作成される必要があります。CRI などの全てのノードコンポーネントは、ユーザ空間で実行される必要があります。このフィーチャーゲートが有効なとき、kubelet は次の sysctl の値の設定時のエラーは無視します。
- Endpoints が 1,000 以上のエンドポイントを持つ場合、切り詰めが行われるようになり、Endpoints リソースの
endpoints.kubernetes.io/over-capacityアノテーションにtruncatedとセットされるようになりました。 (#103520, @swetharepakula) [SIG Apps and Network] - kube-proxy でログレベルを動的に設定するための、
/debug/flags/vが公開されるようになりました。(#98306, @borgerli) [SIG Network]-
動的なログレベル変更は、以前から他のコンポーネント (kube-apiserver, kubelet, kube-scheduler) ではサポートされています。(Support dynamiclly set glog.logging.verbosity #63777)
-
- フィーチャーゲート
EndpointSliceProxyingとWindowsEndpointSliceProxyingは GA に昇格し、無条件で有効になりました。kube-proxy は、endpoint の情報として EndpointSlices を使うようになります。(#103451, @swetharepakula) - kube-proxy が V1 の
EndpointSlicesを使うようになりました。 (#103306, @swetharepakula)-
今までは
v1beta1の EndpointSlice を参照していました。
-
-
net.ipv4.ip_unprivileged_port_startを安全なsysctlとして扱うようになりました。(#103326, @pacoxu)-
安全な sysctl はホワイトリストとして管理されています。
-
- NetworkPolicy のバリデーションフレームワークが Windows をサポートしました。(#98077, @jayunit100)
- 新しいフィーチャーゲート
ExpandedDNSConfigが利用できるようになりました。このフィーチャーによって、Kubernetes で拡張された DNS の設定を持つことができるようになります。(#100651, @gjkim42)-
DNS のサーチパスの最大(
MaxDNSSearchPaths)が 6 から 32, サーチパスの文字列長の最大(MaxDNSSearchListChars)が 256 から 2048 へと拡張されます。詳細は KEP-2595: Expanded DNS Configurationをご覧ください。
-
-
EndpointSliceTerminatingConditionが Beta へと昇格しました。これにより、EndpointSlice のtermination,serving状態がデフォルトで有効になります。(#103596, @andrewsykim) -
EndpointSliceが有効な kube-proxy で iptables または ipvs モードを私用している場合、externalTrafficPolicy: Localを持った Service が、グレースフルターミネーションをサポートするようになりました。具体的には、ある Service の "Ready" なエンドポイントが存在しない状態でノードが Service への接続を受け、少なくとも１つの Terminating な Pod がノード上に存在するときは、kube-proxy はトラフィックをドロップせずに、Terminating な Pod へ送るようになります。これは、Pod が kill され、外部ロードバランサがそれを検知した場合の、レースコンディションが修正されます。(#97238, @andrewsykim) -
IngressClassNamespacedParamsフィーチャーゲートがベータに昇格し、デフォルトで有効になりました。これにより、IngressClassは新たに 2 つのフィールドspec.paramters.namespaceとspec.parameters.scopeを持つようになります。(#101711, @hbagdi) -
ServiceInternalTrafficPolicy機能がベータに昇格し、デフォルトで有効になりました。これにより、Service のinternalTrafficPolicyフィールドがデフォルトで有効になります。(#103462, @andrewsykim) -
ServiceLBNodePortControlがベータに昇格し、デフォルトで有効になりました。(#100412, @hanlins) -
SetHostnameAsFQDNが GA に昇格し、無条件で有効になります。(#101294, @javidiaz)
Bug or Regression (バグまたはリグレッション)
- デフォルトの
viewとeditの RBAC ロールに、EndpointSliceのための権限が追加されました。(#101203, @mtougeron) - Endpoint が zone を持たないときに、
EndpointSliceの describe がパニックになる問題が修正されました。(#101025, @tnqn) -
endpointslicemirroringコントローラーで、endpoint のNotReadyAddressesが対応するEndpointSliceに Ready としてミラーされるバグが修正されました。(#102683, @aojea) - winkernel の kube-proxy で、ホストとネットワークがデュアルスタックをサポートしている場合のみに、デュアルスタックを使うよう修正されました。@jsturtevant) [SIG Network and Windows]
-
kube-proxyのレイテンシメトリクスが、実行開始後に作られたEndpointsのレイテンシしか計算していないバグが修正されました。いつ作成されたかに関わらず、すべてのEndpointsオブジェクトは再起動時に処理される必要があります。(#100861, @aojea) -
kube-proxyのモードが userpace のとき、EndpointSlicesは有効とならないようになりました (#100913, @JornShen)-
userspace モードでは
EndpointSlicesの実装がされていないためのようです。
-
-
EndpointSliceの IP のバリデーションは、Endpointsのものと一致するようになりました。(#101084, @robscott) - "kube-proxy" のログ "Skipping topology aware endpoint filtering since no hints were provided for zone" の warning が正しい条件で出されるようになりました。(#101857, @dervoeti)
-
system:aggregate-to-editロールは、Endtpoints API への書き込み権限を持たないようになりました。Kubernetes 1.22 で新規にクラスタを作ったときは、editとadminロールは、この権限を持たなくなります。既存のクラスタを Kubernetes v1.22 にアップグレードした場合は影響がありません。新規に作成した 1.22 のクラスタで、集約されたeditとadminロールの Endtpoints に対する書き込み権限を保ちたい場合は、https://github.com/kubernetes/website/pull/29025 を参照してください。(#103704, @robscott) [SIG Auth and Network] - コンフォーマンステストで
-
IPFamilyPolicyがPreferDualstackに設定された Service の現在の挙動について。クラスタがデュアルスタックにアップグレードされたときの現在の振る舞いは- IPFamilyPolicy = PreferDualstack に設定された Service は、Service オブジェクトが更新されるとアップグレードされます。例: 利用者がラベルを変更したとき
- この振る舞いが次のように変更されます。
- IPFamilyPolicy = PreferDualstack に設定された Service は、Service オブジェクトが更新されてもアップグレードされません。利用者が policy, type などを変更しても、既存の振る舞いは維持されます。(#102898, @khenidak) [SIG Network and Testing]
-
Service の更新でデュアルスタックに自動的にアップグレードされてしまうと、割り当てられた IP アドレスが変わってしまうため問題があったようです。参考: Dual-stack updates w/ PreferDualStack changes IP assignments #101681
-
kube-proxyのベースイメージdebian-iptablesが https://github.com/kubernetes/release/pull/2106 を取り入れるため v1.6.2 にアップデートしました。-
debian-iptables: iptables-wrappers に合わせて、nft の行が legacy の行より多い場合に、nft モードを選択するようになりました。(#102590, @BenTheElder) -
iptables の nft, legacy については iptables: The two variants and their relationship with nftables が参考になります。
-
その他 (Cleanup or Flake)
- e2e スイートで "SCTP" と書かれているにも関わらず、実際には SCTP を実装していないネットワークプラグインの振る舞いのテストしている記述を明確にしました。(#102509, @danwinship)
- フィーチャーゲート
ServiceLoadBalancerClassはベータへと昇格し、デフォルトで有効になりました。(#103129, @XudongLiuHarold) -
proxy/ipvs/proxier.goのログを構造化ログへと移行しました。(#97796, @JornShen) - CNI プラグインを v0.9.1 にアップデートしました。(#102328, @lentzi90)
- Calico を v3.19.1 にアップデートしました。(#102386, @JornShen)
今後のトピックの紹介
SIG-Network で取り組まれているトピックで、個人的に気になったものを紹介します。動きが活発なため、記載した状況については参考までにしていただければと思います。なお、Kubernetes の次期バージョン v1.23 での状況は、Kubernetes 1.23 Enhancements Tracking でトラッキングされる予定です。
- IPv4/IPv6 デュアルスタックの GA
- v1.23 で stable に昇格予定: KEP-563 - Moving IPv4/IPv6 dual-stack networking to stable in 1.23 #2860
- Issue: Add IPv4/IPv6 dual-stack support #563
- gRPC probe の追加
- Pod の Liveness/Readiness/Startup probe で gRPC のヘルスチェック をサポートする動き
- Issue: Add gRPC probe to Pod.Spec.Container.{Liveness,Readiness,Startup}Probe #2727
- KEP: Add support for gRPC probes to kubelet (KEP-2727) #2728
- クラスタスコープの NetworkPolicy (
ClusterNetworkPolicy) の追加 -
Gateway API の公式 API への移行
- Gateway API は過去に "Service API" と呼ばれていたものがリネームされたもの
- 現在、experimental API (
x-k8s.io) である Gateway API を、公式のk8s.ioに移行させる動き - KEP レビュー中: KEP-2829: Formalize Gateway API transition to k8s.io group #2830
- Issue: Migrate Gateway API to k8s.io Group #2829
- Gateway API Meeting Notes
-
CNI トラフィック制御のサポート
- Kubernetes v1.9 からアルファで存在する機能
- KEP レビュー中: KEP-2819: CNI traffic shaping support #2808 (元々あったものを復活させている)
- Issue: CNI traffic shaping support #2819
参考