XNUMX-р сарын сүүлээр сэдвээр цахим хурал хийлээ . Бид чингэлэг, Кубернетес болон зарчмын хувьд найрал хөгжим, дэд бүтцийг сонгох шалгуур болон бусад зүйлийн талаар ярилцсан. Оролцогчид өөрсдийн туршлагаасаа хуваалцсан.
Оролцогчид:
- Евгений Потапов, ITSumma компанийн гүйцэтгэх захирал. Үйлчлүүлэгчдийн талаас илүү хувь нь аль хэдийн шилжиж байгаа эсвэл Кубернетес рүү шилжихийг хүсч байна.
- Дмитрий Столяров, "Флант" техникийн захирал. Контейнерын систем дээр ажиллаж байсан 10 гаруй жилийн туршлагатай.
- Денис Ремчуков (эрик Олдманн), COO argotech.io, хуучин RAO UES. Тэрбээр “цуст” аж ахуйн нэгжийн хэргийн талаар ярихаа амласан.
- Андрей Федоровский, CTO "News360.com"Компанийг өөр тоглогч худалдаж авсны дараа тэрээр олон тооны ML болон AI төсөл, дэд бүтцийг хариуцдаг.
- Иван Круглов, хуучин Booking.com сайтын системийн инженер.Өөрийнхөө гараар Кубернетестэй маш их зүйлийг хийсэн хүн.
Сэдэв:
- Оролцогчдын контейнер ба зохион байгуулалтын талаархи ойлголт (Docker, Kubernetes гэх мэт); практик дээр туршиж үзсэн эсвэл дүн шинжилгээ хийсэн.
- Кейс: Тус компани олон жилийн турш дэд бүтцийн хөгжлийн төлөвлөгөө боловсруулж байна. Дэд бүтцийг барьж байгуулах (эсвэл одоогийн байгаа) байгууламжийг контейнер болон Кубер руу шилжүүлэх эсэх шийдвэрийг хэрхэн гаргадаг вэ?
- Үүлний уугуул ертөнцөд тулгарч буй асуудлууд, юу дутагдаж байна, маргааш юу болохыг төсөөлөөд үз дээ.
Сонирхолтой хэлэлцүүлэг өрнөж, оролцогчдын санал бодол маш их ялгаатай, маш олон сэтгэгдэл үлдээсэн тул та бүхэнтэй хуваалцахыг хүсч байна. Идэх , мөн доорх хэлэлцүүлгийн хураангуй юм.
Kubernetes аль хэдийн стандарт эсвэл гайхалтай маркетинг үү?
“Бид энэ тухай (Кубернетес. - Ред.) хэн ч мэдэхгүй байхад ирсэн. Түүнийг байхгүй үед ч бид түүн дээр ирсэн. Бид үүнийг өмнө нь хүсч байсан" - Дмитрий Столяров
Reddit.com сайтаас авсан зураг
5-10 жилийн өмнө маш олон тооны багаж хэрэгсэл байсан бөгөөд нэг стандарт байгаагүй. Зургаан сар тутамд шинэ бүтээгдэхүүн гарч ирэв, эсвэл бүр нэгээс олон. Эхлээд тэнүүлч, дараа нь Давс, тогооч, хүүхэлдэй,... "мөн та зургаан сар тутамд дэд бүтцээ сэргээдэг. Танд тохиргоог дахин бичих завгүй байдаг таван админ бий" гэж Андрей Федоровский дурсав. Тэрээр Докер, Кубернетес нар бусад хүмүүсийг "хөгжүүлсэн" гэж тэр үзэж байна. Докер сүүлийн таван жилд, Кубернетес сүүлийн хоёр жилд стандарт болсон. Мөн энэ нь салбарын хувьд ашигтай..
Дмитрий Столяров ба түүний баг Куберт дуртай. Тэд ийм хэрэгсэл гарч ирэхээс нь өмнө хүсч байсан бөгөөд энэ талаар хэн ч мэдэхгүй байхад хүрч ирсэн. Одоогийн байдлаар тэд Кубернетесийг түүнтэй хамт хэрэгжүүлэхгүй гэдгээ ойлговол ая тухтай байдлын үүднээс үйлчлүүлэгч авахгүй. Үүний зэрэгцээ, Дмитрийгийн хэлснээр тус компани "аймшигт өвийг сэргээх талаар олон гайхалтай амжилтын түүхтэй".
Kubernetes нь зөвхөн контейнер зохион байгуулалт биш, энэ нь боловсруулсан API, сүлжээний бүрэлдэхүүн хэсэг, L3 тэнцвэржүүлэгч болон Ingress хянагчтай тохиргооны удирдлагын систем бөгөөд нөөцийг удирдах, масштаблах, дэд бүтцийн доод давхаргаас хийсвэрлэн гаргахад харьцангуй хялбар болгодог.
Харамсалтай нь бидний амьдралд бид бүх зүйлийг төлөх ёстой. Мөн Иван Кругловын үзэж байгаагаар хөгжингүй дэд бүтэцтэй компаний Кубернетес рүү шилжих тухай ярих юм бол энэ татвар маш том юм. Тэрээр уламжлалт дэд бүтэцтэй компани болон Кубертэй хоёуланд нь чөлөөтэй ажиллах боломжтой байв. Хамгийн гол нь тухайн компани, зах зээлийн онцлогийг ойлгох явдал юм. Гэхдээ, жишээлбэл, Кубернетесийг ямар ч контейнер зохион байгуулах хэрэгсэл болгон нэгтгэх Евгений Потаповын хувьд ийм асуулт гарч ирдэггүй.
Евгений 1990-ээд онд объект хандалтат програмчлал нь нарийн төвөгтэй програмуудыг програмчлах арга хэлбэрээр гарч ирсэн нөхцөл байдалтай адилтгаж үзжээ. Тэр үед мэтгэлцээн үргэлжилж, OOP-ийг дэмжих шинэ хэрэгслүүд гарч ирэв. Дараа нь микро үйлчилгээнүүд цул үзэл баримтлалаас холдох арга зам болж гарч ирэв. Энэ нь эргээд чингэлэг, савны менежментийн хэрэгсэл бий болоход хүргэсэн. "Бид удахгүй жижиг микро үйлчилгээний програм бичих нь зүйтэй эсэх талаар ямар ч асуудал гарахгүй, энэ нь анхдагчаар бичил үйлчилгээ хэлбэрээр бичигдэх болно гэж би бодож байна" гэж тэр үзэж байна. Үүний нэгэн адил Докер, Кубернетес нар эцэст нь сонголт хийх шаардлагагүй стандарт шийдэл болно.
Харьяалалгүй хүмүүсийн мэдээллийн сангийн асуудал
Фото зураг
Өнөө үед Кубернетес дэх мэдээллийн санг ажиллуулах олон жор байдаг. Оролт гаралтын дисктэй ажилладаг хэсгийг болзолтойгоор мэдээллийн сангийн хэрэглээний хэсгээс хэрхэн салгах вэ. Ирээдүйд мэдээллийн сангууд нь маш их өөрчлөгдөж, нэг хэсгийг нь Docker болон Kubernetes-ээр дамжуулан, дэд бүтцийн өөр хэсэгт тусдаа програм хангамжаар дамжуулан хадгалах хэсгийг нь өгөх хайрцагт хүргэх боломжтой юу? ? Бүтээгдэхүүний хувьд суурь нь өөрчлөгдөх үү?
Энэ тайлбар нь дарааллын менежменттэй төстэй боловч уламжлалт мэдээллийн сан дахь мэдээллийн найдвартай байдал, синхрончлолд тавигдах шаардлага илүү өндөр байдаг гэж Андрей үзэж байна. Энгийн мэдээллийн сан дахь кэшийн цохилтын харьцаа 99% хэвээр байна. Хэрэв ажилчин доошоо буувал шинийг ажиллуулж, кэш эхнээс нь "дулаацдаг". Кэшийг халаах хүртэл ажилтан удаан ажилладаг бөгөөд энэ нь хэрэглэгчийн ачаалалд ачаалах боломжгүй гэсэн үг юм. Хэрэглэгчийн ачаалал байхгүй ч кэш дулаардаггүй. Энэ бол харгис тойрог юм.
Дмитрий зарчмын хувьд санал нийлэхгүй байна - чуулгууд болон хуваалтууд асуудлыг шийддэг. Гэвч Андрей энэ шийдэл нь хүн бүрт тохиромжгүй гэж батлав. Зарим тохиолдолд чуулга тохиромжтой байдаг ч сүлжээнд нэмэлт ачаалал өгдөг. NoSQL мэдээллийн сан нь бүх тохиолдолд тохиромжгүй.
Уулзалтад оролцогчид хоёр лагерьт хуваагдсан.
Денис, Андрей хоёр дискэнд бичигдсэн бүх зүйлийг - мэдээллийн сан гэх мэтийг одоогийн Кубер экосистемд хийх боломжгүй гэж маргадаг. Kubernetes дахь үйлдвэрлэлийн мэдээллийн бүрэн бүтэн байдал, тууштай байдлыг хадгалах боломжгүй юм. Энэ бол үндсэн шинж чанар юм. Шийдэл: гибрид дэд бүтэц.
MongoDB, Cassandra гэх мэт орчин үеийн үүлэн мэдээллийн сан эсвэл Кафка эсвэл RabbitMQ гэх мэт мессежийн дараалалууд хүртэл Кубернетесээс гадуур байнгын мэдээллийн санг шаарддаг.
Евгений хэлэхдээ: "Кубера дахь баазууд нь Оросын ойролцоох, эсвэл аж ахуйн нэгжийн ойролцоо гэмтэл бөгөөд энэ нь Орост үүл үрчлэх ажиллагаа байдаггүйтэй холбоотой юм." Барууны жижиг дунд компаниуд бол Үүлэн . Amazon RDS мэдээллийн сангууд нь Kubernetes-тэй өөрөө оролдохоос илүү хялбар байдаг. Орос улсад тэд амьтны хүрээлэнгээс салах гэж оролдохдоо Куберийг "байгууллагадаа" ашигладаг бөгөөд баазаа түүн рүү шилжүүлдэг.
Дмитрий мөн Кубернетес дэх мэдээллийн сан хадгалах боломжгүй гэсэн мэдэгдэлтэй санал нийлэхгүй байна: "Суурь нь баазаас ялгаатай. Хэрэв та аварга том харилцааны мэдээллийн сан руу түлхэж байгаа бол ямар ч тохиолдолд. Хагас түр зуурын амьдралд оюун санааны хувьд бэлтгэгдсэн жижиг, үүлэрхэг уугуул зүйлийг түлхэж өгвөл бүх зүйл сайхан болно." Дмитрий мөн өгөгдлийн сангийн менежментийн хэрэгслүүд нь Docker эсвэл Kuber-ийн аль алинд нь бэлэн биш байгаа тул маш их бэрхшээлтэй тулгардаг гэж дурдсан.
Иван, эргээд бид төрийн болон харьяалалгүй гэсэн ойлголтоос хийсвэрлэсэн ч Кубернетес дэх аж ахуйн нэгжийн шийдлүүдийн экосистем хараахан бэлэн болоогүй байгаа гэдэгт итгэлтэй байна. Kuber-ийн тусламжтайгаар хууль тогтоомж, зохицуулалтын шаардлагыг хангахад хэцүү байдаг. Жишээлбэл, серверт суулгасан техник хангамж хүртэл серверийг таниулах хатуу баталгаа шаардагддаг бол таниулах шийдлийг гаргах боломжгүй юм. Энэ салбар хөгжиж байгаа ч одоохондоо шийдэл алга.
Оролцогчид санал нэгдэж чадаагүй тул энэ хэсэгт дүгнэлт хийхгүй. Хэд хэдэн практик жишээ хэлье.
Кейс 1. Куберагийн гадна байрлах баазтай “мега зохицуулагч”-ын кибер аюулгүй байдал
Хөгжингүй кибер аюулгүй байдлын системийн хувьд контейнер, зохион байгуулалтыг ашиглах нь халдлага, халдлагыг эсэргүүцэх боломжийг олгодог. Жишээлбэл, нэг мега зохицуулагч дээр Денис болон түүний баг логуудыг бодит цаг хугацаанд шинжилж, халдлага, хакердах, бүтэлгүйтлийн үйл явцыг тодорхойлдог бэлтгэгдсэн SIEM үйлчилгээтэй найруулагчийн хослолыг хэрэгжүүлсэн. Халдлагад өртөх, ямар нэгэн зүйл байрлуулах оролдлого, эсвэл ransomware вирус халдсан тохиолдолд энэ нь найруулагчаар дамжуулан програмууд бүхий савыг халдвар авахаас илүү хурдан эсвэл халдагчийн дайралтаас хурдан авдаг.
Тохиолдол 2. Booking.com мэдээллийн санг Кубернетес рүү хэсэгчлэн шилжүүлсэн
Booking.com-д үндсэн мэдээллийн сан нь асинхрон хуулбарлалттай MySQL юм - мастер, боолуудын бүх шатлал байдаг. Иван компанийг орхих үед тодорхой хохиролтой "буудагдах" боломжтой боолуудыг шилжүүлэх төсөл хэрэгжиж эхэлсэн.
Үндсэн баазаас гадна Кубер гол урсгалд орохоос өмнө бичигдсэн өөрөө бичсэн найрал хөгжимтэй Кассандра инсталляци байдаг. Энэ талаар ямар ч асуудал байхгүй, гэхдээ энэ нь орон нутгийн SSD дээр тогтвортой байдаг. Алсын санах ой, тэр ч байтугай нэг өгөгдлийн төвд байсан ч өндөр хоцрогдолтой байдлаас болж ашиглагддаггүй.
Өгөгдлийн сангийн гуравдахь анги нь Booking.com хайлтын үйлчилгээ бөгөөд үйлчилгээний цэг бүр мэдээллийн сан юм. Хайлтын үйлчилгээг Kuber руу шилжүүлэх оролдлого амжилтгүй болсон, учир нь зангилаа бүр нь 60-80 ГБ дотоод санах ойтой тул "өргөх", "дулаацуулах" нь хэцүү байдаг.
Үүний үр дүнд хайлтын системийг Кубернетес рүү шилжүүлээгүй бөгөөд Иван ойрын ирээдүйд шинэ оролдлого гарахгүй гэж бодож байна. MySQL мэдээллийн баазыг хагасаар шилжүүлсэн: зөвхөн "буудагдахаас" айдаггүй Боолууд. Кассандра төгс суурьшсан.
Дэд бүтцийн сонголт нь ерөнхий шийдэлгүй ажил
Фото зураг
Шинэ компани, эсвэл дэд бүтцийн нэг хэсэг нь хуучин аргаар баригдсан компанитай боллоо гэж бодъё. Дэд бүтцийн хөгжлийн төлөвлөгөөг олон жилийн турш боловсруулдаг. Контейнер болон Кубер дээр дэд бүтэц барих эсэх шийдвэрийг хэрхэн гаргадаг вэ?
Нано секундын төлөө тэмцдэг компаниудыг хэлэлцүүлэгт оруулахгүй. Эрүүл консерватизм нь найдвартай байдлын хувьд үр өгөөжөө өгдөг боловч шинэ арга барилыг авч үзэх ёстой компаниуд байсаар байна.
Иван: "Би одоо үүлэн дээр компани байгуулах нь гарцаагүй, учир нь энэ нь илүү хурдан учраас" гэхдээ хямд байх албагүй. Венчур капитализм хөгжихийн хэрээр стартапууд мөнгөтэй холбоотой том асуудалгүй бөгөөд зах зээлийг эзлэх нь гол ажил юм.
Иван ийм бодолтой байна одоогийн дэд бүтцийг хөгжүүлэх нь сонгон шалгаруулах шалгуур юм. Хэрэв өнгөрсөн хугацаанд ноцтой хөрөнгө оруулалт хийгдсэн бол үр дүнд хүрсэн бол дахин хийх нь утгагүй юм. Хэрэв дэд бүтэц хөгжөөгүй, багаж хэрэгсэл, хамгаалалт, хяналт зэрэг асуудал байгаа бол хуваарилагдсан дэд бүтцийг харах нь зүйтэй юм.
Татварыг ямар ч тохиолдолд төлөх ёстой бөгөөд Иван ирээдүйд бага төлөх боломжийг олгосон татварыг төлөх болно. "Учир нь би зүгээр л бусдын хөдөлгөж байгаа галт тэргэнд сууж байгаа учраас би өөр галт тэргэнд сууснаас хамаагүй хол явах болно."гэж Иван хэлэв. Компани шинээр байгуулагдаж, хоцролтод тавигдах шаардлага нь хэдэн арван миллисекунд байх үед Иван өнөөдөр сонгодог мэдээллийн сангууд "боодсон" "операторууд" руу хандах болно. Тэд бүтэлгүйтэх гэх мэт тохиолдолд өөрөө шилждэг хуулбарлах гинжийг босгодог ...
Хоёр сервертэй жижиг компанийн хувьд Кубера ямар ч утгагүй юм" гэж Андрей хэлэв. Гэхдээ хэрэв энэ нь хэдэн зуун буюу түүнээс дээш сервертэй болох төлөвлөгөөтэй байгаа бол автоматжуулалт, нөөцийн удирдлагын систем хэрэгтэй. Тохиолдлын 90% нь үнэ цэнэтэй байдаг. Түүнээс гадна ачаалал, нөөцийн түвшингээс үл хамааран. Гарааны бизнесээс эхлээд сая сая үзэгчтэй томоохон компаниуд хүртэл чингэлэг зохион бүтээх бүтээгдэхүүн рүү аажмаар хандах нь утга учиртай юм. "Тийм ээ, энэ бол үнэхээр ирээдүй" гэж Андрей итгэлтэй байна.
Денис хоёр үндсэн шалгуурыг тодорхойлсон. үйл ажиллагааны цар хүрээ, тогтвортой байдал. Тэр даалгаварт хамгийн тохиромжтой хэрэгслийг сонгох болно. “Энэ нь таны өвдөг дээрээ угсарсан noname байж болох бөгөөд дээр нь Nutanix Community Edition байгаа. Энэ нь хуулбарласан, RTO болон RPO параметрүүдийг тодорхойлсон мэдээллийн сан бүхий Kuber дээрх програмын хоёр дахь мөр байж болно" (нөхөн сэргээх хугацаа/цэг зорилтууд - ойролцоогоор.).
Евгений боловсон хүчинтэй холбоотой байж болзошгүй асуудлыг тодорхойлсон. Одоогийн байдлаар зах зээл дээр "гэдэс" -ийг ойлгодог өндөр мэргэшсэн мэргэжилтнүүд тийм ч олон байдаггүй. Үнэхээр ч сонгосон технологи нь хуучирсан бол амьдралаас залхсан дунд эргэм насны хүмүүсээс өөр хүнийг ажилд авахад хэцүү. Хэдийгээр бусад оролцогчид үүнийг боловсон хүчний сургалтын асуудал гэж үзэж байна.
Хэрэв бид Amazon RDS дахь мэдээллийн баазтай, эсвэл Кубернетес дэх мэдээллийн баазтай "Нийтийн Клоуд" дахь жижиг компанийг нээх гэсэн асуултыг тавьж байгаа бол зарим дутагдалтай талуудыг үл харгалзан Amazon RDS нь оролцогчдын сонголт болсон.
Уулзалтын сонсогчдын дийлэнх нь “цуст” аж ахуйн нэгжийнх биш тархсан шийдлүүд нь бидний хичээх ёстой зүйл юм. Мэдээлэл хадгалах систем нь тархсан, найдвартай байх ёстой бөгөөд миллисекунд, хамгийн ихдээ хэдэн арван нэгжээр хэмжигдэх хоцрогдол үүсгэх ёстой." гэж Андрей дүгнэв.
Kubernetes ашиглалтыг үнэлэх
Сонсогч Антон Жбанков Кубернетесийн уучлалт гуйгчдад урхи асуулт тавьжээ: Та ТЭЗҮ-ийг хэрхэн сонгож, хийсэн бэ? Яагаад Кубернетес, жишээ нь виртуал машинууд яагаад болохгүй гэж?
Фото зураг
Дмитрий, Иван нар хариулав. Аль ч тохиолдолд туршилт, алдааны үр дүнд дараалсан шийдвэрүүд гарсан бөгөөд үүний үр дүнд оролцогч хоёулаа Кубернетес хотод ирэв. Одоо бизнесүүд Кубер руу шилжүүлэхэд тохиромжтой програм хангамжийг бие даан боловсруулж эхэлж байна. Бид 1С гэх мэт гуравдагч этгээдийн сонгодог системүүдийн талаар яриагүй байна. Kubernetes нь хөгжүүлэгчид хурдан гаргах шаардлагатай үед зогсолтгүй тасралтгүй сайжруулахад тусалдаг.
Андрейгийн баг виртуал машин дээр суурилсан өргөтгөх боломжтой кластер үүсгэхийг оролдсон. Зангилаанууд даалуу шиг унасан бөгөөд энэ нь заримдаа кластер нурахад хүргэдэг. “Онолын хувьд та үүнийг дуусгаад гараараа дэмжиж болно, гэхдээ энэ нь уйтгартай. Хэрэв зах зээл дээр танд хайрцагнаас гарах боломжийг олгодог шийдэл байгаа бол бид үүнийг хийхдээ баяртай байх болно. Үүний үр дүнд бид сольсон" гэж Андрей хэлэв.
Ийм дүн шинжилгээ хийх, тооцоолох стандартууд байдаг боловч тэдгээр нь ажиллаж байгаа бодит техник хангамж дээр хэр үнэн зөв болохыг хэн ч хэлж чадахгүй. Тооцооллын хувьд хэрэгсэл, экосистем бүрийг ойлгох нь чухал боловч энэ нь боломжгүй юм.
Биднийг юу хүлээж байна
Фото зураг
Технологи хөгжихийн хэрээр олон янзын хэсгүүд гарч ирэн, дараа нь фазын шилжилт явагдаж, бүх зүйл нэг хэрэгсэлд нэгдэхийн тулд хангалттай зуурсан гурилыг устгасан худалдагч гарч ирнэ.
Линуксийн ертөнцөд Ubuntu шиг хэрэгсэл гарах цаг ирнэ гэж та бодож байна уу? Магадгүй нэг контейнержуулалт, зохион байгуулалтын хэрэгсэлд Kuber багтах болно. Энэ нь үүл үүсгэхэд хялбар болгоно.
Хариултыг Иван өгсөн: "Google одоо Anthos-ийг бүтээж байна. Энэ бол үүл байршуулах, Kuber, Service Mesh, мониторинг зэрэг газар дээрх микро үйлчилгээнд шаардлагатай бүх техник хангамжийг багтаасан тэдний багцалсан санал юм." Бид бараг л ирээдүйд байна."
Денис мөн vRealize Suite бүтээгдэхүүнтэй Nutanix болон VMWare-ийн талаар дурьдсан бөгөөд энэ нь савлахгүйгээр ижил төстэй ажлыг даван туулах чадвартай.
"Өвдөлтийг" багасгаж, татварыг бууруулах нь сайжирна гэж найдаж болох хоёр талбар гэж Дмитрий санал бодлоо хуваалцав.
Хэлэлцүүлгийг нэгтгэн дүгнэхийн тулд бид орчин үеийн дэд бүтцийн дараах асуудлуудыг онцолж байна.
- Гурван оролцогч нэн даруй төлөвтэй холбоотой асуудлыг олж мэдэв.
- Докер нь Python-ийн олон хувилбар, програмын серверүүд болон бүрэлдэхүүн хэсгүүдтэй болох зэрэг аюулгүй байдлын дэмжлэгийн янз бүрийн асуудлууд.
Хэт их зарлага, аль нь тусад нь хурлаар хэлэлцэх нь дээр.
Оркестрийн хувьд суралцах сорилт бол нарийн төвөгтэй экосистем юм.
Салбарын нийтлэг асуудал бол багаж хэрэгслийг буруу ашиглах явдал юм.Үлдсэн дүгнэлт нь танаас хамаарна. Docker+Kubernetes хослол нь системийн "төв" хэсэг болоход тийм ч амар биш гэсэн мэдрэмж байсаар байна. Жишээлбэл, үйлдлийн системүүдийг эхлээд техник хангамжид суулгадаг бөгөөд үүнийг контейнер, зохион байгуулалтын талаар хэлэх боломжгүй юм. Магадгүй ирээдүйд үйлдлийн системүүд болон контейнерууд үүлэн удирдлагын программ хангамжтай нэгдэх болов уу.
Фото зурагЭнэ завшааныг ашиглан ээжтэйгээ мэндчилж, фэйсбүүк групптэй гэдгийг сануулмаар байна , суваг янз бүрийн технологийн блогуудын сонирхолтой нийтлэлүүдтэй. Мөн миний суваг , энд би бүтээгдэхүүний компаниудын хөгжлийг удирдах талаар ярьдаг.
Эх сурвалж: www.habr.com