Faça a Atualização Caber na Quota

Introdução

A Aster Supply está servindo seu catálogo normal enquanto uma atualização de inverno está bloqueada. Seu namespace tem CPU solicitada suficiente para a operação habitual, mas não para o Pod extra solicitado durante uma atualização gradual. Você escolherá um orçamento de rollout que caiba na alocação fixa, manterá a loja de referência em execução e entregará o catálogo atualizado.

Você já deve conhecer caminhos básicos no terminal, YAML simples, Pods, Deployments, Services e labels. Este laboratório explica as unidades de solicitação de CPU, ResourceQuota e o cálculo do orçamento de atualização. O cluster real de um único nó, a aplicação, as verificações de saúde e os dados do catálogo estão preparados; não é necessário instalar o cluster, criar imagens nem programar a aplicação. O tempo estimado inclui leitura e erros comuns; é uma estimativa do autor.

Ajuste a Atualização ao Orçamento Fixo

Nesta etapa, você concluirá a atualização do catálogo de inverno da Aster Supply sem aumentar sua alocação de CPU nem parar a loja de referência.

A aba Shop mostra um catálogo em funcionamento. Abra Stoneware tray, anote seu preço e use Back to collection para voltar. A coleção atual Everyday essentials tem três produtos; a coleção solicitada The winter edit acrescenta Amber cup e altera preços. Abra a aba Reference: a Fern Stationery é um serviço separado e protegido que deve manter seu catálogo existente. Mantenha inalterados seu Deployment, Service e Pod original. Depois mude para a aba Workspace.

O cluster preparado é Kubernetes real, de um único nó. Um namespace agrupa os recursos deste curso. Uma ResourceQuota limita o total de recursos admitidos nesse namespace. Aqui ela acompanha somente as solicitações de CPU: CPU reservada para agendamento, não uma verba financeira nem um limite de uso medido de CPU. 1000m significa um núcleo de CPU; 40m significa 0,04 de um núcleo. A memória está preparada e não é o gargalo de quota desta tarefa.

Primeiro leia a quota. --context=labex-v135 seleciona o cluster preparado, -n shop-quota seleciona o namespace deste curso e describe exibe os detalhes de um objeto:

kubectl --context=labex-v135 -n shop-quota describe resourcequota shop-budget

Espere requests.cpu com Used 140m e Hard 140m. Isso é CPU reservada, não utilização atual. A loja original ainda está disponível, mas sua tentativa de atualização precisa de outro Pod. Uma réplica disponível passou pela verificação de prontidão e pelo período mínimo preparado de três segundos em estado pronto; apenas criar um Pod não o torna disponível. Leia o Deployment e seus ReplicaSets. Um ReplicaSet mantém Pods para um modelo de Deployment; rs é seu nome abreviado de recurso:

kubectl --context=labex-v135 -n shop-quota get deployments,rs,pods

Há três réplicas disponíveis da loja e uma réplica de referência. O novo ReplicaSet da loja não consegue criar seu Pod. Descreva ambos os ReplicaSets da loja; -l app=shop seleciona sua label:

kubectl --context=labex-v135 -n shop-quota describe rs -l app=shop

Encontre FailedCreate ou ReplicaFailure com exceeded quota: shop-budget, requested: requests.cpu=40m, used: requests.cpu=140m e limited: requests.cpu=140m. Isso é uma rejeição de admissão: esse novo Pod não foi criado. É diferente de um Pod Pending existente que um agendador não consegue alocar. Não altere a quota nem remova a carga de trabalho de referência.

O novo catálogo aprovado e o manifesto candidato já estão fornecidos. Entre explicitamente no espaço de trabalho. pwd exibe seu diretório atual; ls lista suas entradas:

cd /home/labex/project/shop-update

pwd

ls

Você deve ver approved, starter e tools. cat exibe o catálogo aprovado:

cat approved/catalogue.json

Leia todo o candidato com sed -n '1,180p': -n suprime a saída habitual, e p imprime as linhas de 1 a 180. O intervalo entre aspas é um único argumento:

sed -n '1,180p' starter/shop.yaml

A loja precisa de três réplicas, cada uma solicitando 40m. A referência protegida solicita 20m. Somente spec.strategy.rollingUpdate pode mudar; o novo modelo de aplicação fornecido, as réplicas, os recursos, os seletores e as verificações de saúde devem permanecer intactos.

Uma atualização gradual equilibra dois valores. maxSurge permite Pods extras acima da quantidade desejada de réplicas. maxUnavailable permite que algumas réplicas desejadas estejam indisponíveis. O requisito aqui é pelo menos duas réplicas disponíveis da loja durante a atualização observada. Com três réplicas desejadas, uma pode ficar temporariamente indisponível, mas nenhum Pod extra cabe na alocação. Escolha maxSurge: 0 e maxUnavailable: 1. Ambos os valores não podem ser zero. Recreate, excluir o Deployment, reduzir solicitações, diminuir a quantidade desejada de réplicas ou aumentar a quota estão fora desta tarefa.

Crie um diretório de versão editável e copie o candidato fornecido. mkdir cria um diretório; cp copia o arquivo. Os originais fornecidos são somente para leitura. chmod u+w acrescenta permissão de escrita para seu usuário na cópia:

mkdir release

cp starter/shop.yaml release/shop.yaml

chmod u+w release/shop.yaml

Se release já existir de uma tentativa anterior, mantenha-o e continue com a cópia que você está editando. Para um erro de digitação no caminho, use os comandos pwd, ls e cd absoluto acima antes de repetir o comando que falhou; um caminho ausente não exige reinicializar a VM.

sed -i edita um arquivo diretamente. Cada expressão s/old/new/ substitui o texto mostrado. As aspas simples mantêm juntos os espaços e a pontuação. Altere somente os dois valores de rollout em sua cópia:

sed -i 's/maxSurge: 1/maxSurge: 0/' release/shop.yaml

sed -i 's/maxUnavailable: 0/maxUnavailable: 1/' release/shop.yaml

Leia o início do manifesto salvo antes de aplicá-lo:

sed -n '1,35p' release/shop.yaml

Espere replicas: 3, type: "RollingUpdate", maxSurge: 0 e maxUnavailable: 1. apply -f reconcilia este arquivo com o Deployment existente; ele mantém a identidade do Deployment. rollout status espera pelas novas réplicas, com um --timeout finito:

kubectl --context=labex-v135 apply -f release/shop.yaml

kubectl --context=labex-v135 -n shop-quota rollout status deployment/shop --timeout=180s

Espere deployment "shop" successfully rolled out. O controlador pode remover uma réplica antiga, admitir uma nova, esperar que ela fique disponível e continuar. Pods em encerramento podem permanecer brevemente na contabilização de quota, portanto um evento FailedCreate adicional temporário pode se resolver naturalmente; isso não é motivo para alterar a quota. O orçamento de rollout não é um limite absoluto para todos os processos em encerramento nem uma garantia de disponibilidade contínua.

Se uma edição incorreta impedir a conclusão, inspecione o arquivo salvo e corrija os dois valores da estratégia. Para recuperar uma tentativa malsucedida ou uma falha na janela de observação, reaplique a configuração de base original aprovada e espere antes de tentar novamente sua versão corrigida:

kubectl --context=labex-v135 apply -f approved/shop.yaml

kubectl --context=labex-v135 -n shop-quota rollout status deployment/shop --timeout=180s

A opção --wait-baseline da ferramenta de status fornecida espera por uma observação recente e saudável do catálogo antigo antes de uma nova tentativa. Ela apenas lê fatos registrados:

./tools/update-status --wait-baseline

kubectl --context=labex-v135 apply -f release/shop.yaml

kubectl --context=labex-v135 -n shop-quota rollout status deployment/shop --timeout=180s

Esses comandos de recuperação são necessários somente para uma tentativa malsucedida. Mantenha inalterada a configuração de base fornecida. O observador somente para leitura mantém as tentativas e distingue uma nova tentativa completa da configuração de base até a atualização; a recuperação não apaga evidências anteriores.

Por fim, leia novamente a carga de trabalho e a quota reais:

kubectl --context=labex-v135 -n shop-quota get deployments

kubectl --context=labex-v135 -n shop-quota describe resourcequota shop-budget

Ambos os Deployments devem estar disponíveis: loja 3/3 e referência 1/1. Quando os Pods antigos terminam, o uso da quota volta a 140m, com o mesmo limite fixo. A próxima etapa verifica o catálogo que as pessoas realmente recebem.

Entregue o Catálogo Atualizado

Nesta etapa, você inspecionará a nova experiência do cliente e manterá um download real do catálogo junto com o manifesto de versão salvo.

Comece em Workspace, em /home/labex/project/shop-update. O comando fornecido tools/update-status resume amostras reais de API e HTTP registradas por um observador somente para leitura. O ./ inicial executa um programa a partir do diretório atual:

./tools/update-status

Ele informa o mínimo exigido, a quantidade de amostras, o menor número de réplicas disponíveis amostrado e o estado da atualização mais recente. Espere um mínimo de pelo menos duas e três réplicas atualizadas/disponíveis na conclusão. O observador coleta amostras aproximadamente a cada meio segundo mais o tempo da API, verifica a quota/referência originais e registra falhas. Deixe esse observador fornecido em execução. Ele não comprova o que aconteceu entre as amostras, não garante disponibilidade contínua em produção nem conserta o cluster. Uma verificação feita imediatamente após a conclusão do rollout pode exigir uma breve espera por duas amostras de conclusão. Se uma tentativa violou o mínimo exigido ou teve uma longa lacuna de observação, use a recuperação da configuração de base ensinada na etapa anterior antes de uma tentativa corrigida.

Mude para Shop e recarregue a página. Espere The winter edit, quatro produtos, Stoneware tray $20.00, Linen cloth $14.00, Bud vase $24.00 e Amber cup $16.00. Abra Amber cup e confirme seu preço e o status Available in store, depois retorne com Back to collection. Este é um catálogo, sem finalização de compra online.

A coleção concluída tem quatro cartões reais de produtos. Compare o título da coleção e os preços com este exemplo em execução:

Use Download catalogue. Abra o catalogue.csv baixado pelo navegador; suas quatro linhas de dados devem corresponder à coleção, aos nomes, aos preços em centavos e à disponibilidade mostrados no site. O download do navegador e o espaço de trabalho do terminal são locais diferentes. A seguir, salve o mesmo download real do Service no espaço de trabalho para a entrega.

Volte para Workspace. curl busca uma URL. --fail informa erros HTTP, --silent --show-error oculta o medidor de progresso mantendo os erros, e --output grava os bytes da resposta no arquivo indicado. 127.0.0.1:8081 é a entrada local preparada que encaminha para o Service original da loja:

curl --fail --silent --show-error http://127.0.0.1:8081/catalogue.csv --output catalogue.csv

cat catalogue.csv

Espere:

id,name,price_cents,available,collection
stone-tray,Stoneware tray,2000,true,The winter edit
linen-cloth,Linen cloth,1400,true,The winter edit
bud-vase,Bud vase,2400,true,The winter edit
amber-cup,Amber cup,1600,true,The winter edit

Um erro de conexão significa que a entrada local não pôde ser acessada; um erro HTTP é uma resposta de um servidor. Volte aos comandos de carga de trabalho e rollout ensinados para inspecionar o estado atual; não substitua o resultado por um arquivo estático nem altere o serviço de encaminhamento preparado. Se um download estiver incompleto ou for sobrescrito acidentalmente, repita o mesmo comando curl depois que o catálogo correto estiver disponível.

Abra Reference novamente e recarregue. A Fern Stationery ainda deve mostrar Desk essentials, Field notebook $9.00 e Clay pencil cup $14.00. Abra um produto e volte para confirmar que seus links reais continuam funcionando.

Sua entrega é release/shop.yaml mais o catalogue.csv real, sustentados pela nova versão completa, pela quota inalterada, pelo serviço de referência original e por uma tentativa válida de atualização observada. Preserve os originais fornecidos, a aplicação, os Services e o observador somente para leitura.

Resumo

Você relacionou uma rejeição real de quota de um ReplicaSet às necessidades temporárias de recursos de uma atualização gradual, calculou um orçamento adequado de réplicas extras e indisponíveis e concluiu o novo catálogo sem ampliar a alocação. Também manteve o serviço de referência protegido e entregou um CSV real junto com um manifesto de versão reutilizável.

As solicitações de CPU descrevem a contabilização de recursos, não a utilização medida nem uma promessa de desempenho. Observações nativas finitas sustentam a verificação de disponibilidade deste curso; elas não estabelecem disponibilidade ininterrupta em produção. Em outro namespace, recalcule tanto a alocação livre quanto o mínimo de réplicas disponíveis antes de escolher a estratégia.