Аппликешныг Kubernetes руу шилжүүлэхэд хангалттай гэж олон хүмүүс (Helm ашиглан эсвэл гараар) итгэдэг бөгөөд тэд баяртай байх болно. Гэхдээ энэ нь тийм ч энгийн зүйл биш юм.
баг DevOps инженер Жулиан Гиндигийн нийтлэлийг орчуулав. Та нэг тармуур дээр гишгэхгүйн тулд шилжин суурьших явцад компанидаа тулгарч байсан бэрхшээлүүдийг тэр хуваалцдаг.
Нэгдүгээр алхам: Pod хүсэлт болон хязгаарыг тохируулах
Манай хонхорхойнууд гүйх цэвэр орчинг бүрдүүлж эхэлцгээе. Кубернетес нь хонгилын хуваарь гаргах, бүтэлгүйтлийн нөхцөлийг зохицуулах ажлыг маш сайн гүйцэтгэдэг. Гэхдээ амжилттай ажиллахын тулд хичнээн нөөц хэрэгтэйг тооцоолоход хэцүү бол төлөвлөгч заримдаа pod байрлуулж чаддаггүй нь тогтоогдсон. Эндээс нөөц, хязгаарлалтын хүсэлт гарч ирдэг. Хүсэлт, хязгаарлалт тогтоох хамгийн сайн арга барилын талаар маш их маргаан байдаг. Заримдаа үнэхээр шинжлэх ухаан гэхээсээ илүү урлаг юм шиг санагддаг. Бидний арга барил энд байна.
Pod хүсэлт - Энэ бол подволкийг оновчтой байрлуулахын тулд төлөвлөгчийн ашигладаг гол утга юм.
Эхлээд : Шүүлтүүрийн алхам нь pod-ыг төлөвлөж болох цэгүүдийн багцыг тодорхойлдог. Жишээлбэл, PodFitsResources шүүлтүүр нь зангилаа нь pod-ийн тодорхой нөөцийн хүсэлтийг хангах хангалттай нөөцтэй эсэхийг шалгадаг.
Бид програмын хүсэлтийг ашигладаг бөгөөд ингэснээр хэчнээн нөөцийг тооцоолоход ашиглаж болно Үнэндээ Аппликешн зөв ажиллахад шаардлагатай. Ингэснээр төлөвлөгч зангилааг бодитоор байрлуулж чадна. Бид эхлээд под тус бүр хангалттай олон тооны нөөцтэй байхын тулд хүсэлтүүдийг маржингаар тохируулахыг хүссэн боловч хуваарь гаргах хугацаа мэдэгдэхүйц нэмэгдэж, зарим нэг хэсэг нь нөөцийн хүсэлтийг хүлээж аваагүй мэт хэзээ ч бүрэн төлөвлөгдөөгүй байгааг анзаарсан.
Энэ тохиолдолд төлөвлөлтийн алгоритмын гол бүрэлдэхүүн хэсэг болох программыг хэрэгжүүлэхэд хичнээн их нөөц шаардагдахыг удирдлагын хавтгайд мэдэхгүй байсан тул хуваарь гаргагч нь ихэвчлэн подволкуудыг шахаж, дахин төлөвлөх боломжгүй байдаг.
Под хязгаар - энэ нь хонгилын хувьд илүү тодорхой хязгаар юм. Энэ нь кластераас контейнерт хуваарилах нөөцийн дээд хэмжээг илэрхийлнэ.
Дахин хэлэхэд, -аас : Хэрэв саванд 4 ГБ санах ойн хязгаар тогтоосон бол kubelet (болон контейнерын ажиллах хугацаа) үүнийг хэрэгжүүлэх болно. Ашиглалтын хугацаа нь заасан нөөцийн хязгаараас илүүг ашиглахыг чингэлэгт зөвшөөрдөггүй. Жишээлбэл, саванд байгаа процесс зөвшөөрөгдөх хэмжээнээс илүү санах ой ашиглахыг оролдох үед системийн цөм "санах ойгүй" (OOM) алдаагаар үйл явцыг зогсоодог.
Контейнер нь нөөцийн хүсэлтэд зааснаас илүү их нөөцийг үргэлж ашиглаж болох боловч хязгаарт заасан хэмжээнээс илүүг хэзээ ч ашиглаж чадахгүй. Энэ утгыг зөв тогтооход хэцүү боловч энэ нь маш чухал юм.
Бид системийн бусад процессуудад саад учруулахгүйгээр үйл явцын амьдралын мөчлөгийн туршид pod-ийн нөөцийн хэрэгцээг өөрчлөхийг хүсч байна - энэ бол хязгаарлалт тогтоох зорилго юм.
Харамсалтай нь би ямар утгыг тохируулах талаар тодорхой заавар өгөх боломжгүй, гэхдээ бид өөрсдөө дараах дүрмийг баримталдаг.
- Ачааллыг шалгах хэрэглүүрийг ашиглан бид замын хөдөлгөөний суурь түвшинг дуурайж, под нөөцийн (санах ой, процессор) ашиглалтыг хянадаг.
- Бид pod хүсэлтүүдийг дур зоргоороо бага утгаар (хүсэлтийн утгаас 5 дахин их нөөцийн хязгаартай) тохируулж, ажиглана. Хүсэлтүүд хэтэрхий бага байвал процесс эхлэх боломжгүй бөгөөд энэ нь ихэвчлэн Go ажиллах үеийн нууцлаг алдааг үүсгэдэг.
Под хангалттай нөөцтэй зорилтот зангилаа хэрэгтэй тул нөөцийн дээд хязгаар нь хуваарийг илүү төвөгтэй болгодог гэдгийг анхаарна уу.
Та маш өндөр нөөцийн хязгаартай, 4 ГБ санах ойтой хөнгөн жинтэй вэб сервертэй байгаа нөхцөл байдлыг төсөөлөөд үз дээ. Энэ процесс нь хэвтээ байдлаар томрох ёстой бөгөөд шинэ модуль бүрийг дор хаяж 4 ГБ санах ойтой зангилаа дээр төлөвлөх шаардлагатай болно. Хэрэв тийм зангилаа байхгүй бол кластер нь тухайн подволыг боловсруулахын тулд шинэ зангилаа нэвтрүүлэх ёстой бөгөөд үүнд хэсэг хугацаа зарцуулагдана. Хурдан бөгөөд жигд масштабыг хангахын тулд нөөцийн хүсэлт болон хязгаарлалтын ялгааг хамгийн бага хэмжээнд байлгах нь чухал юм.
Хоёрдугаар алхам: Амьдрах болон бэлэн байдлын тестийг тохируулах
Энэ бол Кубернетес нийгэмлэгт ихэвчлэн яригддаг өөр нэг нарийн сэдэв юм. Амьдрах, бэлэн байдлын тест нь програм хангамжийг жигд ажиллуулж, сул зогсолтыг багасгах механизмыг бүрдүүлдэг тул тэдгээрийн талаар сайн ойлголттой байх нь чухал юм. Гэсэн хэдий ч тэдгээр нь зөв тохируулаагүй тохиолдолд таны програмын гүйцэтгэлд ноцтой хохирол учруулж болзошгүй юм. Доорх хоёр дээж ямар байгааг тоймлон харуулав.
Амьдрал сав ажиллаж байгаа эсэхийг харуулдаг. Хэрэв бүтэлгүйтвэл kubelet савыг устгаж, дахин эхлүүлэх бодлогыг идэвхжүүлнэ. Хэрэв чингэлэг нь Liveness датчикаар тоноглогдоогүй бол анхдагч төлөв амжилттай байх болно - энэ нь энд бичсэн зүйл юм. .
Амьдрах датчик нь хямд байх ёстой, учир нь тэд байнга ажилладаг тул Кубернетесэд програм ажиллаж байгаа талаар мэдэгдэх шаардлагатай байдаг тул их хэмжээний нөөц ашиглах ёсгүй.
Хэрэв та секунд тутамд ажиллах сонголтыг хийвэл энэ нь секундэд 1 хүсэлтийг нэмэх тул энэ урсгалыг зохицуулахад нэмэлт эх үүсвэр шаардлагатай болно гэдгийг анхаарна уу.
Манай компанид Liveness тест нь өгөгдөлд (жишээлбэл, алсын мэдээллийн сан эсвэл кэшээс) бүрэн хандах боломжгүй байсан ч програмын үндсэн бүрэлдэхүүн хэсгүүдийг шалгадаг.
Бид програмуудыг "эрүүл мэндийн" төгсгөлийн цэгээр тохируулсан бөгөөд энэ нь ердөө л 200 гэсэн хариултын кодыг буцаадаг. Энэ нь процесс ажиллаж байгаа бөгөөд хүсэлтийг боловсруулах чадвартай (гэхдээ траффик хараахан болоогүй) байгааг харуулж байна.
Жишээ Бэлэн байдал чингэлэг нь хүсэлтэд үйлчлэхэд бэлэн эсэхийг заана. Хэрэв бэлэн байдлын шалгалт амжилтгүй болвол төгсгөлийн цэгийн хянагч нь подволд харгалзах бүх үйлчилгээний төгсгөлийн цэгүүдээс pod-ийн IP хаягийг устгадаг. Үүнийг Кубернетесийн баримт бичигт мөн дурдсан байдаг.
Бэлэн байдлын шалгалтууд нь хүсэлтийг хүлээн авахад бэлэн байгааг илтгэх байдлаар арын хэсэгт илгээгдэх ёстой тул илүү их нөөц зарцуулдаг.
Мэдээллийн санд шууд хандах эсэх талаар нийгэмд маш их маргаан өрнөж байна. Нэмэлт ачааллыг харгалзан (шалгалтыг байнга хийдэг, гэхдээ тохируулж болно) бид зарим програмын хувьд мэдээллийн сангаас бүртгэлийг буцаасан эсэхийг шалгасны дараа л замын хөдөлгөөнд үйлчлэх бэлэн байдлыг тооцохоор шийдсэн. Сайтар боловсруулсан бэлэн байдлын туршилтууд нь өндөр түвшний хүртээмжийг баталгаажуулж, байршуулах явцад зогсолтыг арилгасан.
Хэрэв та өөрийн өргөдлийн бэлэн байдлыг шалгахын тулд мэдээллийн сангаас асуухаар шийдсэн бол энэ нь аль болох хямд эсэхийг шалгаарай. Энэ хүсэлтийг авч үзье:
SELECT small_item FROM table LIMIT 1Бид эдгээр хоёр утгыг Kubernetes дээр хэрхэн тохируулах жишээг энд харуулав.
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
Та нэмэлт тохиргооны сонголтуудыг нэмж болно:
initialDelaySeconds- савыг хөөргөхөөс дээж авах хооронд хэдэн секунд өнгөрөх вэ.periodSeconds- дээжийн гүйлтийн хоорондох хүлээх интервал.timeoutSeconds- нэгжийг яаралтай тусламж гэж тооцсон секундын тоо. Тогтмол завсарлага.failureThreshold- дахин асаах дохиог pod руу илгээхээс өмнөх туршилтын алдааны тоо.successThreshold- хонхорцог бэлэн байдалд орохоос өмнөх амжилттай датчикуудын тоо (бүтэлгүйтлийн дараа, хонхорцог эхлэх эсвэл сэргэх үед).
Гуравдугаар алхам: pod-д зориулсан сүлжээний өгөгдмөл бодлогыг тохируулах
Кубернетес нь "хавтгай" сүлжээний топографтай бөгөөд анхдагчаар бүх pods нь хоорондоо шууд холбогддог. Зарим тохиолдолд энэ нь хүсээгүй юм.
Аюулгүй байдлын боломжит асуудал бол халдагчид сүлжээний бүх pods руу урсгалыг илгээхийн тулд нэг эмзэг програмыг ашиглаж болох явдал юм. Аюулгүй байдлын олон салбарын нэгэн адил энд хамгийн бага давуу эрхийн зарчим үйлчилдэг. Сүлжээний бодлого нь подсуудын хооронд ямар холболтыг зөвшөөрч, аль нь зөвшөөрөгдөөгүйг тодорхой зааж өгөх ёстой.
Жишээлбэл, тодорхой нэрийн орон зайд ирж буй бүх урсгалыг үгүйсгэх энгийн бодлогыг доор харуулав.
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
Энэ тохиргооны дүрслэл:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
Илүү дэлгэрэнгүй мэдээлэл .
Дөрөвдүгээр алхам: дэгээ болон эхлэлийн савыг ашиглан захиалгат зан үйл
Бидний гол зорилгын нэг бол хөгжүүлэгчдэд зогсолтгүйгээр Kubernetes-д байршуулалтыг хангах явдал байв. Аппликешнүүдийг хааж, ашигласан нөөцийг чөлөөлөх олон сонголт байдаг тул энэ нь хэцүү байдаг.
Онцгой бэрхшээлүүд гарч ирэв . Эдгээр хонхорцогуудыг дараалан байрлуулах үед идэвхтэй холболтууд амжилттай дуусахаас өмнө тасарсныг бид анзаарсан.
Онлайнаар өргөн хүрээтэй судалгаа хийсний дараа Кубернетес pod-ийг зогсоохоос өмнө Nginx холболтууд дуусахыг хүлээдэггүй нь тогтоогджээ. Урьдчилан зогсоох дэгээ ашиглан бид дараах функцийг хэрэгжүүлж, зогсолтоос бүрэн ангижрав.
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
Гэхдээ nginx-killer.sh:
#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
echo "Waiting while shutting down nginx..."
sleep 10
done
Өөр нэг маш хэрэгтэй парадигм бол тодорхой програмуудыг эхлүүлэхэд зориулсан init контейнеруудыг ашиглах явдал юм. Энэ нь танд хэрэглүүр эхлэхээс өмнө ажиллах шаардлагатай мэдээллийн санд шилжих процесс байгаа бол ялангуяа ашигтай байдаг. Та мөн үндсэн програмд ийм хязгаарлалт тавихгүйгээр энэ процессын нөөцийн дээд хязгаарыг зааж өгч болно.
Өөр нэг нийтлэг схем бол тэдгээр итгэмжлэлүүдийг үндсэн модульд өгдөг init контейнер дэх нууцад хандах бөгөөд энэ нь үндсэн програмын модулийн нууцад зөвшөөрөлгүй нэвтрэхээс сэргийлдэг.
Ердийнх шигээ баримтаас иш татна: Init контейнерууд нь тусгай код эсвэл хэрэглүүрийг аюулгүй ажиллуулдаг бөгөөд өөрөөр хэлбэл програмын контейнерийн дүрсний хамгаалалтыг бууруулдаг. Шаардлагагүй хэрэгслүүдийг тусад нь байлгаснаар та програмын контейнерийн дүрсний халдлагын гадаргууг хязгаарлана.
Тавдугаар алхам: Цөмийг тохируулах
Эцэст нь илүү дэвшилтэт техникийн талаар ярилцъя.
Kubernetes бол маш уян хатан платформ бөгөөд танд ажлын ачааллыг өөрийн үзэмжээр гүйцэтгэх боломжийг олгодог. Бидэнд маш их нөөц шаардсан өндөр гүйцэтгэлтэй хэд хэдэн програмууд бий. Ачаалал ихтэй туршилт хийсний дараа бид Kubernetes-ийн анхдагч тохиргоо ажиллаж байх үед нэг програм нь хүлээгдэж буй ачааллыг даван туулахад бэрхшээлтэй байгааг олж мэдсэн.
Гэсэн хэдий ч, Kubernetes нь зөвхөн тодорхой pod-д зориулж цөмийн параметрүүдийг өөрчилдөг давуу эрхтэй контейнер ажиллуулах боломжийг олгодог. Нээлттэй холболтын хамгийн их тоог өөрчлөхөд бид дараах зүйлсийг ашигладаг:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
Энэ нь ихэвчлэн шаардлагагүй байдаг илүү дэвшилтэт техник юм. Гэхдээ хэрэв таны програм хүнд ачааллыг даван туулахад бэрхшээлтэй байгаа бол та эдгээр тохиргоонуудын заримыг өөрчлөхийг оролдож болно. Энэ үйл явцын талаар дэлгэрэнгүй мэдээлэл, өөр өөр утгыг тохируулах - үргэлж байдаг .
Эцэст нь хэлэхэд
Кубернетес нь хайрцагнаас гарсан бэлэн шийдэл мэт санагдаж болох ч програмуудаа хэвийн ажиллуулахын тулд хэд хэдэн үндсэн алхмуудыг хийх шаардлагатай.
Kubernetes-ийн шилжилт хөдөлгөөний туршид "ачааллын туршилтын мөчлөг"-ийг дагаж мөрдөх нь чухал юм: програмыг ажиллуулж, ачаалж туршаад, хэмжигдэхүүн болон масштабын үйлдлийг ажиглаж, тэр өгөгдөл дээр үндэслэн тохиргоог тохируулаад дараа нь мөчлөгийг дахин давт.
Хүлээгдэж буй замын хөдөлгөөний талаар бодитой байж, аль бүрэлдэхүүн хэсэг нь эхлээд эвдэрч байгааг харахын тулд түүнээс цааш түлхэхийг хичээ. Энэхүү давталттай аргын тусламжтайгаар амжилтанд хүрэхийн тулд жагсаасан зөвлөмжүүдийн хэдхэн нь хангалттай байж болно. Эсвэл илүү гүнзгийрүүлэн тохируулах шаардлагатай байж магадгүй юм.
Эдгээр асуултуудыг өөрөөсөө үргэлж асуу.
- Аппликейшн хэр их нөөц хэрэглэдэг бөгөөд энэ хэмжээ хэрхэн өөрчлөгдөх вэ?
- Жинхэнэ масштабын шаардлага юу вэ? Аппликешн дунджаар хэр их ачаалал даах вэ? Замын хөдөлгөөний оргил ачааллын талаар юу хэлэх вэ?
- Үйлчилгээг хэвтээ байдлаар хэр олон удаа масштаблах шаардлагатай вэ? Замын хөдөлгөөнийг хүлээн авахын тулд шинэ хонхорцог онлайнаар хэр хурдан оруулах шаардлагатай вэ?
- Дотор нь хэр зөв унтрах вэ? Энэ ер нь шаардлагатай юу? Сул зогсолтгүйгээр байршуулалтад хүрэх боломжтой юу?
- Та аюулгүй байдлын эрсдлийг хэрхэн багасгаж, эвдэрсэн хонхорцогоос үүсэх хохирлыг хязгаарлах вэ? Ямар нэгэн үйлчилгээнд шаардлагагүй зөвшөөрөл эсвэл хандалт байдаг уу?
Kubernetes нь кластерт мянга мянган үйлчилгээг ашиглах шилдэг туршлагыг ашиглах боломжийг олгодог гайхалтай платформоор хангадаг. Гэсэн хэдий ч програм бүр өөр өөр байдаг. Заримдаа хэрэгжилт нь арай илүү ажил шаарддаг.
Аз болоход Кубернетес нь техникийн бүх зорилгод хүрэхийн тулд шаардлагатай тохиргоог өгдөг. Нөөцийн хүсэлт, хязгаарлалт, Амьдрах байдал, Бэлэн байдлын датчик, эхлүүлэх контейнер, сүлжээний бодлого, цөмийн тохируулгын хослолыг ашигласнаар та алдааг тэсвэрлэх чадвар, хурдацтай өргөтгөх чадвартай байхын зэрэгцээ өндөр гүйцэтгэлд хүрч чадна.
Өөр юу унших вэ:
- .
- .
- .
Эх сурвалж: www.habr.com