Container Service for Kubernetes:Deploy stable, high-performance unmanaged CoreDNS

Avalie a pressão sobre o DNS

Antes de ajustar o número de réplicas, avalie a pressão sobre o DNS. Ferramentas como DNSPerf permitem medir a carga de DNS.

Caso não seja possível medir a pressão diretamente, siga estas diretrizes:

• Execute pelo menos 2 pods do CoreDNS com limites de recursos de, no mínimo, 1 núcleo e 1 GB de memória.

• O QPS de resolução de DNS escala linearmente com o consumo de CPU. Com o NodeLocal DNSCache, cada núcleo de CPU processa mais de 10.000 consultas por segundo (QPS). Diferentes cargas de trabalho têm necessidades de QPS muito variadas; portanto, monitore o pico de uso de CPU de cada pod do CoreDNS. Se algum pod ultrapassar um núcleo durante os horários de pico de negócios, aumente a escala das réplicas.

• Na ausência de dados de carga, comece com 1 pod para cada 8 nós como linha de base.

Após definir a quantidade alvo de réplicas, utilize o ajuste automático (recomendado) ou faça o dimensionamento manual.

Configure o ajuste automático (recomendado)

O componente cluster-proportional-autoscaler ajusta as réplicas do CoreDNS com base no tamanho do cluster. Diferentemente do HPA, ele não depende de métricas de CPU nem realiza reduções de escala disruptivas. Proporção padrão: 1 pod para cada 8 nós.

Fórmula de cálculo de réplicas: replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica)). Os parâmetros min e max limitam a quantidade entre 2 e 100.

Implante o autoscaler:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dns-autoscaler
  namespace: kube-system
  labels:
    k8s-app: dns-autoscaler
spec:
  selector:
    matchLabels:
      k8s-app: dns-autoscaler
  template:
    metadata:
      labels:
        k8s-app: dns-autoscaler
    spec:
      serviceAccountName: admin
      containers:
      - name: autoscaler
        image: registry.cn-hangzhou.aliyuncs.com/acs/cluster-proportional-autoscaler:1.8.4
        resources:
          requests:
            cpu: "200m"
            memory: "150Mi"
        command:
        - /cluster-proportional-autoscaler
        - --namespace=kube-system
        - --configmap=dns-autoscaler
        - --nodelabels=type!=virtual-kubelet
        - --target=Deployment/coredns
        - --default-params={"linear":{"coresPerReplica":64,"nodesPerReplica":8,"min":2,"max":100,"preventSinglePointFailure":true}}
        - --logtostderr=true
        - --v=9

Faça o dimensionamento manual

Para definir uma quantidade específica de réplicas:

kubectl scale --replicas=<target> deployment/coredns -n kube-system # Replace <target> with the target number of pods.

Crie um pool de nós dedicado

Ao criar o pool de nós, siga estas diretrizes:

• O CoreDNS exige uso intensivo de rede, não de computação. Utilize instâncias otimizadas para rede, com tamanho recomendado de 4 núcleos e 8 GB de memória.

• O pool deve ter pelo menos 2 nós, já que o CoreDNS executa 2 pods por padrão.

• Adicione um taint e um rótulo para impedir que outros pods sejam executados nesses nós. Por exemplo, use system-addon: system-addon tanto como par chave-valor do taint quanto como rótulo, com Effect definido como NoSchedule.

Consulte Crie e gerencie pools de nós.

Agende pods do CoreDNS para o pool de nós

1. Na página Add-ons, localize o cartão CoreDNS e clique em Configuration.

2. Na seção NodeSelector, adicione o rótulo do pool de nós dedicado.

   Não exclua os rótulos existentes do NodeSelector.

3. Na seção Tolerations, adicione uma tolerância correspondente ao taint do pool de nós.

   Adicione uma entrada de tolerância em Tolerations: defina effect como NoSchedule, key como system-addon, operator como Equal e value como system-addon.

4. Clique em OK e verifique se os pods do CoreDNS estão em execução nos nós dedicados:

   kubectl -n kube-system get pod -o wide --show-labels | grep coredns

Anti-afinidade de pods

O CoreDNS usa uma regra de anti-afinidade requiredDuringSchedulingIgnoredDuringExecution para impedir que dois pods compartilhem o mesmo nó. Isso requer pelo menos 2 nós com recursos suficientes, excluindo:

• k8s.aliyun.com: true — nós com node autoscaling ativado

• type: virtual-kubelet — nós virtuais

• alibabacloud.com/lingjun-worker: true — nós Lingjun

A configuração de afinidade padrão é:

      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              # virtual nodes have this label
              - key: type
                operator: NotIn
                values:
                - virtual-kubelet
              # lingjun worker nodes have this label
              - key: alibabacloud.com/lingjun-worker
                operator: NotIn
                values:
                - "true"
          preferredDuringSchedulingIgnoredDuringExecution:
          - preference:
              matchExpressions:
              # autoscaled nodes have this label
              - key: k8s.aliyun.com
                operator: NotIn
                values:
                - "true"
            weight: 100
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: k8s-app
                operator: In
                values:
                - kube-dns
            topologyKey: kubernetes.io/hostname

Agendamento com reconhecimento de topologia

Por padrão, o CoreDNS usa topology-aware scheduling para distribuir os pods entre as zonas. A configuração whenUnsatisfiable: DoNotSchedule impõe essa regra — os pods não serão agendados se a condição de equilíbrio entre zonas não puder ser atendida.

Para que isso funcione de forma confiável:

• O cluster deve ter nós em pelo menos 2 zonas diferentes, cada uma com pelo menos 1 nó que possua recursos suficientes para o CoreDNS.

• Todos os nós devem ter o rótulo topology.kubernetes.io/zone (aplicado por padrão). Rótulos ausentes ou inconsistentes causam falhas de agendamento ou distribuição desigual.

• Atualize o cluster para a versão v1.27 ou posterior e o CoreDNS para a versão v1.12.1.3 ou posterior. Versões anteriores do cluster não suportam matchLabelKeys; portanto, uma atualização contínua do CoreDNS pode resultar em pods distribuídos desigualmente entre as zonas e até deixar algumas zonas sem cobertura. Consulte a configuração matchLabelKeys descrita abaixo.

Versões do CoreDNS anteriores à v1.12.1.3 usam esta restrição de distribuição de topologia:

topologySpreadConstraints:
- labelSelector:
    matchLabels:
      k8s-app: kube-dns
  maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule

CoreDNS v1.12.1.3 e posteriores corrigem esse comportamento com matchLabelKeys (Kubernetes v1.27+):

topologySpreadConstraints:
- labelSelector:
    matchLabels:
      k8s-app: kube-dns
  matchLabelKeys:
  - pod-template-hash
  nodeTaintsPolicy: Honor
  maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule

Adicionar matchLabelKeys: [pod-template-hash] restringe a aplicação da restrição ao ReplicaSet atual, garantindo que as atualizações contínuas distribuam os pods uniformemente entre as zonas.