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 Kubernetes – Volumes!

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í:

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! ✨