Дүрмээр бол програмыг зөв, тогтвортой ажиллуулахын тулд тусгай нөөцөөр хангах шаардлагатай байдаг. Гэхдээ хэд хэдэн програм ижил хүчээр ажиллаж байвал яах вэ? Тэд тус бүрийг шаардлагатай хамгийн бага нөөцөөр хэрхэн хангах вэ? Та нөөцийн хэрэглээг хэрхэн хязгаарлах вэ? Зангилаа хоорондын ачааллыг хэрхэн зөв хуваарилах вэ? Хэрэглээний ачаалал нэмэгдвэл хэвтээ масштабын механизм хэрхэн ажиллах вэ?
Та системд ямар үндсэн нөөцүүд байгаа талаар эхлэх хэрэгтэй - энэ нь мэдээжийн хэрэг процессорын цаг ба RAM юм. k8s-д эдгээр нөөцийн төрлийг дараах нэгжээр хэмждэг.
- CPU - цөмд
- RAM - байтаар
Нэмж дурдахад нөөц бүрийн хувьд хоёр төрлийн шаардлага тавих боломжтой. Хүсэлт и хязгаарлалт. Хүсэлт - контейнер ажиллуулах зангилааны чөлөөт нөөцөд тавигдах хамгийн бага шаардлагуудыг (болон бүхэлд нь pod) тайлбарладаг бол хязгаар нь контейнерт байгаа нөөцийн хатуу хязгаарлалтыг тогтоодог.
Манифест нь хоёр төрлийг тодорхой тодорхойлох шаардлагагүй гэдгийг ойлгох нь чухал боловч зан үйл нь дараах байдалтай байна.
- Хэрэв зөвхөн нөөцийн хязгаарыг тодорхой зааж өгсөн бол энэ нөөцийн хүсэлт автоматаар хязгаартай тэнцүү утгыг авна (та үүнийг тайлбарлах нэгж рүү залгаж баталгаажуулж болно). Тэдгээр. үнэндээ савыг ажиллуулахад шаардагдах ижил хэмжээний нөөцөөр хязгаарлагдах болно.
- Хэрэв нөөцөд зөвхөн хүсэлтийг тодорхой зааж өгсөн бол энэ нөөцөд дээд хязгаарлалт тавихгүй. сав нь зөвхөн зангилааны нөөцөөр хязгаарлагддаг.
Мөн нөөцийн удирдлагыг зөвхөн тодорхой контейнерын түвшинд төдийгүй дараах байгууллагуудыг ашиглан нэрийн орон зайн түвшинд тохируулах боломжтой.
- Хязгаарын хүрээ — сав/подны түвшний хязгаарлалтын бодлогыг ns-д тодорхойлсон бөгөөд сав/подны үндсэн хязгаарлалтыг тодорхойлох, түүнчлэн илт тарган сав/под (эсвэл эсрэгээр) үүсэхээс урьдчилан сэргийлэх, тэдгээрийн тоог хязгаарлахад шаардлагатай. хязгаар болон хүсэлтийн утгуудын боломжит зөрүүг тодорхойлох
- Нөөцийн квотууд - ns-ийн бүх контейнерт зориулсан хязгаарлалтын бодлогыг ерөнхийд нь тайлбарлах ба дүрмээр бол орчны хоорондох нөөцийг хязгаарлахад ашигладаг (орчингуудыг зангилааны түвшинд хатуу заагаагүй үед ашигтай)
Дараах нь нөөцийн хязгаарыг тогтоосон манифестуудын жишээ юм:
-
Тодорхой савны түвшинд:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mТэдгээр. Энэ тохиолдолд nginx-тэй контейнер ажиллуулахын тулд танд дор хаяж 1G үнэгүй RAM болон зангилаа дээр 0.2 CPU хэрэгтэй болно, харин хамгийн ихдээ контейнер 0.2 CPU болон зангилаа дээрх бүх боломжтой RAM-г хэрэглэж болно.
-
ns бүхэл тоон түвшинд:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiТэдгээр. өгөгдмөл ns-д байгаа бүх хүсэлтийн контейнерын нийлбэр нь CPU-ийн хувьд 300м, OP-ийн хувьд 1G-ээс хэтрэхгүй байх ба бүх хязгаарын нийлбэр нь CPU-ийн хувьд 700м, OP-ийн хувьд 2G байна.
-
Ns дэх контейнерийн өгөгдмөл хязгаарлалт:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-per-container spec: limits: - type: Container defaultRequest: cpu: 100m memory: 1Gi default: cpu: 1 memory: 2Gi min: cpu: 50m memory: 500Mi max: cpu: 2 memory: 4GiТэдгээр. бүх контейнерийн өгөгдмөл нэрийн талбарт хүсэлтийг CPU-ийн хувьд 100м, OP-ийн хувьд 1G, хязгаар - 1 CPU ба 2G гэж тохируулна. Үүний зэрэгцээ CPU (50м < x < 2) ба RAM (500M < x < 4G) -ийн хүсэлт/хязгаарлалтын боломжит утгуудад хязгаарлалт тавьдаг.
-
Pod түвшний хязгаарлалтууд:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiТэдгээр. өгөгдмөл ns-ийн pod тус бүрийн хувьд 4 vCPU болон 1G-ийн хязгаар байх болно.
Одоо би эдгээр хязгаарлалтыг тогтоох нь бидэнд ямар давуу талтай болохыг хэлмээр байна.
Зангилаа хоорондын ачааллыг тэнцвэржүүлэх механизм
Та бүхний мэдэж байгаагаар k8s бүрэлдэхүүн хэсэг нь зангилааны хооронд хонхорцог хуваарилах үүрэгтэй, тухайлбал хуваарилагч, энэ нь тодорхой алгоритмын дагуу ажилладаг. Энэ алгоритм нь эхлүүлэх оновчтой зангилаа сонгохдоо хоёр үе шатыг дамждаг.
- шүүлт
- Хүрээлэн буй
Тэдгээр. тайлбарласан бодлогын дагуу эхлээд багц дээр тулгуурлан pod ажиллуулах боломжтой зангилаанууд сонгогддог предикатууд (зангилаа нь подыг ажиллуулахад хангалттай нөөц байгаа эсэхийг шалгах - PodFitsResources), дараа нь эдгээр зангилаа тус бүрийн дагуу тэргүүлэх чиглэлүүд оноо өгдөг (үүнд зангилаа чөлөөтэй нөөцтэй байх тусам илүү олон оноо оноодог - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) ба подыг хамгийн олон оноотой зангилаа дээр ажиллуулна (хэрэв хэд хэдэн зангилаа энэ нөхцлийг нэгэн зэрэг хангаж байвал дараа нь) санамсаргүй нэгийг сонгосон).
Үүний зэрэгцээ, төлөвлөгч нь зангилааны боломжит нөөцийг үнэлэхдээ etcd-д хадгалагдсан өгөгдлөөр удирддаг гэдгийг та ойлгох хэрэгтэй. Энэ зангилаа дээр ажиллаж байгаа под тус бүрийн хүссэн/хязгаарлах нөөцийн хэмжээгээр, гэхдээ бодит нөөцийн зарцуулалтад биш. Энэ мэдээллийг тушаалын гаралтаас авч болно kubectl describe node $NODEЖишээ нь:
# kubectl describe nodes nxs-k8s-s1
..
Non-terminated Pods: (9 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
ingress-nginx nginx-ingress-controller-754b85bf44-qkt2t 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system kube-flannel-26bl4 150m (0%) 300m (1%) 64M (0%) 500M (1%) 233d
kube-system kube-proxy-exporter-cb629 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system kube-proxy-x9fsc 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system nginx-proxy-k8s-worker-s1 25m (0%) 300m (1%) 32M (0%) 512M (1%) 233d
nxs-monitoring alertmanager-main-1 100m (0%) 100m (0%) 425Mi (1%) 25Mi (0%) 233d
nxs-logging filebeat-lmsmp 100m (0%) 0 (0%) 100Mi (0%) 200Mi (0%) 233d
nxs-monitoring node-exporter-v4gdq 112m (0%) 122m (0%) 200Mi (0%) 220Mi (0%) 233d
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 487m (3%) 822m (5%)
memory 15856217600 (2%) 749976320 (3%)
ephemeral-storage 0 (0%) 0 (0%)Энд бид тодорхой зангилаа дээр ажиллаж байгаа бүх pods, түүнчлэн под тус бүрийн хүссэн нөөцүүдийг харж байна. Мөн cronjob-cron-events-1573793820-xt6q9 pod-ыг ажиллуулах үед хуваарийн бүртгэлүүд хэрхэн харагдахыг энд харуулав (энэ мэдээлэл нь эхлүүлэх командын аргументуудад 10-р бүртгэлийн түвшинг тохируулах үед төлөвлөгчийн бүртгэлд харагдах болно -v=10 ):
бүртгэл
I1115 07:57:21.637791 1 scheduling_queue.go:908] About to try and schedule pod nxs-stage/cronjob-cron-events-1573793820-xt6q9
I1115 07:57:21.637804 1 scheduler.go:453] Attempting to schedule pod: nxs-stage/cronjob-cron-events-1573793820-xt6q9
I1115 07:57:21.638285 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s5 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638300 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s6 is allowed, Node is running only 20 out of 110 Pods.
I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s3 is allowed, Node is running only 20 out of 110 Pods.
I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s4 is allowed, Node is running only 17 out of 110 Pods.
I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638365 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s12 is allowed, Node is running only 9 out of 110 Pods.
I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s11 is allowed, Node is running only 11 out of 110 Pods.
I1115 07:57:21.638385 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s1 is allowed, Node is running only 19 out of 110 Pods.
I1115 07:57:21.638402 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s2 is allowed, Node is running only 21 out of 110 Pods.
I1115 07:57:21.638383 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638335 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, Node is running only 18 out of 110 Pods.
I1115 07:57:21.638408 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s13 is allowed, Node is running only 8 out of 110 Pods.
I1115 07:57:21.638478 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638505 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638577 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638583 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s7 is allowed, Node is running only 25 out of 110 Pods.
I1115 07:57:21.638932 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 9
I1115 07:57:21.638946 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 8
I1115 07:57:21.638961 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: BalancedResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 9
I1115 07:57:21.638971 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7
I1115 07:57:21.638975 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: LeastResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 8
I1115 07:57:21.638990 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7
I1115 07:57:21.639022 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639030 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639034 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639041 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639053 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639059 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639061 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639063 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639073 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639077 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639085 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639088 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639103 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639109 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639114 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639127 1 generic_scheduler.go:781] Host nxs-k8s-s10 => Score 100037
I1115 07:57:21.639150 1 generic_scheduler.go:781] Host nxs-k8s-s8 => Score 100034
I1115 07:57:21.639154 1 generic_scheduler.go:781] Host nxs-k8s-s9 => Score 100037
I1115 07:57:21.639267 1 scheduler_binder.go:269] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10"
I1115 07:57:21.639286 1 scheduler_binder.go:279] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10": all PVCs bound and nothing to do
I1115 07:57:21.639333 1 factory.go:733] Attempting to bind cronjob-cron-events-1573793820-xt6q9 to nxs-k8s-s10Эндээс бид эхлээд хуваарьлагч нь ажиллуулж болох 3 зангилааны жагсаалтыг шүүж, үүсгэдэг болохыг харж байна (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Дараа нь хамгийн тохиромжтой зангилааг тодорхойлохын тулд эдгээр зангилаа тус бүрийн хувьд хэд хэдэн параметрт (BalancedResourceAllocation, LeastResourceAllocation орно) үндэслэн оноог тооцдог. Эцсийн эцэст, хонхорцог хамгийн олон оноотой зангилаа дээр хуваарилагдана (энд нэг дор хоёр зангилаа ижил тооны 100037 оноотой тул санамсаргүй нэгийг сонгосон - nxs-k8s-s10).
дүгнэлт: хэрэв зангилаа нь ямар ч хязгаарлалт тавиагүй pods ажиллуулдаг бол k8-ийн хувьд (нөөцийн хэрэглээний үүднээс) энэ нь энэ зангилаа дээр огт байхгүй байсантай тэнцэх болно. Тиймээс, хэрэв та болзолтоор, өлөн зэлмүүн үйл явцтай (жишээ нь, wowza) хонхорхойтой бөгөөд түүнд ямар ч хязгаарлалт тогтоогдоогүй бол энэ хонхорцог зангилааны бүх нөөцийг идэж байсан нөхцөл байдал үүсч магадгүй юм, гэхдээ k8s-ийн хувьд энэ зангилаа. нь ачаалалгүй гэж тооцогдох бөгөөд энэ нь зангилааны хооронд ачааллыг жигд бус хуваарилахад хүргэж болохуйц ажиллах хонхорцоггүй зангилааг (боломжтой нөөцийг үнэлэх оноогоор нарийн) зэрэглэхдээ ижил тооны оноо олгоно.
Подыг нүүлгэх
Та бүхний мэдэж байгаагаар pod тус бүрт 3 QoS ангиллын аль нэгийг оноодог:
- баталгаатай - хонхорцог дахь контейнер бүрт санах ой болон CPU-ийн хүсэлт, хязгаарлалтыг зааж өгсөн бөгөөд эдгээр утгууд нь таарч байх ёстой.
- тэсрэх боломжтой — хонхорцог дахь дор хаяж нэг чингэлэгт хүсэлт, хязгаарлалт байгаа бөгөөд хүсэлт < хязгаартай
- хамгийн сайн хүчин чармайлт - хонхорцог дахь ганц ч сав нөөц хязгаарлагдмал үед
Үүний зэрэгцээ, зангилаа нөөц (диск, санах ой) дутагдалтай үед kubelet pod-ийн тэргүүлэх ач холбогдол, түүний QoS ангиллыг харгалзан үзсэн тодорхой алгоритмын дагуу pods-ыг эрэмбэлж, зайлуулж эхэлдэг. Жишээлбэл, хэрэв бид RAM-ийн тухай ярьж байгаа бол QoS ангилалд үндэслэн оноог дараахь зарчмын дагуу олгоно.
- Баталгаат: -нэг
- Хамгийн сайн хүчин чармайлт: 1000
- Тэсрэх чадвартай: мин(хамгийн ихдээ (2, 1000 - (1000 * санах ойн хүсэлт байт) / machineMemoryCapacityBytes), 999)
Тэдгээр. ижил давуу эрхтэйгээр kubelet эхлээд зангилаанаас хамгийн сайн хүчин чармайлт бүхий QoS ангиллын хонхорцогуудыг зайлуулна.
дүгнэлт: Хэрэв та нөөц байхгүй тохиолдолд хүссэн подволкийг зангилаанаас гаргах магадлалыг багасгахыг хүсвэл тэргүүлэх ач холбогдол өгөхийн зэрэгцээ түүнд зориулсан хүсэлт/хязгаарыг тогтооход анхаарах хэрэгтэй.
Хэрэглээний хонхорцог (HPA) хэвтээ автоматаар масштаблах механизм
Даалгавар нь нөөцийн ашиглалтаас (систем - CPU/RAM эсвэл хэрэглэгч - rps) хамааран pods-ийн тоог автоматаар нэмэгдүүлэх, багасгах үед ийм k8s аж ахуйн нэгж. HPA (Хэвтээ Pod Autoscaler). Үүний алгоритм нь дараах байдалтай байна.
- Ажиглагдсан нөөцийн одоогийн уншилтыг тодорхойлно (currentMetricValue)
- Нөөцийн хүссэн утгуудыг (desiredMetricValue) тодорхойлдог бөгөөд үүнийг системийн нөөцөд хүсэлтийг ашиглан тохируулдаг.
- Одоогийн хуулбаруудын тоог тодорхойлсон (одоогийн хуулбар)
- Дараах томьёо нь хүссэн хуулбарын тоог (desiredReplicas) тооцоолно.
wantdReplicas = [ currentReplicas * ( currentMetricValue / desiredMetricValue )]
Энэ тохиолдолд коэффициент (currentMetricValue / desiredMetricValue) 1-тэй ойролцоо байх үед масштаб хийхгүй (энэ тохиолдолд бид зөвшөөрөгдөх алдааг өөрсдөө тохируулж болно; анхдагчаар энэ нь 0.1 байна).
CPU-ийн зарцуулалтаас хамааран хуулбарын тоог өөрчлөх шаардлагатай байгаа програмын туршилтын програмын жишээг (Байршуулах гэж тодорхойлсон) ашиглан hpa хэрхэн ажилладагийг харцгаая.
-
Хэрэглээний манифест
kind: Deployment apiVersion: apps/v1beta2 metadata: name: app-test spec: selector: matchLabels: app: app-test replicas: 2 template: metadata: labels: app: app-test spec: containers: - name: nginx image: registry.nixys.ru/generic-images/nginx imagePullPolicy: Always resources: requests: cpu: 60m ports: - name: http containerPort: 80 - name: nginx-exporter image: nginx/nginx-prometheus-exporter resources: requests: cpu: 30m ports: - name: nginx-exporter containerPort: 9113 args: - -nginx.scrape-uri - http://127.0.0.1:80/nginx-statusТэдгээр. Програмын pod нь эхлээд хоёр тохиолдолд нээгдэж байгааг бид харж байна, тус бүр нь хоёр nginx болон nginx-экспортлогч контейнер агуулсан бөгөөд тус бүрдээ заасан Хүсэлт CPU-ийн хувьд.
-
HPA тунхаг
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: app-test-hpa spec: maxReplicas: 10 minReplicas: 2 scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: app-test metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 30Тэдгээр. Бид суулгацын програмын тестийг хянаж, процессорын индикатор дээр тулгуурлан (бид энэ подволк нь өөрийн хүссэн CPU-ийн 30%-ийг зарцуулна гэж тооцоолдог) програмын тусламжтайгаар тохируулга хийх hpa-г үүсгэсэн. 2-10 хооронд хэлбэлздэг.
Одоо, хэрэв бид зуухны аль нэгэнд ачаалал өгөх тохиолдолд hpa-ийн үйл ажиллагааны механизмыг харцгаая.
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Нийтдээ бидэнд дараахь зүйлс байна.
- Хүссэн утга (хүссэн MetricValue) - hpa тохиргооны дагуу бид 30% байна.
- Одоогийн утга (currentMetricValue) - тооцооллын хувьд хянагч-менежер нь нөөцийн хэрэглээний дундаж утгыг % -аар тооцдог, өөрөөр хэлбэл. нөхцөлтэйгээр дараахь зүйлийг хийнэ.
- Метрийн серверээс под хэмжүүрүүдийн үнэмлэхүй утгыг хүлээн авдаг, жишээлбэл. 101м ба 4м
- Дундаж үнэмлэхүй утгыг тооцоолно, өөрөөр хэлбэл. (101м + 4м) / 2 = 53м
- Хүссэн нөөцийн хэрэглээний үнэмлэхүй утгыг авна (үүнд бүх савны хүсэлтийг нэгтгэн харуулав) 60м + 30м = 90м
- Хүсэлтийн хэсэгтэй харьцуулахад CPU-ийн хэрэглээний дундаж хувийг тооцоолно, i.e. 53м / 90м * 100% = 59%
Одоо бидэнд хуулбарын тоог өөрчлөх шаардлагатай эсэхийг тодорхойлоход шаардлагатай бүх зүйл байгаа бөгөөд үүнийг хийхийн тулд бид коэффициентийг тооцоолно.
ratio = 59% / 30% = 1.96
Тэдгээр. хуулбарын тоог ~2 дахин нэмэгдүүлж, [2 * 1.96] = 4 байх ёстой.
Дүгнэлт: Таны харж байгаагаар энэ механизм ажиллахын тулд зайлшгүй нөхцөл бол ажиглагдсан хонхорцог дахь бүх савны хүсэлт байх явдал юм.
Зангилааны хэвтээ автомат масштабын механизм (Cluster Autoscaler)
Ачааллын өсөлтийн үед системд үзүүлэх сөрөг нөлөөллийг саармагжуулахын тулд тохируулсан hpa байх нь хангалтгүй юм. Жишээлбэл, hpa хянагч менежерийн тохиргооны дагуу хуулбарын тоог 2 дахин нэмэгдүүлэх шаардлагатай гэж шийдсэн боловч зангилаанууд ийм тооны подсыг ажиллуулах үнэгүй нөөцгүй байдаг (жишээ нь, зангилаа нь үүнийг хангаж чадахгүй. Хүссэн нөөцийг хүсэлтийн хэсэг рүү шилжүүлэх) ба эдгээр подкууд Хүлээгдэж буй төлөв рүү шилжинэ.
Энэ тохиолдолд, хэрэв үйлчилгээ үзүүлэгч нь тохирох IaaS/PaaS (жишээ нь, GKE/GCE, AKS, EKS гэх мэт) байвал дараах хэрэгсэл Node Autoscaler. Энэ нь кластер дахь зангилааны хамгийн дээд ба хамгийн бага тоог тохируулах боломжийг олгодог бөгөөд кластер болон pods-д нөөц хомс байгаа үед одоогийн зангилааны тоог автоматаар тохируулах боломжийг олгодог (үүлэн үйлчилгээ үзүүлэгч API руу залгаж зангилаа захиалах/ устгах) төлөвлөх боломжгүй (Хүлээгдэж буй төлөвт байна).
Дүгнэлт: Зангилааг автоматаар масштаблахын тулд k8-ууд зангилааны ачааллыг зөв үнэлж, улмаар кластерт дараагийн подволкийг эхлүүлэх нөөц байхгүй гэж мэдээлэхийн тулд pod контейнерт хүсэлт тавих шаардлагатай.
дүгнэлт
Контейнерийн нөөцийн хязгаарыг тохируулах нь програмыг амжилттай ажиллуулахад тавигдах шаардлага биш боловч дараах шалтгааны улмаас үүнийг хийх нь дээр гэдгийг тэмдэглэх нь зүйтэй.
- k8s зангилааны хооронд ачааллыг тэнцвэржүүлэх хувьд хуваарьлагчийг илүү нарийвчлалтай ажиллуулахын тулд
- "Под нүүлгэн шилжүүлэх" үйл явдлын магадлалыг бууруулах
- Хэрэглээний хонхорцог (HPA)-ийн хэвтээ автомат масштабаар ажиллахын тулд
- Үүлэн үйлчилгээ үзүүлэгчдэд зориулсан зангилааны хэвтээ автомат масштабын хувьд (Cluster Autoscaling).
Мөн манай блог дээрх бусад нийтлэлүүдийг уншина уу:
Эх сурвалж: www.habr.com