Павел Селиванов, Southbridge шешімдерінің сәулетшісі және Slurm мұғалімі DevOpsConf 2019 көрмесінде презентация жасады. Бұл баяндама Kubernetes «Slurm Mega» тереңдетілген курсының тақырыптарының бір бөлігі болып табылады.
18-20 қарашада Мәскеуде өтеді.
— Мәскеу, 22-24 қараша.
әрқашан қол жетімді.
Кесектің астында есептің стенограммасы берілген.
Қайырлы күн, әріптестер және оларға жанашырлар. Бүгін мен қауіпсіздік туралы айтатын боламын.
Қарасам, бүгінде залда күзетшілер көп. Қауіпсіздік әлеміндегі терминдерді сіз үшін әдеттегідей емес пайдалансам, сізден алдын ала кешірім сұраймын.
Осыдан алты ай бұрын мен бір қоғамдық Kubernetes кластерін кездестірдім. Қоғамдық аттар кеңістігінің n-ші саны бар екенін білдіреді; бұл аттар кеңістігінде олардың аттар кеңістігінде оқшауланған пайдаланушылар бар. Бұл пайдаланушылардың барлығы әртүрлі компанияларға тиесілі. Бұл кластерді CDN ретінде пайдалану керек деп есептелді. Яғни, олар сізге кластерді береді, олар сізге сол жерде пайдаланушы береді, сіз өзіңіздің аттар кеңістігіңізге барасыз, фронттарыңызды орналастырасыз.
Менің бұрынғы компаниям осындай қызметті сатуға тырысты. Маған бұл шешімнің қолайлы ма, жоқ па екенін білу үшін кластерді соғуды сұрады.
Мен осы кластерге келдім. Маған шектеулі құқықтар, шектеулі аттар кеңістігі берілді. Ондағы жігіттер қауіпсіздіктің не екенін түсінді. Олар Kubernetes-те Рөлге негізделген қол жеткізуді басқару (RBAC) туралы оқыды - және олар мен подкасттарды орналастырудан бөлек іске қоса алмайтындай етіп бұрап қойды. Орналастырусыз подкастты іске қосу арқылы шешуге тырысқан мәселе есімде жоқ, бірақ мен жай ғана подкастты іске қосқым келді. Сәттілік үшін мен кластерде қандай құқықтарым бар екенін, не істей алатынымды, не істей алмайтынымды және олар нені бұзғанын көруді шештім. Сонымен қатар, мен сізге RBAC-да не дұрыс емес конфигурациялағанын айтамын.
Екі минуттан кейін мен олардың кластеріне әкімші алдым, барлық көрші атау кеңістігін қарап шықтым, сол жерде қызметті сатып алған және орналастырған компаниялардың жұмыс істеп тұрған өндірістік фронттарын көрдім. Біреудің алдына шығып, басты бетке балағат сөздер жазудан өзімді әрең тоқтаттым.
Мен мұны қалай жасағанымды және өзіңізді одан қалай қорғау керектігін мысалдармен айтып беремін.
Бірақ алдымен өзімді таныстырып өтейін. Менің атым Павел Селиванов. Мен Southbridge-те сәулетшімін. Мен Kubernetes, DevOps және барлық сәнді нәрселерді түсінемін. Мен және Оңтүстік көпірдің инженерлері осының бәрін салып жатырмыз, мен кеңес беремін.
Негізгі қызметімізге қоса, жақында біз Slurms деп аталатын жобаларды іске қостық. Біз Кубернетеспен жұмыс істеу қабілетімізді көпшілікке жеткізуге, басқа адамдарды да K8-мен жұмыс істеуге үйретуге тырысамыз.
Мен бүгін не туралы сөйлесемін? Есептің тақырыбы айқын - Kubernetes кластерінің қауіпсіздігі туралы. Бірақ мен бұл тақырып өте үлкен екенін бірден айтқым келеді, сондықтан мен не туралы айтпайтынымды бірден түсіндіргім келеді. Мен Интернетте жүз рет қолданылған бұзылған терминдер туралы айтпаймын. RBAC және сертификаттардың барлық түрлері.
Мен Kubernetes кластеріндегі қауіпсіздік туралы мені және менің әріптестерімді не мазалайтыны туралы айтатын боламын. Біз бұл проблемаларды Kubernetes кластерлерін ұсынатын провайдерлерден де, бізге келетін клиенттерден де көреміз. Тіпті бізге басқа консалтингтік әкімші компаниялардан келетін клиенттерден. Яғни, қайғылы оқиғаның ауқымы шын мәнінде өте үлкен.
Мен бүгін айтатын үш мәселе бар:
- Пайдаланушы құқықтары мен подкаст құқықтары. Пайдаланушы құқықтары мен подкаст құқықтары бірдей нәрсе емес.
- Кластер туралы ақпарат жинау. Мен сізге кластерден барлық қажетті ақпаратты осы кластерде арнайы құқықтарсыз жинай алатыныңызды көрсетемін.
- Кластерге DoS шабуылы. Егер ақпарат жинай алмасақ, кез келген жағдайда кластерді қоя аламыз. Мен кластерді басқару элементтеріне DoS шабуылдары туралы айтатын боламын.
Тағы бір айта кететін жайт, мен мұның бәрін сынап көрдім, мен мұның бәрі жұмыс істейтінін анық айта аламын.
Біз Kubespray көмегімен Kubernetes кластерін орнатуды негізге аламыз. Егер біреу білмесе, бұл шын мәнінде Ansible үшін рөлдер жиынтығы. Біз оны жұмысымызда үнемі қолданамыз. Бір жақсысы, сіз оны кез келген жерде айналдыра аласыз - оны темір кесектеріне немесе бір жерде бұлтқа айналдыра аласыз. Бір орнату әдісі негізінен барлығы үшін жұмыс істейді.
Бұл кластерде менде Kubernetes v1.14.5 болады. Біз қарастыратын бүкіл Cube кластері аттар кеңістігіне бөлінген, әрбір аттар кеңістігі бөлек командаға жатады және осы топ мүшелері әрбір аттар кеңістігіне қатынаса алады. Олар әртүрлі аттар кеңістігіне бара алмайды, тек өздеріне ғана. Бірақ бүкіл кластерге құқықтары бар белгілі бір әкімші тіркелгісі бар.
Мен ең бірінші кластерге әкімші құқықтарын алу деп уәде бердім. Бізге Kubernetes кластерін бұзатын арнайы дайындалған подвод қажет. Бізге тек оны Kubernetes кластеріне қолдану керек.
kubectl apply -f pod.yamlБұл блок Kubernetes кластерінің шеберлерінің біріне келеді. Осыдан кейін кластер бізге admin.conf деп аталатын файлды қуана қайтарады. Текшеде бұл файл барлық әкімші куәліктерін сақтайды және сонымен қатар API кластерін теңшейді. Менің ойымша, Kubernetes кластерлерінің 98% әкімшіге қол жеткізу оңай.
Қайталап айтамын, бұл подкастты кластеріңіздегі ұсыныстарын бір шағын аттар кеңістігінде орналастыруға рұқсаты бар бір әзірлеуші жасаған, мұның барлығы RBAC арқылы бекітілген. Оның құқығы болмады. Бірақ соған қарамастан сертификат қайтарылды.
Ал енді арнайы дайындалған пышақ туралы. Біз оны кез келген суретте іске қосамыз. Мысал ретінде debian:jessie-ді алайық.
Бізде мына нәрсе бар:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Толеранттылық дегеніміз не? Кубернетес кластеріндегі шеберлер әдетте ластану деп аталатын нәрсемен белгіленеді. Және бұл «инфекцияның» мәні - бұл түйіндерді негізгі түйіндерге тағайындауға болмайтынын айтады. Бірақ ешкім оның «инфекцияға» төзімді екенін кез келген бөтелкеде көрсетуге алаңдамайды. Толерация бөлімінде жай ғана айтады, егер кейбір түйінде 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-ті сол жерден алуды және мастердің бүкіл түбірін осы подкольдің ішіне орнатуды айттық.
Сіз Debian-да бізде bash жұмыс істейтінін және бұл bash түбірі астында жұмыс істейтінін түсінесіз. Яғни, біз Kubernetes кластерінде ешқандай құқыққа ие болмай, шеберде түбір алдық.
Содан кейін барлық тапсырма /host /etc/kubernetes/pki ішкі каталогына өту, егер қателеспесем, кластердің барлық негізгі сертификаттарын сол жерден алыңыз және тиісінше кластер әкімшісі болыңыз.
Егер сіз оны осылай қарасаңыз, пайдаланушының қандай құқықтары бар екеніне қарамастан, бұл подкасттардағы ең қауіпті құқықтардың кейбірі:
Егер менде кластердің кейбір аттар кеңістігінде подкастты іске қосу құқығы болса, онда бұл подкасттың әдепкі бойынша осы құқықтары бар. Мен артықшылықты подкасттарды іске қоса аламын және бұл жалпы құқықтар, іс жүзінде түйінде түбір.
Менің сүйікті Root пайдаланушысы. Ал Kubernetes-те бұл «Түбірлік емес іске қосу» опциясы бар. Бұл хакерлерден қорғаудың бір түрі. Сіз «молдаван вирусы» деген не екенін білесіз бе? Егер сіз кенеттен хакер болсаңыз және менің Kubernetes кластеріме келсеңіз, біз, кедей әкімшілер, сұраймыз: «Сіздің түйіндеріңізде менің кластерді бұзатыныңызды көрсетіңіз, root емес ретінде іске қосыңыз. Әйтпесе, сіз өзіңіздің подводыңыздағы процесті root астында іске қосасыз және мені бұзу өте оңай болады. Өзіңізді өзіңізден сақтаңыз."
Хост жолының көлемі, менің ойымша, Kubernetes кластерінен қажетті нәтижені алудың ең жылдам жолы.
Бірақ мұның бәрімен не істеу керек?
Кубернетеспен кездескен кез келген қарапайым әкімшіге келесі ой келеді: «Иә, мен айттым, Кубернетес жұмыс істемейді. Оның ішінде тесіктер бар. Ал текшенің бәрі ақымақ». Негізі құжаттама деген бар, қарасаңыз бөлім бар .
Бұл yaml нысаны - біз оны Kubernetes кластерінде жасай аламыз - ол блоктардың сипаттамасында қауіпсіздік аспектілерін бақылайды. Яғни, іс жүзінде ол іске қосу кезінде блоктарда болатын кез келген hostNetwork, hostPID, белгілі бір көлем түрлерін пайдалану құқықтарын басқарады. Pod Security Policy көмегімен мұның барлығын сипаттауға болады.
Pod қауіпсіздік саясаты туралы ең қызықты нәрсе Kubernetes кластерінде барлық PSP орнатушылары ешбір жолмен сипатталмаған, олар әдепкі бойынша өшірілген. Pod қауіпсіздік саясаты қабылдау плагині арқылы қосылады.
Жарайды, Pod қауіпсіздік саясатын кластерге орналастырайық, аттар кеңістігінде тек әкімшілер қол жеткізе алатын кейбір қызмет бөлімшелері бар делік. Айталық, барлық басқа жағдайларда бұршақтардың құқықтары шектеулі. Себебі әзірлеушілерге кластеріңізде артықшылықты подкасттарды іске қосудың қажеті жоқ.
Ал бізде бәрі жақсы сияқты. Біздің Kubernetes кластерін екі минут ішінде бұзу мүмкін емес.
Мәселе бар. Сірә, сізде Kubernetes кластері болса, бақылау кластеріңізге орнатылған. Мен тіпті егер сіздің кластеріңізде мониторинг болса, ол Прометей деп аталады деп болжауға дейін барар едім.
Менің сізге айтайын деп отырғаным Прометей операторы үшін де, оның таза түрінде жеткізілген Прометей үшін де жарамды болады. Мәселе мынада, егер мен кластерге әкімшіні тез кіргізе алмасам, бұл маған көбірек іздеу керек дегенді білдіреді. Мен сіздің бақылауыңыздың көмегімен іздей аламын.
Мүмкін бәрі Хабре туралы бірдей мақалаларды оқиды және мониторинг мониторинг аттар кеңістігінде орналасқан. Штурвал диаграммасы барлығы үшін бірдей деп аталады. Менің ойымша, егер сіз тұрақты/прометейді орнатуды орындасаңыз, сіз шамамен бірдей атаулармен аяқталасыз. Мен сіздің кластеріңіздегі DNS атауын болжаудың қажеті жоқ шығар. Өйткені бұл стандартты.
Әрі қарай бізде белгілі бір подкастты іске қосуға болатын белгілі бір әзірлеушілер бар. Ал содан кейін бұл подводтан келесідей нәрсені жасау өте оңай:
$ 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-тің өзіне тікелей қол жеткізе аласыз. Сол жерден көрсеткіштерді жинауға болады. Сіз тіпті сол жерден көрсеткіштерді құра аласыз. Теориялық тұрғыдан да, мұндай сұрауды Prometheus кластерінен құрастыруға болады, ол оны жай ғана өшіреді. Сіздің бақылауыңыз кластерден мүлдем жұмысын тоқтатады.
Бұл жерде кез келген сыртқы мониторинг сіздің бақылауыңызды бақылайды ма деген сұрақ туындайды. Мен Kubernetes кластерінде өзім үшін ешқандай салдарсыз жұмыс істеу мүмкіндігіне ие болдым. Сіз менің ол жерде жұмыс істеп жатқанымды білмейсіз, өйткені бұдан былай бақылау жоқ.
PSP сияқты, бұл барлық сәнді технологиялар - Кубернетес, Прометей - олар жұмыс істемейді және тесіктерге толы. Онша емес.
Ондай нәрсе бар - .
Егер сіз кәдімгі әкімші болсаңыз, онда сіз Желілік саясат туралы білесіз бе, бұл кластерде олардың көпшілігі бар басқа ямл ғана. Кейбір желілік саясаттар міндетті түрде қажет емес. Желілік саясат дегеніміз не екенін оқысаңыз да, бұл Kubernetes-тің yaml брандмауэрі, ол аттар кеңістігі, подкасттар арасындағы қол жеткізу құқықтарын шектеуге мүмкіндік береді, содан кейін сіз Кубернетестегі yaml пішіміндегі брандмауэр келесі абстракцияларға негізделген деп шештіңіз. ... Жоқ Жоқ . Бұл міндетті емес.
Қауіпсіздік мамандарына Kubernetes көмегімен сіз өте оңай және қарапайым брандмауэр және өте түйіршікті брандмауэр құра алатыныңызды айтпаған болсаңыз да. Егер олар мұны әлі білмесе және сізді алаңдатпаса: «Ал, маған беріңіз, маған беріңіз...» Сонда кез келген жағдайда кластеріңізден шығарылатын кейбір қызмет көрсету орындарына кіруге тыйым салу үшін сізге желілік саясат қажет. ешқандай рұқсатсыз.
Мен келтірген мысалдағыдай, Kubernetes кластеріндегі кез келген аттар кеңістігінен куб күйінің көрсеткіштерін ешбір құқықсыз алуға болады. Желі саясаттары барлық басқа аттар кеңістігінен бақылау аттар кеңістігіне жабық қатынасқа ие және міне, қол жеткізу жоқ, проблемалар жоқ. Бар барлық диаграммаларда, стандартты Prometheus және оператордағы Prometheus екеуі де, олар үшін желілік саясатты қосу үшін басқару мәндерінде жай ғана опция бар. Тек оны қосу керек және олар жұмыс істейді.
Бұл жерде шынымен бір мәселе бар. Қалыпты сақалды әкімші бола отырып, сіз желілік саясаттарды қажет етпейтін шығарсыз. Хабр сияқты ресурстар туралы мақалалардың барлық түрлерін оқығаннан кейін, сіз фланельді, әсіресе хост-шлюз режимін таңдай алатын ең жақсы нәрсе деп шештіңіз.
Не істеу?
Kubernetes кластерінде бар желілік шешімді қайта орналастыруға тырысуға болады, оны функционалдырақ нәрсемен ауыстыруға тырысыңыз. Мысалы, сол Calico үшін. Бірақ мен Kubernetes жұмыс кластеріндегі желілік шешімді өзгерту міндеті өте маңызды емес екенін бірден айтқым келеді. Мен оны екі рет шештім (екі рет те теориялық тұрғыдан), бірақ біз оны Slurms-те қалай жасау керектігін көрсеттік. Студенттеріміз үшін біз Kubernetes кластеріндегі желілік шешімді қалай өзгерту керектігін көрсеттік. Негізінде, өндіріс кластерінде тоқтап қалудың жоқтығына көз жеткізуге болады. Бірақ сіз табысқа жете алмайтын шығарсыз.
Ал мәселе шын мәнінде өте қарапайым шешіледі. Кластерде сертификаттар бар және сіз сертификаттарыңыздың мерзімі бір жылдан кейін бітетінін білесіз. Әдетте кластердегі сертификаттары бар қалыпты шешім - біз неге алаңдаймыз, біз жақын жерде жаңа кластерді көтереміз, ескісін шіріп, бәрін қайта орналастырамыз. Рас, ол шіріп кеткенде, бір күн отыруға тура келеді, бірақ міне жаңа кластер.
Жаңа кластерді көтерген кезде, бір уақытта фланельдің орнына Calico салыңыз.
Егер сіздің сертификаттарыңыз жүз жылға берілсе және сіз кластерді қайта орналастырғыңыз келмесе, не істеу керек? Kube-RBAC-Proxy сияқты нәрсе бар. Бұл өте керемет әзірлеме, ол сізге Kubernetes кластеріндегі кез келген подводқа бүйірлік контейнер ретінде ендіруге мүмкіндік береді. Және ол шын мәнінде Kubernetes RBAC арқылы осы подкастқа авторизацияны қосады.
Бір мәселе бар. Бұрын бұл Kube-RBAC-Proxy шешімі оператордың Prometheus жүйесіне енгізілген. Бірақ кейін ол кетіп қалды. Енді заманауи нұсқалар сізде желілік саясат бар екеніне сүйенеді және солардың көмегімен оны жабады. Сондықтан біз диаграмманы аздап қайта жазуымыз керек. Шын мәнінде, егер сіз барсаңыз , мұны бүйірлік арбалар ретінде пайдаланудың мысалдары бар және диаграммаларды ең аз түрде қайта жазу керек.
Тағы бір кішкентай мәселе бар. Прометей өз метрикасын кез келген адамға тарататын жалғыз адам емес. Біздің барлық Kubernetes кластерінің құрамдас бөліктері де өз көрсеткіштерін қайтара алады.
Бірақ мен айтқанымдай, егер сіз кластерге қол жеткізіп, ақпарат жинай алмасаңыз, кем дегенде біраз зиян келтіре аласыз.
Сондықтан мен Kubernetes кластерін қалай бұзуға болатынын екі жолды тез көрсетемін.
Осыны айтсам күлесің, бұл екі өмірлік оқиға.
Бірінші әдіс. Ресурстардың сарқылуы.
Тағы бір арнайы бөлімді іске қосайық. Онда осындай бөлім болады.
resources:
requests:
cpu: 4
memory: 4Gi Өздеріңіз білетіндей, сұраулар - сұраулары бар арнайы подкольдер үшін хостта сақталған CPU және жад көлемі. Егер бізде Kubernetes кластерінде төрт ядролы хост болса және төрт орталық процессоры сол жерге сұраулармен келсе, бұл сұраулары бар бірде-бір бөлім бұл хостқа келе алмайтынын білдіреді.
Егер мен осындай подкастты іске қоссам, пәрменді орындаймын:
$ kubectl scale special-pod --replicas=...Содан кейін басқа ешкім Kubernetes кластеріне орналастыра алмайды. Өйткені барлық түйіндерде сұраулар бітеді. Осылайша мен сіздің Kubernetes кластерін тоқтатамын. Егер мен мұны кешке жасасам, орналастыруды ұзақ уақытқа тоқтата аламын.
Егер біз Kubernetes құжаттамасына қайта қарасақ, біз бұл шекті диапазон деп аталатын нәрсені көреміз. Ол кластер нысандары үшін ресурстарды орнатады. Шектеу ауқымы нысанын yaml тілінде жаза аласыз, оны белгілі бір аттар кеңістігіне қолдана аласыз - содан кейін осы аттар кеңістігінде сізде подкасттар үшін әдепкі, максималды және ең аз ресурстар бар екенін айта аласыз.
Осындай нәрсенің көмегімен біз пайдаланушыларды топтардың белгілі бір өнім аттары кеңістігінде олардың қоршауларында барлық жағымсыз нәрселерді көрсету мүмкіндігін шектей аламыз. Бірақ, өкінішке орай, пайдаланушыға бірнеше CPU сұраулары бар подкасттарды іске қоса алмайтынын айтсаңыз да, мұндай керемет масштабтау пәрмені бар немесе олар бақылау тақтасы арқылы масштабтауға болады.
Міне, №11 әдіс осыдан келеді. Біз 111 111 111 111 XNUMX шұңқырды іске қосамыз. Бұл он бір миллиард. Бұл мұндай санды ойлап тапқанымнан емес, оны өзім көргендіктен.
Шынайы оқиға. Кешке қарай кеңседен шықпақ болдым. Мен бір топ әзірлеушілерді бұрышта отырып, ноутбуктарымен бірдеңе істеп жатқанын көріп тұрмын. Мен жігіттерге барып: «Саған не болды?» деп сұраймын.
Сәл бұрын, кешкі тоғыздар шамасында әзірлеушілердің бірі үйіне қайтуға дайындалып жатты. Мен шешім қабылдадым: «Енді мен қолданбамды біреуіне дейін кішірейтемін». Біреуін бастым, бірақ интернет аздап баяулады. Біреуін тағы бір басып, біреуін басып, Enter пернесін басып. Мен қолымнан келгеннің бәрін қағып алдым. Содан кейін Интернет өмірге келді - және бәрі осы санға дейін төмендей бастады.
Рас, бұл оқиға Кубернетесте болған жоқ, ол кезде бұл Nomad еді. Оның соңы бір сағаттық біздің Nomad-ті масштабтаудың табанды әрекеттерінен тоқтату әрекетінен кейін Nomad масштабтауды тоқтатпайтынын және басқа ештеңе істемейтінін айтты. «Мен шаршадым, кетемін». Және ол бұралып қалды.
Әрине, мен Кубернетесте де солай жасауға тырыстым. Кубернетес он бір миллиардқа риза болмады, ол: «Мен алмаймын. Ішкі ауызды қорғаудан асып түседі». Бірақ 1 000 000 000 бұршақ мүмкін.
Бір миллиардқа жауап ретінде текше өзіне кірмеді. Ол шынымен масштабтай бастады. Процесс неғұрлым ұзағырақ болса, соғұрлым оған жаңа бөтелкелерді жасауға уақыт кетті. Бірақ әлі де процесс жүрді. Жалғыз мәселе, егер мен өзімнің аттар кеңістігімде подкасттарды шексіз іске қоса алсам, тіпті сұрауларсыз және шектеулерсіз мен кейбір тапсырмалары бар көптеген қосқыштарды іске қоса аламын, бұл тапсырмалардың көмегімен түйіндер жадқа, орталық процессорға қосыла бастайды. Мен көптеген подкасттарды іске қосқан кезде, олардан алынған ақпарат жадқа түсуі керек, яғни т.б. Ол жерге тым көп ақпарат келгенде, сақтау орны тым баяу орала бастайды - Кубернетес бұлыңғыр бола бастайды.
Және тағы бір мәселе... Өздеріңіз білетіндей, 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 тілінде сипаттауға мүмкіндік береді. Ал командалық ортада бұл бізге көптеген ресурстарды бөліп жатқанымызды сипаттауға мүмкіндік береді.
Кішкентай .
Және қорытындысында. Мұның бәрін не істеу керек?
Бірінші. Pod қауіпсіздік саясаты жақсы. Kubernetes орнатушылардың ешқайсысы оларды осы күнге дейін пайдаланбағанына қарамастан, сіз оларды кластерлеріңізде пайдалануыңыз керек.
Желі саясаты басқа қажетсіз мүмкіндік емес. Бұл кластерде шынымен қажет нәрсе.
LimitRange/ResourceQuota - оны пайдалану уақыты келді. Біз мұны баяғыда қолдана бастадық, мен көптен бері барлығының оны пайдаланып жатқанына сенімді болдым. Бұл сирек болатыны белгілі болды.
Есеп барысында айтқандарыма қоса, кластерге шабуыл жасауға мүмкіндік беретін құжатталмаған мүмкіндіктер бар. Жақында шығарылды .
Кейбір нәрселер өте қайғылы және ауыр. Мысалы, белгілі шарттарда Kubernetes кластеріндегі текшелер рұқсат етілмеген пайдаланушыға warlocks каталогының мазмұнын бере алады.
Сізге айтқанымның барлығын қайта шығару туралы нұсқаулар бар. ResourceQuota және Pod қауіпсіздік саясаты қалай көрінетінін өндіру мысалдары бар файлдар бар. Және мұның барлығына қол тигізуге болады.
Барлығыңа Рақмет.
Ақпарат көзі: www.habr.com