Benvido á nosa serie de inicio rápido de Kubernetes. Esta é unha columna habitual coas preguntas máis interesantes que recibimos en liña e nos nosos adestramentos. Respostas dos expertos de Kubernetes.
O experto de hoxe é Daniel Polenchik (). Daniel traballa como instrutor e desenvolvedor de software en .
Se queres responder á túa pregunta na seguinte publicación, ou .
Perdeches publicacións anteriores? .
Como conectar clústeres de Kubernetes en diferentes centros de datos?
Brevemente: , e tamén recomendo ler sobre и .
Moitas veces, a infraestrutura replícase e distribúese en diferentes rexións, especialmente en ambientes controlados.
Se unha rexión non está dispoñible, o tráfico redirixe a outra para evitar interrupcións.
Con Kubernetes, podes usar unha estratexia similar e distribuír cargas de traballo en diferentes rexións.
Podes ter un ou máis clústeres por equipo, rexión, ambiente ou unha combinación destes elementos.
Os teus clústeres pódense aloxar en diferentes nubes e locais.
Pero, como se planifican as infraestruturas para tal difusión xeográfica?
Necesitas crear un clúster grande para varios ambientes de nube nunha única rede?
Ou tes moitos clústeres pequenos e atopas unha forma de controlalos e sincronizalos?
Un cluster de liderado
Crear un clúster nunha única rede non é tan sinxelo.
Imaxina que tes un accidente, a conectividade entre os segmentos do clúster está perdida.
Se tes un servidor mestre, a metade dos recursos non poderán recibir novos comandos porque non poderán contactar co mestre.
E ao mesmo tempo tes táboas de enrutamento antigas (kube-proxy non pode descargar novos) e non hai pods adicionais (kubelet non pode solicitar actualizacións).
Para empeorar as cousas, se Kubernetes non ve un nodo, márcao como orfo e distribúe os pods que faltan aos nodos existentes.
Como resultado, tes o dobre de vainas.
Se fai un servidor mestre para cada rexión, haberá problemas co algoritmo de consenso na base de datos etcd. (aprox. ed. — De feito, a base de datos etcd non ten que estar necesariamente situada nos servidores mestres. Pódese executar nun grupo separado de servidores da mesma rexión. É certo, ao mesmo tempo conseguir un punto de falla do clúster. Pero rapidamente.)
usos etcd para negociar o valor antes de escribilo no disco.
É dicir, a maioría das instancias deben chegar a un consenso antes de que o estado poida escribirse a etcd.
Se a latencia entre instancias etcd aumenta drasticamente, como é o caso de tres instancias etcd en diferentes rexións, leva moito tempo negociar un valor e escribir no disco.
Isto reflíctese nos controladores Kubernetes.
O xestor do controlador necesita máis tempo para coñecer o cambio e escribir a resposta na base de datos.
E como non hai un controlador, senón varios, resulta unha reacción en cadea e todo o clúster comeza a funcionar moi lentamente.
etcd é tan sensible á latencia que .
Actualmente non hai bos exemplos de rede grande para un único clúster.
Basicamente, a comunidade de desenvolvedores e o grupo de clústeres SIG están tentando descubrir como orquestrar os clústeres do mesmo xeito que Kubernetes organiza os contedores.
Opción 1: federación de clúster con kubefed
Resposta oficial de SIG-cluster - .
Por primeira vez, tentamos xestionar unha colección de clústeres como un único obxecto mediante a ferramenta de federación de kube.
O comezo foi bo, pero ao final a federación kube nunca se popularizou porque non soportaba todos os recursos.
Soportaba entregas e servizos federados, pero non StatefulSets, por exemplo.
Ademais, a configuración da federación transmitíase en forma de anotacións e non era flexible.
Imaxina como poderías describir a partición de réplica para cada clúster nunha federación usando só anotacións.
Foi unha desorde completa.
SIG-cluster traballou moito despois de kubefed v1 e decidiu abordar o problema desde un ángulo diferente.
En lugar de anotacións, decidiron lanzar un controlador que está instalado en clústeres. Pódese personalizar mediante Definicións de recursos personalizadas (CRD).
Para cada recurso que formará parte da federación, tes unha definición de CRD personalizada con tres seccións:
- definición estándar dun recurso, por exemplo despregamento;
- sección
placement, onde se define como se distribuirá o recurso na federación; - sección
override, onde para un recurso específico pode anular o peso e os parámetros da colocación.
Aquí tes un exemplo de entrega combinada con seccións de colocación e anulación.
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 podes ver, a oferta distribúese en dous clústeres: cluster1 и cluster2.
O primeiro clúster ofrece tres réplicas e o segundo está configurado en 5.
Se precisa máis control sobre o número de réplicas, kubefed2 proporciona un novo obxecto ReplicaSchedulingPreference onde se poden ponderar as réplicas:
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 a API aínda non están listas, e está en marcha un traballo activo no repositorio oficial do proxecto.
Manteña un ollo en kubefed2, pero lembre que aínda non é apto para a produción.
Obtén máis información sobre kubefed2 en no blog sobre Kubernetes e en .
Opción 2: combinar clusters ao estilo de Booking.com
Os desenvolvedores de Booking.com non traballaron en kubefed v2, pero pensaron en Shipper, un operador para a entrega en varios clústeres, en varias rexións e en varias nubes.
algo semellante a kubefed2.
Ambas ferramentas permítenche personalizar a túa estratexia de implantación de varios clústeres (que clústeres se utilizan e cantas réplicas teñen).
Pero O obxectivo do remitente é reducir o risco de erros durante a entrega.
En Shipper, pode definir unha serie de pasos que describen a división de réplicas entre a implantación anterior e actual e o volume de tráfico entrante.
Cando empurras un recurso a un clúster, o controlador Shipper implementa gradualmente ese cambio en todos os clústeres unidos.
Ademais, o cargador é moi limitado.
Por exemplo, a acepta gráficos de timón como entrada e non admite recursos de vainilla.
En termos xerais, Shipper funciona así.
En lugar da entrega estándar, cómpre crear un recurso de aplicación que inclúa un 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: 3Shipper é unha boa opción para xestionar varios clústeres, pero a súa estreita relación con Helm só se interpón.
E se todos cambiamos de Helm a ou ?
Obtén máis información sobre Shipper e a súa filosofía en .
Se queres profundizar no código, .
Opción 3: fusión de clúster "máxico".
Kubefed v2 e Shipper traballan coa federación de clústeres, proporcionando novos recursos aos clústeres mediante unha definición de recursos personalizada.
Pero e se non queres reescribir todas as entregas, StatefulSets, DaemonSets, etc. para fusionar?
Como incluír un clúster existente nunha federación sen cambiar YAML?
, que se ocupa da programación de cargas de traballo en clústeres.
Pero en lugar de crear unha nova forma de interactuar co clúster e envolver recursos en definicións personalizadas, o programador de clústeres múltiples está integrado no ciclo de vida estándar de Kubernetes e intercepta todas as chamadas que crean pods.
Cada pod creada substitúese inmediatamente por un maniquí.
usos do programador de múltiples clústeres para interceptar a chamada e crear un pod ficticio inactivo.
O pod orixinal pasa por outro ciclo de planificación onde, despois de consultar a toda a federación, tómase unha decisión de colocación.
Finalmente, o pod entrégase ao clúster de destino.
Como resultado, tes unha vaina extra que non fai nada, só ocupa espazo.
A vantaxe é que non tiñas que escribir novos recursos para combinar materiais.
Cada recurso que crea un pod está automaticamente listo para ser combinado.
Isto é interesante, porque de súpeto tes subministracións distribuídas por varias rexións e nin sequera te decataches. Non obstante, isto é bastante arriscado, porque aquí todo depende da maxia.
Pero aínda que Shipper intenta mitigar principalmente o impacto das entregas, o programador de clusters múltiples xestiona tarefas máis xerais e quizais sexa máis adecuado para traballos por lotes.
Non ten un mecanismo avanzado de entrega gradual.
Podes atopar máis información sobre o programador multi-clúster en .
Se queres ler sobre o programador multi-cluster en acción, o Almirantazgo ten — fluxos de traballo, eventos, CI e CD Kubernetes.
Outras ferramentas e solucións
Conectar e xestionar varios clústeres é unha tarefa complexa e non existe unha solución universal.
Se queres profundizar neste tema, aquí tes algúns recursos:
- é unha ferramenta que conecta redes superpostas de diferentes clústeres de Kubernetes.
- Cadea de venda polo miúdo Usos obxectivos .
- Proba a usar IPV6 e .
- Podes usar unha malla de servizo, por exemplo .
- Cilium, un complemento de interface de rede de contedores, ofrece , que permite combinar varios clusters
Iso é todo por hoxe
Grazas por ler ata o final!
Se sabes como conectar varios clústeres de forma máis eficiente, .
Engadiremos o teu método ás ligazóns.
Agradecemento especial a Chris Nesbitt-Smith () e Vincent de Sme () (enxeñeiro de fiabilidade en ) por ler o artigo e compartir información útil sobre o funcionamento da federación.
Fonte: www.habr.com