Compilado de Kubernetes na prática: do básico ao avançado

O Kubernetes é uma das principais plataformas utilizadas para gerenciamento de aplicações conteinerizadas. Para entender seu funcionamento, porém, é importante começar pelo conceito de container, compreender o papel do Docker e, posteriormente, avançar para os componentes que formam um cluster Kubernetes.

O material “Kubernetes na prática: do básico ao avançado” apresenta essa evolução em uma sequência que começa com Docker e containers e chega a temas como rede, armazenamento, Container Registry, GitLab CI/CD, Vault e Argo CD.

O que você vai aprender

O conteúdo está organizado em dez etapas:

1. Containers e Docker
2. Fundamentos do Kubernetes
3. Recursos básicos
4. Recursos básicos — continuação
5. Rede
6. Armazenamento
7. Container Registry
8. GitLab CI/CD e GitLab Runner
9. HashiCorp Vault
10. Argo CD e GitOps

1. Containers: a base da infraestrutura moderna

Antes de falar em Kubernetes, é necessário entender containers.

Um container é um ambiente isolado utilizado para empacotar aplicações, facilitando a segregação e a portabilidade entre diferentes ambientes.

O container executa processos a partir de uma imagem, que fornece os arquivos necessários para a aplicação. Diferentemente de uma máquina virtual tradicional, os containers compartilham o mesmo kernel do sistema operacional e isolam os processos da aplicação.

Container x máquina virtual

MÁQUINA VIRTUAL

┌──────────────────────┐
│      Aplicação       │
├──────────────────────┤
│ Sistema operacional  │
├──────────────────────┤
│      Hypervisor      │
├──────────────────────┤
│    Infraestrutura    │
└──────────────────────┘


CONTAINER

┌──────────────────────┐
│      Aplicação       │
├──────────────────────┤
│      Container       │
├──────────────────────┤
│        Docker        │
├──────────────────────┤
│ Sistema operacional  │
├──────────────────────┤
│    Infraestrutura    │
└──────────────────────┘

2. O que é Docker?

O Docker é uma plataforma aberta para desenvolver, distribuir e executar aplicações.

A proposta é separar a aplicação da infraestrutura, permitindo trabalhar com desenvolvimento, testes e implantação de maneira mais padronizada.

Arquitetura simplificada

              Docker Client
                   │
       ┌───────────┼───────────┐
       │           │           │
   docker run  docker build  docker pull
       │           │           │
       └───────────▼───────────┘
             Docker Host
                  │
            Docker Daemon
             /         \
         Images      Containers
             │
             ▼
          Registry

3. Container Registry

Uma imagem de container precisa estar disponível para ser utilizada por diferentes ambientes. É aí que entra o Container Registry.

O Registry armazena, organiza e distribui imagens de containers. Ele pode ser entendido como um tipo de “repositório Git para containers”.

Registries públicos

• Docker Hub
• GitHub Container Registry
• Quay.io
• Google Artifact Registry

Registries privados

• Harbor
• GitLab Registry
• Nexus
• Amazon ECR
• Azure Container Registry

Imagem, tag, repository e layers

Imagem: pacote contendo a aplicação e suas dependências.

Tag: identifica uma versão da imagem.

nginx:1.25

Repository: agrupa imagens relacionadas.

library/nginx

Layers: as imagens são formadas por camadas que podem ser reutilizadas.

4. Docker Compose

Nem sempre uma aplicação é composta por apenas um container. Uma aplicação pode possuir, por exemplo, um servidor web, banco de dados e cache.

Aplicação Web
      │
      ├── Web
      ├── Banco de dados
      └── Cache

O Docker Compose permite definir aplicações compostas por múltiplos containers utilizando um arquivo YAML.

5. Por que precisamos do Kubernetes?

Containers resolvem diversos problemas relacionados ao empacotamento e à portabilidade, mas administrar muitos containers manualmente pode se tornar complexo.

Entre os desafios estão:

• Múltiplas dependências;
• Dificuldade de configuração e alocação;
• Balanceamento de carga;
• Publicação de aplicações;
• Monitoramento;
• Self-healing;
• Escalabilidade;
• Comunicação segura entre containers.

É nesse cenário que entra a orquestração de containers.

6. O que é Kubernetes?

O Kubernetes é uma plataforma open source, portável e extensível para gerenciamento de serviços e aplicações conteinerizadas, facilitando configuração declarativa e automação.

                Kubernetes
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
      Node          Node         Node
        │            │            │
       Pods         Pods         Pods
        │
   Containers

Em vez de administrar cada container individualmente, o Kubernetes trabalha com objetos declarativos que descrevem o estado desejado da aplicação.

7. Histórico do Kubernetes

O Kubernetes foi originalmente desenvolvido por engenheiros do Google e lançado em 2014. Em 2015, o projeto foi tornado open source e doado à recém-criada Cloud Native Computing Foundation (CNCF).

O nome Kubernetes vem do grego e está relacionado às ideias de “capitão” ou “piloto”. O projeto é implementado em Go.

8. Arquitetura de um cluster Kubernetes

                 CLUSTER KUBERNETES
                         │
          ┌──────────────┴──────────────┐
          │                             │
          ▼                             ▼
     CONTROL PLANE                    NODES
          │                             │
          │                       ┌─────┼─────┐
          │                       ▼     ▼     ▼
          │                      Pod   Pod   Pod

9. Componentes do Control Plane

kube-apiserver

É o componente que expõe a API do Kubernetes e funciona como front-end do Control Plane.

etcd

É o banco de dados chave-valor utilizado pelo Kubernetes para armazenar os dados do cluster.

kube-scheduler

Monitora Pods recém-criados e seleciona o nó onde eles deverão executar.

kube-controller-manager

Executa os processos responsáveis pelos controllers do Kubernetes.

cloud-controller-manager

É utilizado para lógica específica de provedores de nuvem e não existe em instalações on-premises.

10. Componentes dos Nodes

kubelet

Agente executado em cada nó. Ele garante que os containers estejam rodando nos Pods.

kube-proxy

Implementa parte do funcionamento dos Services e atua na rede do nó.

Container Runtime

É responsável pela execução e pelo ciclo de vida dos containers.

O material cita:

• containerd;
• CRI-O;
• outras implementações compatíveis com a Container Runtime Interface (CRI).

11. Add-ons do Kubernetes

Os add-ons utilizam recursos Kubernetes, como Deployments e DaemonSets, para fornecer funcionalidades adicionais ao cluster.

• DNS;
• Web UI;
• Monitoramento de recursos dos containers;
• Logging em nível de cluster;
• Plugins de rede.

12. Ferramentas fundamentais

kubectl

Ferramenta de linha de comando para interagir com clusters Kubernetes.

kubeadm

Utilizado para instalação e configuração de clusters Kubernetes.

Helm

Ferramenta de empacotamento de aplicações Kubernetes.

13. Workloads e Pods

Uma workload representa uma aplicação executando no Kubernetes.

Independentemente de a aplicação ser simples ou composta por vários componentes, seus containers são executados dentro de Pods.

O Pod é a menor unidade implantável do Kubernetes.

Pod
┌──────────────────────────┐
│ Container                │
│                          │
├──────────────────────────┤
│ Container                │
└──────────────────────────┘
       │
       ├── Rede compartilhada
       └── Armazenamento

14. Criando um Pod

Forma imperativa

kubectl run servidor-web --image nginx:1.14.2 --port 80

Forma declarativa

apiVersion: v1
kind: Pod
metadata:
  name: servidor-web

spec:
  containers:
    - name: nginx
      image: nginx:1.14.2
      ports:
        - containerPort: 80

Depois:

kubectl apply -f pods/simple-pod.yaml

15. Investigando um Pod

Uma ferramenta importante para troubleshooting é:

kubectl describe pod servidor-web

O comando apresenta informações como:

• Namespace;
• Node;
• Status;
• IP;
• Container;
• Imagem;
• Estado;
• Quantidade de reinicializações;
• Volumes montados.

Também é possível observar os eventos do Pod:

Scheduled
Pulling
Pulled
Created
Started

16. ReplicaSet

O ReplicaSet garante que uma quantidade desejada de Pods esteja em execução.

ReplicaSet
    │
    ├── Pod 1
    ├── Pod 2
    └── Pod 3

Se um Pod falhar ou for removido, o ReplicaSet cria outro.

17. Deployment

O Deployment gerencia ReplicaSets e permite controlar a execução dos Pods.

Entre suas funções estão:

• Atualizações controladas;
• Rollback;
• Escalabilidade horizontal;
• Rolling Update.

Deployment
     │
     ▼
ReplicaSet
     │
 ┌───┼───┐
 ▼   ▼   ▼
Pod Pod Pod

18. StatefulSet

O StatefulSet é destinado a workloads que precisam de identidade e armazenamento persistentes.

É adequado para aplicações stateful, como bancos de dados e sistemas distribuídos.

19. DaemonSet

O DaemonSet garante que determinado Pod seja executado em todos — ou em determinados — nós do cluster.

É útil para workloads que precisam estar presentes nos nós, como:

• Monitoramento;
• Logging;
• Componentes de rede.

20. Services

Os Pods possuem ciclo de vida próprio e podem ser recriados. Por isso, o acesso direto ao IP de um Pod não é uma boa abstração para comunicação persistente.

O Service fornece um ponto estável de acesso.

Os tipos apresentados no material são:

• ClusterIP;
• NodePort;
• LoadBalancer;
• ExternalName.

             Service
                │
       ┌────────┼────────┐
       ▼        ▼        ▼
     Pod 1    Pod 2    Pod 3

21. Namespaces

Namespaces permitem organizar o cluster em ambientes separados.

Podem ser utilizados para separar equipes, projetos ou ambientes.

Cluster
│
├── namespace: dev
│
├── namespace: staging
│
└── namespace: prod

22. ConfigMap

O ConfigMap armazena configurações em pares chave-valor.

Sua finalidade é separar configuração do código da aplicação.

Os dados podem ser disponibilizados ao Pod como:

• Variáveis de ambiente;
• Arquivos;
• Argumentos de linha de comando.

23. Secret

O Secret é destinado a informações sensíveis, como:

• Senhas;
• Tokens;
• Chaves de API.

Atenção: Base64 não deve ser confundido com criptografia. Os Secrets precisam continuar sendo protegidos por boas práticas de segurança.

24. Armazenamento persistente

Containers são efêmeros, mas muitos sistemas precisam preservar dados. É o caso de bancos de dados, caches, aplicações stateful e arquivos persistentes.

O Kubernetes utiliza recursos específicos para abstrair o armazenamento.

25. PersistentVolume — PV

O PersistentVolume (PV) representa uma unidade de armazenamento disponibilizada ao cluster.

Pode utilizar tecnologias como:

• NFS;
• Ceph;
• AWS EBS;
• Discos locais.

26. PersistentVolumeClaim — PVC

O PVC é a solicitação de armazenamento feita pelo workload.

Pod
 │
 ▼
PVC
 │
 ▼
PV
 │
 ▼
Storage

O PVC abstrai os detalhes da infraestrutura, permitindo que a aplicação solicite armazenamento sem precisar conhecer diretamente sua implementação.

27. StorageClass

A StorageClass define diferentes classes de armazenamento e permite provisionamento dinâmico.

StorageClass
├── SSD
├── HDD
└── NFS

28. Modos de acesso

29. Rede no Kubernetes

A Aula 5 apresenta o kubectl port-forward, ferramenta útil para diagnóstico e testes.

Exemplo:

kubectl port-forward pod/meu-pod 8080:80

Ou utilizando um Service:

kubectl port-forward svc/meu-servico 8080:80

A aplicação poderá ser acessada em:

http://localhost:8080

30. Quando utilizar port-forward?

• Desenvolvimento;
• Testes;
• Troubleshooting;
• Acesso temporário.

O material ressalta que o port-forward é temporário, manual, limitado a um cliente por vez e não é recomendado para produção.

31. Service LoadBalancer

O tipo LoadBalancer disponibiliza uma aplicação externamente, normalmente por meio de um IP público fornecido pelo provedor de nuvem.

Internet
   │
   ▼
LoadBalancer
   │
   ▼
Service
   │
   ▼
ClusterIP
   │
   ▼
Pods

Em ambientes bare-metal, o material cita soluções como MetalLB.

32. Ingress

Quando existem várias aplicações HTTP/HTTPS, o Ingress permite centralizar o roteamento.

Ele trabalha com regras baseadas em hostname e path.

                   Internet
                       │
                       ▼
                    Ingress
                  /          \
                 /            \
                ▼              ▼
          app.exemplo.com   api.exemplo.com
                │              │
                ▼              ▼
             Service A      Service B
                │              │
               Pods           Pods

33. Ingress Controller

O recurso Ingress precisa de um componente que implemente seu comportamento.

O material cita:

• NGINX;
• Traefik;
• HAProxy.

Ingress
   │
   ▼
Ingress Controller
   │
   ├── Service A
   ├── Service B
   └── Service C

34. HTTPS com Cert-Manager

O Cert-Manager automatiza a emissão, renovação e gerenciamento de certificados TLS.

Ele pode integrar-se a autoridades como Let’s Encrypt e HashiCorp Vault.

Ingress
   │
   ▼
Cert-Manager
   │
   ▼
Let's Encrypt
   │
   ▼
Certificado TLS
   │
   ▼
Secret

35. Helm: gerenciamento de aplicações Kubernetes

O Helm é apresentado como o gerenciador de pacotes do Kubernetes.

Ele trabalha com Charts, que são pacotes contendo recursos Kubernetes reutilizáveis.

Exemplos de Helm

helm repo add bitnami https://charts.bitnami.com/bitnami

helm install meu-nginx bitnami/nginx

helm search repo nginx

helm upgrade meu-nginx bitnami/nginx

helm uninstall meu-nginx

36. Estrutura de um Helm Chart

meu-chart/
├── Chart.yaml
├── values.yaml
└── templates/
    └── deployment.yaml

O values.yaml concentra os valores configuráveis, enquanto templates/ contém os manifestos com suporte a variáveis.

37. Quando utilizar Helm?

• Deploys repetíveis;
• Aplicações versionadas;
• Aplicações com múltiplos componentes;
• Ambientes com CI/CD;
• Padronização de deployments.

38. Container Registry no fluxo Kubernetes

Código
  │
  ▼
Docker Build
  │
  ▼
Imagem
  │
  │ docker push
  ▼
Registry
  │
  │ docker pull
  ▼
Kubernetes

Exemplo:

docker login

docker tag meuapp usuario/meuapp:v1

docker push usuario/meuapp:v1

39. Segurança das imagens

O material recomenda:

• Autenticação e autorização;
• Assinatura e verificação das imagens;
• Evitar latest em produção;
• Análise de vulnerabilidades.

Entre as ferramentas e tecnologias citadas estão:

• Notary;
• Sigstore;
• Cosign;
• Trivy;
• Clair.

40. CI/CD com GitLab

O CI/CD permite automatizar build, testes e entrega.

Continuous Integration corresponde à integração frequente das alterações de código acompanhada por testes automatizados.

Continuous Delivery/Deployment corresponde à liberação contínua ou automatizada das alterações.

41. .gitlab-ci.yml

A configuração da pipeline fica no arquivo:

.gitlab-ci.yml

Exemplo:

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - make build

test-job:
  stage: test
  script:
    - make test

deploy-job:
  stage: deploy
  script:
    - ./deploy.sh

42. GitLab Runner

O GitLab Runner é o agente responsável por executar os jobs da pipeline.

O material apresenta:

• Shared Runners;
• Self-hosted Runners;
• Docker;
• Shell;
• Kubernetes.

43. Pipeline: do Git Push ao Deploy

Desenvolvedor
      │
      │ git push
      ▼
    GitLab
      │
      ▼
  Pipeline
      │
      ├── Build
      │
      ├── Test
      │
      └── Deploy

Os stages são executados em ordem. Os testes ocorrem antes do deploy e falhas interrompem a pipeline.

44. Variáveis e ambientes

Development
     │
     ▼
Staging
     │
     ▼
Production

As pipelines podem utilizar variáveis secretas e configurações específicas para cada ambiente.

45. HashiCorp Vault

O HashiCorp Vault é utilizado para gerenciamento de segredos e controle de acesso a informações sensíveis.

Entre suas funcionalidades estão:

• Armazenamento de segredos;
• Controle de acesso por políticas;
• Criptografia como serviço;
• Credenciais dinâmicas;
• Auditoria e logs.

46. Arquitetura do Vault

                 Vault
                   │
      ┌────────────┼────────────┐
      ▼            ▼            ▼
 Storage       Authentication  Secrets
 Backend                       Engines
                                  │
                                  ▼
                               Policies

Storage Backend

Local onde os dados são armazenados.

Authentication

Métodos utilizados para autenticação, como Token, AppRole, LDAP e Kubernetes.

Secrets Engines

Responsáveis por armazenar ou gerar segredos, incluindo KV, PKI, AWS e DB.

Policies

Definem as permissões de acesso por ACLs.

47. Vault começa selado

Quando inicializado, o Vault começa sealed, mantendo seus dados criptografados e inacessíveis.

O desbloqueio utiliza Unseal Keys, baseado no mecanismo de Shamir’s Secret Sharing.

48. Armazenando segredos no Vault

Exemplo apresentado no material:

vault kv put secret/meusdados senha=123456

Consulta:

vault kv get secret/meusdados

Importante: o valor apresentado acima é apenas um exemplo didático e não deve ser utilizado como senha real.

49. Credenciais dinâmicas

O Vault pode gerar credenciais temporárias para determinados serviços.

Vault
 │
 │ credencial administrativa
 ▼
Banco de dados
 │
 ▼
Usuário temporário
 │
 └── TTL

50. Vault integrado ao Kubernetes

Pod
 │
 │ JWT
 ▼
Vault
 │
 │ valida identidade
 ▼
Policies
 │
 ▼
Segredos autorizados

A integração pode utilizar Sidecar, CSI Driver ou Operator.

51. GitOps

GitOps é a prática de utilizar o Git como fonte única de verdade para infraestrutura e aplicações.

As alterações são realizadas por meio de Pull Requests, proporcionando um processo auditável e reversível.

52. Argo CD

O Argo CD é uma ferramenta declarativa de Continuous Delivery para Kubernetes.

Git
 │
 │ Estado desejado
 ▼
Argo CD
 │
 │ Sincronização
 ▼
Kubernetes
 │
 │ Estado atual
 ▼
Aplicação

53. Como o Argo CD funciona?

O Argo CD monitora um repositório Git contendo manifestos Kubernetes.

Esses manifestos podem ser:

• YAML;
• Helm Charts;
• Kustomize.

O Argo CD compara o estado desejado no Git com o estado atual do cluster. A sincronização pode ser automática ou manual.

54. Componentes do Argo CD

• API Server: disponibiliza a interface Web e CLI.
• Repository Server: responsável por acessar o Git.
• Application Controller: responsável por sincronizar o estado.
• Dex/Auth: componente opcional para autenticação.

55. Application no Argo CD

Uma Application representa uma aplicação Kubernetes administrada pelo Argo CD.

Ela define:

• Repositório Git;
• Caminho;
• Namespace;
• Estratégia de sincronização.

apiVersion: argoproj.io/v1alpha1
kind: Application

metadata:
  name: minha-app

spec:
  source:
    repoURL: https://github.com/usuario/repo
    path: k8s/app

  destination:
    server: https://kubernetes.default.svc
    namespace: default

  syncPolicy:
    automated:
      prune: true
      selfHeal: true

56. Argo CD pela Web e CLI

O Argo CD possui interface Web para visualizar aplicações, consultar histórico e comparar estados.

Também possui CLI:

argocd login

argocd app list

argocd app sync minha-app

57. Segurança e RBAC

O Argo CD possui mecanismos de controle de acesso, incluindo:

• Usuários;
• Times;
• Permissões por aplicação;
• SSO;
• LDAP;
• OIDC;
• GitHub;
• Logs de auditoria.

58. Como todas as tecnologias se conectam?

                       DESENVOLVEDOR
                            │
                            │ git push
                            ▼
                         GITLAB
                            │
                            ▼
                      GitLab CI/CD
                            │
                  ┌─────────┴─────────┐
                  ▼                   ▼
                Build               Test
                  │
                  ▼
             Docker Image
                  │
                  │ docker push
                  ▼
          Container Registry
             / Harbor
                  │
                  │ docker pull
                  ▼
            KUBERNETES
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
     Pod        Pod        Pod
       │
       ▼
    Service
       │
       ▼
    Ingress
       │
       ▼
    Internet


        ┌─────────────────┐
        │      Vault      │
        │    Secrets      │
        └────────┬────────┘
                 │
                 ▼
              Pods


             ┌───────┐
             │  Git  │
             └───┬───┘
                 │
                 ▼
             Argo CD
                 │
                 ▼
             Kubernetes

59. O ciclo completo de uma aplicação

1. Código: o desenvolvedor cria ou altera a aplicação.
2. Git: o código é versionado.
3. CI/CD: o GitLab executa build e testes.
4. Container: uma imagem é construída.
5. Registry: a imagem é armazenada.
6. GitOps: os manifestos são mantidos no Git.
7. Argo CD: o estado definido no Git é sincronizado com o cluster.
8. Kubernetes: o cluster executa os Pods.
9. Service: a aplicação recebe conectividade interna.
10. Ingress: o tráfego HTTP/HTTPS é encaminhado para os Services.
11. Cert-Manager: certificados TLS podem ser automatizados.
12. Storage: dados persistentes são disponibilizados por PV/PVC/StorageClass.
13. Vault: credenciais e outros segredos podem ser gerenciados externamente.

60. Mapa mental do Kubernetes

                         KUBERNETES
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
       ▼                      ▼                      ▼
    COMPUTE                 NETWORK                STORAGE
       │                      │                      │
       ├── Pod                ├── Service           ├── PV
       ├── Deployment         ├── LoadBalancer      ├── PVC
       ├── ReplicaSet         ├── Ingress           └── StorageClass
       ├── StatefulSet        └── port-forward
       └── DaemonSet
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
       ▼                      ▼                      ▼
 CONFIGURAÇÃO             SEGURANÇA               AUTOMAÇÃO
       │                      │                      │
       ├── ConfigMap          ├── Secret             ├── GitLab CI/CD
       └── Namespace          ├── Vault              ├── Helm
                              └── Cert-Manager       └── Argo CD

61. O que estudar primeiro?

Para quem está começando, a sequência do material oferece uma trilha progressiva:

Docker
  ↓
Containers
  ↓
Kubernetes
  ↓
Pods
  ↓
Deployments
  ↓
Services
  ↓
ConfigMaps / Secrets
  ↓
PV / PVC / StorageClass
  ↓
Networking
  ↓
Ingress
  ↓
Helm
  ↓
Registry
  ↓
GitLab CI/CD
  ↓
Vault
  ↓
GitOps
  ↓
Argo CD

62. Checklist prático

• ☐ Entender containers
• ☐ Criar e executar containers Docker
• ☐ Entender imagens
• ☐ Trabalhar com Docker Compose
• ☐ Publicar imagens em Registry
• ☐ Entender arquitetura Kubernetes
• ☐ Instalar um cluster
• ☐ Utilizar kubectl
• ☐ Criar Pods
• ☐ Trabalhar com ReplicaSets
• ☐ Criar Deployments
• ☐ Conhecer StatefulSets
• ☐ Conhecer DaemonSets
• ☐ Criar Services
• ☐ Organizar recursos com Namespaces
• ☐ Utilizar ConfigMaps
• ☐ Utilizar Secrets
• ☐ Configurar PV e PVC
• ☐ Trabalhar com StorageClass
• ☐ Utilizar kubectl port-forward
• ☐ Conhecer LoadBalancer
• ☐ Configurar Ingress
• ☐ Conhecer Ingress Controllers
• ☐ Automatizar certificados com Cert-Manager
• ☐ Utilizar Helm
• ☐ Configurar Container Registry
• ☐ Criar pipelines GitLab CI/CD
• ☐ Configurar GitLab Runner
• ☐ Conhecer Vault
• ☐ Integrar Vault ao Kubernetes
• ☐ Entender GitOps
• ☐ Configurar Argo CD

63. Projeto final: colocando tudo em prática

A ementa do curso prevê como projeto final o deploy de uma aplicação utilizando os conceitos apresentados ao longo do curso.

                    ┌──────────────┐
                    │ Desenvolvedor│
                    └──────┬───────┘
                           │
                           ▼
                         Git
                           │
                           ▼
                    GitLab CI/CD
                           │
                           ▼
                    Docker Build
                           │
                           ▼
                       Registry
                           │
                           ▼
                      Kubernetes
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
          Deployment     Service      Config
              │            │
              ▼            ▼
             Pods       Ingress
              │            │
              │            ▼
              │         HTTPS
              │
              ▼
            Vault
              │
              ▼
           Secrets

Git ───────────────► Argo CD
                         │
                         ▼
                    Kubernetes

Conclusão

O material apresenta uma jornada que começa em containers e Docker e evolui progressivamente para um ambiente Kubernetes com recursos de computação, rede, armazenamento, segurança e automação.

O aprendizado pode ser dividido em cinco grandes blocos:

Containers

Docker, imagens, Registry e Docker Compose.

Kubernetes

Cluster, Control Plane, Nodes, Pods, Deployments, StatefulSets, DaemonSets e Services.

Infraestrutura

Namespaces, ConfigMaps, Secrets, PV, PVC, StorageClass e networking.

Segurança e operação

Ingress, Cert-Manager, HTTPS, Registry e Vault.

DevOps e GitOps

GitLab CI/CD, GitLab Runner, Helm e Argo CD.

De forma resumida:

Código → CI/CD → Container → Registry → Kubernetes
       → Networking → Storage → Secrets
       → GitOps → Argo CD

O principal conceito é que Kubernetes não deve ser entendido apenas como uma ferramenta para executar containers, mas como parte de um ecossistema de automação, infraestrutura, segurança e entrega de aplicações.

ReplicaSet: mantém uma quantidade definida de Pods funcionando.
Deployment: gerencia os Pods e permite atualizar a aplicação.
StatefulSet: gerencia Pods que precisam de identidade estável.
DaemonSet: garante um Pod em cada Node necessário.
Service: permite acessar e encontrar os Pods.
Namespace: organiza e separa recursos dentro do cluster.
ConfigMap: armazena configurações da aplicação.
Secret: armazena informações sensíveis, como senhas e tokens.

Para decorar:

Fonte: Material “Kubernetes na prática: do básico ao avançado”, Ministrado por Mauricio Accetturi para funcionários Unicamp.