Aplicar o Manifest YAML
Nesta etapa, você explorará o comando kubectl apply com mais detalhes e aprenderá diferentes maneiras de aplicar manifestos Kubernetes. Com base nos arquivos YAML da etapa anterior, demonstraremos várias técnicas para aplicar manifestos.
Primeiro, certifique-se de estar no diretório correto:
cd ~/project/k8s-manifests
Vamos criar um novo subdiretório para organizar ainda mais nossos manifestos. Crie um diretório chamado manifests e navegue até ele:
mkdir -p manifests
cd manifests
Agora, vamos criar um manifesto para uma aplicação web simples que inclui tanto um Deployment quanto um Service em um único arquivo. Crie um novo arquivo chamado web-app.yaml usando nano:
nano web-app.yaml
Adicione o seguinte conteúdo a web-app.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:alpine
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
selector:
app: web
type: ClusterIP
ports:
- port: 80
targetPort: 80
Este manifesto define dois recursos Kubernetes em um único arquivo, separados por ---. Esta é uma maneira comum de agrupar recursos relacionados. Vamos detalhar o que há de novo:
- Múltiplos Recursos em um Único Arquivo: O arquivo
web-app.yaml agora contém duas definições de recursos Kubernetes separadas: um Deployment e um Service. O separador --- é usado para distingui-los.
kind: Service: Isso define um recurso Service.
spec.selector.app: web: Este Service terá como alvo pods que possuem o label app: web. Isso corresponde aos labels que definimos para os pods criados pelo Deployment web-app.spec.type: ClusterIP: Especifica o tipo de serviço como ClusterIP. Isso significa que o serviço será exposto em um endereço IP interno dentro do cluster e é tipicamente usado para comunicação entre serviços dentro do cluster.spec.ports: Define como o serviço mapeia portas para os pods de destino.
port: 80: A porta no próprio Service à qual você acessará.targetPort: 80: A porta nos pods de destino para a qual o serviço encaminhará o tráfego.
Agora, vamos aplicar este manifesto usando diferentes métodos.
Método 1: Aplicar o arquivo inteiro
Esta é a maneira mais comum de aplicar um manifesto. Use kubectl apply -f seguido pelo nome do arquivo:
kubectl apply -f web-app.yaml
Este comando criará tanto o Deployment quanto o Service definidos em web-app.yaml. Você deverá ver uma saída como:
deployment.apps/web-app created
service/web-service created
Método 2: Aplicar de um diretório
Você pode aplicar todos os manifestos em um diretório de uma vez. Se você tiver vários arquivos de manifesto no diretório manifests, pode aplicá-los todos especificando o diretório em vez de um arquivo específico:
kubectl apply -f .
O . representa o diretório atual. O kubectl procurará arquivos YAML neste diretório e aplicará todos eles. Isso é útil quando você organizou seus manifestos em vários arquivos dentro de um diretório.
Método 3: Aplicar de uma URL (Opcional)
O kubectl apply também pode aplicar manifestos diretamente de uma URL. Isso é útil para implantar rapidamente aplicações de exemplo ou configurações hospedadas online. Por exemplo, você pode implantar o deployment master do Redis do repositório de exemplos do Kubernetes:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/redis-master-deployment.yaml
Isso baixará o manifesto da URL e o aplicará ao seu cluster. Nota: Tenha cuidado ao aplicar manifestos de URLs não confiáveis, pois eles podem potencialmente modificar seu cluster.
Vamos explorar algumas opções adicionais para kubectl apply.
Dry Run
Você pode usar o flag --dry-run=client para simular a aplicação de um manifesto sem realmente fazer alterações no cluster. Isso é útil para verificar se o seu manifesto é válido e para ver quais recursos seriam criados ou modificados:
kubectl apply -f web-app.yaml --dry-run=client
Este comando exibirá o que seria criado ou alterado, mas não aplicará realmente as alterações ao seu cluster.
Saída Verbosa
Para uma saída mais detalhada do kubectl apply, você pode usar o flag -v seguido por um nível de verbosidade (por exemplo, -v=7). Níveis de verbosidade mais altos fornecem informações mais detalhadas, o que pode ser útil para depuração:
kubectl apply -f web-app.yaml -v=7
Isso imprimirá muito mais informações sobre as requisições da API que estão sendo feitas e o processamento do manifesto.
Verifique os recursos criados aplicando web-app.yaml. Use kubectl get deployments e kubectl get services para listar os Deployments e Services no seu cluster:
## Listar deployments
kubectl get deployments
## Listar services
kubectl get services
## Descrever o deployment para ver mais detalhes
kubectl describe deployment web-app
Exemplo de saída para kubectl get deployments:
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 3m33s
redis-master 0/1 1 0 23s
web-app 2/2 2 2 42s
Exemplo de saída para kubectl get services:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8m28s
web-service ClusterIP 10.106.220.33 <none> 80/TCP 46s
Observe que agora você tem um Deployment web-app com 2/2 réplicas READY e um web-service do tipo ClusterIP.
Vamos discutir brevemente a diferença entre gerenciamento declarativo e imperativo no Kubernetes, especialmente no contexto de kubectl apply e kubectl create.
kubectl apply: Usa uma abordagem declarativa. Você define o estado desejado em seus arquivos de manifesto, e o kubectl apply tenta alcançar esse estado. Se você executar kubectl apply várias vezes com o mesmo manifesto, o Kubernetes fará alterações apenas se houver diferenças entre o estado desejado no manifesto e o estado atual no cluster. O kubectl apply é geralmente recomendado para gerenciar recursos Kubernetes porque é mais robusto e fácil de gerenciar alterações ao longo do tempo. Ele rastreia a configuração dos seus recursos e permite atualizações incrementais.kubectl create: Usa uma abordagem imperativa. Você instrui diretamente o Kubernetes a criar um recurso. Se você tentar executar kubectl create para um recurso que já existe, geralmente resultará em um erro. O kubectl create é menos flexível para gerenciar atualizações e alterações em comparação com o kubectl apply.
Na maioria dos casos, especialmente para gerenciar implantações de aplicações, kubectl apply é o método preferido e recomendado devido à sua natureza declarativa e melhor tratamento de atualizações e gerenciamento de configuração.
