Southbridge həllinin memarı və Slurm müəllimi Pavel Selivanov DevOpsConf 2019-da çıxış etdi. Bu çıxış Slurm Mega qabaqcıl Kubernetes kursunun mövzularından birinin bir hissəsidir.
18-20 noyabr tarixlərində Moskvada keçiriləcək.
- Moskva, 22-24 noyabr.
həmişə mövcuddur.
Kəsik altında - hesabatın stenoqramı.
Axşamınız xeyir, həmkarlar və rəğbət bəsləyənlər. Bu gün təhlükəsizlik haqqında danışacağam.
Baxıram ki, bu gün zalda çoxlu təhlükəsizlik işçiləri var. Təhlükəsizlik dünyasına aid terminləri sizin adətən etdiyiniz kimi istifadə etməsəm, sizdən əvvəlcədən üzr istəyirəm.
Belə oldu ki, təxminən altı ay əvvəl bir ictimai Kubernetes klasteri mənim əlimə düşdü. İctimai - o deməkdir ki, n-ci sayda ad sahəsi var, bu ad boşluqlarında onların ad məkanında təcrid olunmuş istifadəçilər var. Bu istifadəçilərin hamısı müxtəlif şirkətlərə aiddir. Yaxşı, bu klasterin CDN kimi istifadə edilməli olduğu güman edilirdi. Yəni sizə klaster verirlər, orada istifadəçi verirlər, sən öz ad məkanında ora gedirsən, cəbhələrini yerləşdirirsən.
Əvvəlki şirkətim belə bir xidmət satmağa çalışdı. Və məndən bu mövzuda klasteri soxmaq istədilər - belə bir həllin uyğun olub-olmaması.
Mən bu klasterə gəldim. Mənə məhdud hüquqlar, məhdud ad sahəsi verildi. Orada uşaqlar təhlükəsizliyin nə olduğunu başa düşdülər. Onlar Kubernetes-də Rol əsaslı giriş nəzarətinin (RBAC) nə olduğunu oxudular - və onu bükdülər ki, podları yerləşdirmələrdən ayrıca işlədə bilməyim. Yerləşdirmədən bir pod işlətməklə həll etməyə çalışdığım problemi xatırlamıram, amma həqiqətən bir pod işlətmək istəyirdim. Mən klasterdə hansı hüquqlarım olduğunu, nəyi edə biləcəyimi, nəyi edə bilməyəcəyimi, orada nəyi batırdıqlarını görmək qərarına gəldim. Eyni zamanda, RBAC-da nəyi səhv konfiqurasiya etdiklərini söyləyəcəyəm.
Belə oldu ki, iki dəqiqədən sonra mən onların klasterinə bir admin aldım, bütün qonşu ad boşluqlarına baxdım, artıq xidməti almış və orada yerləşdirilən şirkətlərin istehsal cəbhələrini gördüm. Qarşıdakı kiminsə yanına gəlib ana səhifəyə söyüşlər yazmamaq üçün özümü güclə saxladım.
Bunu necə etdiyimi və ondan necə müdafiə olunacağını misallarla izah edəcəyəm.
Amma əvvəlcə özümü təqdim edim. Mənim adım Pavel Selivanovdur. Mən Southbridge üçün memaram. Mən Kubernetes, DevOps və hər cür zərif şeyləri başa düşürəm. Southbridge mühəndisləri və mən hamısını tikirik və mən məsləhət görürəm.
Əsas fəaliyyətlərimizlə yanaşı, bu yaxınlarda Slurms adlı layihələrə start vermişik. Biz Kubernetes ilə işləmək bacarığımızı bir az da kütlələrə çatdırmağa, digər insanlara da K8-lərlə işləməyi öyrətməyə çalışırıq.
Bu gün nə danışacağam. Hesabatın mövzusu aydındır - Kubernetes klasterinin təhlükəsizliyi haqqında. Ancaq dərhal demək istəyirəm ki, bu mövzu çox böyükdür - və buna görə də mütləq nəyi danışmayacağımı dərhal dəqiqləşdirmək istəyirəm. Onsuz da internetdə yüz dəfə həddən artıq işlədilən hackney terminləri haqqında danışmayacağam. İstənilən RBAC və sertifikatlar.
Məni və həmkarlarımı Kubernetes klasterində təhlükəsizlikdən nəyin incitdiyi barədə danışacağam. Biz bu problemləri həm Kubernetes klasterlərini təmin edən provayderlərlə, həm də bizə gələn müştərilərlə görürük. Və hətta digər konsaltinq idarə şirkətlərindən bizə gələn müştərilər üçün. Yəni faciənin miqyası əslində çox böyükdür.
Bu gün danışacağım üç nöqtə:
- İstifadəçi hüquqları və pod hüquqları. İstifadəçi hüquqları və pod hüquqları eyni şey deyil.
- Klaster haqqında məlumatların toplanması. Mən göstərəcəyəm ki, siz bu klasterdə xüsusi hüquqlarınız olmadan bir klasterdən sizə lazım olan bütün məlumatları toplaya bilərsiniz.
- Çoxluğa DoS hücumu. Əgər məlumat toplaya bilməsək, istənilən halda klasteri yerləşdirə biləcəyik. Mən klaster idarəetmə elementlərinə DoS hücumlarından danışacağam.
Qeyd edəcəyim başqa bir ümumi şey, hamısını sınadığım şeydir və bunun hamısının işlədiyini əminliklə deyə bilərəm.
Əsas olaraq Kubespray istifadə edərək Kubernetes klasterinin quraşdırılmasını götürürük. Əgər kimsə bilmirsə, bu, əslində Ansible üçün rollar toplusudur. İşdə hər zaman istifadə edirik. Yaxşısı odur ki, sən istənilən yerə yuvarlana bilərsən - həm də dəmir parçaları üzərində yuvarlana bilərsən, həm də buludda bir yerə. Bir quraşdırma üsulu prinsipcə hər şey üçün uyğundur.
Bu klasterdə məndə Kubernetes v1.14.5 olacaq. Nəzərdən keçirəcəyimiz bütün Cube klaster ad boşluqlarına bölünür, hər bir ad sahəsi ayrıca komandaya aiddir, bu komandanın üzvlərinin hər bir ad sahəsinə çıxışı var. Onlar müxtəlif ad boşluqlarına gedə bilməzlər, yalnız öz adlarına. Ancaq bütün klaster üçün hüquqları olan müəyyən bir admin hesabı var.
Söz verdim ki, bizdə ilk şey klasterə admin hüquqlarını əldə etmək olacaq. Bizə Kubernetes klasterini qıracaq xüsusi hazırlanmış pod lazımdır. Etməli olduğumuz tək şey onu Kubernetes klasterinə tətbiq etməkdir.
kubectl apply -f pod.yamlBu pod Kubernetes klasterinin ustalarından birinə gələcək. Və klaster bundan sonra admin.conf adlı faylı məmnuniyyətlə qaytaracaq. Kubada bu fayl bütün admin sertifikatlarını saxlayır və eyni zamanda klaster API-si konfiqurasiya edilir. Düşünürəm ki, Kubernetes klasterlərinin 98%-nə admin girişi əldə etmək bu qədər asandır.
Yenə də, bu pod klasterinizdə öz təkliflərini kiçik bir ad məkanında yerləşdirmək imkanı olan bir tərtibatçı tərəfindən hazırlanmışdır, hamısı RBAC tərəfindən sıxışdırılır. Onun heç bir hüququ yox idi. Lakin buna baxmayaraq sertifikat geri qaytarıldı.
İndi isə xüsusi hazırlanmış ocaq haqqında. İstənilən şəkil üzərində işə salırıq. Nümunə olaraq debian:jessie-ni götürək.
Bizdə belə bir şey var:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Tolerantlıq nədir? Kubernetes klasterindəki ustalar adətən ləkə deyilən bir şeylə etiketlənirlər. Və bu "infeksiyanın" mahiyyəti ondan ibarətdir ki, podların master qovşaqlara təyin edilə bilməyəcəyini söyləyir. Ancaq heç kim onun "infeksiyaya" dözümlü olduğunu hər hansı bir podda göstərməkdən narahat deyil. Tolerasiya bölməsi sadəcə deyir ki, əgər NoSchedule hansısa qovşaqda quraşdırılıbsa, deməli bizim pod belə infeksiyaya dözümlüdür - və heç bir problem yoxdur.
Daha sonra deyirik ki, podumuz nəinki dözümlüdür, həm də qəsdən ustaya vurmaq istəyir. Çünki ustalarda bizə lazım olan ən dadlı şey var - bütün sertifikatlar. Buna görə də, biz nodeSelector deyirik - və masterlarda standart etiketimiz var ki, bu da klasterin bütün qovşaqlarından məhz master olan qovşaqları seçməyə imkan verir.
Bu iki bölmə ilə mütləq ustaya gələcək. Və ona orada yaşamağa icazə veriləcək.
Amma təkcə ustaya gəlmək bizə bəs etmir. Bu bizə heç nə verməyəcək. Beləliklə, növbəti iki şeyimiz var:
hostNetwork: true
hostPID: true İşlətdiyimiz podun nüvə ad məkanında, şəbəkə ad məkanında və PID ad məkanında yaşayacağını müəyyən edirik. Bir pod master üzərində işlədikdən sonra o, həmin qovşağın bütün real, canlı interfeyslərini görə, bütün trafiki dinləyə və bütün proseslərin PID-lərini görə biləcək.
Sonra xırda şeylərə aiddir. etcd götürün və istədiyinizi oxuyun.
Ən maraqlısı, standart olaraq orada olan bu Kubernetes xüsusiyyətidir.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Və onun mahiyyəti ondan ibarətdir ki, biz işə saldığımız podda hətta bu klasterə hüquqlar olmadan belə deyə bilərik ki, hostPath tipli həcm yaratmaq istəyirik. Beləliklə, başlayacağımız ev sahibinin yolunu götürün və onu həcm kimi qəbul edin. Və sonra onu ad adlandırırıq: host. Bütün bu hostPath-ı podun içərisinə quraşdırırıq. Bu nümunədə, /host qovluğuna.
Bir daha təkrar edəcəyəm. Biz poda dedik ki, mastera gəlsin, orada hostNetwork və hostPID əldə etsin və master-ın bütün kökünü bu podun içərisinə quraşdırsın.
Siz başa düşürsünüz ki, debian-da bizdə bash var və bu bash bizim üçün root kimi işləyir. Yəni Kubernetes klasterində heç bir hüququmuz olmadığı halda, sadəcə ustada kök aldıq.
Sonra bütün vəzifə qovluğuna / host / etc / kubernetes / pki daxil olmaqdır, səhv etmirəmsə, oradan bütün klasterin master sertifikatlarını götürün və müvafiq olaraq klasterin idarəçisi olun.
Bu şəkildə baxdıqda, istifadəçinin hansı hüquqlara malik olmasından asılı olmayaraq, bunlar podlarda ən təhlükəli hüquqlardan bəziləridir:
Əgər mənim bəzi klaster ad məkanında pod işlətmək hüququm varsa, bu pod defolt olaraq bu hüquqlara malikdir. Mən imtiyazlı podları işlədə bilirəm, bu, ümumiyyətlə, bütün hüquqlara malikdir, praktiki olaraq node köklənir.
Ən çox sevdiyim Root istifadəçisidir. Və Kubernetes-də bu Run As Qeyri-Root seçimi var. Bu hakerdən qorunmanın bir növüdür. “Moldova virusu”nun nə olduğunu bilirsinizmi? Birdən haker olsanız və mənim Kubernetes klasterimə gəldinizsə, onda biz, yoxsul idarəçilər soruşurlar: “Xahiş edirəm, mənim klasterimi sındıracağınızı podlarınızda qeyd edin, kök olmayan kimi işləyin. Yoxsa kök altından podunuzda prosesi başladığınız ortaya çıxacaq və məni hack etmək sizin üçün çox asan olacaq. Özünüzü qoruyun, xahiş edirəm”.
Host yolunun həcmi - mənim fikrimcə, Kubernetes klasterindən istədiyiniz nəticəni əldə etməyin ən sürətli yolu.
Ancaq bütün bunlarla nə etmək lazımdır?
Kuberneteslə qarşılaşan istənilən normal idarəçinin ağlına gəlməli olan fikirlər: “Bəli, sizə dedim, Kubernetes işləmir. İçində deşiklər var. Və bütün Küp axmaqlıqdır." Əslində sənədləşmə deyə bir şey var, ora baxırsan, deməli, bölmə var .
Bu, belə bir yaml obyektidir - biz onu Kubernetes klasterində yarada bilərik - bu, podların təsvirində təhlükəsizlik aspektlərinə nəzarət edir. Yəni, əslində o, başlanğıcda podlarda olan hər hansı hostNetwork, hostPID, müəyyən həcm növlərindən istifadə hüquqlarını idarə edir. Pod Təhlükəsizlik Siyasətinin köməyi ilə bütün bunları təsvir etmək olar.
Pod Təhlükəsizlik Siyasəti ilə bağlı ən maraqlı şey, Kubernetes klasterində bütün PSP quraşdırıcılarının heç bir şəkildə təsvir edilməməsi, sadəcə olaraq standart olaraq söndürülməsidir. Pod Təhlükəsizlik Siyasəti qəbul plaginindən istifadə etməklə aktivləşdirilib.
Yaxşı, gəlin klasterə Pod Təhlükəsizlik Siyasətini yerləşdirək, deyək ki, ad məkanında yalnız adminlərin daxil ola biləcəyi bəzi xidmət bölmələrimiz var. Tutaq ki, bütün qalanlarda podların məhdud hüquqları var. Çünki çox güman ki, tərtibatçıların klasterinizdə imtiyazlı podlar işlətməsinə ehtiyac yoxdur.
Və deyəsən yaxşıyıq. Kubernetes klasterimizi iki dəqiqə ərzində sındırmaq olmaz.
Problem var. Çox güman ki, Kubernetes klasteriniz varsa, monitorinq klasterinizdə quraşdırılıb. Mən hətta proqnozlaşdırmağı öhdəmə götürürəm ki, əgər klasterinizdə monitorinq varsa, o zaman Prometey adlanır.
İndi sizə deyəcəklərim həm Prometey operatoru, həm də təmiz formada çatdırılan Prometey üçün keçərlidir. Sual odur ki, mən klasterə bu qədər tez admin ala bilmirəmsə, bu o deməkdir ki, daha çox axtarış etməliyəm. Mən sizin monitorinqinizdən istifadə edərək axtarış edə bilərəm.
Yəqin ki, hər kəs Habré-də eyni məqalələri oxuyur və monitorinq monitorinq ad məkanında yerləşir. Helm chart hər kəs üçün təxminən eyni adlanır. Düşünürəm ki, stabil/prometeyi quraşdırsanız, təxminən eyni adlarla başa çatmalısınız. Və hətta çox güman ki, mən sizin klasterinizdəki DNS adını təxmin etməli olmayacağam. Çünki standartdır.
Sonra, müəyyən bir pod işlədə biləcəyiniz müəyyən bir inkişaf etdiricimiz var. Və sonra bu poddan bunu etmək çox asandır:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics Kubernetes API-nin özündən ölçüləri toplayan prometey ixracatçılarından biridir. Orada çoxlu məlumat var, klasterinizdə nə işləyir, nədir, onunla hansı problemləriniz var.
Sadə bir misal olaraq:
kube_pod_container_info{namespace="kube-system",pod="kube-apiserver-k8s-1",container="kube-apiserver",şəkil=
"gcr.io/google-containers/kube-apserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
İmtiyazsız bir poddan sadə bir qıvrım sorğusu edərək, bu kimi məlumat əldə edə bilərsiniz. Kubernetes-in hansı versiyasını işlətdiyinizi bilmirsinizsə, o sizə asanlıqla xəbər verəcəkdir.
Ən maraqlısı odur ki, kube-state-metriklərinə daxil olmaqdan əlavə, Prometheus-un özünə də birbaşa daxil ola bilərsiniz. Metrikləri oradan toplaya bilərsiniz. Siz hətta oradan metrikalar qura bilərsiniz. Hətta nəzəri cəhətdən belə bir sorğunu Prometeydəki klasterdən qura bilərsiniz ki, bu da onu sadəcə söndürəcək. Və monitorinqiniz ümumiyyətlə klasterdən işləməyi dayandıracaq.
Və burada artıq sual yaranır ki, hər hansı bir kənar monitorinq sizin monitorinqinizə nəzarət edirmi? Mən sadəcə Kubernetes klasterində işləmək imkanı əldə etdim, özüm üçün heç bir nəticəsi yoxdur. Siz heç bilməyəcəksiniz ki, mən orada işləyirəm, çünki monitorinq artıq orada deyil.
PSP-də olduğu kimi, problem bütün bu gözəl texnologiyaların - Kubernetes, Prometheus - sadəcə işləmir və deşiklərlə dolu olmasıdır. Həqiqətən yox.
Belə bir şey var - .
Əgər siz normal idarəçisinizsə, çox güman ki, Şəbəkə Siyasəti haqqında bilirsiniz ki, bu, artıq klasterdə dofiga olan başqa bir yamldır. Və Şəbəkə Siyasətləri mütləq lazım deyil. Şəbəkə Siyasətinin nə olduğunu, Kubernetes yaml firewallının nə olduğunu oxusanız belə, ad boşluqları, podlar arasında giriş hüquqlarını məhdudlaşdırmağa imkan verir, onda siz mütləq Kubernetesdəki yaml firewallının növbəti abstraksiyalara əsaslandığına qərar verdiniz ... Xeyr -yox. Bu mütləq lazım deyil.
Təhlükəsizlik mütəxəssislərinizə Kubernetesinizin köməyi ilə çox asan və sadə və çox detallı bir firewall qura biləcəyiniz deyilməsə belə. Əgər onlar hələ bunu bilmirlərsə və sizi çəkmirlərsə: “Yaxşı, ver, ver...” Onda hər halda, klasterinizdən çəkə biləcəyiniz bəzi xidmət yerlərinə girişi bloklamaq üçün sizə Şəbəkə Siyasəti lazımdır. heç bir icazə olmadan.
Verdiyim nümunədə olduğu kimi, heç bir hüququnuz olmadan Kubernetes klasterindəki istənilən ad sahəsindən kube dövlət ölçülərini çıxara bilərsiniz. Şəbəkə siyasətləri bütün digər ad məkanlarından monitorinq ad sahəsinə və sanki hər şeyə qapalı girişə malikdir: giriş yoxdur, problem yoxdur. Mövcud olan bütün diaqramlarda, həm standart prometey, həm də operatorda olan prometey, sadəcə olaraq, onlar üçün şəbəkə siyasətlərini aktivləşdirmək üçün sükan dəyərlərində sadəcə bir seçim var. Sadəcə onu yandırmaq lazımdır və onlar işləyəcək.
Burada həqiqətən bir problem var. Normal saqqallı bir idarəçi olaraq, çox güman ki, şəbəkə siyasətlərinə ehtiyac olmadığına qərar verdiniz. Və Habr kimi resurslara dair hər cür məqaləni oxuduqdan sonra qərara gəldiniz ki, flanel, xüsusən də host-gateway rejimi ilə seçə biləcəyiniz ən yaxşı şeydir.
Bəs nə etməli?
Siz Kubernetes klasterinizdə olan şəbəkə həllini yenidən yerləşdirməyə cəhd edə, onu daha funksional bir şeylə əvəz etməyə cəhd edə bilərsiniz. Eyni Calico-da, məsələn. Ancaq dərhal demək istəyirəm ki, işləyən Kubernetes klasterində şəbəkə həllini dəyişdirmək vəzifəsi olduqca qeyri-ciddidir. Mən bunu iki dəfə həll etdim (hər iki dəfə də nəzəri olaraq), lakin biz hətta Slurms-da bunu necə edəcəyimizi göstərdik. Tələbələrimiz üçün Kubernetes klasterində şəbəkə həllini necə dəyişdirməyi göstərdik. Prinsipcə, istehsal klasterində heç bir fasilə olmadığından əmin olmağa çalışa bilərsiniz. Amma yəqin ki, uğur qazana bilməyəcəksiniz.
Və problem əslində çox sadə həll olunur. Klasterdə sertifikatlar var və siz bilirsiniz ki, bir ildən sonra sertifikatlarınız xarab olacaq. Yaxşı və adətən çoxluqda sertifikatları olan normal bir həll - niyə buxar banyosuna girəcəyik, onun yanında yeni bir çoxluq qaldıracağıq, köhnədə çürüməsinə icazə verəcəyik və hər şeyi yenidən yerləşdirəcəyik. Düzdür, çürüyəndə hər şey bir gün yatacaq, amma sonra yeni bir çoxluq.
Yeni bir çoxluq qaldırdığınız zaman, eyni zamanda flanel yerinə Calico daxil edin.
Yüz il müddətinə verilmiş sertifikatlarınız varsa və klasteri yenidən yerləşdirmək fikrində deyilsinizsə nə etməli? Kube-RBAC-Proxy belə bir şey var. Bu, çox gözəl bir inkişafdır, o, özünü Kubernetes klasterində istənilən podda yan qutu kimi yerləşdirməyə imkan verir. Və əslində bu poda Kubernetes-in RBAC-ı vasitəsilə icazə əlavə edir.
Bir problem var. Əvvəllər bu Kube-RBAC-Proxy həlli operatorun prometeyində qurulmuşdu. Amma sonra o getdi. İndi müasir versiyalar sizin şəbəkə siyasətləriniz olduğuna və onları onlarla bağladığınıza əsaslanır. Və beləliklə, qrafiki bir az yenidən yazmalısınız. Əslində, getsən , onun yan arabalar kimi necə istifadə ediləcəyinə dair nümunələr var və qrafiklər minimal şəkildə yenidən yazılmalı olacaq.
Daha bir kiçik problem var. Nəinki Prometey öz ölçülərini hər kəsə verir. Bizim vəziyyətimizdə Kubernetes klasterinin bütün komponentləri də öz ölçülərini verə bilir.
Amma dediyim kimi, əgər klasterə daxil ola bilmirsinizsə və məlumat toplaya bilmirsinizsə, heç olmasa zərər verə bilərsiniz.
Beləliklə, mən sizə tez bir zamanda Kubernetes klasterinin xəstələnməsinin iki yolunu göstərəcəyəm.
Sizə deyəndə güləcəksiniz, bunlar iki real həyat hadisəsidir.
Birinci üsul. Resursların tükənməsi.
Daha bir xüsusi pod təqdim edirik. Bu bölmə olacaq.
resources:
requests:
cpu: 4
memory: 4Gi Bildiyiniz kimi, sorğular xüsusi sorğu bölmələri üçün hostda saxlanılan CPU və yaddaşın miqdarıdır. Kubernetes klasterində dörd nüvəli hostumuz varsa və dörd CPU podu ora sorğularla gəlirsə, bu hosta daha sorğulu podlar gələ bilməz.
Əgər belə bir pod işlətsəm, o zaman əmr verirəm:
$ kubectl scale special-pod --replicas=...Onda başqa heç kim Kubernetes klasterinə yerləşdirə bilməyəcək. Çünki bütün qovşaqların sorğuları tükənəcək. Beləliklə, mən sizin Kubernetes klasterinizi dayandıracağam. Bunu axşam etsəm, yerləşdirmələr kifayət qədər uzun müddətə dayandırıla bilər.
Kubernetes sənədlərinə yenidən baxsaq, Limit Range adlı bir şey görəcəyik. O, klaster obyektləri üçün resursları təyin edir. Siz yaml-də Limit Range obyekti yaza, onu müəyyən ad məkanlarına tətbiq edə bilərsiniz - və daha sonra bu ad məkanında siz defolt, maksimum və minimum podlar üçün resurslarınız olduğunu söyləyə bilərsiniz.
Belə bir şeyin köməyi ilə biz xüsusi komanda məhsul ad məkanlarında olan istifadəçiləri öz podlarında hər cür pis şeyləri göstərmək imkanından məhdudlaşdıra bilərik. Təəssüf ki, istifadəçiyə birdən çox CPU üçün sorğu ilə podları işlədə bilməyəcəyinizi söyləsəniz belə, belə gözəl bir miqyas əmri var, ya da tablosundan miqyası edə bilərlər.
Və burada ikinci nömrə gəlir. 11 111 111 111 111 podları işə salın. On bir milyarddır. Bu, belə bir rəqəmi ağlıma gətirdiyim üçün deyil, özüm görmüşəm.
Əsl hekayə. Axşam saatlarında ofisdən çıxmaq istəyirdim. Baxıram, bir qrup tərtibatçı küncdə oturub çılğınlıqla noutbuklarla nəsə edir. Uşaqların yanına gedib soruşuram: “Sənə nə olub?”
Bir az əvvəl, axşam saat doqquzda tərtibatçılardan biri evə gedirdi. Və qərara gəldim: "İndi ərizəmi birinə qədər genişləndirəcəyəm." Birini basdım, internet bir az sönük oldu. Yenə birini basdı, birini basdı, Enter düyməsini basdı. O, bacardığı hər şeyi ovuşdurdu. Sonra İnternet canlandı - və hər şey bu tarixə qədər genişlənməyə başladı.
Düzdür, bu əhvalat Kubernetesdə baş vermədi, o vaxt Nomad idi. Bu onunla sona çatdı ki, Nomad-ı inadkar miqyaslı cəhdlərdən dayandırmaq üçün bir saatlıq cəhdlərimizdən sonra Nomad cavab verdi ki, o, miqyas almağı dayandırmayacaq və başqa heç nə etməyəcək. "Yoruldum, gedirəm". Və çevrildi.
Mən təbii olaraq Kubernetes-də də eyni şeyi etməyə çalışdım. On bir milyard pod Kubernetes xoşuna gəlmədi, dedi: “Mən bacarmıram. Daxili qapaqları aşır. Ancaq 1 pod bilər.
Bir milyarda cavab olaraq Kub özünə çəkilmədi. O, həqiqətən miqyas almağa başladı. Proses nə qədər irəli getsə, yeni podların yaradılması bir o qədər çox vaxt apardı. Amma yenə də proses davam edirdi. Yeganə problem odur ki, əgər mən ad məkanımda podları qeyri-müəyyən müddətə işlədə bilsəm, hətta sorğular və məhdudiyyətlər olmadan belə bir sıra podları bəzi tapşırıqlarla işlədə bilərəm ki, bu tapşırıqların köməyi ilə qovşaqlar yaddaşdan yığılmağa başlayacaq, CPU üzərində. Mən çoxlu podları işlətdiyim zaman onlardan gələn məlumatlar anbara daxil olmalıdır, yəni və s. Həddindən artıq məlumat daxil olduqda, yaddaş çox yavaş geri qaytarmağa başlayır - və Kubernetes küt olmağa başlayır.
Və daha bir problem ... Bildiyiniz kimi, Kubernetes idarəetmələri bir növ mərkəzi şey deyil, bir neçə komponentdir. Orada, xüsusən də nəzarətçi meneceri, planlaşdırıcı və s. Bütün bu uşaqlar eyni vaxtda lazımsız axmaq işlərlə məşğul olmağa başlayacaqlar ki, bu da zaman keçdikcə daha çox vaxt aparmağa başlayacaq. Nəzarətçi meneceri yeni podlar yaradacaq. Planlayıcı onlar üçün yeni qovşaq tapmağa çalışacaq. Klasterinizdə yeni qovşaqlar çox güman ki, tezliklə tükənəcək. Kubernetes klasteri daha yavaş və daha yavaş işləməyə başlayacaq.
Ancaq daha da irəli getməyə qərar verdim. Bildiyiniz kimi, Kubernetesdə xidmət deyilən bir şey var. Yaxşı, klasterlərinizdə standart olaraq, xidmət IP cədvəllərindən istifadə edərək işləyir.
Məsələn, bir milyard pod işlətsəniz və sonra Kubernetisin yeni xidmətlər yaratmağa məcbur etmək üçün skriptdən istifadə etsəniz:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Klasterin bütün qovşaqlarında təxminən eyni vaxtda getdikcə daha çox yeni iptables qaydaları yaradılacaq. Üstəlik, hər xidmət üçün bir milyard iptables qaydaları yaradılacaq.
Mən bütün bunları bir neçə min, on ilə qədər yoxladım. Problem ondadır ki, artıq bu ərəfədə node üçün ssh etmək olduqca problemlidir. Çünki bu qədər zəncirdən keçən paketlər özlərini çox yaxşı hiss etməyə başlayır.
Bütün bunlar da Kubernetesin köməyi ilə həll olunur. Belə bir obyekt var Resurs kvotası. Klasterdəki ad sahəsi üçün mövcud resursların və obyektlərin sayını təyin edir. Hər Kubernetes klaster ad məkanında yaml obyekti yarada bilərik. Bu obyektin köməyi ilə deyə bilərik ki, bizim müəyyən sayda sorğularımız, bu ad məkanı üçün ayrılmış limitlər var və daha sonra deyə bilərik ki, bu ad məkanında 10 xidmət və 10 pod yaratmaq mümkündür. Və tək bir tərtibatçı hətta axşamlar özünü əzə bilər. Kubernetes ona deyəcək: "Siz podlarınızı belə bir məbləğə miqyaslaya bilməzsiniz, çünki bu, resurs kvotasını aşır." Budur, problem həll olundu. .
Bununla bağlı bir problem yaranır. Kubernetes-də ad sahəsi yaratmağın nə qədər çətin olduğunu hiss edirsiniz. Onu yaratmaq üçün bir çox şeyi nəzərə almalıyıq.
Resurs kvotası + Limit Aralığı + RBAC
• Ad sahəsi yaradın
• İçəridə sərhəd yaradın
• Daxili resurs kvotası yaradın
• CI üçün xidmət hesabı yaradın
• CI və istifadəçilər üçün rol bağlama yaradın
• İstənilən halda lazımi xidmət podlarını işə salın
Ona görə də fürsətdən istifadə edərək, öz inkişaflarımı bölüşmək istərdim. SDK operatoru deyilən bir şey var. Bu, Kubernetes klasterində bunun üçün bəyanatlar yazmağın yoludur. Ansible ilə ifadələr yaza bilərsiniz.
Əvvəlcə Ansible-da yazdıq, sonra SDK operatorunun nə olduğuna baxdım və Ansible rolunu yenidən operatora yazdım. Bu ifadə Kubernetes klasterində əmr adlanan obyekt yaratmağa imkan verir. Əmrin daxilində bu əmr üçün mühiti yaml-da təsvir etməyə imkan verir. Komanda mühitində isə bu, bizə çoxlu resurs ayırdığımızı təsvir etməyə imkan verir.
Kiçik .
Və yekunda. Bütün bunlarla nə etmək lazımdır?
Birinci. Pod Təhlükəsizlik Siyasəti yaxşıdır. Kubernetes quraşdırıcılarından heç birinin bu günə qədər onlardan istifadə etməməsinə baxmayaraq, siz hələ də onları çoxluqlarınızda istifadə etməlisiniz.
Şəbəkə Siyasəti başqa bir lazımsız xüsusiyyət deyil. Çoxluqda həqiqətən lazım olan budur.
LimitRange / ResourceQuota - istifadə etmək vaxtıdır. Biz onu çoxdan istifadə etməyə başladıq və uzun müddətdir ki, istisnasız olaraq hamının istifadə etdiyinə əmin idim. Məlum oldu ki, bu nadirdir.
Hesabat zamanı qeyd etdiklərimə əlavə olaraq, klasterə hücum etməyə imkan verən sənədsiz xüsusiyyətlər var. Bu yaxınlarda buraxıldı .
Bəzi şeylər çox üzücü və incidir. Məsələn, müəyyən şərtlər altında Kubernetes klasterindəki kubetlər warlocks kataloqunun məzmununu və icazəsiz istifadəçiyə verə bilər.
dediyim hər şeyi necə təkrarlamaq barədə təlimatlar var. ResourceQuota, Pod Təhlükəsizlik Siyasətinin necə göründüyü istehsal nümunələri olan fayllar var. Və bütün bunlara toxunmaq olar.
Hamıya təşəkkürlər.
Mənbə: www.habr.com