Validar a resiliência do Valkey durante uma atualização do pool de nós do AKS (Serviço de Kubernetes do Azure)

Usando o mesmo cluster Valkey no AKS (Serviço de Kubernetes do Azure) implantado com o Locust, você pode validar a resiliência do cluster Valkey durante uma atualização do pool de nós do AKS. Esse processo ajuda a validar que o Valkey mantém a resiliência durante as atualizações do pool de nós do AKS. O monitoramento com o Locust garante visibilidade na manipulação de solicitações e na disponibilidade de partições, permitindo que você gerencie atualizações com confiança e com interrupções mínimas no serviço.

Atualizar o cluster do AKS

1. Liste as versões disponíveis para o cluster do AKS e identifique a versão de destino para a qual você está atualizando usando o az aks get-upgrades comando.

   az aks get-upgrades --resource-group $MY_RESOURCE_GROUP_NAME --name $MY_CLUSTER_NAME --output table
   

2. Atualize o plano de controle do AKS usando o az aks upgrade comando. Neste exemplo, a versão de destino é 1.33.0.

   az aks upgrade --resource-group $MY_RESOURCE_GROUP_NAME --name $MY_CLUSTER_NAME --control-plane-only --kubernetes-version 1.33.0
   

Verificar o status do cliente do Locust

• Verifique se o cliente Locust iniciado no artigo anterior ainda está em execução. O painel do Locust mostrará o impacto da atualização do pool de nós do AKS no cluster Valkey.

Atualizar o pool de nós do Valkey

1. Atualize o pool de nós do Valkey usando o az aks nodepool upgrade comando.

   az aks nodepool upgrade \
       --resource-group $MY_RESOURCE_GROUP_NAME \
       --cluster-name $MY_CLUSTER_NAME \
       --kubernetes-version 1.33.0 \
       --name valkey
   

2. Enquanto o processo de atualização está em execução, você pode monitorar o painel do Locust para ver o status das solicitações do cliente. O painel deve ser semelhante à seguinte captura de tela:

   

   O painel mostra que o Locust está em execução com 100 usuários fazendo 50 solicitações por segundo. Durante o processo de atualização, um pod primário é removido quatro vezes. Você pode ver que o fragmento não está disponível por alguns segundos, mas o cluster Valkey ainda pode responder a solicitações para os outros fragmentos.

Conteúdo relacionado

Para saber mais sobre cargas de trabalho com estado no AKS, consulte Projetar e implantar cargas de trabalho com estado no AKS (Serviço de Kubernetes do Azure).