Kubernetes-ийн хамгийн алдартай багц менежерийн тухай түүхийн мөн чанарыг эможи ашиглан дүрсэлж болно.
- хайрцаг нь Helm (энэ нь хамгийн сүүлийн үеийн Emoji хувилбарт хамгийн ойр байгаа зүйл);
- цоож - аюулгүй байдал;
- Бяцхан хүн бол асуудлын шийдэл юм.
Үнэн хэрэгтээ бүх зүйл арай илүү төвөгтэй байх болно, түүх нь техникийн нарийн ширийн зүйлсээр дүүрэн байдаг Helm-ийг хэрхэн аюулгүй болгох вэ.
- Хэрэв та мэдэхгүй эсвэл мартсан тохиолдолд Helm гэж юу болохыг товчхон хэлье. Энэ нь ямар асуудлыг шийдэж, экосистемд хаана байрладаг вэ.
- Helm архитектурыг харцгаая. Бүрэлдэхүүн хэсгийн архитектурыг ойлгохгүйгээр аюулгүй байдал, хэрэгсэл эсвэл шийдлийг хэрхэн илүү найдвартай болгох талаар яриа хэлэлцээ хийх боломжгүй юм.
- Helm бүрэлдэхүүн хэсгүүдийн талаар ярилцъя.
- Хамгийн гол асуулт бол ирээдүй - Helm 3-ын шинэ хувилбар юм.
Энэ нийтлэл дэх бүх зүйл Helm 2-д хамаарна. Энэ хувилбар нь одоогоор үйлдвэрлэгдэж байгаа бөгөөд таны одоо ашиглаж байгаа хувилбар бөгөөд аюулгүй байдлын эрсдэлийг агуулсан хувилбар юм.
Илтгэгчийн тухай: Александр Хайёров () нь 10 жилийн турш хөгжиж, агуулгыг сайжруулахад тусалдаг мөн хороонд элсэв . Одоо тэрээр Chainstack-д хөгжүүлэлтийн удирдагчаар ажилладаг - энэ нь хөгжлийн менежер ба эцсийн хувилбаруудыг хүргэх үүрэгтэй хүний хоорондын эрлийз юм. Өөрөөр хэлбэл, энэ нь дайны талбарт байрладаг бөгөөд бүтээгдэхүүн бүтээхээс эхлээд үйл ажиллагаа нь хүртэл бүх зүйл тохиолддог.
Chainstack нь жижиг, идэвхтэй хөгжиж буй стартап бөгөөд үйлчлүүлэгчдэд төвлөрсөн бус хэрэглээний программуудын дэд бүтэц, нарийн төвөгтэй байдлын талаар мартах боломжийг олгох зорилготой бөгөөд хөгжүүлэлтийн баг нь Сингапурт байрладаг. Chainstack-ээс криптовалют зарах, худалдаж авахыг бүү асуу, харин аж ахуйн нэгжийн блокчейн хүрээний талаар ярихыг санал болго, тэд танд баяртайгаар хариулах болно.
Helm
Энэ бол Kubernetes-ийн багц (диаграм) менежер юм. Кубернетес кластерт программуудыг авчрах хамгийн ойлгомжтой, түгээмэл арга.
Мэдээжийн хэрэг, бид өөрийн YAML манифест үүсгэж, жижиг хэрэгслүүд бичихээс илүү бүтцийн болон үйлдвэрлэлийн арга барилын талаар ярьж байна.
Helm бол одоо байгаа бөгөөд алдартай хамгийн шилдэг нь юм.
Яагаад Helm гэж? Юуны өмнө үүнийг CNCF дэмждэг. Cloud Native бол томоохон байгууллага бөгөөд Kubernetes, etcd, Fluentd болон бусад төслүүдийн толгой компани юм.
Өөр нэг чухал баримт бол Helm бол маш алдартай төсөл юм. Би 2019 оны 12-р сард Helm-ийг хэрхэн аюулгүй болгох талаар ярьж эхлэхэд төсөл GitHub дээр мянган одтой байсан. Тавдугаар сар гэхэд тэдний тоо XNUMX мянга болжээ.
Олон хүмүүс Helm-ийг сонирхож байгаа тул та үүнийг хараахан ашиглаагүй байсан ч түүний аюулгүй байдлын талаар мэдэх нь танд ашигтай байх болно. Аюулгүй байдал чухал.
Гол Helm багийг Microsoft Azure дэмждэг тул бусад олонхоос ялгаатай нь нэлээд тогтвортой төсөл юм. 3-р сарын дундуур Helm 2 Alpha XNUMX гарсан нь төсөл дээр маш олон хүмүүс ажиллаж байгаа бөгөөд тэд Helm-ийг хөгжүүлж, сайжруулах хүсэл, эрч хүчтэй байгааг харуулж байна.
Helm нь Kubernetes дахь хэрэглээний менежментийн хэд хэдэн үндсэн асуудлыг шийддэг.
- Хэрэглээний савлагаа. WordPress дээрх "Сайн уу, Дэлхий" гэх мэт програм хүртэл хэд хэдэн үйлчилгээнээс бүрдэх бөгөөд та тэдгээрийг багцлахыг хүсч байна.
- Эдгээр програмуудыг удирдахад ирдэг нарийн төвөгтэй байдлыг удирдах.
- Аппликейшнийг суулгасны дараа эсвэл байрлуулсны дараа дуусдаггүй амьдралын мөчлөг. Энэ нь амьдарсаар байгаа бөгөөд үүнийг шинэчлэх шаардлагатай бөгөөд Хелм үүнд тусалж, үүний тулд зөв арга хэмжээ, бодлогыг авчрахыг хичээдэг.
Уутлах Энэ нь тодорхой байдлаар зохион байгуулагдсан: Линукс, Windows эсвэл MacOS-д зориулсан ердийн багц менежерийн ажилд бүрэн нийцсэн мета өгөгдөл байдаг. Өөрөөр хэлбэл, репозитор, янз бүрийн багцын хамаарал, програмын мета мэдээлэл, тохиргоо, тохиргооны функцууд, мэдээллийн индексжүүлэлт гэх мэт. Helm нь энэ бүгдийг программуудад ашиглах боломжийг олгодог.
Нарийн төвөгтэй байдлын менежмент. Хэрэв танд ижил төрлийн олон програм байгаа бол параметржүүлэх шаардлагатай. Загварууд эндээс гардаг боловч загвар үүсгэх өөрийн гэсэн арга барилыг гаргахаас зайлсхийхийн тулд та Helm-ийн санал болгож буй зүйлийг ашиглаж болно.
Хэрэглээний амьдралын мөчлөгийн менежмент - Миний бодлоор энэ бол хамгийн сонирхолтой бөгөөд шийдэгдээгүй асуулт юм. Тийм ч учраас би тэр үед Хелмд ирсэн юм. Бид програмын амьдралын мөчлөгийг ажиглах шаардлагатай байсан бөгөөд CI/CD болон хэрэглээний циклээ энэ парадигмд шилжүүлэхийг хүссэн.
Helm танд дараах боломжийг олгоно:
- байршуулалтыг удирдах, тохиргоо, засварын тухай ойлголтыг танилцуулах;
- буцаах ажлыг амжилттай хийх;
- янз бүрийн үйл явдалд зориулж дэгээ ашиглах;
- нэмэлт програмын шалгалтыг нэмж, тэдгээрийн үр дүнд хариу өгөх.
Үүнээс гадна Жолоонд "батарей" байдаг - Таны амьдралыг хялбаршуулах залгаас хэлбэрээр оруулж болох олон тооны амттай зүйлс. Plugins-ийг бие даан бичиж болно, тэдгээр нь нэлээд тусгаарлагдсан бөгөөд эв нэгдэлтэй архитектур шаарддаггүй. Хэрэв та ямар нэг зүйлийг хэрэгжүүлэхийг хүсч байвал үүнийг залгаас болгон хийхийг зөвлөж байна, дараа нь үүнийг дээд хэсэгт оруулахыг зөвлөж байна.
Helm нь гурван үндсэн ойлголт дээр суурилдаг.
- Диаграмын репо — таны манифестэд боломжтой параметрийн тодорхойлолт ба массив.
- тохиргооны -өөрөөр хэлбэл хэрэглэгдэх утгууд (текст, тоон утга гэх мэт).
- Хувилбарын дээд хоёр бүрэлдэхүүн хэсгийг цуглуулж, тэд хамтдаа Release болж хувирдаг. Хувилбаруудыг хувилбар болгож, ингэснээр зохион байгуулалттай амьдралын мөчлөгт хүрч болно: суулгах үед жижиг, шинэчлэх, бууруулах эсвэл буцаах үед том хэмжээтэй.
Жолооны архитектур
Диаграм нь Helm-ийн өндөр түвшний архитектурыг концепцоор дүрсэлсэн.
Helm бол Кубернетестэй холбоотой зүйл гэдгийг танд сануулъя. Тиймээс бид Kubernetes кластер (тэгш өнцөгт)гүйгээр хийж чадахгүй. kube-apiserver бүрэлдэхүүн хэсэг нь мастер дээр байрладаг. Helm байхгүй бол бидэнд Kubeconfig байна. Helm нь компьютер, зөөврийн компьютер, үндсэн фрэйм гэх мэт бүх зүйл дээр суулгасан нэг жижиг хоёртын файлыг авчирдаг.
Гэхдээ энэ нь хангалтгүй юм. Helm нь Tiller нэртэй серверийн бүрэлдэхүүн хэсэгтэй. Энэ нь кластер доторх Helm-ийн ашиг сонирхлыг илэрхийлдэг; энэ нь бусадтай адил Кубернетес кластер доторх програм юм.
Chart Repo-ийн дараагийн бүрэлдэхүүн хэсэг нь диаграмм бүхий агуулах юм. Албан ёсны репозитор байдаг ба компани, төслийн хувийн репозитор байж болно.
Харилцаа холбоо
Бид Helm ашиглан програм суулгахыг хүссэн үед архитектурын бүрэлдэхүүн хэсгүүд хэрхэн харьцаж байгааг харцгаая.
- Бид ярьж байна
Helm install, репозитор руу (Chart Repo) нэвтэрч, Helm диаграмыг аваарай.
- Helm хэрэгсэл (Helm CLI) нь Kubeconfig-тэй харилцаж, аль кластертай холбогдохыг олж мэдэх болно.
- Энэхүү мэдээллийг хүлээн авсны дараа уг хэрэгсэл нь манай кластерт байрладаг Tiller-ийг програм гэж үздэг.
- Tiller Kubernetes-д үйлдэл хийх, зарим объект (үйлчилгээ, подс, хуулбар, нууц гэх мэт) үүсгэхийн тулд Kube-apiserver-д ханддаг.
Дараа нь бид бүхэл бүтэн Helm архитектурт өртөж болох халдлагын векторыг харахын тулд диаграммыг төвөгтэй болгоно. Тэгээд бид түүнийг хамгаалахыг хичээх болно.
Довтолгооны вектор
Эхний боломжит сул тал бол давуу эрхтэй API-хэрэглэгч. Уг схемийн нэг хэсэг болгон энэ бол Helm CLI-д админ хандах эрхийг авсан хакер юм.
Давуу эрхгүй API хэрэглэгч Ойролцоох нь бас аюул учруулж болзошгүй. Ийм хэрэглэгч өөр контексттэй байх болно, жишээлбэл, түүнийг Kubeconfig тохиргоонд нэг кластерын нэрийн талбарт засах боломжтой.
Хамгийн сонирхолтой халдлагын вектор нь Tiller-ийн ойролцоох кластер дотор байрладаг бөгөөд түүнд хандах боломжтой процесс байж болно. Энэ нь кластерын сүлжээний орчныг хардаг вэб сервер эсвэл микро үйлчилгээ байж болно.
Хачирхалтай, гэхдээ улам бүр түгээмэл болж буй халдлагын хувилбар нь Chart Repo-г агуулдаг. Шударга бус зохиогчийн бүтээсэн график нь аюултай нөөцийг агуулж болзошгүй тул та үүнийг итгэл үнэмшилд тулгуурлан дуусгах болно. Эсвэл энэ нь таны албан ёсны репозитороос татаж авсан диаграмыг орлуулж, жишээлбэл, бодлогын хэлбэрээр нөөц үүсгэж, түүний хандалтыг нэмэгдүүлэх боломжтой.
Эдгээр дөрвөн талаас довтолгооноос хамгаалж, Helm архитектурт хаана асуудал байгаа, хаана нь ямар ч асуудал байхгүй болохыг олж мэдье.
Диаграммыг томруулж, илүү олон элемент нэмж оруулъя, гэхдээ бүх үндсэн бүрэлдэхүүн хэсгүүдийг хадгалъя.
Helm CLI нь Chart Repo-той холбогдож, Kubeconfig-тэй харилцаж, ажлыг кластер руу Tiller бүрэлдэхүүн хэсэг рүү шилжүүлдэг.
Тариалагчийг хоёр объектоор төлөөлдөг.
- Тодорхой үйлчилгээг илчилсэн Tiller-deploy svc;
- Бүтэн ачаалал ажилладаг, кластерт ханддаг Tiller-deploy pod (диаграммд нэг хуулбараар нэг хуулбараар).
Харилцааны хувьд өөр өөр протокол, схемийг ашигладаг. Аюулгүй байдлын үүднээс бид хамгийн их сонирхож байна:
- Helm CLI нь график репо руу нэвтрэх механизм: ямар протокол, баталгаажуулалт байгаа эсэх, түүгээр юу хийж болох вэ.
- Helm CLI нь kubectl ашиглан Tiller-тэй харилцдаг протокол. Энэ нь кластер дотор суулгасан RPC сервер юм.
- Tiller нь өөрөө кластерт байрладаг микро үйлчилгээнд хандах боломжтой бөгөөд Kube-apiserver-тэй харьцдаг.
Эдгээр бүх чиглэлийг дарааллаар нь авч үзье.
RBAC
RBAC-г идэвхжүүлээгүй л бол кластер доторх Helm болон бусад үйлчилгээний аюулгүй байдлын талаар ярих нь утгагүй юм.
Энэ бол хамгийн сүүлийн үеийн зөвлөмж биш юм шиг санагдаж байна, гэхдээ олон хүмүүс RBAC-ийг үйлдвэрлэлд ч идэвхжүүлээгүй байгаа гэдэгт би итгэлтэй байна, учир нь энэ нь маш их шуугиан дэгдээж, олон зүйлийг тохируулах шаардлагатай байдаг. Гэсэн хэдий ч би таныг үүнийг хийхийг зөвлөж байна.
- RBAC-ийн вэбсайтын хуульч. Энэ нь танд RBAC-ыг тохируулах, яагаад сайн болохыг, үйлдвэрлэлд хэрхэн яаж амьдрахыг харуулахад туслах олон тооны сонирхолтой материалыг агуулдаг.
Би Tiller болон RBAC хэрхэн ажилладаг талаар тайлбарлахыг хичээх болно. Тиллер нь тодорхой үйлчилгээний дансны дор кластер дотор ажилладаг. Ерөнхийдөө, хэрэв RBAC тохируулагдаагүй бол энэ нь супер хэрэглэгч болно. Үндсэн тохиргоонд Tiller админ байх болно. Ийм учраас Tiller бол таны кластер руу чиглэсэн SSH хонгил гэж ихэвчлэн хэлдэг. Үнэн хэрэгтээ энэ нь үнэн тул та дээрх диаграммд заасан Үндсэн үйлчилгээний дансны оронд тусдаа тусгай үйлчилгээний данс ашиглаж болно.
Та Helm-ийг эхлүүлж, сервер дээр анх удаа суулгахдаа үйлчилгээний бүртгэлийг ашиглан тохируулж болно --service-account. Энэ нь танд шаардлагатай хамгийн бага эрх бүхий хэрэглэгчийг ашиглах боломжийг олгоно. Үнэн бол та ийм "зүүлэг" үүсгэх хэрэгтэй болно: Role and RoleBinding.
Харамсалтай нь, Helm үүнийг таны өмнөөс хийхгүй. Та эсвэл таны Kubernetes кластерын администратор нь Helm-д нэвтрэхийн тулд үйлчилгээний дансанд үүрэг болон үүрэг холбох багцыг урьдчилан бэлтгэх шаардлагатай.
Асуулт гарч ирнэ - Role болон ClusterRole хоёрын ялгаа юу вэ? Үүний ялгаа нь ClusterRole нь зөвхөн тусгай нэрийн талбарт ажилладаг ердийн Roles болон RoleBindings-ээс ялгаатай нь бүх нэрийн талбарт ажилладаг. Та бүхэл кластер болон бүх нэрийн талбарт зориулсан бодлогыг тохируулах эсвэл нэрийн талбар тус бүрд тус тусад нь тохируулж болно.
RBAC өөр нэг том асуудлыг шийдэж байгааг дурдах нь зүйтэй. Харамсалтай нь Helm нь олон түрээслэгч биш (олон түрээслэлтийг дэмждэггүй) гэж олон хүмүүс гомдоллодог. Хэрэв хэд хэдэн баг кластерыг ашиглаж, Helm ашигладаг бол энэ кластер дотор бодлого тогтоож, тэдний хандалтыг хязгаарлах нь үндсэндээ боломжгүй, учир нь Helm ажилладаг тодорхой үйлчилгээний бүртгэл байдаг бөгөөд энэ нь кластерын бүх нөөцийг доороос нь үүсгэдэг. , энэ нь заримдаа маш тохиромжгүй байдаг. Энэ нь үнэн - хоёртын файл шиг, процесс шиг, Хелм Тиллерт олон түрээсийн тухай ойлголт байдаггүй.
Гэсэн хэдий ч Tiller-ийг кластерт олон удаа ажиллуулах боломжийг олгодог гайхалтай арга бий. Үүнд ямар ч асуудал байхгүй, Tiller-ийг бүх нэрийн орон зайд ажиллуулж болно. Тиймээс та RBAC, Kubeconfig-ийг контекст болгон ашиглаж, тусгай Helm-д хандах хандалтыг хязгаарлаж болно.
Энэ нь иймэрхүү харагдах болно.
Жишээлбэл, өөр өөр багуудад зориулсан контекст бүхий хоёр Kubeconfig байдаг (хоёр нэрийн зай): Хөгжлийн баг болон админ кластерт зориулсан X баг. Админ кластер нь өөрийн гэсэн өргөн Tiller-тэй бөгөөд энэ нь Kube-системийн нэрийн талбарт байрладаг бөгөөд зохих ёсоор дэвшилтэт үйлчилгээний данс юм. Мөн хөгжүүлэлтийн багийн хувьд тусдаа нэрийн орон зай нь тэд үйлчилгээгээ тусгай нэрийн талбарт байрлуулах боломжтой болно.
Энэ бол ажиллах боломжтой арга бөгөөд Тиллер тийм ч их хүч чадалгүй тул таны төсөвт ихээхэн нөлөөлнө. Энэ бол хурдан шийдлүүдийн нэг юм.
Tiller-ийг тусад нь тохируулж, Kubeconfig-ийг баг, тодорхой хөгжүүлэгч эсвэл хүрээлэн буй орчинд зориулсан контекстээр хангах боломжтой: Хөгжүүлэгч, Үе шат, Үйлдвэрлэл (бүх зүйл нэг кластер дээр байх нь эргэлзээтэй, гэхдээ үүнийг хийж болно).
Түүхээ үргэлжлүүлж, RBAC-аас сольж, ConfigMaps-ийн талаар ярилцъя.
ConfigMaps
Helm нь ConfigMaps-ийг мэдээллийн сан болгон ашигладаг. Архитектурын талаар ярихад хувилбарууд, тохиргоонууд, буцаалтууд гэх мэт мэдээллийг хадгалах мэдээллийн сан байхгүй байсан. Үүнд ConfigMaps ашигладаг.
ConfigMaps-ийн гол асуудал нь мэдэгдэж байгаа - тэдгээр нь зарчмын хувьд аюултай; нууц мэдээллийг хадгалах боломжгүй. Үйлчилгээнээс хэтэрч болохгүй бүх зүйлийн талаар бид ярьж байна, жишээлбэл, нууц үг. Яг одоо Helm-ийн хамгийн уугуул арга бол ConfigMaps ашиглахаас нууцлал руу шилжих явдал юм.
Үүнийг маш энгийнээр хийдэг. Tiller тохиргоог дарж, хадгалах газар нь нууц байх болно гэдгийг зааж өгнө үү. Дараа нь байршуулалт бүрийн хувьд та ConfigMap биш, харин нууцыг хүлээн авах болно.
Нууц нь өөрөө хачирхалтай ойлголт бөгөөд тийм ч найдвартай биш гэж та маргаж болно. Гэсэн хэдий ч Kubernetes-ийн хөгжүүлэгчид өөрсдөө үүнийг хийж байгааг ойлгох нь зүйтэй. 1.10 хувилбараас эхлэн, i.e. Нэлээд удаан хугацааны турш, наад зах нь нийтийн үүлэн дунд нууц хадгалах зөв хадгалах санг холбох боломжтой болсон. Тус баг одоо нууц мэдээлэл, хувь хүн эсвэл бусад байгууллагуудад хандах хандалтыг илүү сайн түгээх арга зам дээр ажиллаж байна.
Storage Helm-ийг нууц руу шилжүүлэх нь дээр бөгөөд тэдгээр нь эргээд төвлөрсөн байдлаар хамгаалагдсан байдаг.
Мэдээжийн хэрэг үлдэх болно өгөгдөл хадгалах хязгаар 1 МБ. Helm энд etcd-г ConfigMaps-ийн хуваарилагдсан хадгалах сан болгон ашигладаг. Тэнд тэд үүнийг хуулбарлахад тохиромжтой өгөгдлийн хэсэг гэж үзсэн. Reddit дээр энэ талаар сонирхолтой хэлэлцүүлэг өрнөж байна, би энэ инээдтэй уншлагыг амралтын өдрүүдэд олохыг зөвлөж байна. .
Диаграмын репо
График нь нийгмийн хувьд хамгийн эмзэг бөгөөд ялангуяа хувьцааны шийдлийг ашигладаг бол "Дунд байгаа хүн"-ийн эх сурвалж болж чадна. Юуны өмнө бид HTTP-ээр дамжуулан нээлттэй байдаг репозиторуудын тухай ярьж байна.
Та HTTPS-ээр Helm Repo-г ил гаргах хэрэгтэй - энэ бол хамгийн сайн сонголт бөгөөд хямд юм.
анхаарал хандуулах графикийн гарын үсэг зурах механизм. Технологи нь там шиг энгийн юм. Энэ нь нийтийн болон хувийн түлхүүр бүхий энгийн PGP машин болох GitHub дээр ашигладагтай ижил зүйл юм. Тохируулж, шаардлагатай түлхүүрүүдтэй байж, бүх зүйлд гарын үсэг зурснаар энэ нь үнэхээр таны график мөн гэдэгт итгэлтэй байгаарай.
Цаашилбал, Helm үйлчлүүлэгч TLS-ийг дэмждэг (сервер талын HTTP утгаараа биш, харин харилцан TLS). Та харилцахын тулд сервер болон үйлчлүүлэгчийн түлхүүрүүдийг ашиглаж болно. Үнэнийг хэлэхэд би харилцан гэрчилгээнд дургүй учраас ийм механизм ашигладаггүй. Үндсэндээ, - Helm 2-д зориулсан Helm Repo-г тохируулах үндсэн хэрэгсэл - мөн үндсэн баталгаажуулалтыг дэмждэг. Хэрэв та илүү тохиромжтой, чимээгүй бол үндсэн баталгаажуулалтыг ашиглаж болно.
Мөн залгаас байдаг , энэ нь танд Google Cloud Storage дээр Chart Repos-г байршуулах боломжийг олгодог. Энэ нь маш тохиромжтой, маш сайн ажилладаг бөгөөд аюулгүй байдаг, учир нь тайлбарласан бүх механизмыг дахин боловсруулдаг.
Хэрэв та HTTPS эсвэл TLS-г идэвхжүүлж, mTLS-г ашиглаж, эрсдэлийг бууруулахын тулд үндсэн баталгаажуулалтыг идэвхжүүлбэл Helm CLI болон Chart Repo-той аюулгүй харилцааны суваг авах болно.
gRPC API
Дараагийн алхам бол маш чухал бөгөөд энэ нь кластерт байрладаг бөгөөд нэг талаас сервер, нөгөө талаас өөрөө бусад бүрэлдэхүүн хэсгүүдэд нэвтэрч, хэн нэгний дүр эсгэхийг оролддог Tiller-ийг хамгаалах явдал юм.
Би аль хэдийн хэлсэнчлэн Tiller бол gRPC-г ил гаргадаг үйлчилгээ бөгөөд Helm үйлчлүүлэгч нь gRPC-ээр дамжуулан ирдэг. Анхдагч байдлаар мэдээж TLS идэвхгүй байна. Яагаад үүнийг хийсэн нь маргаантай асуулт бөгөөд эхэндээ тохиргоог хялбаршуулсан гэж би бодож байна.
Үйлдвэрлэл, тэр ч байтугай найруулгын хувьд би gRPC дээр TLS-г идэвхжүүлэхийг зөвлөж байна.
Миний бодлоор диаграммд зориулсан mTLS-ээс ялгаатай нь энэ нь энд тохиромжтой бөгөөд маш энгийн байдлаар хийгддэг - PQI дэд бүтцийг бий болгох, гэрчилгээ үүсгэх, Tiller-ийг эхлүүлэх, эхлүүлэх явцад гэрчилгээг шилжүүлэх. Үүний дараа та үүсгэсэн гэрчилгээ болон хувийн түлхүүрээр өөрийгөө танилцуулж, бүх Helm командуудыг гүйцэтгэж болно.
Ингэснээр та кластерын гаднаас Тиллерт ирэх бүх хүсэлтээс өөрийгөө хамгаалах болно.
Тиймээс бид Tiller-тэй холбогдох сувгийг хамгаалж, RBAC-ийн талаар аль хэдийн ярилцаж, Kubernetes apiserver-ийн эрхийг тохируулж, түүний харилцах домэйныг багасгасан.
Хамгаалагдсан дуулга
Эцсийн диаграммыг харцгаая. Энэ нь ижил сумтай ижил архитектур юм.
Одоо бүх холболтыг ногоон өнгөөр аюулгүйгээр зурж болно:
- Chart Repo-д бид TLS эсвэл mTLS болон үндсэн баталгаажуулалтыг ашигладаг;
- Tiller-д зориулсан mTLS бөгөөд энэ нь TLS-тэй gRPC үйлчилгээ хэлбэрээр илэрдэг тул бид гэрчилгээ ашигладаг;
- кластер нь Role болон RoleBinding-тэй тусгай үйлчилгээний бүртгэлийг ашигладаг.
Бид кластерыг ихээхэн хамгаалсан боловч хэн нэгэн ухаалаг хэлэв:
"Цэргүүд хамгаалж, бетон хайрцагт байрлуулсан, унтраасан компьютер гэсэн туйлын аюулгүй шийдэл байж болно."
Өгөгдлийг удирдах, шинэ халдлагын векторуудыг олох янз бүрийн арга байдаг. Гэсэн хэдий ч эдгээр зөвлөмжүүд нь аюулгүй байдлын үндсэн салбарын стандартад хүрнэ гэдэгт би итгэлтэй байна.
Шагнал
Энэ хэсэг нь аюулгүй байдалтай шууд хамааралгүй, гэхдээ бас ашигтай байх болно. Цөөн хүний мэддэг сонирхолтой зүйлсийг би танд үзүүлэх болно. Жишээлбэл, графикийг хэрхэн хайх вэ - албан ёсны болон албан бус.
Хадгалах газарт Одоо 300 орчим график, тогтвортой, инкубатор гэсэн хоёр урсгал бий. Инкубатороос хашаа руу ороход ямар хэцүү, хашаанаас нисэх нь ямар амархан байдгийг хувь нэмрээ оруулсан хэн бүхэн сайн мэднэ. Гэсэн хэдий ч, энэ нь Prometheus болон өөр дуртай бүхний график хайх хамгийн сайн хэрэгсэл биш бөгөөд нэг энгийн шалтгаанаар энэ нь багцуудыг хялбархан хайх боломжтой портал биш юм.
Гэхдээ үйлчилгээ байдаг , энэ нь график олоход илүү хялбар болгодог. Хамгийн гол нь өөр олон гадаад хадгалах газар, бараг 800 увдис байдаг. Түүнчлэн, хэрэв та ямар нэг шалтгааны улмаас графикаа тогтвортой руу илгээхийг хүсэхгүй байгаа бол репозитороо холбож болно.
hub.helm.sh-г туршаад хамтдаа хөгжүүлцгээе. Энэ үйлчилгээ нь Helm төслийн хүрээнд явагддаг бөгөөд хэрэв та урд талын хөгжүүлэгч бөгөөд зөвхөн гадаад төрхийг сайжруулахыг хүсч байвал түүний UI-д хувь нэмрээ оруулах боломжтой.
Би бас таны анхаарлыг татахыг хүсч байна Нээлттэй Service Broker API интеграцчилал. Энэ нь төвөгтэй, ойлгомжгүй мэт сонсогдож байгаа ч хүн бүрт тулгардаг асуудлыг шийддэг. Энгийн жишээгээр тайлбарлая.
Бид сонгодог програм болох WordPress-ийг ажиллуулахыг хүсч буй Kubernetes кластер байдаг. Ерөнхийдөө бүрэн ажиллагаатай байхын тулд мэдээллийн сан хэрэгтэй. Олон янзын шийдэл байдаг, жишээлбэл, та өөрийн статустай үйлчилгээг эхлүүлэх боломжтой. Энэ нь тийм ч тохиромжтой биш боловч олон хүн үүнийг хийдэг.
Бусад нь Chainstack дээрх бидэн шиг MySQL эсвэл PostgreSQL гэх мэт удирддаг мэдээллийн санг сервертээ ашигладаг. Тийм ч учраас манай мэдээллийн сан үүлэн дотор хаа нэгтээ байрладаг.
Гэхдээ асуудал гарч ирдэг: бид үйлчилгээгээ мэдээллийн сантай холбож, мэдээллийн баазын амтыг үүсгэж, итгэмжлэлийг шилжүүлж, ямар нэгэн байдлаар удирдах хэрэгтэй. Энэ бүгдийг ихэвчлэн системийн администратор эсвэл хөгжүүлэгч гараар хийдэг. Мөн цөөн программтай үед ямар ч асуудал байхгүй. Олон байхад комбайн хэрэгтэй. Ийм хураагч байдаг - энэ бол Үйлчилгээний зуучлагч юм. Энэ нь танд олон нийтийн үүлэн кластерт зориулсан тусгай залгаасыг ашиглах, API шиг брокероор дамжуулан үйлчилгээ үзүүлэгчээс нөөц захиалах боломжийг олгоно. Үүнийг хийхийн тулд та уугуул Kubernetes хэрэгслийг ашиглаж болно.
Энэ нь маш энгийн. Та жишээ нь, Azure дахь Managed MySQL-г үндсэн давхаргаар асууж болно (үүнийг тохируулж болно). Azure API ашиглан мэдээллийн санг үүсгэж, ашиглахад бэлтгэнэ. Та үүнд хөндлөнгөөс оролцох шаардлагагүй, залгаас нь үүнийг хариуцдаг. Жишээлбэл, OSBA (Azure залгаас) нь итгэмжлэлийг үйлчилгээнд буцааж, Helm руу дамжуулах болно. Та WordPress-ийг үүл MySQL-тэй ашиглах боломжтой бөгөөд удирддаг мэдээллийн баазтай огт харьцахгүй, доторх үйлчилгээний талаар санаа зовохгүй байх болно.
Helm нь нэг талаас үйлчилгээ нэвтрүүлэх боломжийг олгодог цавуу болж, нөгөө талаас үүлэн үйлчилгээ үзүүлэгчдийн нөөцийг ашигладаг гэж бид хэлж чадна.
Та өөрийн залгаасыг бичиж, энэ түүхийг бүхэлд нь газар дээр нь ашиглаж болно. Дараа нь та корпорацийн Cloud үйлчилгээ үзүүлэгчийн өөрийн залгаастай болно. Хэрэв та том хэмжээтэй бөгөөд тухайн функцийн хөгжүүлэлт, үе шат эсвэл бүхэл бүтэн дэд бүтцийг хурдан байршуулахыг хүсч байвал би энэ аргыг туршиж үзэхийг зөвлөж байна. Энэ нь таны үйл ажиллагаа эсвэл DevOps-ийн амьдралыг хөнгөвчлөх болно.
Миний өмнө дурдсан өөр нэг олдвор бол helm-gcs залгаас, энэ нь танд Google-buckets (объект хадгалах) ашиглан Helm диаграмыг хадгалах боломжийг олгодог.
Үүнийг ашиглаж эхлэхийн тулд танд ердөө дөрвөн тушаал хэрэгтэй:
- залгаасыг суулгах;
- үүнийг эхлүүлэх;
- gcp-д байрлах хувин руу хүрэх замыг тохируулах;
- графикийг стандарт аргаар нийтлэх.
Зөвшөөрөлдөө уугуул gcp аргыг ашиглах нь гоо үзэсгэлэн юм. Та үйлчилгээний данс, хөгжүүлэгчийн данс, хүссэн бүхнээ ашиглаж болно. Энэ нь маш тохиромжтой бөгөөд ажиллуулахад ямар ч зардал гарахгүй. Хэрэв та над шиг сэтгэлгээгүй философийг сурталчлах юм бол энэ нь ялангуяа жижиг багуудад маш тохиромжтой байх болно.
Хувилбарууд
Helm бол үйлчилгээний менежментийн цорын ганц шийдэл биш юм. Энэ талаар маш олон асуулт гарч ирдэг бөгөөд энэ нь гурав дахь хувилбар нь ийм хурдан гарч ирсэн байж магадгүй юм. Мэдээжийн хэрэг өөр хувилбарууд байдаг.
Эдгээр нь тусгай шийдэл байж болно, жишээлбэл, Ksonnet эсвэл Metaparticle. Та өөрийн сонгодог дэд бүтцийн менежментийн хэрэгслүүдээ (Ansible, Terraform, Chef гэх мэт) миний ярьсантай ижил зорилгоор ашиглаж болно.
Эцэст нь шийдэл бий , алдар нэр нь өсч байна.
Operator Framework бол Helm-ийн хамгийн шилдэг хувилбар юм.
Энэ нь CNCF болон Kubernetes-ээс илүү төрөлх юм. гэхдээ орох саад нь хамаагүй өндөр, та илүү их програмчилж, манифестуудыг бага тайлбарлах хэрэгтэй.
Draft, Scaffold гэх мэт янз бүрийн нэмэлтүүд байдаг. Тэд амьдралыг ихээхэн хөнгөвчлөх, жишээлбэл, хөгжүүлэгчдэд туршилтын орчинг байрлуулахын тулд Helm-г илгээх, ажиллуулах циклийг хялбаршуулдаг. Би тэднийг хүчирхэгжүүлэгч гэж нэрлэх болно.
Энд бүх зүйл хаана байгааг харуулсан график байна.
X тэнхлэг дээр юу болж байгааг таны хувийн хяналтын түвшин, y тэнхлэг дээр Кубернетесийн уугуул байдлын түвшин байна. Helm хувилбар 2 нь хаа нэгтээ дунд хэсэгт ордог. 3-р хувилбарт тийм ч их биш, харин хяналт, төрөлхийн түвшинг хоёуланг нь сайжруулсан. Ksonnet түвшний шийдэл нь Helm 2-оос ч доогуур хэвээр байна. Гэсэн хэдий ч, энэ дэлхий дээр өөр юу байгааг мэдэхийн тулд тэдгээрийг анхаарч үзэх хэрэгтэй. Мэдээжийн хэрэг, таны тохиргооны менежер таны хяналтанд байх болно, гэхдээ энэ нь Kubernetes-д хамаарахгүй.
Operator Framework нь Kubernetes-ийн жинхэнэ эх сурвалж бөгөөд танд үүнийг илүү гоёмсог, болгоомжтой удирдах боломжийг олгодог (гэхдээ нэвтрэх түвшний талаар санаарай). Үүний оронд энэ нь Helm ашиглан асар олон тооны програмуудыг савлах зориулалттай масс хураагч гэхээсээ илүү тусгай хэрэглээ, менежментийг бий болгоход тохиромжтой.
Өргөтгэгчид нь хяналтыг бага зэрэг сайжруулж, ажлын урсгалыг нөхөж эсвэл CI/CD дамжуулах шугамын булангуудыг багасгадаг.
Хелмийн ирээдүй
Сайн мэдээ гэвэл Helm 3 гарах гэж байна. Helm 3.0.0-alpha.2-ын альфа хувилбар аль хэдийн гарсан тул та үүнийг туршиж үзэх боломжтой. Энэ нь нэлээд тогтвортой боловч үйл ажиллагаа нь хязгаарлагдмал хэвээр байна.
Яагаад танд Helm 3 хэрэгтэй байна вэ? Юуны өмнө энэ бол түүх юм Тиллер алга болсон, бүрэлдэхүүн хэсэг болгон. Энэ нь та аль хэдийн ойлгож байгаачлан, урагшлах маш том алхам юм, учир нь архитектурын аюулгүй байдлын үүднээс бүх зүйл хялбаршуулсан болно.
Kubernetes 2 эсвэл түүнээс өмнөх үеийн үед байсан Helm 1.8-г бүтээхэд олон ойлголт төлөвшөөгүй байсан. Жишээлбэл, CRD үзэл баримтлал одоо идэвхтэй хэрэгжиж байгаа бөгөөд Хелм үүнийг хэрэгжүүлэх болно CRD ашиглахбүтцийг хадгалах. Энэ нь зөвхөн үйлчлүүлэгчийг ашиглах боломжтой бөгөөд серверийн хэсгийг хадгалахгүй байх болно. Үүний дагуу бүтэц, нөөцтэй ажиллахын тулд төрөлх Kubernetes тушаалуудыг ашиглана уу. Энэ бол маш том алхам юм.
Гарч ирнэ эх OCI репозиторыг дэмжих (Нээлттэй контейнер санаачилга). Энэ бол асар том санаачлага бөгөөд Хелм үндсэндээ графикуудаа нийтлэхийг сонирхож байна. Жишээлбэл, Docker Hub нь олон OCI стандартыг дэмждэг. Би таамаглаагүй байна, гэхдээ сонгодог Docker репозиторын үйлчилгээ үзүүлэгчид танд Helm диаграмаа байршуулах боломжийг олгож эхлэх байх.
Миний хувьд маргаантай түүх бол Луа дэмжиж байна, скрипт бичих загварчлалын хөдөлгүүр болгон. Би Луагийн нэг их шүтэн бишрэгч биш, гэхдээ энэ нь бүрэн сонголт байх болно. Би үүнийг 3 удаа шалгасан - Луа ашиглах шаардлагагүй болно. Тиймээс Lua-г ашиглахыг хүсч байгаа хүмүүс, Go-д дуртай хүмүүс манай том лагерт нэгдэж, go-tmpl-ийг ашиглах хэрэгтэй.
Эцэст нь надад үнэхээр дутагдаж байсан зүйл байсан схем гарч ирэх ба өгөгдлийн төрлийг баталгаажуулах. Дахиж int эсвэл стрингтэй холбоотой асуудал гарахгүй, тэгийг давхар хашилтанд оруулах шаардлагагүй болно. JSONS схем гарч ирэх бөгөөд энэ нь танд утгын хувьд үүнийг тодорхой тайлбарлах боломжийг олгоно.
Маш их засвар хийх болно үйл явдалд тулгуурласан загвар. Үүнийг аль хэдийн үзэл баримтлалын хувьд тайлбарласан. Helm 3 салбарыг харвал та хичнээн олон үйл явдал, дэгээ болон бусад зүйлс нэмэгдсэнийг харах болно, энэ нь маш хялбаршуулж, нөгөө талаас байршуулах үйл явц, хариу үйлдлийг хянах боломжтой болно.
Helm 3 нь бид Helm 2-т дургүй учраас биш, харин Kubernetes илүү дэвшилтэт болж байгаа учраас илүү энгийн, аюулгүй, илүү хөгжилтэй байх болно. Үүний дагуу Helm Kubernetes-ийн хөгжүүлэлтийг ашиглаж, үүн дээр Kubernetes-ийн маш сайн менежерүүдийг бий болгож чадна.
Өөр нэг сайн мэдээ бол энэ юм Александр Хайёров танд хэлэх болно. Хөгжил, туршилт, ашиглалтын үйл явцыг нэгтгэх хурал Москвад болно гэдгийг сануулъя 30-р сарын 1, XNUMX-р сарын XNUMX. Та үүнийг 20-р сарын XNUMX хүртэл хийх боломжтой мөн шийдэлтэй холбоотой туршлагаа бидэнд хэлээрэй DevOps аргын даалгавар.
Чуулганы хяналтын цэг болон мэдээг дараах хаягаар дагаарай и .
Эх сурвалж: www.habr.com