《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