8 april by de konferinsje , as ûnderdiel fan 'e seksje "DevOps and Operations" waard in rapport "Utwreidzjen en oanfolling fan Kubernetes" jûn, yn 'e skepping wêrfan trije meiwurkers fan it Flant-bedriuw dielnimme. Dêryn prate wy oer tal fan situaasjes wêryn wy de mooglikheden fan Kubernetes woenen útwreidzje en oanfolje, mar dêr't wy gjin klearebare en ienfâldige oplossing foar fûnen. Wy hawwe de nedige oplossingen yn 'e foarm fan Open Source-projekten, en dizze taspraak is ek wijd oan har.
Troch tradysje binne wy bliid om te presintearjen (50 minuten, folle mear ynformatyf as it artikel) en de haad gearfetting yn tekstfoarm. Go!
Kearn en tafoegings yn K8s
Kubernetes feroaret de yndustry en oanpak foar administraasje dy't al lang fêstlein binne:
- Mei tank oan him abstraksjes, wurkje wy net mear mei begripen lykas it opsetten fan in konfiguraasje of it útfieren fan in kommando (Chef, Ansible...), mar brûke groepearring fan konteners, tsjinsten, ensfh.
- Wy kinne tariede applikaasjes sûnder tinken oer de nuânses fan de spesifike side, wêrop it sil wurde lansearre: bleat metaal, wolk fan ien fan 'e oanbieders, ensfh.
- Mei K8's hawwe jo noait mear tagonklik west bêste praktiken oer it organisearjen fan ynfrastruktuer: skaalfergruttingstechniken, selshealing, fouttolerânsje, ensfh.
Alles is lykwols net sa glêd: Kubernetes brocht ek har eigen nije útdagings.
Kubernetes net is in kombinearje dy't alle problemen fan alle brûkers oplost. De kearn Kubernetes is allinnich ferantwurdlik foar in set fan de minimale nedige funksjes dy't oanwêzich yn elk kluster:
De Kubernetes-kearn definiearret in basisset fan primitives foar groepearjen fan konteners, behear fan ferkear, ensfh. Wy prate oer harren yn mear detail yn .
Oan 'e oare kant biedt K8's geweldige kânsen om de beskikbere funksjes út te wreidzjen, dy't helpe om oaren te sluten - beskaat - brûker behoeften. Tafoegings oan Kubernetes binne de ferantwurdlikens fan klusterbehearders, dy't alles moatte ynstallearje en konfigurearje om har kluster "yn 'e goede foarm" te krijen [om har spesifike problemen op te lossen]. Wat foar oanfollingen binne dit? Litte wy nei guon foarbylden sjen.
Foarbylden fan tafoegings
Nei it ynstalleare fan Kubernetes, kinne wy fernuverje dat it netwurk dat sa nedich is foar de ynteraksje fan pods sawol binnen in knooppunt as tusken knooppunten net op himsels wurket. De Kubernetes-kernel garandearret de nedige ferbiningen net; ynstee bepaalt it it netwurk de ynterface () foar tafoegings fan tredden. Wy moatte ien fan dizze tafoegings ynstallearje, dy't ferantwurdlik wêze sil foar de netwurkkonfiguraasje.
In nau foarbyld is oplossings foar gegevensopslach (lokale skiif, netwurkblokapparaat, Ceph ...). Ynearsten sieten se yn 'e kearn, mar mei de komst de situaasje feroaret nei wat ferlykber mei dat al beskreaun: de ynterface is yn Kubernetes, en de ymplemintaasje dêrfan is yn modules fan tredden.
Oare foarbylden omfetsje:
- Ingress-controllers (sjoch harren resinsje yn ).
- :
- is in hiele klasse fan tafoegings (dy't de neamde cert-manager omfettet), se definiearje primitive (s) en controller (s). De logika fan har wurk wurdt allinich beheind troch ús ferbylding en lit ús klearmakke ynfrastruktuerkomponinten (bygelyks in DBMS) omsette yn primitiven, dy't folle makliker binne om mei te wurkjen (as mei in set fan konteners en har ynstellingen). In grut oantal operators is skreaun - sels as in protte fan harren noch net klear binne foar produksje, it is mar in kwestje fan tiid:
- Metrics - in oare yllustraasje fan hoe't Kubernetes de ynterface (Metrics API) skiede fan 'e ymplemintaasje (tafoegings fan tredden lykas Prometheus adapter, Datadog cluster agent ...).
- foar tafersjoch en statistyk, dêr't yn 'e praktyk net allinnich nedich binne , mar ek kube-state-metrics, node-eksporteur, ensfh.
En dit is net in folsleine list fan oanfollingen ... Bygelyks, wy by it bedriuw Flant op it stuit ynstallearje 29 oanfollingen (allegear meitsje in totaal fan 249 Kubernetes-objekten). Simpelwei kinne wy it libben fan in kluster net sûnder tafoegings sjen.
Automatisearring
Operators binne ûntworpen om routine operaasjes te automatisearjen dy't wy elke dei tsjinkomme. Hjir binne echte foarbylden wêrfoar it skriuwen fan in operator in poerbêste oplossing soe wêze:
- D'r is in privee (d.w.s. in oanmelding nedich) register mei ôfbyldings foar de applikaasje. It wurdt oannommen dat elke pod in spesjaal geheim wurdt tawiisd dat ferifikaasje yn it register mooglik makket. Us taak is om te soargjen dat dit geheim fûn wurdt yn 'e nammeromte, sadat pods ôfbyldings kinne downloade. D'r kinne in protte applikaasjes wêze (dy't elk in geheim nedich hawwe), en it is handich om de geheimen sels regelmjittich te aktualisearjen, sadat de opsje om geheimen mei de hân út te lizzen is elimineare. Dit is wêr't de operator ta de rêding komt: wy meitsje in kontrôler dy't wachtet oant de nammeromte ferskynt en, basearre op dit barren, in geheim taheakje sil oan 'e nammeromte.
- Lit standert tagong fan pods nei it ynternet is ferbean. Mar soms kin it nedich wêze: it is logysk dat it tagongsrjochtmeganisme gewoan wurket, sûnder spesifike feardichheden te fereaskje, bygelyks troch de oanwêzigens fan in bepaald label yn 'e nammeromte. Hoe kin de operator ús hjir helpe? In kontrôler wurdt makke dy't wachtet op it label om te ferskinen yn 'e nammeromte en foeget it passende belied foar ynternettagong ta.
- In fergelykbere situaasje: stel dat wy in bepaalde taheakje moasten , as it in ferlykber label hat (mei in soarte fan foarheaksel). De aksjes mei de operator binne dúdlik ...
Yn elke kluster moatte routine taken wurde oplost, en rjocht dit kin dien wurde mei help fan operators.
Alle beskreaune ferhalen gearfette, kamen wy ta de konklúzje dat foar noflik wurk yn Kubernetes jo nedich:A) add-ons ynstallearje, b) ûntwikkeljen operators (foar it oplossen fan deistige admintaken).
Hoe skriuw ik in ferklearring foar Kubernetes?
Yn it algemien is it skema ienfâldich:
... mar dan docht bliken dat:
- De Kubernetes API is in nochal net-trivial ding dat in protte tiid nimt om te behearskjen;
- programmearring is ek net foar elkenien (de Go-taal waard keazen as de foarkarstaal, om't der in spesjaal ramt foar is - );
- De situaasje is fergelykber mei it ramt sels.
Bottom line: in kontrôler te skriuwen (operator) moat besteegje wichtige middels materiaal te studearjen. Dit soe terjochte wêze foar "grutte" operators - sis, foar de MySQL DBMS. Mar as wy de hjirboppe beskreaune foarbylden ûnthâlde (geheimen ûntdekke, tagong krije ta pods op it ynternet ...), dy't wy ek goed dwaan wolle, dan sille wy begripe dat de ynspanningen dy't jo bestege, grutter binne as it resultaat dat wy no nedich binne:
Oer it algemien ûntstiet in dilemma: besteegje in soad middels en fyn it goede ark foar it skriuwen fan útspraken, of doch it op de âlderwetske manier (mar fluch). Om it op te lossen - om in kompromis te finen tusken dizze ekstremen - hawwe wy ús eigen projekt makke: (sjoch ek syn op de hub).
Shell-operator
Hoe wurket hy? It kluster hat in pod mei in Go-binêr mei in shell-operator. Njonken him is in set fan heakjes (mear details oer har - sjoch hjirûnder). De shell-operator sels abonnearret op bepaalde eveneminten yn 'e Kubernetes API, op it foarkommen fan dat it lansearret de oerienkommende heakjes.
Hoe wit de shell-operator hokker heakken te belje op hokker eveneminten? Dizze ynformaasje wurdt oerbrocht nei de shell-operator troch de heakjes sels, en se dogge it heul ienfâldich.
In heak is in Bash-skript as in oar útfierber bestân dat ien argumint akseptearret --config en reagearret mei JSON. Dat lêste bepaalt hokker objekten dêrfoar fan belang binne en op hokker eveneminten (foar dizze objekten) reagearre wurde moatte:
Ik sil de ymplemintaasje yllustrearje op 'e shell-operator fan ien fan ús foarbylden - ûntbining fan geheimen foar tagong ta in privee register mei applikaasjeôfbyldings. It bestiet út twa stadia.
Oefenje: 1. Skriuw in heak
Earst fan alles, yn 'e heak sille wy ferwurkje --config, wat oanjout dat wy ynteressearre binne yn nammeromten, en spesifyk, it momint fan har skepping:
[[ $1 == "--config" ]] ; then
cat << EOF
{
"onKubernetesEvent": [
{
"kind": "namespace",
"event": ["add"]
}
]
}
EOF
…Hoe soe de logika der útsjen? Ek frij simpel:
…
else
createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi
De earste stap is om út te finen hokker nammeromte makke is, en de twadde is om it te meitsjen mei help fan kubectl geheim foar dizze nammeromte.
Oefenje: 2. Sammelje de ôfbylding
Alles wat oerbliuwt is de makke heak troch te jaan oan de shell-operator - hoe dit te dwaan? De shell-operator sels komt as in Docker-ôfbylding, dus ús taak is om de hook ta te foegjen oan in spesjale map yn dizze ôfbylding:
FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooksAlles wat oerbliuwt is it te sammeljen en it te triuwen:
$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1De lêste touch is om de ôfbylding yn te setten nei it kluster. Om dit te dwaan, litte wy skriuwe Deployment:
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 # 2Der binne twa punten om omtinken te jaan:
- oantsjutting fan it nij oanmakke byld;
- Dit is in systeemkomponint dat (op syn minst) rjochten nedich hat om te abonnearjen op eveneminten yn Kubernetes en om geheimen oan nammeromten te tawizen, dus meitsje wy in ServiceAccount (en in set regels) foar de heak.
Resultaat - wy hawwe ús probleem oplost sibben foar Kubernetes op in wize dy't skept in operator foar decomposing geheimen.
Oare shell-operator funksjes
Om de objekten fan jo keazen type te beheinen wêrmei de heak sil wurkje, se kinne wurde filtere, selektearjen neffens bepaalde labels (of brûke matchExpressions):
"onKubernetesEvent": [
{
"selector": {
"matchLabels": {
"foo": "bar",
},
"matchExpressions": [
{
"key": "allow",
"operation": "In",
"values": ["wan", "warehouse"],
},
],
}
…
}
]Foarsjoen deduplication meganisme, dy't - mei in jq-filter - jo grutte JSON-objekten omsette kinne yn lytse, wêr't allinich dy parameters oerbliuwe dy't wy kontrolearje wolle op feroaringen.
As in heak neamd wurdt, giet de shell-operator it foarby objekt data, dat kin brûkt wurde foar elke need.
De barrens dy't haken trigger binne net beheind ta Kubernetes-eveneminten: de shell-operator jout stipe foar ropt heakjes troch de tiid (fergelykber mei crontab yn in tradisjonele planner), lykas ek in spesjaal barren onStartup. Al dizze eveneminten kinne wurde kombinearre en tawiisd oan deselde heak.
En noch twa funksjes fan 'e shell-operator:
- It wurket asynchronously. Sûnt in Kubernetes evenemint (lykas in foarwerp wurdt oanmakke) waard ûntfongen, oare eveneminten (lykas itselde foarwerp wurdt wiske) koe hawwe bard yn it kluster, en heakken moatte rekken hâlde mei dit. As de hook waard útfierd mei in flater, dan sil it standert wêze opnij belje oant suksesfolle foltôging (dit gedrach kin feroare wurde).
- It eksportearret metriken foar Prometheus, wêrmei jo kinne begripe oft de shell-operator wurket, fyn út it oantal flaters foar elke heak en de hjoeddeiske wachtrige grutte.
Om dit diel fan it rapport gearfetsje:
Ynstallaasje fan tafoegings
Foar noflik wurk mei Kubernetes waard ek de needsaak om tafoegings te ynstallearjen neamd. Ik sil jo der oer fertelle mei it foarbyld fan it paad fan ús bedriuw nei hoe't wy it no dogge.
Wy begon te wurkjen mei Kubernetes mei ferskate klusters, de ienige oanfolling dêr't Ingress wie. It moast oars wurde ynstalleare yn elk kluster, en wy makken ferskate YAML-konfiguraasjes foar ferskate omjouwings: blank metaal, AWS ...
Om't d'r mear klusters wiene, wiene d'r mear konfiguraasjes. Derneist hawwe wy dizze konfiguraasjes sels ferbettere, wêrtroch't se frij heterogeen waarden:
Om alles op oarder te setten, begûnen wy mei in skript (install-ingress.sh), dy't as argumint naam it type kluster wêryn wy sille ynsette, generearre de nedige YAML-konfiguraasje en rôle it út nei Kubernetes.
Koartsein, ús fierdere paad en de dêrby ferbûne redenearring wiene as folget:
- om te wurkjen mei YAML-konfiguraasjes, is in sjabloanmotor nedich (yn 'e earste fazen is dit ienfâldich sed);
- mei it tanimmen fan it oantal klusters kaam de needsaak foar automatyske bywurking (de ierste oplossing wie om it skript yn Git te setten, it te aktualisearjen mei cron en it út te fieren);
- in ferlykber skript wie nedich foar Prometheus (
install-prometheus.sh), it is lykwols opmerklik foar it feit dat it folle mear ynfiergegevens fereasket, lykas har opslach (op in goede manier - sintralisearre en yn in kluster), en guon gegevens (wachtwurden) kinne automatysk oanmakke wurde: - it risiko om wat ferkeard út te rôljen nei in groeiend oantal klusters groeide konstant, dat wy realisearren dat ynstallateurs (dat wol sizze twa skripts: foar Ingress en Prometheus) staging wie nedich (ferskate tûken yn Git, ferskate crons om se te aktualisearjen yn 'e oerienkommende: stabile of testklusters);
- с
kubectl applyit is lestich wurden om mei te wurkjen, om't it net deklaratyf is en allinich objekten meitsje kin, mar gjin besluten nimme oer har status / se wiskje; - Wy misten guon funksjes dy't wy op dat stuit hielendal net hienen ymplementearre:
- folsleine kontrôle oer it resultaat fan klusterupdates,
- automatyske bepaling fan guon parameters (ynfier foar ynstallaasjeskripts) basearre op gegevens dy't kinne wurde krigen fan it kluster (ûntdekking),
- syn logyske ûntwikkeling yn 'e foarm fan trochgeande ûntdekking.
Wy implementearre al dizze opboude ûnderfining yn it ramt fan ús oare projekt - .
Addon-operator
It is basearre op de al neamde shell-operator. It hiele systeem sjocht der sa út:
It folgjende wurdt tafoege oan 'e shell-operatorhaken:
- wearden opslach,
- Helm chart,
- komponint dat kontrolearret de weardenwinkel en - yn gefal fan feroarings - freget Helm om de kaart opnij te rôljen.
Sa kinne wy reagearje op in evenemint yn Kubernetes, in hook lansearje, en fan dizze hook kinne wy wizigingen oanmeitsje oan 'e opslach, wêrnei't de kaart opnij wurdt ynladen. Yn it resultearjende diagram skiede wy de set fan haken en de kaart yn ien komponint, dy't wy neame module:
D'r kinne in protte modules wêze, en oan har foegje wy globale heakjes ta, in wrâldwide weardenwinkel, en in komponint dat dizze wrâldwide winkel kontrolearret.
No, as der wat bart yn Kubernetes, kinne wy derop reagearje mei in wrâldwide hook en wat feroarje yn 'e wrâldwide winkel. Dizze wiziging sil opmurken wurde en soarget derfoar dat alle modules yn it kluster útrol wurde:
Dit skema foldocht oan alle easken foar it ynstallearjen fan tafoegings dy't hjirboppe neamd binne:
- Helm is ferantwurdlik foar sjabloanen en declarativeness.
- It probleem fan auto-update waard oplost mei in globale hook, dy't op in skema nei it register giet en, as it dêr in nije systeemôfbylding sjocht, it útrôlet (dus "sels").
- It opslaan fan ynstellings yn it kluster wurdt ymplementearre mei ConfigMap, dy't de primêre gegevens foar de opslach befettet (by it opstarten wurde se yn 'e opslach laden).
- Problemen mei wachtwurd generaasje, ûntdekking en trochgeande ûntdekking waarden oplost mei help fan heakjes.
- Staging wurdt berikt troch tags, dy't Docker út 'e doaze stipet.
- It resultaat wurdt kontrolearre mei metriken wêrmei't wy de status kinne begripe.
Dit hiele systeem wurdt ymplementearre yn 'e foarm fan ien binêr yn Go, dy't addon-operator neamd wurdt. Dit makket it diagram ienfâldiger te sjen:
De wichtichste komponint yn dit diagram is in set fan modules (ûnder yn griis markearre). No kinne wy skriuwe in module foar de fereaske tafoeging mei in bytsje ynspanning en der wis fan wêze dat it wurdt ynstallearre yn elk kluster, sil bywurke wurde en reagearje op de eveneminten dy't it nedich is yn it kluster.
"Flant" brûkt op 70+ Kubernetes-klusters. Aktuele status - alpha ferzje. No meitsje wy dokumintaasje foar om de beta frij te litten, mar foar no yn 'e repository , op basis wêrfan jo jo eigen addon kinne oanmeitsje.
Wêr kin ik de modules krije foar addon-operator? It publisearjen fan ús bibleteek is de folgjende etappe foar ús; wy binne fan plan dit yn 'e simmer te dwaan.
Fideo's en dia's
Fideo fan 'e foarstelling (~ 50 minuten):
Presintaasje fan it rapport:
PS
Oare rapporten op ús blog:
- «"; (Dmitry Stolyarov; 8 novimber 2018 op HighLoad++);
- «"; (Dmitry Stolyarov; 28 maaie 2018 by RootConf);
- «"; (Dmitry Stolyarov; 7 novimber 2017 op HighLoad++);
- «"; (Dmitry Stolyarov; 6 juny 2017 by RootConf).
Jo kinne ek ynteressearre wêze yn de folgjende publikaasjes:
- «".
Boarne: www.habr.com