Visão geral

Neste laboratório, você vai configurar e testar sondagens de atividade e prontidão do Kubernetes para contêineres.

Objetivos

Neste laboratório, você vai aprender a fazer o seguinte:

• Configurar e testar uma sondagem de atividade
• Configurar e testar uma sondagem de prontidão

Configuração do laboratório

Acesse o Qwiklabs

Para cada laboratório, você recebe um novo projeto do Google Cloud e um conjunto de recursos por um determinado período e sem custos financeiros.

1. Faça login no Qwiklabs em uma janela anônima.

2. Confira o tempo de acesso do laboratório (por exemplo, 1:15:00) e finalize todas as atividades nesse prazo.
   Não é possível pausar o laboratório. Você pode reiniciar o desafio, mas vai precisar refazer todas as etapas.

3. Quando tudo estiver pronto, clique em Começar o laboratório.

4. Anote as credenciais (Nome de usuário e Senha). É com elas que você vai fazer login no Console do Google Cloud.

5. Clique em Abrir Console do Google.

6. Clique em Usar outra conta, depois copie e cole as credenciais deste laboratório nos locais indicados.
   Se você usar outras credenciais, vai receber mensagens de erro ou cobranças.

7. Aceite os termos e pule a página de recursos de recuperação.

Depois que você concluir as etapas iniciais de login, o painel do projeto será exibido.

Ative o Google Cloud Shell

O Google Cloud Shell é uma máquina virtual com ferramentas de desenvolvimento. Ele tem um diretório principal permanente de 5 GB e é executado no Google Cloud.

O Cloud Shell oferece acesso de linha de comando aos recursos do Google Cloud.

1. No console do Cloud, clique no botão "Abrir o Cloud Shell" na barra de ferramentas superior direita.

   

2. Clique em Continuar.

O provisionamento e a conexão do ambiente podem demorar um pouco. Quando você estiver conectado, já estará autenticado, e o projeto estará definido com seu PROJECT_ID. Exemplo:

A gcloud é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.

• Para listar o nome da conta ativa, use este comando:

gcloud auth list

Saída:

Credentialed accounts: - @.com (active)

Exemplo de saída:

Credentialed accounts: - google1623327_student@qwiklabs.net

• Para listar o ID do projeto, use este comando:

gcloud config list project

Saída:

[core] project =

Exemplo de saída:

[core] project = qwiklabs-gcp-44776a13dea667a6 Observação: a documentação completa da gcloud está disponível no guia com informações gerais sobre a gcloud CLI .

Tarefa 1: conectar-se ao cluster do GKE do laboratório

Nesta tarefa, você vai se conectar ao cluster do GKE do laboratório, além de clonar o repositório do laboratório no Cloud Shell do laboratório.

Conexão com o cluster do GKE do laboratório

1. No Cloud Shell, digite o comando a seguir para definir a variável de ambiente da zona e o nome do cluster:

export my_zone={{{ project_0.default_zone | "ZONE" }}} export my_cluster=standard-cluster-1

2. Configure o preenchimento automático da ferramenta de linha de comando kubectl:

source <(kubectl completion bash)

3. Configure o acesso ao cluster para o kubectl:

gcloud container clusters get-credentials $my_cluster --zone $my_zone

4. No Cloud Shell, digite o comando a seguir para clonar o repositório no Cloud Shell deste laboratório:

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

5. Crie um link flexível como atalho para o diretório de trabalho:

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

6. Mude para o diretório que contém os arquivos de exemplo deste laboratório:

cd ~/ak8s/Probes/

Tarefa 2: configurar sondagens de atividade

Configure uma sondagem de atividade

Nesta tarefa, você vai implantar uma sondagem de atividade para detectar aplicativos que fizeram a transição do estado "em execução" para o estado "inválido". Às vezes, os aplicativos perdem temporariamente a capacidade de veicular tráfego. Por exemplo, um aplicativo pode precisar carregar dados ou arquivos de configuração grandes durante a inicialização.

Nesses casos, você não quer forçar o encerramento do aplicativo, mas também não quer enviar solicitações. O Kubernetes fornece sondagens de prontidão para detectar e mitigar essas situações. Um pod com contêineres informando que eles não estão prontos não recebe tráfego pelos serviços do Kubernetes.

As sondagens de prontidão são configuradas do mesmo modo que as de atividade. A única diferença é que você usa o campo readinessProbe em vez de livenessProbe.

Você recebeu o arquivo de definição de pod exec-liveness.yaml que define um contêiner simples chamado liveness que executa o Busybox e também uma sondagem de atividade que usa o comando cat no arquivo /tmp/healthy do contêiner para testar a atividade a cada 5 segundos.

O script de inicialização do contêiner liveness cria o /tmp/healthy e o exclui após 30 segundos para simular uma interrupção do serviço que a sondagem de atividade pode detectar.

apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec spec: containers: - name: liveness image: k8s.gcr.io/busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5

1. No Cloud Shell, execute o seguinte comando para criar o pod:

kubectl create -f exec-liveness.yaml

2. Em 30 segundos, veja os eventos do pod:

kubectl describe pod liveness-exec

A saída indica que nenhuma sondagem de atividade apresentou falhas até o momento.

Exemplo de saída resumida:

Type: Secret (a volume populated by a Secret) SecretName: default-token-wq52t Optional: false QoS Class: Burstable Node-Selectors: Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age ... Message ---- ------ ---- ... ------- Normal Scheduled 11s ... Successfully assigned liveness-e ... Normal Su...ntVolume 10s ... MountVolume.SetUp succeeded for ... Normal Pulling 10s ... pulling image "k8s.gcr.io/busybox" Normal Pulled 9s ... Successfully pulled image "k8s.g ... Normal Created 9s ... Created container Normal Started 9s ... Started container

A saída mostrada aqui foi resumida para facilitar a leitura. Você vai encontrar ainda mais detalhes na tela.

3. Após 35 segundos, veja os eventos do pod novamente:

kubectl describe pod liveness-exec

No fim da saída, há mensagens indicando que as sondagens de atividade apresentaram falhas e que os contêineres foram eliminados e criados novamente.

Exemplo de saída resumida:

Type: Secret (a volume populated by a Secret) SecretName: default-token-wq52t Optional: false QoS Class: Burstable Node-Selectors: Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age ... Message ---- ------ ---- ... ------- Normal Scheduled 2m ... Successfully assigned liveness-e ... Normal Su...ntVolume 2m ... MountVolume.SetUp succeeded for ... Normal Pulling 49s ... pulling image "k8s.gcr.io/busybox" Normal Pulled 49s ... Successfully pulled image "k8s.g ... Normal Created 49s ... Created container Normal Started 49s ... Started container Normal Killing 49s ... Killing container with id docker://liveness:Container failed liveness probe.. Container will be killed and recreated. Warning Unhealthy 5s ... Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory

4. Aguarde mais 60 segundos e veja se o contêiner foi reiniciado:

kubectl get pod liveness-exec

A resposta mostra que RESTARTS foi ampliado por causa da falha detectada pela sondagem de atividade:

Exemplo de resposta:

NAME READY STATUS RESTARTS AGE liveness-exec 1/1 Running 2 4m

5. Exclua o pod de demonstração da sondagem de atividade:

kubectl delete pod liveness-exec

Clique em Verificar meu progresso para ver o objetivo. Configure sondagens de atividade

Tarefa 3: configurar sondagens de prontidão

Um pod pode ser iniciado e considerado íntegro por uma sondagem de atividade, mas é provável que ele não esteja pronto para receber tráfego imediatamente. Isso é comum para implantações que servem como back-end para um serviço como um balanceador de carga. Uma sondagem de prontidão é usada para determinar quando um pod e os contêineres dele estão prontos para receber tráfego.

As sondagens de prontidão são configuradas do mesmo modo que as de atividade. A única diferença na configuração é que você usa o campo readinessProbe em vez de livenessProbe. As sondagens de prontidão definem se um contêiner específico pode ser considerado pronto. Isso é usado pelos serviços para decidir quando um contêiner pode receber o tráfego.

Nesta tarefa, foi disponibilizado um arquivo de definição de pod chamado readiness-deployment.yaml para você criar um pod único que será usado como servidor da Web de teste com um balanceador de carga.

O contêiner tem uma sondagem de prontidão definida que usa o comando cat no arquivo /tmp/healthz dele para testar a prontidão a cada 5 segundos.

Cada contêiner também tem uma sondagem de atividade definida que usa o comando cat para o mesmo arquivo dentro do contêiner, com o objetivo de testar a prontidão a cada cinco segundos. Entretanto, também há um atraso de 45 segundos para simular um aplicativo que talvez tenha um processo de inicialização complexo e que demora para se estabilizar após a inicialização do contêiner.

Depois que o serviço começar a lidar com o tráfego, esse padrão vai garantir que ele seja encaminhado apenas para contêineres prontos para lidar com ele.

apiVersion: v1 kind: Pod metadata: labels: demo: readiness-probe name: readiness-demo-pod spec: containers: - name: readiness-demo-pod image: nginx ports: - containerPort: 80 readinessProbe: exec: command: - cat - /tmp/healthz initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: readiness-demo-svc labels: demo: readiness-probe spec: type: LoadBalancer ports: - port: 80 targetPort: 80 protocol: TCP selector: demo: readiness-probe

1. No Cloud Shell, execute o seguinte comando para criar o pod:

kubectl create -f readiness-deployment.yaml

2. No Cloud Shell, verifique o status do serviço do balanceador de carga readiness-demo-svc:

kubectl get service readiness-demo-svc

3. Digite o endereço IP em uma janela do navegador. Você vai notar uma mensagem de erro indicando que o site não pode ser acessado.

4. Verifique os eventos do pod:

kubectl describe pod readiness-demo-pod

A saída vai mostrar que a sondagem de prontidão falhou:

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m24s default-scheduler Successfully assigned default/readiness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 2m23s kubelet Pulling image "nginx" Normal Pulled 2m23s kubelet Successfully pulled image "nginx" Normal Created 2m23s kubelet Created container readiness-demo-pod Normal Started 2m23s kubelet Started container readiness-demo-pod Warning Unhealthy 35s (x21 over 2m15s) kubelet Readiness probe failed: cat: /tmp/healthz: No such file or directory

Ao contrário da sondagem de atividade, uma sondagem de prontidão que não é íntegra não faz com que o pod seja reinicializado.

5. Use o comando a seguir para gerar o arquivo que a sondagem de prontidão está procurando:

kubectl exec readiness-demo-pod -- touch /tmp/healthz

Agora a seção Conditions da descrição do pod deve mostrar True como o valor de Ready.

kubectl describe pod readiness-demo-pod | grep ^Conditions -A 5

Saída:

Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True

6. Atualize a guia do navegador que tinha o IP externo de readiness-demo-svc. Você verá a mensagem Welcome to nginx! exibida corretamente.

Definir sondagens de prontidão significativas para seus contêineres de aplicativos garante que os pods só recebam o tráfego quando estiverem prontos. Um exemplo de uma sondagem de prontidão significativa é verificar se um cache do seu aplicativo é carregado na inicialização.

Clique em Verificar meu progresso para conferir o objetivo. Configure sondagens de prontidão

Monitorar o comportamento das sondagens de atividade e prontidão

Agora é possível verificar a correlação entre o status "Pronto" dos pods na implantação e os endpoints que estão ativos no seu serviço. Conforme os pods falham nos testes de sondagem de atividade e prontidão, eles são marcados como "não prontos", os endpoints são removidos do serviço e a sondagem de atividade inicia o processo de reinicialização para recuperar o pod com falha.

Os pods reiniciados não são marcados como "prontos" imediatamente e precisam aguardar a aprovação do teste de prontidão para que o serviço adicione o endpoint novamente ao pool.

1. Verifique o status dos pods novamente:

kubectl get pods

Você vai ver que os pods aparecem individualmente como "prontos". Dependendo do tempo, um ou mais deles talvez sejam reiniciados, mas pode demorar de dois a três minutos para que isso aconteça. Os pods listados como "prontos" precisam ter um endpoint correspondente associado ao serviço.

2. Para verificar se você consegue se conectar ao aplicativo, consulte primeiro o endereço IP externo nas informações de serviço do balanceador de carga e salve-o em uma variável de ambiente:

export EXTERNAL_IP=$(kubectl get services readiness-demo-svc -o json | jq -r '.status.loadBalancer.ingress[0].ip')

3. Verifique se o aplicativo está respondendo:

curl $EXTERNAL_IP

4. Nos próximos minutos, repita os comandos a seguir a cada 10 segundos para verificar o status da implantação e enviar uma solicitação ao balanceador de carga:

curl $EXTERNAL_IP kubectl get pods

Você ainda vai receber respostas sem falhas ou sem atingir o tempo limite mesmo que cada contêiner seja reiniciado regularmente por causa das falhas detectadas pelas sondagens de atividade. Se os três contêineres forem reiniciados mais ou menos ao mesmo tempo, talvez você ainda veja um tempo limite, mas isso raramente vai acontecer.

Com a combinação das sondagens de atividade e de prontidão, é possível garantir que os sistemas com falha sejam reiniciados com segurança enquanto o serviço encaminha o tráfego para contêineres que conseguem responder.

Finalize o laboratório

Clique em Terminar o laboratório após a conclusão. O Google Cloud Ensina remove os recursos usados e limpa a conta por você.

Você vai poder avaliar sua experiência no laboratório. Basta selecionar o número de estrelas, digitar um comentário e clicar em Enviar.

O número de estrelas indica o seguinte:

• 1 estrela = muito insatisfeito
• 2 estrelas = insatisfeito
• 3 estrelas = neutro
• 4 estrelas = satisfeito
• 5 estrelas = muito satisfeito

Feche a caixa de diálogo se não quiser enviar feedback.

Para enviar seu feedback, fazer sugestões ou correções, use a guia Suporte.

Copyright 2020 Google LLC. Todos os direitos reservados. Google e o logotipo do Google são marcas registradas da Google LLC. Todos os outros nomes de produtos e empresas podem ser marcas registradas das respectivas empresas a que estão associados.