Намайг Дмитрий Сугробов гэдэг, би Leroy Merlin-ийн хөгжүүлэгч. Энэ нийтлэлд би Helm яагаад хэрэгтэй вэ, энэ нь Kubernetes-тэй ажиллахыг хэрхэн хялбаршуулдаг, гурав дахь хувилбарт юу өөрчлөгдсөн, мөн үйлдвэрлэлд байгаа програмуудыг сул зогсолтгүйгээр шинэчлэхэд хэрхэн ашиглах талаар танд хэлэх болно.
Энэ бол чуулган дээр хэлсэн үгн дээр үндэслэсэн хураангуй юм by - Хэрэв та уншихыг хүсэхгүй байвал видеог үзээрэй.
Бид яагаад Kubernetes-ийг үйлдвэрлэлд ашигладаг вэ?
Лерой Мерлин бол Орос, Европ дахь DIY жижиглэн худалдааны зах зээлд тэргүүлэгч юм. Манай компани нь зуу гаруй хөгжүүлэгч, 33 дотоод ажилтан, хайпермаркет, вэбсайтад зочилдог асар олон тооны хүмүүстэй. Тэднийг бүгдийг нь баярлуулахын тулд бид салбарын стандарт арга барилыг баримтлахаар шийдсэн. Микро үйлчилгээний архитектурыг ашиглан шинэ програмуудыг хөгжүүлэх; орчныг тусгаарлах, зохих ёсоор хүргэхийн тулд савыг ашиглах; болон зохион байгуулалтад Kubernetes ашиглах. Оркестр ашиглах үнэ хурдацтай хямдарч байна: технологийн чиглэлээр мэргэшсэн инженерүүдийн тоо зах зээл дээр нэмэгдэж, үйлчилгээ үзүүлэгчид Kubernetes-ийг үйлчилгээ болгон санал болгож байна.
Мэдээжийн хэрэг, Кубернетесийн хийдэг бүх зүйлийг өөр аргаар, жишээлбэл, зарим Женкинс, докер-композитыг скриптээр хамрах замаар хийж болно, гэхдээ бэлэн бөгөөд найдвартай шийдэл байгаа бол яагаад амьдралыг хүндрүүлдэг вэ? Тийм ч учраас бид Кубернетес хотод ирээд нэг жилийн турш үйлдвэрлэлд ашиглаж байна. Одоогоор бид хорин дөрвөн Кубернетес кластертай бөгөөд хамгийн эртний нь нэг жилээс дээш настай, хоёр зуу орчим хонхорхойтой.
Kubernetes дахь том YAML файлуудын хараал
Kubernetes-д микро үйлчилгээг эхлүүлэхийн тулд бид дор хаяж таван YAML файл үүсгэнэ: Байршуулах, Үйлчилгээ, Оролцох, ConfigMap, Нууц зэрэгт зориулж кластер руу илгээнэ. Дараагийн програмын хувьд бид ижил багцын шатыг бичих болно, гурав дахь нь өөр нэгийг бичих гэх мэт. Хэрэв бид баримт бичгийн тоог орчны тоогоор үржүүлбэл бид аль хэдийн хэдэн зуун файл авах болно, энэ нь динамик орчныг хараахан тооцоогүй байна.
Helm-ийн үндсэн засварлагч Адам Риз "" гэсэн ойлголтыг нэвтрүүлсэн.", иймэрхүү харагдаж байна:
- YAML хуулах - YAML файлыг хуулах.
- YAML-г буулгах - буулгана уу.
- Fix Indents - догол мөрийг засах.
- Давтах - дахин давт.
Энэ сонголт ажилладаг, гэхдээ та YAML файлуудыг олон удаа хуулах хэрэгтэй. Энэ мөчлөгийг өөрчлөхийн тулд Helm-ийг зохион бүтээсэн.
Helm гэж юу вэ
Нэгдүгээрт, Helm - багц менежер, энэ нь танд хэрэгтэй програмуудаа олж суулгахад тусална. Жишээлбэл, MongoDB-г суулгахын тулд албан ёсны вэбсайт руу орж хоёртын файлуудыг татаж авах шаардлагагүй, зүгээр л командыг ажиллуулна уу. helm install stable/mongodb.
Хоёрдугаарт, Хелм - загвар хөдөлгүүр, файлуудыг параметржүүлэхэд тусалдаг. Kubernetes дахь YAML файлуудын нөхцөл байдал руу буцаж орцгооё. Ижил YAML файлыг бичих нь илүү хялбар бөгөөд түүнд зарим орлуулагч нэмэх бөгөөд үүнд Helm утгыг орлуулах болно. Өөрөөр хэлбэл, олон тооны тавцангийн оронд шаардлагатай утгыг зөв цагт нь орлуулах загваруудын багц байх болно.
Гуравдугаарт, Хелм - байршуулах мастер. Үүний тусламжтайгаар та програмуудыг суулгах, буцаах, шинэчлэх боломжтой. Үүнийг хэрхэн яаж хийхийг олж мэдье.
Helm-ийг ашиглан өөрийн програмуудыг хэрхэн ашиглах вэ
Албан ёсны дагуу Helm клиентийг компьютер дээрээ суулгацгаая . Дараа нь бид YAML файлуудын багц үүсгэх болно. Тодорхой утгыг зааж өгөхийн оронд бид орлуулагчийг үлдээх бөгөөд ирээдүйд Helm мэдээллээр дүүргэх болно. Ийм файлуудын багцыг Helm chart гэж нэрлэдэг. Үүнийг Helm консол клиент рүү гурван аргаар илгээж болно:
- загвар бүхий хавтсыг зааж өгөх;
- архивыг .tar руу боож, түүн рүү чиглүүлэх;
- Загварыг алсын хадгалах газарт байрлуулж, Helm клиент дэх репозитор руу холбоос нэмнэ үү.
Танд бас утгууд бүхий файл хэрэгтэй - values.yaml. Тэндээс авсан өгөгдлийг загварт оруулах болно. Үүнийг бас бүтээцгээе.
Helm-ийн хоёр дахь хувилбар нь нэмэлт сервер програмтай - Tiller. Энэ нь Kubernetes-ийн гадаа өлгөөтэй бөгөөд Helm үйлчлүүлэгчийн хүсэлтийг хүлээж, дуудсан үед шаардлагатай утгыг загварт орлуулж, Kubernetes руу илгээдэг.
Helm 3 нь илүү энгийн: загваруудыг сервер дээр боловсруулахын оронд мэдээллийг одоо Helm клиент тал дээр бүхэлд нь боловсруулж Kubernetes API руу шууд илгээдэг. Энэхүү хялбарчлал нь кластерын аюулгүй байдлыг сайжруулж, нэвтрүүлэх схемийг хөнгөвчлөх болно.
Энэ бүхэн хэрхэн ажилладаг вэ
Командыг ажиллуулна уу helm install. Програмын хувилбарын нэрийг зааж, values.yaml гэсэн замыг өгье. Төгсгөлд нь бид диаграм байгаа репозитор болон диаграмын нэрийг зааж өгнө. Жишээн дээр эдгээр нь "lmru" ба "bestchart" юм.
helm install --name bestapp --values values.yaml lmru/bestchart
Командыг зөвхөн нэг удаа гүйцэтгэх боломжтой бөгөөд оронд нь дахин гүйцэтгэхэд install ашиглах хэрэгтэй upgrade. Энгийн болгох үүднээс хоёр тушаалын оронд та тушаалыг ажиллуулж болно upgrade нэмэлт түлхүүрээр --install. Эхний удаа ажиллах үед Helm хувилбарыг суулгах тушаалыг илгээж, ирээдүйд шинэчлэх болно.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Helm ашиглан програмын шинэ хувилбаруудыг ашиглахад тулгардаг бэрхшээлүүд
Өгүүллийн энэ үед би үзэгчидтэй "Хэн саятан болохыг хүсдэг" тоглоомыг тоглож байгаа бөгөөд бид програмын хувилбарыг шинэчлэхийн тулд Helm-ийг хэрхэн авах талаар бодож байна. .
Би Helm хэрхэн ажилладагийг сурч байхдаа ажиллаж байгаа програмуудын хувилбаруудыг шинэчлэх гэж оролдох үед хачирхалтай зан үйлд нь гайхсан. Би програмын кодыг шинэчилж, Docker бүртгэлд шинэ зураг байршуулж, байршуулах командыг илгээсэн - юу ч болоогүй. Аппликешнүүдийг шинэчлэх бүрэн амжилттай бус аргуудыг доор харуулав. Тэдгээрийг тус бүрийг нарийвчлан судалснаар та багажийн дотоод бүтэц, энэ нь тодорхойгүй зан үйлийн шалтгааныг ойлгож эхэлдэг.
Арга 1. Хамгийн сүүлд эхлүүлснээс хойшхи мэдээллийг бүү өөрчил
Түүний хэлснээр Хелм, "Кубернетес графикууд нь том бөгөөд төвөгтэй байж болох тул Хелм ямар нэгэн зүйлд хэт их хүрэхгүй байхыг хичээдэг." Тиймээс, хэрэв та докерын бүртгэл дэх програмын зургийн хамгийн сүүлийн хувилбарыг шинэчилж, тушаалыг ажиллуулна уу helm upgrade, тэгвэл юу ч болохгүй. Helm юу ч өөрчлөгдөөгүй гэж бодож байгаа бөгөөд програмыг шинэчлэхийн тулд Кубернетес рүү тушаал илгээх шаардлагагүй болно.
Энд болон доор хамгийн сүүлийн шошгыг зөвхөн жишээ болгон харуулав. Энэ хаягийг зааж өгөх үед Kubernetes нь imagePullPolicy параметрээс үл хамааран докерын бүртгэлээс зургийг татаж авах болно. Сүүлийн үеийн үйлдвэрлэлийг ашиглах нь хүсээгүй бөгөөд гаж нөлөө үүсгэдэг.
Арга 2. Зураг дээрх LABEL-г шинэчил
Үүнтэй адилаар бичсэн , "Хэлм нь зөвхөн сүүлийн хувилбараас хойш өөрчлөгдсөн програмыг шинэчлэх болно." Үүний логик сонголт бол докерын зураг дээрх LABEL-г шинэчлэх явдал юм. Гэсэн хэдий ч Helm програмын зургуудыг хардаггүй бөгөөд тэдгээрт ямар нэгэн өөрчлөлт орсон талаар ямар ч ойлголтгүй байна. Үүний дагуу зураг дээрх шошгыг шинэчлэх үед Helm тэдний талаар мэдэхгүй бөгөөд програмыг шинэчлэх командыг Kubernetes руу илгээхгүй.
Арга 3: Түлхүүрийг ашиглана уу --force
Гарын авлага руу эргэж, шаардлагатай түлхүүрийг хайцгаая. Түлхүүр нь хамгийн утга учиртай --force. Нэрийг нь үл харгалзан зан төлөв нь хүлээгдэж байснаас өөр юм. Аппликешн шинэчлэхийг албадахын оронд түүний жинхэнэ зорилго нь FAILED төлөвт байгаа хувилбарыг сэргээх явдал юм. Хэрэв та энэ түлхүүрийг ашиглахгүй бол тушаалуудыг дарааллаар гүйцэтгэх хэрэгтэй helm delete && helm install --replace. Үүний оронд түлхүүрийг ашиглахыг зөвлөж байна --force, эдгээр командуудын дараалсан гүйцэтгэлийг автоматжуулдаг. Энэ талаар дэлгэрэнгүй мэдээлэл . Helm-д програмын хувилбарыг шинэчлэхийг хэлэхийн тулд харамсалтай нь энэ түлхүүр ажиллахгүй.
Арга 4. Kubernetes дээр шошгыг шууд өөрчлөх
Командыг ашиглан шошгыг кластерт шууд шинэчилж байна kubectl edit - муу санаа. Энэ үйлдэл нь ажиллаж байгаа програм болон анх байршуулахаар илгээсэн програмын хооронд мэдээлэл үл нийцэхэд хүргэнэ. Энэ тохиолдолд байршуулах үеийн Helm-ийн үйлдэл нь түүний хувилбараас ялгаатай: Helm 2 нь юу ч хийхгүй бөгөөд Helm 3 нь програмын шинэ хувилбарыг ашиглах болно. Яагаад гэдгийг ойлгохын тулд та Helm хэрхэн ажилладагийг ойлгох хэрэгтэй.
Helm хэрхэн ажилладаг вэ?
Аппликешн сүүлийн хувилбараасаа хойш өөрчлөгдсөн эсэхийг тодорхойлохын тулд Helm дараахь зүйлийг ашиглаж болно.
- Kubernetes дээр ажиллаж байгаа програм;
- шинэ утгууд.yaml болон одоогийн график;
- Helm-ийн дотоод хувилбарын мэдээлэл.
Илүү их сонирхвол: Helm хувилбаруудын талаарх дотоод мэдээллийг хаана хадгалдаг вэ?Тушаалыг гүйцэтгэх замаар helm history, бид Helm ашиглан суулгасан хувилбаруудын талаархи бүх мэдээллийг авах болно.
Мөн илгээсэн загвар болон утгын талаар дэлгэрэнгүй мэдээлэл байна. Бид үүнийг хүсч болно:
Helm-ийн хоёр дахь хувилбарт энэ мэдээлэл нь Tiller ажиллаж байгаа ижил нэрийн талбарт (анхдагчаар kube-систем), ConfigMap-д "OWNER=TILLER" гэсэн шошготой байрладаг.
Helm-ийн гурав дахь хувилбар гарч ирэхэд мэдээлэл нууцлал руу шилжиж, програм ажиллаж байсан ижил нэрийн талбарт шилжсэн. Үүний ачаар ижил хувилбарын нэртэй өөр өөр нэрийн зайд хэд хэдэн програмыг нэгэн зэрэг ажиллуулах боломжтой болсон. Хоёрдахь хувилбарт нэрийн орон зай тусгаарлагдсан боловч бие биедээ нөлөөлж чаддаг бол энэ нь ноцтой толгойн өвчин байсан.
Хоёр дахь Helm нь шинэчлэлт шаардлагатай эсэхийг ойлгохыг оролдохдоо зөвхөн хоёр мэдээллийн эх сурвалжийг ашигладаг: одоо түүнд өгсөн зүйл, ConfigMap-д байгаа хувилбаруудын талаарх дотоод мэдээлэл.
Гурав дахь Helm нь гурван талын нэгтгэх стратегийг ашигладаг: эдгээр мэдээллээс гадна яг одоо Kubernetes дээр ажиллаж байгаа програмыг харгалзан үздэг.
Энэ шалтгааны улмаас Helm-ийн хуучин хувилбар нь кластер дахь програмын мэдээллийг харгалздаггүй тул юу ч хийхгүй, харин Helm 3 нь өөрчлөлтийг хүлээн авч, шинэ програмыг байршуулахаар илгээх болно.
Арга 5. --recreate-pods шилжүүлэгчийг ашиглана уу
Түлхүүртэй --recreate-pods Та түлхүүрийн тусламжтайгаар анх хүрэхээр төлөвлөж байсан зүйлдээ хүрч чадна --force. Контейнерууд дахин эхлэх бөгөөд imagePullPolicy: Үргэлж хамгийн сүүлийн шошгоны бодлого (энэ талаар дээрх зүүлт тайлбараас) дагуу Кубернетес зургийн шинэ хувилбарыг татаж аваад эхлүүлэх болно. Үүнийг хамгийн сайн аргаар хийхгүй: байршуулалтын стратегийн төрлийг харгалзахгүйгээр энэ нь бүх хуучин програмын тохиолдлуудыг гэнэт унтрааж, шинээр эхлүүлж эхэлнэ. Дахин эхлүүлэх үед систем ажиллахгүй, хэрэглэгчид хохирох болно.
Кубернетес хотод үүнтэй төстэй асуудал удаан хугацааны туршид байсан. Одоо нээлтээ хийгээд 4 жил болж байна , асуудал шийдэгдсэн бөгөөд Kubernetes-ийн 1.15 хувилбараас эхлэн pods-ыг эргүүлж дахин эхлүүлэх боломжтой болсон.
Helm зүгээр л бүх програмыг унтрааж, ойролцоох шинэ контейнеруудыг ажиллуулдаг. Аппликейшний зогсолтыг үүсгэхгүйн тулд та үүнийг үйлдвэрлэлд хийх боломжгүй. Энэ нь зөвхөн хөгжлийн хэрэгцээнд шаардлагатай бөгөөд зөвхөн тайзны орчинд гүйцэтгэх боломжтой.
Helm ашиглан програмын хувилбарыг хэрхэн шинэчлэх вэ?
Бид Helm руу илгээсэн утгыг өөрчлөх болно. Ихэвчлэн эдгээр нь зургийн шошгоны оронд орлуулсан утгууд юм. Бүтээмжгүй орчинд ихэвчлэн ашиглагддаг хамгийн сүүлийн үеийн хувьд өөрчлөгддөг мэдээлэл нь Кубернетесийн хувьд ашиггүй тайлбар бөгөөд Helm-ийн хувьд энэ нь програмыг шинэчлэх шаардлагатай дохио болж өгдөг. Тэмдэглэгээний утгыг бөглөх сонголтууд:
- Санамсаргүй утга стандарт функцийг ашиглан -
{{ randAlphaNum 6 }}.
Анхааруулга бий: ийм хувьсагчтай график ашиглан байршуулалт бүрийн дараа тэмдэглэгээний утга өвөрмөц байх ба Helm өөрчлөлт орсон гэж үзнэ. Бид түүний хувилбарыг өөрчлөөгүй байсан ч програмыг үргэлж дахин эхлүүлэх болно. Энэ нь тийм ч чухал биш, учир нь сул зогсолт гарахгүй, гэхдээ энэ нь тааламжгүй хэвээр байна. - Одоогийн буулгах огноо, цаг -
{{ .Release.Date }}.
Хувилбар нь байнгын өвөрмөц хувьсагчтай санамсаргүй утгатай төстэй. - Илүү зөв арга бол ашиглах явдал юм шалгах нийлбэр. Энэ бол зургийн SHA эсвэл git дэх хамгийн сүүлийн амлалтын SHA юм -
{{ .Values.sha }}.
Тэдгээрийг тоолж, дуудаж буй тал дахь Helm үйлчлүүлэгч рүү, жишээлбэл, Женкинс рүү илгээх шаардлагатай болно. Хэрэв програм өөрчлөгдсөн бол шалгах нийлбэр өөрчлөгдөнө. Тиймээс Helm програмыг шаардлагатай үед л шинэчлэх болно.
Бидний оролдлогуудыг нэгтгэн дүгнэж үзье
- Helm нь өөрчлөлтийг хамгийн бага инвазив аргаар хийдэг тул Docker Registry дахь програмын зургийн түвшинд гарсан аливаа өөрчлөлт нь шинэчлэлт хийхэд хүргэдэггүй: тушаалыг гүйцэтгэсний дараа юу ч болохгүй.
- Түлхүүр үг
--forceасуудалтай хувилбаруудыг сэргээхэд ашигладаг бөгөөд албадан шинэчлэлттэй холбоогүй. - Түлхүүр үг
--recreate-podsпрограмуудыг хүчээр шинэчлэх болно, гэхдээ үүнийг сүйтгэгч байдлаар хийх болно: энэ нь бүх савыг гэнэт унтраах болно. Хэрэглэгчид үүнээс болж зовох болно, та үүнийг үйлдвэрлэлд хийх ёсгүй. - Командыг ашиглан Kubernetes кластерт шууд өөрчлөлт хийнэ үү
kubectl editбүү хий: бид тууштай байдлыг эвдэх ба Helm-ийн хувилбараас хамааран зан байдал өөр байх болно. - Helm-ийн шинэ хувилбар гарснаар олон нюанс гарч ирэв. Helm репозитор дахь асуудлуудыг тодорхой хэлээр тайлбарласан бөгөөд тэдгээр нь нарийн ширийн зүйлийг ойлгоход тусална.
- Диаграмд засварлах боломжтой тайлбарыг нэмбэл илүү уян хатан болгоно. Энэ нь танд ямар ч сул зогсолтгүйгээр програмыг зөв ашиглах боломжийг олгоно.
Амьдралын бүхий л салбарт үйлчилдэг "дэлхийн амар амгалан" санаа: хэрэглэхийн өмнө зааврыг унш, дараа нь биш. Зөвхөн бүрэн мэдээлэлтэй байж л найдвартай системийг бий болгож, хэрэглэгчдийг баярлуулах боломжтой болно.
Бусад холбогдох холбоосууд:
Энэ тайланг анх удаа танилцуулав Mail.ru Cloud Solutions. Хараач бусад үзүүлбэрүүд болон Telegram дээр үйл явдлын зарлалыг захиалах .
Эх сурвалж: www.habr.com