1 
2Se você trabalha no mundo do desenvolvimento de software, certamente já ouviu falar de Kubernetes. Mas o que exatamente é, e por que se tornou o padrão de fato para gerenciar aplicações em contêineres? Este guia levará você dos conceitos básicos aos fundamentais, com exemplos práticos e diagramas para ajudá-lo a entender.
3 
4## Antes do Kubernetes: Um Pouco de História
5 
6Para entender por que o Kubernetes é tão revolucionário, vamos dar um passo atrás.
7 
81.  **Implantação Tradicional**: Inicialmente, as aplicações eram executadas em servidores físicos. Essa abordagem era cara, difícil de escalar e propensa a conflitos de recursos.
92.  **Implantação Virtualizada**: Então surgiram as Máquinas Virtuais (VMs). As VMs permitiam executar múltiplas aplicações isoladas no mesmo hardware, melhorando a utilização de recursos e a segurança. No entanto, cada VM executa um sistema operacional inteiro, consumindo muitos recursos.
103.  **Implantação em Contêineres**: Os contêineres (como Docker) são a próxima evolução. Eles compartilham o mesmo sistema operacional do host, mas executam processos isolados. São leves, rápidos para iniciar e portáteis.
11 
12Os contêineres resolveram o problema de portabilidade, mas criaram outro: como gerenciar centenas (ou milhares) de contêineres em um ambiente de produção? Como garantir que estejam sempre em execução, possam se comunicar entre si e escalar com base na carga?
13 
14É aqui que o **Kubernetes** entra.
15 
16## O que é Kubernetes?
17 
18Kubernetes (frequentemente abreviado como **K8s**) é uma plataforma open-source para orquestração de contêineres. Em termos simples, ele automatiza a implantação, o escalonamento e o gerenciamento de aplicações em contêineres. Criado pelo Google e agora mantido pela Cloud Native Computing Foundation (CNCF), o Kubernetes se tornou a ferramenta essencial para quem trabalha com microsserviços em escala.
19 
20## A Arquitetura de um Cluster Kubernetes
21 
22Um ambiente Kubernetes é chamado de **cluster**. Um cluster é composto por um conjunto de máquinas, chamadas **nodes**, que executam nossas aplicações. A arquitetura é dividida em duas partes principais: o Control Plane e os Worker Nodes.
23 
24```mermaid
25graph TD
26    subgraph "Control Plane (Master)"
27        A["API Server"]
28        B["etcd"]
29        C["Scheduler"]
30        D["Controller Manager"]
31    end
32 
33    subgraph "Worker Node 1"
34        E["Kubelet"] --- F["Container Runtime"]
35        G["Kube-proxy"]
36        F --- H["Pod"]
37        F --- I["Pod"]
38    end
39 
40    subgraph "Worker Node 2"
41        J["Kubelet"] --- K["Container Runtime"]
42        L["Kube-proxy"]
43        K --- M["Pod"]
44    end
45 
46    A -- "Communicates with" --> E
47    A -- "Communicates with" --> J
48    User -- "kubectl" --> A
49    C -- "Assigns Pods to Nodes" --> E
50    D -- "Maintains state" --> A
51    A -- "Saves/Reads state" --> B
52```
53 
54### Control Plane
55 
56O Control Plane é o "cérebro" do cluster. Ele toma decisões globais (como agendamento) e detecta e responde a eventos do cluster. Seus principais componentes são:
57 
58-   **API Server (`kube-apiserver`)**: É o gateway do cluster. Ele expõe a API do Kubernetes, que é usada por usuários (via `kubectl`), componentes do cluster e ferramentas externas para se comunicar.
59-   **etcd**: Um banco de dados chave-valor consistente e altamente disponível. Ele armazena todos os dados do cluster, representando o estado desejado e atual do sistema.
60-   **Scheduler (`kube-scheduler`)**: Atribui Pods recém-criados a um Worker Node disponível, levando em conta requisitos de recursos, políticas e outras restrições.
61-   **Controller Manager (`kube-controller-manager`)**: Executa controladores, que são loops de controle que observam o estado do cluster e trabalham para trazê-lo ao estado desejado. Por exemplo, o `Node Controller` gerencia os nodes, enquanto o `Replication Controller` garante que o número correto de Pods esteja em execução.
62 
63### Worker Node
64 
65Os Worker Nodes são as máquinas (físicas ou virtuais) onde as aplicações são realmente executadas. Cada node é gerenciado pelo Control Plane e contém os seguintes componentes:
66 
67-   **Kubelet**: Um agente que roda em cada node. Ele garante que os contêineres descritos nos Pods estejam em execução e saudáveis.
68-   **Kube-proxy**: Um proxy de rede que gerencia as regras de rede nos nodes. Ele permite a comunicação de rede com os Pods a partir de sessões de rede internas ou externas ao cluster.
69-   **Container Runtime**: O software responsável por executar os contêineres. O Docker é o mais famoso, mas o Kubernetes também suporta outros runtimes como `containerd` e `CRI-O`.
70 
71## Objetos Fundamentais do Kubernetes
72 
73No Kubernetes, tudo é representado por **objetos**. Esses objetos são "registros de intenção": uma vez que você cria um objeto, o Kubernetes trabalha constantemente para garantir que ele exista e corresponda ao estado desejado.
74 
75Aqui estão os mais importantes:
76 
77### Pod
78 
79O **Pod** é a menor unidade de execução no Kubernetes. Ele representa um ou mais contêineres que são executados juntos no mesmo node, compartilhando recursos como rede e armazenamento.
80 
81Geralmente, você executa apenas um contêiner por Pod, mas em cenários avançados (como "sidecar containers" para logging ou monitoramento), você pode ter mais.
82 
83Você quase nunca cria Pods diretamente. Você usa abstrações de nível superior como Deployments.
84 
85### Deployment
86 
87Um **Deployment** é o objeto que você usará com mais frequência. Ele descreve o estado desejado para um grupo de Pods idênticos. O controlador de Deployment é responsável por:
88 
89-   Criar e gerenciar um **ReplicaSet** (outro objeto que garante que um número específico de réplicas de um Pod estejam sempre em execução).
90-   **Escalar** o número de Pods para cima ou para baixo.
91-   Gerenciar **atualizações** da aplicação de maneira controlada (por exemplo, *Rolling Update*), sem tempo de inatividade.
92 
93Aqui está um exemplo de arquivo YAML para um Deployment que executa 3 réplicas de um servidor NGINX:
94 
95```yaml
96# nginx-deployment.yaml
97apiVersion: apps/v1
98kind: Deployment
99metadata:
100  name: nginx-deployment
101spec:
102  replicas: 3
103  selector:
104    matchLabels:
105      app: nginx
106  template:
107    metadata:
108      labels:
109        app: nginx
110    spec:
111      containers:
112      - name: nginx
113        image: nginx:1.14.2
114        ports:
115        - containerPort: 80
116```
117 
118### Service
119 
120Os Pods no Kubernetes são efêmeros: podem ser criados e destruídos a qualquer momento. Cada Pod tem seu próprio endereço IP, mas esse IP não é estável. Então, como expor nossa aplicação de forma confiável?
121 
122Com um **Service**. Um Service é uma abstração que define um conjunto lógico de Pods e uma política para acessá-los. Ele fornece um **ponto de acesso estável** (um endereço IP virtual e um nome DNS) para um grupo de Pods.
123 
124```mermaid
125graph TD
126    subgraph "Service (nginx-service)"
127        A["ClusterIP: 10.96.0.10"]
128    end
129 
130    subgraph "Pods"
131        B("Pod 1 - IP: 192.168.1.2")
132        C("Pod 2 - IP: 192.168.1.3")
133        D("Pod 3 - IP: 192.168.1.4")
134    end
135 
136    A -- "Selector: app=nginx" --> B
137    A -- "Selector: app=nginx" --> C
138    A -- "Selector: app=nginx" --> D
139 
140    Client -- "Request to nginx-service" --> A
141```
142 
143O Service usa um `selector` baseado em `labels` para encontrar os Pods para os quais deve encaminhar o tráfego.
144 
145Veja como criar um Service para nosso Deployment NGINX:
146 
147```yaml
148# nginx-service.yaml
149apiVersion: v1
150kind: Service
151metadata:
152  name: nginx-service
153spec:
154  selector:
155    app: nginx
156  ports:
157    - protocol: TCP
158      port: 80
159      targetPort: 80
160  type: ClusterIP # Default - exposes the service only within the cluster
161```
162 
163Existem diferentes tipos de Services:
164- `ClusterIP`: Expõe o service em um IP interno do cluster (padrão).
165- `NodePort`: Expõe o service em uma porta estática em cada Worker Node.
166- `LoadBalancer`: Cria um load balancer externo no provedor de nuvem (ex.: AWS, GCP) e atribui um IP público ao service.
167 
168### Ingress
169 
170Um Service `LoadBalancer` é ótimo, mas criar um para cada service pode ser caro. Para expor múltiplos services HTTP/HTTPS ao mundo externo, você usa um **Ingress**.
171 
172Um Ingress atua como um "roteador inteligente" para tráfego externo. Ele permite definir regras de roteamento baseadas no host (ex.: `api.mysite.com`) ou caminho (ex.: `mysite.com/api`).
173 
174```mermaid
175graph LR
176    User -- "mysite.com/api" --> Ingress
177    User -- "mysite.com/ui" --> Ingress
178 
179    subgraph "Cluster"
180        Ingress -- "/api" --> ServiceA("api-service")
181        Ingress -- "/ui" --> ServiceB("ui-service")
182 
183        ServiceA --> PodA1("API Pod 1")
184        ServiceA --> PodA2("API Pod 2")
185 
186        ServiceB --> PodB1("UI Pod 1")
187        ServiceB --> PodB2("UI Pod 2")
188    end
189```
190 
191Aqui está um exemplo de Ingress:
192```yaml
193# example-ingress.yaml
194apiVersion: networking.k8s.io/v1
195kind: Ingress
196metadata:
197  name: example-ingress
198spec:
199  rules:
200  - host: mysite.com
201    http:
202      paths:
203      - path: /api
204        pathType: Prefix
205        backend:
206          service:
207            name: api-service
208            port:
209              number: 8080
210      - path: /ui
211        pathType: Prefix
212        backend:
213          service:
214            name: ui-service
215            port:
216              number: 3000
217```
218 
219### Outros Objetos Úteis
220 
221-   **Namespace**: Permite criar "clusters virtuais" dentro de um cluster físico. Útil para isolar ambientes (ex.: `development`, `staging`, `production`) ou equipes.
222-   **ConfigMap e Secret**: Para gerenciar dados de configuração e segredos (como senhas ou chaves de API) desacoplados da imagem do contêiner.
223-   **StatefulSet**: Similar a um Deployment, mas específico para aplicações com estado (como bancos de dados) que requerem identidades de rede estáveis e armazenamento persistente.
224-   **PersistentVolume (PV) e PersistentVolumeClaim (PVC)**: Para gerenciar armazenamento persistente no cluster.
225 
226## Conclusão
227 
228O Kubernetes é uma ferramenta incrivelmente poderosa, mas sua curva de aprendizado pode ser íngreme. Este guia apenas arranhou a superfície, mas esperamos que tenha lhe dado uma compreensão sólida dos conceitos básicos.
229 
230**O que fazer agora?**
231- **Experimente localmente**: Instale o [Minikube](https://minikube.sigs.k8s.io/docs/start/) ou o [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) para criar um cluster Kubernetes no seu computador.
232- **Use o `kubectl`**: Familiarize-se com o comando `kubectl`, sua principal ferramenta para interagir com o cluster. Tente criar o Deployment e o Service NGINX deste artigo.
233- **Explore os tutoriais oficiais**: A [documentação do Kubernetes](https://kubernetes.io/docs/tutorials/) é um recurso fantástico repleto de exemplos.
234 
235A orquestração de contêineres é uma habilidade fundamental no mundo cloud-native, e dominar o Kubernetes abrirá um mundo de possibilidades. Divirta-se!
236