{"id":80076,"date":"2020-05-03T01:42:34","date_gmt":"2020-05-02T23:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt"},"modified":"2020-05-03T01:42:34","modified_gmt":"2020-05-02T23:42:34","slug":"proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt","title":{"rendered":"Projetando clusters Kubernetes: quantos devem existir?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota do tradutor.<\/b>: este material do projeto educacional <noindex><a rel=\"nofollow\" href=\"https:\/\/learnk8s.io\/\">learnk8s<\/a><\/noindex> \u2014 \u00e9 a resposta para uma pergunta popular ao projetar infraestrutura baseada em Kubernetes. Esperamos que as descri\u00e7\u00f5es detalhadas dos pr\u00f3s e contras de cada uma das op\u00e7\u00f5es ajudem a tomar a melhor decis\u00e3o para seu projeto.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Projetando clusters Kubernetes: quantos devem existir?\" src=\"\/wp-content\/uploads\/2020\/05\/d3cc3b7e686e39032b1f02f3e8b6c46c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>TL;DR<\/b>: o mesmo conjunto de cargas de trabalho pode ser executado em v\u00e1rios grandes clusters (cada cluster ter\u00e1 um grande n\u00famero de workloads) ou em muitas pequenas (com um n\u00famero reduzido de cargas em cada cluster).<\/p>\n<p>Abaixo est\u00e1 uma tabela avaliando os pr\u00f3s e contras de cada abordagem:<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><img decoding=\"async\" alt=\"Projetando clusters Kubernetes: quantos devem existir?\" src=\"\/wp-content\/uploads\/2020\/05\/ab5b5fefc97c3befddbaeb0791f8a90d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAo utilizar Kubernetes como plataforma para opera\u00e7\u00e3o de aplicativos, v\u00e1rias quest\u00f5es fundamentais sobre as nuances da configura\u00e7\u00e3o de clusters frequentemente surgem:<\/p>\n<ul>\n<li> <i>Quantos clusters usar?<\/i><\/li>\n<li> <i>Qual deve ser o tamanho deles?<\/i><\/li>\n<li> <i>O que cada cluster deve incluir?<\/i><\/li>\n<\/ul>\n<p>\nNeste artigo, tentarei responder a todas essas perguntas, analisando os pr\u00f3s e contras de cada abordagem.<\/p>\n<h2>Enunciado do Problema<\/h2>\n<p>\nComo criador de software, \u00e9 prov\u00e1vel que voc\u00ea desenvolva e opere simultaneamente v\u00e1rios aplicativos.<\/p>\n<p>Al\u00e9m disso, muitos inst\u00e2ncias desses aplicativos provavelmente s\u00e3o executadas em diferentes ambientes \u2014 por exemplo, podem ser <i>dev<\/i>, <i>test<\/i> e <i>prod<\/i>.<\/p>\n<p>Como resultado, cria-se uma verdadeira matriz de aplicativos e ambientes:<\/p>\n<p><img decoding=\"async\" alt=\"Projetando clusters Kubernetes: quantos devem existir?\" src=\"\/wp-content\/uploads\/2020\/05\/f2a811fa82e1e433463ba25d29f837e6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Aplicativos e Ambientes<\/i><\/p>\n<p>No exemplo acima, est\u00e3o apresentados 3 aplicativos e 3 ambientes, totalizando 9 combina\u00e7\u00f5es poss\u00edveis.<\/p>\n<p>Cada inst\u00e2ncia de aplicativo representa uma unidade de deployment autossuficiente, com a qual se pode trabalhar de forma independente.<\/p>\n<p><i>Observe que <b>inst\u00e2ncia de aplicativo<\/b> pode consistir em m\u00faltiplos <b>componentes<\/b>, como frontend, backend, banco de dados etc. No caso de um aplicativo de microservi\u00e7os, a inst\u00e2ncia incluir\u00e1 todos os microservi\u00e7os.<\/i><\/p>\n<p>Como resultado, os usu\u00e1rios do Kubernetes t\u00eam algumas perguntas:<\/p>\n<ul>\n<li> Devo hospedar todas as inst\u00e2ncias de aplicativo em um \u00fanico cluster?<\/li>\n<li> Devo criar um cluster separado para cada inst\u00e2ncia de aplicativo?<\/li>\n<li> Ou talvez deva utilizar uma combina\u00e7\u00e3o das abordagens mencionadas?<\/li>\n<\/ul>\n<p>\nTodas essas op\u00e7\u00f5es s\u00e3o vi\u00e1veis, pois o Kubernetes \u00e9 um sistema flex\u00edvel que n\u00e3o limita as possibilidades do usu\u00e1rio.<\/p>\n<p>Aqui est\u00e3o alguns dos caminhos poss\u00edveis:<\/p>\n<ul>\n<li> um grande cluster compartilhado;<\/li>\n<li> m\u00faltiplos clusters pequenos e especializados;<\/li>\n<li> um cluster para cada aplicativo;<\/li>\n<li> um cluster para cada ambiente.<\/li>\n<\/ul>\n<p>\nComo mostrado abaixo, as duas primeiras abordagens est\u00e3o em extremidades opostas da escala de op\u00e7\u00f5es:<\/p>\n<p><img decoding=\"async\" alt=\"Projetando clusters Kubernetes: quantos devem existir?\" src=\"\/wp-content\/uploads\/2020\/05\/99b8fd0d1e4173705e7996cf8ccb6eec.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>De v\u00e1rios clusters grandes (\u00e0 esquerda) a muitos pequenos (\u00e0 direita)<\/i><\/p>\n<p><i>Em geral, considera-se que um cluster \u00e9 \"maior\" que outro se ele tiver uma soma maior de n\u00f3s e pods. Por exemplo, um cluster com 10 n\u00f3s e 100 pods \u00e9 maior do que um cluster com 1 n\u00f3 e 10 pods.<\/i><\/p>\n<p>Bem, vamos come\u00e7ar!<\/p>\n<h2>1. Um grande cluster compartilhado<\/h2>\n<p>\nA primeira op\u00e7\u00e3o \u00e9 alocar todas as cargas de trabalho em um \u00fanico cluster:<\/p>\n<p><img decoding=\"async\" alt=\"Projetando clusters Kubernetes: quantos devem existir?\" src=\"\/wp-content\/uploads\/2020\/05\/283fc3c3f5ccb40a157ccff600628114.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Um grande cluster<\/i><\/p>\n<p>Dentro dessa abordagem, o cluster \u00e9 utilizado como uma plataforma de infraestrutura <b>\u2014 tudo o que voc\u00ea precisa \u00e9 simplesmente implantado no cluster Kubernetes existente.<\/b> Namespaces<\/p>\n<p><i><noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/overview\/working-with-objects\/namespaces\/\">Namespaces<\/a><\/noindex> Vamos analisar os pr\u00f3s e contras dessa abordagem.<\/i><\/p>\n<p><i>+ Uso eficiente de recursos<\/i><\/p>\n<h3>No caso de um \u00fanico cluster, apenas uma c\u00f3pia de todos os recursos necess\u00e1rios para iniciar e gerenciar o cluster Kubernetes ser\u00e1 necess\u00e1ria.<\/h3>\n<p>\nPor exemplo, isso \u00e9 v\u00e1lido para os n\u00f3s mestres. Normalmente, h\u00e1 3 n\u00f3s mestres para cada cluster Kubernetes, ent\u00e3o para um \u00fanico cluster esse n\u00famero permanecer\u00e1 o mesmo (para compara\u00e7\u00e3o, 10 clusters precisar\u00e3o de 30 n\u00f3s mestres).<\/p>\n<p>Essa sutileza acima se aplica a outros servi\u00e7os que funcionam em todo o cluster, como balanceadores de carga, controladores Ingress, sistemas de autentica\u00e7\u00e3o, registro e monitoramento.<\/p>\n<p>Em um \u00fanico cluster, todos esses servi\u00e7os podem ser usados simultaneamente para todas as cargas de trabalho (n\u00e3o \u00e9 necess\u00e1rio criar suas c\u00f3pias, como acontece em v\u00e1rios clusters).<\/p>\n<p>+ Barateza<\/p>\n<h3>Como consequ\u00eancia do que foi exposto, um n\u00famero menor de clusters geralmente \u00e9 mais barato, pois n\u00e3o h\u00e1 despesas com recursos redundantes.<\/h3>\n<p>\nIsso \u00e9 especialmente verdadeiro para n\u00f3s mestres, que podem custar bastante independetemente da forma de implanta\u00e7\u00e3o (on-premises ou na nuvem).<\/p>\n<p>Alguns servi\u00e7os Kubernetes gerenciados, como<\/p>\n<p>Google Kubernetes Engine (GKE) <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/kubernetes-engine\">Azure Kubernetes Service (AKS)<\/a><\/noindex> ou <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/aks\/\">Servi\u00e7o de Kubernetes do Azure (AKS)<\/a><\/noindex>, fornece uma camada de gerenciamento gratuitamente. Neste caso, a quest\u00e3o de custos \u00e9 menos problem\u00e1tica.<\/p>\n<p>Tamb\u00e9m existem servi\u00e7os gerenciados que cobram uma taxa fixa pelo funcionamento de cada cluster Kubernetes (por exemplo, <noindex><a rel=\"nofollow\" href=\"https:\/\/aws.amazon.com\/eks\/\">Amazon Elastic Kubernetes Service, EKS<\/a><\/noindex>).<\/p>\n<h3>+ Administra\u00e7\u00e3o eficiente<\/h3>\n<p>\nGerenciar um cluster \u00e9 mais f\u00e1cil do que gerenciar v\u00e1rios.<\/p>\n<p>A administra\u00e7\u00e3o pode incluir as seguintes tarefas:<\/p>\n<ul>\n<li> atualiza\u00e7\u00e3o da vers\u00e3o do Kubernetes;<\/li>\n<li> configura\u00e7\u00e3o do pipeline CI\/CD;<\/li>\n<li> instala\u00e7\u00e3o do plugin CNI;<\/li>\n<li> configura\u00e7\u00e3o do sistema de autentica\u00e7\u00e3o de usu\u00e1rios;<\/li>\n<li> instala\u00e7\u00e3o do controlador de acesso;<\/li>\n<\/ul>\n<p>\ne muitos outros\u2026<\/p>\n<p>No caso de um \u00fanico cluster, tudo isso precisa ser feito apenas uma vez.<\/p>\n<p>Para m\u00faltiplos clusters, as opera\u00e7\u00f5es precisam ser repetidas v\u00e1rias vezes, o que provavelmente exigir\u00e1 alguma automa\u00e7\u00e3o de processos e ferramentas para garantir sistematicidade e uniformidade no processo.<\/p>\n<p><i>Agora, algumas palavras sobre as desvantagens.<\/i><\/p>\n<h3>\u2212 Ponto \u00fanico de falha<\/h3>\n<p>\nNo caso de falha <i>do \u00fanico<\/i> cluster, as <i>tudo<\/i> cargas de trabalho param de funcionar imediatamente!<\/p>\n<p>Existem in\u00fameras situa\u00e7\u00f5es em que algo pode dar errado:<\/p>\n<ul>\n<li> a atualiza\u00e7\u00e3o do Kubernetes pode resultar em efeitos colaterais inesperados;<\/li>\n<li> um componente do cluster (por exemplo, o plugin CNI) come\u00e7a a funcionar de forma diferente do esperado;<\/li>\n<li> um dos componentes do cluster est\u00e1 configurado incorretamente;<\/li>\n<li> falha na infraestrutura subjacente.<\/li>\n<\/ul>\n<p>\nUm \u00fanico incidente pode causar danos significativos a todas as cargas de trabalho hospedadas no cluster compartilhado.<\/p>\n<h3>\u2212 Falta de isolamento rigoroso<\/h3>\n<p>\nTrabalhar em um cluster compartilhado significa que os aplicativos compartilham recursos de hardware, capacidades de rede e o sistema operacional nos n\u00f3s do cluster.<\/p>\n<p>De certa forma, dois cont\u00eaineres com dois aplicativos diferentes, executando no mesmo n\u00f3, s\u00e3o semelhantes a dois processos funcionando na mesma m\u00e1quina sob o mesmo n\u00facleo do SO.<\/p>\n<p><i>Os cont\u00eaineres Linux fornecem uma forma de isolamento, mas n\u00e3o \u00e9 t\u00e3o forte quanto a que \u00e9 fornecida, por exemplo, por m\u00e1quinas virtuais. Em ess\u00eancia, o processo em um cont\u00eainer \u00e9 o mesmo processo executado no sistema operacional do host.<\/i><\/p>\n<p>Isso pode se tornar um problema do ponto de vista da seguran\u00e7a: tal organiza\u00e7\u00e3o teoricamente permite que aplicativos n\u00e3o relacionados interajam entre si (intencionalmente ou acidentalmente).<\/p>\n<p>Al\u00e9m disso, todas as cargas de trabalho no cluster Kubernetes compartilham alguns servi\u00e7os comuns de cluster, como <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/dns-pod-service\/\">DNS<\/a><\/noindex> \u2014 isso permite que aplicativos encontrem os servi\u00e7os de outros aplicativos no cluster.<\/p>\n<p><i>Todos os pontos mencionados acima podem ter significados diferentes dependendo dos requisitos de seguran\u00e7a dos aplicativos.<\/i><\/p>\n<p>O Kubernetes fornece v\u00e1rias ferramentas para evitar problemas de seguran\u00e7a, como <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/policy\/pod-security-policy\/\">PodSecurityPolicies<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/network-policies\/\">NetworkPolicies<\/a><\/noindex>. No entanto, para configur\u00e1-las corretamente, \u00e9 necess\u00e1rio certa experi\u00eancia, al\u00e9m disso, elas n\u00e3o conseguem fechar todas as brechas de seguran\u00e7a.<\/p>\n<p>\u00c9 importante sempre lembrar que o Kubernetes foi projetado originalmente para <i>uso compartilhado<\/i>, e n\u00e3o para <i>isolamento e seguran\u00e7a<\/i>.<\/p>\n<h3>\u2212 Aus\u00eancia de multi-tenancy r\u00edgido<\/h3>\n<p>\nDada a abund\u00e2ncia de recursos compartilhados no cluster Kubernetes, existem v\u00e1rias maneiras de como diferentes aplicativos podem 'pisar no calo' uns dos outros.<\/p>\n<p>Por exemplo, um aplicativo pode monopolizar um recurso compartilhado (como CPU ou mem\u00f3ria) e privar outros aplicativos que est\u00e3o rodando no mesmo n\u00f3 de acesso a ele.<\/p>\n<p>O Kubernetes oferece v\u00e1rios mecanismos de controle para esse comportamento, como <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/manage-compute-resources-container\/\">solicita\u00e7\u00f5es de recursos e limites<\/a><\/noindex> <i>(veja tamb\u00e9m o artigo \u201c<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/489668\/\"> Limites de CPU e throttling agressivo no Kubernetes <\/a><\/noindex>' - nota do tradutor.)<\/i>, <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/policy\/resource-quotas\/\">ResourceQuotas<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/policy\/limit-range\/\">LimitRanges<\/a><\/noindex>. No entanto, assim como acontece com a seguran\u00e7a, sua configura\u00e7\u00e3o \u00e9 bastante complexa e n\u00e3o consegue prevenir todos os efeitos colaterais imprevistos.<\/p>\n<h3>\u2212 Grande n\u00famero de usu\u00e1rios<\/h3>\n<p>\nNo caso de um \u00fanico cluster, \u00e9 preciso abrir o acesso a muitas pessoas. E quanto maior o n\u00famero delas, maior \u00e9 o risco de que algo seja 'quebrado'.<\/p>\n<p>Dentro do cluster, \u00e9 poss\u00edvel controlar quem e o que pode fazer por meio de <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/access-authn-authz\/rbac\/\">controle de acesso baseado em fun\u00e7\u00f5es (RBAC)<\/a><\/noindex> <i>(veja o artigo \u201c<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/470503\/\"> Usu\u00e1rios e autoriza\u00e7\u00e3o RBAC no Kubernetes <\/a><\/noindex>' - nota do tradutor.)<\/i>. Contudo, isso n\u00e3o impedir\u00e1 que os usu\u00e1rios 'quebrem' algo dentro de sua zona de responsabilidade.<\/p>\n<h3>\u2212 Os clusters n\u00e3o podem crescer infinitamente<\/h3>\n<p>\nUm cluster que \u00e9 utilizado para todas as cargas de trabalho provavelmente ser\u00e1 bastante grande (em n\u00famero de n\u00f3s e pods).<\/p>\n<p>Mas aqui surge outro problema: clusters no Kubernetes n\u00e3o podem crescer infinitamente.<\/p>\n<p>H\u00e1 um limite te\u00f3rico para o tamanho do cluster. No Kubernetes, esse limite \u00e9 de aproximadamente <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/setup\/best-practices\/cluster-large\/\">5000 n\u00f3s, 150 mil pods e 300 mil cont\u00eaineres<\/a><\/noindex>.<\/p>\n<p>No entanto, na vida real, os problemas podem come\u00e7ar muito antes \u2014 por exemplo, com apenas <noindex><a rel=\"nofollow\" href=\"https:\/\/events19.lfasiallc.com\/wp-content\/uploads\/2017\/11\/BoF_-Not-One-Size-Fits-All-How-to-Size-Kubernetes-Clusters_Guang-Ya-Liu-_-Sahdev-Zala.pdf\">500 n\u00f3s<\/a><\/noindex>.<\/p>\n<p>O fato \u00e9 que grandes clusters imp\u00f5em uma alta carga na camada de controle do Kubernetes. Em outras palavras, para manter o cluster em funcionamento e usar os recursos de forma eficiente, \u00e9 necess\u00e1ria uma configura\u00e7\u00e3o cuidadosa.<\/p>\n<p><i>Esse problema \u00e9 abordado no artigo correspondente no blog original intitulado \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/learnk8s.io\/kubernetes-node-size\">Architecting Kubernetes clusters \u2014 choosing a worker node size<\/a><\/noindex>\u00bb.<\/i><\/p>\n<p><i>Mas vamos considerar a abordagem oposta: muitos clusters pequenos.<\/i><\/p>\n<h2>2. Muitos clusters pequenos e especializados<\/h2>\n<p>\nCom essa abordagem, voc\u00ea utiliza um cluster separado para cada elemento a ser implantado:<\/p>\n<p><img decoding=\"async\" alt=\"Projetando clusters Kubernetes: quantos devem existir?\" src=\"\/wp-content\/uploads\/2020\/05\/2320f62d945944f2e26f07252e9b8440.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Muitos clusters pequenos<\/i><\/p>\n<p>Para os prop\u00f3sitos deste artigo, um <i>elemento a ser implantado<\/i> refere-se a uma inst\u00e2ncia de aplicativo \u2014 por exemplo, a vers\u00e3o dev de um aplicativo espec\u00edfico.<\/p>\n<p>Nesta estrat\u00e9gia, o Kubernetes \u00e9 utilizado como um <b>ambiente de execu\u00e7\u00e3o<\/b> para inst\u00e2ncias individuais de aplicativo.<\/p>\n<p><i>+ Uso eficiente de recursos<\/i><\/p>\n<h3>+ Raio de explos\u00e3o limitado<\/h3>\n<p>\nQuando ocorre uma \"quebra\" no cluster, as consequ\u00eancias negativas s\u00e3o limitadas apenas \u00e0s cargas de trabalho que estavam implementadas nesse cluster. Todas as outras workloads permanecem intocadas.<\/p>\n<h3>+ Isolamento<\/h3>\n<p>\nAs cargas de trabalho alocadas em clusters individuais n\u00e3o compartilham recursos, como CPU, mem\u00f3ria, sistema operacional, rede ou outros servi\u00e7os.<\/p>\n<p>Como resultado, obtemos um isolamento rigoroso entre aplicativos n\u00e3o relacionados, o que pode beneficiar sua seguran\u00e7a.<\/p>\n<h3>+ Poucos usu\u00e1rios<\/h3>\n<p>\nConsiderando que cada cluster cont\u00e9m apenas um conjunto limitado de cargas de trabalho, o n\u00famero de usu\u00e1rios com acesso \u00e9 reduzido.<\/p>\n<p>Quanto menos pessoas tiverem acesso ao cluster, menor o risco de algo \"quebrar\".<\/p>\n<p><i>Vamos olhar para as desvantagens.<\/i><\/p>\n<h3>\u2212 Uso ineficiente de recursos<\/h3>\n<p>\nComo mencionado anteriormente, cada cluster Kubernetes requer um determinado conjunto de recursos de gerenciamento: n\u00f3s mestres, componentes da camada de controle, solu\u00e7\u00f5es de monitoramento e registros.<\/p>\n<p>Com um grande n\u00famero de clusters pequenos, \u00e9 necess\u00e1rio alocar uma parcela maior de recursos para gerenciamento.<\/p>\n<h3>\u2212 Custo elevado<\/h3>\n<p>\nO uso ineficiente de recursos automaticamente leva a custos elevados.<\/p>\n<p>Por exemplo, ter 30 n\u00f3s mestre em vez de tr\u00eas com a mesma capacidade de computa\u00e7\u00e3o certamente impactar\u00e1 os custos.<\/p>\n<h3>\u2212 Dificuldades de administra\u00e7\u00e3o<\/h3>\n<p>\nAdministrar muitos clusters Kubernetes \u00e9 muito mais complexo do que trabalhar com um \u00fanico.<\/p>\n<p>Por exemplo, ser\u00e1 necess\u00e1rio configurar autentica\u00e7\u00e3o e autoriza\u00e7\u00e3o para cada cluster. A atualiza\u00e7\u00e3o da vers\u00e3o do Kubernetes tamb\u00e9m ter\u00e1 que ser realizada v\u00e1rias vezes.<\/p>\n<p>Provavelmente, ser\u00e1 necess\u00e1rio aplicar automa\u00e7\u00e3o para aumentar a efici\u00eancia de todas essas tarefas.<\/p>\n<p><i>Agora, vamos considerar cen\u00e1rios menos extremos.<\/i><\/p>\n<h2>3. Um cluster para cada aplicativo<\/h2>\n<p>\nNesse approach, voc\u00ea cria um cluster separado para todas as inst\u00e2ncias de um aplicativo espec\u00edfico:<\/p>\n<p><img decoding=\"async\" alt=\"Projetando clusters Kubernetes: quantos devem existir?\" src=\"\/wp-content\/uploads\/2020\/05\/238ee74d4e4dc42b7daeadc1ce484905.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Cluster por aplicativo<\/i><\/p>\n<p>Esse caminho pode ser considerado uma generaliza\u00e7\u00e3o do princ\u00edpio \"<b>um cluster separado por equipe<\/b>\", uma vez que normalmente uma equipe de engenheiros se ocupa do desenvolvimento de um ou mais aplicativos.<\/p>\n<p><i>+ Uso eficiente de recursos<\/i><\/p>\n<h3>+ O cluster pode ser ajustado para o aplicativo<\/h3>\n<p>\nSe o aplicativo tiver necessidades especiais, elas podem ser implementadas no cluster sem afetar outros clusters.<\/p>\n<p>Essas necessidades podem incluir workers com GPU, certos plug-ins CNI, service mesh ou algum outro servi\u00e7o.<\/p>\n<p>Cada cluster pode ser ajustado para o aplicativo que est\u00e1 nele operando, de modo que contenha apenas o que \u00e9 necess\u00e1rio.<\/p>\n<h3>\u2212 Diferentes ambientes em um \u00fanico cluster<\/h3>\n<p>\nA desvantagem desse approach \u00e9 que as inst\u00e2ncias de aplicativos de diferentes ambientes coexistem em um \u00fanico cluster.<\/p>\n<p>Por exemplo, a vers\u00e3o em produ\u00e7\u00e3o do aplicativo roda no mesmo cluster que a vers\u00e3o de desenvolvimento. Isso tamb\u00e9m significa que os desenvolvedores operam no mesmo cluster em que a vers\u00e3o de produ\u00e7\u00e3o do aplicativo est\u00e1 em opera\u00e7\u00e3o.<\/p>\n<p>Se, devido \u00e0s a\u00e7\u00f5es dos desenvolvedores ou falhas da vers\u00e3o de desenvolvimento, houver uma falha no cluster, a vers\u00e3o de produ\u00e7\u00e3o pode sofrer, o que \u00e9 uma grande desvantagem desse approach.<\/p>\n<p><i>E, finalmente, o \u00faltimo cen\u00e1rio na nossa lista.<\/i><\/p>\n<h2>4. Um cluster para cada ambiente<\/h2>\n<p>\nEsse cen\u00e1rio prev\u00ea a aloca\u00e7\u00e3o de um cluster separado para cada ambiente:<\/p>\n<p><img decoding=\"async\" alt=\"Projetando clusters Kubernetes: quantos devem existir?\" src=\"\/wp-content\/uploads\/2020\/05\/157da599edf178832b1b15459786fbc8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Um cluster para cada ambiente<\/i><\/p>\n<p>Por exemplo, voc\u00ea pode ter clusters <i>dev<\/i>, <i>test<\/i> e <i>prod<\/i>, nos quais voc\u00ea executar\u00e1 todas as inst\u00e2ncias do aplicativo destinadas a um ambiente espec\u00edfico.<\/p>\n<p><i>Aqui est\u00e3o os pr\u00f3s e contras desse approach.<\/i><\/p>\n<h3>+ Isolamento do ambiente de produ\u00e7\u00e3o<\/h3>\n<p>\nNeste enfoque, todos os ambientes s\u00e3o isolados uns dos outros. No entanto, na pr\u00e1tica, isso \u00e9 especialmente importante para o ambiente de produ\u00e7\u00e3o.<\/p>\n<p>As vers\u00f5es de produ\u00e7\u00e3o do aplicativo agora n\u00e3o dependem do que acontece em outros clusters e ambientes.<\/p>\n<p>Assim, se ocorrer um problema inesperado no cluster de desenvolvimento, as vers\u00f5es em produ\u00e7\u00e3o dos aplicativos continuar\u00e3o a funcionar como se nada tivesse acontecido.<\/p>\n<h3>+ O cluster pode ser ajustado para o ambiente<\/h3>\n<p>\nCada cluster pode ser ajustado para o seu ambiente. Por exemplo, \u00e9 poss\u00edvel:<\/p>\n<ul>\n<li> instalar ferramentas de desenvolvimento e depura\u00e7\u00e3o no cluster de desenvolvimento;<\/li>\n<li> instalar frameworks e ferramentas de teste no cluster; <i>test<\/i>;<\/li>\n<li> usar hardware mais potente e canais de rede no cluster; <i>prod<\/i>.<\/li>\n<\/ul>\n<p>\nIsso permite aumentar a efici\u00eancia tanto do desenvolvimento quanto da opera\u00e7\u00e3o dos aplicativos.<\/p>\n<h3>+ Limita\u00e7\u00e3o de acesso ao cluster de produ\u00e7\u00e3o<\/h3>\n<p>\nA necessidade de trabalhar diretamente com o cluster de produ\u00e7\u00e3o n\u00e3o surge com frequ\u00eancia, portanto, \u00e9 poss\u00edvel restringir significativamente o n\u00famero de pessoas que t\u00eam acesso a ele.<\/p>\n<p>\u00c9 poss\u00edvel ir ainda mais longe e eliminar completamente o acesso humano a esse cluster, realizando todos os deploys por meio de uma ferramenta de CI\/CD automatizada. Essa abordagem reduzir\u00e1 ao m\u00e1ximo o risco de erros humanos exatamente onde isso \u00e9 mais cr\u00edtico.<\/p>\n<p><i>Agora, algumas palavras sobre as desvantagens.<\/i><\/p>\n<h3>\u2212 Falta de isolamento entre aplicativos<\/h3>\n<p>\nA principal desvantagem do abordagem \u00e9 a falta de isolamento de hardware e recursos entre os aplicativos.<\/p>\n<p>Aplicativos desconectados compartilham recursos do cluster: n\u00facleo do sistema, processador, mem\u00f3ria e alguns outros servi\u00e7os.<\/p>\n<p>Como j\u00e1 mencionado, isso pode ser potencialmente perigoso.<\/p>\n<h3>\u2212 Impossibilidade de localizar as depend\u00eancias dos aplicativos<\/h3>\n<p>\nSe um aplicativo tiver requisitos especiais, \u00e9 necess\u00e1rio atend\u00ea-los em todos os clusters.<\/p>\n<p>Por exemplo, se um aplicativo precisar de GPU, ent\u00e3o cada cluster deve conter pelo menos um worker com GPU (mesmo que seja usado apenas por esse aplicativo).<\/p>\n<p>Como resultado, corremos o risco de ter custos mais altos e uso ineficaz dos recursos.<\/p>\n<h2>Conclus\u00e3o<\/h2>\n<p>\nCom um conjunto espec\u00edfico de aplicativos, eles podem ser implantados em v\u00e1rios grandes clusters ou em muitos pequenos.<\/p>\n<p>O artigo discute os pr\u00f3s e contras de diferentes abordagens, come\u00e7ando por um \u00fanico cluster global e terminando com v\u00e1rios clusters pequenos e especializados:<\/p>\n<ul>\n<li> um grande cluster comum;<\/li>\n<li> m\u00faltiplos clusters pequenos e especializados;<\/li>\n<li> um cluster para cada aplicativo;<\/li>\n<li> um cluster para cada ambiente.<\/li>\n<\/ul>\n<p>\n<i>Ent\u00e3o, qual abordagem escolher?<\/i><\/p>\n<p>Como de costume, a resposta depende do cen\u00e1rio de uso: \u00e9 necess\u00e1rio pesar os pr\u00f3s e contras de diferentes abordagens e escolher a op\u00e7\u00e3o mais otimizada.<\/p>\n<p>No entanto, a escolha n\u00e3o se limita aos exemplos acima \u2014 pode-se usar qualquer combina\u00e7\u00e3o deles!<\/p>\n<p>Por exemplo, pode-se organizar um par de clusters para cada equipe: um cluster para desenvolvimento (onde estar\u00e3o os ambientes <i>dev<\/i> e <i>test<\/i>) e um cluster para <i>production<\/i> (onde estar\u00e1 o ambiente de produ\u00e7\u00e3o).<\/p>\n<p>Com base nas informa\u00e7\u00f5es deste artigo, voc\u00ea poder\u00e1 otimizar adequadamente os pr\u00f3s e contras para um cen\u00e1rio espec\u00edfico. Boa sorte!<\/p>\n<h2>P.S.<\/h2>\n<p>\nConfira tamb\u00e9m em nosso blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/484954\/\">Guia visual para diagnosticar problemas no Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/480946\/\">Logs no Kubernetes (e n\u00e3o s\u00f3) hoje: expectativas e realidade<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/478306\/\">Service Mesh: o que cada Software Engineer precisa saber sobre a tecnologia mais hype<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468679\/\">O ABC da seguran\u00e7a no Kubernetes: autentica\u00e7\u00e3o, autoriza\u00e7\u00e3o, auditoria<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/498100\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u043e\u0442 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u043e\u0442 \u043e\u0431\u0440\u0430\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430 learnk8s \u2014 \u043e\u0442\u0432\u0435\u0442 \u043d\u0430 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0439 \u0432\u043e\u043f\u0440\u043e\u0441 \u043f\u0440\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0438 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u043d\u0430 \u0431\u0430\u0437\u0435 Kubernetes. \u041d\u0430\u0434\u0435\u0435\u043c\u0441\u044f, \u0447\u0442\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0440\u0430\u0437\u0432\u0451\u0440\u043d\u0443\u0442\u044b\u0435 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u044f \u043f\u043b\u044e\u0441\u043e\u0432 \u0438 \u043c\u0438\u043d\u0443\u0441\u043e\u0432 \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u0438\u0437 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u043e\u0432 \u043f\u043e\u043c\u043e\u0433\u0443\u0442 \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043e\u043f\u0442\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u0439 \u0432\u044b\u0431\u043e\u0440 \u0438 \u0434\u043b\u044f \u0432\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430. TL;DR: \u043e\u0434\u0438\u043d \u0438 \u0442\u043e\u0442 \u0436\u0435 \u043d\u0430\u0431\u043e\u0440 \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u043d\u0430\u0433\u0440\u0443\u0437\u043e\u043a \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043a\u0440\u0443\u043f\u043d\u044b\u0445 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 (\u043d\u0430 \u043a\u0430\u0436\u0434\u044b\u0439 \u043a\u043b\u0430\u0441\u0442\u0435\u0440 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":80077,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-80076","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 Kubernetes-\u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432: \u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0438\u0445 \u0434\u043e\u043b\u0436\u043d\u043e \u0431\u044b\u0442\u044c? | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-02T23:42:34+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-02T23:42:34+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Projeto de clusters Kubernetes: quantos devem existir? | ProHoster","description":"Nota.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 Kubernetes-\u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432: \u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0438\u0445 \u0434\u043e\u043b\u0436\u043d\u043e \u0431\u044b\u0442\u044c? | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-02T23:42:34+00:00","article:modified_time":"2020-05-02T23:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"80076","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:24:58","updated":"2022-10-02 20:23:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/80076","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=80076"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/80076\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/80077"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=80076"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=80076"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=80076"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}