Como Executar Comandos em Pods do Kubernetes na Inicialização - Guia Prático

Introdução

Este tutorial guia você através da execução de comandos em pods do Kubernetes na inicialização. Você aprenderá como configurar comandos de inicialização usando os campos command e args, executar múltiplos comandos e lidar com falhas na inicialização. Usaremos o Minikube para criar um ambiente Kubernetes local onde você poderá praticar esses conceitos na prática.

Ao final deste laboratório, você entenderá como personalizar o comportamento de seus pods do Kubernetes durante a inicialização e garantir uma implantação suave da aplicação. Este conhecimento é essencial para configurar corretamente aplicações em contêineres em um ambiente Kubernetes.

Configurando Seu Ambiente Kubernetes

Nesta etapa, prepararemos nosso ambiente iniciando o Minikube e entendendo os conceitos básicos do Kubernetes necessários para este laboratório.

O que é Kubernetes?

Kubernetes é uma plataforma de código aberto projetada para automatizar a implantação, o dimensionamento e a operação de contêineres de aplicações. No cerne do Kubernetes estão os Pods - as menores unidades implantáveis que podem ser criadas e gerenciadas.

Iniciando o Minikube

Minikube é uma ferramenta que permite executar o Kubernetes localmente. Vamos iniciá-lo:

minikube start --driver=docker

Este comando criará um cluster Kubernetes local usando o Docker como driver. O processo de inicialização pode levar alguns minutos, pois ele baixa os componentes necessários.

Você deve ver uma saída semelhante a:

😄  minikube v1.30.1 on Ubuntu 22.04
✨  Using the docker driver based on user configuration
📌  Using Docker driver with root privileges
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=2200MB) ...
🐳  Preparing Kubernetes v1.27.4 on Docker 24.0.4 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
🌟  Enabled addons: default-storageclass, storage-provisioner
💡  kubectl not found. If you need it, try: 'minikube kubectl -- get pods -A'
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Verificando a Instalação

Vamos verificar se tudo está funcionando corretamente, verificando o status do nosso cluster Minikube:

minikube status

Você deve ver uma saída indicando que o Minikube está em execução:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Agora, vamos verificar se o kubectl (a ferramenta de linha de comando do Kubernetes) está configurado corretamente:

kubectl get nodes

Você deve ver um nó (sua instância Minikube) listado como Ready:

NAME       STATUS   ROLES           AGE     VERSION
minikube   Ready    control-plane   2m15s   v1.27.4

Entendendo os Pods do Kubernetes

Um Pod é a unidade básica de execução de uma aplicação Kubernetes. Cada Pod representa um processo em execução no seu cluster e encapsula um ou mais contêineres. Os Pods são efêmeros por design, o que significa que podem ser criados, destruídos e recriados conforme necessário.

No Kubernetes, você normalmente define Pods em arquivos YAML. Para este laboratório, já preparamos alguns arquivos YAML de exemplo em seu ambiente.

Vamos para o diretório onde esses arquivos estão localizados:

cd ~/project/kubernetes-examples
ls -la

Você deve ver os seguintes arquivos:

total 20
drwxr-xr-x 2 labex labex 4096 Sep 21 10:00 .
drwxr-xr-x 3 labex labex 4096 Sep 21 10:00 ..
-rw-r--r-- 1 labex labex  193 Sep 21 10:00 basic-pod.yaml
-rw-r--r-- 1 labex labex  254 Sep 21 10:00 liveness-probe-pod.yaml
-rw-r--r-- 1 labex labex  312 Sep 21 10:00 multi-command-pod.yaml
-rw-r--r-- 1 labex labex  263 Sep 21 10:00 startup-command-pod.yaml

Agora que nosso ambiente está configurado, estamos prontos para começar a trabalhar com Pods do Kubernetes e aprender como executar comandos na inicialização.

Criando Seu Primeiro Pod com Comandos Básicos de Inicialização

Nesta etapa, criaremos nosso primeiro Pod do Kubernetes e entenderemos como ele executa comandos na inicialização. Examinaremos o campo command, que define o que o contêiner deve executar quando inicia.

Explorando a Configuração Básica do Pod

Primeiro, vamos examinar a configuração de um Pod básico. Abra o arquivo basic-pod.yaml com o editor nano:

nano basic-pod.yaml

Você verá um arquivo YAML com o seguinte conteúdo:

apiVersion: v1
kind: Pod
metadata:
  name: basic-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c", "echo 'Pod is running' && sleep 3600"]

Esta configuração define:

Um Pod chamado basic-pod
Um único contêiner chamado ubuntu usando a imagem ubuntu:20.04
Um comando de inicialização que ecoa uma mensagem e, em seguida, dorme por 3600 segundos (1 hora)

O campo command especifica o executável que será executado quando o contêiner iniciar. Neste caso, estamos executando o shell /bin/bash com a flag -c, que nos permite passar uma string de comandos para executar.

Pressione Ctrl+X para sair do editor nano.

Criando o Pod

Vamos criar este Pod em nosso cluster Kubernetes:

kubectl apply -f basic-pod.yaml

Você deve ver uma saída como:

pod/basic-pod created

Verificando o Status do Pod

Agora, vamos verificar se nosso Pod está sendo executado corretamente:

kubectl get pods

Você deve ver uma saída semelhante a:

NAME        READY   STATUS    RESTARTS   AGE
basic-pod   1/1     Running   0          30s

Isso indica que nosso Pod está sendo executado com sucesso. O 1/1 em READY significa que um contêiner está em execução de um contêiner esperado.

Visualizando os Logs do Pod

Para ver a saída do nosso comando de inicialização, podemos verificar os logs do Pod:

kubectl logs basic-pod

Você deve ver:

Pod is running

Isso confirma que nosso comando de inicialização foi executado com sucesso.

Explorando o Contêiner em Execução

Vamos examinar o que está acontecendo dentro do nosso contêiner executando um shell interativo:

kubectl exec -it basic-pod -- /bin/bash

Agora você está dentro do shell do contêiner. Vamos verificar se nosso processo está em execução:

ps aux

Você deve ver o comando sleep em execução, que faz parte do nosso comando de inicialização:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   4112  3372 ?        Ss   10:05   0:00 /bin/bash -c echo 'Pod is running' && sleep 3600
root         7  0.0  0.0   4112  3536 pts/0    Ss   10:06   0:00 /bin/bash
root        14  0.0  0.0   5900  2928 pts/0    R+   10:06   0:00 ps aux
root        15  0.0  0.0   2512   580 ?        S    10:06   0:00 sleep 3600

O processo com PID 1 é nosso comando de inicialização, e o comando sleep 3600 está sendo executado como um processo separado.

Saia do shell do contêiner digitando:

exit

Entendendo o Ciclo de Vida do Pod

Quando você cria um Pod, ele passa por várias fases:

Pending (Pendente): O Pod foi aceito pelo Kubernetes, mas ainda não está em execução
Running (Em execução): O Pod está em execução com todos os contêineres
Succeeded (Bem-sucedido): Todos os contêineres no Pod foram encerrados com sucesso
Failed (Falha): Todos os contêineres foram encerrados, e pelo menos um contêiner falhou
Unknown (Desconhecido): O estado do Pod não pode ser determinado

Nosso Pod está no estado Running porque nosso processo principal (sleep 3600) ainda está em execução. Quando este processo for concluído ou for encerrado, o Pod fará a transição para o estado Succeeded ou Failed, dependendo do código de saída.

Agora você entende como criar um Pod básico e executar comandos na inicialização usando o campo command.

Usando Command e Args para Configuração de Inicialização

Nesta etapa, aprenderemos como usar os campos command e args juntos para configurar comportamentos de inicialização mais complexos em Pods do Kubernetes.

Entendendo Command e Args

O Kubernetes fornece duas maneiras principais de especificar o comando que é executado quando um contêiner inicia:

command: Especifica o executável a ser executado (semelhante ao ENTRYPOINT do Docker)
args: Especifica os argumentos a serem passados para o comando (semelhante ao CMD do Docker)

Usar esses campos separadamente ou juntos oferece flexibilidade na forma como seus contêineres são iniciados.

Explorando o Pod de Comando de Inicialização

Vamos examinar o arquivo startup-command-pod.yaml:

nano startup-command-pod.yaml

Você verá a seguinte configuração:

apiVersion: v1
kind: Pod
metadata:
  name: startup-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash"]
      args:
        ["-c", "echo 'Custom startup message' > /tmp/startup.txt && sleep 3600"]

Nesta configuração:

O campo command especifica que queremos executar /bin/bash
O campo args fornece os argumentos a serem passados para o bash: -c e a string contendo nossos comandos

Essa separação de comando e argumentos torna a configuração mais legível e fácil de manter.

Pressione Ctrl+X para sair do editor nano.

Criando o Pod de Comando de Inicialização

Vamos criar este Pod:

kubectl apply -f startup-command-pod.yaml

Você deve ver:

pod/startup-command-pod created

Verificando o Status do Pod

Verifique se o Pod está em execução:

kubectl get pods startup-command-pod

Você deve ver:

NAME                  READY   STATUS    RESTARTS   AGE
startup-command-pod   1/1     Running   0          30s

Verificando o Comando de Inicialização

Agora, vamos verificar se nosso comando de inicialização foi executado corretamente, verificando se ele criou o arquivo esperado:

kubectl exec startup-command-pod -- cat /tmp/startup.txt

Você deve ver:

Custom startup message

Isso confirma que nosso comando foi executado com sucesso e criou o arquivo com o conteúdo especificado.

Entendendo a Diferença entre Command e Args

A relação entre command e args é importante de entender:

Se você especificar apenas command, ele substitui o ENTRYPOINT padrão da imagem do contêiner
Se você especificar apenas args, ele substitui o CMD padrão da imagem do contêiner
Se você especificar command e args, eles substituem tanto o ENTRYPOINT quanto o CMD

Vamos ver o que acontece se modificarmos a configuração do nosso Pod. Crie um novo arquivo chamado modified-command-pod.yaml:

nano modified-command-pod.yaml

Adicione o seguinte conteúdo:

apiVersion: v1
kind: Pod
metadata:
  name: modified-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/echo"]
      args: ["This message is printed by echo"]

Salve e saia com Ctrl+X, seguido por Y e Enter.

Agora, vamos criar este Pod:

kubectl apply -f modified-command-pod.yaml

Você deve ver:

pod/modified-command-pod created

Verifique os logs para ver o que aconteceu:

kubectl logs modified-command-pod

Você deve ver:

This message is printed by echo

Observe como o Pod executou o comando /bin/echo com nosso argumento especificado e, em seguida, foi encerrado, pois echo sai após imprimir sua saída.

Verifique o status do Pod:

kubectl get pods modified-command-pod

Você deve ver algo como:

NAME                   READY   STATUS      RESTARTS   AGE
modified-command-pod   0/1     Completed   0          45s

O status Completed indica que o Pod foi executado até a conclusão e saiu com sucesso.

Agora você entende como usar command e args juntos para configurar o comportamento de inicialização em Pods do Kubernetes.

Executando Múltiplos Comandos e Lidando com Falhas de Inicialização

Nesta etapa, aprenderemos como executar vários comandos na inicialização do Pod e como lidar com falhas de inicialização usando verificações de integridade.

Executando Múltiplos Comandos

Frequentemente, você precisa executar vários comandos quando um contêiner inicia. Existem várias maneiras de fazer isso no Kubernetes:

Encadeie comandos usando operadores de shell (&&, ;, etc.)
Use um arquivo de script
Use um contêiner init

Vamos explorar o primeiro método examinando o arquivo multi-command-pod.yaml:

nano multi-command-pod.yaml

Você verá:

apiVersion: v1
kind: Pod
metadata:
  name: multi-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        [
          "echo 'First command' > /tmp/first.txt && echo 'Second command' > /tmp/second.txt && sleep 3600"
        ]

Esta configuração encadeia vários comandos usando o operador &&, que executa cada comando somente se o anterior for bem-sucedido.

Pressione Ctrl+X para sair do editor.

Vamos criar este Pod:

kubectl apply -f multi-command-pod.yaml

Você deve ver:

pod/multi-command-pod created

Agora, vamos verificar se ambos os comandos foram executados, verificando os arquivos criados:

kubectl exec multi-command-pod -- cat /tmp/first.txt

Você deve ver:

First command

E para o segundo arquivo:

kubectl exec multi-command-pod -- cat /tmp/second.txt

Você deve ver:

Second command

Lidando com Falhas de Inicialização com Verificações de Integridade

O Kubernetes fornece mecanismos para detectar e lidar com falhas de inicialização:

Liveness Probes (Sondas de Vivacidade): Verificam se o contêiner está em execução; caso contrário, o Kubernetes o reiniciará
Readiness Probes (Sondas de Prontidão): Verificam se o contêiner está pronto para receber tráfego
Startup Probes (Sondas de Inicialização): Verificam se o aplicativo foi iniciado; útil para contêineres de inicialização lenta

Vamos examinar um Pod que usa uma sonda de vivacidade:

nano liveness-probe-pod.yaml

Você verá:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-probe-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args: ["touch /tmp/healthy && sleep 3600"]
      livenessProbe:
        exec:
          command: ["cat", "/tmp/healthy"]
        initialDelaySeconds: 5
        periodSeconds: 5

Nesta configuração:

O contêiner cria um arquivo /tmp/healthy na inicialização
A sonda de vivacidade verifica este arquivo a cada 5 segundos
Se o arquivo estiver ausente, o Kubernetes considera o contêiner não íntegro e o reinicia

Pressione Ctrl+X para sair do editor.

Vamos criar este Pod:

kubectl apply -f liveness-probe-pod.yaml

Você deve ver:

pod/liveness-probe-pod created

Verifique se o Pod está em execução:

kubectl get pods liveness-probe-pod

Você deve ver:

NAME                 READY   STATUS    RESTARTS   AGE
liveness-probe-pod   1/1     Running   0          30s

Agora, vamos ver o que acontece se removermos o arquivo de verificação de integridade:

kubectl exec liveness-probe-pod -- rm /tmp/healthy

Aguarde cerca de 10 segundos e, em seguida, verifique o status do Pod novamente:

kubectl get pods liveness-probe-pod

Você deve ver que o contêiner foi reiniciado:

NAME                 READY   STATUS    RESTARTS   AGE
liveness-probe-pod   1/1     Running   1          60s

A contagem de RESTARTS aumentou para 1, indicando que o Kubernetes detectou o estado não íntegro e reiniciou o contêiner.

Vamos verificar se o arquivo de verificação de integridade existe novamente (ele deveria ter sido recriado pelo comando de inicialização quando o contêiner reiniciou):

kubectl exec liveness-probe-pod -- ls -la /tmp/healthy

Você deve ver que o arquivo existe novamente:

-rw-r--r-- 1 root root 0 Sep 21 10:30 /tmp/healthy

Isso demonstra como o Kubernetes pode se recuperar automaticamente de falhas de inicialização e manter o estado desejado de seus aplicativos.

Criando um Script de Inicialização Personalizado

Para uma inicialização mais complexa, você pode querer usar um script de inicialização personalizado. Vamos criar um Pod que usa um script de shell para inicialização:

nano script-pod.yaml

Adicione o seguinte conteúdo:

apiVersion: v1
kind: Pod
metadata:
  name: script-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          cat > /tmp/startup.sh << 'EOF'
          #!/bin/bash
          echo "Script started at $(date)" > /tmp/script-log.txt
          echo "Creating configuration files..." >> /tmp/script-log.txt
          mkdir -p /tmp/config
          echo "app_name=MyApp" > /tmp/config/app.conf
          echo "version=1.0" >> /tmp/config/app.conf
          echo "Script completed successfully" >> /tmp/script-log.txt
          EOF
          chmod +x /tmp/startup.sh
          /tmp/startup.sh
          sleep 3600

Esta configuração:

Cria um script de inicialização no contêiner
Torna-o executável
Executa o script
Mantém o contêiner em execução com sleep

Salve e saia com Ctrl+X, seguido por Y e Enter.

Vamos criar este Pod:

kubectl apply -f script-pod.yaml

Você deve ver:

pod/script-pod created

Aguarde um momento para o Pod iniciar e, em seguida, verifique seu status:

kubectl get pods script-pod

Você deve ver:

NAME         READY   STATUS    RESTARTS   AGE
script-pod   1/1     Running   0          30s

Agora, vamos verificar a saída do nosso script:

kubectl exec script-pod -- cat /tmp/script-log.txt

Você deve ver algo como:

Script started at Tue Sep 21 10:35:42 UTC 2023
Creating configuration files...
Script completed successfully

E vamos verificar se o arquivo de configuração foi criado:

kubectl exec script-pod -- cat /tmp/config/app.conf

Você deve ver:

app_name=MyApp
version=1.0

Isso demonstra como usar scripts de inicialização complexos para inicializar seus contêineres no Kubernetes.

Melhores Práticas e Aplicações do Mundo Real

Nesta etapa final, exploraremos as melhores práticas para executar comandos em Pods do Kubernetes na inicialização e criaremos um exemplo de aplicação do mundo real que implementa essas práticas.

Melhores Práticas para Comandos de Inicialização

Ao configurar comandos de inicialização para Pods do Kubernetes, considere estas melhores práticas:

Mantenha os comandos de inicialização idempotentes: Os comandos devem ser seguros para serem executados várias vezes sem causar problemas
Use verificações de integridade: Implemente sondas de vivacidade e prontidão para verificar a inicialização bem-sucedida
Lide com falhas com elegância: Inclua tratamento de erros em seus scripts de inicialização
Separe as preocupações: Use contêineres init para tarefas de inicialização separadas de seu aplicativo principal
Limite o tempo de inicialização: Mantenha a inicialização rápida para reduzir o tempo de implantação
Use variáveis de ambiente: Torne seus comandos de inicialização configuráveis por meio de variáveis de ambiente
Registre o progresso da inicialização: Gere logs claros para solução de problemas

Usando Contêineres Init para Tarefas de Inicialização

Os contêineres init são executados antes que os contêineres de aplicativos iniciem e são ideais para tarefas de configuração. Vamos criar um Pod com um contêiner init:

nano init-container-pod.yaml

Adicione o seguinte conteúdo:

apiVersion: v1
kind: Pod
metadata:
  name: init-container-pod
spec:
  initContainers:
    - name: init-config
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          echo "Initializing configuration..."
          mkdir -p /work-dir/config
          echo "database_url=mysql://user:password@db:3306/mydb" > /work-dir/config/db.conf
          echo "api_key=1234567890" > /work-dir/config/api.conf
          echo "Initialization complete"
      volumeMounts:
        - name: shared-volume
          mountPath: /work-dir
  containers:
    - name: app
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          echo "Application starting..."
          echo "Reading configuration:"
          cat /work-dir/config/db.conf
          cat /work-dir/config/api.conf
          echo "Application running..."
          sleep 3600
      volumeMounts:
        - name: shared-volume
          mountPath: /work-dir
  volumes:
    - name: shared-volume
      emptyDir: {}

Nesta configuração:

O contêiner init init-config é executado primeiro e cria arquivos de configuração
Ambos os contêineres compartilham um volume chamado shared-volume
O contêiner principal do aplicativo lê a configuração criada pelo contêiner init

Salve e saia com Ctrl+X, seguido por Y e Enter.

Vamos criar este Pod:

kubectl apply -f init-container-pod.yaml

Você deve ver:

pod/init-container-pod created

Verifique o status do Pod:

kubectl get pods init-container-pod

Você deve ver que o Pod está em execução:

NAME                 READY   STATUS    RESTARTS   AGE
init-container-pod   1/1     Running   0          30s

Agora, vamos verificar os logs do contêiner principal:

kubectl logs init-container-pod -c app

Você deve ver algo como:

Application starting...
Reading configuration:
database_url=mysql://user:password@db:3306/mydb
api_key=1234567890
Application running...

Isso confirma que o contêiner init criou com sucesso os arquivos de configuração e o contêiner principal foi capaz de lê-los.

Exemplo do Mundo Real: Aplicação Web com Verificação de Banco de Dados

Vamos criar um exemplo mais realista - uma aplicação web que verifica a disponibilidade do banco de dados antes de iniciar:

nano webapp-pod.yaml

Adicione o seguinte conteúdo:

apiVersion: v1
kind: Pod
metadata:
  name: webapp-pod
spec:
  initContainers:
    - name: wait-for-db
      image: busybox:1.28
      command: ["/bin/sh", "-c"]
      args:
        - |
          echo "Checking for database availability..."
          ## In a real scenario, this would check an actual database
          ## For this example, we'll simulate success after a short delay
          sleep 5
          echo "Database is available"
          touch /tmp/db-ready
      volumeMounts:
        - name: shared-volume
          mountPath: /tmp
  containers:
    - name: webapp
      image: nginx:1.19
      ports:
        - containerPort: 80
      command: ["/bin/sh", "-c"]
      args:
        - |
          if [ -f /tmp/db-ready ]; then
            echo "Database connection verified, starting web application..."
            ## Customize nginx configuration
            echo "<h1>Web Application Started Successfully</h1>" > /usr/share/nginx/html/index.html
            echo "<p>Connected to database</p>" >> /usr/share/nginx/html/index.html
            ## Start nginx
            nginx -g 'daemon off;'
          else
            echo "Error: Database not available"
            exit 1
          fi
      volumeMounts:
        - name: shared-volume
          mountPath: /tmp
      readinessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 5
  volumes:
    - name: shared-volume
      emptyDir: {}

Esta configuração:

Usa um contêiner init para verificar a disponibilidade do banco de dados (simulado)
O contêiner principal verifica um arquivo criado pelo contêiner init antes de iniciar
Inclui uma sonda de prontidão para verificar se o aplicativo está servindo tráfego
Usa um volume compartilhado para comunicação entre contêineres

Salve e saia com Ctrl+X, seguido por Y e Enter.

Vamos criar este Pod:

kubectl apply -f webapp-pod.yaml

Você deve ver:

pod/webapp-pod created

Aguarde um momento para o Pod iniciar totalmente e, em seguida, verifique seu status:

kubectl get pods webapp-pod

Você deve ver:

NAME         READY   STATUS    RESTARTS   AGE
webapp-pod   1/1     Running   0          30s

O 1/1 na coluna READY indica que a sonda de prontidão foi bem-sucedida.

Vamos encaminhar a porta para acessar a aplicação web:

kubectl port-forward webapp-pod 8080:80 &

Este comando é executado em segundo plano (devido ao &). Agora podemos acessar a aplicação web usando curl:

curl http://localhost:8080

Você deve ver:

<h1>Web Application Started Successfully</h1>
<p>Connected to database</p>

Isso confirma que nosso aplicativo foi inicializado corretamente, verificou a disponibilidade do banco de dados e agora está servindo tráfego.

Pare o processo de encaminhamento de porta:

pkill -f "kubectl port-forward"

Limpeza

Antes de concluir o laboratório, vamos limpar os recursos que criamos:

kubectl delete pod basic-pod startup-command-pod modified-command-pod multi-command-pod liveness-probe-pod script-pod init-container-pod webapp-pod

Você deve ver:

pod "basic-pod" deleted
pod "startup-command-pod" deleted
pod "modified-command-pod" deleted
pod "multi-command-pod" deleted
pod "liveness-probe-pod" deleted
pod "script-pod" deleted
pod "init-container-pod" deleted
pod "webapp-pod" deleted

Agora você aprendeu como executar comandos em Pods do Kubernetes na inicialização, executar vários comandos, lidar com falhas e aplicar as melhores práticas em cenários do mundo real.

Resumo

Neste laboratório, você aprendeu como executar comandos em Pods do Kubernetes na inicialização. Você adquiriu experiência prática com:

Configuração de um ambiente Kubernetes usando Minikube
Criação e gerenciamento de Pods com comandos de inicialização específicos
Uso dos campos command e args para configurar o comportamento do contêiner
Execução de múltiplos comandos usando operadores de shell e scripts
Tratamento de falhas de inicialização com verificações de integridade
Implementação de melhores práticas com contêineres init
Construção de aplicações do mundo real que exigem inicialização adequada

Essas habilidades são essenciais para implantar aplicações em contêineres em ambientes Kubernetes. Ao configurar corretamente os comandos de inicialização, você pode garantir que suas aplicações sejam inicializadas corretamente, verificar as dependências e lidar com erros com elegância.

Ao continuar sua jornada no Kubernetes, lembre-se de que a inicialização adequada da aplicação é uma parte crítica da construção de sistemas confiáveis, escaláveis e sustentáveis.