‫Até agora, com o Kubernetes, ainda não discutimos armazenamento
‫ou volumes.
‫Você lidou com isso com o Docker, e depois
‫com o Compose e o Swarm e, até certo ponto, é a
‫mesma coisa no Kubernetes.
‫Você tem contêineres e assumimos que os contêineres são
‫sem estado, o que significa que, quando você joga
‫fora o contêiner, tudo nele desaparece.
‫Quando você substitui um contêiner por uma atualização ou
‫altera algo e o aplica com um kubectl apply, você perde o contêiner,
‫perde tudo nele.
‫Obviamente, o Kubernetes, assim como os outros
‫orquestradores, precisa ter uma maneira de manter
‫os dados persistentes. É ainda mais do que os próprios volumes.
‫Até os contêineres e implantações podem ser diferentes no
‫Kubernetes com algo chamado StatefulSets.
‫Esses são recursos diferentes
‫das implantações.
‫Basicamente, eles são projetados em torno de bancos de dados e coisas que
‫exigem muito mais persistência, incluindo o mesmo nome,
‫os mesmos IPs desse tipo.
‫Nós não conseguimos isso de imediato com Swarm
‫ou Docker necessariamente.
‫Realmente não havia uma maneira de manter
‫esses atributos diferentes entre contêineres.
‫O StatefulSets é um novo recurso do Kubernetes
‫que está fora apenas um pouco de tempo aqui.
‫É o que você olharia se
‫considerasse bancos de dados ou algo muito sensível a
‫alterações como nomes, endereços IP, volumes e dados
‫persistentes. Uma palavra de cautela aqui.
‫O motivo pelo qual não vamos
‫analisar muitos detalhes é porque não recomendo que sua
‫primeira implantação do Kubernetes envolva
‫muitos StatefulSets. De fato, idealmente, sua primeira
‫implantação de um orquestrador, de qualquer orquestrador, seja
‫Swarm ou Kubernetes, está envolvida apenas com apátridas e,
‫você sabe, mantenha-o simples. Talvez faça apenas os front-ends da web
‫ou algumas APIs, ou alguns recursos de trabalho ou algo que não
‫envolva bancos de dados. De fato, se você pode usar bancos
‫de dados em nuvem, faça isso.
‫Eu sempre recomendo terceirizar seus bancos de dados, a menos
‫que você tenha requisitos específicos que você simplesmente não pode
‫evitar para executar a si próprio. A orquestração, inicialmente, foi
‫realmente projetada para contêineres serem imutáveis, distribuídos
‫e substituíveis.
‫Essa idéia de aderência ao estado adicionará mais
‫trabalho, complexidade e muito mais
‫testes para você. Idealmente, fora do portão, você não
‫precisa se preocupar com isso.
‫Mais tarde, quando você estiver muito mais confortável com todas as outras coisas
‫em torno do Kubernetes, poderá voltar e dizer: agora
‫quero considerar meus bancos de dados.
‫Não é que você não deva executar bancos de dados em clusters.
‫É apenas mais trabalho. É mais difícil.
‫Bancos de dados e armazenamento persistente são sempre mais difíceis e com
‫mais detalhes para trabalhar. Aqui está a minha dica profissional.
‫Com qualquer contêiner, você pode adicionar um volume
‫muito semelhante ao que você fez no Swarm e
‫no Docker e no Docker Compose. Você pode apenas adicionar uma declaração de volume
‫no modelo dentro das especificações. Se você pensa no arquivo
‫YAML, podemos colocar um volume como você esperaria,
‫e o formato e os detalhes
‫exatos estão nos recursos. Ao contrário do Docker
‫e do Swarm, onde o volume está em um
‫contêiner, nesse caso, é tecnicamente com o pod. Ele se conecta a cada contêiner, ou apenas a um
‫contêiner, no pod, se for solicitado.
‫Então, você está controlando no nível do contêiner, mas a persistência está no
‫nível do pod. Há um
‫recurso mais recente que é volumes persistentes.
‫Isso funciona com outra coisa chamada reivindicação.
‫A idéia interessante disso é que você
‫o está usando ou define fora
‫dos pods. Você está basicamente criando esse
‫recurso por conta própria e, em seguida, está fazendo uma reivindicação
‫contra esse recurso dentro das especificações do seu pod.
‫A razão pela qual isso é mais interessante é que
‫o Kubernetes assume a empresa, geralmente você tem pessoas
‫cuidando do armazenamento, geralmente de terceiros, que não é a mesma equipe que
‫executa o Kubernetes.
‫Eles serão os envolvidos no gerenciamento e
‫criação desses volumes persistentes.
‫Então são os implementadores de aplicativos que dirão:
‫ei, preciso
‫de um volume desse tipo. Então, vou fazer uma reivindicação de
‫SSD ou talvez precisemos de armazenamento em RAM, ou talvez precise de NFS, ou
‫o que seja. Esse armazenamento
‫será fornecido automaticamente porque a equipe de armazenamento
‫já o configurou no Kubernetes.
‫Esse é o tipo de idéia sobre volumes persistentes.
‫Se você precisar apenas temporariamente de um armazenamento simples
‫em um único servidor para o pod, use o atributo de
‫volumes padrão.
‫Uma última coisa aqui é
‫sobre a criação de plugins CSI. Na história do
‫Kubernetes, qualquer coisa que fosse armazenamento de terceiros,
‫seja armazenamento na nuvem ou algum armazenamento de terceiros,
‫ou algo personalizado, qualquer um desses itens
‫foi adicionado na árvore.
‫Isso significa que foi adicionado aos binários do Kubernetes
‫e enviado com o Kubernetes.
‫Isso significa que o Kubernetes veio com o armazenamento da
‫Amazon e do Azure criado imediatamente.
‫Isso foi bastante conveniente, mas acrescentou
‫muitos desafios.
‫A maioria delas estava relacionada ao fato de os fornecedores
‫de armazenamento agora estarem contribuindo com o código do núcleo do seu sistema
‫que você provavelmente nem precisava, porque você pode usar apenas um fornecedor de armazenamento, então
‫por que todos eles?
‫Além disso, os fornecedores de armazenamento tiveram que controlar seus ciclos de lançamento em
‫torno do ciclo de lançamento do Kubernetes, e não era
‫um modelo muito flexível.
‫Assim, a indústria se uniu e, como aconteceu
‫com a rede e com os próprios arquivos de Dockerfiles e
‫imagens, criou um padrão. Esse padrão é o CSI.
‫Isso significa Container Storage Interface.
‫Isso fornecerá plug-ins agora para que qualquer fornecedor de armazenamento
‫possa criar um plug-in que você instalaria em todos
‫os nós e que seria diferente com base
‫no plug-in e suas instruções.
‫Em seguida, eles operarão em uma API padrão que o CSI fornece
‫para que qualquer um de
‫seus contêineres possa usar esse plug-in para acessar seu armazenamento.
‫Esse é um modelo muito melhor e mais flexível.
‫Esse é o tipo de futuro do Kubernetes,
‫mas ainda é bem novo. Com frequência, em exemplos,
‫e mesmo os fornecedores de armazenamento podem recomendar, dependendo
‫da maturidade do CSI, que você use o plug-in tradicional,
‫embutido no Kubernetes e pronto para uso.