Definir estratégias de atualização reutilizáveis usando o Azure Kubernetes Fleet Manager

1. No portal do Azure, navegue até o recurso do Azure Kubernetes Fleet Manager.

2. No menu de serviço, em Configurações, selecione Clusters de membros>Adicionar.

   

3. Selecione o cluster que pretende adicionar e, em seguida, selecione Seguinte: Rever + adicionar.

4. Introduza o nome do grupo de atualizações ao qual pretende atribuir o cluster e, em seguida, selecione Adicionar.

   

Atribua um cluster membro a um grupo de atualização ao adicionar o cluster membro à frota, utilizando o comando az fleet member create com o parâmetro --update-group definido para o nome do grupo de atualização.

az fleet member create \
    --resource-group $GROUP \
    --fleet-name $FLEET \
    --name member1 \
    --member-cluster-id $CLUSTERID \
    --update-group group-1a

1. No portal do Azure, navegue até o recurso do Azure Kubernetes Fleet Manager.

2. No menu de serviço, em Configurações, selecione Clusters de membros.

3. Selecione os clusters que pretende atribuir a um grupo de atualizações e, em seguida, selecione Atribuir grupo de atualizações

   

4. Introduza o nome do grupo de atualização ao qual pretende atribuir o cluster e, em seguida, selecione Atribuir.

   

Atribua um membro da frota existente a um grupo de atualização usando o az fleet member update comando com o --update-group sinalizador definido para o nome do grupo de atualização.

az fleet member update \
 --resource-group $GROUP \
 --fleet-name $FLEET \
 --name member1 \
 --update-group group-1

1. No portal do Azure, navegue até o recurso do Azure Kubernetes Fleet Manager.

2. No menu de serviço, em Configurações, selecione de vários clusters e, em seguida>.

3. Insira um nome para a estratégia.

4. Na primeira vez que você visualiza a página, um diagrama de explicação da estratégia de atualização é exibido que pode ajudar a visualizar como as estratégias funcionam.

   

5. Selecione Criar estágio e digite:

   • Nome da etapa - nomeie a etapa - deve ser único entre todos os nomes de etapa na estratégia.
   • Aprovações de estágio (opcional) - selecione esta opção se quiser aguardar uma aprovação antes que esta etapa comece ou depois de ser concluída. Para obter mais informações, consulte Adicionar aprovações para atualizar grupos e estágios.
   • (Opcional) Pausar após etapa - selecione esta opção se quiser definir uma pausa antes de passar para a próxima etapa.
   • (Opcional) Duração da pausa - selecione uma duração predefinida ou insira um valor personalizado em segundos.

   

6. Atribui um ou mais Grupos de Atualização ao palco e depois seleciona Criar.

   Nota

   O número máximo de Grupos de Atualização em cada Estágio de Atualização é 50.

   

Para esse cenário, criamos estágios e grupos para corresponder aos detalhes usados para o processo do portal do Azure.

1. Crie um arquivo JSON para definir os estágios e grupos para a execução da atualização. Os estágios são executados sequencialmente na ordem em que aparecem no arquivo JSON. Os grupos correm em paralelo dentro de cada etapa, por isso a ordenação não é importante. O ficheiro de exemplo seguinte (example-stages.json) define uma estratégia com duas fases e inclui as definições opcionais maxConcurrency e maxAllowedFailures:

   {
       "stages": [
           {
               "name": "stage-1",
               "maxConcurrency": "7",
               "maxAllowedFailures": "2",
               "groups": [
                   {
                       "name": "group-1",
                       "maxConcurrency": "3",
                       "maxAllowedFailures": "1"
                   },
                   {
                       "name": "group-2",
                       "maxConcurrency": "50%",
                       "maxAllowedFailures": "25%"
                   }
               ],
               "afterStageWaitInSeconds": 300
           },
           {
               "name": "stage-2",
               "maxConcurrency": "100%",
               "maxAllowedFailures": "0",
               "groups": [
                   {
                       "name": "group-3",
                       "maxConcurrency": "2",
                       "maxAllowedFailures": "0"
                   }
               ]
           }
       ]
   }
   

   maxConcurrency

   O maxConcurrency campo é opcional e controla quantos clusters podem ser atualizados simultaneamente ao nível do estágio ou grupo. Utilize um valor mais elevado para atualizar os clusters mais rapidamente em toda a sua frota, ou um valor mais baixo para uma implementação mais controlada que limite o impacto caso surjam problemas.

   Neste exemplo, stage-1 define maxConcurrency como "7", permitindo que até "7" clusters sejam atualizados simultaneamente. Dentro de stage-1, group-1 limita a concorrência a "3" clusters, o que significa que até "3" clusters neste grupo podem ser atualizados simultaneamente. group-2 permite que até "50%" um dos seus clusters sejam atualizados simultaneamente (por exemplo, se o grupo tiver 4 clusters, até 2 podem ser atualizados ao mesmo tempo).

   Os valores podem ser um inteiro fixo (por exemplo, "3") ou uma percentagem (por exemplo, "100%"). Se for omitido, o sistema aplica valores por defeito. Para detalhes sobre como estes valores são resolvidos e os seus limites superiores, veja Concorrência máxima (pré-visualização).

   maxAllowedFailures

   O maxAllowedFailures campo é opcional e controla quantas falhas de atualização de cluster de membros são toleradas antes de o grupo ou etapa ser marcado como falhado. Por defeito (quando desativado ou "0"), uma única falha interrompe toda a execução da atualização.

   Esta configuração avalia apenas o número de falhas. Não impõe uma taxa mínima de sucesso. Um grupo ou fase pode, portanto, terminar em Completed mesmo que alguns ou todos os membros tenham falhado, desde que o limiar de falha não tenha sido ultrapassado quando o Fleet tomou as suas decisões de agendamento.

   Neste exemplo, stage-1 define maxAllowedFailures como "2", tolerando até duas falhas de membros em todo o estágio. Dentro de stage-1, group-1 tolera a falha de "1" e group-2 tolera a falha de "25%" dos seus membros (por exemplo, se o grupo contiver 4 clusters, até 1 falha é tolerada). stage-2 define maxAllowedFailures como "0", o que significa que qualquer falha interrompe imediatamente a execução e é frequentemente útil em fases de produção.

   Para a maioria dos lançamentos, prefira valores baseados em percentagens porque escalam melhor entre diferentes tamanhos de grupo. Evite definir o valor como igual ao total de membros, a menos que queira intencionalmente um comportamento que, na prática, corresponda a "nunca falhar" para esse segmento.

   Os valores podem ser um inteiro fixo (por exemplo, "3") ou uma percentagem (por exemplo, "25%"). Para detalhes sobre como estes valores são resolvidos, veja Falhas Máximas permitidas (pré-visualização).

2. Crie uma nova estratégia de atualização usando o az fleet updatestrategy create comando com o sinalizador --stages definido como o nome do seu arquivo JSON.

   az fleet updatestrategy create \
    --resource-group $GROUP \
    --fleet-name $FLEET \
    --name $STRATEGY \
    --stages example-stages.json