Benvingut a la sèrie d'inici ràpid de Kubernetes. Aquesta és una columna habitual amb les preguntes més interessants que rebem en línia i en els nostres entrenaments. Respostes d'experts de Kubernetes.
L'expert d'avui és Daniel Polenchik (). Daniel treballa com a instructor i desenvolupador de programari a .
Si vols una resposta a la teva pregunta a la següent publicació, o .
T'has perdut publicacions anteriors? .
Com connectar els clústers de Kubernetes a diferents centres de dades?
Breument: , i també us aconsello que llegiu и .
Molt sovint, la infraestructura es replica i es distribueix entre diferents regions, especialment en entorns controlats.
Si una regió no està disponible, el trànsit es redirigeix a una altra per evitar interrupcions.
Amb Kubernetes, podeu utilitzar una estratègia similar i distribuir les càrregues de treball a diferents regions.
Podeu tenir un o més clústers per equip, regió, entorn o una combinació d'aquests.
Els vostres clústers es poden allotjar en diversos núvols i locals.
Però, com planificar la infraestructura per a una estesa geogràfica?
Necessites crear un clúster gran per a diversos entorns de núvol en una mateixa xarxa?
O tens molts clústers petits i trobes una manera de controlar-los i sincronitzar-los?
Un grup de lideratge
Crear un clúster en una única xarxa no és tan fàcil.
Imagineu que teniu un accident, la connectivitat entre els segments del clúster es perd.
Si teniu un servidor mestre, la meitat dels recursos no podran rebre ordres noves perquè no podran contactar amb el mestre.
I al mateix temps teniu taules d'encaminament antigues (kube-proxy no se'n poden baixar de nous) i no hi ha pods addicionals (kubelet no pot consultar actualitzacions).
Encara pitjor, si Kubernetes no pot veure un node, el marca com a orfe i distribueix les beines que falten als nodes existents.
Com a resultat, teniu el doble de beines.
Si feu un servidor mestre per regió, hi haurà problemes amb l'algoritme de consens a la base de dades etcd. (aprox. ed. - De fet, la base de dades etcd no s'ha d'ubicar als servidors mestres. Es pot executar en un grup separat de servidors de la mateixa regió. No obstant això, havent rebut al mateix temps un punt de fallada d'un clúster. Però ràpidament.)
usos etcd per posar-se d'acord en un valor abans d'escriure'l al disc.
És a dir, la majoria dels casos han d'arribar a un consens abans que l'estat es pugui escriure a etcd.
Si la latència entre les instàncies d'etcd es dispara, com és el cas de tres instàncies d'etcd a diferents regions, es triga molt de temps a acordar un valor i escriure-lo al disc.
Això també es reflecteix als controladors Kubernetes.
El gestor del controlador necessita més temps per conèixer el canvi i escriure la resposta a la base de dades.
I com que el controlador no és un, sinó diversos, s'obté una reacció en cadena i tot el clúster comença a funcionar molt lentament.
etcd és tan sensible a la latència que .
Actualment no hi ha bons exemples de xarxa gran per a un únic clúster.
Bàsicament, la comunitat de desenvolupadors i el grup de clúster SIG estan intentant esbrinar com organitzar clústers de la mateixa manera que Kubernetes orquestra els contenidors.
Opció 1: federar clústers amb kubefed
Resposta oficial de SIG-cluster - .
Per primera vegada, vam intentar gestionar una col·lecció de clústers com un únic objecte mitjançant l'eina de federació de kube.
El començament va ser bo, però al final, la federació de kube no es va popularitzar, perquè no suportava tots els recursos.
Admetava subministraments i serveis federats, però no StatefulSets, per exemple.
A més, la configuració de la federació es va passar en forma d'anotacions i no era flexible.
Imagineu com podeu descriure la divisió de rèpliques per a cada clúster d'una federació mitjançant una única anotació.
Va resultar ser un embolic complet.
SIG-cluster va fer un gran treball després de kubefed v1 i va decidir abordar el problema des d'un angle diferent.
En lloc d'anotacions, van decidir llançar un controlador instal·lat als clústers. Es pot configurar mitjançant definicions de recursos personalitzades (Custom Resource Definition, CRD).
Per a cada recurs que es federarà, teniu una definició de CRD personalitzada en tres seccions:
- una definició estàndard d'un recurs, com ara desplegar;
- secció
placement, on definiu com es distribuirà el recurs a la federació; - secció
override, on per a un recurs específic podeu anul·lar el pes i els paràmetres de la ubicació.
Aquí teniu un exemple d'un lliurament agrupat amb seccions d'ubicació i anul·lació.
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: 5Com podeu veure, l'oferta es divideix en dos grups: cluster1 и cluster2.
El primer clúster proporciona tres rèpliques i el segon té un valor de 5.
Si necessiteu més control sobre el nombre de rèpliques, kubefed2 proporciona un nou objecte ReplicaSchedulingPreference on les rèpliques es poden ponderar:
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: 2L'estructura CRD i l'API encara no estan a punt, i s'està treballant actiu al repositori oficial del projecte.
Estigueu atents a kubefed2, però tingueu en compte que encara no és prou bo per a un entorn de producció.
Més informació sobre kubefed2 de al blog de Kubernetes i .
Opció 2: agrupar l'estil de Booking.com
Els desenvolupadors de Booking.com no van tractar amb kubefed v2, però van inventar Shipper, un operador per al lliurament en diversos clústers, diverses regions i diversos núvols.
una mica semblant a kubefed2.
Ambdues eines us permeten personalitzar la vostra estratègia de desplegament de diversos clústers (quins clústers s'utilitzen i quantes rèpliques tenen).
Sinó La feina del transportista és reduir el risc d'errors d'enviament.
A Shipper, podeu definir una sèrie de passos que descriuen la divisió de rèpliques entre els desplegaments anteriors i actuals i la quantitat de trànsit entrant.
Quan envieu un recurs a un clúster, el controlador de l'enviament desplega aquest canvi de manera incremental a tots els clústers federats.
També el transportista és molt limitat.
Per exemple, pren com a entrada els gràfics Helm i no admet recursos de vainilla.
En termes generals, el carregador funciona de la següent manera.
En lloc d'una distribució estàndard, heu de crear un recurs d'aplicació que inclogui un gràfic 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 és una bona opció per gestionar diversos clústers, però la seva estreta relació amb Helm només s'interposa.
Què passa si tots canviem de Helm a? o ?
Més informació sobre Shipper i la seva filosofia a .
Si voleu aprofundir en el codi, .
Opció 3: fusió de clúster "màgic".
Kubefed v2 i Shipper treballen amb la federació de clústers proporcionant nous recursos als clústers mitjançant una definició de recursos personalitzada.
Però, què passa si no voleu reescriure tots els subministraments, StatefulSets, DaemonSets, etc. que es fusionin?
Com incloure un clúster existent a la federació sense canviar YAML?
, que s'ocupa de la programació de càrregues de treball en clústers.
Però en lloc d'inventar una nova manera d'interaccionar amb el clúster i embolicar els recursos en definicions personalitzades, el programador de múltiples clústers s'injecta al cicle de vida estàndard de Kubernetes i intercepta totes les trucades que creen pods.
Cada beina creat es substitueix immediatament per un maniquí.
usos del programador de múltiples clústers per interceptar la trucada i crear un pod fictici inactiu.
El pod original passa per un altre cicle de programació on, després d'enquestar a tota la federació, es pren una decisió d'acollida.
Finalment, el pod es lliura al clúster objectiu.
Com a resultat, teniu una beina addicional que no fa res, només ocupa espai.
L'avantatge és que no cal escriure nous recursos per combinar subministraments.
Cada recurs que crea un pod està llest automàticament per ser federat.
Això és interessant, perquè de sobte tens subministraments distribuïts en diverses regions i no te'n vas adonar. Tanmateix, això és força arriscat, perquè aquí tot es basa en la màgia.
Però mentre que l'enviament intenta principalment mitigar els efectes dels enviaments, el programador de múltiples clústers és més general i potser més adequat per a treballs per lots.
No té un mecanisme de lliurament gradual avançat.
Podeu trobar més informació sobre el programador de múltiples clústers a .
Si voleu llegir sobre el programador de múltiples clústers en acció, l'Almirallat ho té - fluxos de treball, esdeveniments, CI i CD Kubernetes.
Altres eines i solucions
Connectar i gestionar diversos clústers és una tasca complexa i no hi ha una solució única.
Si voleu aprendre més sobre aquest tema, aquí teniu alguns recursos:
- és una eina que connecta xarxes superposades de diferents clústers de Kubernetes.
- La cadena minorista Target utilitza .
- Proveu d'utilitzar IPV6 i .
- Podeu utilitzar una malla de servei, per exemple .
- Cilium, un connector d'interfície de xarxa de contenidors, ofereix , que permet combinar diversos clústers
Això és tot per avui
Gràcies per llegir fins al final!
Si sabeu com connectar de manera més eficient diversos clústers, .
Afegirem el vostre mètode als enllaços.
Agraïment especial a Chris Nesbitt-Smith () i Vincent de Sme () (a l'enginyer de fiabilitat a ) per llegir l'article i compartir informació útil sobre com funciona la federació.
Font: www.habr.com