Definir uma estratégia de rollout para a colocação de recursos do Azure Kubernetes Fleet Manager

Aplica-se a: ✔️ Fleet Manager com cluster de hub

Durante a vida útil de uma colocação de recurso (com âmbito ClusterResourcePlacement de cluster ou namespace ResourcePlacement), poderão ser feitas alterações que podem resultar num dos seguintes cenários:

• Podem ser necessárias novas cargas de trabalho em todos os clusters escolhidos
• Cargas de trabalho já colocadas num cluster escolhido podem ser atualizadas ou eliminadas
• Alguns clusters escolhidos anteriormente agora não são selecionados, e as cargas de trabalho devem ser removidas desses clusters
• Alguns clusters são recém-selecionados e cargas de trabalho devem ser adicionadas a eles.

A maioria dos cenários pode levar a interrupções de serviço, pois as cargas de trabalho a correr nos clusters membros podem ficar temporariamente indisponíveis à medida que o Gestor de Frotas despacha recursos atualizados. Os clusters que não são mais selecionados perdem todos os recursos colocados, resultando em perda de tráfego. Se forem selecionados demasiados novos clusters e o Fleet Manager colocar recursos neles simultaneamente, os clusters podem ficar sobrecarregados. O padrão exato de interrupção pode variar consoante os recursos disponibilizados.

Para minimizar a interrupção, as APIs de colocação de recursos do Fleet Manager permitem aos utilizadores configurar uma estratégia de implementação, semelhante à implementação nativa do Kubernetes, para transitar entre alterações da forma mais suave possível.

Neste artigo, abordamos as opções de estratégia de implementação disponíveis tanto para ClusterResourcePlacement como para ResourcePlacement.

Comportamento padrão sem estratégia explícita

Ambos ClusterResourcePlacement e ResourcePlacement não exigem que definas uma estratégia de implementação. Se não especificares um, o comportamento padrão é usar uma RollingUpdate estratégia com um maxSurge de 25%, maxUnavailable de 25%e unavailablePeriodSeconds de 10 segundos.

Estratégia de atualização contínua

Uma estratégia explícita de atualização progressiva pode ser usada ao adicionar uma strategy especificação a um ClusterResourcePlacement ou ResourcePlacement, conforme mostrado. Pode definir parâmetros que controlam o quão disruptivo é o posicionamento dos recursos do Gestor de Frotas.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-example
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-namespace
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 2
    affinity:
      clusterAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  fleet.azure.com/location: westus
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 50%

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: rp-example
  namespace: test-namespace
spec:
  resourceSelectors:
    - group: "apps"
      kind: Deployment
      name: my-app
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 50%

Parâmetros de configuração

As estratégias de atualização contínua podem ser configuradas com os seguintes parâmetros:

• maxUnavailable: considera um cluster como indisponível se os recursos não forem aplicados com sucesso ao cluster e garante que, a qualquer momento, existam pelo menos (N - maxUnavailable) números de clusters disponíveis. Você pode definir como um número absoluto ou uma porcentagem. O padrão é 25% e zero não deve ser usado. Definir esse parâmetro para um valor mais baixo resulta em menos interrupções durante uma alteração, mas leva a distribuições mais lentas.

• maxSurge: garante que, a qualquer momento, haja no máximo (N+ maxSurge) número de clusters disponíveis. Você pode definir como um número absoluto ou uma porcentagem. O padrão é 25% e zero não deve ser usado. Definir esse parâmetro para um valor mais baixo resulta em menos posicionamentos de recursos em mais clusters pelo Fleet Manager, o que atrasa o processo de implantação.

• unavailablePeriodSeconds permite definir um período de tempo antes que os recursos sejam avaliados como "prontos". O valor padrão é 60 segundos. O Fleet Manager só considera os recursos recém-aplicados em um cluster como "prontos" unavailablePeriodSeconds segundos depois que os recursos são aplicados com êxito a esse cluster. A definição de um valor mais baixo para esse parâmetro resulta em distribuições mais rápidas. No entanto, é altamente recomendável que os usuários definam um valor que permita que as tarefas de inicialização/preparação sejam concluídas.

Como a contagem de clusters é determinada

O Fleet Manager usa o tipo de posicionamento para determinar o número de linha de base de clusters (N) a ser usado ao calcular maxUnavailable ou maxSurge:

• PickFixed: o número de clusterNames especificado
• PickAll: o número de clusters escolhidos
• PickN: o numberOfClusters valor.

Se usares uma percentagem para o parâmetro, o Gestor de Frotas faz o cálculo contra N também.

Estratégia de atualização em etapas

A estratégia de atualização em estágios fornece controle refinado sobre distribuições de recursos, organizando clusters em estágios sequenciais com regras de progressão configuráveis. Ao contrário da estratégia de atualização contínua, as atualizações em estágios são definidas externamente usando recursos personalizados separados que trabalham juntos para orquestrar implantações.

Exemplo de padrão de implantação

O diagrama a seguir ilustra um padrão típico de implantação de três estágios:

Este padrão permite-lhe:

• Desdobrar em clusters de teste primeiro para validação inicial
• Aguarde um tempo especificado antes de prosseguir para os clusters canários
• Exigir aprovação manual antes de entrar em produção
• Controlar a ordem das atualizações dentro das etapas canário e de produção

Quando usar atualizações em estágios

As estratégias de atualização escalonada são ideais quando você precisa:

• Distribuições baseadas em ambiente (desenvolvimento → preparação → produção)
• Atrasos de validação e portas de aprovação entre etapas
• Ordenação determinística de atualizações de cluster dentro de estágios
• Padrões de implementação reutilizáveis através de múltiplas distribuições de recursos

Para cenários mais simples em que distribuições baseadas em porcentagem são suficientes, considere usar a estratégia de atualização contínua em linha.

Como funcionam as atualizações em etapas

Tanto as colocações de cluster como as de namespace oferecem os seus próprios tipos de recursos.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: my-app-placement
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: External  # Rollout is controlled by ClusterStagedUpdateRun, ClusterStagedUpdateStrategy.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterStagedUpdateStrategy
metadata:
  name: three-stage-strategy
spec:
  stages:
    - name: staging
      labelSelector:
        matchLabels:
          environment: staging
      afterStageTasks:
        - type: TimedWait
          waitTime: 1h
      maxConcurrency: 50%  # Update 50% of staging clusters at once
    - name: canary
      labelSelector:
        matchLabels:
          environment: canary
      sortingLabelKey: name
      afterStageTasks:
        - type: Approval
      maxConcurrency: 2  # Update 2 clusters concurrently
    - name: production
      labelSelector:
        matchLabels:
          environment: production
      sortingLabelKey: order
      beforeStageTasks:
        - type: Approval
      maxConcurrency: 1  # Sequential updates (default)

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: my-app-placement
  namespace: my-app
spec:
  resourceSelectors:
    - group: "apps"
      kind: Deployment
      name: my-deployment
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: External  # Rollout is controlled by StagedUpdateRun, StagedUpdateStrategy.

apiVersion: placement.kubernetes-fleet.io/v1
kind: StagedUpdateStrategy
metadata:
  name: three-stage-strategy
  namespace: my-app
spec:
  stages:
    - name: staging
      labelSelector:
        matchLabels:
          environment: staging
      afterStageTasks:
        - type: TimedWait
          waitTime: 1h
      maxConcurrency: 50%  # Update 50% of staging clusters at once
    - name: canary
      labelSelector:
        matchLabels:
          environment: canary
      sortingLabelKey: name
      afterStageTasks:
        - type: Approval
      maxConcurrency: 2  # Update 2 clusters concurrently
    - name: production
      labelSelector:
        matchLabels:
          environment: production
      sortingLabelKey: order
      beforeStageTasks:
        - type: Approval
      maxConcurrency: 1  # Sequential updates (default)

Configuração do palco

Cada etapa da estratégia pode especificar:

• Seletor de etiquetas (labelSelector) para determinar que clusters pertencem ao estágio
• Ordem de ordenação (sortingLabelKey) para clusters dentro do estágio usando sortingLabelKey (opcional - os clusters são ordenados alfabeticamente por nome, se não especificados)
• Tarefas da fase anterior (beforeStageTasks) requisito de aprovação (opcional - até 1 tarefa por etapa)
• Tarefas pós-estágio (afterStageTasks) ou espera cronometrada ou requisito de aprovação (opcional - até 2 tarefas por etapa, máximo uma de cada tipo)
• Concorrência máxima (maxConcurrency) para determinar o número máximo de clusters a atualizar simultaneamente dentro do estágio (opcional - pode ser um número absoluto de 1 para o número de clusters no estágio, ou uma percentagem de 1 a 100, os resultados fracionados são arredondados para baixo com um mínimo de 1)

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterStagedUpdateRun
metadata:
  name: my-app-rollout
spec:
  placementName: my-app-placement # Required - ClusterResourcePlacement name the update run is applied to.
  # resourceSnapshotIndex: "0" # Optional - ClusterResourceSnapshot index of the selected resources to be updated across clusters. 
                               # Omit to use the latest snapshot, creating one if it doesn't already exist.
  stagedRolloutStrategyName: three-stage-strategy # Required - The name of the update strategy to use.
  state: Run # Optional - Controls the execution state of the update run.

apiVersion: placement.kubernetes-fleet.io/v1
kind: StagedUpdateRun
metadata:
  name: my-app-rollout
  namespace: my-app
spec:
  placementName: my-app-placement # Required - ResourcePlacement name the update run is applied to.
  # resourceSnapshotIndex: "0" # Optional - ResourceSnapshot index of the selected resources to be updated across clusters.
                               # Omit or leave empty to use the latest snapshot, creating one if it doesn't already exist.
  stagedRolloutStrategyName: three-stage-strategy # Required - The name of the update strategy to use.
  state: Run # Optional - Controls the execution state of the update run. 

Especificação da implementação

O resourceSnapshotIndex campo controla qual a versão do snapshot de recursos a implementar. Tem várias opções:

• Omita o campo para usar o snapshot mais recente, criando um novo caso ainda não exista (como mostrado no exemplo).
• Especifique um índice de snapshot de recursos existente (por exemplo, "2") para direcionar explicitamente essa versão.
• Especifique um índice de snapshot de recursos mais antigo (por exemplo, "0") para implementar ou reverter para uma versão anterior.

Para mais informações sobre snapshots de recursos, consulte Compreender snapshots para snapshots de recursos do Azure Kubernetes Fleet Manager.

Compreender os estados de execução das atualizações

As execuções de atualização em etapas usam um state campo para controlar o seu comportamento de execução. Compreender estes estados e as suas transições é essencial para gerir eficazmente as implementações.

Estados disponíveis

• Inicializar: Prepara a execução da atualização sem executar o lançamento. Use este estado para preparar e validar a atualização e a configuração antes de iniciar a implementação.

• Run: Executa a implementação faseada. Se começar do zero, este estado tanto inicializa como realiza a atualização. Se a execução da atualização já estiver inicializada, irá apenas executar a distribuição. Use este estado para iniciar ou retomar corridas de atualização.

• Parar: Interrompe graciosamente a corrida de atualização. Este estado permite que clusters em progresso completem as suas atualizações antes de interromperem todo o processo de implementação.

Regras de transição de Estado

São suportadas as seguintes transições de estado:

• Inicializar → Executar: Iniciar execução após a inicialização
• Executar → Parar: Parar um processo de atualização
• Parar → Correr: Retomar uma atualização interrompida

Quando uma execução de atualização termina, não pode ser reiniciada.

Progressão das fases

O Gestor de Frota processa as etapas sequencialmente:

1. Qualquer tarefa configurada antes da fase é executada
2. Todos os clusters em um estágio recebem atualizações de acordo com sua ordem de classificação
3. Depois que todos os clusters em um estágio são atualizados com êxito, todas as tarefas pós-estágio configuradas são executadas
4. A próxima etapa começa somente depois que todas as tarefas anteriores após a etapa forem concluídas

Pedidos de Aprovação

Para progressão baseada em aprovação, o Fleet Manager cria um recurso ClusterApprovalRequest (para colocações com âmbito de cluster) ou ApprovalRequest (para colocações com âmbito de espaço de nomes) que deve ser aprovado antes de avançar para a próxima etapa.

Uma etapa pode ter uma tarefa de aprovação antes da fase e uma tarefa de aprovação após a fase. Para ajudar a diferenciar qual pedido de aprovação corresponde a quais tarefas de estágio, o nome do pedido de aprovação conterá -before- para as tarefas anteriores à fase ou -after- para as tarefas posteriores à fase.

Nomes exemplos de pedidos de aprovação:

• my-update-run-before-canary - Tarefa de aprovação da fase prévia para a fase "canário" da execução "my-update-run"
• my-update-run-after-staging - Tarefa de aprovação pós-estágio para a fase de "preparação" da execução da atualização "my-update-run"

Principais diferenças entre estratégias com âmbito de cluster e namespace

Próximos passos

• Implementar recursos com âmbito de cluster em múltiplos clusters.
• Implementar recursos com âmbito de namespace em múltiplos clusters
• Posicionamento inteligente de recursos do Kubernetes entre clusters com base nas propriedades dos clusters membros.
• Como usar ClusterStagedUpdateRun para orquestrar distribuições em estágios.
• Controlando o desalojamento e a perturbação para o posicionamento de recursos do cluster.