🥇Kubernetes Pod нөөцөд хэрхэн хандах вэ

Тохадын шагнал

Kubernetes-тэй ажиллахдаа контейнерийн нөөцийг тохируулахаа мартдаг. Энэ үед Docker дүрс ажиллаж, Kubernetes кластерт байршуулах боломжтой байх нь хангалттай юм.

Гэхдээ дараа нь уг программыг бусад програмын хамт үйлдвэрлэлийн кластерт байрлуулах шаардлагатай. Үүнийг хийхийн тулд та контейнерт нөөцийг хуваарилж, програмыг ажиллуулахад хангалттай нөөц байгаа эсэхийг шалгах хэрэгтэй бөгөөд бусад ажиллаж байгаа програмууд нь асуудал үүсгэхгүй.

баг Mail.ru сайтаас Kubernetes aaS контейнерийн нөөц (CPU & MEM), хүсэлт, нөөцийн хязгаарлалтын тухай нийтлэлийг орчуулсан. Та эдгээр тохиргооны ашиг тусыг мэдэж авах бөгөөд хэрэв та эдгээр тохиргоог хийхгүй бол юу болох талаар мэдэх болно.

Тооцоолох нөөц

Бид дараах нэгжтэй хоёр төрлийн нөөцтэй.

Төв боловсруулах нэгж (CPU) - цөм;
Санах ой (MEM) - байт.

Нөөцийг чингэлэг тус бүрт зааж өгсөн болно. Дараах Pod YAML файлд та хүссэн болон хязгаарлагдмал нөөцийг агуулсан нөөцийн хэсгийг харах болно:

Requested Pod Resources = бүх савны хүссэн нөөцийн нийлбэр;
Pod нөөцийн хязгаар = Бүх Pod нөөцийн хязгаарын нийлбэр.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

Хүссэн болон хязгаарлагдмал нөөцийн жишээ

талбар resources.requested тодорхойлолтоос Pod нь хүссэн зангилааг олоход хэрэглэгддэг элементүүдийн нэг юм. Та үүнд зориулж Pod байршуулалтыг аль хэдийн төлөвлөж болно. Тохиромжтой зангилаа хэрхэн олох вэ?

Kubernetes нь мастер зангилаа эсвэл мастер зангилаа (Kubernetes Control Plane) зэрэг хэд хэдэн бүрэлдэхүүн хэсгээс бүрддэг. Мастер зангилаа нь хэд хэдэн процесстой: kube-apiserver, kube-controller-manager, kube-scheduler.

Куб хуваарьлагч процесс нь шинээр үүсгэсэн подкуудыг шалгаж, хүссэн нөөцийн тоо зэрэг бүх подын хүсэлттэй таарч тохирох ажилчны зангилааг олох үүрэгтэй. Kube-scheduler-ийн олсон зангилааны жагсаалтыг эрэмбэлсэн. Под хамгийн өндөр оноо авсан зангилаа дээр хуваарилагдана.

Нил ягаан өнгийн хонхорхойг хаана байрлуулах вэ?

Зурган дээр та kube-хуваарилагч шинэ ягаан Pod-г төлөвлөх ёстойг харж болно. Kubernetes кластер нь A ба B гэсэн хоёр зангилаа агуулж байна. Таны харж байгаагаар kube-хуваарьлагч нь A зангилаа дээрх Pod-г төлөвлөх боломжгүй - боломжтой (хүсээгүй) нөөцүүд нь нил ягаан өнгийн Pod-ийн хүсэлттэй таарахгүй байна. Тиймээс, нил ягаан өнгийн Pod-ийн хүссэн 1 ГБ санах ой нь А зангилаанд багтахгүй, учир нь боломжтой санах ой нь 0,5 ГБ байна. Гэхдээ В зангилаа хангалттай нөөцтэй. Үүний үр дүнд kube-хуваарилагч нь нил ягаан өнгийн Pod-ийн очих газрыг В зангилаа гэж шийддэг.

Одоо бид хүссэн нөөцүүд нь Pod-ийг ажиллуулах зангилааны сонголтод хэрхэн нөлөөлж байгааг мэдэж байна. Гэхдээ ахиу нөөцийн нөлөө юу вэ?

Нөөцийн хязгаар нь CPU/MEM-ийн давж гарах боломжгүй хил хязгаар юм. Гэсэн хэдий ч CPU-ийн нөөц нь уян хатан байдаг тул CPU-ийн хязгаарт хүрсэн савнууд нь Pod-оос гарахад хүргэдэггүй. Үүний оронд CPU-ийн тохируулга эхэлнэ. Хэрэв MEM ашиглалтын хязгаарт хүрсэн бол контейнер OOM-Killer-ийн улмаас зогсох бөгөөд RestartPolicy тохиргоонд зөвшөөрвөл дахин эхлүүлэх болно.

Хүссэн болон хамгийн их нөөцийг нарийвчлан

Docker болон Kubernetes хоорондын нөөцийн холбоо

Нөөцийн хүсэлт болон нөөцийн хязгаарлалт хэрхэн ажилладагийг тайлбарлах хамгийн сайн арга бол Кубернетес болон Докер хоёрын харилцааг нэвтрүүлэх явдал юм. Дээрх зурган дээр та Kubernetes талбарууд болон Docker эхлүүлэх тугууд хоорондоо хэрхэн холбогдож байгааг харж болно.

Санах ой: хүсэлт ба хязгаарлалт

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

Дээр дурдсанчлан санах ойг байтаар хэмждэг. Үндэслэн Kubernetes баримт бичиг, бид санах ойг тоогоор зааж өгч болно. Ихэвчлэн энэ нь бүхэл тоо, жишээлбэл 2678, өөрөөр хэлбэл 2678 байт. Та мөн дагаваруудыг ашиглаж болно G и Gi, гол зүйл бол тэдгээр нь тэнцүү биш гэдгийг санах явдал юм. Эхнийх нь аравтын тоо, хоёр дахь нь хоёртын тоо. k8s баримт бичигт дурдсан жишээ шиг: 128974848, 129e6, 129M, 123Mi - тэдгээр нь бараг тэнцүү юм.

Kubernetes сонголт limits.memory тугтай таарч байна --memory Docker-аас. Тохиолдолд request.memory Docker энэ талбарыг ашигладаггүй тул Docker-д зориулсан сум байхгүй. Та асууж магадгүй, энэ нь зайлшгүй шаардлагатай юу? Тиймээ хэрэгтэй. Би өмнө нь хэлсэнчлэн талбай нь Кубернетесийн хувьд чухал юм. Үүнээс авсан мэдээлэлд үндэслэн kube хуваарьлагч нь аль зангилаа Pod-ыг төлөвлөхийг шийддэг.

Хэрэв та хүсэлтийн санах ой хангалтгүй бол яах вэ?

Хэрэв чингэлэг хүссэн санах ойн хязгаарт хүрсэн бол Pod нь зангилаанд хангалттай санах ой байхгүй үед зогсох Pod-ийн бүлэгт байрладаг.

Хэрэв та санах ойн хязгаарыг хэт бага тохируулбал яах вэ?

Хэрэв контейнер санах ойн хязгаараас хэтэрсэн бол OOM-Killed-ийн улмаас дуусгавар болно. Боломжтой бол өгөгдмөл утга нь байгаа RestartPolicy дээр үндэслэн дахин эхлүүлэх болно Always.

Хэрэв та хүссэн санах ойг зааж өгөхгүй бол яах вэ?

Кубернетес хязгаарын утгыг авч, өгөгдмөл утга болгон тохируулах болно.

Хэрэв та санах ойн хязгаарыг заагаагүй бол юу болох вэ?

Контейнер нь ямар ч хязгаарлалтгүй бөгөөд хүссэн хэмжээгээрээ санах ойг ашиглах боломжтой. Хэрэв тэр зангилааны бүх боломжтой санах ойг ашиглаж эхэлбэл OOM түүнийг алах болно. Дараа нь боломжтой бол RestartPolicy дээр үндэслэн контейнер дахин ачаалагдах болно.

Хэрэв та санах ойн хязгаарыг заагаагүй бол яах вэ?

Энэ бол хамгийн муу тохиолдол юм: төлөвлөгч нь контейнерт хичнээн нөөц шаардлагатайг мэдэхгүй бөгөөд энэ нь зангилаа дээр ноцтой асуудал үүсгэж болзошгүй юм. Энэ тохиолдолд нэрийн орон зайд анхдагч хязгаарлалттай байх нь сайхан байх болно (LimitRange-ээр тохируулсан). Анхдагч хязгаарлалт байхгүй - Pod-д хязгаарлалт байхгүй, хүссэн хэмжээгээрээ санах ойг ашиглах боломжтой.

Хэрэв хүссэн санах ой нь зангилааны санал болгож чадах хэмжээнээс их байвал Pod-г төлөвлөхгүй. Үүнийг санах нь чухал Requests.memory - хамгийн бага утга биш. Энэ нь савыг тасралтгүй ажиллуулахад хангалттай санах ойн хэмжээний тодорхойлолт юм.

Ихэвчлэн ижил утгыг тохируулахыг зөвлөж байна request.memory и limit.memory. Энэ нь Pod-г ажиллуулахад хангалттай санах ойтой боловч ажиллуулахад хүрэлцэхгүй байгаа цэг дээр Кубернетес Pod-г төлөвлөхгүй гэдгийг баталгаажуулдаг. Санаж байгаарай: Kubernetes Pod төлөвлөлт нь зөвхөн харгалзан үздэг requests.memoryболон limits.memory тооцдоггүй.

CPU: хүсэлт ба хязгаарлалт

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

CPU-ийн хувьд бүх зүйл арай илүү төвөгтэй байдаг. Кубернетес ба Докер хоёрын харилцааны зураг руу буцаж очоод та үүнийг харж болно request.cpu харгалзана --cpu-shares, харин limit.cpu тугтай таарч байна cpus Docker-д.

Kubernetes-ийн хүссэн CPU-ийг 1024-оор үржүүлж, CPU-ийн мөчлөгийн эзлэх хувь. Хэрэв та 1 бүтэн цөм хүсэхийг хүсвэл нэмэх ёстой cpu: 1дээр үзүүлсэн шиг.

Бүрэн цөм (пропорциональ = 1024) хүсэх нь таны контейнер үүнийг хүлээн авна гэсэн үг биш юм. Хэрэв таны хост машин зөвхөн нэг цөмтэй бөгөөд та нэгээс олон контейнер ажиллуулж байгаа бол бүх контейнерууд боломжтой CPU-г хооронд нь хуваалцах ёстой. Энэ яаж болдог вэ? Зургийг харцгаая.

CPU-ийн хүсэлт - Нэг цөмт систем

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

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

Тооцоолол дээр үндэслэн гурван хүүхэд цөмийг бүхэлд нь биш харин 28% -ийг авна. Дөрөв дэх хүүхэд нь хагас биш харин бүтэн цөмийн 14 хувийг авна. Гэхдээ олон цөмт системтэй бол бүх зүйл өөр байх болно.

CPU-ийн хүсэлт - Олон цөмт (4) систем

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

CPU-ийг контейнеруудад хэрхэн хуваарилдагийг ойлгохын тулд дээрх тооцооллыг хялбаршуулсан болно. Мэдээжийн хэрэг, савнаас гадна CPU-ийн нөөцийг ашигладаг бусад процессууд байдаг. Нэг контейнер дэх процессууд идэвхгүй байх үед бусад нь түүний нөөцийг ашиглах боломжтой. CPU: "200m" харгалзана CPU: 0,2, энэ нь нэг цөмийн ойролцоогоор 20% гэсэн үг.

Одоо ярилцъя limit.cpu. Kubernetes-ийн хязгаарласан CPU-ийг 100-аар үржүүлнэ. Үр дүн нь 100 мкс тутамд контейнер ашиглах хугацаа юм (cpu-period).

limit.cpu Docker тугтай таарч байна --cpus. Энэ бол хуучин шинэ хослол юм --cpu-period и --cpu-quota. Үүнийг тохируулснаар бид тохируулга эхлэхээс өмнө контейнер хамгийн их ашиглаж болох CPU-ийн нөөцийг зааж өгнө.

cpus - хослол cpu-period и cpu-quota. cpus = 1.5 тохируулахтай тэнцэнэ cpu-period = 100000 и cpu-quota = 150000;
CPU-хугацаа - үе CPU CFS төлөвлөгч, анхдагч 100 микросекунд;
cpu-квот - доторх микросекундын тоо cpu-period, энэ нь чингэлэгээр хязгаарлагддаг.

Хэрэв та хүссэн CPU хангалтгүй суулгавал яах вэ?

Хэрэв саванд суулгаснаас илүү их зүйл хэрэгтэй бол бусад процессуудаас CPU хулгайлах болно.

Хэрэв та CPU-ийн хязгаарыг хэт бага тохируулбал яах вэ?

CPU-ийн нөөцийг тохируулах боломжтой тул тохируулагчийг асаах болно.

Хэрэв та CPU-ийн хүсэлтийг заагаагүй бол яах вэ?

Санах ойн нэгэн адил хүсэлтийн утга нь хязгаартай тэнцүү байна.

Хэрэв та CPU-ийн хязгаарыг заагаагүй бол яах вэ?

Контейнер нь шаардлагатай хэмжээгээр CPU ашиглах болно. Хэрэв нэрийн талбарт анхдагч CPU-ийн бодлого (LimitRange) тодорхойлогдсон бол энэ хязгаарыг контейнерт мөн ашиглана.

Хэрэв та хүсэлт эсвэл CPU-ийн хязгаарыг заагаагүй бол яах вэ?

Санах ойн нэгэн адил энэ бол хамгийн муу тохиолдол юм. Төлөвлөгч нь таны чингэлэгт хичнээн их нөөц хэрэгтэйг мэдэхгүй бөгөөд энэ нь зангилаанд ноцтой асуудал үүсгэж болзошгүй юм. Үүнээс зайлсхийхийн тулд та нэрийн орон зайд (LimitRange) өгөгдмөл хязгаарлалт тавих хэрэгтэй.

Санаж байна уу: хэрэв та зангилаануудын өгч чадахаас илүү их CPU шаардвал Pod-г төлөвлөхгүй. Requests.cpu - хамгийн бага утга биш, харин Pod-ыг эхлүүлэх, алдаагүй ажиллахад хангалттай утга. Хэрэв програм нь нарийн төвөгтэй тооцоолол хийхгүй бол хамгийн сайн сонголт бол суулгах явдал юм request.cpu <= 1 шаардлагатай бол олон хуулбарыг ажиллуул.

Хүссэн нөөцийн хамгийн тохиромжтой хэмжээ эсвэл нөөцийн хязгаар

Бид тооцоолох нөөцийн хязгаарлалтын талаар олж мэдсэн. Одоо асуултанд хариулах цаг боллоо: "Миний Pod програмыг ямар ч асуудалгүй ажиллуулахын тулд хичнээн нөөц шаардлагатай вэ? Хамгийн тохиромжтой хэмжээ нь юу вэ?

Харамсалтай нь эдгээр асуултад тодорхой хариулт алга байна. Хэрэв та өөрийн аппликейшн хэрхэн ажилладаг, түүнд хэр их CPU эсвэл санах ой хэрэгтэйг мэдэхгүй байгаа бол хамгийн сайн сонголт бол тухайн программдаа их хэмжээний санах ой, CPU-г өгч, гүйцэтгэлийн тест хийх явдал юм.

Гүйцэтгэлийн туршилтаас гадна долоо хоногийн турш хяналт тавихдаа програмын зан төлөвийг хянах. Хэрэв графикууд таны аппликешн таны хүссэнээс бага нөөц хэрэглэж байгааг харуулж байвал та хүссэн CPU эсвэл санах ойн хэмжээг багасгаж болно.

Үүнийг жишээ болгон харна уу Графана хяналтын самбар. Энэ нь хүссэн нөөц эсвэл нөөцийн хязгаар болон одоогийн нөөцийн ашиглалтын хоорондох ялгааг харуулдаг.

дүгнэлт

Нөөц хүсэх, хязгаарлах нь таны Kubernetes кластерыг эрүүл байлгахад тусална. Хязгаарлалтын зөв тохиргоо нь зардлыг бууруулж, програмуудыг үргэлж ажиллуулдаг.

Товчхондоо, санаж байх ёстой хэд хэдэн зүйл байна:

Хүссэн нөөц бол эхлүүлэх үед (Кубернетес програмыг байршуулахаар төлөвлөж байгаа үед) харгалзан үздэг тохиргоо юм. Үүний эсрэгээр, програм нь зангилаа дээр ажиллаж байх үед нөөцийг хязгаарлах нь чухал юм.
Санах ойтой харьцуулахад CPU нь зохицуулалттай нөөц юм. Хэрэв хангалттай CPU байхгүй бол таны Pod унтрахгүй бөгөөд тохируулагч механизм асаах болно.
Хүссэн нөөц ба нөөцийн хязгаар нь хамгийн бага ба дээд утга биш юм! Хүссэн нөөцийг тодорхойлсноор та програмыг асуудалгүй ажиллуулах болно.
Санах ойн хүсэлтийг санах ойн хязгаартай тэнцүү болгох нь сайн туршлага юм.
За суулгах хүсэлт тавьсан CPU <=1, хэрэв програм нь нарийн төвөгтэй тооцоолол хийхгүй бол.
Хэрэв та зангилаан дээр байгаа нөөцөөс илүү их нөөц хүсэх юм бол Pod-г хэзээ ч тухайн зангилаа руу хуваарь гаргахгүй.
Хүссэн нөөц/нөөцийн хязгаарын зөв хэмжээг тодорхойлохын тулд ачааллын туршилт, хяналтыг ашиглана уу.

Энэ нийтлэл танд нөөцийн хязгаарлалтын үндсэн ойлголтыг ойлгоход тусална гэж найдаж байна. Мөн та энэ мэдлэгийг ажилдаа ашиглах боломжтой болно.

Амжилт хүсье!

Өөр юу унших вэ:

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

Kubernetes Pod-ийн нөөцөд хэрхэн хандах вэ