Анхаарна уу. орчуулга.: энэ материалыг боловсролын төслөөс авсан болно нь Кубернетес дээр суурилсан дэд бүтцийг төлөвлөхдөө түгээмэл байдаг асуултын хариулт юм. Сонголт бүрийн давуу болон сул талуудын нэлээн нарийвчилсан тайлбар нь таны төслийн хамгийн сайн сонголтыг хийхэд тусална гэж найдаж байна.
TL, DR: ижил багц ачааллыг хэд хэдэн том кластерууд дээр (кластер бүр олон тооны ачаалалтай байх болно) эсвэл олон жижиг (кластер бүрт цөөн тооны ачаалалтай) дээр ажиллуулж болно.
Арга тус бүрийн давуу болон сул талуудыг үнэлэх хүснэгтийг доор харуулав.
Kubernetes-ийг програмуудыг ажиллуулах платформ болгон ашиглах үед кластер үүсгэх нарийн төвөгтэй байдлын талаар хэд хэдэн үндсэн асуултууд ихэвчлэн гарч ирдэг.
- Би хэдэн кластер ашиглах ёстой вэ?
- Би тэднийг хэр том болгох ёстой вэ?
- Кластер бүр юуг агуулсан байх ёстой вэ?
Энэ нийтлэлд би хандлага бүрийн давуу болон сул талуудыг шинжлэх замаар эдгээр бүх асуултанд хариулахыг хичээх болно.
Асуултын мэдэгдэл
Програм хангамж хөгжүүлэгчийн хувьд та олон программыг нэгэн зэрэг боловсруулж, ажиллуулж магадгүй юм.
Нэмж дурдахад, эдгээр програмуудын олон тохиолдлууд өөр өөр орчинд ажиллах магадлалтай - жишээлбэл, эдгээр байж болно dev, туршилтын и бүтээгдэхүүн.
Үр дүн нь програмууд болон орчны бүхэл бүтэн матриц юм:
Хэрэглээ ба орчин
Дээрх жишээ нь 3 программ болон 3 орчныг төлөөлүүлэн нийт 9 боломжит хувилбарыг харуулж байна.
Хэрэглээний жишээ бүр нь бусдаас үл хамааран ажиллах боломжтой бие даасан байршуулах нэгж юм.
тэрийг тэмдэглэ хэрэглээний жишээ олон хэсгээс бүрдэж болно бүрэлдэхүүн хэсэг, тухайлбал, frontend, backend, өгөгдлийн сан гэх мэт. Микро үйлчилгээний програмын хувьд жишээ нь бүх микро үйлчилгээг багтаана.
Үүний үр дүнд Kubernetes хэрэглэгчдэд хэд хэдэн асуулт байна:
- Бүх програмын жишээг нэг кластерт байрлуулах ёстой юу?
- Хэрэглээний тохиолдол бүрт тусдаа кластертай байх нь үнэ цэнэтэй юу?
- Эсвэл дээрх аргуудыг хослуулан хэрэглэх нь зүйтэй болов уу?
Kubernetes нь хэрэглэгчийн чадавхийг хязгаарладаггүй уян хатан систем тул эдгээр бүх сонголтууд нь нэлээд боломжтой юм.
Энд зарим боломжит аргууд байна:
- нэг том нийтлэг кластер;
- олон жижиг өндөр мэргэшсэн кластерууд;
- програм бүрт нэг кластер;
- орчинд нэг кластер.
Доор үзүүлсэн шиг эхний хоёр арга нь сонголтуудын цар хүрээний эсрэг талд байна:
Хэдэн том кластераас (зүүн) олон жижиг бөөгнөрөл хүртэл (баруун)
Ерөнхийдөө нэг кластер нь илүү их зангилаа, хонхорцогтой бол нөгөөгөөсөө "илүү" гэж тооцогддог. Жишээлбэл, 10 зангилаа, 100 хонхорцог бүхий кластер нь 1 зангилаа, 10 хонхорцогтой кластераас том байна.
За, эхэлцгээе!
1. Нэг том нийтлэг кластер
Эхний сонголт бол бүх ачааллыг нэг кластерт байрлуулах явдал юм.
Нэг том кластер
Энэ аргын хүрээнд кластерыг универсал болгон ашигладаг дэд бүтцийн платформ - Та зүгээр л хэрэгтэй бүх зүйлээ одоо байгаа Kubernetes кластерт байрлуулна.
Кубернетес нь кластерын хэсгүүдийг бие биенээсээ логикоор тусгаарлах боломжийг олгодог бөгөөд ингэснээр програмын жишээ бүр өөрийн гэсэн нэрийн орон зайтай болно.
Энэ аргын давуу болон сул талуудыг авч үзье.
+ Нөөцийг үр ашигтай ашиглах
Нэг кластертай бол танд Кубернетес кластерыг ажиллуулах, удирдахад шаардлагатай бүх нөөцийн зөвхөн нэг хуулбар хэрэгтэй.
Жишээлбэл, энэ нь мастер зангилааны хувьд үнэн юм. Ерөнхийдөө Кубернетес кластер бүр 3 мастер зангилаатай байдаг тул нэг кластерын хувьд тэдний тоо ийм хэвээр байх болно (харьцуулахын тулд 10 кластерт 30 мастер зангилаа хэрэгтэй болно).
Дээрх нарийн зүйл нь ачаалал тэнцвэржүүлэгч, нэвтрэх хянагч, нэвтрэлт танилт, бүртгэл, хяналтын систем зэрэг бүхэл бүтэн кластерт ажилладаг бусад үйлчилгээнд мөн хамаарна.
Нэг кластерт эдгээр бүх үйлчилгээг нэг дор бүх ажлын ачаалалд ашиглах боломжтой (олон кластерт байдаг шиг тэдгээрийн хуулбарыг үүсгэх шаардлагагүй).
+ Хямд
Дээр дурдсан зүйлсийн үр дүнд нэмэлт зардал байхгүй тул цөөн тооны кластерууд ихэвчлэн хямд байдаг.
Энэ нь ялангуяа мастер зангилааны хувьд үнэн бөгөөд тэдгээрийг хэрхэн зохион байгуулж байгаагаас үл хамааран (байгууллагад эсвэл үүлэн дээр) ихээхэн хэмжээний мөнгө зарцуулдаг.
Зарим нь Kubernetes үйлчилгээг удирддаг буюу , хяналтын давхаргыг үнэ төлбөргүй өгөх. Энэ тохиолдолд зардлын асуудал бага хурцаддаг.
Мөн Kubernetes кластер бүрийг ажиллуулахын тулд тогтмол төлбөр авдаг удирддаг үйлчилгээнүүд байдаг (жишээлбэл, ).
+ Үр дүнтэй удирдлага
Нэг кластерыг удирдах нь хэд хэдэн удирдлагаас илүү хялбар байдаг.
Удирдлага нь дараахь ажлуудыг агуулж болно.
- Kubernetes хувилбарын шинэчлэл;
- CI/CD дамжуулах хоолой тавих;
- CNI залгаасыг суулгах;
- хэрэглэгчийн баталгаажуулалтын системийг бий болгох;
- хандалтын хянагч суурилуулах;
болон бусад олон ...
Нэг кластерын хувьд та энэ бүгдийг нэг л удаа хийх хэрэгтэй болно.
Олон кластеруудын хувьд үйлдлүүдийг олон удаа давтах шаардлагатай бөгөөд энэ нь үйл явцын тууштай, тууштай байдлыг хангахын тулд процесс, хэрэгслийг зарим автоматжуулах шаардлагатай болно.
Одоо сул талуудын талаар хэдэн үг хэлье.
- Нэг бүтэлгүйтлийн цэг
Татгалзсан тохиолдолд цорын ганц кластер шууд ажиллахаа болино бүх ажлын ачаалал!
Алдаа гарах олон арга бий:
- Kubernetes-ийг шинэчлэх нь гэнэтийн сөрөг үр дагаварт хүргэдэг;
- Кластер даяарх бүрэлдэхүүн хэсэг (жишээлбэл, CNI залгаас) санаснаар ажиллахгүй байна;
- кластерийн бүрэлдэхүүн хэсгүүдийн нэг нь зөв тохируулагдаагүй;
- суурь дэд бүтцийн доголдол.
Ийм нэг тохиолдол нь хуваалцсан кластерт байрлах бүх ажлын ачаалалд ноцтой хохирол учруулж болзошгүй юм.
− Хатуу дулаалга байхгүй
Хуваалцсан кластерт ажиллах нь программууд нь кластерийн зангилаанууд дээрх техник хангамж, сүлжээний боломжууд болон үйлдлийн системийг хуваалцдаг гэсэн үг юм.
Нэг утгаараа нэг зангилаа дээр ажиллаж байгаа хоёр өөр програмтай хоёр контейнер нь ижил үйлдлийн системийн цөм дээр ажилладаг нэг машин дээр ажиллаж байгаа хоёр процесстой адил юм.
Линукс контейнерууд нь зарим төрлийн тусгаарлалтыг хангадаг боловч энэ нь виртуал машинуудын өгсөн шиг тийм ч хүчтэй биш юм. Үнэн чанартаа, контейнер дэх процесс нь хост үйлдлийн систем дээр ажилладаг ижил процесс юм.
Энэ нь аюулгүй байдлын асуудал байж болно: энэ зохицуулалт нь онолын хувьд хамааралгүй програмууд хоорондоо (санаатай эсвэл санамсаргүй байдлаар) харилцах боломжийг олгодог.
Нэмж дурдахад, Кубернетес кластер дахь бүх ажлын ачаалал нь кластерын зарим үйлчилгээг хуваалцдаг - энэ нь програмуудад кластерт байгаа бусад програмын үйлчилгээг олох боломжийг олгодог.
Дээрх бүх цэгүүд нь програмын аюулгүй байдлын шаардлагаас хамааран өөр өөр утгатай байж болно.
Kubernetes зэрэг аюулгүй байдлын асуудлаас урьдчилан сэргийлэх янз бүрийн хэрэгслээр хангадаг и . Гэсэн хэдий ч тэдгээрийг зөв тохируулах нь тодорхой туршлага шаарддаг бөгөөд үүнээс гадна тэд аюулгүй байдлын бүх цоорхойг хааж чадахгүй.
Kubernetes нь анхнаасаа зориулагдсан гэдгийг үргэлж санаж байх нь чухал хуваалцах, төлөө биш тусгаарлалт ба аюулгүй байдал.
− Олон түрээслэх хатуу зарчим байхгүй
Kubernetes кластерт хуваалцсан нөөцийн элбэг дэлбэг байдлыг харгалзан өөр өөр програмууд бие биенийхээ хуруунд гишгэх олон арга бий.
Жишээлбэл, програм нь хуваалцсан нөөцийг (CPU эсвэл санах ой гэх мэт) монопольчилж, ижил зангилаа дээр ажиллаж байгаа бусад програмуудад хандахыг хориглож болно.
Кубернетес нь энэ зан үйлийг хянах янз бүрийн механизмаар хангадаг (мөн "өгүүллийг үзнэ үү""- ойролцоогоор. орчуул.), и . Гэсэн хэдий ч аюулгүй байдлын нэгэн адил тэдгээрийн тохиргоо нь маш энгийн бөгөөд урьдчилан тооцоолоогүй бүх сөрөг үр дагавраас урьдчилан сэргийлэх боломжгүй юм.
- Хэрэглэгчдийн тоо их
Нэг кластерын хувьд олон хүнд хандах боломжийг нээх хэрэгтэй. Тэдний тоо их байх тусам ямар нэг зүйлийг "эвдэх" эрсдэл өндөр байдаг.
Кластер дотроос хэн юуг ашиглаж болохыг хянах боломжтой ("өгүүллийг үзнэ үү""- ойролцоогоор. орчуул.). Гэсэн хэдий ч, энэ нь хэрэглэгчид өөрсдийн хариуцлагын хүрээнд ямар нэг зүйлийг "эвдэх"-ээс сэргийлж чадахгүй.
− Кластерууд хязгааргүй өсөх боломжгүй
Бүх ажлын ачаалалд ашигладаг кластер нь нэлээд том байх магадлалтай (зангилаа ба хонгилын тоогоор).
Гэхдээ энд өөр нэг асуудал гарч ирж байна: Кубернетес дэх кластерууд хязгааргүй өсч чадахгүй.
Кластерын хэмжээнд онолын хязгаарлалт байдаг. Кубернетес хотод энэ нь ойролцоогоор байна .
Гэсэн хэдий ч бодит амьдрал дээр асуудал хамаагүй эрт эхэлж болно - жишээлбэл, зүгээр л .
Баримт нь том кластерууд Kubernetes хяналтын давхаргад өндөр ачаалал өгдөг. Өөрөөр хэлбэл, кластерыг үр дүнтэй ажиллуулахын тулд нарийн тохируулга хийх шаардлагатай.
Энэ асуудлыг анхны блог дээрх "" нэртэй холбоотой нийтлэлд судалсан болно.".
Гэхдээ эсрэг талын хандлагыг авч үзье: олон жижиг кластерууд.
2. Олон тооны жижиг, тусгайлсан кластерууд
Энэ аргын тусламжтайгаар та байршуулсан элемент бүрт тусдаа кластер ашигладаг:
Олон жижиг кластерууд
Энэ зүйлийн зорилгын үүднээс доор байрлуулж болох элемент нь програмын жишээг хэлдэг - жишээлбэл, тусдаа програмын хөгжүүлэлтийн хувилбар.
Энэхүү стратеги нь Kubernetes-ийг тусгайлан ашигладаг ажиллах хугацаа бие даасан хэрэглээний тохиолдлуудад.
Энэ аргын давуу болон сул талуудыг авч үзье.
+ Хязгаарлагдмал "тэсэлгээний радиус"
Кластер бүтэлгүйтсэн тохиолдолд сөрөг үр дагавар нь зөвхөн тухайн кластерт байрлуулсан ажлын ачаалалд л хязгаарлагдана. Бусад бүх ажлын ачаалал хөндөгдөөгүй хэвээр байна.
+ Тусгаарлагч
Тусдаа кластерт байршуулсан ажлын ачаалал нь процессор, санах ой, үйлдлийн систем, сүлжээ болон бусад үйлчилгээ зэрэг нөөцүүдийг хуваалцдаггүй.
Үр дүн нь хамааралгүй программуудын хооронд нягт тусгаарлагдсан байдаг бөгөөд энэ нь тэдний аюулгүй байдалд ашигтай байж болох юм.
+ Цөөн тооны хэрэглэгчид
Кластер бүр нь зөвхөн хязгаарлагдмал багц ачааллыг агуулдаг тул түүнд хандах боломжтой хэрэглэгчдийн тоо багасдаг.
Кластерт хандах хүмүүс цөөхөн байх тусам ямар нэг зүйл "эвдрэх" эрсдэл бага байх болно.
Сул талуудыг харцгаая.
− Нөөцийг үр ашиггүй ашиглах
Өмнө дурьдсанчлан, Kubernetes кластер бүр нь удирдлагын тодорхой багц нөөцийг шаарддаг: мастер зангилаа, хяналтын давхаргын бүрэлдэхүүн хэсгүүд, хяналт, бүртгэлийн шийдлүүд.
Олон тооны жижиг кластеруудын хувьд илүү их нөөцийг удирдлагад хуваарилах ёстой.
- Үнэтэй
Нөөцийг үр ашиггүй ашиглах нь автоматаар өндөр зардал шаарддаг.
Жишээлбэл, ижил тооцоолох хүчин чадалтай гурвын оронд 30 мастер зангилааг хадгалах нь зардалд зайлшгүй нөлөөлнө.
- Удирдах ажилд хүндрэлтэй
Олон Kubernetes кластерыг удирдах нь зөвхөн нэгийг удирдахаас хамаагүй хэцүү юм.
Жишээлбэл, та кластер бүрийн баталгаажуулалт, зөвшөөрлийг тохируулах шаардлагатай болно. Kubernetes хувилбарыг мөн хэд хэдэн удаа шинэчлэх шаардлагатай болно.
Эдгээр бүх ажлыг илүү үр дүнтэй болгохын тулд та автоматжуулалтыг ашиглах шаардлагатай болно.
Одоо арай бага экстремаль хувилбаруудыг харцгаая.
3. Нэг программд нэг кластер
Энэ аргад та тодорхой програмын бүх тохиолдлуудад тусдаа кластер үүсгэдэг:
Аппликешн бүрийн кластер
Энэ замыг зарчмын ерөнхий ойлголт гэж үзэж болно "баг бүрт тусдаа кластер”, учир нь ихэвчлэн инженерүүдийн баг нэг буюу хэд хэдэн програм боловсруулдаг.
Энэ аргын давуу болон сул талуудыг авч үзье.
+ Кластерыг програмд тохируулж болно
Хэрэв програм нь тусгай хэрэгцээтэй бол тэдгээрийг бусад кластерт нөлөөлөхгүйгээр кластерт хэрэгжүүлж болно.
Ийм хэрэгцээнд GPU ажилчид, тодорхой CNI залгаасууд, үйлчилгээний сүлжээ эсвэл бусад үйлчилгээ багтаж болно.
Кластер бүрийг дотор нь ажиллаж байгаа програмд тохируулан тохируулж болох бөгөөд ингэснээр зөвхөн шаардлагатай зүйлийг л агуулна.
− Нэг кластерт өөр өөр орчин
Энэ аргын сул тал нь өөр өөр орчны хэрэглээний жишээнүүд нэг кластерт зэрэгцэн оршдог явдал юм.
Жишээлбэл, програмын үйлдвэрлэлийн хувилбар нь dev хувилбартай ижил кластерт ажилладаг. Энэ нь мөн програмын үйлдвэрлэлийн хувилбарыг ажиллуулж буй ижил кластерт хөгжүүлэгчид ажилладаг гэсэн үг юм.
Хэрэв хөгжүүлэгчдийн үйлдэл эсвэл хөгжүүлэлтийн хувилбарт гарсан доголдлоос болж кластерт алдаа гарвал үйлдвэрлэлийн хувилбар нь бас хохирч магадгүй нь энэ аргын асар том сул тал юм.
Эцэст нь бидний жагсаалтын сүүлчийн хувилбар.
4. Нэг орчинд нэг кластер
Энэ хувилбарт орчин бүрд тусдаа кластер хуваарилах орно:
Нэг орчинд нэг кластер
Жишээлбэл, та кластертай байж болно dev, туршилтын и бүтээгдэхүүн, үүнд та тодорхой орчинд зориулагдсан програмын бүх тохиолдлыг ажиллуулах болно.
Энэ аргын давуу болон сул талууд энд байна.
+ Үйлдвэрлэлийн орчныг тусгаарлах
Энэ аргын хүрээнд бүх орчин бие биенээсээ тусгаарлагдсан байдаг. Гэсэн хэдий ч бодит байдал дээр энэ нь үйлдвэрлэлийн орчинд онцгой ач холбогдолтой юм.
Програмын үйлдвэрлэлийн хувилбарууд нь бусад кластерууд болон орчинд болж буй зүйлээс хараат бус болсон.
Ийм байдлаар, хэрэв dev cluster-д гэнэт асуудал гарвал программуудын үйлдвэрлэлийн хувилбарууд юу ч болоогүй юм шиг ажилласаар байх болно.
+ Кластерыг хүрээлэн буй орчинд тохируулж болно
Кластер бүрийг хүрээлэн буй орчиндоо тохируулж болно. Жишээлбэл, та:
- dev кластерт хөгжүүлэлт, дибаг хийх хэрэгслүүдийг суулгах;
- кластерт туршилтын хүрээ болон хэрэгслүүдийг суулгах туршилтын;
- кластерт илүү хүчирхэг техник хангамж болон сүлжээний сувгуудыг ашиглах бүтээгдэхүүн.
Энэ нь програмыг хөгжүүлэх, ажиллуулах үр ашгийг нэмэгдүүлэх боломжийг танд олгоно.
+ Үйлдвэрлэлийн кластерт нэвтрэх эрхийг хязгаарлах
Бүтээгдэхүүний кластертай шууд ажиллах хэрэгцээ ховор тохиолддог тул та түүнд хандах боломжтой хүмүүсийн хүрээг ихээхэн хязгаарлаж чадна.
Та цаашаа явж, хүмүүсийг энэ кластерт хандахыг бүхэлд нь хориглож, автомат CI/CD хэрэглүүрийг ашиглан бүх байршуулалтыг хийж болно. Ийм арга барил нь хамгийн их хамааралтай газарт хүний алдааны эрсдлийг багасгах болно.
Одоо сул талуудын талаар хэдэн үг хэлье.
− Хэрэглээний хооронд тусгаарлалт байхгүй
Аргын гол сул тал нь программуудын хооронд техник хангамж, нөөцийн тусгаарлалт дутмаг байдаг.
Холбоогүй програмууд нь кластерийн нөөцийг хуваалцдаг: системийн цөм, процессор, санах ой болон бусад үйлчилгээ.
Дээр дурдсанчлан энэ нь аюултай байж болзошгүй.
− Хэрэглээний хамаарлыг нутагшуулах боломжгүй
Хэрэв програмд тусгай шаардлага байгаа бол тэдгээрийг бүх кластерт хангасан байх ёстой.
Жишээлбэл, хэрэв програм GPU шаарддаг бол кластер бүр GPU-тэй дор хаяж нэг ажилтантай байх ёстой (зөвхөн энэ програмд ашиглагдсан байсан ч).
Үүний үр дүнд бид өндөр зардал, нөөцийг үр ашиггүй ашиглах эрсдэлтэй.
дүгнэлт
Хэрэв танд тодорхой програмууд байгаа бол тэдгээрийг хэд хэдэн том кластер эсвэл олон жижиг бүлэгт байрлуулж болно.
Нийтлэлд нэг дэлхийн кластераас эхлээд хэд хэдэн жижиг, өндөр мэргэшсэн янз бүрийн хандлагын давуу болон сул талуудыг авч үзнэ.
- нэг том ерөнхий кластер;
- олон жижиг өндөр мэргэшсэн кластерууд;
- програм бүрт нэг кластер;
- орчинд нэг кластер.
Тэгэхээр та ямар арга барилыг баримтлах ёстой вэ?
Үргэлжийн нэгэн адил хариулт нь ашиглалтын байдлаас хамаарна: та янз бүрийн аргын давуу болон сул талуудыг жинлэж, хамгийн оновчтой хувилбарыг сонгох хэрэгтэй.
Гэсэн хэдий ч сонголт нь дээрх жишээнээр хязгаарлагдахгүй - та тэдгээрийн аль ч хослолыг ашиглаж болно!
Жишээлбэл, та баг бүрт хэд хэдэн кластер зохион байгуулж болно: хөгжлийн кластер (орчны орчин байх болно) dev и туршилтын) болон кластер үйлдвэрлэл (үйлдвэрлэлийн орчин хаана байрлах вэ).
Энэ нийтлэл дэх мэдээлэлд үндэслэн та тодорхой хувилбарт тохирсон давуу болон сул талуудыг оновчтой болгож чадна. Амжилт хүсье!
PS
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «";
- «".
Эх сурвалж: www.habr.com