Павел Селиванов, Southbridge чечимдеринин архитектору жана Slurm мугалими, DevOpsConf 2019да презентация жасады. Бул баяндама Kubernetes "Slurm Mega" боюнча тереңдетилген курстун темаларынын бир бөлүгү болуп саналат.
18—20-ноябрда Москвада болот.
— Москва, 22—24-ноябрь.
ар дайым мүмкүн.
Кесиптин астында баяндаманын стенограммасы бар.
Кутмандуу күн, кесиптештер жана аларга боор ооругандар. Бүгүн мен коопсуздук жөнүндө сүйлөшөм.
Карасам, бүгүн залда күзөтчүлөр көп. Эгер мен коопсуздук дүйнөсүндөгү терминдерди сиз үчүн адаттагыдай эмес колдонсом, сизден алдын ала кечирим сурайм.
Болжол менен алты ай мурун мен бир коомдук Kubernetes кластерин кезиктирдим. Коомдук аттар мейкиндигинин n-саны бар экенин билдирет; бул аттар мейкиндигинде алардын аттар мейкиндигинде обочолонгон колдонуучулар бар. Бул колдонуучулардын баары ар кандай компанияларга таандык. Ооба, бул кластер CDN катары колдонулушу керек деп болжолдонгон. Башкача айтканда, алар сизге кластерди беришет, алар сизге ошол жерде колдонуучуну беришет, сиз ал жакка өзүңүздүн аттар мейкиндигине барасыз, фронтторуңузду жайылтасыз.
Менин мурунку компаниям ушундай кызматты сатууга аракет кылган. Жана менден бул чечим ылайыктуу же туура эмес экенин билүү үчүн кластерди тешүүнү суранышты.
Мен бул кластерге келдим. Мага чектелген укуктар, чектелген ат мейкиндиги берилди. Ал жердеги балдар коопсуздук эмне экенин түшүнүштү. Алар Kubernetesтеги ролго негизделген кирүү башкаруусу (RBAC) жөнүндө окушту - жана алар мен подкасттарды жайгаштыруудан өзүнчө иштете албай тургандай кылып бурушту. Мен жайгаштыруу жок подключканы ишке киргизүү менен чечүүгө аракет кылган көйгөй эсимде жок, бирок мен чындап эле подводду ишке киргизгим келди. Ийгилик үчүн, мен кластерде кандай укуктарым бар, эмне кыла алам, эмне кыла албайм жана алар ал жерде эмнелерди бузушканын көрүүнү чечтим. Ошол эле учурда, мен сизге RBACда туура эмес конфигурацияланганын айтып берем.
Ошентип, эки мүнөттүн ичинде мен алардын кластерине администраторду кабыл алдым, бардык кошуна аттар мейкиндигин карап, ал жерде буга чейин кызматты сатып алган жана орноткон компаниялардын иштеп жаткан өндүрүш фронтторун көрдүм. Эптеп бирөөнүн алдына барып, башкы бетке сөгүнгөн сөздөрдү жазып өзүмдү араң токтоттум.
Мен муну кантип кылганымды жана мындан кантип коргонууну мисалдар менен айтып берем.
Бирок адегенде өзүмдү тааныштырып кетейин. Менин атым Павел Селиванов. Мен Саутбриджде архитектормун. Мен Kubernetes, DevOps жана ар кандай кооз нерселерди түшүнөм. Түштүк көпүрөнүн инженерлери экөөбүз мунун баарын куруп жатабыз, мен кеңешип жатабыз.
Негизги иш-чараларыбыздан тышкары, биз жакында Slurms деп аталган долбоорлорду ишке киргиздик. Биз Kubernetes менен иштөө жөндөмүбүздү бир аз массага жеткирүүгө, башка адамдарды да K8s менен иштөөгө үйрөтүүгө аракет кылып жатабыз.
Мен бүгүн эмне жөнүндө сүйлөшөм? Отчеттун темасы ачык - Kubernetes кластеринин коопсуздугу жөнүндө. Бирок мен бул тема абдан чоң экенин дароо айткым келет - ошондуктан мен эмне жөнүндө сөз кылбай турганымды дароо тактагым келет. Интернетте буга чейин жүз жолу колдонулган бузуку терминдер жөнүндө айтпай эле коёюн. RBAC жана сертификаттардын бардык түрлөрү.
Мен Kubernetes кластериндеги коопсуздук жөнүндө мени жана менин кесиптештеримди кыйнаган нерселер жөнүндө сүйлөшөм. Биз бул көйгөйлөрдү Kubernetes кластерлерин камсыз кылган провайдерлерден да, бизге келген кардарлардан да көрөбүз. Ал тургай, бизге башка консалтингдик админ компаниялардан келген кардарлардан. Башкача айтканда, трагедиянын масштабы чындыгында абдан чоң.
Мен бүгүн сүйлөшө турган үч пункт бар:
- Колдонуучунун укуктары vs pod укуктарын. Колдонуучунун укуктары менен подъезддин укуктары бир эле нерсе эмес.
- Кластер жөнүндө маалымат чогултуу. Мен бул кластерде атайын укуктарга ээ болбостон, кластерден керектүү маалыматтын баарын чогулта аларыңызды көрсөтөм.
- кластерге DoS чабуулу. Эгерде биз маалымат чогулта албасак, анда биз кластерди каалаган учурда кое алабыз. Мен кластердик башкаруу элементтерине DoS чабуулдары жөнүндө сүйлөшөм.
Мен айтып кете турган дагы бир жалпы нерсе, мен мунун бардыгын сынап көрдүм, мен мунун баары иштейт деп айта алам.
Биз негиз катары Kubespray аркылуу Kubernetes кластерин орнотууну алабыз. Эгер кимдир бирөө билбесе, бул чындыгында Ansible үчүн ролдордун жыйындысы. Аны ишибизде тынымсыз колдонобуз. Жакшы жери, сиз аны каалаган жерден тоголоктоп алсаңыз болот - аны темир кесимдерге же бир жерде булутка тоголоктоп аласыз. Бир орнотуу ыкмасы принцибинде бардыгы үчүн иштейт.
Бул кластерде менде Kubernetes v1.14.5 болот. Биз карап чыга турган бүт Cube кластери аттар мейкиндигине бөлүнгөн, ар бир аттар мейкиндиги өзүнчө командага таандык жана бул команданын мүчөлөрү ар бир аттар мейкиндигине кире алышат. Алар ар кандай аталыш мейкиндигине бара алышпайт, өздөрүнө гана. Бирок бүткүл кластерге укугу бар белгилүү бир администратор эсеби бар.
Мен биринчи кезекте кластерге администратордук укуктарды алабыз деп убада бердим. Бизге Kubernetes кластерин талкалай турган атайын даярдалган поддон керек. Бизге керек болгон нерсе - аны Kubernetes кластерине колдонуу.
kubectl apply -f pod.yamlБул кабык 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 Биз ишке киргизген поддонубуз ядронун аттар мейкиндигинде, тармактын аттар мейкиндигинде жана PID аттар мейкиндигинде жашай турганын белгилейбиз. Кожоюнда подряд ишке киргизилгенден кийин, ал бул түйүндүн бардык реалдуу, жандуу интерфейстерин көрө алат, бардык трафикти уга алат жана бардык процесстердин PIDди көрө алат.
Анан майда-чүйдө нерселерге байланыштуу. etcd алып, каалаганыңызды окуңуз.
Эң кызыгы - бул Kubernetes өзгөчөлүгү, ал жерде демейки боюнча бар.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Ал эми анын маңызы - биз бул кластерге укуктарыбыз жок болсо дагы, биз hostPath типтеги көлөмдү түзгүбүз келет деп ишке киргизебиз деп айта алабыз. Бул биз ишке киргизе турган хосттон жолду алуу жана аны көлөм катары кабыл алуу дегенди билдирет. Анан биз аны ат деп атайбыз: хост. Бул hostPathтин баарын поддондун ичине орнотобуз. Бул мисалда, /хост каталогуна.
Мен дагы кайталайм. Биз поддонго мастерге келүүнү, ошол жерден hostNetwork жана hostPID алуусун айттык жана мастердин бүт тамырын ушул поддондун ичине орнотуңуз.
Дебианда бизде bash иштеп жатканын түшүнөсүз жана бул баш тамырдын астында иштейт. Башкача айтканда, биз Kubernetes кластеринде эч кандай укуктарга ээ болбостон, мастерде тамыр алдык.
Андан кийин бардык тапшырма /host /etc/kubernetes/pki подкаталогуна өтүү, эгер жаңылбасам, кластердин бардык мастер сертификаттарын ал жерден алып, ошого жараша кластердин администратору бол.
Эгер сиз муну мындай карасаңыз, бул колдонуучунун кандай укуктары бар экенине карабастан, подкасттардагы эң коркунучтуу укуктардын айрымдары:
Эгерде менде кластердин кээ бир аттар мейкиндигинде поддонду иштетүүгө укугум бар болсо, анда бул поддон демейки боюнча бул укуктарга ээ. Мен артыкчылыктуу подкасттарды иштете алам, булар негизинен түйүндө түп тамыры болгон бардык укуктар.
Менин сүйүктүү Root колдонуучу. Жана Kubernetes бул Run Non-Root опциясына ээ. Бул хакерлерден коргоонун бир түрү. “Молдавия вирусу” эмне экенин билесизби? Эгер сиз күтүлбөгөн жерден хакер болуп, менин Kubernetes кластериме келип калсаңыз, анда биз, начар администраторлор, сурайбыз: “Сураныч, менин кластеримди бузуп, тамыр эмес катары иштетиңиз. Болбосо, сиз процессти өзүңүздүн подъездиңизде root астында иштетип, мени бузуп алуу абдан оңой болот. Өзүңдү өзүңдөн сакта."
Хост жолунун көлөмү, менин оюмча, Kubernetes кластеринен каалаган натыйжаны алуунун эң тез жолу.
Бирок мунун баарын эмне кылуу керек?
Kubernetes менен жолуккан ар бир кадимки администраторго мындай ой келет: "Ооба, мен сага айттым, Kubernetes иштебейт. Анын ичинде тешиктер бар. Ал эми бүт Куб – шылдың». Негизи документация деген бар, карасаң бөлүм бар .
Бул yaml объекти - биз аны Kubernetes кластеринде түзө алабыз - ал коопсуздук аспектилерин атайын поддондордун сүрөттөмөсүндө көзөмөлдөйт. Башкача айтканда, чындыгында, ал ишке киргизүүдө поддондордо турган ар кандай hostNetwork, hostPID, белгилүү бир көлөм түрлөрүн колдонуу укуктарын көзөмөлдөйт. Pod Security Policy жардамы менен мунун баарын сүрөттөсө болот.
Pod коопсуздук саясаты жөнүндө эң кызыктуу нерсе, Kubernetes кластеринде бардык PSP орнотуучулары эч кандай сүрөттөлбөйт, алар жөн гана демейки боюнча өчүрүлгөн. Pod Коопсуздук саясаты кабыл алуу плагини аркылуу иштетилген.
Макул, келгиле, Pod Коопсуздук саясатын кластерге жайгаштыралы, келгиле, аттар мейкиндигинде администраторлор гана кире алган кээ бир кызмат подколорубуз бар дейли. Айталы, башка бардык учурларда, порошоктун укуктары чектелген. Себеби, иштеп чыгуучуларга кластериңизде артыкчылыктуу подтексттерди иштетүүнүн кереги жок.
Анан бизде баары жакшы окшойт. Биздин Kubernetes кластерин эки мүнөттө бузуп салуу мүмкүн эмес.
Маселе бар. Кыязы, эгер сизде Kubernetes кластери болсо, анда кластериңизге мониторинг орнотулган. Мен ал тургай, эгерде сиздин кластериңизде мониторинг болсо, ал Прометей деп аталат деп алдын ала айткым келет.
Мен сизге айта турган нерсе Прометей оператору үчүн да, анын таза түрүндө жеткирилген Прометей үчүн да жарактуу болот. Суроо, эгерде мен кластерге администраторду мынчалык тез киргизе албасам, анда бул мен көбүрөөк издешим керек дегенди билдирет. Жана мен сиздин мониторингиңиздин жардамы менен издей алам.
Кыязы, баары Habré боюнча бир эле макалаларды окуп, мониторинг мониторинг аттар мейкиндигинде жайгашкан. Руль диаграммасы бардыгы үчүн бирдей деп аталат. Менимче, эгер сиз стабилдүү/прометейди орнотуп алсаңыз, болжол менен ошол эле аттарга ээ болосуз. Жана балким, мен сиздин кластериңиздеги DNS атын болжолдоого да туура келбейт. Анткени ал стандарттуу.
Андан кийин бизде белгилүү бир иштеп чыгуучу 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″,контейнер=”kube-apiserver”,image=
"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
Артыкчылыксыз поддондон жөнөкөй тармал суроо менен сиз төмөнкү маалыматты ала аласыз. Эгер сиз Kubernetesтин кайсы версиясын иштетип жатканыңызды билбесеңиз, ал сизге оңой айтып берет.
Эң кызыгы, kube-state-метрикага кирүүдөн тышкары, сиз Prometheusтун өзүнө түздөн-түз кире аласыз. Сиз ошол жерден көрсөткүчтөрдү чогулта аласыз. Ал жерден метрикаларды кура аласыз. Теориялык жактан да, сиз Прометейдеги кластерден мындай суроону түзө аласыз, ал аны жөн эле өчүрөт. Жана сиздин мониторингиңиз кластерден таптакыр иштебей калат.
Бул жерде кандайдыр бир тышкы мониторинг сиздин мониторингиңизди көзөмөлдөйбү деген суроо туулат. Мен Kubernetes кластеринде эч кандай кесепеттери жок иштөө мүмкүнчүлүгүнө ээ болдум. Сиз менин ал жерде иштеп жатканымды билбей каласыз, анткени мониторинг жок.
PSP сыяктуу эле, көйгөй мына ушундай сезилет: бардык бул кооз технологиялар - Кубернетес, Прометей - алар иштебейт жана тешиктерге толгон. Жок эле.
Мындай нерсе бар - .
Эгер сиз кадимки администратор болсоңуз, анда сиз Тармак саясаты жөнүндө билесиз, балким, бул дагы бир ямл, алардын кластерде көптөрү бар. Жана кээ бир Тармак саясаттары сөзсүз керек эмес. Тармак саясаты деген эмне экенин, ал Kubernetesтин ямл брандмауэри экенин окусаңыз да, ал аттар мейкиндиктери, подколор ортосундагы кирүү укуктарын чектөөгө мүмкүндүк берет, анда сиз албетте Kubernetesтеги yaml форматындагы брандмауэр кийинки абстракцияларга негизделген деп чечтиңиз. ... Жок, жок. Бул, албетте, зарыл эмес.
Эгер сиз коопсуздук адистериңизге Kubernetes'иңизди колдонуу менен абдан оңой жана жөнөкөй брандмауэрди жана өтө майдаланган брандмауэрди кура аларыңызды айтпасаңыз да. Эгер алар муну али билишпесе жана сизди убара кылбаса: “Макул, мага бер, мага бер...” Анда кандай болгон күндө да, кластериңизден алынышы мүмкүн болгон кээ бир тейлөө жерлерине кирүүгө бөгөт коюу үчүн тармак саясаты керек. эч кандай уруксаты жок.
Мен келтирген мисалдагыдай, сиз Кубернетес кластериндеги каалаган аттар мейкиндигинен куб абалынын көрсөткүчтөрүн эч кандай укугусуз тарта аласыз. Тармак саясаттары башка бардык аттар мейкиндигинен мониторингдин аталыш мейкиндигине жабык кирүү мүмкүнчүлүгүнө ээ жана ушуну менен бүттү: мүмкүндүк жок, көйгөйлөр жок. Бар болгон бардык диаграммаларда, стандарттуу Prometheus да, оператордогу Prometheus да, алар үчүн тармак саясатын иштетүү үчүн рул баалуулуктарында жөн гана параметр бар. Сиз жөн гана аны күйгүзүү керек жана алар иштейт.
Бул жерде чындап эле бир көйгөй бар. Кадимки сакалчан администратор болгондуктан, сиз тармактык саясаттын кереги жок деп чечкенсиз. Хабр сыяктуу ресурстар боюнча ар кандай макалаларды окугандан кийин, сиз фланель, айрыкча хост-шлюз режими менен, сиз тандай турган эң жакшы нерсе деп чечтиңиз.
Эмне кылуу керек?
Сиз Kubernetes кластериңизде болгон тармактык чечимди кайра жайгаштырууга аракет кылсаңыз болот, аны көбүрөөк функционалдык нерсе менен алмаштырууга аракет кылыңыз. Мисалы, ошол эле Калико үчүн. Бирок мен дароо айткым келет, Kubernetes жумушчу кластериндеги тармактык чечимди өзгөртүү милдети өтө маанилүү эмес. Мен аны эки жолу чечтим (эки жолу тең теориялык жактан), бирок биз муну Slurmsта кантип көрсөттүк. Биздин студенттер үчүн биз Kubernetes кластериндеги тармактык чечимди кантип өзгөртүү керектигин көрсөттүк. Негизи өндүрүш кластеринде токтоп калуулар жок экенине ынанууга аракет кылсаңыз болот. Бирок, балким, ийгиликке жетпейт.
Ал эми маселе чындыгында абдан жөнөкөй чечилет. Кластерде сертификаттар бар, сертификаттарыңыздын мөөнөтү бир жылдан кийин бүтөөрүн билесиз. Ооба, адатта, кластердеги сертификаттары бар кадимки чечим - биз эмне үчүн тынчсызданып жатабыз, биз жакын жерде жаңы кластер түзүп, эскисин чирип, баарын кайра жайгаштырабыз. Ырас, ал чирип кеткенде, биз бир күн отурушубуз керек, бирок бул жерде жаңы кластер.
Жаңы кластерди көтөргөндө, ошол эле учурда фланелдин ордуна Calico салыңыз.
Эгерде сиздин сертификаттарыңыз жүз жылга берилип, кластерди кайра жайгаштырбай жатсаңыз, эмне кылуу керек? Kube-RBAC-Proxy деген нерсе бар. Бул абдан сонун иштеп чыгуу, ал сизди Kubernetes кластериндеги каалаган подъездге каптал контейнер катары киргизүүгө мүмкүндүк берет. Ал чындыгында Kubernetes'тин RBAC аркылуу бул подкастка авторизацияны кошот.
Бир көйгөй бар. Буга чейин бул Kube-RBAC-Proxy чечими оператордун Prometheus программасына курулган. Бирок андан кийин ал жок болду. Азыр заманбап версиялар сиздин тармактык саясатыңыз бар экенине таянып, аларды колдонуу менен жаап салышат. Ошентип, диаграмманы бир аз кайра жазууга туура келет. Чынында, эгер барсаң , муну каптал катары колдонуунун мисалдары бар жана диаграммалар минималдуу түрдө кайра жазылууга тийиш.
Дагы бир кичинекей көйгөй бар. Прометей өзүнүн метрикасын кимдир бирөөлөргө тараткан жалгыз адам эмес. Биздин бардык Kubernetes кластердик компоненттери дагы өздөрүнүн метрикасын кайтара алышат.
Бирок мен буга чейин айткандай, кластерге кире албасаңыз жана маалымат чогулта албасаңыз, анда сиз жок дегенде зыян келтире аласыз.
Ошентип, мен тез арада Kubernetes кластерин кантип жок кылуунун эки жолун көрсөтөм.
Мен муну айтсам күлөсүң, бул эки реалдуу окуя.
Биринчи ыкма. Ресурстун түгөнүп калышы.
Келгиле, дагы бир өзгөчө подводду ишке киргизели. Анда ушундай бөлүм болот.
resources:
requests:
cpu: 4
memory: 4Gi Белгилүү болгондой, суроо-талаптар - бул суроо-талаптары бар белгилүү подколор үчүн хостто сакталган CPU жана эс тутумдун көлөмү. Эгерде бизде Kubernetes кластеринде төрт өзөктүү хостубуз болсо жана ал жерге төрт CPU поддондору сурамдар менен келсе, анда бул хостко суроо-талаптары бар бир дагы подряд келе албайт дегенди билдирет.
Эгерде мен мындай подкукту иштетсем, анда мен буйрукту аткарам:
$ kubectl scale special-pod --replicas=...Ошондо башка эч ким Kubernetes кластерине жайгаштыра албайт. Анткени бардык түйүндөрдүн суроо-талаптары түгөнүп калат. Ошентип, мен сиздин Kubernetes кластерин токтотом. Эгер мен муну кечинде жасасам, жайгаштырууларды көпкө токтото алам.
Эгерде биз Kubernetes документтерин дагы бир жолу карасак, биз Limit Range деп аталган нерсени көрөбүз. Ал кластердик объекттер үчүн ресурстарды орнотот. Yaml менен Limit Range объектисин жазып, аны белгилүү бир аттар мейкиндигине колдоно аласыз - анан бул аттар мейкиндигинде сизде подколор үчүн демейки, максималдуу жана минималдуу ресурстар бар деп айта аласыз.
Мындай нерсенин жардамы менен биз колдонуучуларды командалардын белгилүү өнүмдөрүнүн аталыштары менен чектей алабыз. Бирок, тилекке каршы, сиз колдонуучуга бирден ашык CPU үчүн суроо-талаптар менен подкачкаларды ишке киргизе албасыңызды айтсаңыз да, мындай сонун масштабдуу буйрук бар же алар башкаруу панели аркылуу масштабды жасай алышат.
Мына ушул жерден экинчи ыкма келип чыгат. Биз 11 породаны чыгарабыз. Бул он бир миллиард. Мындай санды ойлоп тапканым үчүн эмес, өзүм көргөндүктөн.
Чыныгы окуя. Кечке жуук кеңседен чыгайын деп жаттым. Мен бурчта отурган иштеп чыгуучулардын тобун көрүп, ноутбуктары менен бир нерсе кылып жатышат. Мен балдарга барып: -Сага эмне болду?
Бир аз мурда, кечки тогуздар чамасында иштеп чыгуучулардын бири үйүнө кетүүгө камданып жаткан. Анан мен чечтим: "Мен азыр арызымды бирге чейин азайтам." Бирин бастым, бирок интернет бир аз жайлады. Кайра бирин басты, бирин басты, анан Enter баскычын басты. Колумдан келгендин баарын тыйдым. Андан кийин Интернет жанданды - жана баары ушул санга чейин кыскара баштады.
Ырас, бул окуя Кубернетеде болгон эмес, ал кезде Көчмөн болчу. Бул бир сааттык биздин Nomadды тынымсыз масштабдуу аракеттерден токтотуу аракетибизден кийин, Nomad масштабын токтотпойм жана башка эч нерсе кылбайм деп жооп бергени менен аяктады. – Чарчадым, кетем. Анан ал ийилип калды.
Албетте, мен Kubernetesте да ушундай кылууга аракет кылдым. Кубернетес он бир миллиард бакка ыраазы болгон жок, ал: «Мен кыла албайм. Ички ооз коргоочулардан ашып кетет». Бирок 1 000 000 000 порода мүмкүн.
Бир миллиардга жооп кылып, Куб өзүнө ыктаган жок. Ал чынында эле масштабдуу баштады. Процесс канчалык ары барса, ага жаңы поддондорду түзүү үчүн ошончолук көп убакыт талап кылынды. Бирок дагы эле процесс улана берди. Бир гана көйгөй, эгерде мен өзүмдүн аттар мейкиндигимде чексиз подкасттарды ишке киргизе алсам, анда мен суранычтарсыз жана чектөөлөрсүз эле кээ бир тапшырмалар менен ушунчалык көп подводдорду ишке киргизе алам, бул тапшырмалардын жардамы менен түйүндөр эстутумда, CPUда кошула баштайт. Мен ушунча көп подводдорду ишке киргизгенде, алардан алынган маалымат сактагычка, башкача айтканда, ж.б. Ал жерге өтө көп маалымат келгенде, сактагыч өтө жай кайтып келе баштайт - жана Кубернетес кызыксыз боло баштайт.
Жана дагы бир көйгөй... Белгилүү болгондой, Kubernetes башкаруу элементтери бир негизги нерсе эмес, бир нече компоненттер. Атап айтканда, башкаруучу башкаруучу, пландоочу ж.б.у.с. Бул балдардын баары бир эле учурда керексиз, келесоо иштерди жасай башташат, ал убакыттын өтүшү менен көбүрөөк убакытты талап кыла баштайт. Контроллердин менеджери жаңы подкасттарды түзөт. Пландоочу алар үчүн жаңы түйүн табууга аракет кылат. Жакында кластериңизде жаңы түйүндөр түгөнүп калышы мүмкүн. Kubernetes кластери жайыраак жана жайыраак иштей баштайт.
Бирок мен андан да ары кетүүнү чечтим. Белгилүү болгондой, Kubernetes-те сервис деген нерсе бар. Демейки боюнча, кластерлериңизде кызмат IP таблицаларын колдонуу менен иштейт.
Эгер сиз, мисалы, бир миллиард подсткаларды иштетип, андан кийин 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 поддон түзүүгө болот деп айта алабыз. Ал эми жалгыз иштеп чыгуучу жок дегенде кечинде өзүн муунтуп алат. Кубернетес ага мындай дейт: "Сиз өзүңүздүн капчыктарыңызды бул суммага чейин масштабдай албайсыз, анткени ресурс квотадан ашат." Болду, маселе чечилди. .
Буга байланыштуу бир көйгөйлүү жагдай келип чыгат. Kubernetes'те аттар мейкиндигин түзүү канчалык кыйын болуп жатканын сезесиз. Аны түзүү үчүн биз көп нерселерди эске алышыбыз керек.
Ресурс квотасы + Чектөө диапазону + RBAC
• Ат мейкиндигин түзүңүз
• Ичинде чек аралыгын түзүңүз
• Ички ресурстук квотаны түзүү
• CI үчүн кызмат эсебин түзүү
• CI жана колдонуучулар үчүн ролдорду түзүү
• Кааласаңыз, керектүү кызмат подкасттарын ишке киргизиңиз
Ошондуктан, учурдан пайдаланып, өзүмдүн өнүгүүлөрүмдү бөлүшкүм келет. SDK оператору деген нерсе бар. Бул Kubernetes кластери үчүн операторлорду жазуу жолу. Сиз Ansible аркылуу билдирүү жаза аласыз.
Башында Ansible менен жазылыптыр, анан SDK оператору бар экенин көрүп, Ansible ролун оператор кылып кайра жаздым. Бул билдирүү Kubernetes кластеринде буйрук деп аталган объектти түзүүгө мүмкүндүк берет. Буйруктун ичинде бул буйруктун чөйрөсүн yaml менен сүрөттөөгө мүмкүндүк берет. Ал эми команда чөйрөсүндө, бул бизге көптөгөн ресурстарды бөлүп жатканыбызды сүрөттөөгө мүмкүндүк берет.
Petite .
Жана корутундусунда. Мунун баарын эмне кылуу керек?
Алгачкы. Pod коопсуздук саясаты жакшы. Kubernetes орнотуучуларынын бири да аларды ушул күнгө чейин колдонбогонуна карабастан, сиз аларды кластерлериңизде колдонушуңуз керек.
Тармак саясаты дагы бир керексиз функция эмес. Бул чындыгында кластерде керек.
LimitRange/ResourceQuota - аны колдонууга убакыт келди. Биз муну көп убакыт мурун эле колдоно баштаганбыз жана көптөн бери баары аны колдонуп жатканына ишенчүмүн. Бул сейрек кездешет экен.
Отчеттун жүрүшүндө мен айткан нерселерден тышкары, кластерге кол салууга мүмкүндүк берүүчү документсиз функциялар бар. Жакында жарыкка чыкты .
Кээ бир нерселер абдан кайгылуу жана кайгылуу. Мисалы, белгилүү бир шарттарда, Kubernetes кластериндеги кубеттер уруксатсыз колдонуучуга warlocks каталогунун мазмунун бере алат.
Мен айткандардын баарын кантип кайра чыгаруу керектиги боюнча көрсөтмөлөр бар. ResourceQuota жана Pod Коопсуздук Саясаты кандай экенин көрсөткөн өндүрүш мисалдары бар файлдар бар. Жана мунун баарына тийсе болот.
рахмат.
Source: www.habr.com