La 8-an de aprilo ĉe la konferenco , kadre de la sekcio "DevOps kaj Operacioj", estis donita raporto "Venigi kaj kompletigi Kubernetes", en kies kreado partoprenis tri dungitoj de la kompanio Flant. En ĝi, ni parolas pri multaj situacioj, en kiuj ni volis pligrandigi kaj kompletigi la kapablojn de Kubernetes, sed por kiuj ni ne trovis pretan kaj simplan solvon. Ni havas la necesajn solvojn en la formo de Open Source projektoj, kaj ĉi tiu parolado ankaŭ estas dediĉita al ili.
Laŭ tradicio, ni ĝojas prezenti (50 minutoj, multe pli informa ol la artikolo) kaj la ĉefa resumo en tekstformo. Iru!
Kerno kaj aldonoj en K8s
Kubernetes ŝanĝas la industrion kaj alirojn al administrado delonge establitaj:
- Dankon al li abstraktaĵoj, ni ne plu funkcias kun konceptoj kiel agordi agordon aŭ ruli komandon (Chef, Ansible...), sed uzas grupigon de ujoj, servoj, ktp.
- Ni povas prepari aplikojn sen pensi pri la nuancoj de la specifa retejo, sur kiu ĝi estos lanĉita: nuda metalo, nubo de unu el la provizantoj, ktp.
- Kun K8s vi neniam estis pli alirebla plej bonaj praktikoj pri organizado de infrastrukturo: skalo-teknikoj, mem-resanigo, misfunkciado, ktp.
Tamen, kompreneble, ĉio ne estas tiel glata: Kubernetes ankaŭ alportis siajn proprajn novajn defiojn.
Kubernetoj ne estas kombinaĵo, kiu solvas ĉiujn problemojn de ĉiuj uzantoj. La kerno Kubernetes respondecas nur pri aro de la minimumaj necesaj funkcioj, kiuj ĉeestas ĉiu areto:
La Kubernetes-kerno difinas bazan aron da primitivuloj por grupigi ujojn, administri trafikon ktp. Ni parolis pri ili pli detale en .
Aliflanke, K8s ofertas grandajn ŝancojn por vastigi la disponeblajn funkciojn, kiuj helpas fermi aliajn - specifa - bezonoj de uzantoj. Aldonoj al Kubernetes estas la respondeco de administrantoj de grapolo, kiuj devas instali kaj agordi ĉion necesan por akiri sian areton "en la ĝusta formo" [por solvi siajn specifajn problemojn]. Kiaj aldonoj estas ĉi tiuj? Ni rigardu kelkajn ekzemplojn.
Ekzemploj de aldonaĵoj
Instalinte Kubernetes, ni eble surprizos, ke la retoj, kiuj estas tiom necesaj por la interago de podoj kaj ene de nodo kaj inter nodoj, ne funkcias per si mem. La Kubernetes-kerno ne garantias la necesajn konektojn; anstataŭe, ĝi determinas la reton interfaco () por triaj aldonaĵoj. Ni devas instali unu el ĉi tiuj aldonaĵoj, kiu respondecos pri la reto-agordo.
Proksima ekzemplo estas datumstokaj solvoj (loka disko, retbloka aparato, Ceph...). Komence ili estis en la kerno, sed kun la alveno la situacio ŝanĝiĝas al io simila al tio jam priskribita: la interfaco estas en Kubernetes, kaj ĝia efektivigo estas en triaj moduloj.
Aliaj ekzemploj inkludas:
- Ingreso-regiloj (vidu ilian recenzon en ).
- :
- estas tuta klaso de aldonaĵoj (kiu inkluzivas la menciitan cert-manaĝeron), ili difinas primitivon(j)n kaj regilon(j)n. La logiko de ilia laboro estas limigita nur de nia imago kaj permesas al ni igi pretajn infrastrukturajn komponantojn (ekzemple DBMS) en primitivaĵojn, kun kiuj estas multe pli facile labori (ol kun aro da ujoj kaj iliaj agordoj). Granda nombro da funkciigistoj estis skribita - eĉ se multaj el ili ankoraŭ ne estas pretaj por produktado, estas nur demando de tempo:
- Metriko - alia ilustraĵo de kiel Kubernetes apartigis la interfacon (Metrics API) de la efektivigo (triaj aldonaĵoj kiel Prometheus-adaptilo, Datadog-cluster-agento...).
- Por monitorado kaj statistiko, kie en la praktiko ne nur necesas , sed ankaŭ kube-state-metrics, node-exporter, ktp.
Kaj ĉi tio ne estas kompleta listo de aldonoj... Ekzemple ĉe la kompanio Flant, kiun ni nuntempe instalas 29 aldonoj (ĉiuj kreas entute 249 Kubernetes-objektojn). Simple dirite, ni ne povas vidi la vivon de areto sen aldonoj.
Aŭtomatigo
Funkciistoj estas dezajnitaj por aŭtomatigi rutinajn operaciojn, kiujn ni renkontas ĉiutage. Jen realaj ekzemploj por kiuj skribi operatoron estus bonega solvo:
- Estas privata (t.e. postulanta ensaluton) registro kun bildoj por la aplikaĵo. Oni supozas, ke al ĉiu podo estas asignita speciala sekreto, kiu permesas aŭtentikigon en la registro. Nia tasko estas certigi, ke ĉi tiu sekreto troviĝas en la nomspaco por ke podoj povu elŝuti bildojn. Povas ekzisti multaj aplikoj (ĉiu el kiuj bezonas sekreton), kaj estas utile ĝisdatigi la sekretojn mem regule, do la opcio meti sekretojn mane estas forigita. Jen kie la operatoro venas al la savo: ni kreas regilon, kiu atendos ke la nomspaco aperos kaj, surbaze de ĉi tiu evento, aldonos sekreton al la nomspaco.
- Lasu defaŭlte aliron de podoj al Interreto estas malpermesita. Sed foje ĝi povas esti postulata: estas logike, ke la alirpermesa mekanismo funkciu simple, sen postuli specifajn kapablojn, ekzemple per la ĉeesto de certa etikedo en la nomspaco. Kiel la funkciigisto povas helpi nin ĉi tie? Regilo estas kreita, kiu atendas ke la etikedo aperos en la nomspaco kaj aldonas la taŭgan politikon por Interreta aliro.
- Simila situacio: supozu, ke ni bezonis aldoni certan , se ĝi havas similan etikedon (kun ia prefikso). La agoj kun la funkciigisto estas evidentaj...
En ajna areto, rutinaj taskoj devas esti solvitaj, kaj dekstre ĉi tio povas esti farita uzante operatorojn.
Resumante ĉiujn priskribitajn rakontojn, ni alvenis al la konkludo, ke por komforta laboro en Kubernetes vi bezonas: A) instali aldonaĵojn, b) evoluigi operatorojn (por solvi ĉiutagajn administrajn taskojn).
Kiel skribi deklaron por Kubernetes?
Ĝenerale, la skemo estas simpla:
... sed poste rezultas ke:
- La Kubernetes API estas sufiĉe ne-triviala afero, kiu bezonas multan tempon por majstri;
- programado ankaŭ ne estas por ĉiuj (la lingvo Go estis elektita kiel la preferata lingvo ĉar ekzistas speciala kadro por ĝi - );
- La situacio estas simila kun la kadro mem.
Funda linio: por skribi regilon (funkciigisto) devas elspezi gravajn rimedojn studi materialon. Ĉi tio estus pravigita por "grandaj" funkciigistoj - ekzemple, por la MySQL DBMS. Sed se ni memoras la ekzemplojn priskribitajn supre (malvolvi sekretojn, aliri podojn al Interreto...), kiujn ni ankaŭ volas ĝuste fari, tiam ni komprenos, ke la elspezita fortostreĉo superpezos la rezulton, kiun ni bezonas nun:
Ĝenerale aperas dilemo: elspezu multajn rimedojn kaj trovu la ĝustan ilon por verki deklarojn, aŭ faru ĝin malmoderne (sed rapide). Por solvi ĝin - por trovi kompromison inter ĉi tiuj ekstremoj - ni kreis nian propran projekton: (vidu ankaŭ lian sur la nabo).
Ŝelo-funkciigisto
Kiel li laboras? La areto havas balgon enhavantan Go-binaron kun ŝel-funkciigisto. Apud li estas aro da hokoj (pli da detaloj pri ili - vidu malsupre). La ŝelo-funkciigisto mem abonas certan okazaĵoj en la Kubernetes API, sur kies okazo ĝi lanĉas la respondajn hokojn.
Kiel la ŝelo-funkciigisto scias kiujn hokojn voki sur kiuj eventoj? Ĉi tiu informo estas transdonita al la ŝel-funkciigisto per la hokoj mem, kaj ili faras ĝin tre simple.
Hoko estas Bash-skripto aŭ ajna alia rulebla dosiero kiu akceptas ununuran argumenton --config kaj respondas per JSON. Ĉi-lasta determinas kiuj objektoj estas interesaj al ĝi kaj al kiuj okazaĵoj (por tiuj objektoj) devus esti responditaj:
Mi ilustros la efektivigon sur la ŝelo-funkciigisto de unu el niaj ekzemploj - malkomponi sekretojn por aliri privatan registron kun aplikaj bildoj. Ĝi konsistas el du etapoj.
Praktiko: 1. Skribu hokon
Antaŭ ĉio, en la hoko ni prilaboros --config, indikante ke ni interesiĝas pri nomspacoj, kaj specife, la momento de ilia kreado:
[[ $1 == "--config" ]] ; then
cat << EOF
{
"onKubernetesEvent": [
{
"kind": "namespace",
"event": ["add"]
}
]
}
EOF
…Kiel aspektus la logiko? Ankaŭ sufiĉe simpla:
…
else
createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi
La unua paŝo estas ekscii, kiu nomspaco estis kreita, kaj la dua estas krei ĝin uzante kubectl sekreta por ĉi tiu nomspaco.
Praktiko: 2. Kunmeti la bildon
Restas nur transdoni la kreitan hokon al la ŝel-funkciigisto - kiel fari tion? La ŝelo-funkciigisto mem venas kiel Docker-bildo, do nia tasko estas aldoni la hokon al speciala dosierujo en ĉi tiu bildo:
FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooksRestas nur kunmeti ĝin kaj puŝi ĝin:
$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1La fina tuŝo estas deploji la bildon al la areto. Por fari tion, ni skribu deplojo:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: my-operator
spec:
template:
spec:
containers:
- name: my-operator
image: registry.example.com/my-operator:v1 # 1
serviceAccountName: my-operator # 2Estas du punktoj por atenti:
- indiko de la nove kreita bildo;
- Ĉi tio estas sistema komponanto kiu (minimume) bezonas rajtojn por aboni eventojn en Kubernetes kaj por asigni sekretojn al nomspacoj, do ni kreas ServiceAccount (kaj reguloj) por la hoko.
Rezulto - ni solvis nian problemon parencoj por Kubernetes en maniero kiu kreas funkciigiston por malkomponi sekretojn.
Aliaj funkcioj de ŝel-funkciigisto
Por limigi la objektojn de via elektita tipo, kun kiuj la hoko funkcios, ili povas esti filtritaj, elektante laŭ certaj etikedoj (aŭ uzante matchExpressions):
"onKubernetesEvent": [
{
"selector": {
"matchLabels": {
"foo": "bar",
},
"matchExpressions": [
{
"key": "allow",
"operation": "In",
"values": ["wan", "warehouse"],
},
],
}
…
}
]Provizita deduplika mekanismo, kiu - uzante jq-filtrilon - ebligas al vi konverti grandajn JSON-objektojn en malgrandajn, kie restas nur tiuj parametroj, kiujn ni volas kontroli por ŝanĝoj.
Kiam hoko estas vokita, la ŝel-funkciigisto pasas ĝin objektodatenoj, kiu povas esti uzata por ajna bezono.
La eventoj kiuj ekigas hokojn ne estas limigitaj al eventoj de Kubernetes: la ŝel-funkciigisto provizas subtenon por vokante hokojn per tempo (simila al crontab en tradicia planilo), same kiel speciala evento onStartup. Ĉiuj ĉi tiuj eventoj povas esti kombinitaj kaj asignitaj al la sama hoko.
Kaj du pliaj trajtoj de la ŝelo-funkciigisto:
- Ĝi funkcias nesinkrone. Ĉar Kubernetes-okazaĵo (kiel ekzemple objekto estanta kreita) estis ricevita, aliaj okazaĵoj (kiel ekzemple la sama objekto estanta forigita) povus esti okazinta en la areto, kaj hokoj devas respondeci pri tio. Se la hoko estis ekzekutita kun eraro, tiam defaŭlte ĝi estos revoko ĝis sukcesa kompletigo (ĉi tiu konduto povas esti ŝanĝita).
- Ĝi eksportas metrikoj por Prometheus, kun kiu vi povas kompreni ĉu la ŝelo-funkciigisto funkcias, eksciu la nombron da eraroj por ĉiu hoko kaj la nuna vostograndeco.
Por resumi ĉi tiun parton de la raporto:
Instalante aldonaĵojn
Por komforta laboro kun Kubernetes, la bezono instali aldonaĵojn ankaŭ estis menciita. Mi rakontos al vi pri ĝi uzante la ekzemplon de la vojo de nia kompanio al kiel ni faras ĝin nun.
Ni komencis labori kun Kubernetes kun pluraj aretoj, kies nura aldono estis Ingress. Ĝi devis esti instalita malsame en ĉiu areto, kaj ni faris plurajn YAML-agordojn por malsamaj medioj: nuda metalo, AWS...
Ĉar estis pli da aretoj, estis pli da agordoj. Krome, ni plibonigis ĉi tiujn agordojn mem, rezulte de kiuj ili iĝis sufiĉe heterogenaj:
Por ordigi ĉion, ni komencis per skripto (install-ingress.sh), kiu prenis kiel argumenton la tipon de areto al kiu ni deplojos, generis la necesan YAML-agordon kaj eligis ĝin al Kubernetes.
Resume, nia plua vojo kaj la rezonado asociita kun ĝi estis jenaj:
- por labori kun YAML-agordoj, ŝablona motoro estas bezonata (en la unuaj etapoj ĉi tio estas simpla sed);
- kun la pliiĝo de la nombro da aretoj, venis la bezono de aŭtomata ĝisdatigo (la plej frua solvo estis meti la skripton en Git, ĝisdatigi ĝin per cron kaj ruli ĝin);
- simila manuskripto estis postulata por Prometeo (
install-prometheus.sh), tamen estas rimarkinda pro tio, ke ĝi postulas multe pli da enig-datumoj, same kiel ilian konservadon (bonmaniere - centralizita kaj en areto), kaj iuj datumoj (pasvortoj) povus esti aŭtomate generitaj: - la risko disvastigi ion malbonan al kreskanta nombro da aretoj konstante kreskis, do ni rimarkis, ke instalistoj (t.e. du manuskriptoj: por Eniro kaj Prometeo) enscenigo estis bezonata (pluraj branĉoj en Git, pluraj kronoj por ĝisdatigi ilin en la respondaj: stabilaj aŭ testaj aretoj);
- с
kubectl applyĝi fariĝis malfacile labori, ĉar ĝi ne estas deklara kaj povas nur krei objektojn, sed ne fari decidojn pri ilia stato/forigi ilin; - Mankis al ni iuj funkcioj, kiujn ni tiam tute ne efektivigis:
- plena kontrolo de la rezulto de grapo-ĝisdatigoj,
- aŭtomata determino de iuj parametroj (enigo por instalaj skriptoj) bazita sur datumoj kiuj povas esti akiritaj de la areto (malkovro),
- ĝia logika evoluo en la formo de daŭra malkovro.
Ni efektivigis ĉi tiun tutan akumulitan sperton kadre de nia alia projekto - .
Aldon-funkciigisto
Ĝi baziĝas sur la jam menciita ŝel-funkciigisto. La tuta sistemo aspektas jene:
La sekvanta estas aldonita al la ŝel-funkciigisto-hokoj:
- stokado de valoroj,
- Helm-diagramo,
- komponanto kiu kontrolas la vendejon de valoroj kaj - en kazo de iuj ŝanĝoj - petas Helm reruligi la diagramon.
Tiel, ni povas reagi al evento en Kubernetes, lanĉi hokon, kaj de ĉi tiu hoko ni povas fari ŝanĝojn al la stokado, post kio la diagramo estos re-elŝutita. En la rezulta diagramo, ni apartigas la aron de hokoj kaj la diagramo en unu komponenton, kiun ni nomas modulo:
Povas esti multaj moduloj, kaj al ili ni aldonas tutmondajn hokojn, tutmondan valorbutikon kaj komponanton, kiu kontrolas ĉi tiun tutmondan vendejon.
Nun, kiam io okazas en Kubernetes, ni povas reagi al ĝi uzante tutmondan hokon kaj ŝanĝi ion en la tutmonda vendejo. Ĉi tiu ŝanĝo estos rimarkita kaj kaŭzos ĉiujn modulojn en la areto esti lanĉitaj:
Ĉi tiu skemo kontentigas ĉiujn postulojn por instali aldonaĵojn, kiuj estis deklaritaj supre:
- Helm respondecas pri ŝablono kaj deklaro.
- La problemo de aŭtomata ĝisdatigo estis solvita per tutmonda hoko, kiu iras al la registro laŭ horaro kaj, se ĝi vidas novan sisteman bildon tie, ruliĝas ĝin (t.e. "mem").
- Stoki agordojn en la areto estas efektivigita uzante ConfigMap, kiu enhavas la primarajn datumojn por la stokaĵoj (ĉe ekfunkciigo ili estas ŝarĝitaj en la stokaĵojn).
- Problemoj kun pasvortgenerado, malkovro kaj kontinua malkovro estis solvitaj per hokoj.
- Enscenigo estas atingita danke al etikedoj, kiujn Docker subtenas el la skatolo.
- La rezulto estas monitorita uzante metrikojn per kiuj ni povas kompreni la statuson.
Ĉi tiu tuta sistemo estas efektivigita en la formo de ununura duuma en Go, kiu estas nomita aldon-funkciigisto. Ĉi tio igas la diagramon aspekti pli simpla:
La ĉefa komponanto en ĉi tiu diagramo estas aro de moduloj (markita en griza malsupre). Nun ni povas skribi modulon por la bezonata aldonaĵo kun iom da peno kaj certigi, ke ĝi estos instalita en ĉiu areto, estos ĝisdatigita kaj respondos al la eventoj kiujn ĝi bezonas en la areto.
"Flant" uzas sur 70+ Kubernetes-aretoj. Nuna stato - alfa versio. Nun ni preparas dokumentaron por liberigi la beta, sed nuntempe en la deponejo , surbaze de kiu vi povas krei vian propran aldonaĵon.
Kie mi povas akiri la modulojn por addon-operator? Eldoni nian bibliotekon estas la sekva etapo por ni; ni planas fari tion somere.
Filmetoj kaj diapozitivoj
Video de la prezentado (~50 minutoj):
Prezento de la raporto:
PS
Aliaj raportoj en nia blogo:
- «»; (Dmitry Stolyarov; la 8-an de novembro 2018 ĉe HighLoad++);
- «»; (Dmitry Stolyarov; la 28-an de majo 2018 ĉe RootConf);
- «»; (Dmitry Stolyarov; la 7-an de novembro 2017 ĉe HighLoad++);
- «»; (Dmitry Stolyarov; junio 6, 2017 ĉe RootConf).
Vi ankaŭ povas interesiĝi pri la jenaj publikaĵoj:
- «".
fonto: www.habr.com