Skip to main content

Conceitos | Kubernetes

  • Conceitos | Kubernetes

Recursos​

alt text

Breve Explicação

Principais Componentes do Kubernetes​

  1. Pods São as menores unidades executáveis do Kubernetes, contendo um ou mais contêineres que compartilham rede e armazenamento.

  2. Deployments Controlam a criação, atualização e gerenciamento do ciclo de vida dos Pods. Permitem rollouts e rollbacks automáticos.

  3. ReplicaSets Garantem que o número desejado de Pods esteja sempre em execução. Os Deployments utilizam ReplicaSets internamente.

  4. Services Exponibilizam Pods para acesso interno ou externo. Podem ser:

  • ClusterIP – acesso interno no cluster
  • NodePort – acesso em portas expostas nos nodes
  • LoadBalancer – integração com balanceadores externos (cloud)

  1. ConfigMaps e Secrets Armazenam dados de configuração (ConfigMaps) e informações sensíveis (Secrets), que são injetados nos Pods como variáveis de ambiente ou arquivos.

  2. Volumes Fornecem armazenamento temporário ou persistente aos contêineres dentro de um Pod.

  3. Ingress Gerencia tráfego HTTP/S externo e encaminha requisições para os Services apropriados via regras de roteamento.

  4. Namespaces Segmentam o cluster em “espaços lógicos”, permitindo isolamento, organização e controle de recursos.

  5. Nodes Máquinas físicas ou virtuais onde os Pods são executados. Cada Node contém os agentes necessários para rodar containers e se comunicar com o cluster.

  6. Persistent Volumes (PVs) e Persistent Volume Claims (PVCs) Gerenciam armazenamento persistente de forma desacoplada, permitindo que aplicações mantenham dados mesmo quando Pods são recriados.

Como os Componentes Trabalham Juntos​

  • O Control Plane (Master Node) gerencia o estado desejado do cluster, garantindo que recursos como Pods, Deployments e Services estejam conforme definido.

  • Pods são criados e controlados por Deployments, que utilizam ReplicaSets para manter o número correto de réplicas.

  • Services tornam os Pods acessíveis para outros serviços internos ou usuários externos.

  • ConfigMaps e Secrets são anexados aos Pods para fornecer configurações e dados sensíveis de maneira segura.

  • O Ingress roteia tráfego externo HTTP/S para os Services corretos, oferecendo controle avançado de entrada.

  • PVs e PVCs permitem armazenamento persistente independente do ciclo de vida dos Pods.

  • Nodes executam os Pods, e o Scheduler do Kubernetes decide em qual Node cada Pod será alocado.

    alt text

  • Cluster: No Kubernetes, um cluster é um conjunto de nós (máquinas físicas ou virtuais) que são usados para executar e gerenciar aplicativos. O cluster é composto por um nó mestre e vários nós de trabalho. O nó mestre é responsável por controlar e coordenar as operações do cluster, enquanto os nós de trabalho executam os contêineres que contêm os aplicativos. O cluster fornece alta disponibilidade, escalabilidade e tolerância a falhas, permitindo que os aplicativos sejam executados de forma confiável e eficiente.

  • Master: Gerencia o cluster, mantém e atualiza o estado desejado e recebe/executa novos comandos

    • api, c-m, sched e etcd = control plane

  • Node: Executa as aplicações

    • kubelet e k-proxy = nodes

Sequência de dependência​

container <- pods <- replicaSet <- deployments

Pod​

  • Pod é um envelope em volta do container, podemos ter mais de um container dentro do pod
    • Se o container dentro do pod morrer, o kubernetes cria outro pod (são efêmeros)
    • Criando um pod: kubectl run nginx-pod --image=nginx:latest
    • Listar pods: kubectl get pods
    • Ver informações sobre um pod: kubectl describe pod <nome-pod>

ReplicaSet​

  • Estrutura que encapsula 1 ou mais pods
  • Está um nível acima dos podes e garante que um certo números de pods vai estar sempre rodando

PV e PVC​

Volumes Persistentes (PV)

Volumes Persistentes são simplesmente uma parte do armazenamento no cluster. Semelhante a como você tem um recurso de disco em um servidor, um volume persistente fornece recursos de armazenamento para objetos no cluster. De forma simplificada, você pode pensar em um PV como um disco rígido. Vale ressaltar que esse recurso de armazenamento existe independentemente de qualquer pod que possa consumi-lo. Ou seja, se o pod morrer, o armazenamento deve permanecer intacto, desde que as políticas de reivindicação estejam corretas. Os Volumes Persistentes são provisionados de duas maneiras: Estática ou Dinâmica.

  • Volumes Estáticos: Um PV estático simplesmente significa que algum administrador do Kubernetes provisionou um volume persistente no cluster, e ele está pronto para ser consumido por outros recursos.

  • Volumes Dinâmicos: Em algumas circunstâncias, um pod pode exigir um volume persistente que não exista. Nesses casos, é possível que o Kubernetes provisione o volume conforme necessário, se as classes de armazenamento forem configuradas para indicar onde os PVs dinâmicos devem ser criados. Este documento foca nos volumes estáticos por enquanto.

Reivindicações de Volume Persistente (PVC)

Os pods que precisam de acesso a armazenamento persistente obtêm esse acesso por meio de uma Reivindicação de Volume Persistente (PVC). Uma PVC vincula um volume persistente a um pod que o requisitou.

Quando um pod deseja acesso a um disco persistente, ele solicitará acesso à reivindicação, que especificará o tamanho, o modo de acesso e/ou as classes de armazenamento necessárias para o Volume Persistente. Indiretamente, os pods obtêm acesso ao PV, mas apenas por meio do uso de uma PVC.

Políticas de Reivindicação

Também mencionamos anteriormente as políticas de reivindicação. Um Volume Persistente pode ter várias políticas de reivindicação associadas, incluindo:

  • Retain (Manter): Quando a reivindicação é excluída, o volume permanece.

  • Recycle (Reciclar): Quando a reivindicação é excluída, o volume permanece, mas em um estado onde os dados podem ser recuperados manualmente.

  • Delete (Excluir): O volume persistente é excluído quando a reivindicação é excluída.

A política de reivindicação (associada ao PV e não à PVC) é responsável por determinar o que acontece com os dados quando a reivindicação é excluída.

alt

Exemplo de definição de um **Persistent Volume (PV)
  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: my-pv
  spec:
    capacity:
      storage: 10Gi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain
    storageClassName: manual
    hostPath:
      path: /mnt/data
  • capacity: Define o tamanho do volume (neste caso, 10 GB).
  • accessModes: Define o modo de acesso. Neste exemplo, o volume pode ser montado por um único nó no modo leitura/escrita.
  • persistentVolumeReclaimPolicy: Define a política de liberação do volume. Pode ser Retain, Recycle ou Delete. Neste caso, Retain significa que o volume não será automaticamente excluído quando o PVC for liberado.
  • hostPath: Um exemplo de um caminho local no nó onde o volume será montado. Em produção, seria preferível usar soluções de armazenamento em rede (NFS, AWS EBS, etc.).
Exemplo de definição de um **Persistent Volume Claim (PVC)
  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: my-pvc
  spec:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
    storageClassName: manual
  • accessModes: Especifica o tipo de acesso necessário. Neste exemplo, o PVC solicita um volume que possa ser montado como leitura/escrita por um único nó.
  • resources.requests.storage: Define a quantidade de armazenamento solicitada, 10 GB neste caso.
  • storageClassName: Neste exemplo, está vinculado ao PV que também especifica o storageClassName como manual.

Relação entre PV e PVC​

  • O PV representa o armazenamento real disponível no cluster, enquanto o PVC é a solicitação para utilizar esse armazenamento.
  • Quando um PVC é criado, o Kubernetes busca um PV disponível que atenda aos requisitos (como capacidade e modos de acesso).
  • Se um PV adequado for encontrado, o PVC é vinculado a esse PV e o pod que usa o PVC pode acessar o armazenamento associado ao PV.
Exemplo Completo: Usando PV e PVC com um Pod
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv
spec:
capacity:
  storage: 10Gi
accessModes:
  - ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: manual
hostPath:
  path: /mnt/data

2. Crie um Persistent Volume Claim (PVC):​

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: manual

3. Crie um Pod que utiliza o PVC:​

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: nginx
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: my-storage
  volumes:
    - name: my-storage
      persistentVolumeClaim:
        claimName: my-pvc

Modos de Acesso (Access Modes)​

Os modos de acesso são muito importantes ao trabalhar com PVs e PVCs. Eles determinam como o volume pode ser montado e acessado. Existem três principais modos de acesso:

  • ReadWriteOnce (RWO): O volume pode ser montado como leitura/escrita por um único nó.
  • ReadOnlyMany (ROX): O volume pode ser montado como somente leitura por muitos nós.
  • ReadWriteMany (RWX): O volume pode ser montado como leitura/escrita por muitos nós.

Storage Classes - Gerencia os discos e volumes dinamicamente​

O Kubernetes permite a criação de Storage Classes para definir diferentes tipos de armazenamento persistente, como discos de blocos ou sistemas de arquivos em diferentes provedores de nuvem (AWS, GCP, etc.). As Storage Classes facilitam o provisionamento dinâmico de volumes com diferentes tipos de desempenho, custo ou disponibilidade.

Exemplo de Storage Class:​

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "10"
  fsType: ext4

Neste exemplo, a StorageClass define volumes provisionados com o tipo de disco io1 da AWS EBS, ideal para cargas de trabalho com alto desempenho de I/O.

Deployment​

O Deployment é um dos recursos mais importantes do Kubernetes para gerenciar a execução de aplicações. Ele permite que você declare o estado desejado de um conjunto de pods (unidades de execução no Kubernetes) e garante que o cluster mantenha esse estado de forma contínua.

Está a um nível acima do ReplicaSet

Aqui estão os principais conceitos e funcionalidades do Deployment no Kubernetes:

Definição e Propósito​

O Deployment é um recurso de alto nível que gerencia a criação, atualização e a escalabilidade de réplicas de Pods. Ele ajuda a garantir que a aplicação esteja sempre disponível e permite automatizar atualizações e rollbacks de forma segura.

Manifeste do Deployment​

Você descreve um Deployment em um arquivo YAML (ou JSON), onde define os seguintes aspectos principais:

  • replicas: O número de instâncias (réplicas) do Pod que você deseja rodar.
  • template: Um template que descreve o Pod que será executado, incluindo o contêiner, imagem, portas e variáveis de ambiente.
  • strategy: A estratégia de atualização, podendo ser "RollingUpdate" ou "Recreate", que define como o Kubernetes aplica as mudanças durante uma atualização.

Exemplo de um arquivo YAML de Deployment básico:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-aplicacao
spec:
  replicas: 3
  selector:
    matchLabels:
      app: minha-aplicacao
  template:
    metadata:
      labels:
        app: minha-aplicacao
    spec:
      containers:
      - name: meu-container
        image: minha-imagem:1.0
        ports:
        - containerPort: 80

Principais Funcionalidades​

  • Escalonamento (Scaling): Permite aumentar ou diminuir o número de réplicas dos Pods, garantindo alta disponibilidade e capacidade de resposta conforme a demanda da aplicação.
  • Rolling Updates: O Deployment faz atualizações contínuas (rolling updates), permitindo que a nova versão da aplicação seja liberada gradualmente sem downtime.
  • Rollbacks: Se algo der errado com uma nova versão, você pode voltar a uma versão anterior rapidamente. O Kubernetes mantém um histórico de revisions, facilitando o rollback.
  • Self-healing: O Deployment monitora constantemente os Pods. Se um Pod falhar, o Kubernetes automaticamente substitui o Pod defeituoso por um novo, mantendo a aplicação em funcionamento.

Estratégias de Update​

Existem duas estratégias principais para controlar como os Deployments fazem atualizações:

  • RollingUpdate (padrão): Substitui gradualmente os Pods antigos pelos novos.
  • Recreate: Apaga todos os Pods antigos antes de criar os novos. Pode ser útil para cenários onde as versões antigas e novas não podem coexistir.

Comandos Kubernetes para gerenciar Deployments​

Com o kubectl, você pode interagir com os deployments facilmente:

  • Criar ou aplicar um Deployment:

    kubectl apply -f deployment.yaml

  • Escalar um Deployment:

    kubectl scale deployment minha-aplicacao --replicas=5

  • Fazer rollback de um Deployment:

    kubectl rollout undo deployment/minha-aplicacao

  • Ver o status de rollout:

    kubectl rollout status deployment/minha-aplicacao

Atualização de Imagens​

Você pode atualizar facilmente a versão de uma imagem para uma nova versão:

kubectl set image deployment/minha-aplicacao meu-container=minha-imagem:2.0

Essa mudança acionará um rolling update, onde a versão 1.0 será gradualmente substituída pela versão 2.0, garantindo que a aplicação continue funcionando durante a transição.

Histórico de Revisões​

Cada atualização de um Deployment gera uma nova revisão. Isso facilita a execução de rollbacks quando necessário. Você pode visualizar o histórico de revisões com:

kubectl rollout history deployment/minha-aplicacao

Propriedades Avançadas​

  • Probes: Você pode configurar liveness e readiness probes nos contêineres para garantir que o Kubernetes consiga detectar problemas e agir automaticamente.
  • Autoscaling: Combinado com o Horizontal Pod Autoscaler, o Deployment pode escalar automaticamente baseado em métricas, como CPU e memória.

Service (svc)​

No Kubernetes, o recurso Service (svc) é utilizado para expor uma aplicação executando em um conjunto de Pods e possibilitar que eles se comuniquem entre si ou com o exterior (no caso de expor a aplicação para fora do cluster). O Service age como um ponto de entrada estável para acessar os Pods, independentemente de seus endereços IP, que podem mudar ao longo do tempo, já que Pods são criados e destruídos de forma dinâmica.

  • NodePort:

Principais conceitos de um Service:​

  1. Definição e Propósito

    • Um Service agrupa um conjunto de Pods (definidos por seletores) e expõe eles através de um IP fixo e um nome DNS dentro do cluster.
    • O Service fornece balanceamento de carga entre os Pods para distribuir o tráfego de rede de forma eficiente.
    • O Kubernetes resolve o problema de endereços IP dinâmicos dos Pods, já que o Service oferece um IP virtual estático que permanece constante, independentemente da rotação dos Pods.

  2. Tipos de Service Existem quatro tipos principais de Service em Kubernetes, dependendo de como você quer que o tráfego seja exposto:

    • ClusterIP (padrão): O Service é acessível apenas dentro do cluster, utilizando um endereço IP interno. É usado para comunicação interna entre Pods.
    • NodePort: Expõe o Service em uma porta estática em cada nó do cluster. Com isso, o Service pode ser acessado externamente via <NodeIP>:<NodePort>. É bom apenas para uma aplicação, quando se implementa load balancer começa a atrapalhar
    • LoadBalancer: Usa um balanceador de carga externo, geralmente em um ambiente de nuvem, para expor o Service externamente. Este tipo é comum para expor aplicações publicamente.
    • ExternalName: Mapeia o nome de um Service para um nome DNS externo (útil para referenciar serviços externos sem criar balanceamento de carga ou redirecionamento de porta).

  3. Estrutura básica de um Service

    Um Service é descrito através de um arquivo YAML (ou JSON), onde você define as principais configurações, como tipo, seletor de Pods, portas expostas, etc.

    Exemplo de YAML para um Service do tipo ClusterIP:

    apiVersion: v1
    kind: Service
    metadata:
      name: meu-servico
    spec:
      selector:
        app: minha-aplicacao
      ports:
        - protocol: TCP
          port: 80       # Porta exposta pelo Service
          targetPort: 8080 # Porta no Pod

    Aqui, o Service mapeia a porta 80 para a porta 8080 do contêiner nos Pods que correspondem ao seletor app: minha-aplicacao.

  4. Como o Kubernetes resolve os Serviços O Kubernetes cria automaticamente uma entrada DNS para cada Service, o que permite que outros Pods no mesmo cluster se comuniquem com o Service apenas pelo seu nome.

    Exemplo de comunicação dentro do cluster:

    http://meu-servico

    Qualquer Pod no cluster pode usar esse endereço para se comunicar com o Service, e o Kubernetes vai automaticamente redirecionar o tráfego para um dos Pods em execução que o Service está gerenciando.

  5. Balanceamento de Carga

    • O Service distribui automaticamente o tráfego entre os Pods selecionados, garantindo que o tráfego seja balanceado de maneira uniforme.
    • Kubernetes utiliza mecanismos como round-robin para distribuir as requisições entre os Pods que fazem parte do Service.

  6. Exemplo de Service NodePort

    Para expor um Service externamente usando o tipo NodePort:

    apiVersion: v1
    kind: Service
    metadata:
      name: meu-servico-nodeport
    spec:
      type: NodePort
      selector:
        app: minha-aplicacao
      ports:
        - port: 80         # Porta acessada pelo Service
          targetPort: 8080  # Porta do contêiner nos Pods
          nodePort: 30000   # Porta exposta em cada nó

    Aqui, o Service será acessível externamente pelo IP do nó, em qualquer nó do cluster, na porta 30000, e internamente o tráfego será redirecionado para a porta 8080 do contêiner nos Pods correspondentes.

  7. Exemplo de Service LoadBalancer

    No caso de um ambiente de nuvem (como AWS ou GCP), você pode criar um Service do tipo LoadBalancer para expor o serviço externamente, utilizando os recursos de balanceamento de carga da nuvem:

    apiVersion: v1
    kind: Service
    metadata:
      name: meu-servico-loadbalancer
    spec:
      type: LoadBalancer
      selector:
        app: minha-aplicacao
      ports:
        - protocol: TCP
          port: 80
          targetPort: 8080

    Aqui, a nuvem automaticamente provisionará um balanceador de carga externo e mapeará o tráfego para os Pods internos.

Principais comandos para gerenciar Services com kubectl:​

  • Criar um Service:

    kubectl apply -f service.yaml

  • Listar os Services:

    kubectl get services

  • Descrever um Service (mostra detalhes de um Service específico):

  • Consegue ver tudo da configuração do pod e também algumas mensagens de erro

    kubectl describe service meu-servico

  • Deletar um Service:

    kubectl delete service meu-servico

HPA - Horizontal Pod Auto Scaler​

  • Responsável por fazer o auto scaler
  • Precisa do metric server para funcionar. Link: https://github.com/kubernetes-sigs/metrics-server
    • Nas releases do projeto, existe um arquivo .yaml chamado component e é ele que precisamos executar o kubectl apply
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: portal-noticias-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: portal-noticias-deployment
  minReplicas: 3
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50
    - type: Resource
      resource:
        name: memory
        targetAverageUtilization: 50

Statefulset​

Kubernetes StatefulSet é um recurso do Kubernetes que gerencia a implantação e o escalonamento de um conjunto de pods, garantindo que esses pods tenham identificadores únicos e persistentes. Diferente de um Deployment, que é ideal para aplicações sem estado, o StatefulSet é projetado para aplicações que requerem persistência e identidade, como bancos de dados e sistemas de mensageria. Cada pod em um StatefulSet é atribuído a um nome exclusivo e mantém seu estado mesmo após falhas ou reinicializações, o que é essencial para a integridade dos dados.