{"id":71858,"date":"2020-02-28T21:00:08","date_gmt":"2020-02-28T18:00:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/patterny-hraneniya-dannyh-v-kubernetes"},"modified":"2020-03-03T16:14:09","modified_gmt":"2020-03-03T13:14:09","slug":"patterny-hraneniya-dannyh-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"Padr\u00f5es de armazenamento de dados no Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Padr\u00f5es<\/a><\/noindex>
\nOl\u00e1, Habr!<\/p>\n

Lembramos que publicamos mais um conte\u00fado extremamente interessante e \u00fatil livro<\/a><\/noindex> sobre os padr\u00f5es do Kubernetes. Tudo come\u00e7ou com \"Padr\u00f5es<\/a><\/noindex>\" Brendan Burns, e, afinal, o trabalho nesse segmento para n\u00f3s a todo vapor<\/a><\/noindex>. Hoje, n\u00f3s oferecemos a voc\u00ea a leitura de um artigo do blog MinIO, que resume as tend\u00eancias e a especificidade dos padr\u00f5es de armazenamento de dados no Kubernetes.
\n<\/a><\/noindex><\/p>\n

O Kubernetes transformou fundamentalmente os padr\u00f5es tradicionais de desenvolvimento e implanta\u00e7\u00e3o de aplica\u00e7\u00f5es. Agora, uma equipe pode levar apenas alguns dias para desenvolver, testar e implantar uma aplica\u00e7\u00e3o em diferentes ambientes, tudo dentro de clusters Kubernetes. Esse tipo de trabalho com tecnologias anteriores geralmente levava semanas, se n\u00e3o meses.<\/p>\n

Essa acelera\u00e7\u00e3o foi poss\u00edvel gra\u00e7as \u00e0 abstra\u00e7\u00e3o proporcionada pelo Kubernetes \u2014 ou seja, pelo fato de que o Kubernetes lida com os detalhes de baixo n\u00edvel das m\u00e1quinas f\u00edsicas ou virtuais, permitindo que os usu\u00e1rios especifiquem, entre outros par\u00e2metros, o processador necess\u00e1rio, o volume de mem\u00f3ria necess\u00e1rio e o n\u00famero de inst\u00e2ncias de cont\u00eaineres. Como o suporte ao Kubernetes \u00e9 mantido por uma vasta comunidade e a aplica\u00e7\u00e3o do Kubernetes continua a se expandir, ele lidera de longe entre todas as plataformas de orquestra\u00e7\u00e3o de cont\u00eaineres.<\/p>\n

\u00c0 medida que o uso do Kubernetes se expande, tamb\u00e9m cresce a confus\u00e3o sobre os padr\u00f5es de armazenamento de dados utilizados<\/b><\/i>.<\/p>\n

Com a intensa concorr\u00eancia pela fatia do mercado do Kubernetes (ou seja, pelo armazenamento de dados), quando se fala de armazenamento de dados, os sinais se perdem em um ru\u00eddo alto.
\nO Kubernetes incorpora um modelo moderno de desenvolvimento e implanta\u00e7\u00e3o de aplica\u00e7\u00f5es, bem como sua gest\u00e3o. Esse modelo moderno desacopla o armazenamento de dados dos c\u00e1lculos. Para compreender totalmente esse desacoplamento no contexto do Kubernetes, tamb\u00e9m \u00e9 necess\u00e1rio entender o que s\u00e3o aplicativos que mant\u00eam estado e aqueles que n\u00e3o mant\u00eam estado, e como isso se relaciona com o armazenamento de dados. \u00c9 aqui que a abordagem da API REST, aplicada ao S3, apresenta vantagens claras em compara\u00e7\u00e3o com a abordagem POSIX\/CSI, caracter\u00edstica de outras solu\u00e7\u00f5es.<\/p>\n

Neste artigo, vamos falar sobre padr\u00f5es de armazenamento de dados no Kubernetes e abordar a quest\u00e3o das aplica\u00e7\u00f5es que operam sem estado e com estado, para entender a diferen\u00e7a entre elas e sua import\u00e2ncia. No texto, ser\u00e3o discutidas as aplica\u00e7\u00f5es e os padr\u00f5es de armazenamento de dados utilizados \u00e0 luz das melhores pr\u00e1ticas em containers e Kubernetes.<\/p>\n

Containers sem estado<\/h4>\n

\nContainers s\u00e3o, por natureza, leves e ef\u00eameros. Eles podem ser facilmente parados, removidos ou implantados em outro n\u00f3 \u2013 tudo isso leva apenas alguns segundos. Em um sistema de orquestra\u00e7\u00e3o de containers grande, essas opera\u00e7\u00f5es acontecem constantemente, e os usu\u00e1rios mal percebem essas mudan\u00e7as. No entanto, as movimenta\u00e7\u00f5es s\u00e3o poss\u00edveis apenas se o container n\u00e3o tiver depend\u00eancias do n\u00f3 em que est\u00e1 localizado. Containers assim s\u00e3o ditos como funcionando sem estado<\/i>.<\/p>\n

Containers com estado<\/h4>\n

\nSe um container armazena dados em dispositivos localmente conectados (ou em um dispositivo de bloco), o armazenamento de dados em que ele reside precisar\u00e1 ser movido para um novo n\u00f3 junto com o pr\u00f3prio container \u2013 em caso de falha. Isso \u00e9 importante, pois caso contr\u00e1rio, a aplica\u00e7\u00e3o em execu\u00e7\u00e3o no container n\u00e3o conseguir\u00e1 funcionar corretamente, pois precisa acessar os dados armazenados em m\u00eddias locais. Containers assim s\u00e3o ditos como funcionando com estado<\/i>.<\/p>\n

Sob uma perspectiva t\u00e9cnica, containers com estado tamb\u00e9m podem ser movidos para outros n\u00f3s. Geralmente, isso \u00e9 garantido atrav\u00e9s de sistemas de arquivos distribu\u00eddos ou armazenamento em bloco de rede anexados a todos os n\u00f3s onde os containers est\u00e3o em execu\u00e7\u00e3o. Assim, os containers t\u00eam acesso a volumes para armazenamento persistente, e as informa\u00e7\u00f5es s\u00e3o mantidas em discos distribu\u00eddos pela rede. Eu chamarei esse m\u00e9todo de \"abordagem de containers com estado<\/i>\", e na parte restante do artigo o chamarei assim por uma quest\u00e3o de uniformidade.<\/p>\n

\"Padr\u00f5es
\n
\nNa abordagem t\u00edpica de cont\u00eainer com estado, todos os pods de aplicativos est\u00e3o conectados a um \u00fanico sistema de arquivos distribu\u00eddo \u2013 formando uma esp\u00e9cie de armazenamento compartilhado, onde todos os dados dos aplicativos residem. Embora algumas varia\u00e7\u00f5es sejam poss\u00edveis, essa \u00e9 uma abordagem de alto n\u00edvel.<\/p>\n

Agora, vamos analisar por que a abordagem de cont\u00eainer com estado no mundo orientado para a nuvem \u00e9 um antipadr\u00e3o.<\/p>\n

Projeto de aplicativos orientado para a nuvem<\/h4>\n

\nTradicionalmente, os aplicativos usavam bancos de dados para armazenamento estruturado de informa\u00e7\u00f5es e discos locais ou sistemas de arquivos distribu\u00eddos, onde todos os dados n\u00e3o estruturados ou at\u00e9 mesmo semi-estruturados eram armazenados. \u00c0 medida que o volume de dados n\u00e3o estruturados crescia, os desenvolvedores perceberam que o POSIX era excessivamente 'falante', implicava custos significativos e, no final das contas, dificultava o funcionamento do aplicativo ao escalar para realmente grandes dimens\u00f5es.<\/p>\n

Isso basicamente contribuiu para o surgimento de um novo padr\u00e3o de armazenamento de dados, ou seja, armazenamento orientado para a nuvem, que opera principalmente com base em REST API e isenta o aplicativo da manuten\u00e7\u00e3o onerosa de um armazenamento local de dados. Nesse caso, o aplicativo efetivamente entra em um modo de opera\u00e7\u00e3o sem estado (uma vez que o estado est\u00e1 em um armazenamento remoto). Aplicativos modernos s\u00e3o constru\u00eddos desde o in\u00edcio levando esse fator em considera\u00e7\u00e3o. Geralmente, qualquer aplicativo moderno que processa dados de algum tipo (logs, metadados, blobs, etc.) \u00e9 constru\u00eddo dentro da paradigma orientada para a nuvem, onde o estado \u00e9 transferido para um sistema de software especialmente designado para seu armazenamento. <\/p>\n

A abordagem de cont\u00eainer com estado faz com que toda essa paradigma retorne exatamente ao ponto de partida! <\/b><\/i><\/p>\n

Ao usar interfaces POSIX para o armazenamento de dados, os aplicativos operam de maneira semelhante a como se estivessem salvando estados, afastando-se assim dos postulados mais importantes do design orientado \u00e0 nuvem, ou seja, da capacidade de variar o tamanho das cargas de trabalho dos aplicativos de acordo com a carga de entrada, mudar para um novo n\u00f3 assim que o atual falhar, e assim por diante.<\/p>\n

Ao analisarmos essa situa\u00e7\u00e3o mais de perto, percebemos que, ao escolher um armazenamento de dados, enfrentamos repetidamente o dilema \"POSIX versus REST API\", MAS com a agravante dos problemas do POSIX, devido \u00e0 natureza distribu\u00edda dos ambientes Kubernetes. Em particular,<\/p>\n