在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的負載下降。