Distribua cargas de trabalho entre nós e zonas de disponibilidade

A distribuição de uma carga de trabalho em domínios de falha, como zonas de disponibilidade e nós, melhora a disponibilidade dos componentes e diminui as chances de falha em aplicativos escaláveis horizontalmente. As seções a seguir apresentam formas de distribuir cargas de trabalho entre nós e zonas de disponibilidade.

Use restrições de dispersão da topologia do pod

As restrições de dispersão da topologia do pod do Kubernetes instruem o programador do Kubernetes a distribuir pods que são gerenciados por ReplicaSet ou StatefulSet entre diferentes domínios de falha (zonas de disponibilidade, nós e tipos de hardware). Ao usar restrições de dispersão da topologia do pod, você pode fazer o seguinte:

• Distribua ou concentre os pods em diferentes domínios de falha, dependendo dos requisitos do aplicativo. Por exemplo, você pode distribuir pods para resiliência e concentrar pods para desempenho de rede.

• Combine condições diferentes, como distribuição entre zonas de disponibilidade e distribuição entre nós.

• Especifique a ação preferida se as condições não puderem ser atendidas:

  • Use whenUnsatisfiable: DoNotSchedule com uma combinação de maxSkew e minDomains para criar requisitos rígidos para o agendador.

  • Use whenUnsatisfiable: ScheduleAnyway para reduzirmaxSkew.

Se uma zona de falha ficar indisponível, os pods dessa zona ficarão insalubres. O Kubernetes reprograma os pods enquanto segue a restrição de propagação, se possível.

Restrições de distribuição da topologia do pod

O código a seguir mostra um exemplo do uso de restrições de distribuição da topologia de pod entre zonas de disponibilidade ou entre nós:

...
spec:
  selector:
    matchLabels:
      app: <your-app-label>
    replicas: 3
    template:
      metadata:
        labels: <your-app-label>
      spec:
        serviceAccountName: <ServiceAccountName>
...
        topologySpreadConstraints:
        - labelSelector:
            matchLabels:
              app: <your-app-label>
          maxSkew: 1
          topologyKey: topology.kubernetes.io/zone # <---spread those pods evenly over all availability zones
          whenUnsatisfiable: ScheduleAnyway
        - labelSelector:
            matchLabels:
              app: <your-app-label>
          maxSkew: 1
          topologyKey: kubernetes.io/hostname # <---spread those pods evenly over all nodes
          whenUnsatisfiable: ScheduleAnyway

Restrições de dispersão da topologia padrão em todo o cluster

Pronto para usar, o Kubernetes fornece um conjunto padrão de restrições de distribuição de topologia para distribuição de pods entre nós e zonas de disponibilidade:

defaultConstraints:
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway

nota

Aplicativos que precisam de diferentes tipos de restrições de topologia podem substituir a política em nível de cluster.

As restrições padrão definem um valor altomaxSkew, o que não é útil para implantações com um pequeno número de pods. No momento, não KubeSchedulerConfiguration pode ser alterado no Amazon EKS. Se você precisar aplicar outros conjuntos de restrições de dispersão de topologia, considere usar o controlador de admissão mutante, como na seção abaixo. Você também pode controlar as restrições de dispersão da topologia padrão se você executar um agendador alternativo. No entanto, o gerenciamento de agendadores personalizados aumenta a complexidade e pode ter implicações na resiliência do cluster e na HA. Por esses motivos, não recomendamos o uso de um programador alternativo somente para restrições de dispersão de topologia.

A política do Gatekeeper para restrições de dispersão de topologia

Outra opção para impor restrições de dispersão de topologia é usar uma política do projeto Gatekeeper. As políticas do Gatekeeper são definidas no nível do aplicativo.

Os exemplos de código a seguir mostram o uso de uma Gatekeeper OPA política para implantação. Você pode modificar a política de acordo com suas necessidades. Por exemplo, aplique a política somente às implantações que tenham o rótulo HA=true ou escreva uma política semelhante usando um controlador de política diferente.

Este primeiro exemplo mostra o ConstraintTemplate uso comk8stopologyspreadrequired_template.yml:

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8stopologyspreadrequired
spec:
  crd:
    spec:
      names:
        kind: K8sTopologySpreadRequired
      validation:
        openAPIV3Schema:
          type: object
          properties:
            message:
              type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8stopologyspreadrequired

        get_message(parameters, _default) =3D msg {
          not parameters.message
          msg :=_default
        }


        get_message(parameters, _default) =3D msg {
          msg := parameters.message
        }

        violation[{"msg": msg}] {
          input.review.kind.kind ="Deployment"
          not input.review.object.spec.template.spec.topologySpreadConstraint
          def_msg :"Pod Topology Spread Constraints are required for Deployments"
          msg :get_message(input.parameters, def_msg)

        }

O código a seguir mostra o k8stopologyspreadrequired_constraint.yml manifesto constraints YAML:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sTopologySpreadRequired
metadata:
  name: require-topologyspread-for-deployments
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
    namespaces:  ## Without theses two lines will apply to the whole cluster
      - "example"

Quando usar restrições de dispersão de topologia

Considere o uso de restrições de dispersão de topologia para os seguintes cenários:

• Qualquer aplicativo escalável horizontalmente (por exemplo, serviços web sem estado)

• Aplicativos com réplicas ativo-ativas ou ativas-passivas (por exemplo, bancos de dados NoSQL ou caches)

• Aplicativos com réplicas em espera (por exemplo, controladores)

Os componentes do sistema que podem ser usados para o cenário escalável horizontalmente, por exemplo, incluem o seguinte:

• Cluster Autoscaler e Karpenter (com e) replicaCount > 1 leader-elect = true

• AWS Controlador de balanceador de carga

• CoreDNS

Afinidade e antiafinidade do pod

Em alguns casos, é vantajoso garantir que não mais do que um pod de um tipo específico esteja sendo executado em um nó. Por exemplo, para evitar o agendamento de vários pods com muita rede no mesmo nó, você pode usar a regra de antiafinidade com o rótulo ou. Ingress Network-heavy Ao usaranti-affinity, você também pode usar uma combinação do seguinte:

• Manchas em nós otimizados para rede

• Tolerâncias correspondentes em cápsulas com muita rede

• Afinidade de nós ou seletor de nós para garantir que pods com muita rede usem instâncias otimizadas para rede

Os pods com muita rede são usados como exemplo. Você pode ter requisitos diferentes, como GPU, memória ou armazenamento local. Para ver outros exemplos de uso e opções de configuração, consulte a documentação do Kubernetes.

Rebalancear cápsulas

Esta seção discute duas abordagens para rebalancear pods em um cluster Kubernetes. O primeiro usa o Descheduler for Kubernetes. O Descheduler ajuda a manter a distribuição dos pods aplicando estratégias para remover os pods que violam as restrições de dispersão da topologia ou as regras de antiafinidade. A segunda abordagem usa o recurso de consolidação e empacotamento do Karpenter. A consolidação avalia e otimiza continuamente o uso de recursos consolidando cargas de trabalho em menos nós compactados com mais eficiência.

Recomendamos usar o Descheduler se você não estiver usando o Karpenter. Se você estiver usando o Karpenter e o Autoescalador de Cluster juntos, poderá usar o Desagendador com o Autoescalador de Cluster para grupos de nós.

Desagendador para nós sem grupos

Não há garantia de que as restrições de topologia permaneçam satisfeitas quando os pods são removidos. Por exemplo, reduzir uma implantação pode resultar em uma distribuição desequilibrada de pods. No entanto, como o Kubernetes usa restrições de dispersão da topologia do pod somente no estágio de agendamento, os pods ficam desbalanceados em todo o domínio da falha.

Para manter uma distribuição equilibrada de pods nesses cenários, você pode usar o Descheduler for Kubernetes. O Descheduler é uma ferramenta útil para vários propósitos, como impor a idade máxima do pod ou o tempo de vida (TTL) ou para melhorar o uso da infraestrutura. No contexto de resiliência e alta disponibilidade (HA), considere as seguintes estratégias do Descheduler:

• RemovePodsViolatingTopologySpreadConstraint

• RemovePodsViolatingInterPodAntiAffinity

• RemoveDuplicates

Recurso de consolidação e empacotamento de caixas do Karpenter

Para cargas de trabalho que usam o Karpenter, você pode usar a funcionalidade de consolidação e empacotamento para otimizar a utilização de recursos e reduzir custos em clusters Kubernetes. O Karpenter avalia continuamente o posicionamento dos pods e a utilização dos nós e tenta consolidar as cargas de trabalho em menos nós compactados com mais eficiência, sempre que possível. Esse processo envolve analisar os requisitos de recursos, considerar restrições como regras de afinidade de pods e potencialmente mover pods entre os nós para melhorar a eficiência geral do cluster. O código a seguir fornece um exemplo:

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h

ParaconsolidationPolicy, você pode usar WhenUnderutilized ouWhenEmpty:

• Quando consolidationPolicy está definido comoWhenUnderutilized, o Karpenter considera todos os nós para consolidação. Quando o Karpenter descobre um nó vazio ou subutilizado, o Karpenter tenta remover ou substituir o nó para reduzir o custo.

• Quando consolidationPolicy está definido comoWhenEmpty, o Karpenter considera para consolidação somente nós que não contêm pods de carga de trabalho.

As decisões de consolidação do Karpenter não se baseiam apenas nas porcentagens de utilização da CPU ou da memória que você pode ver nas ferramentas de monitoramento. Em vez disso, o Karpenter usa um algoritmo mais complexo baseado em solicitações de recursos do pod e possíveis otimizações de custos. Para obter mais informações, consulte a documentação do Karpenter.