DEV Community: DeividFerraz

Services no Kubernetes

DeividFerraz — Mon, 06 Apr 2026 02:07:57 +0000

🚀 O que eu aprendi sobre Kubernetes Service (e por que isso finalmente fez sentido pra mim)

Depois de apanhar um pouco tentando entender como minha API realmente “se comunica” dentro do cluster, finalmente caiu a ficha sobre o papel do Service no Kubernetes.

Se você também já ficou confuso com Pods mudando de IP, balanceamento e tipos de Service… esse resumo pode te ajudar 👇

🧠 Primeiro insight (o mais importante)
👉 Pods são efêmeros

Eles sobem e caem

O IP muda o tempo todo

👉 Service resolve isso

Dá um IP fixo + DNS estável

E ainda faz load balancing automaticamente

⚙️ Como o Service realmente funciona
O Service não “conhece” ReplicaSet, Deployment nem nada disso.

Ele só faz:

selector:
app: minha-api
E pensa:

“Vou mandar tráfego pra qualquer Pod com essa label”

💥 Pronto. É assim que ele encontra os Pods.

⚖️ Load Balancing
Se você tem 3 Pods:

Pod A (IP 10.0.0.1)
Pod B (IP 10.0.0.2)
Pod C (IP 10.0.0.3)
O Service faz:

Cliente → Service → distribui entre A, B, C
👉 Você não precisa saber os IPs 👉 Você não precisa atualizar nada manualmente

🔌 Sobre portas
ports:

port: 80 targetPort: 3000 port → porta do Service

targetPort → porta do container

💡 Dica: use named ports pra deixar mais claro:

ports:

port: 80 targetPort: http Um ponto importante. Esse (http) é apenas o nome dado para a porta na sessão de containers.ports dentro do yaml do POD, ou no meu caso do ReplicaSet.

🌐 Os 2 tipos mais usados na prática
🔵 1. ClusterIP (padrão)
👉 Usado para comunicação interna

type: ClusterIP
✔️ Só funciona dentro do cluster ✔️ Ideal para microservices ✔️ Mais seguro

Exemplo real:

backend falando com banco

API interna chamando outro serviço

🟢 2. LoadBalancer
👉 Usado para expor para fora

type: LoadBalancer
✔️ Cria um IP externo ✔️ Acessível via internet ✔️ Ideal para APIs públicas

Exemplo:

sua API que será consumida por frontend ou terceiros

🧠 Boas práticas que aprendi
✅ Use labels consistentes (app, tier, etc.) ✅ Prefira ClusterIP por padrão (segurança) ✅ Só use LoadBalancer quando precisar expor ✅ Use named ports pra facilitar manutenção ✅ Sempre confira os endpoints se algo não funcionar.

🔥 Resumo mental
Pod = efêmero

Service = estável

Labels = conexão 🔗

Service = load balancer automático ⚖️

💬 Conclusão
O Service não é só “um detalhe” do Kubernetes.

Ele é o que transforma:

👉 containers isolados em 👉 um sistema distribuído que funciona de verdade

🚨 CrashLoopBackOff no Kubernetes: o que é e por que acontece?

DeividFerraz — Mon, 30 Mar 2026 04:14:55 +0000

Quem trabalha com Kubernetes cedo ou tarde encontra esse status no terminal:

CrashLoopBackOff

Ele aparece quando um container dentro do Pod falha repetidamente e o Kubernetes passa a reiniciá-lo com um tempo de espera progressivo entre as tentativas. Esse status é mostrado pelo kubectl para indicar exatamente esse ciclo de falha + reinício + espera.

🔁 Como funciona na prática

Quando a aplicação quebra, o Kubernetes não reinicia o container infinitamente sem pausa.

Ele aplica um backoff exponencial, com atrasos como:

10s → 20s → 40s → 80s...

Esse tempo cresce até um limite máximo de 5 minutos entre as tentativas de reinício. Se a aplicação continuar falhando, o Kubernetes continua tentando, mas respeitando esse teto.

🛡️ Qual é a finalidade do CrashLoopBackOff?

A ideia não é “travar” o Pod por acaso. O objetivo é:

evitar reinícios inúteis sem parar
reduzir consumo desnecessário de recursos no node e no cluster
dar tempo para diagnóstico
deixar claro que a aplicação está falhando repetidamente

Ou seja: o CrashLoopBackOff é uma forma de proteger a infraestrutura e, ao mesmo tempo, evidenciar que algo está errado na aplicação.

⏱️ E os 10 minutos?

Existe um ponto importante aqui: se o container conseguir ficar 10 minutos rodando sem falhar, o Kubernetes zera o contador do backoff. Então, se ele voltar a quebrar depois disso, a próxima espera volta a começar do início, em vez de continuar num intervalo alto.

⚙️ O papel do restartPolicy

O comportamento também depende da política de reinício do Pod:

Always: sempre tenta reiniciar
OnFailure: reinicia apenas se houver erro
Never: não reinicia automaticamente

O valor padrão em Pods é Always.

✅ E quando o Pod termina com sucesso?

Isso também pode gerar reinício, dependendo da política usada.

Se um container termina com sucesso, mas o Pod está com restartPolicy: Always, ele pode ser iniciado novamente. Só que esse não costuma ser o modelo ideal para tarefas que têm começo, meio e fim.

🧩 Quando usar Job em vez de Pod?

Para tarefas que executam e terminam, o recurso mais adequado normalmente é um Job.

O Job existe justamente para workloads finitas e aceita apenas restartPolicy: Never ou OnFailure no template do Pod. Quando a tarefa termina com sucesso, o Job considera a execução concluída.

🎯 Resumindo

O CrashLoopBackOff não é só um erro visual no terminal.
Ele é um mecanismo do Kubernetes para:

desacelerar reinícios de uma aplicação quebrada
evitar desperdício de recursos
facilitar diagnóstico
proteger o node e o cluster

Em resumo: se o Pod falha repetidamente, o Kubernetes não reinicia “na marra” para sempre ele controla esse comportamento de forma inteligente.

etcd: a camada de armazenamento do Kubernetes

DeividFerraz — Mon, 23 Mar 2026 17:55:05 +0000

Boa tarde, Pessoal. 👋

etcd: a camada de armazenamento do Kubernetes

Estudando Kubernetes, comecei a olhar com mais atenção para alguns componentes que quase não aparecem no uso do dia a dia, mas são fundamentais para o funcionamento do cluster. Um deles é o etcd.

Quando estamos em ambientes gerenciados, principalmente em nuvem, é muito fácil focar só em Deployment, Service, Ingress, escalabilidade e esquecer da base que sustenta o estado do cluster. Mas entender isso ajuda bastante a enxergar melhor o funcionamento do Kubernetes por trás dos panos.

━━━━━━━━━━━━━━━━━━

📌 O que é o etcd?

━━━━━━━━━━━━━━━━━━

O etcd é um banco de dados distribuído do tipo chave-valor que o Kubernetes usa para armazenar o estado do cluster.

É nele que ficam registradas informações como:

• Pods

• Services

• Deployments

• ConfigMaps

• Secrets

• Namespaces

• entre outros objetos do plano de controle

Ou seja, boa parte do que existe no cluster, em algum momento, depende do etcd para ter esse estado armazenado.

━━━━━━━━━━━━━━━━━━

⚙️ Como ele participa da arquitetura do Kubernetes

━━━━━━━━━━━━━━━━━━

Na prática, a comunicação acontece principalmente por meio do kube-apiserver. É ele que recebe as requisições, faz a validação, processa as informações e consulta ou grava esses dados no etcd.

Isso ajuda a entender melhor o papel do etcd: mesmo sem aparecer tanto no uso diário, ele é uma peça central da arquitetura.

Em ambientes com alta disponibilidade, o etcd pode rodar em múltiplos nós, formando um cluster distribuído. Isso aumenta a resiliência e reduz o risco de indisponibilidade em caso de falha de uma instância.

Por isso, a saúde do etcd impacta diretamente a saúde do cluster.

━━━━━━━━━━━━━━━━━━

💾 E o backup, como funciona?

━━━━━━━━━━━━━━━━━━

Como o etcd armazena o estado do cluster, manter backups regulares é essencial para recuperação em cenários de desastre, como perda de nós do plano de controle ou corrupção de dados.

A forma mais comum de fazer isso é por meio de snapshot.

Esse snapshot registra o conteúdo do banco naquele momento e pode ser usado depois em uma restauração.

Um detalhe importante: não é necessário parar o kube-apiserver para gerar esse backup.

O etcd permite criar snapshot a partir de um membro em execução usando o comando etcdctl snapshot save. Ou seja, esse processo pode ser feito com o serviço ativo.

━━━━━━━━━━━━━━━━━━

🧩 Exemplo de comando: doc: Operando clusters etcd para Kubernetes | Kubernetes

━━━━━━━━━━━━━━━━━━

🔎 O que esse comando faz: Leia a doc: https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/

━━━━━━━━━━━━━━━━━━

🛠️ Exemplo prático: Leia a doc também: https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/

━━━━━━━━━━━━━━━━━━

Depois de gerar o backup, ainda é possível validar o snapshot com:

etcdutl --write-out=table snapshot status /backup/etcd-snapshot.db

Kubernetes #DevOps #Cloud #SRE #Containers

Deploy aplicação no cluster do aks 🚀

DeividFerraz — Tue, 17 Mar 2026 19:25:04 +0000

Eae pessoal! 👋

Hoje vou compartilhar com vocês uma forma simples e eficiente de criar um pipeline em YAML no Azure DevOps para publicar uma aplicação no AKS (Azure Kubernetes Service).🚀

Contexto:

Aqui na empresa, já temos um repositório central com templates prontos de pipeline + Helm, o que acelera muito o processo de criação de novas APIs e jobs.

Neste post, vou mostrar como usamos esse template.

👉 Em um próximo, posso mostrar como fazer tudo do zero.

🧩 Estrutura do pipeline

A ideia é bem simples:

Criamos um repositório do projeto

Adicionamos um azure-pipelines.yml mínimo

Referenciamos um template centralizado

Ou seja:

👉 O projeto praticamente não precisa de configuração — a inteligência já está no template.

📦 Pipeline do projeto

No YAML do projeto, definimos apenas o essencial:

branch

dockerFilePath

dockerBuildContext

Todo o restante vem do template e de arquivos como o values.yaml.

💡 Isso reduz drasticamente erros e padroniza deploys.

⚙️ O papel do template (Helm + Pipeline)

O template é o coração da solução.

Ele é responsável por:

Build da imagem Docker

Push para o container registry

Deploy no AKS via Helm

Configuração de ambiente (Dev/Prod)

Integração com variáveis e secrets

👉 Ou seja: ao rodar o pipeline, toda a infraestrutura é provisionada automaticamente e a aplicação já sobe no cluster do AKS.

🧠 Por que usar Helm + Templates?

A principal vantagem é abstrair a infraestrutura do desenvolvedor.

O dev:

Não precisa acessar o portal do Azure

Não precisa configurar Kubernetes manualmente

Só precisa garantir que o projeto está correto

⚠️ Boas práticas ao criar templates Helm

Aqui vai um ponto importante 👇

O poder do template depende de como você o constrói. Algumas boas práticas:

🔹 Padronize nomes e labels (facilita observabilidade)

🔹 Separe configs por ambiente (dev, staging, prod)

🔹 Use values.yaml bem estruturado

🔹 Evite hardcode de credenciais (use secrets/Key Vault)

🔹 Permita override de variáveis importantes

🔹 Versione o chart Helm

🔹 Adicione health checks (liveness/readiness probes)

🔹 Defina requests/limits de CPU e memória

Um bom template evita retrabalho e reduz incidentes em produção.

--- 🧪 Resultado

Com esse modelo, precisamos basicamente informar:

Caminho do Dockerfile

Contexto de build

Branch

E pronto 🚀

O pipeline cuida de todo o resto e a aplicação já sobe no cluster do AKS.

Imagem de exemplo prático no meu linkedin: https://www.linkedin.com/feed/update/urn:li:activity:7439753064225366016/?originTrackingId=WQDMTOfIYxXFTM3qmKO3KA%3D%3D

🚀 Pods no Kubernetes (com 2 containers no mesmo Pod):

DeividFerraz — Tue, 23 Sep 2025 22:21:53 +0000

Continuação...

2) Services (um para cada porta do mesmo Pod):
apiVersion: v1
kind: Service
metadata:
name: api3a-svc
namespace: prod
spec:
selector: { app: api3, svc-api3a: "true" }

ports: [{ port: 80, targetPort: 8080 }]

apiVersion: v1
kind: Service
metadata:
name: api3b-svc
namespace: prod
spec:
selector: { app: api3, svc-api3b: "true" }
ports: [{ port: 80, targetPort: 8081 }]

⁉️Service não “aponta para container”; ele seleciona Pods por label. O que diferencia é o targetPort. exemplo: 10.224.0.31(PodIP):(targetPort)8080. _________________________________________________________________________________ 3) Ingress (um host, vários paths → Services): apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: prod-paths namespace: prod annotations: https://lnkd.in/du23U4PY: / spec: ingressClassName: nginx rules:
host: 20-246-240-254.sslip.io # ou api.seu-dominio.com http: paths:
path: /api3a //necessario para encaminhar ao backend abaixo(service) pathType: Prefix backend: { service: { name: api3a-svc, port: { number: 80 } } }
path: /api3b pathType: Prefix backend: { service: { name: api3b-svc, port: { number: 80 } } }

🚀 Pods no Kubernetes (com 2 containers no mesmo Pod):

DeividFerraz — Tue, 23 Sep 2025 22:14:50 +0000

☝️ Resumo do artigo:

Cliente → DNS/Host → IP público (LB do ingress-nginx) -> Pod do ingress-nginx (Nginx) → Ingress (host + path).
Ingress decide quem recebe (host + path) e fala com Service. -> Service (ClusterIP:port, L4) → Endpoints (PodIP:targetPort).
Service seleciona Pods por labels e encaminha para PodIP:targetPort. -> Pod (containers compartilham o mesmo IP, portas diferentes).
Pod = mesmo IP para todos os containers; o que muda é a porta.

🚢 O que é um Pod:
Menor unidade implantável, pode ter 1 ou mais containers.

Containers do mesmo Pod compartilham:
Network namespace → mesmo IP (o Pod IP), localhost comum
Volumes (se montados).

IMPORTANTE: Você não cria Pod “puro” na produção: cria um Deployment, que cria ReplicaSet, que cria Pods.

🧭 Por que usar Namespaces?

Isolam nomes: api1 em dev e api1 em prod.
Controlam acesso (RBAC), quotas, políticas de rede.
Ciclo de vida: deletar o namespace remove tudo.

🧪 Exemplo prático: duas APIs no mesmo Pod (api3a + api3b):
1) Deployment (um Pod com 2 containers, portas 8080 e 8081):
apiVersion: apps/v1
kind: Deployment
metadata:
name: api3
namespace: prod
spec:
replicas: 1
selector:
matchLabels: { app: api3 }
template:
metadata:
labels:
app: api3
svc-api3a: "true" # ajuda os Services a “enxergar” este Pod
svc-api3b: "true"
spec:
containers:

name: api3a image: https://suaiamgem ports: [{ name: http-api3a, containerPort: 8080 }] env: [{ name: ASPNETCORE_URLS, value: http://+:8080 }] readinessProbe: { httpGet: { path: "/", port: 8080 }, initialDelaySeconds: 5, periodSeconds: 10 } livenessProbe: { httpGet: { path: "/", port: 8080 }, initialDelaySeconds: 10, periodSeconds: 20 }
name: api3b image: https://suaimagem ports: [{ name: http-api3b, containerPort: 8081 }] env: [{ name: ASPNETCORE_URLS, value: http://+:8081 }] readinessProbe: { httpGet: { path: "/", port: 8081 }, initialDelaySeconds: 5, periodSeconds: 10 } livenessProbe: { httpGet: { path: "/", port: 8081 }, initialDelaySeconds: 10, periodSeconds: 20 } ⁉️ - Por quê duas portas?
Containers do mesmo Pod compartilham IP, então precisam portas diferentes.

CONTINUAÇÂO NO PRÒXIMO POST...

Redes virtuais do Azure.

DeividFerraz — Sat, 13 Sep 2025 04:08:25 +0000

🌐 Redes Virtuais no Azure: conectividade segura e de alta disponibilidade para sua empresa

No mundo digital de hoje, conectar ambientes locais à nuvem com segurança, baixa latência e resiliência deixou de ser um diferencial e passou a ser uma necessidade. O Azure oferece uma variedade de opções de redes virtuais que permitem interligar datacenters, filiais e usuários remotos ao poder da nuvem, garantindo escalabilidade e proteção contra falhas.

🔹 Tipos de conexões de rede virtual

Ponto-a-Site (P2S):

Ideal para usuários individuais, como colaboradores remotos.
O próprio computador do usuário inicia uma VPN criptografada até a VNet no Azure.
Ótima opção para home office ou acessos ocasionais.

Site-a-Site (S2S):

Perfeito para integração contínua de datacenters locais ou filiais.
Um appliance VPN local se conecta ao Azure VPN Gateway.
A rede local é estendida para a nuvem como se fosse uma única infraestrutura.

ExpressRoute:

Para quem precisa de segurança e desempenho máximos.
Conexão privada e dedicada ao backbone da Microsoft, sem passar pela Internet pública.
Ideal para workloads críticos, replicações de dados em larga escala e cenários regulatórios.

🔹 Conectando redes virtuais no Azure:

Além de conectar sua empresa à nuvem, o Azure também permite interligar VNets entre si por meio de:

Emparelhamento de VNets (VNet Peering): conecta redes virtuais de forma transparente e privada, usando o backbone da Microsoft.
Service Endpoints e Private Endpoints: formas de expor serviços como Storage e SQL de maneira segura, evitando exposição pública.

🔹 Alta disponibilidade e proteção contra falhas:

Quando falamos em continuidade de negócios, a arquitetura de rede também precisa ser resiliente:

Gateways ativo/ativo: dois IPs públicos para reduzir downtime.
Gateways redundantes em zonas de disponibilidade: proteção contra falhas físicas em datacenters.
Failover com ExpressRoute + VPN: se a conexão dedicada falhar, uma VPN site-a-site pode assumir como backup.
Esses recursos garantem que sua empresa continue operando mesmo em cenários de falha ou manutenção.

🔹 Segurança e roteamento de tráfego:

NSGs (Network Security Groups): filtros em nível de rede (L3/L4) para controlar tráfego entre sub-redes.
Tabelas de rotas (UDRs): regras personalizadas de encaminhamento.
BGP (Border Gateway Protocol): troca dinâmica de rotas entre sua rede e o Azure.
Com isso, é possível controlar fluxos, segmentar ambientes e proteger dados sensíveis.

🚀 Conclusão

As redes virtuais do Azure oferecem flexibilidade para diferentes cenários: de um desenvolvedor acessando remotamente recursos de teste até grandes corporações que demandam links dedicados, redundância e alta segurança.

Docker Compose: Simplificando o Gerenciamento de Containers

DeividFerraz — Sat, 23 Aug 2025 05:09:06 +0000

O Docker revolucionou a forma como desenvolvemos e entregamos aplicações, mas gerenciar vários containers manualmente pode ser confuso e trabalhoso. Para não haver esse tipo de problema que entra o Docker Compose. Docker compose é uma ferramenta poderosa que permite definir e orquestrar múltiplos containers de forma simples e organizada, usando um único arquivo YAML (nome de arquivo padrão: docker-compose.yml).

✅ Em que momento usar o Docker compose?
Quando vc tiver aplicações que conversam entre si, é ideal usar o Docker Compose, Pq ele permite agrupar esses serviços. Por exemplo: uma aplicação web pode depender de um banco de dados e de um cache, e todos esses containers podem ser definidos e gerenciados juntos.

Beneficios:

Serviços como, imagens, porta, rede entre outros ficam descritos no mesmo arquivo, assim, ficam mais facil de serem manipulados.
Com apenas um simples comando, conseguimos subir, para reconstruir toda a stack de serviços, só isso já elimina a necessidade de escrever varios comandos para instanciar apenas um container.
O mesmo arquivo pode ser usado em diferentes máquinas e ambientes (local, staging, produção), garantindo consistência e evitando o famoso “na minha máquina funciona”. Isso é possível porque toda a aplicação é encapsulada em containers, que incluem suas dependências e configuram um ambiente padronizado.
Independentemente se você estiver rodando em Linux, Windows ou macOS, o Docker garante essa compatibilidade.

Código usado:

docker-compose -f docker-compose-local.yml -p dev-store up -d Explicação dos termos: -f: especifica qual arquivo YAML usar (ex.: docker-compose-local.yml). -p: define o nome do projeto (usado para nomear containers, rede e volumes). up: sobe todos os serviços definidos no YAML. -d: executa em modo “detached” (em segundo plano).
É importante usar para n ficar preso no terminal.

Imagens e Containers: pensando como classe e instância

DeividFerraz — Fri, 22 Aug 2025 03:45:43 +0000

Quando eu comecei a mexer com Docker, acabava confundindo bastante imagens com containers, e creio que muita gente também. Eles são muito relacionados, mas não são a mesma coisa. Uma imagem é um pacote encapsulado com tudo que a aplicação precisa para rodar, já um container é a imagem em execução, com seu próprio processo e configurações de rede.

Vi uma análogia no treinamento que estou fazendo atualmente que deixou tudo isso ainda mais claro.
--(Em termos de programação orientada a objetos: imagem é como a classe, e container é como a instância da classe. EX: var car = new Carro();)

-Através dele, você pode expor na rede por meio de portas, dar um nome e fazer algumas alterações. Só não podemos esquecer que toda alteração feita em um container fica salva apenas na memória daquele container.

Para resumir, o container acaba se tornando a sua imagem gerenciada.

Redes no Docker, Bridge e Outras Possibilidades

DeividFerraz — Wed, 20 Aug 2025 03:30:21 +0000

-Quando trabalhamos com containers, um dos pontos mais importantes é como eles se comunicam entre si e com o mundo externo. É aqui que entram as redes do Docker, que garantem conectividade, isolamento e flexibilidade.

-Existem alguns tipos de rede no docker, o principal entre eles é; Bridge.
Os containers conectados a uma rede bridge podem se comunicar entre si usando o nome do container como hostname.
Também permite comunicação com o host e com a internet, quando configurada.

Comando exemplo para criar uma rede e já indicar o driver (O tipo de rede) que aquele container vai ser exposto;

docker network create --driver bridge/TipoDeRede minha-rede/nomeDaMinhaRede

Conhecimento em redes é a base para começar a entender como os containers se relacionam entre si.
hashtag#docker hashtag#rede #8080 hashtag#port

[Boost]

DeividFerraz — Wed, 20 Aug 2025 03:28:46 +0000

Volumes no Docker: Como Persistir e Compartilhar Dados

DeividFerraz — Mon, 18 Aug 2025 19:16:35 +0000

Quando usamos containers, um dos maiores desafios é a persistência de dados.
Por padrão, tudo que é criado dentro de um container é temporário. Se o container for parado ou removido, os dados são perdidos.

É aqui que entram os volumes no Docker, uma forma de mapear diretórios do host para dentro do container, garantindo persistência e até compartilhamento de arquivos.

Como funciona o volume no Docker:

Exemplo base: docker run -d -p 8088:80 --name n-demo -v C:\Users\deivi\EstudoImagens\html:/usr/share/nginx/html:ro nginx:latest

Vamos destrinchar da parte que interessa (-v) para frente:

(-v): Significa volume. É onde informamos o mapeamento entre o host e o container.
(C:\Users\deivi\EstudoImagens\html:): É o caminho do host. Nesse diretório você tem seus arquivos HTML.
(/usr/share/nginx/html): É o caminho dentro do container. O Nginx, por padrão, serve páginas desse diretório.
Ou seja, o que está na pasta do host será espelhado aqui dentro do container.
(:ro): É a permissão de acesso do container ao volume.
- ro → read-only (somente leitura). O container pode ler, mas não alterar arquivos.
- rw → read-write (leitura e escrita, é o padrão). O container pode modificar arquivos. _________________________________________________________________________

Benefícios de usar volumes:

1 Persistência de dados: mesmo que o container seja parado ou recriado, os dados continuam salvos no host.
2 Facilidade de desenvolvimento: você pode alterar arquivos no host e ver as mudanças refletirem no container em tempo real.
3 Compartilhamento: um volume pode ser usado por múltiplos containers ao mesmo tempo, permitindo colaboração entre serviços.