Kubernetes ашиглах үед гаргадаг 10 нийтлэг алдаа

Анхаарна уу. орчуулга.: Энэхүү нийтлэлийн зохиогчид нь Чехийн жижиг компанийн инженерүүд юм. Тэд Кубернетес кластеруудын үйл ажиллагаатай холбоотой [заримдаа улиг болсон боловч] маш тулгамдсан асуудал, буруу ойлголтуудын гайхалтай жагсаалтыг гаргаж чадсан.

Kubernetes-ийг ашигласан олон жилийн туршид бид олон тооны кластеруудтай (удирдлагатай болон удирдагдаагүй - GCP, AWS болон Azure дээр) хамтран ажилласан. Цаг хугацаа өнгөрөхөд бид зарим алдаа байнга давтагдаж байгааг анзаарч эхэлсэн. Гэсэн хэдий ч үүнд ичгүүр байхгүй: бид ихэнхийг нь өөрсдөө хийсэн!

Нийтлэлд хамгийн нийтлэг алдаануудыг багтаасан бөгөөд тэдгээрийг хэрхэн засах талаар дурдсан болно.

1. Нөөц: хүсэлт, хязгаарлалт

Энэ зүйл нь мэдээжийн хэрэг хамгийн их анхаарал хандуулж, жагсаалтын эхний байранд орох ёстой.

CPU-ийн хүсэлт ихэвчлэн байдаг нэг бол огт заагаагүй эсвэл маш бага утгатай (зангилаа бүр дээр аль болох олон хонхорцог байрлуулах). Тиймээс зангилаанууд хэт ачаалалтай болдог. Ачаалал ихтэй үед зангилааны боловсруулах хүчийг бүрэн ашиглаж, тодорхой ажлын ачаалал зөвхөн "хүссэн" зүйлийг л хүлээн авдаг. CPU-ийн тохируулга. Энэ нь програмын хоцролт, хугацаа хэтрэх болон бусад таагүй үр дагаварт хүргэдэг. (Энэ тухай бидний сүүлийн орчуулгаас дэлгэрэнгүй уншина уу: "Кубернетес дэх CPU-ийн хязгаарлалт ба түрэмгий тохируулга"- ойролцоогоор. орчуул.)

Хамгийн сайн хүчин чармайлт (маш их үгүй зөвлөж байна):

resources: {}

CPU-ийн маш бага хүсэлт (маш их үгүй зөвлөж байна):

   resources:
      Requests:
        cpu: "1m"

Нөгөөтэйгүүр, CPU-ийн хязгаарлалт байгаа нь зангилааны процессор бүрэн ачаалагдаагүй байсан ч цагны циклийг pods-ээр үндэслэлгүй алгасахад хүргэдэг. Дахин хэлэхэд энэ нь саатал нэмэгдэхэд хүргэдэг. Параметрийн эргэн тойронд маргаан үргэлжилсээр байна CPU CFS квот Линукс цөм болон CPU-ийн тохируулсан хязгаараас хамааран тохируулга хийх, мөн CFS квотыг идэвхгүй болгох... Харамсалтай нь CPU-ийн хязгаарлалт нь шийдэж чадахаас илүү олон асуудал үүсгэж болзошгүй юм. Энэ талаарх дэлгэрэнгүй мэдээллийг доорх линкээс авах боломжтой.

Хэт их сонголт (хэт их үүрэг хариуцлага хүлээх) санах ойн асуудал нь илүү том асуудалд хүргэдэг. CPU-ийн хязгаарт хүрэх нь цагийн мөчлөгийг алгасах, санах ойн хязгаарт хүрэх нь подволыг устгахад хүргэдэг. Ажиглаж үзсэн үү OOMkill? Тийм ээ, бид яг энэ тухай ярьж байна.

Та ийм тохиолдлын магадлалыг багасгахыг хүсч байна уу? Санах ойг хэт их хуваарилж болохгүй бөгөөд санах ойн хүсэлтийг хязгаарт тохируулах замаар Баталгаат QoS (Үйлчилгээний Чанар)-ыг ашиглаарай (доорх жишээн дээрх шиг). Энэ талаар дэлгэрэнгүй уншина уу Henning Jacobs илтгэлүүд (Заландогийн ахлах инженер).

Тэсрэх чадвартай (OOMkilled авах магадлал өндөр):

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

Баталгаат:

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

Нөөцийг бүрдүүлэхэд юу туслах вэ?

Тусламжийн тусламжтайгаар хэмжүүр-сервер та одоогийн CPU-ийн нөөцийн хэрэглээ болон санах ойн ашиглалтыг pods (болон тэдгээрийн доторх сав)-аар харж болно. Та үүнийг аль хэдийн ашиглаж байгаа байх. Зүгээр л дараах тушаалуудыг ажиллуулна уу:

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

Гэсэн хэдий ч тэдгээр нь зөвхөн одоогийн хэрэглээг харуулдаг. Энэ нь танд хэмжээний дарааллын талаар бүдүүлэг ойлголт өгөх болно, гэхдээ эцэст нь танд хэрэгтэй болно хэмжигдэхүүнүүдийн цаг хугацааны өөрчлөлтийн түүх ("Процессорын ачаалал хамгийн их байсан бэ?", "Өчигдөр өглөө ямар ачаалалтай байсан бэ?" гэх мэт асуултуудад хариулах). Үүний тулд та ашиглаж болно Prometheus, DataDog болон бусад хэрэгсэл. Тэд зүгээр л хэмжүүр-серверээс хэмжигдэхүүнийг авч хадгалдаг бөгөөд хэрэглэгч тэдгээрээс асууж, зохих ёсоор зурах боломжтой.

VerticalPodAutoscaler Энэ нь олгодог автоматжуулах энэ үйл явц. Энэ нь CPU болон санах ойн ашиглалтын түүхийг хянаж, эдгээр мэдээлэлд үндэслэн шинэ хүсэлт, хязгаарлалт тогтоодог.

Тооцооллын хүчийг үр ашигтай ашиглах нь тийм ч амар ажил биш юм. Байнга Тетрис тоглож байгаа юм шиг. Хэрэв та дундаж хэрэглээ багатай (~10%) тооцоолох хүчин чадалд хэт их мөнгө төлж байгаа бол бид AWS Fargate эсвэл Virtual Kubelet дээр суурилсан бүтээгдэхүүнийг үзэхийг зөвлөж байна. Эдгээр нь сервергүй/хэрэглээний төлбөр тооцооны загвар дээр бүтээгдсэн бөгөөд ийм нөхцөлд хямд байх магадлалтай.

2. Амьд байдал, бэлэн байдлын шалгалт

Анхдагч байдлаар, Kubernetes-д амьд байдал болон бэлэн байдлын шалгалтыг идэвхжүүлээгүй байна. Заримдаа тэд асаахаа мартдаг ...

Гэхдээ ноцтой алдаа гарсан тохиолдолд та үйлчилгээг дахин эхлүүлэх ажлыг хэрхэн эхлүүлэх вэ? Ачаалал тэнцвэржүүлэгч нь подвол замын хөдөлгөөнийг хүлээн авахад бэлэн гэдгийг яаж мэдэх вэ? Эсвэл илүү их урсгалыг зохицуулж чадах уу?

Эдгээр туршилтуудыг ихэвчлэн өөр хоорондоо андуурдаг:

• Амьдрал - "Амьд үлдэх" шалгалт, хэрэв энэ нь амжилтгүй болвол подволыг дахин эхлүүлнэ;
• Бэлэн байдал - бэлэн байдлыг шалгах, хэрэв амжилтгүй болвол энэ нь pod-ыг Kubernetes үйлчилгээнээс салгах болно (үүнийг ашиглан шалгаж болно. kubectl get endpoints) дараагийн шалгалтыг амжилттай хийж дуустал замын хөдөлгөөн түүн рүү ирэхгүй.

Энэ хоёр шалгалт ПОД-ЫН АМЬДРАЛЫН БҮХЭЛДЭЭ ХИЙДЭГ. Энэ нь маш чухал юм.

Түгээмэл буруу ойлголт бол бэлэн байдлын шалгалтыг зөвхөн эхлүүлэх үед л ажиллуулдаг бөгөөд ингэснээр тэнцвэржүүлэгч подвол бэлэн болсныг мэдэх боломжтой болно (Ready) болон урсгалыг боловсруулж эхлэх боломжтой. Гэсэн хэдий ч энэ нь тэдний хэрэглээний сонголтуудын зөвхөн нэг юм.

Өөр нэг зүйл бол хонгилын ачаалал хэт их байгааг олж мэдэх боломж юм хэт ачаалал өгдөг (эсвэл pod нь нөөц их шаарддаг тооцооллыг гүйцэтгэдэг). Энэ тохиолдолд бэлэн байдлын шалгалт нь тусалдаг хонхорцог дээрх ачааллыг бууруулж, "хөргөх". Ирээдүйд бэлэн байдлын шалгалтыг амжилттай дуусгах боломжийг олгоно хонхорцог дээрх ачааллыг дахин нэмэгдүүлнэ. Энэ тохиолдолд (хэрэв бэлэн байдлын шалгалт амжилтгүй болбол) амьд байдлын шалгалтын бүтэлгүйтэл нь маш сөрөг үр дагавартай байх болно. Эрүүл, шаргуу ажилладаг подволкыг яагаад дахин эхлүүлэх вэ?

Тиймээс зарим тохиолдолд шалгалтыг огт хийхгүй байх нь буруу тохируулсан параметрүүдийг идэвхжүүлэхээс илүү дээр юм. Дээр дурдсанчлан, хэрэв liveness check copies бэлэн байдлын шалгалт, тэгвэл та маш их асуудалтай байна. Боломжит сонголт бол тохируулах явдал юм зөвхөн бэлэн байдлын шалгалтболон аюултай амьдрал хажуу тийшээ орхи.

Нийтлэг хамаарал бүтэлгүйтсэн үед хоёр төрлийн шалгалт амжилтгүй болох ёсгүй, эс тэгвээс энэ нь бүх хонхорцог үе шаттайгаар (цас нуранги шиг) бүтэлгүйтэхэд хүргэнэ. Өөрөөр хэлбэл, өөрийгөө бүү хорло.

3. HTTP үйлчилгээ бүрийн LoadBalancer

Таны кластерт гадаад ертөнц рүү дамжуулахыг хүсч буй HTTP үйлчилгээнүүд байгаа байх.

Хэрэв та үйлчилгээг нээвэл type: LoadBalancer, түүний хянагч (үйлчилгээ үзүүлэгчээс хамаарч) нь гадаад LoadBalancer (заавал L7 дээр ажиллахгүй, харин L4 дээр ажиллах) хангаж, тохиролцох бөгөөд энэ нь зардалд (гадаад статик IPv4 хаяг, тооцоолох хүч, секундын тооцоо) нөлөөлж болзошгүй. ) ийм нөөцийг их хэмжээгээр бий болгох шаардлагатай байгаатай холбоотой.

Энэ тохиолдолд нэг гадаад ачаалал тэнцвэржүүлэгчийг ашиглах нь илүү логик юм, үйлчилгээг нээх type: NodePort. Эсвэл илүү дээр юм шиг зүйлийг өргөжүүлээрэй nginx-ingress-хянагч (эсвэл траффик), хэн цорын ганц байх болно NodePort төгсгөлийн цэг нь гадаад ачаалал тэнцвэржүүлэгчтэй холбоотой бөгөөд кластер дахь урсгалыг ашиглан чиглүүлэх болно оролт-Кубернетесийн нөөц.

Өөр хоорондоо харилцан үйлчилдэг бусад кластер доторх (микро) үйлчилгээнүүд зэрэг үйлчилгээг ашиглан "харилцаж" болно ClusterIP мөн DNS-ээр дамжуулан үйлчилгээ илрүүлэх суурилуулсан механизм. Тэдний нийтийн DNS/IP-г бүү ашигла, учир нь энэ нь хоцролтод нөлөөлж, үүлэн үйлчилгээний өртөгийг нэмэгдүүлэх болно.

4. Кластерын онцлогийг харгалзахгүйгээр автоматаар масштаблах

Кластерт зангилаа нэмэх болон тэдгээрийг устгахдаа тэдгээр зангилаанууд дээрх CPU-ийн хэрэглээ гэх мэт зарим үндсэн хэмжигдэхүүнд найдах ёсгүй. Под төлөвлөлт нь олон зүйлийг харгалзан үзэх ёстой хязгаарлалт, тухайлбал pod/зангилааны хамаарал, бохирдол ба хүлцэл, нөөцийн хүсэлт, QoS гэх мэт. Эдгээр нюансуудыг харгалздаггүй гадны авто масштабыг ашиглах нь асуудалд хүргэж болзошгүй юм.

Тодорхой подволыг хуваарьтай байх ёстой гэж төсөөлөөд үз дээ, гэхдээ бүх боломжтой CPU-ийн хүчийг авахыг хүссэн/задаргаж, подволыг байдалд гацдаг Pending. Гадны автомат масштаблагч нь одоогийн CPU-ийн дундаж ачааллыг (хүссэн ачааллыг биш) харж, өргөтгөлийг эхлүүлэхгүй. (хэмжээг багасгах) - өөр зангилаа нэмдэггүй. Үүний үр дүнд энэ подволкийг төлөвлөхгүй.

Энэ тохиолдолд урвуу масштабыг хийнэ (томруулах) - кластераас зангилаа арилгах нь хэрэгжүүлэхэд үргэлж хэцүү байдаг. Танд төлөвтэй pod (байнгын хадгалах сан холбогдсон) байна гэж төсөөлөөд үз дээ. Байнгын хэмжээ ихэвчлэн харьяалагддаг тодорхой хүртээмжтэй бүс бөгөөд бүс нутагт давтагддаггүй. Тиймээс хэрэв гадны авто масштаб тохируулагч нь энэ pod бүхий зангилааг устгавал хуваарь гаргагч өөр зангилаа дээр энэ подкастыг төлөвлөх боломжгүй, учир нь үүнийг зөвхөн байнгын хадгалалт байрладаг бэлэн байдлын бүсэд хийх боломжтой. 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хэрэв тэдэнд хэрэггүй бол. Үүнийг хэрэгжүүлэх нь арай илүү хэцүү, ялангуяа RBAC K8-д, гэхдээ хүчин чармайлт гаргах нь гарцаагүй.

6. Үндэстний эсрэг автомат нөлөөнд найдаж болохгүй

Танд зангилаа дээр зарим байршуулалтын гурван хуулбар байна гэж төсөөлөөд үз дээ. Зангилаа унаж, түүнтэй хамт бүх хуулбарууд. Тааламжгүй нөхцөл байдал, тийм үү? Гэхдээ яагаад бүх хуулбарууд нэг зангилаа дээр байсан бэ? Kubernetes нь өндөр хүртээмжтэй байх ёстой (HA) биш гэж үү?!

Харамсалтай нь Кубернетес хуваарьлагч нь өөрийн санаачилгаар тусдаа оршин тогтнох дүрмийг дагаж мөрддөггүй. (харилцааны эсрэг) хонхорцогуудын хувьд. Тэдгээрийг тодорхой зааж өгөх ёстой:

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

Тэгээд л болоо. Одоо хонхорцог өөр өөр зангилаанууд дээр хуваарьтай байх болно (энэ нөхцөлийг зөвхөн хуваарь гаргах үед шалгадаг, гэхдээ тэдгээрийн ажиллах явцад биш - тиймээс requiredDuringSchedulingIgnoredDuringExecution).

Энд бид ярьж байна podAntiAffinity өөр өөр зангилаанууд дээр: topologyKey: "kubernetes.io/hostname", - мөн өөр өөр боломжит бүсийн тухай биш. Бүрэн хэмжээний HA-г хэрэгжүүлэхийн тулд та энэ сэдвийг илүү гүнзгий судлах хэрэгтэй болно.

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 нэрийн орон зай (нэрийн орон зай) хүчтэй дулаалга бүү хий.

Нийтлэг буруу ойлголт бол хэрэв та үйлдвэрлэлийн бус ачааллыг нэг нэрийн талбарт, үйлдвэрлэлийн ачааллыг нөгөөд байршуулбал тэдгээр нь бие биедээ ямар нэгэн байдлаар нөлөөлөхгүй... Гэсэн хэдий ч нөөцийн хүсэлт/хязгаарлалт, квот тогтоох, priorityClasses зэргийг ашиглан тодорхой түвшний тусгаарлалтад хүрч болно. Өгөгдлийн хавтгай дахь зарим "бие махбодийн" тусгаарлалт нь хамаарал, хүлцэл, бохирдол (эсвэл зангилаа сонгогч) -ээр хангагдсан байдаг, гэхдээ ийм тусгаарлалт нь нэлээд юм. хэцүү хэрэгжүүлэх.

Хоёр төрлийн ачааллыг нэг кластерт нэгтгэх шаардлагатай хүмүүс нарийн төвөгтэй байдлыг даван туулах хэрэгтэй болно. Хэрэв ийм хэрэгцээ байхгүй бол та үүнийг авах боломжтой дахиад нэг кластер (нийтийн үүлэн дотор гэх мэт), тэгвэл үүнийг хийх нь дээр. Энэ нь тусгаарлагчийн илүү өндөр түвшинд хүрэх болно.

9. гадаад Замын хөдөлгөөний бодлого: Кластер

Кластер доторх бүх урсгал нь анхдагч бодлогыг тохируулсан NodePort гэх мэт үйлчилгээгээр дамждаг гэдгийг бид ихэвчлэн хардаг. externalTrafficPolicy: Cluster... Энэ нь гэсэн үг NodePort нь кластерын зангилаа бүр дээр нээлттэй бөгөөд та тэдгээрийн аль нэгийг нь ашиглан хүссэн үйлчилгээтэй (подны багц) харьцах боломжтой.

Үүний зэрэгцээ, дээр дурдсан NodePort үйлчилгээтэй холбоотой жинхэнэ pods нь ихэвчлэн зөвхөн тодорхой хэсэгт байдаг. эдгээр зангилааны дэд хэсэг. Өөрөөр хэлбэл, хэрэв би шаардлагатай pod байхгүй зангилаа руу холбогдвол энэ нь траффикийг өөр зангилаа руу дамжуулах болно. хоп нэмэх болон нэмэгдэж байгаа хоцрогдол (хэрэв зангилаанууд өөр өөр хүртээмжтэй бүсэд/өгөгдлийн төвүүдэд байрладаг бол хоцролт нь нэлээд өндөр байж болно; үүнээс гадна гадагш гарах хөдөлгөөний зардал нэмэгдэх болно).

Нөгөө талаас, хэрэв Kubernetes-ийн тодорхой үйлчилгээ нь бодлогын багцтай бол externalTrafficPolicy: Local, дараа нь NodePort зөвхөн шаардлагатай pods ажиллаж байгаа цэгүүд дээр нээгдэнэ. төлөвийг шалгадаг гадаад ачаалал тэнцвэржүүлэгчийг ашиглах үед (эрүүл мэндийн үзлэг) төгсгөлийн цэгүүд (энэ нь яаж хийдэг вэ? AWS ELB), Тэр зөвхөн шаардлагатай зангилаа руу урсгалыг илгээх болно, энэ нь саатал, тооцооллын хэрэгцээ, гарах төлбөрийн тооцоонд сайнаар нөлөөлнө (мөн эрүүл ухаан нь үүнийг шаарддаг).

Ийм зүйлийг аль хэдийн ашиглаж байгаа байх магадлал өндөр байна траффик буюу nginx-ingress-хянагч HTTP нэвтрэлтийн урсгалыг чиглүүлэхийн тулд NodePort төгсгөлийн цэг (эсвэл LoadBalancer нь NodePort ашигладаг) байх ба энэ сонголтыг тохируулснаар ийм хүсэлтийн хоцролтыг мэдэгдэхүйц бууруулж чадна.

В энэ нийтлэлийг Та extraTrafficPolicy, түүний давуу болон сул талуудын талаар илүү ихийг мэдэх боломжтой.

10. Кластерт бүү баригд, удирдлагын хавтгайг бүү буруугаар ашигла

Өмнө нь серверүүдийг зохих нэрээр нь дууддаг заншилтай байсан. Антон, HAL9000 болон Colossus... Өнөөдөр тэдгээрийг санамсаргүй байдлаар үүсгэсэн танигчаар сольсон. Гэсэн хэдий ч зуршил хэвээр үлдсэн бөгөөд одоо зохих нэрс нь кластер руу явдаг.

Ердийн түүх (бодит үйл явдлууд дээр үндэслэсэн): энэ бүхэн үзэл баримтлалын баталгаагаар эхэлсэн тул кластер нь бардам нэртэй байв. шинжилгээ хийх... Олон жил өнгөрч, үүнийг үйлдвэрлэлд ашигласаар байгаа бөгөөд хүн бүр түүнд хүрэхээс айдаг.

Кластерууд гэрийн тэжээвэр амьтан болж хувирахад тийм ч хөгжилтэй зүйл байхгүй тул дасгал хийж байхдаа тэдгээрийг үе үе арилгахыг зөвлөж байна. гамшгийн нөхөн сэргээлт (энэ нь туслах болно эмх замбараагүй инженерчлэл - ойролцоогоор. орчуул.). Үүнээс гадна, хяналтын давхарга дээр ажиллах нь гэмтээхгүй (хяналтын онгоц). Түүнд хүрэхээс айх нь сайн шинж биш юм. гэх мэт үхсэн үү? Залуус аа, та үнэхээр асуудалтай байна!

Нөгөөтэйгүүр, та үүнийг манипуляцид автуулах ёсгүй. Цаг хугацаа өнгөрөхөд хяналтын давхарга удааширч магадгүй. Энэ нь олон тооны объектыг эргүүлэхгүйгээр үүсгэсэнтэй холбоотой байж болох юм (Helm-ийг анхдагч тохиргоотой ашиглах үед тохиолддог нийтлэг нөхцөл байдал, иймээс тохиргооны зураг/нууц дахь төлөв шинэчлэгдээгүй - үр дүнд нь олон мянган объект хуримтлагддаг. хяналтын давхарга) эсвэл kube-api объектуудыг тогтмол засварлах (автоматаар масштаблах, CI/CD, хяналт тавих, үйл явдлын бүртгэл, хянагч гэх мэт).

Нэмж дурдахад бид удирддаг Kubernetes үйлчилгээ үзүүлэгчтэй хийсэн SLA/SLO гэрээг шалгаж, баталгаанд анхаарлаа хандуулахыг зөвлөж байна. Худалдагч баталгаа гаргаж болно давхаргын хүртээмжийг хянах (эсвэл түүний дэд бүрэлдэхүүн хэсгүүд), гэхдээ таны илгээсэн хүсэлтийн p99 саатал биш. Өөрөөр хэлбэл та орж болно kubectl get nodes, зөвхөн 10 минутын дараа л хариу хүлээн авах бөгөөд энэ нь үйлчилгээний гэрээний нөхцлийг зөрчихгүй.

11. Бонус: хамгийн сүүлийн үеийн шошгыг ашиглах

Гэхдээ энэ бол аль хэдийн сонгодог болсон. Сүүлийн үед олон хүн гашуун туршлагаас суралцсан тул шошгыг ашиглахаа больсон тул бид энэ техникийг бага тааруулж байна. :latest болон хувилбаруудыг хавчуулж эхэлсэн. Өө!

ECR зургийн шошгоны хувиршгүй байдлыг хадгалдаг; Энэхүү гайхалтай онцлогтой танилцахыг бид танд зөвлөж байна.

Хураангуй

Бүх зүйл нэг шөнийн дотор ажиллана гэж бүү найд: Кубернетес бол эм биш юм. Муу програм Kubernetes-д ч гэсэн ийм хэвээр байх болно (мөн энэ нь магадгүй улам дордох болно). Анхаарал болгоомжгүй байдал нь хяналтын давхаргын хэт нарийн төвөгтэй, удаан, стресстэй ажилд хүргэдэг. Нэмж хэлэхэд, та гамшгаас хамгаалах стратегигүйгээр үлдэх эрсдэлтэй. Kubernetes нь тусгаарлалт, өндөр хүртээмжтэй байдлыг хангана гэж бүү найд. Аппликейшнээ жинхэнэ үүл болгоход хэсэг хугацаа зарцуулаарай.

Та янз бүрийн багуудын амжилтгүй туршлагатай танилцаж болно энэ түүхүүдийн цуглуулга Хеннинг Жэйкобс.

Энэ нийтлэлд өгөгдсөн алдааны жагсаалтад нэмэхийг хүсч буй хүмүүс Twitter-ээр бидэнтэй холбоо барьж болно (@MarekBartik, @MstrsObserver).

Орчуулагчийн жич

Мөн манай блог дээрээс уншина уу:

• «Kubernetes кластеруудыг зохион бүтээх: хэд байх ёстой вэ?";
• «Кубернетес дэх аюулгүй байдлын ABC: Баталгаажуулалт, зөвшөөрөл, аудит";
• «Кубернетес дэх автомат масштаб болон нөөцийн удирдлага"(хяналт, видео тайлан);
• «Kubernetes дахь ConfigMaps: мэдэх хэрэгтэй нюансууд".

Эх сурвалж: www.habr.com