《Windows Azure Platform 系列文章目錄》
我們在搭建Kubernetes集羣的時候，需要搭建控制節點(Master)和工作節點(Node)，在每個節點上都會安裝不同的組件
Master: 集羣的控制平面，負責集羣的決策
- ApiServer : 資源操作的唯一入口，接收用戶輸入的命令，提供認證、授權、API註冊和發現等機制
- Scheduler : 負責集羣資源調度，按照預定的調度策略將Pod調度到相應的node節點上
- ControllerManager : 負責維護集羣的狀態，比如程序部署安排、故障檢測、自動擴展、滾動更新等
- Etcd ：負責存儲集羣中各種資源對象的信息
Node：集羣的數據平面，負責爲容器提供運行環境
- Kubelet : 負責維護容器的生命週期，即通過控制docker，來創建、更新、銷燬容器
- KubeProxy : 負責提供集羣內部的服務發現和負載均衡
- Docker：負責節點上容器的各種操作
我們在使用Azure Kubernetes集羣的時候，控制節點是由微軟雲Azure平臺運維的，用戶無需管理控制節點的底層硬件部署，也無需爲控制節點支持費用。
AKS最佳實踐，我在這裏總結一下：
1.Azure China鏡像倉庫：
目前 *.azk8s.cn 已經僅限於 Azure China IP 使用，不再對外提供服務。
即在Azure AKS pull image沒有問題，但是如果是本地PC機，則無法pull image from *.azk8s.cn
| 海外倉庫地址 | 國內鏡像倉庫 | format | example |
| dockerhub | dockerhub.azk8s.cn | dockerhub.azk8s.cn/<repo-name>/<image-name>:<version> |
dockerhub.azk8s.cn/microsoft/azure-cli:2.0.61 dockerhub.azk8s.cn/library/nginx:1.15 |
| gcr.io | gcr.azk8s.cn | gcr.azk8s.cn/<repo-name>/<image-name>:<version> | gcr.azk8s.cn/google_containers/hyperkube-amd64:v1.18.4 |
| us.gcr.io | usgcr.azk8s.cn | usgcr.azk8s.cn/<repo-name>/<image-name>:<version> | usgcr.azk8s.cn/k8s-artifacts-prod/ingress-nginx/controller:v0.34.1 |
| k8s.gcr.io | k8sgcr.azk8s.cn | k8sgcr.azk8s.cn/<repo-name>/<image-name>:<version> |
k8sgcr.azk8s.cn/ingress-nginx/controller:v0.35.0 k8sgcr.azk8s.cn/autoscaling/cluster-autoscaler:v1.18.2 |
| quay.io | quay.azk8s.cn | quay.azk8s.cn/<repo-name>/<image-name>:<version> | quay.azk8s.cn/deis/go-dev:v1.10.0 |
| mcr.microsoft.com | mcr.azk8s.cn | mcr.azk8s.cn/<repo-name>/<image-name>:<version> | mcr.azk8s.cn/oss/nginx/nginx:1.17.3-alpine |
2.AKS有兩種網絡模型：
(1)Kubenet網絡
- Node和Pod會部署在2個subnet裏
- 只有Node纔會有內網IP地址。Pod沒有內網Ip地址
- Pod會使用NAT與AKS集羣外部的其他資源通信
(2)Azure CNI網絡
- Node和Pod可以部署在同一個Subnet裏
- Node和Pod都有內網IP地址
3.網絡模型比較
(1)Kubenet
- 節省IP地址空間
- 使用 Kubernetes 內部或外部負載均衡器可從羣集外部訪問 Pod
- 可手動管理和維護用戶定義的路由 (UDR)
- 每個羣集最多可包含 400 個節點
(2)Azure CNI
- Pod 建立了全面的虛擬網絡連接，可以通過其專用 IP 地址直接從已連接的網絡對其進行訪問
- 需要更多的IP地址空間
4.AKS部署的先決條件
- AKS 羣集的虛擬網絡必須允許出站 Internet 連接。
- AKS 羣集不得將 169.254.0.0/16、172.30.0.0/16、172.31.0.0/16 或192.0.2.0/24 用於 Kubernetes 服務地址範圍、Pod 地址範圍或羣集虛擬網絡地址範圍。
- AKS 羣集使用的羣集標識在虛擬網絡中的子網上必須至少具有網絡參與者權限。 如果希望定義自定義角色而不是使用內置的網絡參與者角色，則需要以下權限：
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
- 分配給 AKS 節點池的子網不能是委託子網。
這裏的委託子網，指的是Azure subnet保留的內容，比如某些Azure PaaS需要創建在特殊命名的subnet裏，比如Azure Firewall 需要創建在firewall subet裏；Gateway需要創建在gateway subnet裏。
5.我們在使用Kubenet或者Azure CNI不同的網絡模型，需要預留足夠的內網IP地址
如下圖所示，我們先觀察Kubenet裏的內容
- 在默認情況下，Kubenet模型裏，最大支持400個Node。每個Node默認情況下，最多可以運行110個Pod
- 所以下圖中507個、1019個、2043個Node等情況，都是不支持的，最大隻支持400個Node
我們再觀察Azure CNI網絡模型：
- 在默認情況下，Azure CNI網絡模型裏，每個Node最多運行30個Pod
- Azure CNI支持超過400個Node的情況
- 假設我們有16個Node，則在默認情況下，一共可以運行16*30=480個Pod。總計需要的內網IP地址=Node數量+Pod數量=16 (Node) + 480 (Pod)=496個內網IP地址。
- 在16個Node情況下，CIDR至少需要/23
- 假設我們有1000個Node，則在默認情況下，一共可以運行1000*30=30000個Pod。總計需要的內網IP地址=Node數量+Pod數量=1000 (Node) + 30000 (Pod)=31000個內網IP地址
- 在1000個Node情況下，CIDR至少需要/17
6.每個Node的最大Pod數量
AKS 羣集中每個節點的最大 Pod 數爲 250。 每個節點的默認最大 Pod 數因 kubenet 和 Azure CNI 網絡以及羣集部署方法而異
| 部署方法 | kubenet默認值 | Azure CNI默認值 | 可在部署時配置 |
| Azure CLI | 110 | 30 | 是 (最大250) |
| Resource Manager模板 | 110 | 30 | 是 (最大250) |
| Azure Portal | 110 | 110 (在"節點池"中配置) | 否 |
7.AKS升級
Kubernetes 社區大約會每隔三個月發佈次要版本。 最近，Kubernetes 社區將每個版本的支持時長從 9 個月增加到了 12 個月，從版本 1.19 開始。
AKS上的Kubernetes版本受支持窗口爲"N-2"，(N (最新版本) -2 (次要版本))
例如，如果AKS當前最新的版本是1.21，則提供以下版本的支持
1.21, 1.20, 1.19
我們在使用AKS過程中，可能會對AKS進行升級。就需要考慮預留額外的IP地址數量
8.我們在創建AKS集羣的時候，某些情況下想僅針對內網用戶訪問，這時候我們就可以創建AKS集羣類型爲Private Cluster。如下圖：
在創建完AKS Private Cluster之後，還是會創建出一個新的公網IP地址和一個新的負載均衡器。
在默認情況下，即使我們創建的是AKS Private Cluster，AKS仍然使用這個負載均衡器的公網IP來處理節點(Pod)到第三方的訪問。
9.AKS Private Cluster需要開啓某些公網地址的訪問權限
爲了便於管理和操作，AKS 羣集中的節點需要訪問特定的端口和完全限定的域名 (FQDN)。 節點與 API 服務器進行通信，或者下載並安裝核心 Kubernetes 羣集組件和節點安全更新都需要這些終結點。 例如，羣集需要從 Microsoft 容器註冊表 (MCR) 請求基礎系統容器映像。
AKS訪問公網地址的具體信息，可以參考：https://docs.microsoft.com/zh-cn/azure/aks/limit-egress-traffic