本篇文章作為一個經驗談,探討於 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
ipv4地址 在 矽谷牛的耕田筆記 Facebook 的最佳解答
本篇文章帶來的是 Kubernetes 1.20 的一些整理,到底 Kubernetes 1.20 有什麼改變以及要如何升級舊有的 Kubernetes 到 1.20
官方宣稱該版本有 42 個改進,其中 11 個改進是該內容正式畢業進入 stable 版本, 15 個轉移到 beta 版本而剩下 16 個則是進入 alpha。
1. Volume Snapshot Operations (Stable)
針對容器快照的相關操作正式進入穩定版,要注意的是這個功能必須要使用的 Storage 服務有支援,同時請記得,針對任何的儲存設備,可以使用 CSI 來安裝就使用 CSI。
盡量不要繼續使用 in-tree 的方式去銜接這些設備了,因為所有的維護與修改都轉移到 CSI driver 上
2. Kubectl Debug (Beta)
Kubectl alpha 之前的子指令 debug 已經正式轉移到 beta 版本,未來可以直接使用 kubectl debug 的指令來幫忙一些資源的驗證與處理。
譬如
a. 創建一個 pod 部署到指定的節點上並存取節點上的檔案系統來提供對節點的除錯功能
b. 針對運行 crash 的 pod 除錯
3. Dual IP Stack IPv4/IPv6 (Alpha)
IPv4/IPv6 功能重新實作,未來將可以對單一 Serivce 同時指派 ipv4 + ipv6 的地址,同時也可以針對現存單一 ipv4 的 service 進行轉換
4. Graceful node shutdown (Alpha)
過往刪除 Pod 時都會有所謂的 pod lifecycle 等階段來處理一切狀態,但是當節點被關機時,節點上方運行的 Pod 並不會遵循 Pod lifecycle 來處理。
這個新的功能將會讓 Kubelet 去感知到節點正在關閉,並且能夠針對正在運行的Pod去提供 graceful shutdown 的過程
更多的討論可以參考下列文章或是直接看官方全文,滿多功能都慢慢改變
另外要注意的是,每次改版都要注意 API 是否有改變名稱,非常推薦使用如 kube-no-trouble 這類型的工具去檢查當前部署資源的 APIVersion 是否有即將要被捨棄的,避免 k8s 更新後應用程式都無法部署上去的情況發生
https://faun.pub/whats-new-in-kubernetes-version-1-20-and-how-to-upgrade-to-1-20-x-5ea72f904e7d
ipv4地址 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
這是一篇幻想文,幻想如果你可以重新設計 Kubernetes,你會希望有什麼樣的改動。也因為是幻想文,所以以下所提的東西不一定真的可以實作,也沒有考慮實作上可能會有什麼困難。原文非常的長,所以這邊就稍微列出一些內容
# 前提
作者(David Anderson, MetalLB 的主要貢獻者)認為 Kubernetes 真的很複雜,從 MetalLB 的開發經驗來看,幾乎無法開發出一個永遠不會壞且與 k8s 整合的軟體。
k8s 發展快速,一些不相容的修改也很難除錯,往往導致這些整合應用程式一起壞掉。
此外,作者使用 GKE 的經驗讓他覺得就算是這些k8s專家,也很難大規模環境中平安順利的使用 k8s.
作者認為 k8s 就像是管理平台內的 c++,功能非常強大,什麼都可以做,但是它會一直傷害你,直到你奉獻餘生該領域內。
作者期盼有一天,可以出現一個像是 go 語言的管理平台,簡單,優雅,容易學習
接下來就來看一下如果時光倒流,作者會希望 k8s 有哪些功能
# Mutable Pod
不像其他的資源一樣, Pod 這個資源基本上是不能修改的,有任何的更動都需要先刪除,後重新部署這樣兩步走來處理。
作者希望可以有一種 Pod 是可以支援即時修改的。
舉例來說,我透過 kubectl edit 修改了 Pod Image,然後只要透過 SIGTERM 送給 Runc 底層容器,然後當該 Container 被重啟,就會使用新的設定。這一切的發生都在同一個 Pod 的資源內,而不是重新產生一個新的 Pod
# Version control all the things
當 Pod 可以修正後,下一個作者想要的功能就是基於 Pod 本身的 Rollback。這意味希望叢集內可以有這些資訊可以去紀錄每次的變化
為了實現這個功能,可能每個節點上面也要去紀錄過往的所有 image 版本資訊,並且加上 GC 等概念來清除過期或是太舊的內容
# Replace Deployment with PinnedDeployment
相對於 Deployment, PinnedDeployment 最大的改動就是一個 Deployment 內可以同時維護兩個版本的 Pod。
舉例來說,我今天要將 Nginx 從 1.16 升級到 1.17,我可以透過 PinnedDeployment 去部署 Nginx,其中 1.16 佔了 60% ,而新版本 1.17 佔了 40%。
當一切轉移都沒有問題後,可以逐漸地將新版本的比例遷移到 100% 來達成真正的移轉。
原生的 Deployment 要達到這個功能就要創建兩個 Deployment 的物件來達到這個需求。
# IPv6 only, mostly
作者期望能的話,想要把 k8s networking 內的東西全部移除,什麼 overlay network, serivce, CNI, kube-proxy 通通移除掉。
k8s 全面配置 IPv6,而且也只有 IPv6,通常來說你的 LAN 都會有 /64 這麼多的地址可以分配 IPv6,這個數量多到你根本不可能用完 (2^64)。
也因為都有 public IPv6 的緣故,所有的存取都採用 Routing 的方式,封裝之類的玩法也不需要了。
文章內還提了很多東西,譬如說如果今天真的需要導入 IPv4 於這個純 IPv6 的系統上,可以怎麼做,如何設計 NAT64 等,算是非常有趣的想法
# Security is yes
作者認為安全性方面要最大強化,預設情況下要開啟 AppArmor, seccomp profile 等控管機制,同時也要全面禁止用 Root 來運行容器, 基本上就是用非常嚴格的方式來設定安全性方面的規則。
目前 Kubernetes 內的資源, Pod Security Policy 非常類似作者想要完成的東西,通過這種機制確保所有部署的 Pod 都會符合這些條件。唯一美中不足的是 Pod Security Policy 也不是預設就有的規則。
# gVisor? Firecracker?
從安全性考量出發,是否預設改使用 gVisor 或是 Firecracker 這類型的 OCI Runtime 而非 Runc,同時搭配上述的各種安全性條件來打造非常嚴苛的運行環境
# VMs as primitives
是否可以讓 kubernetes 同時管理 container 以及 virtual machine,也許就會像是將 kubevirt 變成一個內建的功能,讓 kubernetes 更加靈活的使用
除了上面之外,文章內還有許多其他的想法,但是內容都滿長的,如果有興趣的可以點選下列連結參考看看
https://blog.dave.tf/post/new-kubernetes/
ipv4地址 在 IPv4 地址介紹 - YouTube 的推薦與評價
學校技術支援人員培訓視頻短片(Training Video Clips for Technical Support Staff of Hong Kong Schools). IPv4 地址 介紹. 566 views 6 years ago. ... <看更多>