本篇文章作為一個經驗談,探討於 AWS EKS 的環境中要如何避免 IP 發放完畢。
對於 Kubernetes 來說,CNI 負責的功能主要有兩個,分別是 IPAM 以及 Network Connectivity.
公有雲管理的 Kubernetes 為了讓整體操作環境可以與其雲端內的其他元件有更好的整合,通常都會開發屬於自己的 CNI 系統,譬如 Azure, AWS, Google 都有這方面的設計。
這種設計的最大好處就是可以將 Pod 使用的 IP地址透過本來 VPC 內的設計去管理,而本文要討論的就是 AWS EKS 環境中可能會遇到的 IP 地址分配問題。
EKS 預設會使用 AWS VPC CNI 來提供相關服務,其底層實作主要牽扯到底層 ENI 的配置與設定,主要會影響到底還有多少個 IP 地址可以用來分配給新的 Pod 使用。
從 Cluster 的角度來看,要先注意的 VPC 內的網段設定,如果一開始分割的子網段是/28,這情況下你整個叢集內只能有30個左右的 IP 地址可以發放,這數量根本完全不太夠使用。
從單一節點的角度來看,要注意每個節點上可以配置多少個 ENI 以及每個 ENI 能夠配置多少網卡
該 CNI 分配 IP 時會先想辦法把現有網卡上面能夠分配的 IP 填滿,一旦填滿就會創立新的網卡,接者繼續分配 IP,當運行的 Pod 數量超過節點上現時就沒有辦法繼續分配 IP。
官方針對這種情況提供了一個公式去計算
(Number of network interfaces for the instance type × (the number of IP addressess per network interface - 1)) + 2
對於一個 m5.large 的機器來說,支援三張 ENI,且每個都有 10 個 IP 可以分配,因此根據上述公式
(3*(10-1))+2 = 29, 意味 m5.large 的機器上最多只能運行29個不使用 hostnetwork:true 的 Pod。
為了解決這些問題,作者提出了兩個想法,分別是
1. Adding additional IPv4 CIDR blocks to VPC
2. Change VPC CNI to Calico CNI
對這兩個想法有興趣的可以參考原文囉
https://matiaszilli.medium.com/avoiding-ip-consumption-in-amazon-eks-32fc7320253d
「calico network」的推薦目錄:
- 關於calico network 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於calico network 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於calico network 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於calico network 在 Calico - Cloud native networking and network security - GitHub 的評價
- 關於calico network 在 Network Policy and Calico - Kubernetes Networking 的評價
- 關於calico network 在 Calico Kubernetes CNI Provider in depth. - YouTube 的評價
- 關於calico network 在 Calico Cloud - Egress domain network policy issue 的評價
calico network 在 矽谷牛的耕田筆記 Facebook 的最佳解答
今年終於有時間來寫一個原創的長篇文章了,希望大家繼續支持
不知道大家有沒有想要透過 tcpdump 去錄製 Kubernetes 內Pod的封包但是常常卡關的情況?
今天這邊文章跟大家分享兩種不同的思路
1. 從封包內去錄製封包
2. 從節點上去錄製封包
針對第一點會探討三種方式,包括 kubectl sniff 以及 docker run 直接硬掛 network namespace。
第二種方式則會探討如果是 Flannel 以及 Calico 不同的網路架構下,要如何找到對應的虛擬網卡 (veth)。
如果你有任何不同的方式可以幫忙錄製封包也歡迎討論分享
https://www.hwchiu.com/k8s-tcpdump.html
calico network 在 矽谷牛的耕田筆記 Facebook 的精選貼文
這次帶來一篇 CNI 效能的文章分析,該文章介紹不同 CNI 基於 10G 網路下的效能評比,詳細請點連結
https://www.hwchiu.com/cni-performance-2020.html
參閱全文,
以下節錄重點
1. Kube-OVN 不但資源吃很多,效能還很不好
2. Canal/Calico/Flannel 三者的運算資源使用量都不多,且效能都很好
3. Kube-Router 的效能都很差,資源使用方便也不是特別出色
4. WeaveNet 與 Cilium 效能都不差,但是 Cilium 吃的效能很高,可說跟 Kube-OVN 同等級,而 WeaveNet 用到的資源少
5. 這次的實驗評比我認為其實能看到的東西有限,主要是不同的 CNI 所搭配的解決方案不同,目標要配合的情境也不同,雖然從圖表中可以看到 Kube-OVN 的綜合評比最差,但是其要用的場景本>身就不太一樣,單純用最原始的流量互打來判別優劣其實不太對
6. 如果今天要選擇網路 CNI 的時候,可以看到效能跟資源方面, Flannel/Calico/Canal 幾乎等級都差不多,而且 Calico 還支援加密與 Network Policy 等功能。
7. 此外,目前 Flannel 也從 Kubeadm 的官方教學頁面中移除,因為太多問題且維護者沒有要修復。所以我認為如果沒有特別使用情境需求的話,可以考慮使用 Calico.
8. Cilium 對於安全性以及 load-balancing 方面也有別的功能,就如同(5)點所提到,不同的場景有不同的需求,有些功能是獨占的。
calico network 在 Network Policy and Calico - Kubernetes Networking 的推薦與評價
An Ingress and Route Ingress controller,. Network Policies¶. By default, pods are non-isolated and accept traffic from any source. When defining a pod- or ... ... <看更多>
calico network 在 Calico Kubernetes CNI Provider in depth. - YouTube 的推薦與評價
In this video, I will comprehensively cover Calico CNI for Kubernetes. I will start with an overview of the Container Network Interface ... ... <看更多>
calico network 在 Calico - Cloud native networking and network security - GitHub 的推薦與評價
Calico is a widely adopted, battle-tested open source networking and network security solution for Kubernetes, virtual machines, and bare-metal workloads. ... <看更多>