10 ընդհանուր սխալ Kubernetes-ի օգտագործման ժամանակ

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

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

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

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

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

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

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

resources: {}

Չափազանց ցածր CPU հարցում (չափազանց ոչ խորհուրդ է տրվում):

   resources:
      Requests:
        cpu: "1m"

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

Չափազանց ընտրություն (գերակատարում) հիշողության խնդիրները կարող են հանգեցնել ավելի մեծ խնդիրների: 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

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

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

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 պլանավորումը պետք է հաշվի առնի շատերը սահմանափակումներ, ինչպիսիք են pod/node-ի մերձեցումը, աղտոտվածությունը և հանդուրժողականությունը, ռեսուրսների հարցումները, QoS և այլն: Արտաքին autoscaler-ի օգտագործումը, որը հաշվի չի առնում այս նրբությունները, կարող է հանգեցնել խնդիրների:

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

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

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

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

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

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

Մոռացեք kube2iam-ի մասին և անմիջապես գնացեք IAM դերեր՝ սպասարկման հաշիվների համար (ինչպես նկարագրված է համանուն գրություն Štěpan Vraný):

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եթե դա նրանց պետք չէ: Սա մի փոքր ավելի դժվար է իրականացնել, հատկապես RBAC K8-ներում, բայց հաստատ արժե ջանք թափել:

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 ծառայության հետ կապված իրական պատիճները սովորաբար հասանելի են միայն որոշակի այս հանգույցների ենթաբազմությունը. Այլ կերպ ասած, եթե ես միացնեմ մի հանգույցի, որը չունի անհրաժեշտ pod, այն կուղարկի տրաֆիկը մեկ այլ հանգույց, ավելացնելով հոպ և աճող հետաձգումը (եթե հանգույցները տեղակայված են տարբեր հասանելիության գոտիներում/տվյալների կենտրոններում, ուշացումը կարող է բավականին բարձր լինել, բացի այդ, արտագնա երթևեկության ծախսերը կավելանան):

Մյուս կողմից, եթե 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).

PS թարգմանչից

Կարդացեք նաև մեր բլոգում.

• «Kubernetes կլաստերների նախագծում. քանի՞սը պետք է լինի:";
• «Անվտանգության ABC-ն Kubernetes-ում. վավերացում, լիազորում, աուդիտ";
• «Autoscaling և ռեսուրսների կառավարում Kubernetes-ում«(վերանայել և տեսահաշվետվություն);
• «ConfigMaps Kubernetes-ում. նրբերանգներ, որոնց մասին արժե իմանալ.

Source: www.habr.com