Өнөөдөр би хэрхэн програм бичих, Kubernetes дээр сайн ажиллахын тулд таны програмд тавигдах шаардлагуудын талаар ярихаар төлөвлөж байна. Аппликейшн дээр толгой өвдөхгүй байхын тулд та түүний эргэн тойронд ямар нэгэн "цэвэр" зохион бүтээх шаардлагагүй бөгөөд бүх зүйл Кубернетесийн хүссэнээр ажилладаг.
Энэ лекц нь "" Оройн сургуулийн онолын нээлттэй лекцүүдийг үзэх боломжтой . Видео бичлэгээс илүү текстийг илүүд үздэг хүмүүст зориулж бид энэ нийтлэлийг бэлтгэсэн.
Намайг Павел Селиванов гэдэг, одоогоор би Mail.ru Cloud Solutions-ийн тэргүүлэх DevOps инженер, бид үүл хийдэг, менежментийн кубернетүүд гэх мэт. Одоо миний даалгавар бол хөгжүүлэлтэд туслах, эдгээр үүлсийг түгээх, бидний бичсэн програмуудыг түгээх, хэрэглэгчдэдээ өгөх хэрэгслүүдийг шууд хөгжүүлэх явдал юм.
Би DevOps хийж байгаа, сүүлийн, магадгүй гурван жил гэж бодож байна. Гэхдээ зарчмын хувьд би DevOps-ийн хийдэг зүйлийг таван жил орчим хийж байна. Үүнээс өмнө би ихэвчлэн админы ажилд оролцдог байсан. Би Кубернетестэй нэлээд эртнээс хамтран ажиллаж эхэлсэн - магадгүй түүнтэй ажиллаж эхэлснээс хойш дөрвөн жил өнгөрсөн байх.
Ерөнхийдөө би Kubernetes-ийн 1.3 хувилбар, магадгүй 1.2-той байх үед эхэлсэн. Одоо энэ нь анхан шатандаа байхаа больсон бөгөөд Кубернетес хийх боломжтой инженерүүдийн зах зээлд асар их эрэлт хэрэгцээ байгаа нь тодорхой байна. Мөн компаниуд ийм хүмүүст маш их эрэлт хэрэгцээтэй байдаг. Тиймээс, үнэндээ энэ лекц гарч ирэв.
Хэрэв бид миний ярих зүйлийн төлөвлөгөөний дагуу ярих юм бол энэ нь иймэрхүү харагдах бөгөөд хаалтанд (TL;DR) - "хэтэрхий урт; битгий унш". Миний өнөөдрийн танилцуулга эцэс төгсгөлгүй жагсаалтаас бүрдэх болно.
Үнэндээ би өөрөө ийм илтгэл тавихад дургүй байдаг, гэхдээ энэ бол ийм сэдэв тул би энэ илтгэлийг бэлдэж байхдаа энэ мэдээллийг хэрхэн өөрөөр зохион байгуулахаа сайн бодож чадаагүй юм.
Учир нь ерөнхийдөө энэ мэдээлэл нь "ctrl+c, ctrl+v" бөгөөд бусад зүйлсийн дотор манай Wiki-ийн DevOps хэсэгт байгаа бөгөөд бид хөгжүүлэгчдэд тавигдах шаардлагуудыг бичсэн байдаг: "Залуусаа, ингэснээр бид таны програмыг дараах байдлаар ажиллуулна. Кубернетес, ийм байх ёстой."
Тийм ч учраас танилцуулга ийм том жагсаалт болж хувирсан. Уучлаарай. Боломжтой бол уйдахгүйн тулд аль болох ихийг хэлэхийг хичээх болно.
Бид одоо юу үзэх гэж байна:
- Эдгээр нь нэгдүгээрт, лог (програмын бүртгэл?), Кубернетес дээр тэдэнтэй юу хийх, тэдэнтэй юу хийх, юу байх ёстой;
- Kubernetes дахь тохиргоог юу хийх вэ, Kubernetes-д зориулсан програмыг тохируулах хамгийн сайн, хамгийн муу аргууд юу вэ;
- Ер нь хүртээмжийн шалгалт гэж юу болох, тэдгээр нь ямар байх ёстой талаар ярилцъя;
- сайхан унтрах гэж юу болох талаар ярилцъя;
- нөөцийн талаар дахин ярилцъя;
- Өгөгдөл хадгалах сэдвийг дахин нэг удаа хөндье;
- Эцэст нь би энэ нууцлаг үүлэн программ гэж юу болохыг танд хэлэх болно. Cloudnativeness нь энэ нэр томъёоны нэр томъёо юм.
Бүртгэл
Би гуалинуудаас эхлэхийг санал болгож байна - эдгээр гуалиныг Kubernetes-д хаана оруулах шаардлагатай вэ? Одоо та Kubernetes-д програм ажиллууллаа. Сонгодог хүмүүсийн хэлснээр өмнө нь програмууд файлын хаа нэгтээ лог бичдэг байсан. Муу программууд програмыг эхлүүлсэн хөгжүүлэгчийн гэрийн лавлах файлд лог бичсэн. Сайн програмууд хаа нэгтээ байгаа файл руу лог бичдэг /var/log.
Үүний дагуу сайн администраторууд дэд бүтцүүддээ эдгээр логуудыг эргүүлэх боломжтой зарим зүйлийг тохируулсан байдаг - ижил rsyslog нь эдгээр бүртгэлийг хардаг бөгөөд тэдэнд ямар нэг зүйл тохиолдоход тэдгээр нь маш олон байдаг, нөөц хуулбарыг үүсгэдэг, тэнд лог тавьдаг. , хуучин файлуудыг устгадаг, долоо хоногоос дээш, зургаан сар ба түүнээс дээш. Онолын хувьд, програм нь лог бичдэг учраас л үйлдвэрлэлийн серверүүд (байлдааны серверүүд?) зай дуусахгүй байх заалттай байх ёстой. Үүний дагуу логны улмаас үйлдвэрлэл бүхэлдээ зогссонгүй.
Бид Кубернетесийн ертөнц рүү нүүж, тэнд ижил зүйлийг ажиллуулах үед таны анхаарах хамгийн эхний зүйл бол хүмүүс файлд лог бичиж байхдаа үргэлжлүүлэн бичих явдал юм.
Хэрэв бид Kubernetes-ийн тухай ярих юм бол докерын контейнерээс хаа нэгтээ бүртгэл бичих хамгийн зөв газар бол тэдгээрийг програмаас Stdout/Stderr гэж нэрлэгддэг үйлдлийн системийн стандарт гаралтын урсгал руу бичих явдал юм. стандарт алдааны гаралт. Энэ бол Docker болон ялангуяа Kubernetis-д логуудыг зарчмын хувьд оруулах хамгийн зөв, хамгийн энгийн бөгөөд логик арга юм. Учир нь хэрэв таны аппликейшн Stdout/Stderr руу лог бичдэг бол Docker болон Kubernetes нэмэлт нь эдгээр бүртгэлтэй юу хийхээ шийдэх болно. Docker нь анхдагчаар JSON форматаар тусгай файлуудаа бүтээх болно.
Эндээс асуулт гарч ирнэ, та эдгээр логуудыг дараа нь юу хийх вэ? Хамгийн хялбар арга нь ойлгомжтой, бидэнд хийх чадвар бий kubectl logs мөн эдгээр "хөрсөг" -ийн бүртгэлийг хараарай. Гэхдээ энэ нь тийм ч сайн сонголт биш байх магадлалтай - логуудтай өөр зүйл хийх хэрэгтэй.
Одоохондоо логны сэдвийг хөндсөн болохоор логууд ямар байх ёстой талаар нэгэн зэрэг ярилцъя. Өөрөөр хэлбэл, энэ нь Кубернетесэд шууд хамаарахгүй, гэхдээ бид логуудтай юу хийх талаар бодож эхлэх үед энэ талаар бас бодох нь зүйтэй болов уу.
Манай докерын файлууддаа оруулсан эдгээр бүртгэлийг авч хаа нэгтээ илгээх эв найрамдлын арга хэрэгсэл бидэнд хэрэгтэй байна. Ерөнхийдөө бид Кубернетес дотор DaemonSet хэлбэрээр ямар нэгэн төрлийн агентийг ажиллуулдаг - лог цуглуулагч бөгөөд үүнийг Docker цуглуулдаг логууд хаана байрладаг болохыг зүгээр л хэлдэг. Энэхүү цуглуулагч нь тэднийг зүгээр л авч, магадгүй ямар нэгэн байдлаар тэдгээрийг задлан шинжилж, нэмэлт мета мэдээллээр баяжуулж, эцэст нь хаа нэгтээ хадгалахаар илгээдэг. Тэнд өөрчлөлтүүд аль хэдийн боломжтой болсон. Хамгийн түгээмэл нь Elasticsearch байж магадгүй бөгөөд та логуудыг хадгалах боломжтой бөгөөд тэдгээрийг тэндээс хялбархан татаж авах боломжтой. Дараа нь хүсэлтийг ашиглан, Кибана ашиглан, жишээ нь, тэдгээрт үндэслэн график байгуулах, тэдгээрт тулгуурлан анхааруулга үүсгэх гэх мэт.
Хамгийн чухал санаа бол би үүнийг дахин давтахыг хүсч байна, Докер дотор, ялангуяа Кубернетес дотор бүртгэлээ файлд хадгалах нь маш муу санаа юм.
Учир нь нэгдүгээрт, контейнер доторх логуудыг файлд оруулахад хэцүү байдаг. Та эхлээд чингэлэгт орж, тэндээ exec хийж, дараа нь логуудыг харах хэрэгтэй. Дараагийн зүйл бол хэрэв та файлд бүртгэлтэй бол контейнерууд нь ихэвчлэн минималист орчинтой байдаг бөгөөд логтой хэвийн ажиллахад ихэвчлэн шаардлагатай хэрэгслүүд байдаггүй. Тэднийг булж, харж, текст засварлагчаар нээ. Дараагийн мөч бол бид чингэлэг доторх файлд бүртгэлтэй байх үед, хэрэв энэ контейнер устгагдвал логууд үүнтэй хамт үхэх болно гэдгийг та ойлгож байна. Үүний дагуу савыг дахин эхлүүлэх нь лог байхгүй болно гэсэн үг юм. Дахин хэлэхэд муу сонголт.
Хамгийн сүүлчийн зүйл бол савнуудад ихэвчлэн таны програм байдаг бөгөөд энэ нь ихэвчлэн ажилладаг цорын ганц процесс юм. Таны бүртгэлтэй файлуудыг эргүүлэх үйл явцын талаар огт яриагүй байна. Бүртгэлийг файл руу бичиж эхэлмэгц энэ нь уучлаарай, бид үйлдвэрлэлийн серверээ алдаж эхэлнэ гэсэн үг юм. Учир нь нэгдүгээрт, тэдгээрийг олоход хэцүү, хэн ч тэднийг дагаж мөрддөггүй, хэн ч тэднийг хянадаггүй - үүний дагуу сервер дээрх зай дуусах хүртэл файл эцэс төгсгөлгүй ургадаг. Тиймээс би Docker, ялангуяа Kubernetes-д файл руу нэвтрэх нь муу санаа гэдгийг би дахин хэлье.
Дараагийн зүйл бол би энэ талаар дахин ярихыг хүсч байна - бид бүртгэлийн сэдвийг хөндөж байгаа тул тэдэнтэй ажиллахад тохиромжтой байхын тулд логууд хэрхэн харагдах талаар ярих нь зүйтэй болов уу. Миний хэлсэнчлэн энэ сэдэв нь Kubernetes-тэй шууд холбоогүй ч DevOps-ийн сэдэвтэй маш сайн холбоотой. Хүн бүр ая тухтай байхын тулд эдгээр хоёр өөр хэлтэс болох Dev ба Ops хоорондын хөгжлийн соёл, нөхөрлөлийн сэдвээр.
Энэ нь өнөөдөр хамгийн тохиромжтой логуудыг JSON форматаар бичих ёстой гэсэн үг юм. Хэрэв танд ямар нэгэн хэвлэлт эсвэл үүнтэй төстэй зүйл оруулсны улмаас логуудыг ойлгомжгүй форматаар бичдэг өөрийн гэсэн ойлгомжгүй програм байгаа бол ердийн бүртгэлийг хэрэгжүүлэх боломжийг олгодог ямар нэгэн төрлийн хүрээ, ямар нэг төрлийн боодолтой google-ээс хайх цаг болжээ; JSON-д бүртгэлийн параметрүүдийг идэвхжүүлээрэй, учир нь JSON нь энгийн формат тул задлан шинжлэхэд хялбар байдаг.
Хэрэв таны JSON зарим шалгуурын дагуу ажиллахгүй бол хэн ч юу болохыг мэдэхгүй бол ядаж задлан шинжилж болох форматаар лог бичээрэй. Жишээлбэл, хэрэв та олон тооны контейнер ажиллуулж байгаа эсвэл зүгээр л nginx-ээр боловсруулдаг бол тус бүр өөрийн бүртгэлийн тохиргоотой бол энэ нь танд тохиромжгүй байх болно гэдгийг бодох нь зүйтэй болов уу. тэдгээрийг задлан шинжлэх. Учир нь nginx-ийн шинэ жишээ болгонд та өөрийн задлан шинжлэгчийг бичих хэрэгтэй, учир нь тэд логуудыг өөр өөрөөр бичдэг. Дахин хэлэхэд, эдгээр бүх nginx тохиолдлууд ижил бүртгэлийн тохиргоотой бөгөөд бүх бүртгэлээ бүрэн жигд бичсэн эсэхийг бодох нь зүйтэй болов уу. Энэ нь бүх програмуудад мөн адил хамаарна.
Эцэст нь би гал дээр түлш нэмэхийг хүсч байна, хамгийн тохиромжтой нь олон мөр форматтай бүртгэлээс зайлсхийх хэрэгтэй. Энд нэг зүйл бол, хэрэв та хэзээ нэгэн цагт дүнз цуглуулагчидтай ажиллаж байсан бол тэд танд юу амлаж байгааг, олон мөрт логуудтай ажиллах чадвартай, тэдгээрийг хэрхэн цуглуулахаа мэддэг гэх мэт зүйлийг харсан байх. Үнэндээ миний бодлоор өнөөдөр нэг ч цуглуулагч олон мөрийн бүртгэлийг хэвийн, бүрэн, алдаагүй цуглуулж чадахгүй. Хүний маягаар, ингэснээр эвтэйхэн, алдаагүй.
Гэхдээ стекийн ул мөр нь үргэлж олон мөрт бүртгэлүүд бөгөөд тэдгээрээс хэрхэн зайлсхийх вэ. Энд асуулт бол лог нь үйл явдлын бичлэг бөгөөд stactrace нь үнэндээ бүртгэл биш юм. Хэрэв бид бүртгэлийг цуглуулж, Elasticsearch-ийн хаа нэгтээ байрлуулж, тэдгээрийн графикийг зурж, өөрийн сайт дээр хэрэглэгчийн үйл ажиллагааны зарим тайланг бүтээх юм бол та стекийн ул мөрийг авах үед энэ нь гэнэтийн зүйл болж байна гэсэн үг юм. Таны аппликешнд зохицуулагдаагүй нөхцөл байдал. Мөн тэдгээрийг хянах боломжтой системд хаа нэгтээ стекийн ул мөрийг автоматаар байршуулах нь утга учиртай юм.
Энэ бол стекийн мөртэй ажиллахад зориулагдсан программ хангамж (ижил Sentry) юм. Энэ нь автоматжуулсан ажлуудыг нэн даруй үүсгэж, хэн нэгэнд оноож, sacttraces тохиолдоход сэрэмжлүүлж, эдгээр sacttraces-ийг нэг төрлөөр бүлэглэх гэх мэт. Зарчмын хувьд, логны тухай ярихдаа стактрасуудын тухай ярих нь утгагүй юм, учир нь эдгээр нь өөр өөр зорилготой өөр өөр зүйлүүд юм.
Тохиргоо
Дараа нь бид Kubernetes дахь тохиргооны талаар ярих болно: үүнтэй юу хийх, Kubernetes доторх програмуудыг хэрхэн тохируулах талаар. Ерөнхийдөө би Docker бол контейнерийн тухай биш гэж хэлдэг. Докер бол чингэлэгтэй холбоотой гэдгийг хүн бүр мэддэг, тэр ч байтугай Docker-тэй нэг их ажиллаж байгаагүй хүмүүс ч гэсэн. Би давтан хэлье, Docker бол контейнерийн тухай биш юм.
Докер миний бодлоор стандартын тухай юм. Бараг бүх зүйлд стандарт байдаг: програмаа бүтээх стандартууд, програмаа суулгах стандартууд.
Мөн энэ зүйл - бид үүнийг өмнө нь ашиглаж байсан, энэ нь зүгээр л контейнер гарч ирснээр алдартай болсон - энэ зүйлийг ENV (орчны) хувьсагч, өөрөөр хэлбэл таны үйлдлийн системд байгаа орчны хувьсагч гэж нэрлэдэг. Энэ нь ерөнхийдөө таны программыг тохируулах хамгийн тохиромжтой арга юм, учир нь хэрэв танд JAVA, Python, Go, Perl, бурхан хориглосон програмууд байгаа бөгөөд тэдгээр нь бүгд өгөгдлийн сангийн хост, өгөгдлийн сангийн хэрэглэгч, мэдээллийн сангийн нууц үгийн хувьсагчдыг уншиж чаддаг бол энэ нь хамгийн тохиромжтой. Танд өгөгдлийн сангийн төлөвлөгөөнд ижил аргаар тохируулсан дөрвөн өөр хэл дээрх програмууд байна. Өөр өөр тохиргоо байхгүй.
Бүх зүйлийг ENV хувьсагч ашиглан тохируулж болно. Бид Kubernetes-ийн тухай ярихдаа Deployment дотор ENV хувьсагчдыг зарлах гайхалтай арга бий. Үүний дагуу, хэрэв бид нууц өгөгдлийн тухай ярьж байгаа бол бид ENV хувьсагчдаас (өгөгдлийн сангийн нууц үг гэх мэт) нууц өгөгдлийг нэн даруй нууц руу түлхэж, нууц кластер үүсгэж, Deployment дахь ENV тайлбарт бид шууд зарлаагүй гэдгээ зааж өгч болно. энэ хувьсагчийн утга, мөн энэ мэдээллийн сангийн нууц үгийн хувьсагчийн утгыг нууцаас унших болно. Энэ бол Кубернетын стандарт зан төлөв юм. Мөн энэ нь таны програмуудыг тохируулах хамгийн тохиромжтой сонголт юм. Зөвхөн кодын түвшинд, энэ нь хөгжүүлэгчдэд дахин хамаарна. Хэрэв та DevOps бол "Залуус аа, программдаа орчны хувьсагчдыг уншихыг заана уу. Тэгээд бид бүгд аз жаргалтай байх болно."
Хэрэв компанийн бүх хүмүүс ижил нэрлэгдсэн орчны хувьсагчдыг уншдаг бол энэ нь маш сайн хэрэг. Зарим нь postgres мэдээллийн баазыг хүлээж, зарим нь мэдээллийн сангийн нэрийг хүлээж, зарим нь өөр зүйл, бусад нь ямар нэгэн төрлийн dbn хүлээж байгаа тул нэгдмэл байдал бий болно.
Асуудал нь танд маш олон орчны хувьсагчтай тул зүгээр л Deployment-ийг нээхэд гарч ирдэг - таван зуун мөр орчны хувьсагч байдаг. Энэ тохиолдолд та хүрээлэн буй орчны хувьсагчдаас ердөө л давж гарсан тул өөрийгөө тамлах шаардлагагүй болно. Энэ тохиолдолд тохиргоог ашиглаж эхлэх нь зүйтэй болов уу. Өөрөөр хэлбэл, програмаа тохиргоог ашиглахад сурга.
Ганц асуулт бол тохиргоо нь таны бодож байгаа шиг биш юм. Config.pi нь ашиглахад тохиромжтой тохиргоо биш юм. Эсвэл өөрийн гэсэн форматтай зарим тохиргоо, өөр авьяастай - энэ нь бас миний хэлэх гэсэн тохиргоо биш юм.
Миний хэлж байгаа зүйл бол хүлээн зөвшөөрөгдсөн форматын тохиргоо, өөрөөр хэлбэл хамгийн алдартай стандарт бол .yaml стандарт юм. Яаж унших нь ойлгомжтой, хүн унших боломжтой, яаж унших нь программаас ойлгомжтой.
Үүний дагуу YAML-ээс гадна та жишээ нь JSON-г ашиглаж болно, задлан шинжлэх нь тэндээс програмын тохиргоог уншихад YAML-тэй адил тохиромжтой юм. Энэ нь хүмүүст уншихад илүү эвгүй байдаг. Та форматыг оролдож болно, a la ini. Энэ нь хүний үүднээс уншихад маш тохиромжтой боловч автоматаар боловсруулахад тохиромжгүй байж магадгүй, учир нь та хэзээ нэгэн цагт өөрийн тохиргоог үүсгэхийг хүсвэл ini форматыг үүсгэхэд тохиромжгүй байж магадгүй юм.
Гэхдээ ямар ч тохиолдолд та ямар ч форматыг сонгохоос үл хамааран Кубернетесийн үүднээс авч үзвэл энэ нь маш тохиромжтой юм. Та бүх тохиргоогоо ConfigMap доторх Kubernetes дотор байрлуулж болно. Дараа нь энэ тохиргооны зураглалыг аваад, үүнийг ямар нэгэн тодорхой лавлах дотор өөрийн подколь дотор суулгаж өгөхийг хүс, тэнд таны аппликейшн энэ тохиргооны зургийн тохиргоог зүгээр л файл мэт унших болно. Энэ нь үнэндээ таны аппликешн дээр олон тохиргооны сонголттой үед хийх нь зүйтэй юм. Эсвэл энэ нь зүгээр л нэг төрлийн нарийн төвөгтэй бүтэц юм, үүрлэдэг.
Хэрэв танд тохиргооны зураг байгаа бол, жишээлбэл, тохиргооны зураг суурилуулсан файлын өөрчлөлтийг автоматаар хянах, мөн тохиргоо өөрчлөгдөх үед програмаа автоматаар дахин ачаалахыг маш сайн зааж өгч болно. Энэ нь ерөнхийдөө хамгийн тохиромжтой сонголт байх болно.
Дахин хэлэхэд би энэ тухай аль хэдийн ярьсан - нууц мэдээлэл нь тохиргоонд байдаггүй, нууц мэдээлэл нь хувьсагчид биш, нууц мэдээлэл нь нууцад байдаггүй. Тэндээс энэ нууц мэдээллийг дипломат харилцаатай холбоно. Бид ихэвчлэн Kubernetes объект, байршуулалт, тохиргооны зураглал, үйлчилгээний талаархи бүх тайлбарыг git дээр хадгалдаг. Үүний дагуу git-д өгөгдлийн санд нууц үг оруулах нь таны компанид байдаг git байсан ч гэсэн буруу санаа юм. Учир нь git хамгийн багаар бодоход бүх зүйлийг санаж, нууц үгээ устгах нь тийм ч хялбар биш юм.
Эрүүл мэндийн үзлэг
Дараагийн зүйл бол Эрүүл мэндийн үзлэг гэж нэрлэгддэг зүйл юм. Ерөнхийдөө эрүүл мэндийн үзлэг нь таны програм ажиллаж байгаа эсэхийг шалгах явдал юм. Үүний зэрэгцээ, бид ихэнхдээ зарим вэб програмуудын талаар ярьдаг бөгөөд үүний дагуу эрүүл мэндийн үзлэгийн үүднээс (энд болон цааш орчуулахгүй байх нь дээр) энэ нь зарим тусгай URL байх болно. стандарт, тэд ихэвчлэн хийдэг /health.
Энэ URL руу нэвтрэх үед манай програм "тийм ээ, за, надад бүх зүйл сайн байна, 200" эсвэл "үгүй, надад бүх зүйл зүгээр биш, 500" гэж хэлдэг. Үүний дагуу, хэрэв манай програм http биш, вэб програм биш бол бид одоо ямар нэгэн демоны тухай ярьж байна, бид эрүүл мэндийн үзлэгийг хэрхэн хийх талаар олж мэдэх боломжтой. Энэ нь шаардлагагүй, хэрэв програм нь http биш бол бүх зүйл эрүүл мэндийн үзлэггүйгээр ажилладаг бөгөөд үүнийг ямар ч байдлаар хийх боломжгүй юм. Та файлын зарим мэдээллийг үе үе шинэчилж болно, та демондоо зориулж тусгай тушаал гаргаж болно, жишээ нь: daemon status"Тийм ээ, бүх зүйл зүгээр, демон ажиллаж байна, амьд байна" гэж хэлэх болно.
Энэ юунд зориулагдсан бэ? Эхний бөгөөд хамгийн тодорхой зүйл бол эрүүл мэндийн үзлэг яагаад хэрэгтэй вэ гэдэг нь програм ажиллаж байгааг ойлгох явдал юм. Энэ нь зүгээр л тэнэг юм гэж хэлэх гэсэн юм, энэ нь одоо ажиллаж байгаа үед энэ нь ажиллаж байгаа юм шиг харагддаг, тиймээс энэ нь ажиллаж байгаа гэдэгт итгэлтэй байж болно. Аппликешн ажиллаж байна, контейнер ажиллаж байна, жишээ ажиллаж байна, бүх зүйл хэвийн байна - тэгээд хэрэглэгчид техникийн дэмжлэгээс бүх утасны дугаарыг аль хэдийн таслаад "чи юу вэ ..., чи" гэж хэлдэг. Унтсан, юу ч ажиллахгүй байна."
Эрүүл мэндийн үзлэг нь хэрэглэгчийн байр сууринаас үр дүнтэй болохыг харах нэг арга юм. Аргын нэг. Ингэж хэлье. Kubernetes-ийн үүднээс авч үзвэл, энэ нь програм хэзээ эхлэхийг ойлгох арга юм, учир нь бид контейнерыг эхлүүлсэн, үүсгэсэн, эхлүүлсэн болон програмыг энэ саванд шууд эхлүүлсэн үед ялгаа байгааг бид ойлгож байна. Учир нь бид ямар нэгэн дундаж java програмыг авч, док дээр ажиллуулахыг оролдвол дөчин секунд, бүр нэг минут, бүр арван секундын турш энэ нь зүгээр л эхэлж болно. Энэ тохиолдолд та дор хаяж портуудыг нь тогшиж болно, тэр тэнд хариу өгөхгүй, өөрөөр хэлбэл урсгалыг хүлээн авахад бэлэн болоогүй байна.
Дахин хэлэхэд, эрүүл мэндийн үзлэгийн тусламжтайгаар, бид энд эргэлдэж байгаагийн тусламжтайгаар бид Кубернетес дээр зөвхөн чингэлэг нь өргөдлийн дотор босч зогсохгүй програм өөрөө эхэлсэн, энэ нь аль хэдийн хариу үйлдэл үзүүлж байгааг ойлгож чадна. эрүүл мэндийн үзлэг, энэ нь бид тэнд урсгалыг илгээх боломжтой гэсэн үг юм.
Миний одоо ярьж байгаа зүйлийг Кубернетес доторх бэлэн байдал/амьдралын тест гэж нэрлэдэг; үүний дагуу бидний бэлэн байдлын тест нь програмыг тэнцвэржүүлэхэд ашиглах боломжтой эсэхийг хариуцдаг. Өөрөөр хэлбэл, бэлэн байдлын шалгалтыг програм дээр хийсэн бол бүх зүйл хэвийн, үйлчлүүлэгчийн урсгал програм руу явж байна. Хэрэв бэлэн байдлын шалгалт хийгдээгүй бол програм нь ердөө л оролцохгүй, энэ жишээ нь тэнцвэржүүлэхэд оролцдоггүй, тэнцвэржүүлэхээс хасагдсан, үйлчлүүлэгчийн урсгал урсдаггүй. Үүний дагуу Кубернетес доторх Liveness тест хийх шаардлагатай бөгөөд хэрэв програм гацвал дахин эхлүүлэх боломжтой болно. Хэрэв Kubernetes-д зарласан програмын хувьд амьд байдлын тест ажиллахгүй бол програмыг тэнцвэржүүлэхээс хасаад зогсохгүй дахин эхлүүлнэ.
Энд нэг чухал зүйлийг дурдахыг хүсч байна: практикийн үүднээс авч үзвэл бэлэн байдлын тестийг ихэвчлэн амьд байдлын тестээс илүү олон удаа ашигладаг бөгөөд ихэвчлэн шаардлагатай байдаг. Өөрөөр хэлбэл, Кубернетес үүнийг хийж чадна, түүний хийж чадах бүх зүйлийг ашиглацгаая, учир нь бэлэн байдал, амьдрах чадварын тестийг зүгээр л бодолгүй зарлах нь тийм ч сайн санаа биш юм. Би яагаад гэдгийг тайлбарлая. Учир нь шинжилгээний хоёр дахь цэг бол эрүүл мэндийн үзлэгт хамрагдах үндсэн үйлчилгээг шалгах нь зүйтэй юм. Энэ нь хэрэв танд зарим мэдээллийг өгдөг вэб програм байгаа бол энэ нь мэдээжийн хэрэг хаа нэгтээгээс авах ёстой гэсэн үг юм. Жишээлбэл, мэдээллийн санд. За, энэ нь REST API-д орж ирсэн мэдээллийг ижил мэдээллийн санд хадгалдаг. Үүний дагуу, хэрэв таны эрүүл мэндийн үзлэг зүгээр л "slashhealth"-тэй холбоо барьсантай адил хариу өгөх юм бол програм "200, за, бүх зүйл зүгээр" гэж хэлэх ба тэр үед таны програмын мэдээллийн санд хандах боломжгүй, мөн эрүүл мэндийн үзлэг "200, за, бүх зүйл зүгээр" гэж бичнэ. ” - Энэ бол эрүүл мэндийн муу үзлэг юм. Энэ нь ингэж ажиллах ёсгүй.
Энэ нь таны өргөдөл, хүсэлт ирэхэд /health, энэ нь зүгээр л "200, за" гэж хариулах биш, эхлээд жишээлбэл, мэдээллийн сан руу орж, холбогдохыг оролдох, тэнд маш энгийн зүйл хийх, нэгийг нь сонгох гэх мэт, зүгээр л холболт байгаа эсэхийг шалгана. мэдээллийн баазаас асууж болно. Хэрэв энэ бүхэн амжилттай болсон бол "200, за" гэж хариулна. Хэрэв энэ нь амжилтгүй болвол алдаа байна, мэдээллийн сан боломжгүй байна гэж хэлдэг.
Тиймээс, үүнтэй холбогдуулан би бэлэн байдал/амьдралын тестүүд рүү дахин буцаж ирлээ - яагаад танд бэлэн байдлын шалгалт хэрэгтэй байх магадлалтай, гэхдээ амьд байдлын шалгалт нь эргэлзээтэй байна. Учир нь хэрэв та эрүүл мэндийн үзлэгийг яг миний хэлсэнчлэн тайлбарлавал энэ нь жишээ хэсэгт байхгүй болох нь тодорхой болно.в или со всех instanceжишээлбэл мэдээллийн санд. Таныг бэлэн байдлын шалгалт зарлахад бидний эрүүл мэндийн үзлэг амжилтгүй болж, үүний дагуу мэдээллийн санд хандах боломжгүй бүх программуудыг тэнцвэржүүлэхээс татгалзаж, зүгээр л үл тоомсорлож, мэдээллийн сан нь ажиллахыг хүлээж байна. ажил.
Хэрэв бид амьд байдлын тест зарласан бол манай мэдээллийн сан эвдэрч, таны Kubernetes-д амьд байдлын шалгалт амжилтгүй болсон тул бүх зүйлийн тал нь дахин эхэлж байна гэж төсөөлөөд үз дээ. Энэ нь та дахин эхлүүлэх хэрэгтэй гэсэн үг юм. Энэ бол таны хүссэн зүйл биш, би практик дээр хувийн туршлагатай байсан. Бидэнд JS дээр бичигдсэн, Mongo мэдээллийн санд оруулсан чат програм байсан. Асуудал нь Кубернетестэй хийсэн ажлынхаа эхэнд бид Кубернетес үүнийг хийж чадна гэсэн зарчмын дагуу туршилтын бэлэн байдал, амьд байдлыг тодорхойлсон тул бид үүнийг ашиглах болно. Үүний дагуу Монго бага зэрэг "уйтгартай" болж, дээж нь бүтэлгүйтэж эхлэв. Үүний дагуу борооны сорилын дагуу хонхорхойнууд "үхэж" эхлэв.
Таны ойлгож байгаагаар тэднийг "алах" үед энэ нь чат юм, өөрөөр хэлбэл үйлчлүүлэгчдээс маш олон холболтууд өлгөөтэй байдаг. Тэд бас "алагддаг" - үгүй, үйлчлүүлэгч биш, зөвхөн холболтууд - бүгд нэгэн зэрэг биш, мөн тэд нэгэн зэрэг амь үрэгдээгүй тул зарим нь эрт, зарим нь дараа нь нэг дор эхэлдэггүй. цаг. Дээрээс нь стандарт санамсаргүй байдлаар бид програмын эхлэх цагийг миллисекундын нарийвчлалтайгаар урьдчилан таамаглах боломжгүй тул тэд үүнийг нэг удаа хийдэг. Нэг мэдээллийн цэг босч, тэнцвэржүүлж, бүх үйлчлүүлэгчид ирдэг, ийм ачааллыг тэсвэрлэдэггүй, учир нь энэ нь ганцаараа, ойролцоогоор хэдэн арван хүн тэнд ажилладаг бөгөөд энэ нь унадаг. Дараагийнх нь босч, бүх ачаалал түүн дээр байна, тэр бас унана. За, эдгээр хүрхрээ үргэлжилсээр л. Эцсийн эцэст, үүнийг хэрхэн шийдсэн бэ - бид зүгээр л энэ аппликешн рүү чиглэсэн хэрэглэгчийн урсгалыг хатуу зогсоож, бүх тохиолдлуудыг өсгөж, дараа нь бүх хэрэглэгчийн траффикийг нэг дор эхлүүлэх хэрэгтэй болсон бөгөөд ингэснээр бүх арван тохиолдлуудад аль хэдийн хуваарилагдсан болно.
Хэрэв энэ туршилтыг зарлаагүй байсан бөгөөд энэ нь бүгдийг дахин эхлүүлэхэд хүргэдэг байсан бол програм үүнийг зүгээр л зохицуулах байсан. Гэхдээ бидний хувьд тэнцвэржүүлэхээс эхлээд бүх зүйл идэвхгүй болсон, учир нь мэдээллийн санд хандах боломжгүй, бүх хэрэглэгчид "унасан". Дараа нь энэ мэдээллийн сан бэлэн болсон үед бүх зүйл тэнцвэржүүлэхэд багтдаг боловч програмууд дахин эхлүүлэх шаардлагагүй бөгөөд үүнд цаг хугацаа, нөөц үрэх шаардлагагүй болно. Тэд бүгд аль хэдийн энд байна, тэд замын хөдөлгөөнд бэлэн байгаа тул замын хөдөлгөөн дөнгөж нээгдэж, бүх зүйл хэвийн байна - програм бэлэн болсон, бүх зүйл үргэлжлүүлэн ажиллаж байна.
Тиймээс бэлэн байдал, амьдрах чадварын тест нь өөр өөр байдаг, тэр ч байтугай та онолын хувьд өөр өөр эрүүл мэндийн үзлэг, нэг төрлийн радиус, нэг төрлийн liv гэх мэт янз бүрийн зүйлийг шалгаж болно. Бэлэн байдлын шалгалтын үеэр арын хэсгүүдээ шалгана уу. Мөн амьд байдлын тест дээр, жишээлбэл, амьд байдлын тест нь ерөнхийдөө зүгээр л хариу өгөх боломжтой програм юм уу гэдгийг шалгадаггүй.
Учир нь амьд байдлын шалгуур нь ерөнхийдөө бидний "гацах" үе юм. Төгсгөлгүй давталт эсвэл өөр ямар нэг зүйл эхэлсэн бөгөөд дахин хүсэлт боловсруулагдахгүй. Тиймээс тэдгээрийг салгаж, өөр логикийг хэрэгжүүлэх нь утга учиртай юм.
Шинжилгээ өгөх, эрүүл мэндийн үзлэг хийхдээ юу хариулах ёстой талаар. Энэ бол үнэхээр өвдөлт юм. Үүнийг мэддэг хүмүүс инээх байх, гэхдээ би амьдралдаа 200% тохиолдолд "XNUMX" гэж хариулдаг үйлчилгээг харсан. Энэ нь хэн амжилтанд хүрсэн гэсэн үг юм. Гэхдээ тэр үед хариултын хэсэгт тэд "ийм ийм алдаа" гэж бичдэг.
Өөрөөр хэлбэл, хариултын статус танд ирдэг - бүх зүйл амжилттай болсон. Гэхдээ тэр үед та биеийг задлан шинжлэх хэрэгтэй, учир нь бие нь "уучлаарай, хүсэлт алдаагаар дууссан" гэж хэлдэг бөгөөд энэ нь бодит байдал юм. Би үүнийг бодит амьдрал дээр харсан.
Зарим хүмүүс үүнийг инээдтэй гэж үздэггүй, зарим нь маш их өвддөг гэж үздэг тул энгийн дүрмийг баримтлах нь зүйтэй юм. Эрүүл мэндийн үзлэг, зарчмын хувьд вэб програмуудтай ажиллахдаа.
Хэрэв бүх зүйл сайн болсон бол хоёр зуу дахь хариултаар хариулна уу. Зарчмын хувьд аль ч хоёр зуун хариулт танд тохирох болно. Хэрэв та ragsy-г маш сайн уншсан бөгөөд зарим хариултын статус бусдаас ялгаатай гэдгийг мэдэж байвал тохирох хувилбараар хариулна уу: 204, 5, 10, 15, юу ч байсан. Хэрэв энэ нь тийм ч сайн биш бол "хоёр тэг тэг" л болно. Хэрэв бүх зүйл муу болж, эрүүл мэндийн үзлэгт хариу өгөхгүй бол таван зуугаар хариул. Дахин хэлэхэд, хэрвээ та хэрхэн хариулахаа ойлгож байгаа бол өөр өөр хариултын статусууд бие биенээсээ хэрхэн ялгаатай болохыг ойлгодог. Хэрэв та ойлгохгүй байгаа бол 502 нь ямар нэг зүйл буруу болвол эрүүл мэндийн үзлэгт хариу өгөх сонголт юм.
Энэ бол өөр нэг зүйл, би үндсэн үйлчилгээг шалгах талаар бага зэрэг буцахыг хүсч байна. Жишээлбэл, хэрэв та програмынхаа ард байгаа бүх үндсэн үйлчилгээг шалгаж эхэлбэл - ерөнхийдөө бүх зүйл. Микро үйлчилгээний архитектурын үүднээс бид "бага холболт" гэсэн ойлголттой байдаг, өөрөөр хэлбэл таны үйлчилгээ бие биенээсээ хамгийн бага хамааралтай байх үед. Хэрэв тэдгээрийн аль нэг нь бүтэлгүйтсэн бол энэ функцгүй бусад нь зүгээр л үргэлжлүүлэн ажиллах болно. Зарим функцууд зүгээр л ажиллахгүй байна. Үүний дагуу, хэрэв та бүх эрүүл мэндийн үзлэгийг бие биентэйгээ уялдуулах юм бол дэд бүтцэд нэг зүйл унах болно, энэ нь унасан тул бүх үйлчилгээний эрүүл мэндийн үзлэг бас бүтэлгүйтэж эхэлдэг - ерөнхийдөө эрүүл мэндийн дэд бүтэц илүү их байдаг. бүхэл бүтэн микро үйлчилгээний архитектур №. Тэнд бүх зүйл харанхуй болсон.
Иймд та үндсэн үйлчилгээгээ шалгах хэрэгтэй гэдгийг дахин дахин хэлмээр байна, үүнгүйгээр таны өргөдөл зуу зуун хувь нь ажлаа хийж чадахгүй. Өөрөөр хэлбэл, хэрэв танд REST API байгаа бол хэрэглэгч мэдээллийн санд хадгалдаг эсвэл мэдээллийн баазаас татаж авдаг бол мэдээллийн сан байхгүй тохиолдолд та хэрэглэгчидтэйгээ ажиллах баталгаа өгөхгүй байх нь логик юм.
Гэхдээ хэрэв таны хэрэглэгчдийг мэдээллийн баазаас гаргахдаа урд хэсэгт хариу илгээхээсээ өмнө оруулсан өөр арын хэсэгт мета өгөгдлөөр баяжуулсан бол энэ backend боломжгүй бол та өөрийн мета өгөгдлийн ямар ч хэсэггүйгээр хариулах.
Дараа нь бид програмыг эхлүүлэхэд нэг зовлонтой асуудалтай тулгардаг.
Үнэн хэрэгтээ энэ нь зөвхөн Кубернетесэд хамаатай биш, харин зарим төрлийн массын хөгжил, ялангуяа DevOps-ийн соёл Кубернетестэй нэгэн зэрэг тархаж эхэлсэн юм. Тиймээс, ерөнхийдөө та Кубернетесгүйгээр програмаа хаах хэрэгтэй болж байна. Кубернетесээс өмнө хүмүүс үүнийг хийдэг байсан ч Кубернетес гарч ирснээр бид үүнийг бөөнөөр нь ярьж эхэлсэн.
Сайхан унтраах
Ерөнхийдөө Graceful Shutdown гэж юу вэ, яагаад хэрэгтэй вэ? Энэ нь таны програм ямар нэг шалтгааны улмаас гацах үед та үүнийг хийх хэрэгтэй app stop - эсвэл та үйлдлийн системээс дохио хүлээн авбал таны програм үүнийг ойлгож, ямар нэг зүйл хийх ёстой. Мэдээжийн хэрэг хамгийн муу тохиолдол бол таны өргөдөл SIGTERM хүлээн авах бөгөөд "SIGTERM, хүлээцгээе, ажиллая, юу ч хийхгүй" гэсэн шиг байна. Энэ бол үнэхээр муу сонголт юм.
Бараг адилхан муу сонголт бол таны аппликейшн SIGTERM-г хүлээж аваад "тэд segterm гэж хэлсэн, энэ нь бид дуусч байна гэсэн үг, би хараагүй, хэрэглэгчийн хүсэлтийг мэдэхгүй, би ямар төрлийн хүсэлтийг мэдэхгүй байна. Миний яг одоо ажиллаж байгаа хүсэлтүүд, тэд SIGTERM гэж хэлсэн, энэ нь бид дуусч байна гэсэн үг " Энэ нь бас муу сонголт юм.
Аль сонголт нь сайн бэ? Эхний цэг бол үйл ажиллагааны гүйцэтгэлийг анхаарч үзэх явдал юм. Таны сервер SIGTERM хүлээн авсан тохиолдолд юу хийхээ анхаарч үзэх нь сайн сонголт юм.
SIGTERM бол зөөлөн унтрах, энэ нь тусгайлан хийгдсэн, үүнийг кодын түвшинд таслан зогсоох боломжтой, үүнийг боловсруулж болно, одоо хүлээгээрэй, бид эхлээд байгаа ажлаа дуусгана, дараа нь гарна гэж хэлээрэй.
Kubernetes-ийн өнцгөөс харахад энэ нь иймэрхүү харагдаж байна. Бид Кубернетес кластерт ажиллаж байгаа подвод руу "зогс, зайл" гэж хэлэх эсвэл бид дахин асах эсвэл Кубернетес подкуудыг дахин үүсгэх үед шинэчлэлт хийгдэх үед Кубернетес яг ижил SIGTERM мессежийг pod руу илгээж, хүлээх болно. хэсэг хугацаа, мөн , энэ бол түүний хүлээж байгаа цаг, энэ нь бас тохируулагдсан, дипломуудад ийм тусгай параметр байдаг бөгөөд үүнийг Graceful ShutdownTimeout гэж нэрлэдэг. Таны ойлгож байгаагаар үүнийг дэмий хоосон гэж нэрлээгүй бөгөөд бид одоо энэ тухай яриад байгаа нь дэмий хоосон биш юм.
Тэнд бид SIGTERM-ийг програм руу илгээх хүртэл, програм нь ямар нэгэн зүйлд галзуурсан юм уу "гацсан" бөгөөд дуусахгүй гэдгийг ойлгох хооронд хэр удаан хүлээх хэрэгтэйг тодорхой хэлж чадна. үүнийг SIGKILL илгээнэ үү, өөрөөр хэлбэл ажлаа дуусга. Үүний дагуу бид ямар нэгэн төрлийн демон ажиллаж байгаа бөгөөд энэ нь үйл ажиллагааг боловсруулдаг. Демон ажилладаг бидний үйл ажиллагаа дунджаар нэг удаад 30 секундээс хэтрэхгүй гэдгийг бид ойлгож байна. Үүний дагуу SIGTERM ирэхэд манай демон хамгийн ихдээ SIGTERM-ээс 30 секундын дараа дуусгаж чадна гэдгийг бид ойлгож байна. Бид үүнийг жишээ нь 45 секунд гэж бичээд SIGTERM гэж хэлдэг. Үүний дараа бид 45 секунд хүлээнэ. Онолын хувьд энэ хугацаанд чөтгөр ажлаа дуусгаад өөрөө дуусах ёстой байсан. Гэвч хэрэв гэнэт чадахгүй бол энэ нь гацсан байх магадлалтай - энэ нь бидний хүсэлтийг хэвийн байдлаар боловсруулахаа больсон гэсэн үг юм. 45 секундын дотор та түүнийг аюулгүйгээр цохиж чадна.
Энд үнэндээ 2 талыг ч анхаарч үзэх боломжтой. Нэгдүгээрт, хэрэв та хүсэлт хүлээн авсан бол та ямар нэгэн байдлаар түүнтэй ажиллаж эхэлсэн бөгөөд хэрэглэгчдэд хариу өгөөгүй боловч жишээлбэл SIGTERM-ийг хүлээн авсан гэдгийг ойлгоорой. Үүнийг боловсронгуй болгож, хэрэглэгчдэд хариулт өгөх нь утга учиртай юм. Энэ бол үүнтэй холбоотой №XNUMX цэг юм. Хоёрдахь цэг бол хэрэв та өөрөө програм бичвэл ерөнхийдөө программынхаа хүсэлтийг хүлээж авахаар архитектурыг бүтээж, дараа нь зарим ажлыг эхлүүлж, хаа нэг газраас файл татаж, мэдээллийн сан татаж авах гэх мэт. - Тэр. Ерөнхийдөө таны хэрэглэгч, таны хүсэлт хагас цагийн турш гацаж, түүнд хариу өгөхийг хүлээж байна - тэгвэл та архитектур дээр ажиллах хэрэгтэй болно. Өөрөөр хэлбэл, хэрэв таны үйл ажиллагаа богино бол SIGTERM-г үл тоомсорлож, өөрчлөх нь утга учиртай гэсэн нийтлэг ойлголтыг анхаарч үзээрэй. Хэрэв таны үйл ажиллагаа урт бол энэ тохиолдолд SIGTERM-г үл тоомсорлох нь утгагүй болно. Ийм урт үйл ажиллагаа явуулахгүйн тулд архитектурыг дахин төлөвлөх нь утга учиртай. Хэрэглэгчид зүгээр суугаад хүлээхгүйн тулд. Би мэдэхгүй байна, тэнд ямар нэгэн вэбсокет хий, таны сервер аль хэдийн үйлчлүүлэгч рүү илгээх урвуу дэгээ хий, өөр юу ч бай, гэхдээ хэрэглэгчийг хагас цагийн турш түгжрэлд оруулахыг албадах хэрэггүй, та зөвхөн сессийг хүлээх хүртэл хүлээх хэрэгтэй. түүнд хариул. Учир нь энэ нь хагарах газрыг урьдчилан таамаглах аргагүй юм.
Таны програм дуусгавар болоход та тохирох гарах кодыг оруулах ёстой. Өөрөөр хэлбэл, хэрэв таны аппликешныг хаах, зогсоохыг хүссэн бөгөөд энэ нь хэвийн ажиллахаа больсон бол та 1,5,255 гэх мэт гарах кодыг буцааж өгөх шаардлагагүй болно. Линукс системд тэг кодгүй бүх зүйл амжилтгүй гэж тооцогддог. Өөрөөр хэлбэл, энэ тохиолдолд таны өргөдөл алдаатай дууссан гэж үзэж байна. Үүний дагуу, найрсаг байдлаар, хэрэв таны өргөдлийг алдаагүй бөглөсөн бол гаралт дээр 0 гэж бичнэ. Хэрэв таны програм ямар нэг шалтгаанаар бүтэлгүйтвэл гаралт дээр 0 биш гэж хэлнэ. Мөн та энэ мэдээлэлтэй ажиллах боломжтой.
Мөн сүүлчийн сонголт. Таны хэрэглэгч хүсэлт илгээж, түүнийг боловсруулах явцад хагас цаг саатах нь муу байна. Гэхдээ ерөнхийдөө үйлчлүүлэгчийн зүгээс юу үнэ цэнэтэй болохыг би бас хэлмээр байна. Танд мобайл програм, урд талбар гэх мэт байх нь хамаагүй. Ерөнхийдөө хэрэглэгчийн сессийг дуусгаж болно, юу ч тохиолдож болно гэдгийг анхаарч үзэх хэрэгтэй. Хүсэлтийг дутуу боловсруулж, хариу ирүүлээгүй байж болно. Таны frontend эсвэл таны гар утасны програм - ерөнхийдөө ямар ч frontend, үүнийг ингэж хэлье - үүнийг анхаарч үзэх хэрэгтэй. Хэрэв та вэб залгууртай ажилладаг бол энэ нь миний урьд өмнө тохиолдож байсан хамгийн аймшигтай өвдөлт юм.
Зарим ердийн чатын хөгжүүлэгчид үүнийг мэдэхгүй байх үед вэб залгуур эвдэрч магадгүй юм. Тэдний хувьд прокси дээр ямар нэг зүйл тохиолдоход бид зүгээр л тохиргоогоо өөрчилдөг бөгөөд энэ нь дахин ачаалагддаг. Мэдээжийн хэрэг, энэ тохиолдолд бүх урт хугацааны сессүүд урагдсан байдаг. Хөгжүүлэгчид бидэн рүү гүйж ирээд: "Залуус аа, та нар юу хийж байгаа юм бэ, манай бүх үйлчлүүлэгчдийн чат тасарлаа!" Бид тэдэнд: "Чи юу хийж байгаа юм бэ? Таны үйлчлүүлэгчид дахин холбогдох боломжгүй байна уу? Тэд: "Үгүй ээ, бидэнд хуралдаанууд урагдахгүй байх хэрэгтэй." Товчхондоо, энэ бол утгагүй зүйл юм. Үйлчлүүлэгчийн талыг анхаарч үзэх хэрэгтэй. Ялангуяа, миний хэлснээр, вэбсокет гэх мэт урт хугацааны сессүүд нь эвдэрч болзошгүй бөгөөд хэрэглэгч үүнийг анзаарахгүй бол та ийм сессүүдийг дахин суулгах боломжтой байх хэрэгтэй. Тэгээд бүх зүйл төгс болно.
Нөөц
Үнэндээ би энд зүгээр л нэг түүхийг хэлье. Бодит амьдралаас дахин. Нөөцийн талаар сонсож байсан хамгийн аймшигтай зүйл.
Энэ тохиолдолд эх сурвалжууд нь Kubernetes кластерууд дээр тавьж болох зарим төрлийн хүсэлт, хязгаарлалтуудыг хэлнэ. Хөгжүүлэгчээс сонссон хамгийн инээдтэй зүйл... Өмнө нь ажиллаж байсан манай хөгжүүлэгчид нэг удаа: "Миний програм кластерт ажиллахгүй байна" гэж хэлсэн. Энэ нь эхлээгүй байна гэж би харлаа, гэхдээ энэ нь нөөцөд тохирохгүй байна, эсвэл тэд маш бага хязгаарлалт тавьсан. Товчхондоо нөөцийн улмаас програмыг эхлүүлэх боломжгүй байна. Би: "Энэ нь нөөцийн улмаас эхлэхгүй, та хэр их хэрэгтэйг шийдэж, хангалттай үнэ цэнийг тогтооно." Тэр: "Ямар нөөц вэ?" Би түүнд Kubernetes, хүсэлтийн хязгаарлалт, бла, бла, бла тогтоох хэрэгтэй гэдгийг тайлбарлаж эхлэв. Тэр хүн таван минутын турш сонсож, толгой дохин: "Би энд хөгжүүлэгчээр ажиллахаар ирсэн, ямар ч нөөцийн талаар юу ч мэдэхийг хүсэхгүй байна. Би энд код бичих гэж ирсэн, тэгээд л болоо." Энэ нь гунигтай юм. Энэ нь хөгжүүлэгчийн үүднээс маш гунигтай ойлголт юм. Ялангуяа орчин үеийн ертөнцөд дэвшилтэт девопуудын тухай ярих юм.
Ер нь яагаад нөөц хэрэгтэй байна вэ? Kubernetes-д 2 төрлийн нөөц байдаг. Заримыг нь хүсэлт, заримыг нь хязгаар гэж нэрлэдэг. Нөөцөөр бид үндсэндээ үргэлж хоёр үндсэн хязгаарлалт байдаг гэдгийг ойлгох болно. Өөрөөр хэлбэл, Кубернетес дээр ажиллаж байгаа контейнерын CPU-ийн цагийн хязгаарлалт ба RAM-ийн хязгаарлалт.
Хязгаар нь таны програмд нөөцийг хэрхэн ашиглах дээд хязгаарыг тогтоодог. Өөрөөр хэлбэл, хэрэв та хязгаарт 1 ГБ RAM гэж хэлбэл таны програм 1 ГБ-аас илүү RAM ашиглах боломжгүй болно. Хэрэв тэр гэнэт хүсч, үүнийг хийхийг оролдвол oom killer гэж нэрлэгддэг үйл явц нь санах ойгүй, өөрөөр хэлбэл таны програмыг устгах болно - өөрөөр хэлбэл энэ нь зүгээр л дахин эхлүүлэх болно. Процессор дээр үндэслэн програмуудыг дахин эхлүүлэхгүй. CPU-ийн хувьд, хэрэв програм хязгаарт заасан хэмжээнээс илүү ихийг ашиглахыг оролдвол CPU-г зүгээр л хатуу сонгох болно. Энэ нь дахин эхлүүлэхэд хүргэдэггүй. Энэ бол хязгаар юм - энэ бол дээд хязгаар юм.
Мөн хүсэлт байна. Хүсэлт нь Кубернетес таны Kubernetes кластерын зангилаанууд хэрхэн программуудаар дүүрсэнийг хэрхэн ойлгодог болохыг хэлнэ. Өөрөөр хэлбэл, хүсэлт нь таны өргөдлийн нэг төрлийн үүрэг юм. Энэ нь миний ашиглахыг хүссэн зүйлээ бичсэн байна: "Би чамайг ийм их CPU, ийм их санах ойг надад зориулж нөөцлөхийг хүсч байна." Ийм энгийн зүйрлэл. Бидэнд нийт 8 CPU-тэй зангилаа байвал яах вэ, би мэдэхгүй. Тэнд нэг pod ирдэг бөгөөд хүсэлтэд нь 1 CPU гэж бичсэн нь зангилаанд 7 CPU үлдсэн гэсэн үг юм. Өөрөөр хэлбэл, тус бүрдээ 8 CPU-тэй 1 хонхорцог энэ зангилаа дээр ирэнгүүт Kubernetes-ийн үүднээс авч үзвэл уг зангилаа нь CPU-гүй болсон бөгөөд хүсэлт бүхий олон pods боломжгүй юм. энэ зангилаа дээр эхлүүлсэн. Хэрэв бүх зангилааны CPU дуусвал Кубернетес CPU дууссан тул кластерт таны подкуудыг ажиллуулах тохирох цэг байхгүй гэж хэлж эхэлнэ.
Хүсэлт яагаад хэрэгтэй вэ, яагаад хүсэлтгүй бол Кубернетес дээр юу ч эхлүүлэх шаардлагагүй гэж би бодож байна вэ? Таамаглалын нөхцөл байдлыг төсөөлье. Та хүсэлтгүйгээр програмаа ажиллуулдаг бол Кубернетес танд хичнээн их зүйл байгаа, ямар зангилаа руу түлхэж болохыг мэдэхгүй. За, тэр зангилаа руу түлхэж, түлхэж, түлхэж өгдөг. Хэзээ нэгэн цагт та өөрийн аппликешны урсгалыг авч эхлэх болно. Мөн програмуудын нэг нь нөөцийг хязгаарт тохируулан ашиглаж эхэлдэг. Ойролцоох өөр програм байгаа бөгөөд үүнд бас нөөц хэрэгтэй байна. Зангилаа нь бодитоор нөөц бололцоогүй болж эхэлдэг, жишээлбэл, OP. Зангилаа нь бодитоор нөөц бололцоогүй болж эхэлдэг, жишээлбэл, санамсаргүй хандалтын санах ой (RAM). Зангилааны цэнэг дуусвал эхлээд докер, дараа нь куб, дараа нь үйлдлийн систем хариу өгөхөө болино. Тэд зүгээр л ухаангүй болж, БҮХ ЗҮЙЛ таны төлөө ажиллахаа болино. Өөрөөр хэлбэл, энэ нь таны зангилаа гацахад хүргэж, дахин эхлүүлэх шаардлагатай болно. Товчхондоо байдал тийм ч сайн биш байна.
Хэрэв танд хүсэлт байгаа бол хязгаар нь тийм ч их ялгаатай биш, наад зах нь хязгаар эсвэл хүсэлтээс олон дахин их биш бол Кубернетес кластеруудын зангилаанууд дээрх програмуудыг хэвийн, оновчтой бөглөх боломжтой. Үүний зэрэгцээ, Кубернетес юуг хаана, хэдийг нь хаана хэрэглэхээ мэддэг. Энэ бол яг ийм мөч юм. Үүнийг ойлгох нь чухал. Үүнийг зааж өгсөн эсэхийг хянах нь чухал юм.
Өгөгдөл хадгалах
Бидний дараагийн санаа бол өгөгдөл хадгалах тухай юм. Тэдэнтэй юу хийх вэ, ерөнхийдөө Kubernetes-д тууштай байхын тулд юу хийх вэ?
Дахин хэлэхэд бидний дотор , Kubernetes дахь мэдээллийн сангийн тухай сэдэв байсан. "Кубернетес дэх мэдээллийн сан ажиллуулах боломжтой юу?" гэж асуухад танай хамт олон юу гэж хэлснийг би бараг л мэдэж байх шиг байна. Зарим шалтгааны улмаас танай хамт олон танд Kubernetes-д мэдээллийн сан ажиллуулах боломжтой юу гэсэн асуултыг асууж байгаа бол энэ боломжгүй гэж хэлэх ёстой юм шиг санагдаж байна.
Энд байгаа логик нь энгийн. Ямар ч тохиолдолд би дахин нэг удаа тайлбарлая, хэрвээ та тархсан сүлжээний хадгалалтын нэлээн гэмтэлд тэсвэртэй системийг бий болгож чадах үнэхээр гайхалтай залуу бол энэ тохиолдолд мэдээллийн санг хэрхэн тохируулах, контейнер доторх үүлний эх үүсвэр хэрхэн ажиллах ёстойг ойлгоорой. ерөнхийдөө мэдээллийн санд. Үүнийг хэрхэн ажиллуулах талаар танд асуулт байхгүй байх магадлалтай. Хэрэв танд ийм асуулт байгаа бол энэ бүхэн дэлгэгдэж, үйлдвэрлэлд үхтлээ зогсох бөгөөд хэзээ ч унахгүй байхыг хүсч байвал ийм зүйл болохгүй. Энэ арга барилаар та хөл рүүгээ буудах нь баталгаатай. Тиймээс хийхгүй байсан нь дээр.
Манай аппликешныг хадгалахыг хүссэн өгөгдөл, хэрэглэгчдийн байршуулдаг зарим зураг, манай програмыг ажиллуулах явцад үүсгэдэг зарим зүйлийг жишээ нь эхлүүлэх үед бид яах ёстой вэ? Kubernetes-д тэдэнтэй юу хийх вэ?
Ерөнхийдөө, тийм ээ, мэдээжийн хэрэг, Кубернетес нь маш сайн зохион бүтээгдсэн бөгөөд ерөнхийдөө харьяалалгүй програмуудад зориулагдсан болно. Энэ нь мэдээллийг огт хадгалдаггүй програмуудад зориулагдсан болно. Энэ бол хамгийн тохиромжтой.
Гэхдээ мэдээжийн хэрэг хамгийн тохиромжтой сонголт үргэлж байдаггүй. Тэгээд юу гэж? Эхний бөгөөд хамгийн энгийн зүйл бол ямар нэг төрлийн S3 авах явдал юм, зүгээр л гэртээ хийсэн биш, энэ нь хэрхэн ажилладаг нь тодорхойгүй, гэхдээ зарим үйлчилгээ үзүүлэгчээс. Сайн, энгийн үйлчилгээ үзүүлэгч - мөн програмдаа S3 ашиглахыг заа. Өөрөөр хэлбэл, таны хэрэглэгч файл байршуулахыг хүсвэл "энд, S3 руу байршуулна уу" гэж хэлээрэй. Түүнийг хүлээж авахыг хүсвэл: "Энд S3 руу буцах линк байна, эндээс аваарай" гэж хэлээрэй. Энэ бол хамгийн тохиромжтой.
Хэрэв гэнэт ямар нэг шалтгааны улмаас энэ тохиромжтой сонголт тохирохгүй байвал таны бичээгүй, хөгжүүлээгүй эсвэл ямар нэгэн аймшигтай өв залгамжлалтай програм байгаа бол энэ нь S3 протоколыг ашиглах боломжгүй, гэхдээ локал лавлахтай ажиллах ёстой. локал фолдерууд. Илүү бага эсвэл энгийн зүйлийг авч, Kubernetes-ийг байрлуул. Өөрөөр хэлбэл, Цефийг хамгийн бага даалгаврын дагуу шууд хашаалах нь муу санаа юм шиг санагдаж байна. Учир нь Ceph мэдээж сайн, загварлаг. Гэхдээ хэрвээ та юу хийж байгаагаа сайн ойлгохгүй байгаа бол Цеф дээр ямар нэг зүйл тавьсны дараа та үүнийг маш амархан бөгөөд дахиж хэзээ ч гаргаж чадахгүй. Учир нь таны мэдэж байгаагаар Ceph нь өгөгдлийг кластертаа энгийн файл хэлбэрээр биш хоёртын хэлбэрээр хадгалдаг. Тиймээс, хэрэв гэнэт Ceph кластер эвдэрвэл та дахиж хэзээ ч мэдээллээ авахгүй байх магадлал өндөр байна.
Бид Цефийн талаар сургалт явуулах болно, та чадна .
Тиймээс NFS сервер шиг энгийн зүйл хийх нь дээр. Kubernetes тэдэнтэй ажиллах боломжтой, та NFS серверийн доор лавлах холбох боломжтой - таны програм яг л локал лавлахтай адил юм. Үүний зэрэгцээ, мэдээжийн хэрэг та NFS-тэй дахин ямар нэг зүйл хийх хэрэгтэй гэдгийг ойлгох хэрэгтэй, заримдаа энэ нь нэвтрэх боломжгүй болж магадгүй гэдгийг ойлгож, энэ тохиолдолд юу хийх вэ гэсэн асуултыг авч үзэх хэрэгтэй. Магадгүй үүнийг тусдаа машин дээр хаа нэгтээ нөөцлөх хэрэгтэй.
Миний ярьсан дараагийн зүйл бол таны програм ажиллах явцад зарим файл үүсгэдэг бол яах вэ. Жишээлбэл, энэ нь ажиллаж эхлэх үед энэ нь програмыг зөвхөн эхлүүлэх үед хүлээн авдаг зарим мэдээлэл дээр үндэслэсэн статик файл үүсгэдэг. Ямар хором вэ. Хэрэв тийм их мэдээлэл байхгүй бол та огт санаа зовох хэрэггүй, зөвхөн энэ програмыг өөртөө суулгаад ажиллаарай. Энд байгаа цорын ганц асуулт бол юу вэ, хараарай. Ихэнх тохиолдолд WordPress гэх мэт бүх төрлийн хуучин системүүд, ялангуяа өөрчилсөн ухаалаг залгаасууд, ухаалаг PHP хөгжүүлэгчид тэд үүнийг хэрхэн яаж хийхээ мэддэг тул өөрсдөө ямар нэгэн төрлийн файл үүсгэдэг. Үүний дагуу нэг нь нэг файл үүсгэдэг бол хоёр дахь нь хоёр дахь файлыг үүсгэдэг. Тэд өөр. Тэнцвэржүүлэлт нь үйлчлүүлэгчдийн Kubernetes кластерт тохиолдлоор тохиолддог. Үүний дагуу тэд хэрхэн хамтран ажиллахаа мэдэхгүй байна. Нэг нь нэг мэдээлэл өгдөг бол нөгөө нь хэрэглэгчдэд өөр мэдээлэл өгдөг. Энэ бол таны зайлсхийх ёстой зүйл юм. Өөрөөр хэлбэл, Kubernetes-д таны эхлүүлсэн бүх зүйл олон тохиолдолд ажиллах боломжтой болно. Учир нь Кубернетес бол хөдөлгөөнт зүйл. Үүний дагуу тэрээр хүссэн үедээ, хэнээс ч гуйлгүйгээр юуг ч хөдөлгөж чадна. Тиймээс та үүнд найдах хэрэгтэй. Нэг тохиолдлоор эхлүүлсэн бүх зүйл эрт орой хэзээ нэгэн цагт бүтэлгүйтэх болно. Та хэдий чинээ олон захиалгатай байна төдий чинээ сайн. Гэхдээ би дахиад хэлье, хэрэв танд ийм хэдэн файл байгаа бол тэдгээрийг шууд доороо тавьж болно, тэд бага жинтэй. Хэрэв тэдгээрээс бага зэрэг олон байвал та тэдгээрийг саванд хийж болохгүй.
Kubernetes-д ийм гайхалтай зүйл байдаг гэж би зөвлөж байна, та эзлэхүүнийг ашиглаж болно. Ялангуяа хоосон dir төрлийн боть байдаг. Өөрөөр хэлбэл, Кубернетес таны эхлүүлсэн сервер дээрх үйлчилгээний лавлах хэсэгт автоматаар лавлах үүсгэх болно. Тэгээд тэр үүнийг танд өгөх болно, ингэснээр та үүнийг ашиглах болно. Зөвхөн нэг чухал зүйл бий. Өөрөөр хэлбэл, таны өгөгдөл контейнер дотор хадгалагдахгүй, харин таны ажиллаж байгаа хост дээр хадгалагдах болно. Түүгээр ч барахгүй Кубернетес нь ердийн тохиргооны дагуу ийм хоосон дирнуудыг хянах боломжтой бөгөөд тэдгээрийн хамгийн дээд хэмжээг хянаж, хэтрүүлэхийг зөвшөөрдөггүй. Цорын ганц зүйл бол таны хоосон dir-д бичсэн зүйл нь pod дахин эхлүүлэх үед алга болохгүй. Өөрөөр хэлбэл, хэрэв таны хонхорхой санамсаргүйгээр унаж, дахин босвол хоосон дир дахь мэдээлэл хаашаа ч гарахгүй. Тэр үүнийг шинэ эхлэлд дахин ашиглаж болно - энэ нь сайн хэрэг. Хэрэв таны хонхорцог хаа нэгтээ орхих юм бол тэр мэдээж өгөгдөлгүйгээр явах болно. Өөрөөр хэлбэл, хоосон dir-ээр эхлүүлсэн зангилааны pod алга болмогц хоосон dir устана.
Хоосон найрлагын өөр юу сайн бэ? Жишээлбэл, үүнийг кэш болгон ашиглаж болно. Манай аппликейшн нь ямар нэг зүйлийг шууд үүсгэж, хэрэглэгчдэдээ өгч, удаан хугацаанд хийдэг гэж төсөөлөөд үз дээ. Тиймээс, жишээлбэл, програм нь үүнийг үүсгэж, хэрэглэгчдэд өгөхийн зэрэгцээ хаа нэгтээ хадгалдаг тул дараагийн удаа хэрэглэгч ижил зүйлээр ирэхэд үүнийг шууд үүсгэсэн нь хурдан өгөх болно. Санах ойд үүсгэхийг Кубернетесээс хоосон директор асууж болно. Тиймээс таны кэш нь дискний хандалтын хурдны хувьд ерөнхийдөө аянгын хурдаар ажиллах боломжтой. Өөрөөр хэлбэл, таны санах ойд хоосон dir байгаа бөгөөд OS-д энэ нь санах ойд хадгалагддаг, харин таны хувьд, pod доторх хэрэглэгчийн хувьд энэ нь зүгээр л локал лавлах шиг харагдаж байна. Ямар нэгэн ид шидийг тусгайлан заахын тулд танд програм хэрэггүй. Та зүгээр л файлаа шууд аваад директор руу оруулна, гэхдээ үнэндээ үйлдлийн систем дээрх санах ойд. Энэ нь мөн Kubernetes-ийн хувьд маш тохиромжтой шинж чанар юм.
Миниод ямар асуудал тулгардаг вэ? Minio-ийн гол асуудал бол энэ зүйл ажиллахын тулд хаа нэгтээ ажиллаж байх ёстой бөгөөд ямар нэгэн файлын систем, өөрөөр хэлбэл хадгалах газар байх ёстой. Энд бид Сефтэй адил асуудалтай тулгардаг. Өөрөөр хэлбэл, Minio файлуудаа хаа нэгтээ хадгалах ёстой. Энэ бол зүгээр л таны файлуудын HTTP интерфейс юм. Түүгээр ч зогсохгүй функциональ байдал нь Amazon-ийн S3-аас илт муу байна. Өмнө нь энэ нь хэрэглэгчийг зохих ёсоор зөвшөөрөх боломжгүй байсан. Одоо миний мэдэж байгаагаар энэ нь өөр өөр зөвшөөрөлтэй хувинуудыг үүсгэж чаддаг, гэхдээ дахин хэлэхэд гол асуудал бол хамгийн багадаа суурь хадгалах систем юм шиг санагдаж байна.
Санах ойн хоосон зай нь хязгаарт хэрхэн нөлөөлдөг вэ? Хязгаарлалтад ямар нэгэн байдлаар нөлөөлөхгүй. Энэ нь таны чингэлэгийн санах ойд биш, харин хостын санах ойд оршдог. Өөрөөр хэлбэл, таны контейнер эзлэгдсэн санах ойнхоо нэг хэсэг болох санах ойн хоосон дирыг харахгүй байна. Хөтлөгч үүнийг харж байна. Үүний дагуу, тийм ээ, кубернетийн үүднээс авч үзвэл, та үүнийг ашиглаж эхлэхдээ санах ойнхоо нэг хэсгийг хоосон дүрд зориулж байна гэдгийг ойлгох нь зүйтэй болов уу. Үүний дагуу санах ой нь зөвхөн програмуудаас болоод зогсохгүй хэн нэгэн эдгээр хоосон директор руу бичдэг учраас дуусч болно гэдгийг ойлгоорой.
Үүлэрхэг байдал
Эцсийн дэд сэдэв бол Cloudnative гэж юу вэ. Яагаад хэрэгтэй байна вэ? Үүлэрхэг байдал гэх мэт.
Энэ нь орчин үеийн үүлэн дэд бүтцэд ажиллах чадвартай, бичигдсэн програмууд юм. Гэвч үнэн хэрэгтээ Cloudnative нь өөр нэг талтай. Энэ нь орчин үеийн үүлэн дэд бүтцийн бүх шаардлагыг харгалзан үзсэн програм төдийгүй орчин үеийн үүлэн дэд бүтэцтэй хэрхэн ажиллах, эдгээр үүлэн дээр ажилладаг давуу болон сул талуудыг ашиглах чадвартай програм юм. Зөвхөн хэтрүүлж, үүлэн дотор ажиллахгүй, харин үүлэн дээр ажиллахын давуу талыг ашиглаарай.
Зүгээр л Кубернетесийг жишээ болгон авч үзье. Таны програм Кубернетес дээр ажиллаж байна. Таны аппликешн үргэлж, эсвэл таны аппликешны админууд үргэлж үйлчилгээний бүртгэл үүсгэж болно. Энэ нь Кубернетес дэх өөрийн серверт зөвшөөрөл олгох данс юм. Тэнд бидэнд хэрэгтэй зарим эрхийг нэмж оруулаарай. Мөн та өөрийн аппликешн дотроос Kubernetes-д хандах боломжтой. Та энэ аргаар юу хийж чадах вэ? Жишээлбэл, хэрэглүүрээс өөрийн бусад програмууд, бусад ижил төстэй тохиолдлууд хаана байрладаг тухай мэдээллийг хүлээн авч, хэрэв шаардлагатай бол Kubernetes-ийн дээд хэсэгт ямар нэгэн байдлаар кластер хийх боломжтой.
Дахин хэлэхэд бид саяхан нэг хэрэг гарлаа. Бид дараалалд хяналт тавьдаг нэг хянагчтай. Энэ дараалалд зарим шинэ даалгавар гарч ирэхэд энэ нь Кубернетес рүү очих ба Кубернетес дотор шинэ pod үүсгэнэ. Энэ pod-д зарим нэг шинэ даалгавар өгч, энэ pod-ийн хүрээнд уг даалгаврыг гүйцэтгэж, өөрөө хянагч руу хариу илгээж, хянагч энэ мэдээллээр ямар нэг зүйл хийдэг. Жишээлбэл, энэ нь мэдээллийн санг нэмдэг. Энэ нь дахин хэлэхэд энэ нь манай програм Кубернетес дээр ажиллаж байгаагийн давуу тал юм. Бид ямар нэгэн байдлаар өргөжүүлж, програмынхаа үйл ажиллагааг илүү тохиромжтой болгохын тулд суурилуулсан Kubernetes функцийг ашиглаж болно. Өөрөөр хэлбэл, програмыг хэрхэн эхлүүлэх, ажилчдыг хэрхэн эхлүүлэх талаар ямар нэгэн ид шидийг нууж болохгүй. Kubernetes-д хэрэв програм Python дээр бичигдсэн бол та зүгээр л програм дээр хүсэлт илгээдэг.
Хэрэв бид Кубернетесээс цааш явах юм бол мөн адил хамаарна. Манай Кубернетес хаа нэгтээ ажилладаг - энэ нь ямар нэгэн үүлэн дотор байвал сайн. Дахин хэлэхэд, бид ажиллаж байгаа үүлний чадавхийг ашиглаж болно, тэр ч байтугай ашиглах ёстой гэж би бодож байна. Үүл бидэнд өгдөг энгийн зүйлсээс. Тэнцвэржүүлэх, өөрөөр хэлбэл бид үүл тэнцвэржүүлэгчийг үүсгэж, тэдгээрийг ашиглах боломжтой. Энэ нь бидний ашиглаж болох шууд давуу тал юм. Учир нь үүлэн тэнцвэржүүлэх нь нэгдүгээрт, энэ нь хэрхэн ажилладаг, хэрхэн тохируулагдсан талаарх хариуцлагыг биднээс тэнэг байдлаар арилгадаг. Дээрээс нь энэ нь маш тохиромжтой, учир нь ердийн Кубернетес үүлтэй нэгтгэж чаддаг.
Энэ нь масштабын хувьд ч мөн адил юм. Ердийн Kubernetes нь үүл үйлчилгээ үзүүлэгчтэй нэгтгэх боломжтой. Хэрэв кластерт зангилаа дуусвал, өөрөөр хэлбэл зангилааны зай дууссан бол та нэмэх хэрэгтэй гэдгийг хэрхэн ойлгохыг мэддэг - Kubernetes өөрөө таны кластерт шинэ зангилаа нэмж, тэдгээр дээр pods ажиллуулж эхэлнэ. Ачаа чинь ирэхээр гал голомт олширч эхэлдэг гэсэн үг. Кластер дахь зангилаанууд эдгээр хонхорцог дуусвал Kubernetes шинэ зангилаа ажиллуулж, үүний дагуу хонхорцогуудын тоо нэмэгдэх боломжтой. Мөн энэ нь маш тохиромжтой. Энэ нь кластерыг шууд масштабаар нэмэгдүүлэх шууд боломж юм. Маш хурдан биш, энэ нь нэг секунд биш, шинэ зангилаа нэмэхийн тулд нэг минуттай адил юм.
Гэхдээ миний туршлагаас харахад энэ бол миний харж байсан хамгийн гайхалтай зүйл юм. Cloudnative кластер нь өдрийн цагаар тохируулагдсан үед. Энэ бол арын албаны хүмүүс ашигладаг backend үйлчилгээ байсан. Өөрөөр хэлбэл, тэд өглөө 9 цагт ажилдаа ирж, системд нэвтэрч эхэлдэг бөгөөд үүний дагуу бүх ажиллаж байгаа Cloudnative кластер хавдаж, ажилдаа ирсэн хүн бүр програмтай ажиллах боломжтой болохын тулд шинэ pods ажиллуулж эхэлдэг. Тэд оройн 8 эсвэл 6 цагт ажлаасаа тарах үед Кубернетес кластерууд энэ програмыг хэн ч ашиглахгүй байгааг анзаарч, багасч эхэлдэг. 30 хүртэлх хувийн хэмнэлт гаргах баталгаатай. Тэр үед Амазон дээр ажилладаг байсан, тэр үед Орост ийм сайн хийж чадах хүн байгаагүй.
Би шууд хэлье, бид Кубернетес ашиглаж, үүлний боломжуудыг ашигладаг учраас хэмнэлт нь 30 хувь юм. Одоо үүнийг Орост хийж болно. Мэдээжийн хэрэг би хэнд ч сурталчилгаа хийхгүй, гэхдээ үүнийг хийх боломжтой үйлчилгээ үзүүлэгчид байгаа гэдгийг хэлье, үүнийг хайрцагнаас нь товчлуураар ханга.
Хамгийн сүүлд би та бүхний анхаарлыг татахыг хүсч буй нэг зүйл байна. Таны хэрэглүүр, таны дэд бүтэц үүлэрхэг байхын тулд Дэд бүтэц гэж нэрлэгддэг хандлагыг код болгон дасан зохицож эхлэх нь зүйтэй юм. Энэ нь таны програм, эсхүл таны дэд бүтэцтэй яг адилхан хэрэгтэй гэсэн үг юм. код Өөрийн програм, бизнесийн логикийг код хэлбэрээр тайлбарлана уу. Түүнтэй код хэлбэрээр ажиллана, өөрөөр хэлбэл үүнийг туршиж, эргэлдүүлж, git дээр хадгалаад, CICD-г хэрэглээрэй.
Энэ нь танд нэгдүгээрт, дэд бүтцээ үргэлж хянах, ямар байдалд байгааг үргэлж ойлгох боломжийг олгодог зүйл юм. Хоёрдугаарт, алдаа гаргадаг гар ажиллагаанаас зайлсхийх хэрэгтэй. Гуравдугаарт, гар ажиллагаатай ижил ажлуудыг байнга хийх шаардлагатай үед эргэлт гэж нэрлэгддэг зүйлээс зайлсхий. Дөрөвдүгээрт, энэ нь бүтэлгүйтсэн тохиолдолд илүү хурдан сэргээх боломжийг олгодог. Орост намайг энэ тухай ярих болгонд "Тийм ээ, ойлгомжтой, гэхдээ танд арга барил бий, товчхондоо юу ч засах шаардлагагүй" гэж хэлдэг маш олон хүмүүс байдаг. Гэхдээ үнэн. Хэрэв таны дэд бүтцэд ямар нэг зүйл эвдэрсэн бол Cloudnative хандлагын үүднээс, Дэд бүтцийг код болгон авч үзвэл үүнийг засах, серверт очиж, юу эвдэрсэнийг олж мэдэх, засах нь илүү хялбар болно. серверийг устгаад дахин үүсгэх. Тэгээд би энэ бүхнийг сэргээх болно.
Эдгээр бүх асуудлыг илүү дэлгэрэнгүй авч үзэх болно . Та линкээр орж хөтөлбөр болон нөхцөлтэй танилцах боломжтой. Тохиромжтой зүйл бол та гэртээ эсвэл өдөрт 1-2 цаг ажиллах замаар Кубернетесийг эзэмшиж чадна.
Эх сурвалж: www.habr.com