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~