Southbridge Solutions архитектор, Slurm багш Павел Селиванов DevOpsConf 2019 дээр илтгэл тавьсан. Энэхүү яриа нь Kubernetes "Slurm Mega" сэдвээр гүнзгийрүүлсэн сургалтын сэдвүүдийн нэг хэсэг юм.
18-р сарын 20-XNUMX-нд Москвад болно.
- Москва, 22-р сарын 24-XNUMX.
үргэлж бэлэн байдаг.
Тайлангийн доод талд тайлангийн хуулбар байна.
Өдрийн мэнд, хамт олон, тэднийг өрөвддөг хүмүүс. Өнөөдөр би аюулгүй байдлын талаар ярих болно.
Өнөөдөр зааланд олон хамгаалагчид байгааг би харж байна. Аюулгүй байдлын ертөнцийн нэр томьёог таны заншилтай адил бус ашигласан бол та бүхнээс урьдчилан хүлцэл өчье.
Зургаан сарын өмнө би нэг нийтийн Кубернетес кластертай таарсан юм. Нийтлэг гэдэг нь n-р тооны нэрийн орон зай байна гэсэн үг бөгөөд эдгээр нэрийн талбарт өөрсдийн нэрийн талбарт тусгаарлагдсан хэрэглэгчид байна. Эдгээр бүх хэрэглэгчид өөр өөр компанид харьяалагддаг. За, энэ кластерийг CDN болгон ашиглах ёстой гэж үзсэн. Өөрөөр хэлбэл, тэд танд кластер өгч, тэнд хэрэглэгчийг өгч, та өөрийн нэрийн орон зайд очиж, фронтоо байрлуулна.
Миний өмнөх компани ийм үйлчилгээг зарах гэж оролдсон. Мөн энэ шийдэл тохиромжтой эсэхийг мэдэхийн тулд кластерыг нудрахыг надаас хүссэн.
Би энэ кластерт ирсэн. Надад хязгаарлагдмал эрх, хязгаарлагдмал нэрийн орон зай өгсөн. Тэндхийн залуус аюулгүй байдал гэж юу байдгийг ойлгосон. Тэд Кубернетес дэх дүрд суурилсан хандалтын хяналтын (RBAC) талаар уншсан бөгөөд би үүнийг байршуулалтаас тусад нь ажиллуулж чадахгүйн тулд үүнийг мушгин гуйвуулсан. Байршлуулалгүйгээр pod ажиллуулах замаар шийдэх гэж оролдсон асуудлаа би санахгүй байна, гэхдээ би зүгээр л нэг pod ажиллуулахыг үнэхээр хүсч байсан. Амжилт хүсье, би кластерт ямар эрхтэй, би юу хийж чадах, юу хийж чадахгүй, тэнд юуг завдсаныг харахаар шийдсэн. Үүний зэрэгцээ, би RBAC-д юу буруу тохируулсныг танд хэлэх болно.
Хоёр минутын дотор би тэдний кластерын админыг хүлээн авч, хөрш зэргэлдээх бүх нэрсийн орон зайг үзэж, үйлчилгээг аль хэдийн худалдаж авсан компаниудын үйлдвэрлэлийн фронтуудыг олж харав. Би хэн нэгний урд очиж, үндсэн хуудсан дээр хараалын үг бичихээс өөрийгөө арай ядан зогсоож чадсан.
Би үүнийг хэрхэн хийсэн, үүнээс өөрийгөө хэрхэн хамгаалах талаар жишээгээр хэлэх болно.
Гэхдээ эхлээд өөрийгөө танилцуулъя. Намайг Павел Селиванов гэдэг. Би Southbridge-д архитектор хийдэг. Би Kubernetes, DevOps болон бүх төрлийн гоёмсог зүйлсийг ойлгодог. Өмнөд гүүрийн инженерүүд бид хоёр энэ бүхнийг барьж, зөвлөгөө өгч байна.
Бид үндсэн үйл ажиллагаанаасаа гадна саяхан Slurms нэртэй төслүүдийг эхлүүлсэн. Бид Kubernetes-тэй ажиллах чадвараа олон нийтэд хүргэхийг хичээж, бусад хүмүүст мөн K8-тэй ажиллахыг зааж өгөхийг хичээж байна.
Би өнөөдөр юу ярих вэ? Тайлангийн сэдэв нь мэдээжийн хэрэг - Кубернетес кластерын аюулгүй байдлын тухай. Гэхдээ би энэ сэдэв маш том гэдгийг шууд хэлмээр байна - тиймээс би юу ярихгүй байхаа нэн даруй тодруулахыг хүсч байна. Би интернетэд аль хэдийн зуу дахин ашиглагдсан хакердсан нэр томъёоны талаар ярихгүй. Бүх төрлийн RBAC болон гэрчилгээ.
Би Кубернетес кластерын аюулгүй байдлын талаар намайг болон миний хамтран ажиллагсдад юу зовж байгаа талаар ярих болно. Бид эдгээр асуудлуудыг Kubernetes кластераар хангадаг үйлчилгээ үзүүлэгчдийн дунд болон манайд ирдэг үйлчлүүлэгчдийн дунд харж байна. Мөн бусад зөвлөх админ компаниудаас манайд ирдэг үйлчлүүлэгчдээс ч гэсэн. Энэ нь эмгэнэлт явдлын цар хүрээ нь үнэндээ маш том юм.
Өнөөдөр миний ярих гурван зүйл байна:
- Хэрэглэгчийн эрх гэх мэт. Хэрэглэгчийн эрх болон pod эрх нь ижил зүйл биш юм.
- Кластерын талаар мэдээлэл цуглуулах. Та энэ кластерт тусгай эрхгүйгээр кластераас хэрэгтэй бүх мэдээллээ цуглуулж чадна гэдгийг би харуулах болно.
- Кластер дээрх DoS халдлага. Хэрэв бид мэдээлэл цуглуулж чадахгүй бол ямар ч тохиолдолд кластер хийх боломжтой. Би кластерын хяналтын элементүүдэд DoS халдлагын талаар ярих болно.
Миний дурдах өөр нэг ерөнхий зүйл бол би энэ бүгдийг туршиж үзсэн зүйл бөгөөд энэ нь бүгд үр дүнтэй гэж би хэлж чадна.
Бид Kubespray ашиглан Kubernetes кластер суурилуулах ажлыг үндэс болгон авдаг. Хэрэв хэн нэгэн мэдэхгүй бол энэ нь үнэндээ Ansible-д зориулсан дүрүүдийн багц юм. Бид үүнийг ажилдаа байнга ашигладаг. Сайн тал нь та үүнийг хаана ч өнхрүүлж болно - та төмрийн хэсгүүд дээр эсвэл хаа нэгтээ үүлэн дээр өнхрүүлж болно. Нэг суулгах арга нь зарчмын хувьд бүх зүйлд ажилладаг.
Энэ кластерт би Kubernetes v1.14.5 байх болно. Бидний авч үзэх Cube кластер бүхэлдээ нэрийн талбарт хуваагдаж, нэрийн талбар бүр тусдаа багт харьяалагддаг бөгөөд энэ багийн гишүүд нэрийн талбар бүрт хандах эрхтэй. Тэд өөр өөр нэрийн орон зайд очиж чадахгүй, зөвхөн өөрсдийнхөө орон зайд. Гэхдээ бүхэл бүтэн кластерт хандах эрхтэй тодорхой админ данс байдаг.
Бидний хийх хамгийн эхний зүйл бол кластерын админ эрхийг авах болно гэж би амласан. Бид Kubernetes кластерыг эвдэх тусгайлан бэлтгэсэн pod хэрэгтэй. Бидний хийх ёстой зүйл бол үүнийг Kubernetes кластерт ашиглах явдал юм.
kubectl apply -f pod.yamlЭнэ pod Kubernetes кластерын мастеруудын нэгэнд очих болно. Үүний дараа кластер бидэнд admin.conf нэртэй файлыг баяртайгаар буцааж өгөх болно. Cube-д энэ файл нь бүх администраторын гэрчилгээг хадгалдаг бөгөөд үүний зэрэгцээ кластерийн API-г тохируулдаг. Kubernetes кластеруудын 98% -д админ хандах нь ийм амархан байдаг гэж би бодож байна.
Дахин хэлье, энэ подволкыг нэг жижиг нэрийн талбарт оруулах боломжтой таны кластерын нэг хөгжүүлэгч хийсэн бөгөөд үүнийг бүгдийг RBAC хавчуулсан болно. Түүнд ямар ч эрх байгаагүй. Гэсэн хэдий ч гэрчилгээг буцааж өгсөн.
Тэгээд одоо тусгайлан бэлтгэсэн подын тухай. Бид үүнийг ямар ч зураг дээр ажиллуулдаг. Жишээ болгон debian:jessie-г авч үзье.
Бидэнд ийм зүйл байна:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Хүлцэл гэж юу вэ? Kubernetes кластер дахь мастерууд ихэвчлэн бохирдол гэж нэрлэгддэг зүйлээр тэмдэглэгдсэн байдаг. Энэхүү "халдвар" -ын мөн чанар нь үндсэн зангилаанд хонхорцог хуваарилах боломжгүй гэсэн үг юм. Гэхдээ энэ нь "халдвар"-ыг тэсвэрлэдэг гэдгийг хэн ч ямар ч хонхорцог дээр зааж өгөхөөс санаа зовдоггүй. Хүлцэх хэсэг нь хэрэв зарим зангилаа NoSchedule-тэй бол манай зангилаа ийм халдварыг тэсвэрлэдэг бөгөөд ямар ч асуудал байхгүй гэж хэлдэг.
Цаашилбал, бидний доод хэсэг нь зөвхөн тэвчээртэй төдийгүй мастерийг тусгайлан чиглүүлэхийг хүсдэг гэж бид хэлдэг. Учир нь мастерууд бидэнд хэрэгтэй хамгийн амттай зүйл - бүх гэрчилгээтэй байдаг. Тиймээс бид nodeSelector гэж хэлдэг бөгөөд бид мастерууд дээр стандарт шошготой байдаг бөгөөд энэ нь кластерын бүх зангилаанаас яг мастер болохыг сонгох боломжийг олгодог.
Энэ хоёр секцээр тэр гарцаагүй мастерт ирнэ. Тэгээд тэр тэнд амьдрахыг зөвшөөрнө.
Гэхдээ зөвхөн мастер дээр ирэх нь бидний хувьд хангалтгүй юм. Энэ нь бидэнд юу ч өгөхгүй. Дараа нь бидэнд дараах хоёр зүйл байна:
hostNetwork: true
hostPID: true Бидний эхлүүлж буй pod нь цөмийн нэрийн талбар, сүлжээний нэрийн орон зай, PID нэрийн талбарт амьдрах болно гэдгийг бид зааж өгсөн. Мастер дээр подыг ажиллуулсны дараа энэ зангилааны бүх бодит, амьд интерфейсийг харж, бүх урсгалыг сонсож, бүх процессын PID-г харах боломжтой болно.
Тэгвэл жижиг сажиг зүйлсийн асуудал. etcd аваад хүссэнээ уншаарай.
Хамгийн сонирхолтой зүйл бол анхдагчаар тэнд байдаг Kubernetes функц юм.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Үүний мөн чанар нь бид энэ кластерын эрхгүй байсан ч гэсэн бид hostPath төрлийн эзлэхүүнийг бий болгохыг хүсч байгаа гэж хэлж болно. Энэ нь бидний эхлүүлэх хостоос замыг авч, түүнийг эзлэхүүн болгон авна гэсэн үг юм. Тэгээд бид үүнийг нэр гэж нэрлэдэг: хост. Бид энэ бүх hostPath-ийг pod дотор суулгадаг. Энэ жишээнд /host директор руу.
Би дахин давтан хэлье. Бид pod-д мастер дээр ирж, тэндээс hostNetwork болон hostPID-г авч, мастерын үндэсийг бүхэлд нь энэ pod дотор суулгаарай гэж хэлсэн.
Debian-д бид bash ажиллуулдаг бөгөөд энэ баш нь root дор ажилладаг гэдгийг та ойлгож байна. Өөрөөр хэлбэл, бид Кубернетес кластерт ямар ч эрх авалгүйгээр мастер дээр үндэслэв.
Дараа нь бүх даалгавар бол /host /etc/kubernetes/pki дэд лавлах руу очих, хэрэв би андуураагүй бол кластерын бүх мастер гэрчилгээг аваад, үүний дагуу кластерын администратор болох явдал юм.
Хэрэв та үүнийг ингэж харвал хэрэглэгч ямар эрхтэй байгаагаас үл хамааран эдгээр нь pods дээрх хамгийн аюултай эрхүүдийн зарим нь юм:
Хэрэв би кластерын зарим нэрийн талбарт pod ажиллуулах эрхтэй бол энэ pod нь анхдагч байдлаар эдгээр эрхтэй. Би давуу эрхтэй pods ажиллуулж чадна, эдгээр нь ерөнхийдөө зангилаа дээр үндэслэсэн бүх эрх юм.
Миний дуртай Root хэрэглэгч. Мөн Kubernetes-д энэ Run As non-Root сонголт байдаг. Энэ бол хакераас хамгаалах нэг төрөл юм. "Молдавын вирус" гэж юу болохыг та мэдэх үү? Хэрэв та гэнэт хакер болоод миний Kubernetes кластерт ирвэл хөөрхий администраторууд бид "Миний кластерийг хакердах гэж байгаа хэсэгтээ root бус байдлаар ажиллуулна уу. Үгүй бол та процессыг өөрийн pod-доо root дор ажиллуулж, намайг хакердах нь танд маш хялбар байх болно. Өөрөөсөө өөрийгөө хамгаалаарай."
Хост замын эзлэхүүн нь миний бодлоор Kubernetes кластераас хүссэн үр дүнд хүрэх хамгийн хурдан арга юм.
Гэхдээ энэ бүхнийг яах вэ?
Kubernetes-тэй тулгарсан аливаа энгийн администраторын толгойд орж ирэх бодол бол: "Тийм ээ, би чамд хэлсэн, Кубернетес ажиллахгүй байна. Үүнд нүхнүүд бий. Мөн Куб бүхэлдээ тэнэг юм." Уг нь бичиг баримт гэж нэг юм байдаг, тэндээс харвал нэг хэсэг байдаг .
Энэ бол yaml объект юм - бид үүнийг Kubernetes кластерт үүсгэж болно - энэ нь pods-ийн тайлбарт тусгайлан аюулгүй байдлын талыг хянадаг. Энэ нь үнэн хэрэгтээ энэ нь эхлүүлэх үед pods-д байгаа ямар ч hostNetwork, hostPID, зарим төрлийн эзлэхүүнийг ашиглах эрхийг хянадаг. Pod Security Policy-ийн тусламжтайгаар энэ бүхнийг тайлбарлаж болно.
Pod-ийн аюулгүй байдлын бодлогын хамгийн сонирхолтой зүйл бол Kubernetes кластерт бүх PSP суулгагчийг ямар ч байдлаар тайлбарлаагүй бөгөөд тэдгээрийг анхдагч байдлаар идэвхгүй болгосон явдал юм. Pod Security Policy нь элсэлтийн залгаасыг ашиглан идэвхжсэн.
За, Pod Security Policy-г кластерт оруулъя, бидний нэрийн талбарт зөвхөн админууд хандах боломжтой үйлчилгээний хэсэг байна гэж бодъё. Бусад бүх тохиолдолд хонхорхойнууд хязгаарлагдмал эрхтэй гэж үзье. Учир нь хөгжүүлэгчид таны кластерт давуу эрхтэй pods ажиллуулах шаардлагагүй байх магадлалтай.
Мөн бидний хувьд бүх зүйл сайхан байх шиг байна. Мөн манай Kubernetes кластерийг хоёр минутын дотор хакердах боломжгүй.
Асуудал байна. Хэрэв танд Kubernetes кластер байгаа бол хяналтыг таны кластер дээр суулгасан байх магадлалтай. Хэрэв танай кластер хяналттай бол түүнийг Прометей гэж нэрлэнэ гэж би таамаглах хүртэл явна.
Миний танд хэлэх гэж байгаа зүйл нь Prometheus оператор болон Prometheus-ийн аль алинд нь хүчинтэй байх болно. Асуулт нь хэрэв би админыг кластерт хурдан оруулж чадахгүй бол энэ нь би илүү их хайх хэрэгтэй гэсэн үг юм. Мөн би таны мониторингийн тусламжтайгаар хайлт хийж чадна.
Магадгүй хүн бүр Habré-ийн ижил нийтлэлүүдийг уншдаг бөгөөд мониторинг нь хяналтын нэрийн талбарт байрладаг. Helm диаграммыг хүн бүрт бараг адилхан гэж нэрлэдэг. Хэрэв та helm install stable/prometheus-ийг хийвэл бараг ижил нэртэй болно гэж би таамаглаж байна. Магадгүй би таны кластер дахь DNS нэрийг таах шаардлагагүй болно. Учир нь энэ нь стандарт юм.
Дараа нь бидэнд тодорхой pod ажиллуулж болох тодорхой dev ns байна. Дараа нь энэ хонхорцогоос иймэрхүү зүйлийг хийхэд маш хялбар байдаг:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics нь Kubernetes API-аас хэмжүүр цуглуулдаг Prometheus экспортлогчдын нэг юм. Таны кластерт юу ажиллаж байгаа, энэ нь юу вэ, танд ямар асуудал байгаа талаар маш олон өгөгдөл байна.
Энгийн жишээгээр:
kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,зураг=
"gcr.io/google-containers/kube-apiserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Давуу эрхгүй подноос энгийн curl хүсэлт хийснээр та дараах мэдээллийг авах боломжтой. Хэрэв та Kubernetes-ийн ямар хувилбарыг ажиллуулж байгаагаа мэдэхгүй байгаа бол энэ нь танд амархан хэлэх болно.
Хамгийн сонирхолтой нь та kube-state-meterics-д хандахаас гадна Prometheus-д шууд хандах боломжтой юм. Та тэндээс хэмжүүр цуглуулж болно. Та тэндээс хэмжүүрүүдийг ч байгуулж болно. Онолын хувьд ч гэсэн та Prometheus дахь кластераас ийм асуулга үүсгэж болох бөгөөд энэ нь зүгээр л унтраах болно. Мөн таны хяналт кластераас ажиллахаа бүрэн зогсоох болно.
Эндээс аливаа хөндлөнгийн хяналт таны хяналтыг хянадаг уу гэсэн асуулт гарч ирнэ. Би Кубернетес кластерт ямар ч үр дагаваргүйгээр ажиллах боломж оллоо. Ямар ч хяналт байхгүй тул та намайг тэнд ажиллаж байгааг мэдэхгүй байх болно.
Яг л PSP-ийн нэгэн адил Кубернетес, Прометей гэх мэт гоёмсог технологиуд нь ажиллахгүй, цоорхойгоор дүүрэн байдагт л асуудал байгаа юм шиг санагддаг. Үнэхээр биш.
Ийм зүйл байдаг - .
Хэрэв та жирийн админ бол Сүлжээний Бодлогын талаар та мэдэх байх, энэ бол зүгээр л өөр нэг ямл бөгөөд тэдгээрийн олонх нь кластерт байдаг. Мөн зарим Сүлжээний бодлого шаардлагагүй. Сүлжээний бодлого гэж юу болох, энэ нь Kubernetes-ийн yaml галт хана гэдгийг уншсан ч гэсэн энэ нь нэрийн орон зай, pods хоорондын хандалтын эрхийг хязгаарлах боломжийг олгодог, тэгвэл та Kubernetes дахь yaml форматын галт хана нь дараагийн хийсвэрлэл дээр үндэслэсэн гэж шийдсэн нь гарцаагүй. ... Үгүй үгүй . Энэ нь мэдээжийн хэрэг шаардлагагүй юм.
Та аюулгүй байдлын мэргэжилтнүүддээ Kubernetes-ээ ашигласнаар маш хялбар бөгөөд энгийн галт ханыг бий болгож чадна гэж хэлээгүй ч гэсэн маш нарийн ширхэгтэй галт хана бий болгож чадна. Хэрэв тэд үүнийг хараахан мэдээгүй бөгөөд танд төвөг учруулахгүй бол: "За, надад өгөөч, надад өгөөч ..." Дараа нь ямар ч тохиолдолд та өөрийн кластераас татах боломжтой зарим үйлчилгээний газруудад хандах хандалтыг хаахын тулд Сүлжээний бодлого хэрэгтэй. ямар ч зөвшөөрөлгүйгээр.
Миний өгсөн жишээн дээр та Kubernetes кластерын ямар ч нэрийн зайнаас кубын төлөвийн хэмжигдэхүүнийг ямар ч эрхгүйгээр татаж авах боломжтой. Сүлжээний бодлого нь бусад бүх нэрийн орон зайгаас хяналтын нэрийн орон зай руу нэвтрэх эрхийг хаасан бөгөөд энэ нь: хандалт байхгүй, асуудал байхгүй. Стандарт Prometheus болон Prometheus операторын аль алинд нь байгаа бүх диаграммд сүлжээний удирдамжийг идэвхжүүлэх сонголт байдаг. Та үүнийг асаахад л хангалттай бөгөөд тэд ажиллах болно.
Энд үнэхээр нэг асуудал байна. Жирийн сахалтай админ болохоор та сүлжээний бодлого хэрэггүй гэж шийдсэн байх. Хабр гэх мэт нөөцийн талаархи бүх төрлийн нийтлэлийг уншсаны дараа та фланел, ялангуяа хост-гарц горимтой бол таны сонгож болох хамгийн сайн зүйл гэж шийдсэн.
Би яах ёстой вэ?
Та өөрийн Kubernetes кластерт байгаа сүлжээний шийдлээ дахин байршуулж, илүү ажиллагаатай зүйлээр солихыг оролдож болно. Жишээлбэл, ижил Каликогийн хувьд. Гэхдээ Kubernetes-ийн ажлын кластер дахь сүлжээний шийдлийг өөрчлөх ажил бол маш энгийн зүйл биш гэдгийг би шууд хэлмээр байна. Би үүнийг хоёр удаа шийдсэн (хоёр удаа ч гэсэн онолын хувьд), гэхдээ бид үүнийг Slurms дээр хэрхэн хийхийг харуулсан. Оюутнууддаа бид Kubernetes кластерт сүлжээний шийдлийг хэрхэн өөрчлөхийг харуулсан. Зарчмын хувьд та үйлдвэрлэлийн кластер дээр ямар ч сул зогсолт байхгүй эсэхийг шалгахыг оролдож болно. Гэхдээ та амжилтанд хүрэхгүй байх магадлалтай.
Тэгээд асуудал үнэндээ маш энгийнээр шийдэгддэг. Кластерт гэрчилгээ байгаа бөгөөд таны гэрчилгээний хугацаа нэг жилийн дараа дуусна гэдгийг та мэднэ. За, ихэвчлэн кластерт гэрчилгээтэй ердийн шийдэл - бид яагаад санаа зовоод байгаа юм бэ, бид ойролцоох шинэ кластер босгож, хуучин нь ялзарч, бүх зүйлийг дахин байрлуулах болно. Энэ нь ялзарсан үед бид нэг өдөр суух хэрэгтэй болно, гэхдээ энд шинэ кластер байна.
Та шинэ кластер босгохдоо нэгэн зэрэг фланел биш харин Calico-г оруулаарай.
Хэрэв таны гэрчилгээ зуун жилийн хугацаатай олгогдвол кластерыг дахин байрлуулахгүй бол яах вэ? Kube-RBAC-Proxy гэх мэт зүйл байдаг. Энэ бол маш гайхалтай бүтээн байгуулалт бөгөөд энэ нь таныг Kubernetes кластерын аль ч подволк руу хажуугийн сав болгон суулгах боломжийг олгодог. Энэ нь үнэндээ Kubernetes-ийн RBAC-ээр дамжуулан энэ pod-д зөвшөөрлийг нэмдэг.
Нэг асуудал байна. Өмнө нь энэхүү Kube-RBAC-Proxy шийдлийг операторын Prometheus-д суулгасан. Гэвч дараа нь тэр алга болсон. Одоо орчин үеийн хувилбарууд нь таныг сүлжээний бодлоготой бөгөөд тэдгээрийг ашиглан хаадаг гэдэгт найдаж байна. Тиймээс бид графикийг бага зэрэг дахин бичих хэрэгтэй болно. Үнэндээ, хэрэв та очвол , үүнийг хажуугийн тэрэг болгон ашиглах жишээнүүд байдаг бөгөөд графикуудыг хамгийн бага хэмжээгээр дахин бичих шаардлагатай болно.
Бас нэг жижиг асуудал байна. Прометей хэмжүүрээ хэн нэгэнд түгээдэг цорын ганц хүн биш юм. Манай бүх Kubernetes кластер бүрэлдэхүүн хэсгүүд нь мөн өөрсдийн хэмжүүрийг буцаах боломжтой.
Гэхдээ би аль хэдийн хэлсэнчлэн, хэрэв та кластерт нэвтэрч, мэдээлэл цуглуулж чадахгүй бол ядаж хор хөнөөл учруулж болно.
Тиймээс би Кубернетес кластерыг хэрхэн сүйтгэх хоёр аргыг хурдан харуулах болно.
Үүнийг хэлэхэд та инээх болно, энэ бол бодит амьдрал дээрх хоёр тохиолдол юм.
Нэгдүгээр арга. Нөөцийн хомсдол.
Өөр нэг тусгай pod ажиллуулцгаая. Энэ нь иймэрхүү хэсэгтэй байх болно.
resources:
requests:
cpu: 4
memory: 4Gi Таны мэдэж байгаагаар хүсэлт гэдэг нь хүсэлт бүхий тодорхой pods-д зориулж хост дээр хадгалагдсан CPU болон санах ойн хэмжээ юм. Хэрэв бид Kubernetes кластерт дөрвөн цөмт хосттой бөгөөд дөрвөн CPU-ийн pod нь хүсэлтээр ирдэг бол энэ хост руу дахин хүсэлт бүхий pods ирэх боломжгүй болно гэсэн үг юм.
Хэрэв би ийм pod ажиллуулвал дараах тушаалыг ажиллуулна:
$ kubectl scale special-pod --replicas=...Дараа нь өөр хэн ч Kubernetes кластерт байршуулах боломжгүй болно. Учир нь бүх зангилааны хүсэлтүүд дуусах болно. Тиймээс би таны Kubernetes кластерийг зогсоох болно. Хэрэв би үүнийг орой хийвэл байршуулалтыг нэлээд удаан зогсоож чадна.
Хэрэв бид Kubernetes баримт бичгийг дахин харвал Limit Range хэмээх энэ зүйлийг харах болно. Энэ нь кластерын объектуудын нөөцийг тогтоодог. Та Limit Range объектыг yaml-д бичиж, тодорхой нэрийн талбарт хэрэглэж болно - дараа нь энэ нэрийн талбарт та pods-ийн анхдагч, хамгийн их, хамгийн бага нөөцтэй гэж хэлж болно.
Ийм зүйлийн тусламжтайгаар бид багуудын тодорхой бүтээгдэхүүний нэрсийн орон зайд байгаа хэрэглэгчдийг бүх төрлийн муу муухай зүйлийг тус тусад нь зааж өгөх боломжийг хязгаарлаж чадна. Гэвч харамсалтай нь, та хэрэглэгчдэд нэгээс олон CPU-ийн хүсэлт бүхий pods ажиллуулж чадахгүй гэж хэлсэн ч гэсэн ийм гайхалтай масштабтай команд байдаг эсвэл тэд хяналтын самбараар дамжуулан масштаблах боломжтой.
Хоёрдугаар арга нь эндээс гаралтай. Бид 11 ширхэгийг үйлдвэрлэж байна. Энэ нь арван нэгэн тэрбум гэсэн үг. Би ийм тоог гаргаж ирснийхээ төлөө биш, өөрөө харсан болохоор тэр.
Бодит түүх. Орой болж оффисоос гарах гэж байлаа. Хэсэг хөгжүүлэгчид буланд суугаад зөөврийн компьютерээрээ ямар нэгэн зүйл хийж байхыг би харж байна. Би залуус дээр очоод: "Чамд юу тохиолдсон бэ?" Гэж асуув.
Хэсэг хугацааны өмнө, оройн есөн цагийн орчимд хөгжүүлэгчдийн нэг нь гэртээ харихаар бэлдэж байв. Тэгээд би: "Би одоо өргөдлөө нэг болгон бууруулна" гэж шийдсэн. Нэгийг нь дарсан ч интернет бага зэрэг удааширсан. Тэр нэгийг нь дахин дарж, нэгийг нь дараад Enter дарна. Би чадах бүхнээ нударлаа. Дараа нь Интернет амьдрал болж, бүх зүйл энэ тоо хүртэл буурч эхлэв.
Энэ түүх Кубернетес дээр болоогүй нь үнэн, тэр үед энэ нь Номад байсан. Бид Номадыг цар хүрээг нэмэгдүүлэх гэсэн тууштай оролдлогыг зогсоох гэсэн нэг цагийн оролдлогын дараа Номад масштаблахаа зогсоохгүй, өөр юу ч хийхгүй гэж хариулсанаар энэ нь дууссан. "Би ядарч байна, би явлаа." Тэгээд тэр бөхийв.
Мэдээжийн хэрэг, би Kubernetes дээр ижил зүйлийг хийхийг оролдсон. Кубернетес арван нэгэн тэрбум хонхорхойд сэтгэл хангалуун бус байсан тул "Би чадахгүй. Дотор амны хамгаалалтаас давсан." Гэхдээ 1 хонхорхой болно.
Нэг тэрбумын хариуд Куб өөрөө өөртөө татсангүй. Тэр үнэхээр томруулж эхлэв. Энэ үйл явц цааш үргэлжлэх тусам түүнд шинэ хонхорцог бий болгоход илүү их цаг зарцуулсан. Гэвч үйл явц үргэлжилсээр л. Цорын ганц асуудал бол хэрэв би өөрийн нэрийн талбарт pod-уудыг хязгааргүй ажиллуулж чадвал ямар ч хүсэлт, хязгаарлалтгүйгээр би зарим даалгавар бүхий маш олон pods ажиллуулж чадах бөгөөд эдгээр даалгаврын тусламжтайгаар зангилаанууд санах ой, CPU-д нэмэгдэж эхэлнэ. Би маш олон pod ажиллуулахад тэдгээрээс авсан мэдээлэл нь хадгалах санд, өөрөөр хэлбэл гэх мэт зүйлд орох ёстой. Хэт их мэдээлэл ирэхэд хадгалалт хэтэрхий удаан буцаж эхэлдэг бөгөөд Кубернетес уйтгартай болж эхэлдэг.
Бас нэг асуудал... Та бүхний мэдэж байгаагаар Kubernetes хяналтын элементүүд нь нэг гол зүйл биш, харин хэд хэдэн бүрэлдэхүүн хэсэг юм. Ялангуяа хянагч менежер, төлөвлөгч гэх мэт. Эдгээр бүх залуус нэгэн зэрэг шаардлагагүй, тэнэг ажлыг хийж эхлэх бөгөөд энэ нь цаг хугацаа өнгөрөх тусам улам их цаг хугацаа шаардаж эхэлнэ. Хянагчийн менежер шинэ pods үүсгэх болно. Хуваарьлагч нь тэдэнд зориулж шинэ зангилаа олохыг хичээх болно. Удахгүй таны кластерт шинэ зангилаа дуусах магадлалтай. Kubernetes кластер удаан, удаан ажиллаж эхэлнэ.
Гэхдээ би цаашаа явахаар шийдсэн. Та бүхний мэдэж байгаагаар Кубернетес хотод үйлчилгээ гэж нэрлэгддэг ийм зүйл байдаг. Таны кластеруудад анхдагч байдлаар үйлчилгээ нь IP хүснэгтүүдийг ашиглан ажилладаг байх магадлалтай.
Жишээлбэл, хэрэв та нэг тэрбум pod ажиллуулж, дараа нь Kubernetis-ыг шинэ үйлчилгээ үүсгэхийг албадахын тулд скрипт ашиглавал:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Кластерын бүх зангилаанууд дээр илүү олон шинэ iptables дүрмийг ойролцоогоор нэгэн зэрэг үүсгэх болно. Түүнчлэн үйлчилгээ тус бүрт нэг тэрбум iptables дүрэм бий болно.
Би энэ бүх зүйлийг хэдэн мянгаараа, арав хүртэл шалгасан. Асуудал нь энэ босго дээр аль хэдийн зангилаа руу ssh хийх нь нэлээд асуудалтай байдаг. Учир нь пакетууд маш олон гинжээр дамжин өнгөрөхөд тийм ч сайн биш санагдаж эхэлдэг.
Мөн энэ бүхэн Кубернетесийн тусламжтайгаар шийдэгддэг. Ийм нөөцийн квотын объект байдаг. Кластер дахь нэрийн зайд ашиглах боломжтой нөөц болон объектын тоог тохируулна. Бид Kubernetes кластерын нэрийн талбар бүрт yaml объект үүсгэж болно. Энэ объектыг ашигласнаар бид энэ нэрийн талбарт тодорхой тооны хүсэлт, хязгаарлалтыг хуваарилсан гэж хэлж болно, дараа нь энэ нэрийн талбарт 10 үйлчилгээ, 10 pods үүсгэх боломжтой гэж хэлж болно. Мөн ганц хөгжүүлэгч орой ядаж өөрийгөө боомилчихдог. Кубернетес түүнд: "Нөөц нь квотоос хэтэрсэн тул та ийм хэмжээний хонхорцог хийж чадахгүй" гэж хэлэх болно. Ингээд л асуудал шийдэгдлээ. .
Үүнтэй холбоотойгоор нэг асуудал гарч ирж байна. Kubernetes-д нэрийн орон зай үүсгэх нь хичнээн хэцүү болж байгааг та мэдэрч байна. Үүнийг бий болгохын тулд бид маш олон зүйлийг анхаарч үзэх хэрэгтэй.
Нөөцийн квот + Хязгаарлалтын хүрээ + RBAC
• Нэрийн орон зай үүсгэх
• Дотор хязгаарыг бий болгох
• Дотоод нөөцийн квот үүсгэх
• CI-д үйлчилгээний данс үүсгэх
• CI болон хэрэглэгчдэд зориулсан үүрэг даалгавар үүсгэх
• Сонголтоор шаардлагатай үйлчилгээний хэсгүүдийг ажиллуулна
Тиймээс энэ завшааныг ашиглан өөрийн хийсэн бүтээн байгуулалтаа хуваалцахыг хүсч байна. SDK оператор гэж ийм зүйл байдаг. Энэ бол Кубернетес кластерт оператор бичих арга юм. Та Ansible ашиглан мэдэгдэл бичиж болно.
Эхлээд Ansible дээр биччихсэн байсан, дараа нь SDK оператор байгааг хараад Ansible-ийн дүрийг оператор болгон дахин бичсэн. Энэ мэдэгдэл нь Kubernetes кластерт команд гэж нэрлэгддэг объект үүсгэх боломжийг танд олгоно. Команд дотор энэ командын орчныг yaml хэлээр дүрслэх боломжийг танд олгоно. Багийн орчинд бид маш их нөөцийг хуваарилж байгааг тайлбарлах боломжийг олгодог.
Бяцхан .
Тэгээд дүгнэж хэлэхэд. Энэ бүхнийг яах вэ?
Эхлээд. Pod аюулгүй байдлын бодлого сайн байна. Kubernetes-ийн суулгагчдын хэн нь ч эдгээрийг өнөөдрийг хүртэл ашиглаагүй байгаа ч та тэдгээрийг кластертаа ашиглах шаардлагатай хэвээр байна.
Сүлжээний бодлого бол зүгээр нэг шаардлагагүй функц биш юм. Энэ бол кластерт үнэхээр хэрэгтэй зүйл юм.
LimitRange/ResourceQuota - үүнийг ашиглах цаг болжээ. Бид үүнийг эрт дээр үеэс хэрэглэж эхэлсэн бөгөөд удаан хугацааны туршид хүн бүр үүнийг ашиглаж байгаа гэдэгт итгэлтэй байсан. Энэ нь ховор болох нь тогтоогдсон.
Тайлангийн үеэр миний дурдсан зүйлээс гадна кластер руу довтлох боломжийг олгодог баримтжуулаагүй функцууд байдаг. Саяхан гарсан .
Зарим зүйл үнэхээр гунигтай бас гомдоодог. Жишээлбэл, тодорхой нөхцөлд Kubernetes кластер дахь кубууд нь зөвшөөрөлгүй хэрэглэгчдэд warlocks лавлахын агуулгыг өгч болно.
Миний хэлсэн бүх зүйлийг хэрхэн хуулбарлах заавар байдаг. ResourceQuota болон Pod Security Policy ямар харагдахыг харуулсан үйлдвэрлэлийн жишээ бүхий файлууд байна. Мөн та энэ бүхэнд хүрч болно.
Та нарт бүгдэнд нь баярлалаа.
Эх сурвалж: www.habr.com