{"id":34825,"date":"2019-10-31T22:00:35","date_gmt":"2019-10-31T19:00:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah\/"},"modified":"2019-10-31T22:00:35","modified_gmt":"2019-10-31T19:00:35","slug":"kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","title":{"rendered":"Como conectar clusters Kubernetes em diferentes data centers","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Como
\nBem-vindo \u00e0 s\u00e9rie de guias r\u00e1pidos sobre Kubernetes.<\/strong> Esta \u00e9 uma coluna regular com as quest\u00f5es mais interessantes que recebemos online e em nossos treinamentos. Responde um especialista em Kubernetes.<\/p>\n

<\/p>\n

O especialista de hoje \u00e9 Daniele Polencic (Daniele Polencic<\/a><\/noindex>). Daniele atua como instrutor e desenvolvedor de software na Learnk8s<\/a><\/noindex>.<\/p><\/blockquote>\n

Se voc\u00ea deseja que sua pergunta seja respondida no pr\u00f3ximo post, entre em contato conosco por e-mail<\/a><\/noindex> ou para Twitter: @learnk8s<\/a><\/noindex>.<\/p>\n

<\/p>\n

Perdeu os posts anteriores? Procure-os aqui<\/a><\/noindex>.<\/p>\n

<\/p>\n

Como conectar clusters Kubernetes em diferentes data centers?<\/h3>\n

<\/p>\n

Resumidamente<\/strong>: em breve ser\u00e1 lan\u00e7ado o Kubefed v2<\/a><\/noindex>, al\u00e9m disso, recomendo ler sobre Shipper<\/a><\/noindex> e o projeto multi-cluster-scheduler.<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

\u00c9 bastante comum que a infraestrutura seja replicada e distribu\u00edda em diferentes regi\u00f5es, especialmente em ambientes controlados.<\/p><\/blockquote>\n

Se uma regi\u00e3o ficar indispon\u00edvel, o tr\u00e1fego \u00e9 redirecionado para outra para evitar interrup\u00e7\u00f5es.<\/strong><\/p>\n

<\/p>\n

Com o Kubernetes, \u00e9 poss\u00edvel usar uma estrat\u00e9gia semelhante e distribuir cargas de trabalho por diferentes regi\u00f5es.<\/p>\n

<\/p>\n

Voc\u00ea pode ter um ou mais clusters por equipe, regi\u00e3o, ambiente ou uma combina\u00e7\u00e3o desses elementos.<\/p>\n

<\/p>\n

Seus clusters podem estar hospedados em diferentes nuvens e em ambientes locais.<\/p>\n

<\/p>\n

Mas como planejar a infraestrutura para tal dispers\u00e3o geogr\u00e1fica?
\nDeve-se criar um \u00fanico grande cluster em v\u00e1rias nuvens por uma rede unificada?
\nOu ter muitos pequenos clusters e encontrar uma maneira de control\u00e1-los e sincroniz\u00e1-los?<\/em><\/p>\n

<\/p>\n

Um cluster principal<\/h3>\n

<\/p>\n

Criar um \u00fanico cluster em uma rede unificada n\u00e3o \u00e9 t\u00e3o simples.<\/em><\/p>\n

<\/p>\n

Imagine que voc\u00ea tenha uma falha, a conectividade entre segmentos do cluster foi perdida.<\/p>\n

<\/p>\n

Se voc\u00ea tiver um \u00fanico servidor mestre, metade dos recursos n\u00e3o conseguir\u00e1 receber novos comandos, pois n\u00e3o conseguir\u00e1 se conectar ao mestre.<\/p>\n

<\/p>\n

E, durante isso, voc\u00ea ter\u00e1 tabelas de roteamento antigas (kube-proxy<\/code> n\u00e3o consegue carregar novas) e nenhum pod adicional (o kubelet n\u00e3o consegue solicitar atualiza\u00e7\u00f5es).<\/p>\n

<\/p>\n

O que \u00e9 ainda pior, se o Kubernetes n\u00e3o v\u00ea um n\u00f3, ele o marca como perdido e redistribui os pods ausentes pelos n\u00f3s existentes.<\/p>\n

<\/p>\n

No final, voc\u00ea ter\u00e1 o dobro de pods.<\/strong><\/p>\n

<\/p>\n

Se voc\u00ea criar um servidor mestre para cada regi\u00e3o, haver\u00e1 problemas com o algoritmo de consenso no banco de dados etcd.Nota do editor \u2014 Na verdade, a base de dados etcd n\u00e3o precisa estar necessariamente nos servidores mestres. Ela pode ser executada em um grupo separado de servidores em uma \u00fanica regi\u00e3o. No entanto, isso resulta em um ponto de falha no cluster. Mas \u00e9 r\u00e1pido.<\/em>)<\/p>\n

<\/p>\n

etcd utiliza o algoritmo raft<\/a><\/noindex>, para concordar sobre o valor antes de grav\u00e1-lo no disco.
\nIsto \u00e9, a maioria das inst\u00e2ncias deve alcan\u00e7ar consenso antes que o estado possa ser gravado no etcd.<\/p>\n

<\/p>\n

Se a lat\u00eancia entre as inst\u00e2ncias do etcd aumentar drasticamente, como no caso de tr\u00eas inst\u00e2ncias do etcd em regi\u00f5es diferentes, leva muito tempo para concordar sobre o valor e grav\u00e1-lo no disco.
\nIsso tamb\u00e9m se reflete nos controladores do Kubernetes.<\/p>\n

<\/p>\n

O gerenciador de controladores leva mais tempo para se atualizar sobre a mudan\u00e7a e gravar a resposta no banco de dados.<\/p>\n

<\/p>\n

E como existem v\u00e1rios controladores, isso resulta em uma rea\u00e7\u00e3o em cadeia, e todo o cluster come\u00e7a a funcionar muito lentamente.<\/strong>.<\/p>\n

<\/p>\n

etcd \u00e9 t\u00e3o sens\u00edvel \u00e0 lat\u00eancia que na documenta\u00e7\u00e3o oficial, recomenda-se o uso de SSDs em vez de discos r\u00edgidos comuns.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Atualmente, n\u00e3o existem bons exemplos de uma grande rede para um \u00fanico cluster.<\/strong><\/p>\n

<\/p>\n

Principalmente, a comunidade de desenvolvedores e o grupo SIG-cluster est\u00e3o tentando entender como orquestrar clusters da mesma forma que o Kubernetes orquestra cont\u00eaineres.<\/p>\n

<\/p>\n

Op\u00e7\u00e3o 1: federa\u00e7\u00e3o de clusters com kubefed.<\/h3>\n

<\/p>\n

A resposta oficial do SIG-cluster \u00e9 kubefed2, a nova vers\u00e3o do cliente de origem e operador da kube federation.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Foi a primeira vez que se tentou gerenciar uma cole\u00e7\u00e3o de clusters como um \u00fanico objeto usando a ferramenta de kube federation.<\/p>\n

<\/p>\n

O come\u00e7o foi bom, mas no final o kube federation nunca se tornou popular, pois n\u00e3o suportava todos os recursos.<\/p>\n

<\/p>\n

Ele suportava entregas unificadas e servi\u00e7os, mas, por exemplo, n\u00e3o os StatefulSets.
\nAl\u00e9m disso, a configura\u00e7\u00e3o da federa\u00e7\u00e3o era transmitida na forma de anota\u00e7\u00f5es e carecia de flexibilidade.<\/p>\n

<\/p>\n

Imagine como poderia ser descrever a divis\u00e3o de r\u00e9plicas para cada cluster na federa\u00e7\u00e3o usando apenas anota\u00e7\u00f5es.<\/em><\/p>\n

<\/p>\n

Resultou em uma completa bagun\u00e7a.<\/strong><\/p>\n

<\/p>\n

O SIG-cluster fez um grande trabalho ap\u00f3s o kubefed v1 e decidiu abordar o problema de outra forma.<\/p>\n

<\/p>\n

Em vez de anota\u00e7\u00f5es, decidiram lan\u00e7ar um controlador, que \u00e9 instalado nos clusters. Ele pode ser configurado usando defini\u00e7\u00f5es de recursos personalizados (Custom Resource Definition, CRD).<\/strong><\/p>\n

<\/p>\n

Para cada recurso que far\u00e1 parte da federa\u00e7\u00e3o, voc\u00ea tem uma defini\u00e7\u00e3o personalizada de CRD composta por tr\u00eas se\u00e7\u00f5es:<\/p>\n

<\/p>\n