Kustomize-ийн товч танилцуулга

Анхаарна уу. орчуулга.: Нийтлэлийг 2016 хэвлэмэл номын зохиогч/хамт зохиогч (голчлон VMware vSphere дээр) IT чиглэлээр арвин туршлагатай инженер Скотт Лоу бичсэн. Тэрээр одоо VMware-ийн охин компани Heptio-д (XNUMX онд худалдаж авсан) ажилладаг бөгөөд үүлэн тооцоолол болон Kubernetes чиглэлээр мэргэшсэн. Текст нь технологи ашиглан Kubernetes-д зориулсан тохиргооны удирдлагын товч бөгөөд ойлгоход хялбар танилцуулга болж өгдөг. Тохируулах, саяхан K8-ийн нэг хэсэг болсон.

Kustomize нь хэрэглэгчдэд "Энгийн, загваргүй YAML файлуудыг өөр өөр зорилгоор өөрчлөх, анхны YAML-г бүрэн бүтэн, ашиглах боломжтой" болгох боломжийг олгодог хэрэгсэл юм (тайлбарыг эндээс шууд зээлсэн) GitHub дээрх агуулахыг kustomize). Kustomize-г шууд ажиллуулж болно, эсвэл Kubernetes 1.14-ийн дагуу ашиглаж болно kubectl -k түүний функцэд хандахын тулд (хэдийгээр Kubernetes 1.15-ийн хувьд тусдаа хоёртын файл нь kubectl-д суулгасан боломжуудаас шинэ юм). (Анхаарна уу. орчуулга.: Мөн саяхан гарсан хувилбараар Кубернет 1.16 тохируулах дэмждэг Мөн kubeadm хэрэгсэлд байдаг.) Энэ нийтлэлд би уншигчдад kustomize-ийн үндсийг танилцуулахыг хүсч байна.

Хамгийн энгийн хэлбэр/програмд ​​kustomize нь ердөө л нөөцийн цуглуулга (Kubernetes объектуудыг тодорхойлсон YAML файлууд: Байршуулах, Үйлчилгээ гэх мэт) ба тэдгээр нөөцөд хийх шаардлагатай өөрчлөлтийн зааварчилгааны жагсаалт юм. Make нь дотор байгаа зааврын багцыг ашигладагтай адил Makefile, мөн Docker-ийн зааврын дагуу савыг бүтээдэг Dockerfile, хэрэглээг тохируулах kustomization.yaml Хэрэглэгч нөөцийн багцад ямар өөрчлөлт хийхийг хүсэж байгаа талаарх зааврыг хадгалах.

Энд жишээ файл байна kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Би файлын бүх боломжит талбаруудын талаар ярихыг оролдохгүй. kustomization.yaml (энэ тухай сайн бичсэн байна энд), гэхдээ би тодорхой жишээний талаар товч тайлбар өгөх болно:

• талбар resources kustomize юу (ямар нөөц) өөрчлөгдөхийг заана. Энэ тохиолдолд файл доторх нөөцийг хайх болно deployment.yaml и service.yaml өөрийн лавлахдаа (хэрэв шаардлагатай бол бүрэн эсвэл харьцангуй замыг зааж өгч болно).
• талбар namePrefix kustomize-д тодорхой угтвар нэмэхийг заадаг (энэ тохиолдолд - dev-) шинж чанар name талбарт тодорхойлсон бүх нөөц resources. Тиймээс, хэрэв Байршлуулалттай бол name үнэ цэнэтэй nginx-deployment, тохируулах нь үүнийг хийх болно dev-nginx-deployment.
• талбар namespace kustomize-д өгөгдсөн нэрийн орон зайг бүх нөөцөд нэмэхийг заадаг. Энэ тохиолдолд Deployment and Service нь нэрийн талбарт орох болно development.
• Эцэст нь, талбай commonLabels бүх нөөцөд нэмэгдэх шошгуудын багцыг агуулна. Бидний жишээн дээр kustomize нь нөөцөд нэр бүхий шошгыг өгөх болно environment мөн утга development.

Хэрэв хэрэглэгч тэгвэл kustomize build . файлын хамт директорт kustomization.yaml болон шаардлагатай нөөцүүд (жишээ нь файлууд deployment.yaml и service.yaml), дараа нь гаралт дээр заасан өөрчлөлттэй текстийг хүлээн авах болно kustomization.yaml.

Анхаарна уу. орчуулга.: Kustomize-ийн "энгийн" хэрэглээний талаархи төслийн баримт бичгийн зураг

Өөрчлөлт хийх шаардлагатай бол гаралтыг дахин чиглүүлж болно:

kustomize build . > custom-config.yaml

Гаралтын өгөгдөл нь тодорхойлогддог (ижил оролтын өгөгдөл нь ижил үр дүнг гаргах болно), тиймээс та үр дүнг файлд хадгалах шаардлагагүй. Үүний оронд үүнийг өөр тушаал руу шууд дамжуулж болно:

kustomize build . | kubectl apply -f -

Kustomize функцуудыг мөн дамжуулан авах боломжтой kubectl -k (Kubernetes 1.14 хувилбараас хойш). Гэсэн хэдий ч бие даасан kustomize багц нь нэгдсэн kubectl багцаас илүү хурдан шинэчлэгддэг гэдгийг санаарай (наад зах нь Kubernetes 1.15 хувилбартай холбоотой).

Уншигчид: "Хэрэв та файлуудыг шууд засварлаж чадвал яагаад ийм төвөгтэй байдаг вэ?" гэж асууж магадгүй юм. Их асуулт. Бидний жишээн дээр үнэхээр болно файлуудыг өөрчлөх deployment.yaml и service.yaml шууд, гэхдээ тэд өөр хэн нэгний төслийн салаа бол яах вэ? Файлуудыг шууд өөрчлөх нь гарал үүсэл/эх сурвалжид өөрчлөлт хийх үед сэрээг дахин суулгахад хэцүү (хэрэв боломжгүй бол) болгодог. Kustomize-ийг ашигласнаар эдгээр өөрчлөлтийг файлд төвлөрүүлэх боломжтой kustomization.yaml, анхны файлуудыг хэвээр үлдээж, шаардлагатай бол анхны файлуудыг дахин суурьлахад хялбар болгоно.

Kustomize-ийн ашиг тус нь илүү төвөгтэй хэрэглээний тохиолдлуудад тодорхой болно. Дээрх жишээнд kustomization.yaml мөн нөөцүүд нь нэг лавлахад байна. Гэсэн хэдий ч kustomize нь үндсэн тохиргоо болон түүний олон хувилбартай тохиолдолд ашиглах боломжийг дэмждэг. давхцал. Жишээлбэл, хэрэглэгч миний жишээ болгон ашигласан nginx-д зориулсан Deployment and Service-ийг авч, тэдгээр файлуудын хөгжүүлэлт, үе шат, үйлдвэрлэлийн хувилбаруудыг (эсвэл хувилбаруудыг) үүсгэхийг хүссэн. Үүнийг хийхийн тулд түүнд дээр дурдсан давхаргууд, үнэндээ үндсэн нөөцүүд хэрэгтэй болно.

Давхарга ба үндсэн нөөцийн санааг харуулах (үндсэн нөөц), лавлахууд дараах бүтэцтэй байна гэж үзье.

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

Файлд base/kustomization.yaml талбарыг ашиглаж буй хэрэглэгчид resources зүгээр л kustomize оруулах ёстой нөөцийг зарлах.

Файл бүрт overlays/{dev,staging,prod}/kustomization.yaml хэрэглэгчид талбар дахь үндсэн тохиргоонд хандана resources, дараа нь тодорхой өөрчлөлтүүдийг зааж өгнө өгөгдсөн орчин. Жишээлбэл, файл overlays/dev/kustomization.yaml Өмнө нь өгсөн жишээ шиг харагдаж болно:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Энэ тохиолдолд файл overlays/prod/kustomization.yaml огт өөр байж болно:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Хэрэглэгч ажиллах үед kustomize build . каталогид overlays/dev, kustomize нь хөгжүүлэлтийн сонголтыг бий болгоно. Хэрэв та гүйвэл kustomize build . каталогид overlays/prod - Та үйлдвэрлэлийн сонголтыг авах болно. Мөн энэ бүхэн - эх хувилбарт ямар ч өөрчлөлт оруулахгүйгээр (суурь) файлууд, бүгд тунхаглал, тодорхойлогч байдлаар. Та эдгээр файлууд дээр үндэслэн хүссэн тохиргоогоо хүссэн үедээ хуулбарлах боломжтой гэдгээ мэдэж байгаа тул үндсэн тохиргоо болон давхардсан лавлахуудыг хувилбарын удирдлагад шууд оруулах боломжтой.

Анхаарна уу. орчуулга.: Kustomize дахь давхаргыг ашиглах төслийн баримт бичгийн зураг

Тохируулах боломжтой их Энэ нийтлэлд дурдсанаас илүү. Гэсэн хэдий ч энэ нь сайн танилцуулга болно гэж найдаж байна.

Нэмэлт нөөц

Kustomize-ийн талаар олон сайхан нийтлэл, нийтлэлүүд байдаг. Энд надад онцгой хэрэгтэй гэж үзсэн хэд хэдэн зүйл байна:

• Kustomize ашиглан янз бүрийн орчинд YAML-ийн үндсэн тохиргоог өөрчил;
• Kustomize - Kubernetes дээр загвар хийх зөв арга;
• Customize ашиглан Kubernetes объектуудын тунхаглалын удирдлага;
• Тохиромжтой болгохын тулд урсгалын хүрд диаграмыг өөрчлөх.

Анхаарна уу. орчуулга.: Мөн та нийтэлсэн холбоосуудын блокыг санал болгож болно Mongolia хэрэгслийн вэбсайт дээр, дараа нь kustomize-ийн талаархи хамгийн сүүлийн үеийн тайлан бүхий видео бичлэгүүдийн цуглуулга.

Хэрэв танд энэ материалыг сайжруулах талаар асуулт эсвэл санал байвал би санал хүсэлтэд үргэлж бэлэн байна. Та надтай холбогдож болно Twitter болон Kubernetes Slack суваг. Kustomize ашиглан манифестуудаа өөрчлөхдөө хөгжилтэй байгаарай!

Орчуулагчийн жич

Мөн манай блог дээрээс уншина уу:

• «Kubernetes дээр ажиллаж байгаа программ хөгжүүлэгчдэд зориулсан хэрэгслүүд";
• «Kubernetes 1.14: үндсэн инновацийн тойм";
• «Амстердамд болсон Helm Summit 2019-ийн таван үндсэн үр дүн";
• «Kubernetes - Helm-ийн багц менежерийн практик танилцуулга".

Эх сурвалж: www.habr.com