Bem-vindo à nossa série de início rápido do Kubernetes. Esta é uma coluna regular com as perguntas mais interessantes que recebemos online e em nossos treinamentos. Respostas de especialistas em Kubernetes.
O especialista de hoje é Daniel Polenchik (). Daniel trabalha como instrutor e desenvolvedor de software na .
Se você quiser que sua pergunta seja respondida no próximo post, ou .
Perdeu postagens anteriores? .
Como conectar clusters Kubernetes em diferentes data centers?
Brevemente: , e também recomendo ler sobre и .
Muitas vezes, a infraestrutura é replicada e distribuída em diferentes regiões, especialmente em ambientes controlados.
Se uma região estiver indisponí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 em 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 diferentes nuvens e no local.
Mas como planejar a infraestrutura para tal distribuição geográfica?
Você precisa criar um cluster grande para vários ambientes de nuvem em uma única rede?
Ou tem muitos clusters pequenos e encontra uma maneira de controlá-los e sincronizá-los?
Um cluster de liderança
Criar um cluster em uma única rede não é tão fácil.
Imagine que você sofre um acidente e a conectividade entre os segmentos do cluster é perdida.
Se você tiver um servidor mestre, metade dos recursos não poderá receber novos comandos porque não conseguirá entrar em contato com o mestre.
E ao mesmo tempo você tem tabelas de roteamento antigas (kube-proxy não é possível baixar novos) e nenhum pod adicional (o kubelet não pode solicitar atualizações).
Para piorar a situação, se o Kubernetes não encontrar um nó, ele o marcará como órfão e distribuirá os pods ausentes aos 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. (Aproximadamente. Ed. — Na verdade, o banco de dados etcd não precisa necessariamente estar localizado nos servidores mestres. Ele pode ser executado em um grupo separado de servidores na mesma região. É verdade, ao mesmo tempo obtendo um ponto de falha do cluster. Mas rápido.)
etcd usa para negociar o valor antes de gravá-lo no disco.
Ou seja, a maioria das instâncias deve chegar a um consenso antes que o estado possa ser gravado no etcd.
Se a latência entre as instâncias do etcd aumentar drasticamente, como é o caso de três instâncias do etcd em regiões diferentes, levará muito tempo para negociar um valor e gravá-lo no disco.
Isso se reflete nos controladores Kubernetes.
O gerenciador do controlador precisa de mais tempo para aprender sobre a mudança e escrever a resposta no banco de dados.
E como não existe um controlador, mas vários, resulta uma reação em cadeia e todo o cluster começa a funcionar muito lentamente.
etcd é tão sensível à latência que .
Atualmente não existem bons exemplos de uma grande rede para um único cluster.
Basicamente, a comunidade de desenvolvedores e o grupo de clusters SIG estão tentando descobrir como orquestrar clusters da mesma forma que o Kubernetes orquestra contêineres.
Opção 1: federação de cluster com kubefed
Resposta oficial do cluster SIG - .
Pela primeira vez, tentamos gerenciar uma 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 nunca se tornou popular porque não apoiava todos os recursos.
Suportava entregas e serviços federados, mas não StatefulSets, por exemplo.
Além disso, a configuração da federação era transmitida na forma de anotações e não era flexível.
Imagine como você poderia descrever o particionamento de réplica para cada cluster em uma federação usando apenas anotações.
Foi uma bagunça completa.
O cluster SIG trabalhou muito após o kubefed v1 e decidiu abordar o problema de um ângulo diferente.
Em vez de anotações, eles decidiram lançar um controlador instalado em clusters. Ele pode ser personalizado usando Definições de Recursos Personalizados (CRDs).
Para cada recurso que fará parte da federação, você tem uma definição de CRD personalizada com três seções:
- definição padrão de um recurso, por exemplo implantação;
- seção
placement, onde você define como o recurso será distribuído na federação; - seção
override, onde para um recurso específico você pode substituir o peso e os parâmetros do posicionamento.
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: 5Como você pode ver, a oferta está distribuída em dois clusters: cluster1 и cluster2.
O primeiro cluster fornece três réplicas e o segundo é definido como 5.
Se você precisar de mais controle sobre o número de réplicas, 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: 2A estrutura e API do CRD ainda não estão prontas e um trabalho ativo está em andamento no repositório oficial do projeto.
Fique de olho no kubefed2, mas lembre-se que ele ainda não está adequado para produção.
Saiba mais sobre kubefed2 em no blog sobre Kubernetes e em .
Opção 2: combinar clusters no estilo Booking.com
Os desenvolvedores do Booking.com não trabalharam no kubefed v2, mas criaram o Shipper - uma operadora de entrega em vários clusters, em várias regiões e em várias nuvens.
um pouco semelhante ao kubefed2.
Ambas as ferramentas permitem personalizar sua estratégia de implantação de vários clusters (quais clusters são usados e quantas réplicas eles possuem).
Mas O objetivo do expedidor é reduzir o risco de erros durante a entrega.
No Shipper, você pode definir uma série de etapas que descrevem a divisão das réplicas entre a implantação anterior e atual e o volume de tráfego de entrada.
Quando você envia um recurso para um cluster, o controlador do expedidor implementa essa alteração de forma incremental em todos os clusters associados.
Além disso, o Shipper é muito limitado.
Por exemplo, aceita gráficos de leme como entrada e não oferece suporte a recursos vanilla.
Em termos gerais, o Shipper funciona assim.
Em vez da entrega padrão, você precisa criar um recurso de aplicativo que inclua um 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: 3O Shipper é uma boa opção para gerenciar vários clusters, mas seu relacionamento próximo com o Helm só atrapalha.
E se todos mudarmos de Helm para ou ?
Saiba mais sobre a Shipper e sua filosofia em .
Se você quiser se aprofundar no código, .
Opção 3: fusão “mágica” de cluster
Kubefed v2 e Shipper trabalham com federação de clusters, fornecendo novos recursos aos clusters por meio de definição de recursos personalizados.
Mas e se você não quiser reescrever todas as entregas, StatefulSets, DaemonSets, etc.
Como incluir um cluster existente em uma federação sem alterar o YAML?
, que trata do agendamento 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 personalizadas, o agendador de vários clusters é incorporado ao ciclo de vida padrão do Kubernetes e intercepta todas as chamadas que criam pods.
Cada pod criado é imediatamente substituído por um fictício.
usos do agendador de vários clusters para interceptar a chamada e criar um pod fictício ocioso.
O pod original passa por outro ciclo de planejamento onde, após sondar toda a federação, é tomada uma decisão de colocação.
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 suprimentos distribuídos por diversas regiões e você nem percebeu. Porém, isso é bastante arriscado, porque tudo aqui depende da magia.
Mas enquanto o Shipper tenta mitigar principalmente o impacto das entregas, o agendador de vários clusters lida com tarefas mais gerais e talvez seja mais adequado para trabalhos em lote.
Não possui um mecanismo avançado de entrega gradual.
Mais sobre o agendador de vários clusters pode ser encontrado em .
Se você quiser ler sobre o agendador de vários clusters em ação, o Admiralty tem — fluxos de trabalho, eventos, CI e CD Kubernetes.
Outras ferramentas e soluções
Conectar e gerenciar vários clusters é uma tarefa complexa e não existe uma solução universal.
Se você quiser explorar mais este tópico, aqui estão alguns recursos:
- é uma ferramenta que conecta redes sobrepostas de diferentes clusters Kubernetes.
- Cadeia de varejo Target usa .
- Tente usar IPV6 e .
- Você pode usar uma malha de serviço, por exemplo .
- Cilium, um plugin de interface de rede de contêineres, oferece , que permite combinar vários clusters
Isso é tudo por hoje
Obrigado por ler até o fim!
Se você sabe como conectar vários clusters com mais eficiência, .
Adicionaremos seu método aos links.
Agradecimentos especiais a Chris Nesbitt-Smith () e Vincent de Sme () (engenheiro de confiabilidade em ) por ler o artigo e compartilhar informações úteis sobre como funciona a federação.
Fonte: habr.com