Neste laboratório, exploraremos a arquitetura do Kubernetes, uma poderosa plataforma de orquestração de contêineres. Examinaremos os componentes-chave que compõem um cluster Kubernetes e aprenderemos como eles interagem para gerenciar aplicações em contêineres. Este laboratório foi projetado para iniciantes, fornecendo uma introdução prática à arquitetura do Kubernetes.
Vamos começar iniciando um cluster Kubernetes usando o Minikube e examinando os componentes do plano de controle.
Primeiro, abra seu terminal. Você deve estar no diretório /home/labex/project por padrão. Caso contrário, navegue até lá:
cd ~/projectAgora, inicie o Minikube com o seguinte comando:
minikube startEste comando inicializa um cluster Kubernetes de nó único em sua máquina local. Pode levar alguns minutos para ser concluído. Não se preocupe se você vir muita saída – isso é normal.
Depois que o Minikube for iniciado, vamos explorar os componentes do plano de controle. O plano de controle é o cérebro do Kubernetes, responsável por gerenciar o estado geral do cluster. Para verificar o status desses componentes, execute:
kubectl get componentstatusesVocê deve ver uma saída semelhante a esta:
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health":"true"}Vamos detalhar o que cada um desses componentes faz:
Se todos os componentes mostrarem "Healthy" (Saudável), seu plano de controle está funcionando corretamente. Se você vir algum erro, pode valer a pena reiniciar o Minikube com minikube delete seguido por minikube start.
Agora que analisamos o plano de controle, vamos examinar os componentes do nó. No Kubernetes, os nós são as máquinas de trabalho que executam suas aplicações. Pense neles como os músculos do seu cluster, fazendo o trabalho pesado de executar contêineres.
Para ver os nós em seu cluster, execute:
kubectl get nodesVocê deve ver uma saída semelhante a esta:
NAME STATUS ROLES AGE VERSION
minikube Ready control plane 10m v1.20.0Esta saída mostra que temos um nó chamado "minikube", que é tanto um nó mestre (plano de controle) quanto um nó de trabalho, pois estamos usando um cluster de nó único. Em um ambiente de produção, você normalmente teria vários nós, com nós mestre e de trabalho separados.
O status "Ready" (Pronto) significa que o nó está saudável e pronto para aceitar Pods.
Para obter informações mais detalhadas sobre o nó, use:
kubectl describe node minikubeEste comando fornece uma grande quantidade de informações sobre o nó. Não se preocupe se parecer esmagador – vamos detalhar algumas seções-chave:
Os principais componentes do nó, que você não verá diretamente, mas estão em execução no nó, incluem:
Antes de mergulharmos, vamos entender como o YAML funciona no Kubernetes:
Arquivos YAML no Kubernetes atuam como "Infraestrutura como Código":
Vamos criar nosso primeiro arquivo YAML. Crie simple-pod.yaml:
nano ~/project/simple-pod.yamlAdicione o seguinte conteúdo:
## --- Início do arquivo YAML ---
## 1. Diga ao Kubernetes qual versão da API usar
apiVersion: v1
## 2. Declare que tipo de recurso queremos criar
kind: Pod
## 3. Defina metadados para este recurso
metadata:
name: nginx-pod ## Nome do Pod
labels: ## Labels nos ajudam a encontrar e organizar Pods
app: nginx
## 4. Defina o que o Pod deve conter
spec:
containers: ## Pod pode executar um ou mais contêineres
- name: nginx ## Nome do contêiner
image: nginx:latest ## Qual imagem de contêiner usar
ports: ## Quais portas expor
- containerPort: 80 ## Nginx usa a porta 80 por padrãoA estrutura do arquivo YAML é como uma árvore:
Pod (raiz)
├── metadata (ramo)
│ ├── name (folha)
│ └── labels (folha)
└── spec (ramo)
└── containers (ramo)
└── - name, image, ports (folhas)Crie o Pod:
kubectl apply -f simple-pod.yaml ## -f significa ler do arquivoEste comando irá:
Verifique a criação do Pod:
kubectl get podsVocê deve ver:
NAME READY STATUS RESTARTS AGE
nginx-pod 1/1 Running 0 30sO "1/1" em READY significa que um de um contêineres no Pod está pronto. "Running" em STATUS significa que sua primeira configuração YAML funcionou!
💡 Dicas Profissionais:
- A indentação em YAML é crucial - use espaços, não tabs
- Use
kubectl explain podpara ver a documentação dos campos- Sempre adicione comentários para melhor manutenibilidade
Para obter informações detalhadas sobre o pod:
kubectl describe pod nginx-podEste comando fornece muitas informações, incluindo:
Esta informação é crucial para depurar e entender o estado de sua aplicação.
Agora que temos um pod em execução, vamos criar um Service para expô-lo. No Kubernetes, um Service é uma abstração que define um conjunto lógico de Pods e uma política para acessá-los. Pense nisso como uma maneira de expor sua aplicação à rede, seja dentro do cluster ou externamente.
Crie um arquivo chamado nginx-service.yaml em seu diretório de projeto:
nano ~/project/nginx-service.yamlAdicione o seguinte conteúdo ao arquivo:
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: NodePortVamos detalhar este arquivo YAML:
selector: Isso determina para quais Pods o Service enviará tráfego. Neste caso, ele selecionará quaisquer Pods com o rótulo app: nginx.ports: Isso especifica quais portas o Service deve usar.type: NodePort: Isso significa que o Service estará acessível em uma porta em cada nó do seu cluster.Salve o arquivo e saia do editor.
Agora, crie o service executando:
kubectl apply -f nginx-service.yamlPara verificar o status do seu service, use:
kubectl get servicesVocê deve ver uma saída semelhante a esta:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1h
nginx-service NodePort 10.110.126.65 <none> 80:30080/TCP 30sA linha nginx-service mostra que seu service foi criado. O 80:30080/TCP em PORT(S) significa que a porta 80 dentro do cluster está mapeada para a porta 30080 no nó.
Para obter informações mais detalhadas sobre o service, use:
kubectl describe service nginx-serviceEste comando fornece informações sobre o tipo, endereços IP, portas e endpoints do service. Os endpoints são os endereços IP dos Pods para os quais o Service está enviando tráfego.
Agora que temos um pod executando nossa aplicação e um service expondo-a, vamos acessar a aplicação. Esta etapa mostrará como todos os componentes que configuramos trabalham juntos para tornar sua aplicação acessível.
Primeiro, precisamos descobrir a URL que o Minikube atribuiu ao nosso service:
minikube service nginx-service --urlEste comando irá gerar uma URL, que deve ser algo como http://192.168.64.2:30080. O endereço IP pode ser diferente em sua máquina.
Para acessar a aplicação, você pode usar o comando curl seguido pela URL:
curl $(minikube service nginx-service --url)Isso deve retornar a página HTML de boas-vindas padrão do Nginx. Se você vir uma saída HTML começando com <!DOCTYPE html>, parabéns! Você acessou sua aplicação com sucesso.
Vamos detalhar o que acabou de acontecer:
Isso demonstra como o Kubernetes abstrai a infraestrutura subjacente, permitindo que você se concentre em sua aplicação, em vez de se preocupar com qual máquina específica ela está sendo executada.
Neste laboratório, exploramos a arquitetura do Kubernetes, examinando seus principais componentes e suas interações. Iniciamos um cluster Kubernetes usando o Minikube, inspecionamos o plano de controle e os componentes do nó, criamos um pod para executar uma aplicação, expusemos a aplicação usando um service e, finalmente, acessamos a aplicação.
Aprendemos sobre:
Esta experiência prática fornece uma base sólida para entender a arquitetura do Kubernetes. Lembre-se, o Kubernetes é um sistema complexo com muitas partes móveis, e não há problema se você não entender tudo imediatamente. À medida que você continuar a trabalhar com o Kubernetes, esses conceitos se tornarão mais familiares e intuitivos.
Os próximos passos em sua jornada no Kubernetes podem incluir aprender sobre Deployments para gerenciar múltiplas réplicas de sua aplicação, ConfigMaps e Secrets para gerenciar a configuração e Persistent Volumes para armazenamento de dados. Continue explorando e feliz Kuberneting!
