Kubernetes 1.16 の Changelog の SIG-Network に関連する内容をまとめました。
Notable Features
Beta
-
Network: Service LoadBalaner の finalizer に対する保護機能がベータとなり、デフォルトで有効になりました。この機能によって、紐付けられたロードバランサのリソースが削除されるまで、Service リソースは削除されないようになります。 (#81691, @MrHohn)
Misc
-
Network: EndpointSlice の feature gate を有効にした際に、kube-proxy も EndpointSlice を見るようになりました (#81430, @robscott)-
Endpoint Slice は v1.16 でアルファとして導入された、 Endpoint リソースの代替となるものです。詳細は後述しています。
-
-
Network: controller manager で IPV6 のデュアルスタックを設定できるようになしました。--cluster-cidr="<cidr1>,<cidr2>"で設定可能です。-
CIDR の指定の最初の2つのみが使われます(アルファではソフトリミットで、今後取り除かれる可能性があります)
-
--cidr-allocator-type. としてはデフォルトの "RangeAllocator" のみが許可されます。CloudAllocator は IPV6 デュアルスタックとは互換性がありません
(#73977, @khenidak) -
IPv4/IPv6 dual-stack という公式ドキュメントが追加されています。
--cluster-cidr=10.244.0.0/16,fc00::/24のように、IPV4, IPV6 それぞれの cidr を指定するようです。
-
Other notable changes
- IPVS のグレースフルシャットダウンにて、UDP の Real サーバーが削除されない文字列比較のバグを修正。(#78999, @andrewsykim)
-
IPVS で UDP の場合はグレースフルシャットダウンをしないというロジックで、大文字、小文字の
UDP,udpを case-sensitive に扱っていたことにより正しく動いていなかったバグのようです。case-insensitive に修正されました。
-
-
kube-proxy --cleanup willはクリーンアップの成功時に正しい終了コードを返すようになりました (#78775, @johscheuer)-
今までは一律
klog.Fatal()で終了していて、終了コードが 255 となっていたようです
-
- IPVS proxier で対応する Service オブジェクトが削除されたにも関わらず、Virtual サーバーがクリーンアップされないバグが修正されました。(#80942, @gongguan)
- kube-proxy はノードが定義されるまでのある程度の間を待つようになりました (#77167, @paulsubrata55)
-
kube-proxy の起動時に Node オブジェクトから IP アドレスを取得する関係で、kubelet が Node オブジェクトを登録するまで待つ必要がありました
-
- グレースフルシャットダウンのログレベルを
v=5に増やしました (#80100, @andrewsykim)-
元々は
v=2だったため大量にログが出る問題があったようです
-
- IPVS モードで nodePort を利用するService が大量にあった場合の、kube-proxy の CPU 使用量が削減されました (#79444, @cezarsa)
- IPVS が有効な場合、kube-proxy で SCTP の nodeport の Service は Node の Internal IP だけで動作し、その他のノード上の IP で動作しない問題が修正されました (#81477, @paulsubrata55)
- IPVS モードの kube-proxy で
KUBE-MARK-DROPの存在がチェーンが保証されるようになりました。このチェーンはデュアルスタックの IPV4, IPV6 の両方で保証されます (#82214, @uablrek)-
IPVS の場合は、このチェーンは kubelet 側で作られる仕様に依存している問題があったようです。IPVS の場合も kube-proxy 側でこのチェーンを作るようになり解消されました。
-
-
node.kubernetes.io/exclude-balancerとnode.kubernetes.io/exclude-disruptionラベルがアルファとして導入されました。これによってクラスタのデプロイにおいて、すべてのクラスタで提供されているわけではいないオプショナルなnode-roleラベルへの依存を避けることができます (#80238, @smarterclayton) - targetPort が変更された場合にも Service Controller で処理されるようになりました (#77712, @Sn0rt)
EndpointSlice について
Endpoint Slice は v1.16 でアルファとして導入された、 Endpoint リソースの代替となる機能です。
Endpoint の課題
今までの Endpoint は 1 オブジェクトで、1 Service の すべての Endpoint の情報(Pod IP や Node)を管理していました。例えば 5000 ノードのような大規模環境で 1 Service に大量の Pod がいるような場合、パフォーマンス上の問題がありました。
- すべての Endpoint の情報 (Pod IP などの情報) が一つの Endpoint オブジェクトに入っている
- etcd レイヤで 1 オブジェクトで最大 1.5 MB という制限がある
- 10,000 Pod でエラーとなったという issue が上がっている
- 一つの Endpoint に変更に対して Endpoint オブジェクト全体を書き換えないといけない
- 大規模環境だと rolling-update などでパフォーマンス低下が顕著になる
- 通信量のオーダーが O(P^2N) となってします (P=Pod数、N=ノード数)
以下は一部省略した Endpoint のリソースです。
apiVersion: v1
kind: Endpoints
metadata:
name: default-http-backend
namespace: kube-system
subsets:
- addresses:
# 各 Endpoint の情報がすべて配列として管理されている
- ip: xxx.xxx.xxx.xxx
nodeName: node1
targetRef:
kind: Pod
name: default-http-backend-6f89599f78-pjxzt
namespace: kube-system
- ip: yyy.yyy.yyy.yyy
nodeName: node2
targetRef:
kind: Pod
name: default-http-backend-6f89599f78-dx9pc
namespace: kube-system
ports:
- port: 8080
protocol: TCP
EndpointSlice
EndpointSlice ではデフォルト 100 の単位で、Endpoint の情報を管理することでこの課題を解決します。Endpoint の情報を 1:1 で管理しなかった理由は、そうすると別の問題が発生するからのようです。参考: EndpointSlice API の KEP。
- EndpointSlice が 1 オブジェクト 1 情報を管理する場合
- 今度は Node (kube-proxy) が watch する量が莫大になる
- 20,000 Endpoint, 5000 Node だと、20,000 * 5,000 = 100,000,000 の watch となってしまう
- 100 単位で管理すると、watch の数も 100 分の1 となる
- バッチで update する処理もあるので 1 個だとパフォーマンスが下がる
- ほとんどの利用者は 100 以下の Endpoint の Service を使っているので 100 であれば今までと同じ
- 検討の結果 100 がちょうど良いサイズだったようです。KEP に見積もりが載っています。