在Terway的集群中,可以使用NetworkPolicy来控制Pod之间的访问。当Terway的集群节点数量增加到100以上时,NetworkPolicy的代理会给Kubernetes的管控造成不小的压力,所以需要对NetworkPolicy做针对大规模集群的优化调整。本文介绍如何优化大规模Terway集群中NetworkPolicy的性能。
背景信息
Terway使用Calico的Felix作为NetworkPolicy功能的实现。在节点数量大于100的大规模集群中,每个节点上的Felix都从API Server获取规则,这样会给API Server带来不小的压力,所以在大规模集群中可以采用关闭NetworkPolicy的功能或者部署中继组件Typha的方式降低Felix对API Server的压力。
您可以通过两种方式优化大规模集群中NetworkPolicy的性能:
部署NetworkPolicy中继。
关闭集群的NetworkPolicy功能。
说明关闭集群的NetworkPolicy能力会导致NetworkPolicy的功能不可用。
前提条件
集群网络模式为Terway且集群规模大于100个节点以上,详情请参见创建Kubernetes托管版集群。
部署NetworkPolicy中继
登录容器服务管理控制台。
升级集群的Terway组件至最新版本,具体步骤请参见管理组件。
Terway不同模式使用的组件有所不同。详细信息,请参见Terway各种模式对比。
复制以下代码至新建的calico-typha.yaml文件中,用以部署NetworkPolicy中继组件Typha。
apiVersion: v1 kind: Service metadata: name: calico-typha namespace: kube-system labels: k8s-app: calico-typha spec: ports: - port: 5473 protocol: TCP targetPort: calico-typha name: calico-typha selector: k8s-app: calico-typha --- apiVersion: apps/v1 kind: Deployment metadata: name: calico-typha namespace: kube-system labels: k8s-app: calico-typha spec: replicas: 3 # 根据集群规模修改其中的replicas的副本数(一个副本对应200个节点,最少3个副本)。 revisionHistoryLimit: 2 selector: matchLabels: k8s-app: calico-typha template: metadata: labels: k8s-app: calico-typha annotations: cluster-autoscaler.kubernetes.io/safe-to-evict: 'true' spec: nodeSelector: kubernetes.io/os: linux hostNetwork: true tolerations: - operator: Exists serviceAccountName: terway priorityClassName: system-cluster-critical containers: - image: registry-vpc.{REGION-ID}.aliyuncs.com/acs/typha:v3.20.2 # 修改{REGION-ID}为对应集群的地域。 name: calico-typha ports: - containerPort: 5473 name: calico-typha protocol: TCP env: - name: TYPHA_LOGSEVERITYSCREEN value: "info" - name: TYPHA_LOGFILEPATH value: "none" - name: TYPHA_LOGSEVERITYSYS value: "none" - name: TYPHA_CONNECTIONREBALANCINGMODE value: "kubernetes" - name: TYPHA_DATASTORETYPE value: "kubernetes" - name: TYPHA_HEALTHENABLED value: "true" livenessProbe: httpGet: path: /liveness port: 9098 host: localhost periodSeconds: 30 initialDelaySeconds: 30 readinessProbe: httpGet: path: /readiness port: 9098 host: localhost periodSeconds: 10 --- apiVersion: policy/v1 # 若Kubernetes为v1.21以前版本,apiVersion对应的版本为policy/v1beta1。 kind: PodDisruptionBudget metadata: name: calico-typha namespace: kube-system labels: k8s-app: calico-typha spec: maxUnavailable: 1 selector: matchLabels: k8s-app: calico-typha --- apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: bgppeers.crd.projectcalico.org spec: scope: Cluster group: crd.projectcalico.org versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: apiVersion: type: string names: kind: BGPPeer plural: bgppeers singular: bgppeer
说明修改模板中的{REGION-ID}为对应的地域。
根据集群规模修改其中的replicas的副本数(一个副本对应200个节点,最少3个副本)。
根据集群版本适配
PodDisruptionBudget
的apiVersion
:集群版本为v1.21或更高,PodDisruptionBudget
的apiVersion
需要设置为policy/v1
;集群版本低于v1.21,PodDisruptionBudget
的apiVersion
需要设置为policy/v1beta1
。
执行以下命令,部署中继组件。
kubectl apply -f calico-typha.yaml
执行以下命令,修改Terway的配置项文件eni-config。
kubectl edit cm eni-config -n kube-system
在打开的文件中增加中继配置
felix_relay_service: calico-typha
,并将disable_network_policy
的参数取值配置为"false"
(如果没有该参数,则无需配置)。这两个参数均与eni_conf
参数对齐。felix_relay_service: calico-typha disable_network_policy: "false" # 如果没有该参数,则无需新增。
执行以下命令,重启集群中的Terway。
kubectl get pod -n kube-system | grep terway | awk '{print $1}' | xargs kubectl delete -n kube-system pod
预计输出:
pod "terway-eniip-8hmz7" deleted pod "terway-eniip-dclfn" deleted pod "terway-eniip-rmctm" deleted ...
关闭集群NetworkPolicy
当您不需要NetworkPolicy的功能时,也可以采用直接关闭集群的NetworkPolicy功能,从而降低NetworkPolicy的代理对API Server的压力。
执行以下命令,修改Terway的配置项文件eni-config,增加禁用NetworkPolicy的配置disable_network_policy: "true"。
kubectl edit cm -n kube-system eni-config # 修改(如果有以下key)或者新增: disable_network_policy: "true"
执行以下命令,重启集群中的Terway。
kubectl get pod -n kube-system | grep terway | awk '{print $1}' | xargs kubectl delete -n kube-system pod
预计输出:
pod "terway-eniip-8hmz7" deleted pod "terway-eniip-dclfn" deleted pod "terway-eniip-rmctm" deleted ...
执行结果
上述操作完成后,NetworkPolicy的代理会使用中继组件,从而不会再对Kubernetes的API Server造成过大压力。通过观察集群API Server的SLB的监控情况,可以看到API Server的负载下降。