Bem-vindo à série de tutoriais rápidos do Kubernetes. Esta é uma coluna regular com as perguntas mais interessantes que recebemos on-line e em nossos treinamentos. O especialista em Kubernetes responde.
O especialista de hoje é Daniele Polencic . Daniel é instrutor e desenvolvedor de software na Learnk8s .
Se você quiser responder sua pergunta no próximo post, entre em contato conosco por e - mail ou no Twitter: @ learnk8s .
Ignorou as postagens anteriores? Procure-os aqui .
Como conectar clusters Kubernetes em diferentes datacenters?
Resumidamente : o Kubefed v2 será lançado em breve e também aconselho a ler sobre o Shipper e o projeto do planejador de vários clusters .
Muitas vezes, a infraestrutura é replicada e distribuída por diferentes regiões, especialmente em ambientes controlados.
Se uma região não estiver disponível, o tráfego será redirecionado para outra para evitar interrupções.
Com o Kubernetes, você pode usar uma estratégia semelhante e distribuir cargas de trabalho entre diferentes regiões.
Você pode ter um ou mais clusters por equipe, região, ambiente ou uma combinação desses elementos.
Seus clusters podem ser hospedados em nuvens diferentes e em um ambiente local.
Mas como planejar a infraestrutura para uma disseminação geográfica tão grande?
Precisa criar um cluster grande em vários ambientes de nuvem em uma única rede?
Ou criar muitos pequenos agrupamentos e encontrar uma maneira de controlá-los e sincronizá-los?
Um cluster principal
Criar um único cluster em uma única rede não é tão simples.
Imagine que você sofreu um acidente, perdeu a conectividade entre os segmentos do cluster.
Se você tiver um servidor mestre, metade dos recursos não poderá receber novos comandos, porque eles não poderão entrar em contato com o mestre.
E, ao mesmo tempo, você tem tabelas de roteamento antigas (o kube-proxy não pode carregar novas) e nenhum pod adicional (o kubelet não pode solicitar atualizações).
Para piorar, se o Kubernetes não vê o nó, ele o marca como perdido e distribui os pods ausentes nos nós existentes.
Como resultado, você tem o dobro de pods.
Se você criar um servidor mestre para cada região, haverá problemas com o algoritmo de consenso no banco de dados etcd. ( aprox. Ed. - Na verdade, o banco de dados etcd não precisa estar localizado nos servidores mestre. Ele pode ser executado em um grupo separado de servidores na mesma região. No entanto, ao mesmo tempo, recebeu um ponto de falha do cluster. Mas rapidamente. )
O etcd usa o algoritmo raft para negociar o valor antes de gravá-lo no disco.
Ou seja, a maioria dos casos deve chegar a um consenso antes que o estado possa ser gravado no etcd.
Se o atraso entre instâncias do etcd aumentar dramaticamente, como é o caso de três instâncias do etcd em regiões diferentes, leva muito tempo para reconciliar o valor e gravá-lo no disco.
Isso se reflete nos controladores Kubernetes.
O gerente do controlador precisa de mais tempo para aprender sobre a mudança e gravar a resposta no banco de dados.
E se o controlador não é um, mas vários, uma reação em cadeia é obtida, e todo o cluster começa a funcionar muito lentamente .
O etcd é tão sensível à latência que a documentação oficial recomenda o uso de SSDs em vez de discos rígidos comuns .
Atualmente, não há bons exemplos de uma rede grande para um único cluster.
Basicamente, a comunidade de desenvolvimento e o grupo de cluster SIG estão tentando descobrir como orquestrar clusters da mesma maneira que o Kubernetes orquestra contêineres.
Opção 1: federação de cluster com kubefed
A resposta oficial do cluster SIG é o kubefed2, uma nova versão da federação original do cliente e operador do kube .
Pela primeira vez, eles tentaram gerenciar a coleção de clusters como um único objeto usando a ferramenta de federação kube.
O começo foi bom, mas, no final, a federação kube não se tornou popular porque não suportava todos os recursos.
Ele apoiou entregas e serviços conjuntos, mas, por exemplo, não StatefulSets.
E a configuração da federação foi transmitida na forma de anotações e não diferiu em flexibilidade.
Imagine como você pode descrever a separação de réplicas para cada cluster em uma federação usando apenas anotações.
Acabou sendo uma bagunça completa.
O cluster SIG fez um ótimo trabalho após o kubefed v1 e decidiu abordar o problema do outro lado.
Em vez de anotações, eles decidiram liberar um controlador que está instalado nos clusters. Ele pode ser configurado usando a definição de recurso personalizado (CRD).
Para cada recurso que fará parte da federação, você tem uma definição CRD personalizada de três seções:
- definição padrão de um recurso, como deploy;
- seção de
placement , onde você determina como o recurso será distribuído na federação; override seção, onde, para um recurso específico, você pode substituir o peso e os parâmetros da veiculação.
Aqui está um exemplo de entrega combinada com seções de posicionamento e substituição.
apiVersion: types.federation.k8s.io/v1alpha1 kind: FederatedDeployment metadata: name: test-deployment namespace: test-namespace spec: template: metadata: labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx placement: clusterNames: - cluster2 - cluster1 overrides: - clusterName: cluster2 clusterOverrides: - path: spec.replicas value: 5
Como você pode ver, o suprimento é distribuído por dois clusters: cluster1 e cluster2 .
O primeiro cluster entrega três réplicas, enquanto o segundo está definido como 5.
Se você precisar de mais controle sobre o número de réplicas, o kubefed2 fornece um novo objeto ReplicaSchedulingPreference, onde as réplicas podem ser ponderadas:
apiVersion: scheduling.federation.k8s.io/v1alpha1 kind: ReplicaSchedulingPreference metadata: name: test-deployment namespace: test-ns spec: targetKind: FederatedDeployment totalReplicas: 9 clusters: A: weight: 1 B: weight: 2
A estrutura e a API do CRD ainda não estão prontas e o trabalho ativo está sendo realizado no repositório oficial do projeto.
Cuidado com o kubefed2, mas lembre-se de que ele ainda não é adequado para o ambiente de trabalho.
Saiba mais sobre o kubefed2 no artigo oficial do kubefed2 no blog do Kubernetes e no repositório oficial do projeto kubefed .
Opção 2: agrupando clusters no estilo Booking.com
Os desenvolvedores da Booking.com não lidaram com o kubefed v2, mas criaram o Shipper, um operador para entrega em vários clusters, em várias regiões e em várias nuvens.
O remetente é algo semelhante ao kubefed2.
Ambas as ferramentas permitem configurar a estratégia de implantação para vários clusters (quais clusters são usados e quantas réplicas eles possuem).
Mas o objetivo do Shipper é reduzir o risco de erros de entrega.
No remetente, você pode definir uma série de etapas que descrevem a separação de réplicas entre a implantação anterior e a atual e a quantidade de tráfego recebido.
Quando você envia um recurso para um cluster, o controlador Shipper implementa essa alteração passo a passo em todos os clusters combinados.
E o Shipper é muito limitado.
Por exemplo, ele aceita gráficos Helm como entrada e não suporta recursos de baunilha.
Em termos gerais, o Shipper funciona da seguinte maneira.
Em vez da entrega padrão, você precisa criar um recurso de aplicativo que inclua o gráfico Helm:
apiVersion: shipper.booking.com/v1alpha1 kind: Application metadata: name: super-server spec: revisionHistoryLimit: 3 template: chart: name: nginx repoUrl: https://storage.googleapis.com/shipper-demo version: 0.0.1 clusterRequirements: regions: - name: local strategy: steps: - capacity: contender: 1 incumbent: 100 name: staging traffic: contender: 0 incumbent: 100 - capacity: contender: 100 incumbent: 0 name: full on traffic: contender: 100 incumbent: 0 values: replicaCount: 3
O remetente é uma boa opção para gerenciar vários clusters, mas seu relacionamento próximo com o Helm apenas interfere.
E se todos mudarmos de Helm para customizar ou kapitan ?
Saiba mais sobre o remetente e sua filosofia neste comunicado de imprensa oficial .
Se você deseja se aprofundar no código, acesse o repositório oficial do projeto .
Opção 3: junção de cluster "mágica"
O Kubefed v2 e o Shipper trabalham com a federação de cluster, fornecendo aos clusters novos recursos por meio de definições personalizadas de recursos.
Mas e se você não quiser reescrever todos os suprimentos, StatefulSets, DaemonSets etc. para combinar?
Como incluir um cluster existente em uma federação sem alterar o YAML?
O multi-cluster-scheduler é um projeto de Admirality que lida com o planejamento de cargas de trabalho em clusters.
Mas, em vez de criar uma nova maneira de interagir com o cluster e agrupar recursos em definições definidas pelo usuário, o agendador de vários clusters é incorporado ao ciclo de vida padrão do Kubernetes e intercepta todas as chamadas criadas pelos pods.
Cada um deles foi substituído imediatamente por um manequim.
O agendador de vários clusters usa ganchos da Web para modificar o acesso para interceptar a chamada e criar um manequim de pod inativo.
O pod de origem passa por outro ciclo de planejamento, onde, após uma pesquisa de toda a federação, é tomada uma decisão sobre o posicionamento.
Finalmente, o pod é entregue ao cluster de destino.
Como resultado, você tem um pod extra que não faz nada, apenas ocupa espaço.
A vantagem é que você não precisou escrever novos recursos para combinar suprimentos.
Cada recurso que cria um pod está automaticamente pronto para ser mesclado.
Isso é interessante, porque de repente você tem entregas distribuídas por várias regiões, mas não percebeu. No entanto, isso é bastante arriscado, porque aqui tudo depende da magia.
Porém, se o Shipper tentar mitigar principalmente os efeitos dos suprimentos, o agendador de vários clusters executa tarefas mais gerais e provavelmente é mais adequado para tarefas em lote.
Não possui um mecanismo avançado de fornecimento gradual.
Você pode aprender mais sobre o agendador de vários clusters na página oficial do repositório .
Se você quiser ler sobre o agendador de vários clusters em ação, o Admiralty possui um caso de uso interessante com o Argo - fluxos de trabalho, eventos, CI e CDs do Kubernetes.
Outras ferramentas e soluções
Conectar e gerenciar vários clusters é uma tarefa complexa; não há solução universal.
Se você quiser saber mais sobre este tópico, aqui estão alguns recursos:
Isso é tudo por hoje
Obrigado por ler até o fim!
Se você souber conectar vários clusters com mais eficiência, informe-nos .
Adicionaremos seu método aos links.
Agradecimentos especiais a Chris Nesbitt-Smith e Vincent De Smet (engenheiro de confiabilidade da swatmobile.io ) por ler este artigo e compartilhar algumas informações úteis sobre como a federação funciona.