🥇Ընդարձակում և լրացնում է Kubernetes-ը (վերանայում և վիդեո զեկույց)

ապրիլի 8-ին համաժողովում Saint HighLoad++ 2019 թ, որպես «DevOps և Operations» բաժնի մաս, տրվեց «Ընդլայնելով և լրացնելով Kubernetes» զեկույցը, որի ստեղծմանը մասնակցել են Flant ընկերության երեք աշխատակիցներ։ Դրանում մենք խոսում ենք բազմաթիվ իրավիճակների մասին, որոնցում մենք ցանկանում էինք ընդլայնել և լրացնել Kubernetes-ի հնարավորությունները, բայց որոնց համար պատրաստ ու պարզ լուծում չգտանք։ Մենք ունենք անհրաժեշտ լուծումները՝ բաց կոդով նախագծերի տեսքով, և այս ելույթը նույնպես նվիրված է դրանց։

Ավանդույթի համաձայն մենք ուրախ ենք ներկայացնել զեկույցի տեսանյութը (50 րոպե, շատ ավելի տեղեկատվական, քան հոդվածը) և հիմնական ամփոփումը տեքստային տեսքով: Գնա՛

Հիմնական և լրացումներ K8-ում

Kubernetes-ը փոխում է արդյունաբերությունը և կառավարման մոտեցումները, որոնք վաղուց հաստատված են.

Նրա շնորհիվ աբստրակցիաներ, մենք այլևս չենք աշխատում այնպիսի հասկացություններով, ինչպիսիք են կոնֆիգուրացիայի կարգավորումը կամ հրամանի գործարկումը (Chef, Ansible...), այլ օգտագործում ենք կոնտեյներների, ծառայությունների խմբավորում և այլն։
Մենք կարող ենք հայտեր պատրաստել՝ չմտածելով դրա նրբությունների մասին կոնկրետ կայք, որի վրա այն կգործարկվի՝ մերկ մետաղ, պրովայդերներից մեկի ամպ և այլն։
K8-ներով դուք երբեք ավելի հասանելի չեք եղել լավագույն պրակտիկա ենթակառուցվածքների կազմակերպման վերաբերյալ՝ մասշտաբային տեխնիկա, ինքնաբուժում, սխալների հանդուրժողականություն և այլն:

Սակայն, իհարկե, ամեն ինչ այնքան էլ հարթ չէ. Kubernetes-ը նույնպես իր նոր մարտահրավերները բերեց։

Կուբերնետես ոչ կոմբայն է, որը լուծում է բոլոր օգտագործողների բոլոր խնդիրները: Kernel Kubernetes-ը պատասխանատու է միայն նվազագույն անհրաժեշտ գործառույթների համար, որոնք առկա են բոլորին կլաստեր:

Kubernetes միջուկը սահմանում է պրիմիտիվների հիմնական հավաքածու՝ կոնտեյներների խմբավորման, երթևեկության կառավարման և այլնի համար: Դրանց մասին ավելի մանրամասն անդրադարձել ենք այստեղ հաշվետվություն 2 տարի առաջ.

Մյուս կողմից, K8s-ը մեծ հնարավորություններ է տալիս ընդլայնելու առկա գործառույթները, որոնք օգնում են փակել մյուսները. կոնկրետ - օգտագործողի կարիքները: Kubernetes-ում լրացումները կրում են կլաստերի ադմինիստրատորների պատասխանատվությունը, որոնք պետք է տեղադրեն և կազմաձևեն այն ամենը, ինչ անհրաժեշտ է իրենց կլաստերը «ճիշտ ձևի» բերելու համար [իրենց կոնկրետ խնդիրները լուծելու համար]: Ինչպիսի՞ լրացումներ են դրանք: Դիտարկենք մի քանի օրինակ։

Հավելումների օրինակներ

Տեղադրելով Kubernetes-ը, մենք կարող ենք զարմանալ, որ ցանցը, որն այդքան անհրաժեշտ է հանգույցների փոխազդեցության համար ինչպես հանգույցի, այնպես էլ հանգույցների միջև, ինքնուրույն չի աշխատում: Kubernetes միջուկը չի երաշխավորում անհրաժեշտ կապերը, փոխարենը որոշում է ցանցը ինտերֆեյս (CNI) երրորդ կողմի հավելումների համար: Մենք պետք է տեղադրենք այս հավելումներից մեկը, որը պատասխանատու կլինի ցանցի կազմաձևման համար։

Մոտ օրինակ են տվյալների պահպանման լուծումները (տեղական սկավառակ, ցանցային բլոկ սարք, Ceph...): Ի սկզբանե դրանք եղել են առանցքում, բայց գալուստով CSI- ն Իրավիճակը փոխվում է արդեն նկարագրվածի նման. ինտերֆեյսը գտնվում է Kubernetes-ում, և դրա իրականացումը երրորդ կողմի մոդուլներում է:

Այլ օրինակներ ներառում են.

Մուտք- կարգավորիչներ (տես դրանց ակնարկը մեր վերջին հոդվածը).
սերտիֆիկ-մենեջեր:
Օպերատորներ հավելումների մի ամբողջ դաս է (որը ներառում է նշված սերտ-մենեջերը), դրանք սահմանում են պարզունակ(ներ) և վերահսկիչ(ներ): Նրանց աշխատանքի տրամաբանությունը սահմանափակվում է միայն մեր երևակայությամբ և թույլ է տալիս պատրաստի ենթակառուցվածքային բաղադրիչները (օրինակ՝ DBMS) վերածել պարզունակների, որոնց հետ աշխատելը շատ ավելի հեշտ է (քան մի շարք կոնտեյներների և դրանց կարգավորումների հետ): Գրվել են հսկայական թվով օպերատորներ, նույնիսկ եթե նրանցից շատերը դեռ պատրաստ չեն արտադրությանը, դա միայն ժամանակի հարց է.
Չափումներ - ևս մեկ օրինակ, թե ինչպես Kubernetes-ը առանձնացրեց միջերեսը (Metrics API) իրականացումից (երրորդ կողմի հավելումներ, ինչպիսիք են Prometheus ադապտեր, Datadog կլաստերի գործակալ...):
Համար մոնիտորինգ և վիճակագրություն, որտեղ գործնականում ոչ միայն անհրաժեշտ են Պրոմեթևս և Գրաֆանա, այլեւ kube-state-metrics, node-exporter եւ այլն։

Եվ սա լրացումների ամբողջական ցանկը չէ... Օրինակ, ներկայումս մեր տեղադրած Ֆլանտ ընկերությունում 29 լրացում (որոնք բոլորն էլ ստեղծում են ընդհանուր առմամբ 249 Kubernetes օբյեկտ): Պարզ ասած, մենք չենք կարող տեսնել կլաստերի կյանքը առանց հավելումների:

Ավտոմատ

Օպերատորները նախագծված են ավտոմատացնելու սովորական գործողությունները, որոնց մենք հանդիպում ենք ամեն օր: Ահա իրական օրինակներ, որոնց համար օպերատոր գրելը հիանալի լուծում կլինի.

Հավելվածի համար կա մասնավոր (այսինքն՝ մուտք գործելու համար պահանջվող) ռեեստր՝ պատկերներով: Ենթադրվում է, որ յուրաքանչյուր pod-ին հատկացվում է հատուկ գաղտնիք, որը թույլ է տալիս նույնականացում գրանցամատյանում: Մեր խնդիրն է ապահովել, որ այս գաղտնիքը գտնվի անվանատարածքում, որպեսզի պատյանները կարողանան նկարներ ներբեռնել: Կարող են լինել շատ հավելվածներ (որոնցից յուրաքանչյուրին անհրաժեշտ է գաղտնիք), և օգտակար է պարբերաբար թարմացնել գաղտնիքները, այնպես որ գաղտնիքները ձեռքով դնելու տարբերակը բացառվում է: Այստեղ է, որ օգնության է հասնում օպերատորը՝ մենք ստեղծում ենք վերահսկիչ, որը կսպասի անվանատարածքի հայտնվելուն և այս իրադարձության հիման վրա գաղտնիք կավելացնի անվանատարածքում։
Թույլ տվեք, որ լռելյայն մուտքը պատյաններից դեպի ինտերնետ արգելված է: Բայց երբեմն դա կարող է պահանջվել. տրամաբանական է, որ մուտքի թույլտվության մեխանիզմը աշխատի պարզապես՝ առանց հատուկ հմտություններ պահանջելու, օրինակ՝ անվանման տարածքում որոշակի պիտակի առկայությամբ: Ինչպե՞ս կարող է օպերատորը օգնել մեզ այստեղ: Ստեղծվում է կարգավորիչ, որը սպասում է, որ պիտակը հայտնվի անվանատարածքում և ավելացնում է ինտերնետ հասանելիության համապատասխան քաղաքականությունը:
Նմանատիպ իրավիճակ. ենթադրենք, որ անհրաժեշտ էր ավելացնել որոշակի աղտոտել, եթե այն ունի նմանատիպ պիտակ (ինչ-որ նախածանցով): Օպերատորի հետ գործողություններն ակնհայտ են...

Ցանկացած կլաստերում սովորական առաջադրանքները պետք է լուծվեն, և ճիշտ դա կարելի է անել օպերատորների միջոցով:

Ամփոփելով նկարագրված բոլոր պատմությունները՝ եկանք այն եզրակացության, որ Kubernetes-ում հարմարավետ աշխատանքի համար ձեզ անհրաժեշտ է: Ա) տեղադրել հավելումներ, բ) զարգացնել օպերատորներ (Ադմինիստրատորի ամենօրյա առաջադրանքները լուծելու համար):

Ինչպե՞ս գրել հայտարարություն Kubernetes-ի համար:

Ընդհանուր առմամբ, սխեման պարզ է.

... բայց հետո պարզվում է, որ.

Kubernetes API-ն բավականին աննշան բան է, որը տիրապետելու համար շատ ժամանակ է պահանջում.
ծրագրավորումը նույնպես բոլորի համար չէ (Go լեզուն ընտրվել է որպես նախընտրելի լեզու, քանի որ դրա համար կա հատուկ շրջանակ. Օպերատոր SDK);
Իրավիճակը նման է հենց շրջանակի հետ:

Ներքեւի տողը: կարգավորիչ գրելու համար (օպերատորը) պետք է ծախսել զգալի ռեսուրսներ ուսումնասիրել նյութը. Սա արդարացված կլինի «խոշոր» օպերատորների համար, ասենք, MySQL DBMS-ի համար: Բայց եթե հիշենք վերը նկարագրված օրինակները (գաղտնիքների բացահայտում, ինտերնետ կապի հասանելիություն...), որը մենք նույնպես ցանկանում ենք ճիշտ անել, ապա կհասկանանք, որ ծախսած ջանքերը կգերազանցեն մեզ հիմա անհրաժեշտ արդյունքը.

Ընդհանրապես երկընտրանք է առաջանում՝ ծախսել մեծ ռեսուրսներ և գտնել հայտարարություններ գրելու ճիշտ գործիք, կամ դա անել հնաոճ ձևով (բայց արագ): Այն լուծելու համար՝ այս ծայրահեղությունների միջև փոխզիջում գտնելու համար, մենք ստեղծեցինք մեր նախագիծը. shell-օպերատոր (տես նաև նրա վերջին հայտարարությունը հանգույցի վրա).

Shell-օպերատոր

Ինչպե՞ս է նա աշխատում: Կլաստերն ունի պատիճ, որը պարունակում է Go երկուական՝ shell-օպերատորով: Նրա կողքին մի շարք է կեռիկներ (ավելի մանրամասն դրանց մասին - տես ստորև). Shell-օպերատորն ինքն է բաժանորդագրվում որոշակի զարգացումները Kubernetes API-ում, որի առաջացման դեպքում այն գործարկում է համապատասխան կեռիկներ:

Ինչպե՞ս է shell-օպերատորը գիտի, թե որ կեռիկներն ինչ իրադարձությունների վրա պետք է կանչի: Այս տեղեկատվությունը կեղևի օպերատորին փոխանցում են հենց իրենք՝ կեռիկները, և նրանք դա անում են շատ պարզ։

Կեռիկը Bash սցենար է կամ ցանկացած այլ գործարկվող ֆայլ, որն ընդունում է մեկ փաստարկ --config և պատասխանում է JSON-ով: Վերջինս որոշում է, թե որ օբյեկտներն են իրեն հետաքրքրում, և որ իրադարձություններին (այս օբյեկտների համար) պետք է արձագանքել.

Ես կպատկերացնեմ մեր օրինակներից մեկի շելլ-օպերատորի վրա իրականացումը. Այն բաղկացած է երկու փուլից.

Պրակտիկա. 1. Գրիր կարթ

Առաջին հերթին, կեռիկի մեջ մենք կմշակենք --config, նշելով, որ մեզ հետաքրքրում են անունների տարածքները, և մասնավորապես՝ դրանց ստեղծման պահը.

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

Ինչպիսի՞ն կլիներ տրամաբանությունը: Նաև բավականին պարզ.

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

Առաջին քայլը պարզելն է, թե որ անվանատարածքը ստեղծվել է, իսկ երկրորդը` օգտագործելով այն kubectl գաղտնիք այս անվանատարածքի համար:

Պրակտիկա՝ 2. Պատկերի հավաքում

Մնում է միայն ստեղծված կեռիկը փոխանցել shell-օպերատորին. ինչպե՞ս դա անել: Shell-օպերատորն ինքնին գալիս է որպես Docker պատկեր, ուստի մեր խնդիրն է այս պատկերի հատուկ գրացուցակում ավելացնել կեռիկը.

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

Մնում է միայն այն հավաքել և հրել.

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

Վերջին հպումն այն է, որ պատկերը տեղակայվի կլաստերի վրա: Դա անելու համար եկեք գրենք տեղակայումը:

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              # 2

Երկու կետ կա, որին պետք է ուշադրություն դարձնել.

նորաստեղծ պատկերի նշում;
Սա համակարգի բաղադրիչ է, որին (առնվազն) պետք են իրավունքներ՝ բաժանորդագրվելու Kubernetes-ի իրադարձություններին և գաղտնիքներ հատկացնելու անունների տարածքներին, այնպես որ մենք ստեղծում ենք Service Account (և մի շարք կանոններ) կեռիկի համար:

Արդյունք - մենք լուծեցինք մեր խնդիրը հարազատները Kubernetes-ի համար այնպես, որ ստեղծում է գաղտնիքների քայքայման օպերատոր:

Shell-օպերատորի այլ առանձնահատկություններ

Ձեր ընտրած տեսակի օբյեկտները սահմանափակելու համար, որոնց հետ կեռիկը կաշխատի, դրանք կարող են զտվել, ընտրելով ըստ որոշակի պիտակների (կամ օգտագործելով matchExpressions):

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

Տրամադրված է կրկնօրինակման մեխանիզմ, որը, օգտագործելով jq ֆիլտրը, թույլ է տալիս փոխակերպել մեծ JSON օբյեկտները փոքրերի, որտեղ մնում են միայն այն պարամետրերը, որոնք մենք ցանկանում ենք վերահսկել փոփոխությունների համար:

Երբ կեռիկը կանչվում է, shell-օպերատորը փոխանցում է այն օբյեկտի տվյալներ, որը կարող է օգտագործվել ցանկացած կարիքի համար։

Կեռիկներ հրահրող իրադարձությունները չեն սահմանափակվում միայն Kubernetes-ի իրադարձություններով. shell-օպերատորն ապահովում է աջակցություն ժամանակով կեռիկներ կանչելը (նման է crontab-ին ավանդական ժամանակացույցում), ինչպես նաև հատուկ իրադարձություն onStartup. Այս բոլոր իրադարձությունները կարող են համակցվել և վերագրվել նույն կարթին:

Եվ shell-օպերատորի ևս երկու առանձնահատկություն.

Աշխատում է ասինխրոն կերպով. Քանի որ ստացվել է Kubernetes իրադարձություն (օրինակ՝ ստեղծվող օբյեկտ), այլ իրադարձություններ (օրինակ՝ նույն օբյեկտի ջնջումը) կարող էին տեղի ունենալ կլաստերում, և կեռիկները պետք է հաշվի առնեն դա: Եթե կեռիկը կատարվել է սխալմամբ, ապա լռելյայն դա կլինի նորից կանչել մինչև հաջող ավարտը (այս վարքագիծը կարող է փոխվել):
Արտահանում է չափումներ Պրոմեթևսի համար, որի հետ դուք կարող եք հասկանալ, թե արդյոք shell-օպերատորն աշխատում է, պարզել սխալների քանակը յուրաքանչյուր կեռիկի համար և ընթացիկ հերթի չափը:

Զեկույցի այս հատվածն ամփոփելու համար.

Հավելումների տեղադրում

Kubernetes-ի հետ հարմարավետ աշխատանքի համար նշվել է նաեւ հավելումներ տեղադրելու անհրաժեշտությունը։ Ես ձեզ կասեմ դրա մասին՝ օգտագործելով մեր ընկերության ուղու օրինակը, թե ինչպես ենք մենք դա անում հիմա:

Մենք սկսեցինք աշխատել Kubernetes-ի հետ մի քանի կլաստերներով, որոնց միակ լրացումը Ingress-ն էր։ Այն պետք է տարբեր կերպ տեղադրվեր յուրաքանչյուր կլաստերում, և մենք մի քանի YAML կոնֆիգուրացիաներ արեցինք տարբեր միջավայրերի համար՝ մերկ մետաղ, AWS...

Քանի որ ավելի շատ կլաստերներ կային, ավելի շատ կոնֆիգուրացիաներ կային: Բացի այդ, մենք ինքներս բարելավեցինք այս կոնֆիգուրացիաները, ինչի արդյունքում դրանք դարձան բավականին տարասեռ.

Ամեն ինչ կարգի բերելու համար մենք սկսեցինք սցենարով (install-ingress.sh), որը որպես փաստարկ վերցրեց կլաստերի տեսակը, որի վրա մենք կտեղակայենք, ստեղծեց անհրաժեշտ YAML կոնֆիգուրացիան և այն փոխանցեց Kubernetes-ին:

Մի խոսքով, մեր հետագա ուղին և դրա հետ կապված հիմնավորումները հետևյալն էին.

YAML կոնֆիգուրացիաների հետ աշխատելու համար անհրաժեշտ է կաղապարային շարժիչ (առաջին փուլերում սա պարզ sed է);
կլաստերների քանակի աճով առաջացավ ավտոմատ թարմացման անհրաժեշտություն (ամենավաղ լուծումը սկրիպտը Git-ում դնելն էր, այն թարմացնելը cron-ի միջոցով և գործարկել);
Նմանատիպ սցենար պահանջվում էր Պրոմեթևսի համար (install-prometheus.sh), այնուամենայնիվ, հատկանշական է նրանով, որ այն պահանջում է շատ ավելի շատ մուտքային տվյալներ, ինչպես նաև դրանց պահպանում (լավ իմաստով՝ կենտրոնացված և կլաստերային), և որոշ տվյալներ (գաղտնաբառեր) կարող են ավտոմատ կերպով ստեղծվել.
աճող թվով կլաստերներում ինչ-որ սխալ բան տարածելու ռիսկը անընդհատ աճում էր, ուստի մենք հասկացանք, որ տեղադրողները (այսինքն երկու սցենար. Ingress-ի և Prometheus-ի համար) անհրաժեշտ էր բեմականացում (մի քանի ճյուղ Git-ում, մի քանի քրոն՝ դրանք թարմացնելու համար՝ կայուն կամ թեստային կլաստերներ);
с kubectl apply դրա հետ աշխատելը դժվարացել է, քանի որ այն դեկլարատիվ չէ և կարող է միայն օբյեկտներ ստեղծել, բայց դրանց կարգավիճակի վերաբերյալ որոշումներ կայացնել/ջնջել;
Մեզ պակասում էին որոշ գործառույթներ, որոնք այն ժամանակ ընդհանրապես չէինք իրականացրել.
- լիակատար վերահսկողություն կլաստերի թարմացումների արդյունքի վրա,
- որոշ պարամետրերի ավտոմատ որոշում (տեղադրման սկրիպտների մուտքագրում) տվյալների հիման վրա, որոնք կարելի է ստանալ կլաստերից (հայտնաբերում),
- դրա տրամաբանական զարգացումը շարունակական բացահայտման տեսքով։

Այս ամբողջ կուտակված փորձը մենք իրականացրել ենք մեր մյուս նախագծի շրջանակներում՝ հավելում-օպերատոր.

Addon-օպերատոր

Այն հիմնված է արդեն նշված shell-օպերատորի վրա։ Ամբողջ համակարգը այսպիսի տեսք ունի.

Կեղևի օպերատորի կեռիկներին ավելացվում է հետևյալը.

արժեքների պահպանում,
Սաղավարտի աղյուսակ,
բաղադրիչ, որը վերահսկում է արժեքների պահեստը և ցանկացած փոփոխության դեպքում Հելմին խնդրում է նորից գլորել աղյուսակը:

Այսպիսով, մենք կարող ենք արձագանքել Kubernetes-ում որևէ իրադարձության, գործարկել կեռիկ, և այս կեռիկից մենք կարող ենք փոփոխություններ կատարել պահեստում, որից հետո գծապատկերը նորից կներբեռնվի: Ստացված գծապատկերում մենք առանձնացնում ենք կեռիկների հավաքածուն և աղյուսակը մեկ բաղադրիչի մեջ, որը մենք անվանում ենք մոդուլ:

Կարող են լինել շատ մոդուլներ, և դրանց մենք ավելացնում ենք գլոբալ կեռիկներ, գլոբալ արժեքների խանութ և բաղադրիչ, որը վերահսկում է այս գլոբալ խանութը:

Այժմ, երբ ինչ-որ բան տեղի է ունենում Kubernetes-ում, մենք կարող ենք դրան արձագանքել՝ օգտագործելով գլոբալ կեռիկ և ինչ-որ բան փոխել գլոբալ խանութում: Այս փոփոխությունը կնկատվի և կհանգեցնի, որ կլաստերի բոլոր մոդուլները դուրս կգան.

Այս սխեման բավարարում է վերը նշված հավելումների տեղադրման բոլոր պահանջները.

Helm-ը պատասխանատու է ձևանմուշի և դեկլարատիվության համար:
Ավտոմատ թարմացման խնդիրը լուծվել է գլոբալ կեռիկի միջոցով, որը ժամանակացույցով գնում է գրանցամատյան և, եթե այնտեղ տեսնում է համակարգի նոր պատկեր, այն դուրս է հանում (այսինքն՝ «ինքն իրեն»):
Կլաստերում կարգավորումների պահպանումն իրականացվում է օգտագործելով ConfigMap, որը պարունակում է պահեստների առաջնային տվյալները (գործարկման ժամանակ դրանք բեռնվում են պահեստներում):
Գաղտնաբառերի ստեղծման, հայտնաբերման և շարունակական հայտնաբերման հետ կապված խնդիրները լուծվել են կեռիկների միջոցով:
Բեմականացումն իրականացվում է պիտակների շնորհիվ, որոնք Docker-ն աջակցում է տուփից դուրս:
Արդյունքը վերահսկվում է չափումների միջոցով, որոնց միջոցով մենք կարող ենք հասկանալ կարգավիճակը:

Այս ամբողջ համակարգը ներդրված է Go-ում մեկ երկուականի տեսքով, որը կոչվում է addon-operator: Սա գծապատկերն ավելի պարզ է դարձնում.

Այս դիագրամի հիմնական բաղադրիչը մոդուլների մի շարք է (ներքևում ընդգծված է մոխրագույնով). Այժմ մենք կարող ենք մի փոքր ջանք գործադրելով մոդուլ գրել պահանջվող հավելման համար և վստահ լինել, որ այն կտեղադրվի յուրաքանչյուր կլաստերում, կթարմացվի և կարձագանքի կլաստերում իրեն անհրաժեշտ իրադարձություններին։

«Flant» օգտագործում հավելում-օպերատոր 70+ Kubernetes կլաստերների վրա: Ընթացիկ կարգավիճակը - ալֆա տարբերակը. Այժմ մենք փաստաթղթեր ենք պատրաստում բետա տարբերակը թողարկելու համար, բայց առայժմ պահոցում առկա օրինակներ, որի հիման վրա կարող եք ստեղծել ձեր սեփական հավելումը։

Որտե՞ղ կարող եմ ստանալ հավելումների օպերատորի մոդուլները: Մեր գրադարանի հրատարակումը մեզ համար հաջորդ փուլն է, մենք նախատեսում ենք դա անել ամռանը:

Տեսանյութեր և սլայդներ

Տեսանյութ ներկայացումից (~50 րոպե).

Զեկույցի ներկայացում.

PS

Այլ զեկույցներ մեր բլոգում.

«Տվյալների բազաներ և Kubernetes"; (Դմիտրի Ստոլյարով; նոյեմբերի 8, 2018 HighLoad++-ում);
«Մոնիտորինգ և Kubernetes"; (Դմիտրի Ստոլյարով; մայիսի 28, 2018 RootConf-ում);
«CI/CD-ի լավագույն փորձը Kubernetes-ի և GitLab-ի հետ"; (Դմիտրի Ստոլյարով; նոյեմբերի 7, 2017 HighLoad++-ում);
«Մեր փորձը Kubernetes-ի հետ փոքր նախագծերում"; (Դմիտրի Ստոլյարով; 6 թվականի հունիսի 2017-ին RootConf-ում).

Ձեզ կարող են հետաքրքրել նաև հետևյալ հրապարակումները.

«Ներկայացնում ենք shell-օպերատորը. Kubernetes-ի համար օպերատորների ստեղծումը պարզապես հեշտացել է.

Source: www.habr.com

Kubernetes-ի ընդլայնում և լրացում (ակնարկ և վիդեո զեկույց)