《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