Entendendo componentes do Kubernetes – Volumes

Ter estudado Docker no ano passado, a princípio através de um curso da Alura, foi o ponto de partida para o meu interesse na cultura DevOps florescer. Eventualmente, em 2021, eu fui contemplada pelo programa #ChamaAsMinas, promovido pela escola LinuxTips, e ganhei o treinamento Containers Expert completamente na faixa. Além de consolidar meus conhecimentos de Docker, comecei a aprender o tal do Kubernetes e caramba… é muita coisa. Em uma das aulas, fomos apresentadas à diversos conceitos diferentes e estou fazendo essa série de posts porque senti que precisava ir um pouco mais fundo nisso. Por isso, venho por meio deste chamar vocês para minha próxima campanha, que é: entendendo componentes do KubernetesVolumes!

Desenho de um gatinho cinza, o Pusheen, digitando em um notebook.

Quais componentes essa série de posts vai abordar?

Se você, bem como eu, está fazendo o treinamento Descomplicando Kubernetes: hoje é seu dia de sorte. Saiba que vou tentar colocar aqui no meu blog, nos próximos 3 ou 4 posts, um resumo sobre todos os componentes que são explicados no dia 4 do curso. Dessa forma, meu objetivo é, para cada componente, descrever:

  • Sua definição
  • Exemplos de uso
  • Possíveis comandos relacionados
  • Trecho do respectivo YAML de criação e/ou algum YAML relacionado

No momento em que estou começando a escrever este post, acabei de finalizar os meus estudos deste dia do curso e estou com um pouquinho de medo do simulado final. 😅 Pessoalmente, tenho achado o Kubernetes bem mais difícil de entender do que o Docker, mas seguimos em frente!

Contudo, se você não está fazendo este curso, deixo aqui os componentes que pretendo abordar:

  • Volumes (já nesse post!)
    • EmptyDir
    • Persistent Volume
  • Cronjobs
  • Secrets
  • ConfigMaps
  • InitContainer
  • RBAC
    • ServiceAccounts
    • ClusterRole
    • ClusterRoleBinding
  • Helm

Ao final dessa série de posts, pretendo deixar um PDF com todo o conteúdo devidamente condensado, e também editado de uma forma bem bonitinha, pronto para ser usado para seus estudos de Kubernetes!


Volumes no Kubernetes

Definição

Antes de mais nada, se formos colocar de maneira bem simples, um volume nada mais é do que um diretório, acessado pelos containers de um Pod, que contém dados. Se você é dev e precisa de uma analogia bem grosseira, em outras palavras, podemos dizer que o seu Pod e os seus containers são uma aplicação e o volume seria um banco de dados.

A principal utilidade de um volume é tornar seus containers menos efêmeros. Um exemplo: você tem ali o seu cluster, com seus pods e então um dos containers existentes reinicializa devido à algum problema. Caso não haja nenhum tipo de volume associado à esse container, ele vai voltar “limpo”, ou seja, tal qual ele foi criado pela primeira vez. Portanto, os volumes servem para guardar todo e qualquer tipo de informação que possa te ajudar a não perder nenhum tipo de trabalho caso haja algum problema.

O Docker já tem o conceito de volumes, contudo, dentro do Kubernetes, isso é expandido: existem vários tipos de volumes diferentes, que se adequam à diversos usos, e os pods também podem usar quantos volumes forem necessários simultaneamente. Primordialmente, os volumes do Kubernetes podem ser divididos em duas categorias: os volumes efêmeros, cuja existência está condicionada à existência de um pod; e os volumes persistentes, que existem sempre, sem se importar se o pod ainda existe ou se já foi apagado. Apesar disso, não importando o tipo de volume, os dados serão sempre preservados mesmo que os containers dentro daquele pod sejam reiniciados, visto que eles estão atrelados ao pod, e não aos containers associados à ele.

EmptyDir

Definição

Tal qual expliquei ali em cima, o EmptyDir é um tipo de volume do Kubernetes e está dentro do grupo de volumes efêmeros, pois ele não trabalha com persistência de dados. Então cuidado: quando você apagar o seu pod, tudo o que estava salvo neste volume será perdido.

Este volume é criado ao passo que atribuímos um pod à um nó que já existe. Ele sempre vai ser inicializado vazio e tudo o que eventualmente for guardado aqui poderá ser acessado por todos os containers do pod.

Exemplo de uso

O EmptyDir é o volume ideal para ser usado em situações como:

  • quando você precisa de um “rascunho” para o seu algoritmo (por exemplo, algoritmos de ordenação)
  • quando você precisa de lugar para armazenar pontos de recuperação dos containers existentes dentro do seu pod

Configurando um Pod com um volume EmptyDir

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

⚠ Lembrete!

Para criar qualquer tipo de componente do Kubernetes a partir de um YAML, basta executar o seguinte comando:

kubectl create -f nome-do-arquivo.yaml

Persistent Volume

Antes de mais nada é necessário esclarecer que existem “dois conceitos” associados a esse único nome, Persistent Volume. O primeiro é mais geral, ou seja: define o componente Persistent Volume como um tipo de volume e o que ele provê. E dentro do componente Persistent Volume, também existe um “subcomponente” chamado Persistent Volume.

Confuso né? Vou tentar melhorar, peraí:

Uma imagem com o título "Persistent Volume", onde há um disquete com o título "PV" e um computador com o título "PVC"

Definição

Seja como for, existe um subsistema dentro do Kubernetes chamado Persistent Volume, e seu conceito é prover uma API para usuários e administradores que abstrai detalhes de como os volumes são fornecidos e como são consumidos. Dentro desse subsistema de Persistent Volumes, portanto, existem dois principais componentes que cuidam desse processo: o Persistent Volume e o Persistent Volume Claim.

Exemplo de uso

Visto que as aplicações estão cada vez mais inseridas na nuvem, quando alguém quer consumir os dados de uma API, por exemplo, é necessário fazer uma integração com um sistema de armazenamento específico (Amazon, Azure, etc). O Kubernetes, através do Persistent Volume, está justamente tentando mudar isso, através de uma abstração. Dessa forma, é possível conectar-se a uma variedade de sistemas na nuvem sem precisar criar dependências explícitas para cada sistema.

Portanto, com o Persistent Volume, o consumo de dados vindos de um sistema na nuvem tem uma integração mais fácil e firme, além de diminuir muito os custos relacionados à isso. Da mesma forma, faz com que seja mais fácil migrar entre sistemas de nuvem e/ou adotar estratégias que envolvam vários destes sistemas.

⚠ Atenção! Visto que temos uma definição mais bem explicadinha, vamos convencionar uma coisa: quando eu estiver falando do subsistema Persistent Volume, usarei o nome completo. Quando eu estiver falando do componente dentro do subsistema, usarei a sigla PV. Fechou?

Persistent Volume (o subcomponente)

Definição

Esse cara, dentro do subsistema que mencionamos, é quem de fato fornece o armazenamento dos volumes que queremos criar. Ele faz parte do cluster da mesma forma que qualquer outro recurso; tal qual um nó é um recurso, o PV também é. Ao contrário do EmptyDir, o PV é um volume do tipo persistente (óbvio né Olivia, duh), ou seja, seu conteúdo não está atrelado ao tempo de vida de um pod; depois que se apaga o pod que utiliza aquele volume, o conteúdo permanece ali. O PV é o objeto da API responsável, também, por capturar os detalhes da implementação do armazenamento (NFS, iSCI ou um provider de algum sistema da nuvem).

Configurando um PV com NFS

apiVersion: v1
kind: PersistentVolume
metadata:
  name: primeiro-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /opt/dados
    server: 10.138.0.2
    readOnly: false

⚠ Atenção! Para configurar o PV com NFS, é necessário configurar, também, o NFS. No repositório do Descomplicando Kubernetes é possível ver o passo a passo completo da criação deste componente.

Comandos relacionados

Diferentemente do EmptyDir, com o PV conseguimos executar alguns dos comandos kubeclt para visualizações.

kubectl get pv
kubectl describe pv [nome-do-seu-pv]

Persistent Volume Claim

Definição

O PVC é quem, de fato, vai acoplar um PV a um pod. O próprio nome já diz tudo: é através dele que poderemos “reinvindicar” (verbo to claim, em inglês) o acesso a um PV. Da mesma forma que um pod consome recursos de um nó, o PVC vai consumir recursos de um PV; e tal qual o pod pode requisitar níveis específicos de recursos, como CPU e memória, o PVC também pode especificar para o PV o tamanho e o modo de acesso que ele precisa do volume.

Modos de acesso

Todo volume pode e deve ser montado usando somente um modo de acesso, mesmo que ele suporte diversos modos diferentes. Os modos de acesso disponíveis são os seguintes:

  • ReadWriteOnce – somente um nó poderá realizar operações de leitura e escrita
  • ReadOnlyMany – o volume será somente leitura para todos os nós
  • ReadWriteMany – todos os nós podem realizar operações de leitura e escrita

Configurando um PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: primeiro-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 800Mi

Comandos relacionados

Tal qual o PV, conseguimos executar alguns comandos kubeclt para visualizações relacionadas ao PVC.

kubectl get pvc

Um diagrama para facilitar o rolê


📖 Links consultados

📕 Documentação do Kubernetes – Volumes

📘 Repositório do treinamento Descomplicando Kubernetes

📗 Stupid Simple Kubernetes — Persistent Volumes Explained


📜 Posts mais recentes

Um ambiente de desenvolvimento Rails com Docker

Atalhos de teclado para desenvolvedores .NET


💌 Recadinhos

Gostou do texto? Tem algo a adicionar? Alguma crítica construtiva? Feedbacks? Sugestões? Pedidos? Fique à vontade para me contatar via email (oli.pmatt@gmail.com), Twitter (@oliviamattiazzo), LinkedIn (/oliviamattiazzo) ou pela caixa de comentários aqui embaixo! Vai ser um prazer conversar contigo! ✨

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.