Docker Compose эсвэл Kubernetes: нэг сервер дээр илүү их нь дээр биш

Жижиг production үйлчилгээ нэг серверт багтаж, серверийн доголдлын дараах сэргээх хугацааг зөвшөөрч чадвал Docker Compose хангалттай байж болно. Docker-ийн production заавар Compose-ийг алсын Docker host дээр ажиллуулах, үндсэн тохиргоонд production-д зориулсан тусдаа файл давхарлах аргыг тайлбарладаг. Production гэсэн шаардлага дангаараа Kubernetes хэрэгтэй гэсэн үг биш.

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

Нэг сервер дээр Compose юуг шийдэж чадах вэ?

Compose нь жижиг үйлчилгээг production орчинд байрлуулах албан ёсны замтай. Үндсэн Compose файл дээр production тохиргоо давхарлахдаа хөгжүүлэлтийн үеийн код холболтыг авах, host-ийн порт болон орчны хувьсагчийг өөрчлөх, контейнерийн дахин асах бодлогыг сонгох боломжтой. Ийм тохиргоо нь нэг сервер дээрх байршуулалтыг тодорхой, давтан хийхэд ойлгомжтой болгоно.

Гэхдээ контейнер дахин асах бодлого зөвхөн ажиллаж байгаа host дээр хэрэгжинэ. Серверийн тэжээл, диск эсвэл сүлжээ доголдвол тухайн машин дээр ажиллаж буй бүх үйлчилгээ нэгэн зэрэг өртөнө. Тиймээс Compose сонгосон баг өгөгдлийн нөөц хуулбар, дохиолол, сервер солих болон үйлчилгээг сэргээх журмыг контейнерийн тохиргооноос тусад нь шийдэх шаардлагатай.

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

Олон сервертэй болоход босго яагаад өөрчлөгдөх вэ?

Нэг зангилаа унтарсан үед үйлчилгээ өөр зангилаанд ажиллах ёстой бол хуулбарын хүссэн тоо, байрлуулах нөөц, үйлчилгээ рүү чиглүүлэх урсгалыг зохицуулах хэрэг гарна. Kubernetes-ийн өөрийгөө сэргээх тайлбар Deployment эсвэл StatefulSet-ийн Pod эвдэрвэл орлуулах Pod үүсгэх, зангилаа ашиглах боломжгүй болоход ажлыг дахин байрлуулах, ажиллахгүй Pod-ийг Service-ийн чиглүүлэлтээс хасах механизмыг тодорхойлдог.

Энэ ажиллагаанд бодитоор ашиглах өөр зангилаа болон үйлчилгээний шаардлагад нийцсэн өгөгдлийн зам хэрэгтэй. Kubernetes-ийг ганц физик сервер дээр байрлуулбал тэр серверийн доголдлыг давах өөр машин байхгүй. Олон зангилааны зохицуулалт нь хэрэгцээтэй үедээ үнэ цэнтэй болохоос, нэг машинд шинэ удирдлагын давхарга нэмснээр өндөр хүртээмж өөрөө бий болохгүй.

Өгөгдөлтэй үйлчилгээний хувьд Pod-ийг өөр газар ажиллуулах боломж болон өгөгдлийг тэнд ашиглах боломж хоёр тусдаа асуудал. Сүлжээ, хадгалалт, нөөц хуулбар, сэргээх дарааллыг шийдээгүй байхад хуулбарыг автоматаар үүсгэх нь хэрэглэгчийн хүсэлтийг бүрэн сэргээнэ гэж үзэж болохгүй. Иймээс олон сервер рүү шилжих босго нь зөвхөн серверийн тоо биш, зангилааны доголдлын үед үйлчилгээний төлөвийг хадгалах шаардлага юм.

Автоматаар өсгөхөд Pod ба серверийг ялга

Ачаалал нэмэгдэхэд програмын хуулбарын тоог автоматаар өөрчлөх бол Horizontal Pod Autoscaler-ийн тайлбар хэмжигдсэн CPU, санах ой эсвэл тохируулсан бусад үзүүлэлтээр Deployment зэрэг ажлын ачааллын Pod-ийн тоог тохируулдгийг заадаг. Үүнд хэмжилтийн эх үүсвэр болон нөөцийн хүсэлтийг зөв тохируулах шаардлагатай; зөвхөн autoscaler идэвхжүүлэх нь хүчин чадал бий болгохгүй.

Шинээр үүсэх Pod одоо байгаа зангилаанд багтахгүй бол серверийн хүчин чадлыг тусад нь нэмэх хэрэгтэй. Kubernetes-ийн зангилаа өсгөх заавар багтаж чадахгүй Pod-д зориулан шинэ зангилаа нийлүүлэхийг тусдаа autoscaler-ийн ажил гэж тайлбарладаг. Энэ нь дэд бүтцийн нийлүүлэгчийн нөөц, тохируулсан хязгаар болон Pod-ийн нөөцийн хүсэлтээс хамаарна.

Ингэхээр ачааллын өсөлтөд хоёр өөр асуулт тавигдана: одоогийн машинд нэмэлт хуулбар багтах уу, эсвэл шинэ машин зайлшгүй хэрэгтэй юу? Нэг серверийн хүрээнд багтаж, хуулбарын тоог гараар өөрчлөх нь боломжийн хэвээр бол кластерийн автоматжуулалт зайлшгүй шаардлага биш. Харин шинэ зангилаа нэмэх хэрэгцээ давтагдаж, хүний оролцоогүйгээр хийх ёстой бол Kubernetes-ийн удирдлагын давхарга тодорхой ажил гүйцэтгэнэ.

Санах ойн хэмжилтэд яг юу багтсан бэ?

Санта Катаринагийн улсын их сургуулийн SPIFFE ачааллын харьцуулсан хэмжилтэд туршсан Kubernetes орчин Docker Compose-оос баталгаажуулах ажиллагаанд 15–30%, DVID мэдээлэл үүсгэх зарим ачаалалд ойролцоогоор 25–37% илүү санах ой хэрэглэсэн. Харин CPU-ийн хэрэглээ хэмжсэн ажиллагаануудад Kubernetes талд бага гарсан; санах ойн болон CPU-ийн үр дүнг ижил чиглэлтэй гэж нэгтгэж болохгүй.

Энэ туршилтын Compose үйлчилгээ host-ийн Docker орчинд шууд ажилласан бол Kubernetes тал нь мөн тэр физик машин дээр Docker дотор ажилласан нэг зангилаат Minikube кластер байв. Ачаалал нь ерөнхий веб програм бус, SPIFFE таних мэдээлэл үүсгэх болон баталгаажуулах ажиллагаа байсан. Иймээс хувь хэмжээ нь тухайн програм, байршуулалтын бүтэц, хэмжсэн бүрэлдэхүүний үр дүн бөгөөд Kubernetes-ийн бүх түгээлтийн тогтмол санах ойн нэмэгдэл биш.

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

Шийдвэрийн мод

• Нэг сервер, сэргээх хугацааг зөвшөөрнө: Compose тохиромжтой эхлэл. Production тохиргоо, өгөгдлийн нөөц хуулбар, дохиолол, сэргээх хариуцлагыг тодорхой болго.
• Нэг сервер, тасалдлыг давах ёстой: Эхлээд өөр зангилаа болон өгөгдөлд хүрэх зам хэрэгтэй. Ганц сервер дээр orchestrator солих нь физик доголдлын цэгийг арилгахгүй.
• Олон сервер, ажлыг шилжүүлэх шаардлагатай: Kubernetes-ийн хуулбар хадгалах, дахин байрлуулах механизм хэрэгцээнд нийцнэ. Хадгалалт ба сүлжээний нөхцөлийг хамт тооц.
• Ачааллаар автоматаар өсөх ёстой: Pod-ийн тоо болон зангилааны тоог тус тусад нь өсгөх эсэхийг ялга. Шинэ Pod-д сул нөөц байхгүй бол зөвхөн хуулбар нэмэх хангалтгүй.
• Кластерийг ажиллуулах хүн, цаг хязгаарлагдмал: Шинэчлэл, оношилгоо, нөөцийн тохиргооны байнгын ажлыг сонголтын өртөгт оруул. Тэр ажлыг даах чадваргүй бол энгийн байршуулалт илүү зохистой байж болно.

Мөн уншаарай:

• SQLite эсвэл PostgreSQL: нэг writer хүрэлцэхгүй болох мөчид сонголт өөрчлөгдөнө
• OBS эсвэл Streamlabs: 1080p60 дээр CPU-ийн 11 пунктын зөрүү гарчээ
• n8n эсвэл Make: сарын үнэ биш, алхам тоолох арга нь сонголтыг шийднэ