Bem-vindo à série de guias rápidos sobre Kubernetes. Esta é uma coluna regular com as questões mais interessantes que recebemos online e em nossos treinamentos. Responde um especialista em Kubernetes.
O especialista de hoje é Daniele Polencic (). Daniele atua como instrutor e desenvolvedor de software na .
Se você deseja que sua pergunta seja respondida no próximo post, ou para .
Perdeu os posts anteriores? .
Como conectar clusters Kubernetes em diferentes data centers?
Resumidamente: , além disso, recomendo ler sobre e .
É bastante comum que a infraestrutura seja replicada e distribuída em diferentes regiões, especialmente em ambientes controlados.
Se uma região ficar indisponível, o tráfego é redirecionado para outra para evitar interrupções.
Com o Kubernetes, é possível usar uma estratégia semelhante e distribuir cargas de trabalho por diferentes regiões.
Você pode ter um ou mais clusters por equipe, região, ambiente ou uma combinação desses elementos.
Seus clusters podem estar hospedados em diferentes nuvens e em ambientes locais.
Mas como planejar a infraestrutura para tal dispersão geográfica?
Deve-se criar um único grande cluster em várias nuvens por uma rede unificada?
Ou ter muitos pequenos clusters e encontrar uma maneira de controlá-los e sincronizá-los?
Um cluster principal
Criar um único cluster em uma rede unificada não é tão simples.
Imagine que você tenha uma falha, a conectividade entre segmentos do cluster foi perdida.
Se você tiver um único servidor mestre, metade dos recursos não conseguirá receber novos comandos, pois não conseguirá se conectar ao mestre.
E, durante isso, você terá tabelas de roteamento antigas (kube-proxy não consegue carregar novas) e nenhum pod adicional (o kubelet não consegue solicitar atualizações).
O que é ainda pior, se o Kubernetes não vê um nó, ele o marca como perdido e redistribui os pods ausentes pelos nós existentes.
No final, você terá 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.Nota do editor — Na verdade, a base de dados etcd não precisa estar necessariamente nos servidores mestres. Ela pode ser executada em um grupo separado de servidores em uma única região. No entanto, isso resulta em um ponto de falha no cluster. Mas é rápido.)
etcd utiliza , para concordar sobre o valor antes de gravá-lo no disco.
Isto é, a maioria das instâncias deve alcançar consenso antes que o estado possa ser gravado no etcd.
Se a latência entre as instâncias do etcd aumentar drasticamente, como no caso de três instâncias do etcd em regiões diferentes, leva muito tempo para concordar sobre o valor e gravá-lo no disco.
Isso também se reflete nos controladores do Kubernetes.
O gerenciador de controladores leva mais tempo para se atualizar sobre a mudança e gravar a resposta no banco de dados.
E como existem vários controladores, isso resulta em 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.
Principalmente, a comunidade de desenvolvedores e o grupo SIG-cluster estão tentando entender como orquestrar clusters da mesma forma que o Kubernetes orquestra contêineres.
Opção 1: federação de clusters com kubefed.
A resposta oficial do SIG-cluster é .
Foi a primeira vez que se tentou gerenciar uma coleção de clusters como um único objeto usando a ferramenta de kube federation.
O começo foi bom, mas no final o kube federation nunca se tornou popular, pois não suportava todos os recursos.
Ele suportava entregas unificadas e serviços, mas, por exemplo, não os StatefulSets.
Além disso, a configuração da federação era transmitida na forma de anotações e carecia de flexibilidade.
Imagine como poderia ser descrever a divisão de réplicas para cada cluster na federação usando apenas anotações.
Resultou em uma completa bagunça.
O SIG-cluster fez um grande trabalho após o kubefed v1 e decidiu abordar o problema de outra forma.
Em vez de anotações, decidiram lançar um controlador, que é instalado nos clusters. Ele pode ser configurado usando definições de recursos personalizados (Custom Resource Definition, CRD).
Para cada recurso que fará parte da federação, você tem uma definição personalizada de CRD composta por três seções:
- definição padrão de recurso, como um deployment;
- 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 sobrescrever o peso e os parâmetros de placement.
Aqui está um exemplo de entrega combinada com as seções placement e override.
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 entrega está distribuída entre dois clusters: cluster1 e cluster2.
O primeiro cluster fornece três réplicas, enquanto o segundo tem o valor definido como 5.
Se você precisar de mais controle sobre o número de réplicas, o kubefed2 oferece um novo objeto ReplicaSchedulingPreference, onde as réplicas podem ser distribuídas conforme o peso:
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 do CRD e do API ainda não está totalmente pronta, e o repositório oficial do projeto está em ativo desenvolvimento.
Fique de olho no kubefed2, mas lembre-se que ele ainda não é adequado para um ambiente de produção.
Saiba mais sobre kubefed2 no no blog sobre Kubernetes e no .
Opção 2: combinação de clusters no estilo Booking.com
Os desenvolvedores do Booking.com não trabalharam no kubefed v2, mas criaram o Shipper - um operador para entrega em múltiplos clusters, em várias regiões e em diversas nuvens.
é um pouco semelhante ao kubefed2.
Ambas as ferramentas permitem configurar a estratégia de deploy em múltiplos clusters (quais clusters são usados e quantas réplicas eles têm).
Mas A tarefa do Shipper é 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 o deployment anterior e o atual, além do volume de tráfego que está entrando.
Quando você envia um recurso para um cluster, o controlador Shipper realiza essa alteração passo a passo em todos os clusters combinados.
Além disso, o Shipper é bastante limitado.
Por exemplo, ele aceita gráficos Helm como entrada. e não suporta recursos vanilla.
Em termos gerais, o Shipper funciona da seguinte maneira.
Em vez da entrega padrão, é necessário criar um recurso de aplicativo que inclua o Helm chart:
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 sua ligação estreita com o Helm apenas atrapalha.
E se todos nós migrássemos do Helm para ou ?
Saiba mais sobre o Shipper e sua filosofia em .
Se você quiser explorar o código, .
Opção 3: a ‘mágica’ junção de clusters
Kubefed v2 e Shipper trabalham com a federação de clusters, fornecendo novos recursos aos clusters por meio de definições de recursos personalizadas.
Mas e se você não quiser reescrever todas as entregas, StatefulSets, DaemonSets, etc., para a junção?
Como incluir um cluster existente na federação sem mudar o YAML?
, que lida com cargas de trabalho de agendamento em clusters.
Mas em vez de criar uma nova maneira de interagir com o cluster e envolver recursos em definições personalizadas, o multi-cluster-scheduler se incorpora ao ciclo de vida padrão do Kubernetes e intercepta todas as chamadas que criam pods.
Cada pod criado é imediatamente substituído por um placeholder.
O multi-cluster-scheduler usa , a fim de interceptar a chamada e criar um pod placeholder ocioso.
O pod original passa por mais um ciclo de agendamento, onde, após consultar toda a federação, é tomada uma decisão sobre o local de colocação.
Finalmente, o pod é entregue no cluster de destino.
No final, você termina com um pod extra que não faz nada, apenas ocupa espaço.
A vantagem é que você não teve que escrever novos recursos para a junção das entregas.
Cada recurso que cria um pod está automaticamente pronto para a junção.
Isso é interessante, pois de repente você tem entregas distribuídas por várias regiões, e nem percebeu. No entanto, isso é bastante arriscado, pois tudo depende da magia.
Mas se o Shipper se esforça principalmente para mitigar as consequências das entregas, o multi-cluster-scheduler desempenha funções mais gerais e, possivelmente, é mais adequado para tarefas em lote.
Ele não possui um mecanismo avançado de entregas graduais.
Você pode saber mais sobre o multi-cluster-scheduler na .
Se você quiser ler sobre o multi-cluster-scheduler em ação, a Admiralty tem um — fluxos de trabalho, eventos, CI e CD do Kubernetes.
Outras ferramentas e soluções
Conectar e gerenciar múltiplos clusters é uma tarefa complexa; não existe uma solução universal.
Se você deseja explorar esse assunto em mais detalhes, aqui estão alguns recursos:
- — uma ferramenta que conecta redes overlay de diferentes clusters Kubernetes.
- A rede de varejo Target utiliza .
- Tente usar IPV6 e .
- Você pode usar uma service mesh, como .
- O Cilium, um plugin de interface de rede para contêineres, oferece , que permite combinar vários clusters.
É isso por hoje.
Obrigado por ler até o final!
Se você souber como conectar vários clusters de forma mais eficaz, .
Adicionaremos seu método aos links.
Agradecimentos especiais a Chris Nesbitt-Smith () e Vincent De Smet () (engenheiro de confiabilidade na ) por ler o artigo e compartilhar informações úteis sobre como a federação funciona.
Fonte: habr.com
