Við kynnum skeljarstjóra: að búa til rekstraraðila fyrir Kubernetes er nú orðið auðveldara

Það hafa þegar verið greinar á blogginu okkar þar sem talað er um rekstrarhæfileikar í Kubernetes og hvernig skrifaðu einfaldan rekstraraðila sjálfur. Að þessu sinni viljum við kynna fyrir þér Open Source lausnina okkar, sem tekur stofnun rekstraraðila á mjög auðvelt stig - skoðaðu skel-rekstraraðili!

Hvers vegna?

Hugmyndin um skeljarstjóra er frekar einföld: Gerast áskrifandi að viðburðum frá Kubernetes hlutum og þegar þessir atburðir berast skaltu ræsa utanaðkomandi forrit sem gefur henni upplýsingar um viðburðinn:

Þörfin fyrir það kom upp þegar við rekstur klasa fóru að birtast lítil verkefni sem við vildum endilega gera sjálfvirkan á réttan hátt. Öll þessi litlu verkefni voru leyst með einföldum bash forskriftum, þó eins og þú veist er betra að skrifa rekstraraðila í Golang. Augljóslega væri árangurslaus að fjárfesta í fullri þróun rekstraraðila fyrir hvert svo lítið verkefni.

Rekstraraðili á 15 mínútum

Við skulum skoða dæmi um hvað er hægt að gera sjálfvirkt í Kubernetes klasa og hvernig skeljarstjórinn getur hjálpað. Dæmi væri eftirfarandi: endurtaka leyndarmál til að fá aðgang að bryggjuskránni.

Pods sem nota myndir úr einkaskrá verða að innihalda í upplýsingaskrá sinni hlekk á leyndarmál með gögnum til að fá aðgang að skránni. Þetta leyndarmál verður að búa til í hverju nafnarými áður en þú býrð til belg. Þetta er hægt að gera handvirkt, en ef við setjum upp kraftmikið umhverfi, þá verður nafnrýmið fyrir eitt forrit mikið. Og ef það eru ekki líka 2-3 umsóknir... fjöldi leyndarmála verður mjög mikill. Og eitt í viðbót um leyndarmál: Mig langar að breyta lyklinum til að fá aðgang að skránni af og til. Að lokum, handvirkar aðgerðir sem lausn algjörlega árangurslaus — við þurfum að gera sjálfvirkan sköpun og uppfærslu á leyndarmálum.

Einföld sjálfvirkni

Við skulum skrifa skeljaforskrift sem keyrir einu sinni á N sekúndna fresti og athugar nafnarými fyrir tilvist leyndarmáls, og ef það er ekkert leyndarmál, þá er það búið til. Kosturinn við þessa lausn er að hún lítur út eins og skeljahandrit í cron - klassísk og skiljanleg nálgun fyrir alla. Gallinn er sá að á bilinu á milli kynninga þess er hægt að búa til nýtt nafnrými og í nokkurn tíma mun það vera án leyndarmáls, sem mun leiða til villna við að ræsa belg.

Sjálfvirkni með skel-rekstraraðila

Til að handritið okkar virki rétt, þarf að skipta út klassísku cron-ræsingunni fyrir ræsingu þegar nafnrými er bætt við: í þessu tilviki geturðu búið til leyndarmál áður en þú notar það. Við skulum sjá hvernig á að útfæra þetta með því að nota skel-operator.

Fyrst skulum við líta á handritið. Forskriftir í skel-rekstrarskilmálum eru kallaðir krókar. Hver krókur þegar keyrður er með fána --config upplýsir skeljaraðila um bindingar sínar, þ.e. um hvaða atburði ætti að setja af stað. Í okkar tilviki munum við nota onKubernetesEvent:

#!/bin/bash
if [[ $1 == "--config" ]] ; then
cat <<EOF
{
"onKubernetesEvent": [
  { "kind": "namespace",
    "event":["add"]
  }
]}
EOF
fi

Hér er því lýst að við höfum áhuga á að bæta við viðburðum (add) hlutir af gerðinni namespace.

Nú þarftu að bæta við kóðanum sem verður keyrður þegar atburðurinn á sér stað:

#!/bin/bash
if [[ $1 == "--config" ]] ; then
  # конфигурация
cat <<EOF
{
"onKubernetesEvent": [
{ "kind": "namespace",
  "event":["add"]
}
]}
EOF
else
  # реакция:
  # узнать, какой namespace появился
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  # создать в нём нужный секрет
  kubectl create -n ${createdNamespace} -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  ...
data:
  ...
EOF
fi

Frábært! Útkoman varð lítið, fallegt handrit. Til að „endurlífga“ hana eru tvö skref eftir: undirbúið myndina og ræstu hana í þyrpingunni.

Að undirbúa mynd með krók

Ef þú skoðar handritið geturðu séð að skipanirnar eru notaðar kubectl и jq. Þetta þýðir að myndin verður að hafa eftirfarandi hluti: krókinn okkar, skeljarstjóra sem mun hlusta á atburði og keyra krókinn og skipanirnar sem krókurinn notar (kubectl og jq). Hub.docker.com er nú þegar með tilbúna mynd þar sem shell-operator, kubectl og jq eru pakkaðir. Það eina sem er eftir er að bæta við einföldum krók Dockerfile:

$ cat Dockerfile
FROM flant/shell-operator:v1.0.0-beta.1-alpine3.9
ADD namespace-hook.sh /hooks

$ docker build -t registry.example.com/my-operator:v1 . 
$ docker push registry.example.com/my-operator:v1

Hlaupandi í klasa

Skoðum krókinn aftur og í þetta skiptið skrifum niður hvaða aðgerðir og með hvaða hlutum hann framkvæmir í þyrpingunni:

1. gerist áskrifandi að viðburðum til að búa til nafnrými;
2. býr til leyndarmál í öðrum nafnasvæðum en því þar sem það er opnað.

Það kemur í ljós að belgurinn sem myndin okkar verður sett í verður að hafa leyfi til að gera þessar aðgerðir. Þetta er hægt að gera með því að búa til þinn eigin þjónustureikning. Leyfið verður að vera í formi ClusterRole og ClusterRoleBinding, vegna þess að við höfum áhuga á hlutum úr öllum klasanum.

Lokalýsingin í YAML mun líta einhvern veginn svona út:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: monitor-namespaces-acc

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: monitor-namespaces
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "create", "patch"]

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: monitor-namespaces
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: monitor-namespaces
subjects:
  - kind: ServiceAccount
    name: monitor-namespaces-acc
    namespace: example-monitor-namespaces

Þú getur ræst samansettu myndina sem einfalda dreifingu:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1
      serviceAccountName: monitor-namespaces-acc

Til hægðarauka er sérstakt nafnrými búið til þar sem skeljarforritari verður ræstur og búið til birtingarmyndir:

$ kubectl create ns example-monitor-namespaces
$ kubectl -n example-monitor-namespaces apply -f rbac.yaml
$ kubectl -n example-monitor-namespaces apply -f deployment.yaml

Það er allt: skeljarstjórinn mun byrja, gerast áskrifandi að viðburðum til að búa til nafnrými og keyra krókinn þegar þörf krefur.

Þannig er einfalt skeljahandrit breytt í alvöru rekstraraðila fyrir Kubernetes og starfar sem hluti af klasa. Og allt þetta án flókins ferlis við að þróa rekstraraðila í Golang:

Það er önnur mynd um þetta mál...

Við munum afhjúpa merkingu þess nánar í einu af eftirfarandi ritum.

sía

Það er gott að rekja hluti, en oft þarf að bregðast við að breyta sumum eiginleikum hlutar, til dæmis, til að breyta fjölda eftirmynda í Deployment eða til að breyta hlutmerkjum.

Þegar atburður berst, fær skeljarstjórinn JSON upplýsingaskrá hlutarins. Við getum valið eiginleikana sem vekja áhuga okkar á þessu JSON og keyrt krókinn aðeins þegar þeir breytast. Það er völlur fyrir þetta jqFilter, þar sem þú þarft að tilgreina jq tjáninguna sem verður notuð á JSON upplýsingaskrána.

Til dæmis, til að bregðast við breytingum á merkjum fyrir dreifingarhluti, þarftu að sía reitinn labels út af velli metadata. Stillingin verður svona:

cat <<EOF
{
"onKubernetesEvent": [
{ "kind": "deployment",
  "event":["update"],
  "jqFilter": ".metadata.labels"
}
]}
EOF

Þessi jqFilter tjáning breytir langa JSON upplýsingaskrá Deployment í stuttan JSON með merkimiðum:

shell-operator mun aðeins keyra krókinn þegar þessi stutti JSON breytist og breytingar á öðrum eiginleikum verða hunsaðar.

Hook launch samhengi

Hook config gerir þér kleift að tilgreina nokkra valkosti fyrir viðburði - til dæmis 2 valkosti fyrir viðburði frá Kubernetes og 2 tímaáætlun:

{"onKubernetesEvent":[
  {"name":"OnCreatePod",
  "kind": "pod",
  "event":["add"]
  },
  {"name":"OnModifiedNamespace",
  "kind": "namespace",
  "event":["update"],
  "jqFilter": ".metadata.labels"
  }
],
"schedule": [
{ "name":"every 10 min",
  "crontab":"* */10 * * * *"
}, {"name":"on Mondays at 12:10",
"crontab": "* 10 12 * * 1"
]}

Smá frávik: já, styður skeljarstjóra keyra crontab stíl forskriftir. Nánari upplýsingar er að finna í skjöl.

Til að greina hvers vegna króknum var hleypt af stokkunum, býr skeljarstjórinn til bráðabirgðaskrá og sendir slóðina til hennar í breytu til króksins BINDING_CONTEXT_TYPE. Skráin inniheldur JSON lýsingu á ástæðunni fyrir því að keyra krókinn. Til dæmis, á 10 mínútna fresti mun krókurinn keyra með eftirfarandi efni:

[{ "binding": "every 10 min"}]

... og á mánudaginn byrjar þetta á þessu:

[{ "binding": "every 10 min"}, { "binding": "on Mondays at 12:10"}]

Fyrir onKubernetesEvent Það verða fleiri JSON kallar, vegna þess að það inniheldur lýsingu á hlutnum:

[
 {
 "binding": "onCreatePod",
 "resourceEvent": "add",
 "resourceKind": "pod",
 "resourceName": "foo",
 "resourceNamespace": "bar"
 }
]

Hægt er að skilja innihald reitanna út frá nöfnum þeirra og frekari upplýsingar má lesa í skjöl. Dæmi um að fá auðlindarheiti úr reit resourceName að nota jq hefur þegar verið sýnt í krók sem endurtekur leyndarmál:

jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH

Þú getur fengið aðra reiti á svipaðan hátt.

Hvað er næst?

Í verkefnageymslunni, í /dæmi möppur, það eru dæmi um króka sem eru tilbúnir til að keyra á klasa. Þegar þú skrifar eigin króka geturðu notað þá sem grunn.

Það er stuðningur við að safna mælingum með Prometheus - tiltækum mælingum er lýst í kaflanum MÆLI.

Eins og þú gætir giskað á er skeljarstjórinn skrifaður í Go og dreift með Open Source leyfi (Apache 2.0). Við munum vera þakklát fyrir alla þróunaraðstoð verkefni á GitHub: og stjörnur, og málefni, og draga beiðnir.

Lyftum hulunni af leynd, við munum einnig upplýsa þig um að skel-rekstraraðili er lítið hluti af kerfinu okkar sem getur haldið viðbótum uppsettum í Kubernetes klasanum uppfærðum og framkvæmt ýmsar sjálfvirkar aðgerðir. Lestu meira um þetta kerfi sagði bókstaflega á mánudaginn á HighLoad++ 2019 í St. Pétursborg - við munum brátt birta myndbandið og afrit þessarar skýrslu.

Við erum með áætlun um að opna restina af þessu kerfi: viðbótarstjórnandann og safnið okkar af krókum og einingum. Við the vegur, addon-operator er nú þegar fáanlegt á github, en skjölin fyrir því eru enn á leiðinni. Stefnt er að útgáfu á einingasafni fyrir sumarið.

Haltu áfram!

PS

Lestu líka á blogginu okkar:

• «Rekstraraðilar fyrir Kubernetes: hvernig á að keyra staðbundin forrit»;
• «Að skrifa rekstraraðila fyrir Kubernetes í Golang»;
• «Við kynnum nýja viðbót fyrir Grafana - Statusmap spjaldið»;
• «Við kynnum loghouse - Open Source kerfi til að vinna með logs í Kubernetes»;
• «Við kynnum opinberlega dapp - DevOps tól fyrir CI/CD viðhald'.

Heimild: www.habr.com