更新时间:2024-06-12 GMT+08:00
分享

配置条件触发自动切流

本小节指导您配置条件触发自动切流,以识别集群CoreDNS功能故障并自动摘除流量。

为集群安装CPD组件识别集群

在配置自动切流前,您需要在集群中安装CPD(cluster-problem-detector)组件,以自动探测集群CoreDNS域名解析功能是否正常,并进行上报。

CPD会周期性地解析kubernetes.default域名,将解析结果更新到Node对象的conditions中。主CPD Pod会收集各个Node上的conditions,判断集群域名解析功能是否正常,并将该判断结果上报到至集群联邦控制面。

CPD以DaemonSet的形式部署,需要独立部署在每个目标集群的所有节点上。CPD的配置文件示例如下所示,请参见表1中的描述修改相关参数。

表1 CPD参数说明

参数

描述

<federation-version>

集群所在联邦的版本号。请在“容器舰队”页签下单击目标舰队名称以获取联邦版本号。

<your-cluster-name>

需要安装CPD组件的集群名称。

<kubeconfig-of-karmada>

可访问联邦控制面的kubeconfig文件内容。关于如何下载满足要求的kubeconfig文件,请参见kubeconfig

注意:
  • 下载kubeconfig文件时,需要选择部署集群所在的VPC,或者通过云连接、对等连接等方式打通到集群网络的VPC。
  • 若kubeconfig文件中的联邦控制面地址为域名,则需要在部署文件中配置hostAliaes。

hostAliases

若kubeconfig文件中的联邦控制面地址为域名,则需要在部署文件中配置hostAliases,否则请删除YAML中的hostAliases配置。

  • 将<host name of karmada server>替换为联邦控制面地址域名。获取联邦控制面地址域名请查看kubeconfig文件中的server字段,如下图所示。

  • 将<ip of host name of karmada server>替换为该联邦控制面地址域名对应的IP地址。请在集群节点访问联邦控制面地址域名,获取解析后的IP地址。

coredns-detect-period

CoreDNS进行探测和上报的周期,默认5s(推荐值)。周期越短,探测和上报越频繁。

coredns-success-threshold

CoreDNS域名解析成功持续时长超过该阈值,则认为CoreDNS功能正常,默认30s(推荐值)。阈值越大,探测状态越稳定,但是灵敏度越低。阈值越低,灵敏度越高,但可能导致探测状态不稳定。

coredns-failure-threshold

CoreDNS域名解析失败持续时长超过该阈值,则认为CoreDNS功能故障,默认30s(推荐值)。阈值越大,探测状态越稳定,但是灵敏度越低。阈值越低,灵敏度越高,但可能导致探测状态不稳定。

kind: DaemonSet
apiVersion: apps/v1
metadata:
  name: cluster-problem-detector
  namespace: kube-system
  labels:
    app: cluster-problem-detector
spec:
  selector:
    matchLabels:
      app: cluster-problem-detector
  template:
    metadata:
      labels:
        app: cluster-problem-detector
    spec:
      containers:
        - image: swr.cn-north-4.myhuaweicloud.com/hwofficial/cluster-problem-detector:<federation-version>
          name: cluster-problem-detector
          command:
            - /bin/sh
            - '-c'
            - /var/paas/cluster-problem-detector/cluster-problem-detector
              --karmada-kubeconfig=/tmp/config
              --karmada-context=federation
              --cluster-name=<your-cluster-name>
              --host-name=${HOST_NAME}
              --bind-address=${POD_ADDRESS}
              --healthz-port=8081
              --detectors=*
              --coredns-detect-period=5s
              --coredns-success-threshold=30s
              --coredns-failure-threshold=30s
              --coredns-stale-threshold=60s
          env:
            - name: POD_ADDRESS
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: status.podIP
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
            - name: HOST_NAME
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: spec.nodeName
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8081
              scheme: HTTP
            initialDelaySeconds: 3
            timeoutSeconds: 3
            periodSeconds: 5
            successThreshold: 1
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8081
              scheme: HTTP
            initialDelaySeconds: 3
            timeoutSeconds: 3
            periodSeconds: 5
            successThreshold: 1
            failureThreshold: 3
          volumeMounts:
            - mountPath: /tmp
              name: karmada-config
      serviceAccountName: cluster-problem-detector
      volumes:
        - configMap:
            name: karmada-kubeconfig
            items:
              - key: kubeconfig
                path: config
          name: karmada-config
      securityContext:
        fsGroup: 10000
        runAsUser: 10000
        seccompProfile:
          type: RuntimeDefault
      hostAliases:
        hostnames:
          - <host name of karmada server>
        ip: <ip of host name of karmada server>
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cluster-problem-detector
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cpd-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:cluster-problem-detector
subjects:
  - kind: ServiceAccount
    name: cluster-problem-detector
    namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: system:cluster-problem-detector
rules:
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes/status
    verbs:
      - patch
      - update
  - apiGroups:
      - ""
      - events.k8s.io
    resources:
      - events
    verbs:
      - create
      - patch
      - update
  - apiGroups:
      - coordination.k8s.io
    resources:
      - leases
    verbs:
      - get
      - list
      - watch
      - create
      - update
      - patch
      - delete
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: karmada-kubeconfig
  namespace: kube-system
data:
  kubeconfig: |+
    <kubeconfig-of-karmada>

检查CPD组件是否正常运行

部署CPD组件后,请检查CPD组件是否正常运行。

  • 执行以下命令,检查节点的conditions中是否有“ServiceDomainNameResolutionReady”类型的 condition 出现,并检查该condition的“lastHeartBeatTime”是否及时更新。

    kubectl get node <node-name> -oyaml | grep -B4 ServiceDomainNameResolutionReady

    若节点中没有上述类型的condition出现,或者该condition“lastHeartBeatTime”长时间不更新:

    1. 请检查CPD中的pod是否处于Ready状态。
    2. 请检查成员集群中是否有“LoadCorednsConditionFailed”或者“StoreCorednsConditionFailed”类型的事件。若存在,请按事件中的错误提示进行处理。
  • 执行以下命令,检查集群联邦cluster对象中是否有“ServiceDomainNameResolutionReady”类型的condition出现。

    kubectl --kubeconfig <kubeconfig-of-federation> get cluster <cluster-name> -oyaml | grep ServiceDomainNameResolutionReady

    若cluster对象中没有上述类型的condition:

    1. 请检查CPD日志中是否出现“failed to sync corendns condition to control plane, requeuing”错误。
    2. 请检查kubeconfig配置是否有误。若kubeconfig有更新,请重新部署CPD。
    3. 请检查CPD所在节点的网络和下载kubeconfig文件所使用的VPC网络是否打通。

配置条件触发自动切流策略

在CPD组件部署成功并正常运行后,您需要创建Remedy对象,以在特定触发条件下执行特定动作,如在集群CoreDNS组件故障后执行MCI切流。

Remedy对象的配置文件示例如下所示。示例YAML定义了一个Remedy对象,可以通过member1或member2集群上的CPD上报CoreDNS解析功能,在功能故障时自动将该集群上的MCI进行切流。详细的Remedy对象参数说明请参见表2

apiVersion: remedy.karmada.io/v1alpha1
kind: Remedy
metadata:
  name: foo
spec:
  clusterAffinity:
    clusterNames:
      - member1
      - member2
  decisionMatches:
  - clusterConditionMatch:
      conditionType: ServiceDomainNameResolutionReady
      operator: Equal
      conditionStatus: "False"
  actions:
  - TrafficControl
表2 Remedy参数说明

参数

描述

spec.clusterAffinity.clusterNames

策略关注的集群名列表。仅在该列表中的集群会执行指定动作,为空时不会执行任何动作。

spec.decisionMatches

触发条件列表。当上述集群列表中指定的集群满足任一触发条件时,即会执行指定动作。当列表为空时,表示无条件触发。

conditionType

触发条件的类型。当前仅支持ServiceDomainNameResolutionReady类型,即CPD上报的CoreDNS域名解析状态。

operator

判断逻辑,仅支持Equal和NotEqual两种值,即等于和不等于。

conditionStatus

触发条件的状态。

actions

策略要执行的动作,目前仅支持TrafficControl,即流量控制。

分享:

    相关文档

    相关产品