🥇10 տարածված սխալ Kubernetes

Նշում. թարգմ.Այս հոդվածի հեղինակները մի փոքրիկ չեխական ընկերության ինժեներներն են, որը կոչվում է pipetail: Նրանց հաջողվեց հավաքել [երբեմն աննշան, բայց դեռ] շատ տեղին խնդիրների և սխալ պատկերացումների մի մեծ ցուցակ՝ կապված Kubernetes կլաստերների հետ:

Kubernetes-ի օգտագործման տարիների ընթացքում մենք աշխատել ենք մեծ թվով կլաստերների հետ (և՛ կառավարվող, և՛ չկառավարվող՝ GCP-ում, AWS-ում և Azure-ում): Ժամանակի ընթացքում մենք սկսեցինք նկատել, որ որոշ սխալներ անընդհատ կրկնվում են։ Սակայն սրա մեջ ամոթալի ոչինչ չկա. մենք ինքներս ենք կատարել դրանց մեծ մասը։

Հոդվածը պարունակում է ամենատարածված սխալները, ինչպես նաև նշվում է, թե ինչպես դրանք ուղղել:

1. Ռեսուրսներ՝ հարցումներ և սահմանափակումներ

Այս կետը, անկասկած, արժանի է ամենաշատ ուշադրությանն ու ցուցակի առաջին տեղին։

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

Լավագույն ջանք (չափազանց ոչ խորհուրդ է տրվում):

resources: {}

CPU-ի չափազանց ցածր պահանջարկ (չափազանց ոչ խորհուրդ է տրվում):

   resources:
      Requests:
        cpu: "1m"

Մյուս կողմից, CPU-ի սահմանաչափ ունենալը կարող է պատճառ դառնալ, որ pods-ն անհարկի բաց թողնի ցիկլերը, նույնիսկ եթե հանգույցի CPU-ն ամբողջությամբ բեռնված չէ: Կրկին, սա կարող է հանգեցնել հետաձգման ավելացման: Պարամետրի շուրջ հակասությունները շարունակվում են CPU CFS քվոտա միջուկում Linux CPU-ի սահմանափակումը՝ կախված սահմանված սահմանաչափերից, ինչպես նաև CFS քվոտայի անջատումը... Ցավոք, CPU-ի սահմանաչափերը կարող են ավելի շատ խնդիրներ առաջացնել, քան լուծել: Դուք կարող եք ավելին իմանալ այս մասին ստորև նշված հղումով:

Ավելորդ սեկրեցիա (գերակատարում) հիշողությունը կարող է հանգեցնել ավելի լայնածավալ խնդիրների: CPU-ի սահմանաչափին հասնելու դեպքում ցիկլերը բաց են թողնվում, մինչդեռ հիշողության սահմանաչափին հասնելը հանգեցնում է պատիճը սպանելու: Դուք երբևէ նկատե՞լ եք սա: OOMkill? Այո, հենց դրա մասին է խոսքը:

Ցանկանու՞մ եք նվազագույնի հասցնել նման դեպքերի հավանականությունը: Մի չափազանցեք հիշողությունը և օգտագործեք Երաշխավորված QoS (Ծառայության որակ)՝ սահմանելով հիշողության հարցումը սահմանաչափին հավասար (ինչպես ստորև բերված օրինակում): Կարդացեք ավելին այս մասին Հենինգ Ջեյքոբսի շնորհանդեսներ (Զալանդոյի առաջատար ինժեներ):

Պայթող (OOM սպանվելու ավելի մեծ հնարավորություն).

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

Երաշխավորված:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

Ի՞նչը կարող է օգնել ռեսուրսներ ստեղծելիս:

Հետ մետրիկա-սերվեր Դուք կարող եք դիտել պոդերի (և դրանց մեջ գտնվող կոնտեյներների) ընթացիկ CPU-ի և հիշողության օգտագործումը։ Հավանական է, որ դուք արդեն օգտագործում եք այն։ Պարզապես գործարկեք հետևյալ հրամանները.

kubectl top pods
kubectl top pods --containers
kubectl top nodes

Այնուամենայնիվ, դրանք ցույց են տալիս միայն ընթացիկ օգտագործումը: Դա կարող է ձեզ մոտավոր պատկերացում տալ մեծության կարգի մասին, բայց, ի վերջո, ձեզ անհրաժեշտ կլինի. չափումների պատմությունը ժամանակի ընթացքում փոխվում է («Որքա՞ն է եղել պրոցեսորի բեռնվածության գագաթնակետը», «Ի՞նչ էր բեռնվածությունը երեկ առավոտյան» և այլն հարցերին պատասխանելու համար) Դրա համար կարող եք օգտագործել. Պրոմեթեւս, DataDog և այլ գործիքներ: Նրանք պարզապես չափումներ են ստանում metrics-server-ից և պահում դրանք, և օգտագործողը կարող է հարցումներ կատարել դրանց վրա և կառուցել համապատասխան գրաֆիկներ:

VerticalPodAutoscaler թույլ է տալիս ավտոմատացնել այս գործընթացը: Այն հետևում է պրոցեսորի և հիշողության օգտագործման պատմությանը և կարգավորում է նոր հարցումներն ու սահմանափակումները՝ հիմնվելով այս տեղեկատվության վրա:

Հաշվողական հզորության արդյունավետ օգտագործումը հեշտ գործ չէ: Դա նման է անընդհատ Tetris խաղալուն: Եթե դուք չափազանց շատ եք վճարում հաշվողական հզորության համար ցածր միջին սպառման դեպքում (ասենք ~10%), խորհուրդ ենք տալիս դիտել AWS Fargate-ի կամ Virtual Kubelet-ի վրա հիմնված ապրանքներ: Դրանք կառուցված են առանց սերվերի/վճարման մեկ օգտագործման հաշվարկային մոդելի վրա, որը կարող է ավելի էժան լինել նման պայմաններում:

2. Կենսունակության և պատրաստականության զոնդեր

Լռելյայնորեն Kubernetes-ում ակտիվության և պատրաստակամության ստուգումները միացված չեն: Եվ երբեմն մոռանում են դրանք միացնել...

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

Այս թեստերը հաճախ շփոթում են միմյանց հետ.

Կենսունակություն - «աշխուժության» ստուգում, որը վերագործարկում է պատիճը, եթե այն ձախողվի.
Պատրաստակամություն — պատրաստության ստուգում, եթե այն ձախողվի, այն անջատում է պատիճը Kubernetes ծառայությունից (սա կարելի է ստուգել՝ օգտագործելով kubectl get endpoints) և երթևեկությունը չի հասնում դրան մինչև հաջորդ ստուգումը հաջողությամբ ավարտված լինի:

Այս երկու թեստերը ԿԱՏԱՐՎՈՒՄ ԵՆ ՊՈԴԻ ՈՂՋ ԿՅԱՆՔԻ ՑԻԿԼԻ ընթացքում. Սա շատ կարևոր է։

Տարածված սխալ պատկերացում է, որ պատրաստականության զոնդերը գործարկվում են միայն գործարկման ժամանակ, որպեսզի բեռը հավասարակշռողին իմանա, որ պատյանը պատրաստ է (Ready) և կարող է սկսել թրաֆիկի մշակումը: Այնուամենայնիվ, սա դրանց օգտագործման տարբերակներից միայն մեկն է:

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

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

Չեկերի երկու տեսակները չպետք է ձախողվեն, երբ ընդհանուր կախվածությունները ձախողվեն, հակառակ դեպքում դա կհանգեցնի բոլոր պատյանների կասկադային ձախողմանը: Այլ կերպ ասած, մի վնասիր քեզ.

3. LoadBalancer յուրաքանչյուր HTTP ծառայության համար

Ամենայն հավանականությամբ, դուք ունեք HTTP ծառայություններ ձեր կլաստերում, որոնք կցանկանայիք ցուցադրել արտաքին աշխարհին:

Եթե դուք բացում եք ծառայությունը որպես type: LoadBalancer, նրա վերահսկիչը (կախված ծառայություն մատուցողից) կտրամադրի և կբանակցի արտաքին LoadBalancer (պարտադիր չէ, որ այն աշխատում է L7-ով, ամենայն հավանականությամբ նույնիսկ L4-ով), և դա կարող է ազդել արժեքի վրա (արտաքին ստատիկ IPv4 հասցե, հաշվողական հզորություն, վայրկյանում վճարում)՝ մեծ թվով նման ռեսուրսներ ստեղծելու անհրաժեշտության պատճառով:

Այս դեպքում շատ ավելի խելամիտ է օգտագործել մեկ արտաքին բեռի հավասարակշռող սարք՝ բացելով ծառայությունները որպես type: NodePort. Կամ, նույնիսկ ավելի լավ, տեղակայեք նման բան nginx-ingress-controller (Կամ տրեֆիկ), ով կլինի միակը, ով հանդես կգա NodePort վերջնակետը կապված է արտաքին բեռի հավասարակշռիչի հետ և կուղղորդի երթևեկությունը կլաստերի ներսում՝ օգտագործելով մուտք-Kubernetes ռեսուրսները.

Այլ ներկլաստերային (միկրո) ծառայություններ, որոնք փոխազդում են միմյանց հետ, կարող են «շփվել»՝ օգտագործելով տիպի ծառայությունները. ClusterIP և ներկառուցված DNS ծառայության հայտնաբերման մեխանիզմ: Պարզապես մի օգտագործեք նրանց հանրային DNS/IP-ն, քանի որ դա կարող է ազդել հետաձգման վրա և մեծացնել ամպային ծառայության ծախսերը:

4. Կլաստերի ավտոմատ մասշտաբավորում՝ առանց դրա առանձնահատկությունները հաշվի առնելու

Կլաստերում հանգույցներ ավելացնելիս և հեռացնելիս չպետք է ապավինեք որոշ հիմնական չափորոշիչներին, ինչպիսիք են պրոցեսորի օգտագործումը այդ հանգույցների վրա: Պոդի պլանավորումը պետք է կատարվի՝ հաշվի առնելով հավաքածուն սահմանափակումներ, ինչպիսիք են pod/node-ի մերձեցումը, աղտոտումները և հանդուրժողականությունը, ռեսուրսների հարցումները, QoS և այլն: Արտաքին ավտոսանդղակի օգտագործումը, որը հաշվի չի առնում այս նրբությունները, կարող է հանգեցնել խնդիրների:

Պատկերացրեք, որ պատիճը պետք է պլանավորվի, բայց CPU-ի ողջ հասանելի հզորությունը պահանջվում/վերցվում է, և պատիճը խրվում է մի վիճակում Pending. Արտաքին ավտոմատ սանդղակը տեսնում է պրոցեսորի միջին ընթացիկ բեռնվածությունը (ոչ պահանջվածը) և չի սկսում մասշտաբումը (մեծացում) - չի ավելացնում ևս մեկ հանգույց: Արդյունքում, այս պատիճը պլանավորված չի լինի:

Այս դեպքում հակադարձ մասշտաբը (մասշտաբային) - կլաստերից հանգույց հեռացնելը միշտ ավելի դժվար է իրականացնել: Պատկերացրեք, որ դուք ունեք վիճակային պատիճ (կցված մշտական պահեստով): Մշտական ծավալներ սովորաբար պատկանում են հատուկ հասանելիության գոտի և չեն կրկնվում տարածաշրջանում: Այսպիսով, եթե արտաքին autoscaler-ը հեռացնում է հանգույցը այս պատի միջոցով, ապա ժամանակացույցը չի կարողանա պլանավորել այս pod այլ հանգույց, քանի որ դա կարող է արվել միայն հասանելիության գոտում, որտեղ գտնվում է մշտական պահեստը: Պատիճը կխրվի վիճակի մեջ Pending.

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

5. IAM/RBAC հնարավորությունների անտեսում

Զգուշացեք IAM-ի օգտատերերից մշտական գաղտնիքներով մեքենաներ և հավելվածներ. Տրամադրեք ժամանակավոր մուտք՝ օգտագործելով դերերը և ծառայությունների հաշիվները (ծառայության հաշիվներ).

Մենք հաճախ տեսնում ենք, որ մուտքի ստեղները (և գաղտնիքները) «կոշտ կոդավորվում են» հավելվածի կազմաձևում, ինչպես նաև գաղտնի ռոտացիան անտեսվում է՝ չնայած Cloud IAM-ին հասանելիությանը: Անհրաժեշտության դեպքում օգտագործողների փոխարեն օգտագործեք IAM դերերը և ծառայության հաշիվները:

Մոռացեք kube2iam-ի մասին և անմիջապես գնացեք IAM դերեր՝ սպասարկման հաշիվների համար (ինչպես նկարագրված է համանուն գրություն Ստեփան Վրան.

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

Մեկ ծանոթագրություն. Դա այնքան էլ դժվար չէ, չէ՞:

Նաև մի տրամադրեք արտոնություններ սպասարկման հաշիվներին և օրինակների պրոֆիլներին: admin и cluster-admin, եթե դրա կարիքը չունեն։ Սա մի փոքր ավելի դժվար է իրականացնել, հատկապես K8s RBAC-ում, բայց հաստատ արժե ջանք թափել:

6. Մի ապավինեք պատիճների ավտոմատ հակահարաբերություններին

Պատկերացրեք, որ դուք ունեք մի հանգույցի վրա որոշ տեղակայման երեք կրկնօրինակ: Հանգույցը ընկնում է, և դրա հետ միասին բոլոր կրկնօրինակները: Տհաճ իրավիճակ է, չէ՞: Բայց ինչու՞ էին բոլոր կրկնօրինակները նույն հանգույցում: Արդյո՞ք Kubernetes-ը չպետք է ապահովի Բարձր հասանելիություն (HA)?!

Ցավոք, Kubernetes ժամանակացույցն ինքնուրույն չի հետևում առանձին գոյության կանոններին։ (հակամերձություն) պատիճների համար. Դրանք պետք է հստակ նշվեն.

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

Այսքանը: Այժմ պատիճները պլանավորվելու են տարբեր հանգույցների վրա (այս պայմանը ստուգվում է միայն պլանավորման ժամանակ, բայց ոչ դրանց շահագործման ընթացքում, հետևաբար requiredDuringSchedulingIgnoredDuringExecution).

Այստեղ խոսքը գնում է podAntiAffinity տարբեր հանգույցների վրա. topologyKey: "kubernetes.io/hostname", — և ոչ տարբեր հասանելիության գոտիների մասին։ Լրիվ ՀԱ-ն իրականացնելու համար դուք ստիպված կլինեք ավելի խորանալ այս թեմայի մեջ:

7. Անտեսելով PodDisruptionBudgets-ը

Պատկերացրեք, որ դուք արտադրական բեռ ունեք Kubernetes կլաստերում: Պարբերաբար, հանգույցները և բուն կլաստերը պետք է թարմացվեն (կամ ապամոնտաժվեն): PodDisruptionBudget-ը (PDB) կլաստերի ադմինիստրատորների և օգտատերերի միջև ծառայությունների երաշխիքային պայմանագիր է:

PDB-ն օգնում է խուսափել հանգույցների բացակայության հետևանքով առաջացած ծառայության ընդհատումներից.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

Այս օրինակում դուք, որպես կլաստերի օգտատեր, ասում եք ադմինիստրատորներին. «Հեյ, ես ունեմ կենդանաբանական այգու պահապան ծառայություն, և ինչ էլ որ անեք, ես կցանկանայի, որ այս ծառայության առնվազն 2 կրկնօրինակը միշտ հասանելի լինի»:

Այս մասին ավելին կարող եք կարդալ այստեղ այստեղ.

8. Բազմաթիվ օգտվողներ կամ միջավայրեր ընդհանուր կլաստերում

Kubernetes անվանումների տարածքներ (անունների տարածքներ) չեն ապահովում ուժեղ մեկուսացում.

Տարածված սխալ պատկերացում է, որ եթե դուք տեղակայում եք ոչ արդյունահանվող բեռնվածություն մի անվանատարածքում, իսկ արդյունահանվող բեռնումը մյուսի վրա, նրանք ոչ մի կերպ չեն ազդի միմյանց վրա… Այնուամենայնիվ, մեկուսացման որոշակի մակարդակի կարելի է հասնել՝ օգտագործելով ռեսուրսների հարցումները/սահմանները, սահմանելով քվոտաներ և նշելով առաջնահերթ դասեր: Տվյալների հարթության որոշ «ֆիզիկական» մեկուսացում ապահովվում է կապերի, հանդուրժողականության, աղտոտվածության (կամ հանգույցների ընտրիչների) միջոցով, սակայն նման տարանջատումը բավականին է դժվար է իրականացնել։

Նրանք, ովքեր պետք է խառնեն երկու տեսակի ծանրաբեռնվածությունները նույն կլաստերում, ստիպված կլինեն ապրել բարդության հետ: Եթե նման կարիք չկա, և դուք կարող եք ձեզ թույլ տալ ձեռք բերել մեկ այլ կլաստեր (ասենք, հանրային ամպի մեջ), ապա ավելի լավ է դա անել: Սա թույլ կտա հասնել մեկուսացման շատ ավելի բարձր մակարդակի:

9. արտաքին երթևեկության քաղաքականություն. կլաստեր

Շատ հաճախ մենք տեսնում ենք, որ կլաստերի ներսում ամբողջ տրաֆիկը գալիս է NodePort տեսակի ծառայության միջոցով, որի համար սահմանված է լռելյայն քաղաքականությունը: externalTrafficPolicy: Cluster... Դա նշանակում է որ NodePort բաց է կլաստերի յուրաքանչյուր հանգույցի վրա, և դուք կարող եք օգտագործել դրանցից որևէ մեկը՝ ցանկալի ծառայության հետ շփվելու համար (կոմպլեկտներ):

Միևնույն ժամանակ, վերոհիշյալ NodePort ծառայության հետ կապված իրական պատիճները սովորաբար հասանելի են միայն որոշ այս հանգույցների ենթաբազմությունը. Այլ կերպ ասած, եթե ես միացնեմ մի հանգույցի, որը չունի ինձ անհրաժեշտ պատիճը, այն երթևեկությունը կուղարկի մեկ այլ հանգույց, ավելացնելով հոպ և աճող հետաձգումը (եթե հանգույցները գտնվում են տարբեր հասանելիության գոտիներում/տվյալների կենտրոններում, ուշացումը կարող է բավականին բարձր լինել, բացի այդ, արտագնա տրաֆիկի ծախսերը կավելանան):

Մյուս կողմից, եթե որոշակի Kubernetes ծառայության համար քաղաքականություն է սահմանվում externalTrafficPolicy: Local, այնուհետև NodePort-ը բացվում է միայն այն հանգույցների վրա, որտեղ իրականում աշխատում են պահանջվող փոդերը։ Արտաքին բեռի հավասարակշռիչ օգտագործելիս, որը ստուգում է վիճակները (առողջության ստուգում) վերջնակետեր (ինչպես է դա անում AWS ELB), Նա կուղարկի երթևեկությունը միայն անհրաժեշտ հանգույցներին, ինչը դրական ազդեցություն կունենա հետաձգման, հաշվողական կարիքների, էգրեսի հաշիվների վրա (իսկ ողջախոհությունը նույն բանն է թելադրում):

Հավանականությունը մեծ է, որ դուք արդեն օգտագործում եք նման բան տրեֆիկ կամ nginx-ingress-controller որպես NodePort-ի վերջնակետ (կամ LoadBalancer, որը նաև օգտագործում է NodePort)՝ HTTP ներթափանցող տրաֆիկը երթուղավորելու համար, և այս ընտրանքի կարգավորումը կարող է զգալիորեն նվազեցնել նման հարցումների հետաձգումը:

В այս հրապարակումը Դուք կարող եք ավելին իմանալ արտաքին երթևեկության քաղաքականության, դրա առավելությունների և թերությունների մասին:

10. Մի կապվեք կլաստերների հետ և չափից դուրս մի օգտագործեք կառավարման հարթությունը

Նախկինում սովորական էր սերվերներին զանգահարել իրենց հատուկ անուններով. Anton, HAL9000 և Colossus… Այսօր դրանք փոխարինվել են պատահականորեն ստեղծված նույնացուցիչներով: Սակայն սովորությունը մնաց, և այժմ կլաստերներին տրվում են համապատասխան անուններ։

Տիպիկ պատմություն (հիմնված իրական իրադարձությունների վրա). ամեն ինչ սկսվեց հայեցակարգի ապացույցից, ուստի կլաստերը հպարտ անուն ուներ փորձարկում…Անցել են տարիներ, և այն դեռ օգտագործվում է արտադրության մեջ, և բոլորը վախենում են դիպչել դրան:

Կլաստերները ընտանի կենդանիների վերածվելու մեջ ծիծաղելի ոչինչ չկա, ուստի խորհուրդ ենք տալիս պարբերաբար հեռացնել դրանք՝ մարզվելիս աղետի վերականգնում (սա կօգնի քաոսի ճարտարագիտություն - մոտ. թարգմ.). Բացի այդ, չի խանգարի աշխատել կառավարման շերտի վրա: (կառավարման ինքնաթիռ). Դրան դիպչելուց վախենալն այնքան էլ լավ նշան չէ։ և այլն մեռա՞ծ Տղաներ, դուք իսկապես դժվարության մեջ եք:

Մյուս կողմից, դուք չպետք է տարվեք այն շահարկելով: Ժամանակի ընթացքում հսկիչ շերտը կարող է դանդաղ դառնալ. Սա, ամենայն հավանականությամբ, պայմանավորված է մեծ թվով օբյեկտների ստեղծմամբ՝ առանց դրանք պտտելու (սովորական իրավիճակ Helm-ն օգտագործելիս լռելյայն կարգավորումներով, որի պատճառով դրա վիճակը չի թարմացվում configmaps/գաղտնիքներում. արդյունքում հազարավոր օբյեկտներ են կուտակվում կառավարման շերտում) կամ kube-api օբյեկտների մշտական խմբագրմամբ (ավտոմատ մասշտաբի, մոնիտորինգի, վերահսկիչի, CI/CD և այլն):

Բացի այդ, խորհուրդ ենք տալիս ստուգել SLA/SLO պայմանագրերը կառավարվող Kubernetes մատակարարի հետ և ուշադրություն դարձնել երաշխիքներին: Վաճառողը կարող է երաշխավորել վերահսկման շերտի առկայությունը (կամ դրա ենթաբաղադրիչները), բայց ոչ p99 հարցումների հետաձգումը, որը դուք ուղարկում եք դրան: Այսինքն՝ կարող ես մտնել kubectl get nodes, և պատասխան ստացեք միայն 10 րոպե անց, և դա չի լինի ծառայությունների մատուցման պայմանագրի պայմանների խախտում։

11. Բոնուս. Օգտագործելով վերջին պիտակը

Հիմա սա արդեն դասական է։ Վերջերս մենք այս տեխնիկայի հետ այնքան էլ հաճախ չենք հանդիպում, քանի որ շատերը, սովորելով դառը փորձից, դադարել են օգտագործել պիտակը: :latest և սկսեց կապել տարբերակները: Ուռա՜

ECR պահպանում է պատկերների պիտակների անփոփոխությունը; Խորհուրդ ենք տալիս ծանոթանալ այս ուշագրավ հատկության հետ:

Ամփոփում

Մի սպասեք, որ ամեն ինչ կաշխատի մեկ գիշերում. Kubernetes-ը համադարման չէ: Վատ հավելված նույնը կմնա նույնիսկ Կուբերնետեսում (և դա կարող է ավելի վատանալ): Անզգուշությունը կբերի ավելորդ բարդության, հսկիչ շերտի դանդաղ ու սթրեսային աշխատանքի։ Բացի այդ, դուք ռիսկի եք դիմում մնալ առանց աղետի վերականգնման ռազմավարության: Մի ակնկալեք, որ Kubernetes-ը կկարգավորի մեկուսացումը և բարձր հասանելիությունը: Որոշ ժամանակ տրամադրեք ձեր հավելվածը իսկապես ամպային բնիկ դարձնելու համար:

Դուք կարող եք կարդալ տարբեր թիմերի անհաջող փորձառությունների մասին պատմվածքների այս հավաքածուն Հենինգ Ջեյքոբսի կողմից:

Յուրաքանչյուր ոք, ով ցանկանում է ավելացնել այս հոդվածում թվարկված սխալների ցանկը, կարող է կապվել մեզ հետ Twitter-ում (@MarekBartik, @MstrsObserver).