Conceitos de Kubernetes para o Azure
Revise as principais construções do Kubernetes — pods, implantações, serviços e namespaces — e compreenda como o AKS gerencia o plano de controle em seu nome.
Conceitos de Kubernetes para o Azure é uma aula grátis de Cloud & IT Cert Prep no CoddyKit. Esta é a aula 3 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Cloud & IT Cert Prep, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Cloud & IT Cert Prep inclui 4 aulas no total.
O que é o Kubernetes?
O Kubernetes (K8s) é uma plataforma de orquestração de contêineres de código aberto, desenvolvida originalmente pelo Google. Ela automatiza a implantação, o dimensionamento e o gerenciamento de aplicações em contêineres. Em vez de executar contêineres manualmente, você declara o estado desejado da aplicação em manifestos YAML, e o Kubernetes trabalha continuamente para fazer com que o estado real corresponda ao estado desejado — reiniciando contêineres com falha, agendando cargas de trabalho em nós saudáveis e dimensionando réplicas.
Arquitetura do cluster: plano de controle e nós
Um cluster do Kubernetes é composto por um plano de controle e nós de trabalho. O plano de controle contém o servidor de API (ponto de entrada para todos os comandos kubectl), o etcd (repositório distribuído de estado), o agendador (atribui Pods aos nós) e o gerenciador de controladores (mantém o estado desejado). Os nós de trabalho executam o kubelet (agente do nó), o kube-proxy (regras de rede) e um ambiente de execução de contêineres (containerd). No AKS, a Microsoft gerencia o plano de controle — você gerencia apenas os nós de trabalho.
# Kubernetes control plane components
# kube-apiserver - REST API for all cluster operations
# etcd - Distributed key-value store (cluster state)
# kube-scheduler - Assigns pending pods to nodes
# kube-controller-manager - Runs reconciliation controllers
# Worker node components
# kubelet - Node agent, ensures containers run
# kube-proxy - Network routing for services
# containerd - Container runtime (runs containers)Pods: a menor unidade implantável
Um Pod é a menor unidade implantável no Kubernetes. Um Pod encapsula um ou mais contêineres que compartilham um espaço de nomes de rede (o mesmo endereço IP), volumes de armazenamento e ciclo de vida. Os contêineres dentro de um Pod comunicam-se por meio de localhost. Os Pods são efêmeros — quando falham, são substituídos por novos Pods com IPs diferentes. Raramente você cria Pods diretamente; em vez disso, cria recursos de nível superior que gerenciam os Pods.
# Simple pod manifest
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp
image: mycontainerregistry.azurecr.io/myapp:v1.0
ports:
- containerPort: 80
resources:
requests:
cpu: '100m'
memory: '128Mi'
limits:
cpu: '500m'
memory: '512Mi'Implantações: gerenciamento de Replica Sets
Uma Deployment é a maneira padrão de executar aplicações sem estado no Kubernetes. Ela cria e gerencia um ReplicaSet que mantém o número desejado de réplicas de Pods idênticos. As Deployments oferecem atualizações graduais — substituindo os Pods antigos gradualmente pelos novos — e reversões para versões anteriores. Você descreve o modelo de Pod desejado e a quantidade de réplicas; o Kubernetes cuida do restante.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # Create 1 extra pod during update
maxUnavailable: 0 # Never reduce below desired count
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: mycontainerregistry.azurecr.io/myapp:v1.0
ports:
- containerPort: 80Serviços: pontos de extremidade de rede estáveis
Como os Pods são efêmeros e seus IPs mudam, os Services fornecem um ponto de extremidade de rede estável que distribui o tráfego entre os Pods correspondentes. O serviço usa um seletor de rótulos para localizar os Pods. Tipos de serviço: ClusterIP (somente interno, padrão), NodePort (expõe uma porta em cada nó), LoadBalancer (provisiona um Azure Load Balancer com um IP público) e ExternalName (alias DNS para um serviço externo).
# Service exposing myapp pods externally
apiVersion: v1
kind: Service
metadata:
name: myapp-svc
spec:
type: LoadBalancer # Creates Azure Load Balancer
selector:
app: myapp # Routes traffic to pods with this label
ports:
- port: 80 # Service port
targetPort: 80 # Pod/container port
# After creation, check the EXTERNAL-IP (Azure LB public IP)
# kubectl get service myapp-svcNamespaces para multilocação
Os Namespaces particionam um único cluster do Kubernetes em vários clusters virtuais. Os recursos em Namespaces diferentes são isolados por nome — você pode ter uma Deployment chamada myapp tanto no Namespace development quanto no production simultaneamente. Os Namespaces são a principal unidade para aplicar RBAC, cotas de recursos e políticas de rede a uma equipe ou ambiente. Os Namespaces padrão incluem default, kube-system e kube-public.
# Create a namespace for the dev team
kubectl create namespace dev-team
# Deploy into a specific namespace
kubectl apply -f deployment.yaml --namespace dev-team
# List all resources in a namespace
kubectl get all --namespace dev-team
# Set default namespace for current context
kubectl config set-context --current --namespace dev-teamConfigMaps e Secrets
Os ConfigMaps armazenam dados de configuração não confidenciais como pares chave-valor ou arquivos, injetados nos Pods como variáveis de ambiente ou montagens de volume. Os Secrets armazenam dados confidenciais (senhas, tokens) codificados em base64 (não criptografados por padrão — use o Azure Key Vault Provider for Secrets Store CSI Driver para obter criptografia real em repouso). Ambos têm escopo de Namespace e são referenciados nas especificações de Pod pelo nome.
# Create a ConfigMap from literal values
kubectl create configmap app-config \
--from-literal=APP_ENV=production \
--from-literal=LOG_LEVEL=info
# Create a Secret
kubectl create secret generic db-secret \
--from-literal=DB_PASSWORD='super-secret'
# Reference in a pod spec
# env:
# - name: APP_ENV
# valueFrom:
# configMapKeyRef:
# name: app-config
# key: APP_ENV
# - name: DB_PASSWORD
# valueFrom:
# secretKeyRef:
# name: db-secret
# key: DB_PASSWORDVolumes persistentes no Azure
Aplicações com estado precisam de armazenamento que sobreviva aos Pods individuais. O Kubernetes usa PersistentVolumes (PVs) e PersistentVolumeClaims (PVCs) para separar o armazenamento do ciclo de vida do Pod. No AKS, as classes de armazenamento integradas Azure Disk e Azure Files provisionam discos gerenciados e compartilhamentos de arquivos automaticamente quando um PVC é criado. O Azure Disk é destinado ao acesso por um único Pod; o Azure Files oferece suporte à leitura e gravação simultâneas por vários Pods.
# PersistentVolumeClaim using Azure Disk
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-disk-pvc
spec:
accessModes:
- ReadWriteOnce # Single-node read/write (Azure Disk)
storageClassName: managed-csi
resources:
requests:
storage: 10Gi
# Mount in a pod
# volumes:
# - name: data
# persistentVolumeClaim:
# claimName: my-disk-pvc
# volumeMounts:
# - name: data
# mountPath: /dataHorizontal Pod Autoscaler
O HorizontalPodAutoscaler (HPA) ajusta automaticamente a quantidade de réplicas de Pods em uma Deployment com base na utilização observada de CPU/memória ou em métricas personalizadas. O controlador do HPA consulta o servidor de métricas a cada 15 segundos e aumenta ou reduz as réplicas para manter a utilização próxima do valor-alvo. Você define quantidades mínima e máxima de réplicas como limites de segurança para evitar um dimensionamento descontrolado.
# Create an HPA targeting 50% CPU utilisation
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50Verificações de integridade: sondas de atividade e prontidão
O Kubernetes usa sondas para monitorar a integridade dos contêineres. Uma sonda de atividade verifica se um contêiner ainda está em execução — se falhar, o Kubernetes reinicia o contêiner. Uma sonda de prontidão verifica se um contêiner está pronto para receber tráfego — se falhar, o Pod é removido do balanceamento de carga do Service sem ser reiniciado. Uma sonda de inicialização adia as outras sondas até que a aplicação seja inicializada, evitando reinicializações prematuras durante uma inicialização lenta.
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 15
periodSeconds: 20
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 80
initialDelaySeconds: 5
periodSeconds: 10
failureThreshold: 3
startupProbe:
httpGet:
path: /startup
port: 80
failureThreshold: 30
periodSeconds: 10 # Allow 300s for slow startupSolicitações e limites de recursos
Cada contêiner no Kubernetes deve declarar solicitações de recursos (a alocação mínima garantida usada pelo agendador) e limites (o máximo permitido, além do qual o contêiner sofre limitação ou é encerrado). As solicitações de CPU são expressas em millicores (m) — 1000m = 1 núcleo de CPU. Definir solicitações e limites com precisão evita problemas de vizinho barulhento e permite que o agendador distribua os Pods de maneira eficiente pelos nós sem comprometer excessivamente os recursos.
resources:
requests:
cpu: '250m' # 0.25 CPU core guaranteed
memory: '256Mi' # 256 MiB guaranteed
limits:
cpu: '1' # Max 1 CPU core
memory: '512Mi' # Max 512 MiB (OOMKilled if exceeded)Verificação rápida
Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) apresentados nesta lição.
Recapitulação da lição
Nesta lição, você aprendeu que: os pods são as menores unidades que podem ser implantadas e compartilham rede e armazenamento; os Deployments gerenciam conjuntos de réplicas sem estado com suporte a atualizações graduais; e os Services fornecem pontos de extremidade estáveis que distribuem o tráfego entre pods efêmeros. A seguir, exploraremos a implantação de cargas de trabalho no AKS.
Perguntas Frequentes
A aula “Conceitos de Kubernetes para o Azure” é grátis?
Sim — o texto completo de “Conceitos de Kubernetes para o Azure” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Cloud & IT Cert Prep, atualize para CoddyKit PRO. O curso de Cloud & IT Cert Prep inclui 4 aulas no total.
O que vou aprender em “Conceitos de Kubernetes para o Azure”?
Revise as principais construções do Kubernetes — pods, implantações, serviços e namespaces — e compreenda como o AKS gerencia o plano de controle em seu nome. Você pratica Cloud & IT Cert Prep com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar Cloud & IT Cert Prep?
Nenhuma experiência prévia é necessária. Cloud & IT Cert Prep no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 3 de 4.
Quanto tempo leva a aula “Conceitos de Kubernetes para o Azure”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de Cloud & IT Cert Prep?
Sim. Cada aula de Cloud & IT Cert Prep inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Registro de Contêineres do Azure
- Instâncias de Contêineres do Azure
- Conceitos de Kubernetes para o Azure
- Implantando Cargas de Trabalho no AKS