What's New (主な変更)

IPv4/IPv6 デュアルスタックネットワーキングが GA に

IPv4/IPv6 デュアルスタックネットワーキングが GA (General Availability) となりました。1.21 から、Kubernetes クラスタはデュアルスタックネットワーキングのサポートがデフォルトで有効です。1.23 で、IPv6DualStack フィーチャーゲートは削除されました。デュアルスタックネットワーキングの使用は、必須ではありません。クラスタではデュアルスタックネットワークのサポートが有効になっていますが、Pod と Service のデフォルトは引き続きシングルスタックとなっています。

デュアルスタックネットワーキングを使用するには、次のことが必要です。

Kubernetes ノードがルーティング可能な IPv4/IPv6 のネットワークインターフェスを持つ
デュアルスタックに対応した CNI ネットワークプラグインの使用
Pod がデュアルスタックに設定されている
Service が PreferDualStack または RequireDualStack に設定された .spec.ipFamilyPolicy フィールドを持つ

IPv6DualStack のフィーチャーゲートのフラグ自体は残っています。しかし、変更不可 (LockToDefault: true) かつ、このフラグによる分岐が削除されています。(変更 PR: move IPv6DualStack feature to stable. #104691)

IPv4/IPv6 デュアルスタックネットワーキングの歴史を、以下に簡単にまとめてみました。alpha での導入から GA まで約 2 年 3 ヶ月でした。

Kubernetes バージョン	段階
v1.16 (2019年9月)	alpha
v1.21 (2021年4月)	beta
v1.23 (2021年12月)	GA (stable)

Kubernetes 1.22 と 1.23 の API 差分

Kubernetes API (/api/, /apis/) から取得した情報を使って、Kubernetes 1.22 と 1.23 の API の差分を確認しました。差分は以下になります。今回は大きな差分はありませんでした。

API の追加
- autoscaling/v2/horizontalpodautoscalers
- flowcontrol.apiserver.k8s.io/v1beta2/flowschemas
- flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations
API の削除: なし
Deprecation の指定
- autoscaling/v2beta2/horizontalpodautoscalers
- flowcontrol.apiserver.k8s.io/v1beta1/flowschemas
- flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations

参考までに、今までの各 Kubernetes の API バージョン対応表を以下の記事にまとめています。(Kubernetes 1.23 時点での情報に更新しました)

kind で IPv４/IPv6 デュアルスタックを試す

kind (Kubernetes IN Docker ) を使うと、簡単にローカルでデュアルスタックを試せます。なお、minikube は、v1.24.0 時点では IPv6 をサポートしていません。 (参考: Add support for IPv6 #8535)。

デュアルスタッククラスタの作成

まずは、デュアルスタックを設定した kind の設定ファイルを用意します。

dual-stack-cluster.yaml

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  # Kubernetes v1.23.0 のイメージを指定
  image: kindest/node:v1.23.0@sha256:49824ab1727c04e56a21a5d8372a402fcd32ea51ac96a2706a12af38934f81ac
- role: worker
  image: kindest/node:v1.23.0@sha256:49824ab1727c04e56a21a5d8372a402fcd32ea51ac96a2706a12af38934f81ac
networking:
  ipFamily: dual # dual-stack の設定
  apiServerAddress: 127.0.0.1

この設定ファイルを指定して、クラスタを作成します。

kind create cluster --config ./dual-stack-cluster.yaml

デュアルスタックを試す

kind で作成したクラスタ上で、Pod を作成してみます。

apiVersion: v1
kind: Pod
metadata:
  name: dualstack-test
  labels:
    app: dualstack-test
spec:
  containers:
  - name: nginx
    image: nginx:1.21.5
    ports:
    - containerPort: 80

kubectl describe で IP アドレスを確認します。IPv4, IPv6 の 2 つのアドレスが割り当てられていることがわかります。なお、kubectl v1.23.1 時点では kubectl get で -o wide を付けても、IPv4 アドレスのみしか表示されません。

$ kubectl describe pod dualstack-test
...
Status:       Running
IP:           10.244.1.2
IPs:
  IP:  10.244.1.2
  IP:  fd00:10:244:1::2  # IPv6 アドレス

デュアルスタックを指定して、Service を作成します。

apiVersion: v1
kind: Service
metadata:
  name: dualstack-test
spec:
  selector:
    app: dualstack-test
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  # dual-stack を指定
  ipFamilyPolicy: RequireDualStack

kubectl describe で IP アドレスを確認します。IP Families に IPv4, IPv6 の 2 つが表示され、IPs に IP v4, IPv6 の両方のアドレスが表示されていることがわかります。

$ kubectl describe svc dualstack-test
...
IP Family Policy:  RequireDualStack
IP Families:       IPv4,IPv6
IP:                10.96.49.168
IPs:               10.96.49.168,fd00:10:96::8b08

EndpointSlice は IPv4, IPv6 で別々に作られます。

$ kubectl get endpointslices.discovery.k8s.io -l kubernetes.io/service-name=dualstack-test
NAME                   ADDRESSTYPE   PORTS   ENDPOINTS          AGE
dualstack-test-2dvwv   IPv4          80      10.244.1.2         26m
dualstack-test-lj5xl   IPv6          80      fd00:10:244:1::2   26m

なお、非デュアルスタック環境のクラスタで Service に RequireDualStack を指定すると、作成時点で以下のようなエラーになります。

The Service "dualstack-test" is invalid: spec.ipFamilyPolicy: Invalid value: "RequireDualStack": this cluster is not configured for dual-stack services

実際に作成した Service の IPv6 アドレス (fd00:10:96::8b08) を使って、Pod からアクセスできることを確認します。

確認用の Pod を作成します。

kubectl run -it --rm --restart=Never --image busybox debug

Pod のシェルを使って、IPv4, IPv6 のそれぞれのアドレスでアクセスしてみます。どちらとも正しくアクセスできました。

/ # wget -qO- http://10.96.49.168/ | grep title
<title>Welcome to nginx!</title>

/ # wget -qO- http://fd00:10:96::8b08/ | grep title
<title>Welcome to nginx!</title>

Deprecation (非推奨)

kube-proxy の Userspace proxier を使用した際の、非推奨の通知が追加されました。この機能は v1.25 で削除予定です。 (#103860) (#104631, @perithompson)

API Change (API の変更)

kube-proxy の UDP Service におけるリグレッションを修正しました。これは、失効 (stale) したコネクションを検出するロジックが、エンドポイントが ready かどうかを考慮していなかったためです。(#106163, @aojea) [SIG API Machinery, Apps, Architecture, Auth, Autoscaling, CLI, Cloud Provider, Contributor Experience, Instrumentation, Network, Node, Release, Scalability, Scheduling, Storage, Testing and Windows]
IngressClass.Spec.Parameters.Namespace フィールドが GA になりました。 (#104636, @hbagdi)
IPv6DualStack 機能が stable となりました。
Node IPAM Controller のための Conroller Manager のフラグが少し変更されています。
1. デュアルスタッククラスタとして設定時は、利用者は以前の --node-cidr-mask-size に代わって --node-cidr-mask-size-ipv4 と --node-cidr-mask-size-ipv6 の両方にノードごとの IP マスクサイズに設定する必要が必要があります。
2. --node-cidr-mask-size フラグは、--node-cidr-mask-size-ipv4 と --node-cidr-mask-size-ipv6 が相互に排他的となります。
3. シングルスタッククラスタでは変更の必要はありませんが、より明確なフラグを指定できます。利用者は、古いフラグ --node-cidr-mask-size、もしくは新しいフラグの --node-cidr-mask-size-ipv4 と --node-cidr-mask-size-ipv6 のどちらかを使用して、ノードごとの IP マスクサイズを設定できます。ただし、フラグの IP ファミリはクラスタの IP ファミリ (--cluster-cidr) と一致する必要があります。 (#104691, @khenidak)
Service 更新の小さいリグレッションが修正されました。状況の起きる可能性は極めて低いため、おそらく誰もこの問題に当たる可能性はありませんでした。 (#104601, @thockin) [SIG Network]
kube-apiserver: 列挙型 (enum) に null 値のリテラルを含む CRD スキーマの処理を修正しました。 (#104969, @liggitt) [SIG API Machinery, Apps and Network]
Kubernetes は go1.17 でビルドされるようになりました。 (#103692, @justaugustus) [SIG API Machinery, Apps, Architecture, Auth, Autoscaling, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Scheduling, Storage and Testing]
golang 1.17 から、net.ParseIP と net.ParseCIDR の両方で、ドット十進表記の IPv4 アドレスで先頭のゼロを拒否するようになりました。Kubernetes では互換性を保持するため、IPv4 アドレスにおける先頭のゼロを許容し続けます。
- 重要: Kubernetes は IPv4 アドレスの先頭ゼロを 10 進数として解釈します。利用者は関連するセキュリティ勧告の影響を受けないように、パーサーのアライメントに依存してはいけません。
- CVE-2021-29923 golang 標準ライブラリ "net" - golang 1.16.2 以下の標準ライブラリ "net" の八進数リテラルの不適切な入力検証によって、不定の SSRF と RFI の脆弱性が発生します。
- Reference: https://nvd.nist.gov/vuln/detail/CVE-2021-29923 (#104368, @aojea) [SIG API Machinery, Apps, Architecture, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Scalability, Scheduling, Storage and Testing]
Service をデュアルスタックとして作成・更新するには、Service.spec.ipFamilyPolicy フィールドが必須となりました。これはベータの動から破壊的な変更になります。以前まではサーバーはフィールドの値を ipFamilies または clusterIPs から推測していましたが、これは更新時の曖昧さを招いていました。利用者がデュアルスタックの Service を希望する場合は、ipFamilyPolicy に PreferDualStack または RequireDualStack を指定する必要があります。(#96684, @thockin) [SIG API Machinery, Apps, Network and Testing]
kube-apiserver: rbac.authorization.k8s.io/v1alpha1 API バージョンが削除されたため、v1.8 から利用できる rbac.authorization.k8s.io/v1 を使用してください。scheduling.k8s.io/v1alpha1 API バージョンが削除されたため、v1.14 から利用できる scheduling.k8s.io/v1を使用してくさい。 (#104248, @liggitt) [SIG API Machinery, Auth, Network and Testing]
- 実際には API としては以前から廃止されていたもので、ストレージとバリデーションのコードからクリーンアップされたものになります。
- バージョンを読み書きするためのコーデックは削除されておらず、etcd に保存されている古いバージョンは引き続き読めるようです。(参考: Drop dead beta storage and validation code #104248)

Feature (機能追加)

csi-translation-lib に Portworx プラグインのサポートが追加されました。アルファリリースです。
移行には、Portworx CSI ドライバが必要です。この PR によって、CSIMigrationPortworx フィーチャーゲートのサポートが追加されます。これは次の手順で有効になります。
1. kube-controller-manager にフィーチャーフラグ --feature-gates=CSIMigrationPortworx=true を追加
2. kubelet の設定に、次のフィーチャーフラグを追加:
  featureGates:
  CSIMigrationPortworx: true
  (#103447, @trierra) [SIG API Machinery, Apps, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Scalability, Scheduling, Storage, Testing and Windows]
Topology Aware Hints がベータとなりました。 (#106433, @robscott) [SIG Network]
CVE の修正のため debian-iptables を v1.6.7 にアップデートしました。 (#104970, @PushkarJ) [SIG API Machinery, Network, Release, Security and Testing]

Documentation (ドキュメント)

テスト "[sig-network] EndpointSlice should have Endpoints and EndpointSlices pointing to API Server [Conformance]" は、"kubernetes.default" service の Endpoint Slice の存在だけが必須となり、"kubernetes" という名前である必要はなくなりました。 (#104664, @aojea)

Bug or Regression (バグまたはリグレッション)

EndpointSlice Mirroring コントローラーは、Service セレクタが追加されたときに管理している EndpointSlices をクリーンアップするようになりました。 (#105997, @robscott) [SIG Apps, Network and Testing]
kube-proxy の sync_proxy_rules_iptables_total メトリクスが、今まで 1 つずつずれていたものが、正しいルール数を返すようになりました。1.22 で発生した複数の iptables proxy の不具合が修正されています。
- SessionAffinity の Service の使用時、エンドポイントが ready でなくなったときにエンドポイントに対するクライアントのアフィニティが切れるようになりました。 (エンドポイントが完全に削除されるまで続くのではなく)
- Service IP へのトラフィックは、利用可能なエンドポイントがなくなったり次第、拒否 (reject) されるようになりました(ただ drop されるのと反対に)。今までは停止中 (terminating) のエンドポイントは、それが使用されていない場合でもすべて停止するのを待っていました。
- 使用されないエンドポイントのためのチェインが、iptables に出力されなくなりました。これにより、メモリ・時間・CPU が少し節約されます。 (#106030, @danwinship) [SIG Network]
Kube-proxy は Topology Aware Hints が有効な場合の Service に対して、準備できていない (unready) エンドポイントを除去するようになりました。 (#106507, @robscott)
Topology Aware Hints はヒントが割り当てられたとき、準備ができていない (unready) エンドポイントを無視するようになりました。(#106510, @robscott)
EndpointSlice コントローラが、Topology Aware Hints が有効な Service に紐づく EndpointSlices を、不必要に更新する可能性があるバグが修正されました。 (#105267, @llhuii)
Topology Hints は、キャパシティの計算からコントロールプレーンノードを除外するようになりました。(#104744, @robscott)
- 原文では control plane notes とありますが、PR のタイトル・内容を見る限り nodes の typo ではないかと思われます。なおノードに node-role.kubernetes.io/control-plane、node-role.kubernetes.io/master のどちらかのラベルかがある場合に、コントロールプレーンノードと判断されていました
--log-flush-frequency はいくつかのコマンドで効果がないか、存在していませんでした。ヘルプや警告のテキストは、コマンドに対して必ずしも正しいフォーマットになっていませんでした (例えば add-dir-header の代わりに add_dir_header が使われていた)。この修正には、component-base/logs のフラグ処理のクリーンアップも含まれており、このパッケージでグローバルのフラグセットにフラグを追加しなくなりました。klog と --log-flush-frequency フラグを使用したい場合は、logs.AddFlags を必ず明示的に呼び出してください。新しい cli.Run ではこれを行ってくれます。このヘルパー関数は、フラグの標準化および、一貫性を持った使用方法とエラーの表示をカバーします。(パースに失敗した場合は、使用方法のテキストを表示し、次にエラーを表示する) (#105076, @pohly)
kube-proxy の開始の挙動が変更されました。現在の sysctl の値がすでにそれより高い値に設定されている場合、特定の sysctl の値を設定しないようになりました。(非 init ネームスペースでは、最近のカーネルバージョンでは動作しない) (#103174, @Napsty) [SIG Network]
- この PR では nf_conntrack_* のパラメータが対象となっていました
デュアルスタックを有効にせず作成されたセレクタが存在しない Headless Service は、 PreferDualStack の代わりに RequireDualStack がデフォルトになりました。これはデュアルスタックが有効で作成された Service と一貫性があります。(#104986, @thockin) [SIG Network]
ipvs モードで、SCTP プロトコルの NodePort service のクライアント IP アドレス保持するように修正しました。(#104756, @tnqn) [SIG Network]
kube-pxory のヘルスチェックのポートでは、各 Service に対して :<port> で listen していました。これは、不要かつクラスタ利用者が意図していないアドレスでポートを開いていました。この PR では、--nodeport-addresses フラグで制御されるすべてのノードのアドレスに listen するように制限します。もしアドレスが指定されなかった場合、各 Service に対して :<port> で listen する既存の挙動がデフォルトになります。 (#104742, @khenidak) [SIG Network]
kube-proxy: ロードバランサの Ingress IP 用の失効 (stale) した conntrack UDP エントリを削除するようになりました。 (#104009, @aojea) [SIG Network]

その他 (Cleanup or Flake)

pkg/proxy を構造化ロギングに移行しました。 (#104891, @shivanshu1333)
pkg/proxy/ipvs を構造化ロギングに移行しました。 (#104932, @shivanshu1333)
cmd/proxy/{config, healthcheck, winkernel} を構造化ロギングに移行しました。 (#104944, @jyz0309) [SIG Network]
pkg/proxy/util を構造化ロギングに移行しました。 (#104908, @CIPHERTron) [SIG Network]
pkg/proxy/winuserspace を構造化ロギングに移行しました。 (#105035, @shivanshu1333) [SIG Network]
pkg/proxy/userspace を構造化ロギングに移行しました。 (#104931, @shivanshu1333) [SIG Network]
cmd/kube-proxy/app を構造化ロギングに移行しました。 (#98913, @yxxhero) [SIG Network]
EndpointSlice コントローラーに、Topology Aware Hints のためのより詳細なロギングを追加しました。 (#104741, @robscott)
API サーバーに、Service の CIDR 割当の状況をトラックできるようにする 4 つのメトリクスが公開されました。
- Service CIDR ごとの利用可能な IP 数
- Service CIDR ごとの使用済み IP 数
- Service CIDR ごとの割当の総計
- Service CIDR ごとの割当エラーの総計 (#104119, @aojea) [SIG Apps, Instrumentation and Network]

CIDR 割当の状況のメトリクスは、以下のように CIDR がラベルに入っています。デュアルスタック環境では、IPv4 / IPv6 それぞれの CIDR のメトリクスを見られます。以下はデュアルスタック環境の例です。

$ kubectl get --raw /metrics | egrep ^kube_apiserver_clusterip
kube_apiserver_clusterip_allocator_allocated_ips{cidr="10.96.0.0/16"} 0
kube_apiserver_clusterip_allocator_allocated_ips{cidr="fd00:10:96::/112"} 0
kube_apiserver_clusterip_allocator_allocation_total{cidr="10.96.0.0/16"} 42
kube_apiserver_clusterip_allocator_allocation_total{cidr="fd00:10:96::/112"} 15
kube_apiserver_clusterip_allocator_available_ips{cidr="10.96.0.0/16"} 65534
kube_apiserver_clusterip_allocator_available_ips{cidr="fd00:10:96::/112"} 65535