{"id":39203,"date":"2019-10-31T22:28:25","date_gmt":"2019-10-31T19:28:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf\/"},"modified":"2019-10-31T22:28:25","modified_gmt":"2019-10-31T19:28:25","slug":"zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"Mbyllim boshll\u00ebqet n\u00eb klasterin Kubernetes. Raporti dhe sh\u00ebnimi nga DevOpsConf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, arkitekt i zgjidhjeve n\u00eb Southbridge dhe lektori i Slyrm, mbajti nj\u00eb raport n\u00eb DevOpsConf 2019. Ky raport \u00ebsht\u00eb pjes\u00eb e nj\u00eb nga temat e kursit t\u00eb thelluar p\u00ebr Kubernetes \"Slyrm Mega\".<\/p>\n

<\/p>\n

Slyrm Baza: hyrje n\u00eb Kubernetes<\/a><\/noindex> ndodh n\u00eb Mosk\u00eb nga 18-20 N\u00ebntor.
\nSlyrm Mega: hedhim nj\u00eb sy n\u00ebn kapakun e Kubernetes<\/a><\/noindex> \u2014 Mosk\u00eb, 22-24 N\u00ebntor.
\nSlyrm Online: t\u00eb dy kurset p\u00ebr Kubernetes<\/a><\/noindex> kan\u00eb qasje gjithmon\u00eb.<\/p>\n

\n

\r\n \"Luaj\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Posht\u00eb\u2014sh\u00ebnimi i raportit.<\/p>\n

<\/a><\/noindex><\/p>\n

Mir\u00ebdita, koleg\u00ebve dhe atyre q\u00eb ndajn\u00eb shqet\u00ebsimin. Sot do t\u00eb flas p\u00ebr sigurin\u00eb.<\/p>\n

<\/p>\n

V\u00ebrej se n\u00eb sall\u00eb sot jan\u00eb shum\u00eb ekspert\u00eb t\u00eb siguris\u00eb. M\u00eb vjen keq n\u00ebse terminologji nga bota e siguris\u00eb do ta p\u00ebrdor jo ashtu si\u00e7 \u00ebsht\u00eb e zakonshme p\u00ebr ju. <\/p>\n

<\/p>\n

En\u00eb ndodhi q\u00eb diku gjysm\u00eb viti m\u00eb par\u00eb m\u00eb ra n\u00eb dor\u00eb nj\u00eb klas\u00ebr publik Kubernetes. Publik \u2014 do t\u00eb thot\u00eb q\u00eb ka nj\u00eb sasi n-nesh namespaces, ku n\u00eb k\u00ebto namespace ka p\u00ebrdorues, t\u00eb izoluar n\u00eb namespace e tyre. T\u00eb gjith\u00eb k\u00ebta p\u00ebrdorues i p\u00ebrkasin kompanive t\u00eb ndryshme. K\u00ebshtu, parashikohej q\u00eb ky klas\u00ebr t\u00eb p\u00ebrdorej si CDN. Kjo do t\u00eb thot\u00eb se ju jepet nj\u00eb klas\u00ebr, ju jepet nj\u00eb p\u00ebrdorues p\u00ebr at\u00eb, ju hyni n\u00eb namespace tuaj, dhe vendosni aplikacionet tuaja. <\/p>\n

<\/p>\n

Kompania ime e m\u00ebparshme p\u00ebrpiqej t\u00eb m\u00eb shiste nj\u00eb sh\u00ebrbim t\u00eb till\u00eb. Dhe m\u00eb k\u00ebrkuan t\u00eb testoja klasrin p\u00ebr t\u00eb par\u00eb n\u00ebse nj\u00eb zgjidhje e till\u00eb \u00ebsht\u00eb e p\u00ebrshtatshme apo jo. <\/p>\n

<\/p>\n

Arrita n\u00eb k\u00ebt\u00eb klaster. M\u00eb dhan\u00eb t\u00eb drejta t\u00eb kufizuara, nj\u00eb namespace t\u00eb kufizuar. Atje, djemt\u00eb e dinin se \u00e7far\u00eb \u00ebsht\u00eb siguria. Kishin lexuar p\u00ebr kontrollet e aksesit t\u00eb bazuara n\u00eb role (RBAC) t\u00eb Kubernetes \u2014 dhe e kishin vendosur n\u00eb m\u00ebnyr\u00eb q\u00eb nuk mund t\u00eb nisja pod\u00eb pa drith\u00ebrime. Nuk e mbaj mend detyr\u00ebn q\u00eb po p\u00ebrpiqesha t\u00eb zgjidhja, duke nisur nj\u00eb pod pa drith\u00ebrim, por isha shum\u00eb i interesuar p\u00ebr ta nisur thjesht nj\u00eb pod. Vendosa t\u00eb shoh me fat se \u00e7far\u00eb t\u00eb drejtash kisha n\u00eb klaster, \u00e7far\u00eb mundesha, \u00e7far\u00eb nuk mundesha, \u00e7far\u00eb kishin vendosur atje. Po ashtu, do t\u00eb tregoj se \u00e7far\u00eb \u00ebsht\u00eb vendosur gabimisht n\u00eb RBAC-n\u00eb e tyre. <\/p>\n

<\/p>\n

Ishte nj\u00eb rast q\u00eb pas dy minutash morava admin n\u00eb klasterin e tyre, shikoja n\u00eb t\u00eb gjitha namespaces fqinje, pash\u00eb atje fronte prodhimi t\u00eb kompanive q\u00eb kishin bler\u00eb sh\u00ebrbimin dhe ishin deployuar. E pata shum\u00eb t\u00eb v\u00ebshtir\u00eb t\u00eb ndalesha q\u00eb t\u00eb mos shkoja te dikush n\u00eb front dhe n\u00eb faqen kryesore t\u00eb vendosja ndonj\u00eb fjal\u00eb t\u00eb pahijshme. <\/p>\n

<\/p>\n

Do t\u00eb tregoj me shembuj se si e b\u00ebra k\u00ebt\u00eb dhe si duhet mbrojtur nga ajo. <\/p>\n

<\/p>\n

Por fillim, lejoni t\u00eb prezantohem. Emri im \u00ebsht\u00eb Pavel Selivanov. Jam arkitekt i kompanis\u00eb Southbridge. Kam njohuri n\u00eb Kubernetes, DevOps dhe gj\u00ebra t\u00eb tjera moderne. Ne me inxhinier\u00ebt e Southbridge po e nd\u00ebrtojm\u00eb k\u00ebt\u00eb, nd\u00ebrsa un\u00eb ofroj k\u00ebshilla. <\/p>\n

<\/p>\n

P\u00ebrve\u00e7 aktivitetit ton\u00eb kryesor, ne sapo kemi lan\u00e7uar projekte q\u00eb quhen Slerms. Ne po p\u00ebrpiqemi t\u00eb ndihmojm\u00eb njer\u00ebzit t\u00eb punojn\u00eb me Kubernetes dhe t\u2019i m\u00ebsojm\u00eb ata si t\u00eb p\u00ebrdorin K8s. <\/p>\n

<\/p>\n

\u00c7far\u00eb do t\u00eb flas sot. Tema e prezantimit \u00ebsht\u00eb e qart\u00eb \u2014 siguria e klasterit Kubernetes. Por dua t\u00eb theksoj se kjo tem\u00eb \u00ebsht\u00eb shum\u00eb e gjer\u00eb \u2014 dhe prandaj dua t\u00eb sqaroj se p\u00ebr \u00e7far\u00eb nuk do t\u00eb flas. Nuk do t\u00eb flas p\u00ebr terma t\u00eb zakonsh\u00ebm q\u00eb jan\u00eb p\u00ebrs\u00ebritur aq shum\u00eb n\u00eb internet. T\u00eb tilla si RBAC dhe certifikat. <\/p>\n

<\/p>\n

Do t\u00eb flas p\u00ebr ato shqet\u00ebsime q\u00eb kam un\u00eb dhe koleg\u00ebt e mi lidhur me sigurin\u00eb n\u00eb klasterin Kubernetes. Ne i shohim k\u00ebto probleme tek ofruesit q\u00eb ofrojn\u00eb klastere Kubernetes dhe te klient\u00ebt q\u00eb vijn\u00eb tek ne. Edhe tek klient\u00ebt q\u00eb na vijn\u00eb nga kompani t\u00eb tjera konsulente administratash. Pra, n\u00eb t\u00eb v\u00ebrtet\u00eb, shkalla e tragjedis\u00eb \u00ebsht\u00eb shum\u00eb e madhe. <\/p>\n

<\/p>\n

Tre pika, p\u00ebr t\u00eb cilat do t\u00eb flas sot: <\/p>\n

<\/p>\n

    \n
  1. T\u00eb drejtat e p\u00ebrdoruesve vs t\u00eb drejtat e pod\u2019\u00ebve. T\u00eb drejtat e p\u00ebrdoruesve dhe t\u00eb drejtat e pod\u2019\u00ebve nuk jan\u00eb t\u00eb nj\u00ebjta. <\/li>\n
  2. Grumbullimi i informacionit p\u00ebr klasterin. Do t\u00eb tregoj se \u00e7far\u00eb informacioni mund t\u00eb grumbullojm\u00eb nga klasteri pa pasur t\u00eb drejta t\u00eb ve\u00e7anta n\u00eb t\u00eb. <\/li>\n
  3. Sulmi DoS ndaj klasterit. N\u00ebse nuk arrijm\u00eb t\u00eb grumbullojm\u00eb informacion, ne mund ta d\u00ebshtojm\u00eb klasterin n\u00eb \u00e7do rast. Do t\u00eb flas p\u00ebr sulmet DoS ndaj elementeve menaxhuese t\u00eb klasterit. <\/li>\n<\/ol>\n

    <\/p>\n

    Nj\u00eb tjet\u00ebr gj\u00eb e p\u00ebrgjithshme q\u00eb do t\u00eb p\u00ebrmend \u00ebsht\u00eb se mbi \u00e7far\u00eb kam testuar gjith\u00e7ka dhe mbi \u00e7far\u00eb mund t\u00eb them me siguri se gjith\u00e7ka funksionon.<\/p>\n

    <\/p>\n

    Marrim si baz\u00eb instalimin e klasterit Kubernetes me an\u00eb t\u00eb Kubespray. N\u00ebse askush nuk e di, kjo \u00ebsht\u00eb n\u00eb thelb nj\u00eb grup rolesh p\u00ebr Ansible. Ne e p\u00ebrdorim at\u00eb vazhdimisht n\u00eb pun\u00eb. \u00cbsht\u00eb i mir\u00eb sepse mund t\u00eb instalohet kudo \u2014 dhe n\u00eb harduer, si edhe n\u00eb ndonj\u00eb cloud. Nj\u00eb m\u00ebnyr\u00eb instalimi \u00ebsht\u00eb e p\u00ebrshtatshme p\u00ebr gjith\u00e7ka. <\/p>\n

    <\/p>\n

    N\u00eb k\u00ebt\u00eb klas\u00ebr do t\u00eb kem Kubernetes v1.14.5. I gjith\u00eb klastri i Kub\u00ebs, q\u00eb do t\u00eb shqyrtojm\u00eb, \u00ebsht\u00eb ndar\u00eb n\u00eb hap\u00ebsira emri, secila hap\u00ebsir\u00eb emri i takon nj\u00eb skuadre t\u00eb ve\u00e7ant\u00eb, dhe an\u00ebtar\u00ebt e k\u00ebsaj skuadre kan\u00eb qasje n\u00eb \u00e7do hap\u00ebsir\u00eb emri. Ata nuk mund t\u00eb hyjn\u00eb n\u00eb hap\u00ebsira t\u00eb tjera, vet\u00ebm n\u00eb t\u00eb tyre. Megjithat\u00eb, ekziston nj\u00eb llogari admini, e cila ka t\u00eb drejta p\u00ebr t\u00eb gjith\u00eb klastri. <\/p>\n

    <\/p>\n

    \"Mbyllim<\/p>\n

    <\/p>\n

    Premtova se e para q\u00eb do t\u00eb b\u00ebjm\u00eb \u00ebsht\u00eb marrja e t\u00eb drejtave admin n\u00eb klas\u00ebr. Na nevojitet nj\u00eb pod i p\u00ebrgatitur posa\u00e7\u00ebrisht, i cili do t\u00eb thyej\u00eb klastrin Kubernetes. E vetmja gj\u00eb q\u00eb duhet t\u00eb b\u00ebjm\u00eb \u00ebsht\u00eb ta aplikojm\u00eb at\u00eb n\u00eb klastrin Kubernetes. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Ky pod do t\u00eb arrij\u00eb n\u00eb nj\u00eb nga masterat e klasit Kubernetes. Dhe klastri do t\u00eb na kthej\u00eb me g\u00ebzim nj\u00eb skedar, i quajtur admin.conf. N\u00eb Kub\u00eb, n\u00eb k\u00ebt\u00eb skedar ruhen t\u00eb gjith\u00eb certifikatat e adminit, dhe gjithashtu konfigurohet API i klasit. K\u00ebshtu kaq thjesht\u00eb mund t\u00eb merret qasje administrative, mendoj, n\u00eb 98% t\u00eb klastrave Kubernetes. <\/p>\n
    <\/p>\n
    T\u00eb p\u00ebrs\u00ebris, ky pod u krijua nga nj\u00eb zhvillues n\u00eb klasrin tuaj, i cili ka akses p\u00ebr t\u00eb shp\u00ebrndar\u00eb propozimet e tij n\u00eb nj\u00eb hap\u00ebsir\u00eb t\u00eb vog\u00ebl emri, ai \u00ebsht\u00eb plot\u00ebsisht i kufizuar nga RBAC. Ai nuk kishte asnj\u00eb t\u00eb drejt\u00eb. Por megjithat\u00eb, certifikata u kthye. <\/p>\n
    <\/p>\n
    Tani p\u00ebr nj\u00eb pod t\u00eb p\u00ebrgatitur posa\u00e7\u00ebrisht. E fillojm\u00eb n\u00eb \u00e7do imazh. P\u00ebr shembull, do t\u00eb marrim debian:jessie. <\/p>\n
    <\/p>\n
    Kemi nj\u00eb gj\u00eb t\u00eb till\u00eb: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    \u00c7far\u00eb \u00ebsht\u00eb tolerimi? Master\u00ebt n\u00eb klusterin Kubernetes zakonisht sh\u00ebnohen me nj\u00eb gj\u00eb q\u00eb quhet taint (\"infeksion\" n\u00eb anglisht). Ideja e k\u00ebsaj \"infeksioni\" \u00ebsht\u00eb se pod-et nuk mund t\u00eb em\u00ebrohen n\u00eb nodet master. Por askush nuk e ndalon caktimin e toleranc\u00ebs ndaj \"infeksionit\" n\u00eb \u00e7do pod. Seksioni Toleration thot\u00eb se n\u00ebse n\u00eb ndonj\u00eb nod\u00eb \u00ebsht\u00eb vendosur NoSchedule, at\u00ebher\u00eb pod-i yn\u00eb \u00ebsht\u00eb tolerues ndaj k\u00ebtij infeksioni \u2014 dhe nuk ka asnj\u00eb problem. <\/p>\n
    <\/p>\n
    Pastaj, ne themi q\u00eb pod-i yn\u00eb jo vet\u00ebm q\u00eb \u00ebsht\u00eb tolerues, por edhe d\u00ebshiron t\u00eb em\u00ebrohet n\u00eb m\u00ebnyr\u00eb specifike n\u00eb master. Sepse n\u00eb mastera ndodhen gj\u00ebrat m\u00eb interesante q\u00eb na duhen \u2014 t\u00eb gjitha certifikatat. Prandaj ne themi nodeSelector \u2014 dhe kemi nj\u00eb etiket\u00eb standarde n\u00eb mastera, e cila lejon t\u00eb zgjedhim nga t\u00eb gjitha nodet e klusterit ato nodet q\u00eb jan\u00eb master. <\/p>\n
    <\/p>\n
    Me k\u00ebto dy seksione, pod-i do t\u00eb arrij\u00eb me siguri n\u00eb master. Dhe atij do t\u2019i lejohet t\u00eb jetoj\u00eb aty. <\/p>\n
    <\/p>\n
    Por t'u mb\u00ebrritur vet\u00ebm n\u00eb master, nuk mjafton. Kjo nuk na sjell asgj\u00eb. Prandaj, kemi k\u00ebto dy gj\u00ebra p\u00ebr t\u00eb vazhduar:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Ne tregojm\u00eb se pods q\u00eb po e ekzekutojm\u00eb, do t\u00eb jetoj\u00eb n\u00eb hap\u00ebsir\u00ebn em\u00ebrore t\u00eb b\u00ebrtham\u00ebs, n\u00eb hap\u00ebsir\u00ebn e rrjetit dhe n\u00eb hap\u00ebsir\u00ebn e PID. Pasi podi t\u00eb filloj\u00eb ekzekutimin n\u00eb master, ai do t\u00eb mund t\u00eb shikoj\u00eb t\u00eb gjitha nd\u00ebrfaqet e v\u00ebrteta, t\u00eb gjalla t\u00eb k\u00ebsaj node, t\u00eb d\u00ebgjoj\u00eb t\u00eb gjith\u00eb trafikun dhe t\u00eb shoh\u00eb PID-t\u00eb e t\u00eb gjith\u00eb proceseve.<\/p>\n
    <\/p>\n
    M\u00eb pas, \u00ebsht\u00eb nj\u00eb \u00e7\u00ebshtje e thjesht\u00eb. Merrni etcd dhe lexoni at\u00eb q\u00eb d\u00ebshironi. <\/p>\n
    <\/p>\n
    M\u00eb e interesante \u00ebsht\u00eb se kjo \u00ebsht\u00eb nj\u00eb mund\u00ebsi e Kubernetes, e cila \u00ebsht\u00eb aty si vendosje default. <\/p>\n
    <\/p>\n
    volumeMounts:\n- mountPath: \/host \n  name: host \nvolumes:\n- hostPath: \n    path: \/ \n    type: Directory \n  name: host <\/code><\/pre>\n
    <\/p>\n
    Dhe thelbi i saj \u00ebsht\u00eb se ne mund t\u00eb themi n\u00eb podin q\u00eb po e ekzekutojm\u00eb, madje pa t\u00eb drejta n\u00eb k\u00ebt\u00eb klas\u00ebr, se duam t\u00eb krijojm\u00eb nj\u00eb volume t\u00eb tipit hostPath. Kjo do t\u00eb thot\u00eb t\u00eb marrim nj\u00eb rrug\u00eb nga hosti, ku do t\u00eb ekzekutojm\u00eb \u2014 dhe ta marrim at\u00eb si volume. M\u00eb pas e quajm\u00eb name: host. E gjith\u00eb ky hostPath montohen brenda podit. N\u00eb k\u00ebt\u00eb shembull n\u00eb direktorine \/host. <\/p>\n
    <\/p>\n
    P\u00ebrs\u00ebri, e p\u00ebrs\u00ebris. I tham\u00eb podit t\u00eb vij\u00eb n\u00eb master, t\u00eb marr\u00eb hostNetwork dhe hostPID \u2014 dhe t\u00eb montoj\u00eb t\u00eb gjith\u00eb root-in e masterit brenda k\u00ebtij podi. <\/p>\n
    <\/p>\n
    Ju e kuptoni se n\u00eb Debian ne kemi hapur bash-in, dhe ky bash po punon n\u00ebn rolin e root-it. Kjo do t\u00eb thot\u00eb se sapo mor\u00ebm t\u00eb drejtat e root n\u00eb master, edhe pa pasur ndonj\u00eb t\u00eb drejt\u00eb n\u00eb klasterin Kubernetes.<\/p>\n
    <\/p>\n
    Pas k\u00ebsaj, detyra e gjith\u00eb \u00ebsht\u00eb t\u00eb hyj\u00eb n\u00eb pod n\u00eb direktorin\u00eb \/host\/etc\/kubernetes\/pki, n\u00ebse nuk gaboj, t\u00eb marr\u00eb atje t\u00eb gjitha certifikat e master-it t\u00eb klasterit dhe, p\u00ebr pasoj\u00eb, t\u00eb b\u00ebhet administrator i klasterit. <\/p>\n
    <\/p>\n
    N\u00ebse e shohim k\u00ebshtu, k\u00ebto jan\u00eb disa nga t\u00eb drejtat m\u00eb t\u00eb rrezikshme n\u00eb pod-e \u2014 pavar\u00ebsisht se \u00e7far\u00eb t\u00eb drejtash ka p\u00ebrdoruesi:
    \n\"Mbyllim<\/p>\n
    <\/p>\n
    N\u00ebse kam t\u00eb drejta p\u00ebr t\u00eb nisur nj\u00eb pod n\u00eb ndonj\u00eb namespace t\u00eb klasterit, at\u00ebher\u00eb ky pod ka k\u00ebto t\u00eb drejta n\u00eb m\u00ebnyr\u00eb t\u00eb paracaktuar. Mund t\u00eb nis pod-e me privilegje, dhe kjo \u00ebsht\u00eb pothuajse si t\u00eb kem t\u00eb drejta t\u00eb plota n\u00eb nod. <\/p>\n
    <\/p>\n
    Preferenca ime \u00ebsht\u00eb p\u00ebrdoruesi Root. Nd\u00ebrsa Kubernetes ka nj\u00eb opsion t\u00eb till\u00eb Run As Non-Root. Kjo \u00ebsht\u00eb nj\u00eb lloj mbrojtjeje nga haker\u00ebt. A dini \u00e7far\u00eb \u00ebsht\u00eb \"virusi moldavis\"? N\u00ebse ndonj\u00eb haker ka ardhur n\u00eb klasterin tim Kubernetes, ne, administrator\u00ebt e varf\u00ebr, k\u00ebrkojm\u00eb: \"Ju lutemi, tregoni n\u00eb pod-et tuaja, me t\u00eb cilat do t\u00eb hakeroni klasterin tim, run as non-root. N\u00ebse jo, at\u00ebher\u00eb ka gjasa q\u00eb t\u00eb filloni procesin n\u00eb pod-in tuaj n\u00ebn root dhe do t\u00eb keni shum\u00eb leht\u00ebsi p\u00ebr t\u00eb m\u00eb hakuar. Mbrohuni, ju lutem, nga vetja juaj.\" <\/p>\n
    <\/p>\n
    Volume i rrug\u00ebs s\u00eb hostit - sipas mendimit tim, m\u00ebnyra m\u00eb e shpejt\u00eb p\u00ebr t\u00eb marr\u00eb rezultatin e d\u00ebshiruar nga klasteri Kubernetes. <\/p>\n
    <\/p>\n
    Por \u00e7far\u00eb t\u00eb b\u00ebjm\u00eb me t\u00eb gjitha k\u00ebto? <\/p>\n
    <\/p>\n
    Mendimet q\u00eb duhet t\u00eb vijn\u00eb n\u00eb kok\u00ebn e \u00e7do administratori normal q\u00eb p\u00ebrballet me Kubernetes: \"Ah, po, e thash\u00eb, Kubernetes nuk punon. Ka vrima. Dhe e gjith\u00eb kjo \u00ebsht\u00eb e kot\u00eb\". N\u00eb t\u00eb v\u00ebrtet\u00eb, ekziston nj\u00eb gj\u00eb e till\u00eb si dokumentacioni, dhe n\u00ebse e shikoni, ka nj\u00eb seksion. Politika e Siguris\u00eb s\u00eb Pod<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Ky \u00ebsht\u00eb nj\u00eb objekt YAML \u2014 mund ta krijojm\u00eb at\u00eb n\u00eb klasterin Kubernetes \u2014 q\u00eb kontrollon aspektet e siguris\u00eb, sakt\u00ebsisht n\u00eb p\u00ebrshkrimin e pod-\u00ebve. Pra, n\u00eb thelb kontrollon ato t\u00eb drejta p\u00ebr p\u00ebrdorimin e hostNetwork, hostPID, dhe disa lloje volume q\u00eb ekzistojn\u00eb n\u00eb pod-et gjat\u00eb ekzekutimit. Me ndihm\u00ebn e Pod Security Policy, \u00e7do gj\u00eb mund t\u00eb p\u00ebrshkruhet. <\/p>\n
    <\/p>\n
    M\u00eb e r\u00ebnd\u00ebsishmja p\u00ebr Pod Security Policy \u00ebsht\u00eb q\u00eb n\u00eb klasterin Kubernetes, t\u00eb gjith\u00eb instaluesit e PSP nuk jan\u00eb vet\u00ebm t\u00eb pap\u00ebrshkruar, ata jan\u00eb thjesht t\u00eb \u00e7aktivizuar si parazgjedhje. Pod Security Policy aktivizohet me ndihm\u00ebn e nj\u00eb plugin-i admission.<\/p>\n
    <\/p>\n
    Okej, do ta d\u00ebrgojm\u00eb Pod Security Policy n\u00eb klaster, duke th\u00ebn\u00eb q\u00eb kemi disa pod-e sh\u00ebrbimi n\u00eb nj\u00eb namespace, t\u00eb cilin e kan\u00eb akses vet\u00ebm administrator\u00ebt. Le t\u00eb themi, n\u00eb t\u00eb gjitha pod-et e tjera, t\u00eb drejtat jan\u00eb t\u00eb kufizuara. Sepse ndoshta zhvilluesit nuk kan\u00eb nevoj\u00eb t\u00eb ekzekutojn\u00eb pod-e me privilegje n\u00eb klasterin tuaj. <\/p>\n
    <\/p>\n
    Dhe duket se gjith\u00e7ka \u00ebsht\u00eb mir\u00eb. Klasteri yn\u00eb Kubernetes nuk mund t\u00eb thyhet p\u00ebr dy minuta. <\/p>\n
    <\/p>\n
    Ka nj\u00eb problem. Ndoshta, n\u00ebse keni nj\u00eb klaster Kubernetes, at\u00ebher\u00eb n\u00eb klasterin tuaj \u00ebsht\u00eb instaluar monitorimi. Madje m\u00eb guxim, parashikoj q\u00eb n\u00eb klasterin tuaj ka monitorim, dhe ai quhet Prometheus. <\/p>\n
    <\/p>\n
    Ajo q\u00eb do t\u00eb tregoj tani do t\u00eb jet\u00eb i vlefsh\u00ebm si p\u00ebr operatorin Prometheus, ashtu edhe p\u00ebr Prometheus-in e instaluar n\u00eb m\u00ebnyr\u00eb t\u00eb past\u00ebr. Problemi \u00ebsht\u00eb se n\u00ebse nuk mund t\u00eb siguroj nj\u00eb administrator n\u00eb kluster kaq shpejt, at\u00ebher\u00eb do t\u00eb thot\u00eb se duhet t\u00eb k\u00ebrkoj m\u00eb shum\u00eb. Dhe mund t\u00eb k\u00ebrkoj p\u00ebrmes monitorimit tuaj.<\/p>\n
    <\/p>\n
    Padyshim, t\u00eb gjith\u00eb jan\u00eb lexuar t\u00eb nj\u00ebjtat artikuj n\u00eb Habr\u00eb, dhe monitorimi ndodhet n\u00eb hap\u00ebsir\u00ebn e emrave monitoring. Helm chart t\u00eb gjith\u00eb i quajn\u00eb m\u00eb ose m\u00eb pak nj\u00ebsoj. Un\u00eb p\u00ebrfytyroj se n\u00ebse b\u00ebni helm install stable\/prometheus, do t\u00eb keni emra p\u00ebraf\u00ebrsisht t\u00eb nj\u00ebjt\u00eb. Dhe edhe me shum\u00eb mund\u00ebsi, emri DNS n\u00eb klusterin tuaj nuk do t\u00eb duhet ta gjej. Sepse \u00ebsht\u00eb standard. <\/p>\n
    <\/p>\n
    \"Mbyllim<\/p>\n
    <\/p>\n
    M\u00eb pas kemi nj\u00eb dev ns, n\u00eb t\u00eb cilin mund t\u00eb fillojm\u00eb nj\u00eb pod. Dhe pastaj nga ky pod \u00ebsht\u00eb shum\u00eb e leht\u00eb t\u00eb b\u00ebhet k\u00ebshtu: <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    prometheus-kube-state-metrics \u00ebsht\u00eb nj\u00eb nga eksportuesit e Prometheus-it, i cili mbledh metrika nga API i Kubernetes vet\u00eb. Ekziston shum\u00eb informacion se \u00e7far\u00eb \u00ebsht\u00eb e aktivizuar n\u00eb klusterin tuaj, si \u00ebsht\u00eb ajo, \u00e7far\u00eb probleme keni me t\u00eb. <\/p>\n
    <\/p>\n
    Si nj\u00eb shembull i thjesht\u00eb: <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\u00abkube-system»,pod=»kube-apiserver-k8s- 1″,container=»kube-apiserver»,image= <\/p>\n
    <\/p>\n
    «gcr.io\/google-containers\/kube-apiserver:v1.14.5» <\/strong><\/p>\n
    <\/p>\n
    ,image_id=»docker-pullable:\/\/gcr.io\/google-containers\/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1 <\/p>\n
    <\/p>\n
    Duke nj\u00eb k\u00ebrkes\u00eb t\u00eb thjesht\u00eb curl nga nj\u00eb pod jo privilegjuar, mund t\u00eb merrni k\u00ebto informacion. N\u00ebse nuk e dini se n\u00eb cil\u00ebn version t\u00eb Kubernetes jeni, ai do t'ju tregoj\u00eb leht\u00ebsisht. <\/p>\n
    <\/p>\n
    Dhe m\u00eb interesante \u00ebsht\u00eb se, p\u00ebrve\u00e7 faktit q\u00eb po i qaseni kube-state-metrics, ju gjithashtu mund ta qaseni direkt Prometheus. Mund t\u00eb mbledhni metrika nga ai. Mund t\u00eb krijoni metrika nga atje. Teori si\u00e7 \u00ebsht\u00eb, mund t\u00eb ndiheni t\u00eb lir\u00eb t\u00eb nd\u00ebrtoni nj\u00eb k\u00ebrkes\u00eb nga klasteri te Prometheus q\u00eb thjesht do ta shuaj\u00eb. Dhe monitorimi juaj gjithashtu do t\u00eb ndaloj\u00eb s\u00eb funksionuari. <\/p>\n
    <\/p>\n
    Dhe k\u00ebtu lind pyetja, a monitoron ndonj\u00eb monitorim i jasht\u00ebm monitorimin tuaj. Para pak \u00e7astesh, pata mund\u00ebsin\u00eb t\u00eb veproj n\u00eb klasterin Kubernetes pa asnj\u00eb pasoj\u00eb p\u00ebr veten time. Ju madje nuk do t\u00eb kuptoni se un\u00eb po veproj aty, pasi nuk ka asnj\u00eb monitorim m\u00eb. <\/p>\n
    <\/p>\n
    Nj\u00ebsoj si me PSP, krijohet p\u00ebrshtypja se problemi q\u00ebndron te k\u00ebto teknologji t\u00eb mod\u00ebs \u2014 Kubernetes, Prometheus \u2014 q\u00eb thjesht nuk funksionojn\u00eb dhe jan\u00eb plot boshll\u00ebqe. N\u00eb t\u00eb v\u00ebrtet\u00eb, nuk \u00ebsht\u00eb ashtu. <\/p>\n
    <\/p>\n
    Ekziston nj\u00eb gj\u00eb \u2014 Politika e Rrjetit<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    N\u00ebse jeni nj\u00eb administrator normal, ndoshta e dini se Politika e Rrjetit \u00ebsht\u00eb nj\u00eb yaml tjet\u00ebr, t\u00eb cil\u00ebt ka mjaft n\u00eb klas\u00ebr. Dhe Politikat e Rrjetit ndoshta nuk jan\u00eb t\u00eb nevojshme. Por edhe n\u00ebse e keni lexuar se \u00e7far\u00eb \u00ebsht\u00eb Politika e Rrjetit, se \u00ebsht\u00eb nj\u00eb firewall yaml i Kubernetesit, i cili lejon t\u00eb kufizoni t\u00eb drejtat e aksesit midis em\u00ebrhap\u00ebsirave, midis pod-\u00ebve, ju patjet\u00ebr keni vendosur se firewall-i n\u00eb formatin yaml n\u00eb Kubernetes \u00ebsht\u00eb nj\u00eb nga ato abstraksione\u2026 Jo, jo. Kjo qart\u00eb nuk \u00ebsht\u00eb e nevojshme. <\/p>\n
    <\/p>\n
    Edhe n\u00ebse specialist\u00ebt tuaj p\u00ebr sigurin\u00eb nuk jan\u00eb informuar se me ndihm\u00ebn e Kubernetesit tuaj mund t\u00eb nd\u00ebrtoni shum\u00eb leht\u00eb dhe thjesht\u00eb nj\u00eb firewall dhe madje shum\u00eb t\u00eb detajuar. N\u00ebse ata nuk e din\u00eb dhe nuk ju shqet\u00ebsojn\u00eb: \"M\u00eb jepni, m\u00eb jepni...\" Ai do t\u00eb jet\u00eb gjithsesi e nevojshme Politika e Rrjetit p\u00ebr t\u00eb bllokuar qasjen n\u00eb disa vende sh\u00ebrbyese, t\u00eb cilat mund t\u00eb t\u00ebrhiqen nga klasfiku, pa pasur asnj\u00eb autorizim. <\/p>\n
    <\/p>\n
    Si n\u00eb shembullin q\u00eb kam dh\u00ebn\u00eb, mund t\u00eb t\u00ebrheq\u00ebsh kube state metrics nga \u00e7do namespace n\u00eb klasterin Kubernetes, pa pasur asnj\u00eb t\u00eb drejt\u00eb p\u00ebr k\u00ebt\u00eb. Politikat e rrjetit e kufizojn\u00eb aksesin nga t\u00eb gjith\u00eb namespaces e tjera n\u00eb namespace-in e monitorimit dhe si\u00e7 duket, asnj\u00eb akses, asnj\u00eb problem. N\u00eb t\u00eb gjitha chart-et q\u00eb ekzistojn\u00eb, dhe prometheus standard dhe prometheus q\u00eb \u00ebsht\u00eb n\u00eb operator, thjesht ka nj\u00eb opsion n\u00eb values e helm p\u00ebr t\u00eb aktivizuar politikat e rrjetit p\u00ebr ta. Thjesht duhet t\u00eb aktivizosh, dhe ato do t\u00eb punojn\u00eb. <\/p>\n
    <\/p>\n
    Ka nj\u00eb problem k\u00ebtu. Duke qen\u00eb nj\u00eb admin normal me mjek\u00ebr, \u00ebsht\u00eb e mundur q\u00eb keni vendosur se politikat e rrjetit nuk jan\u00eb t\u00eb nevojshme. Dhe duke lexuar artikuj t\u00eb ndrysh\u00ebm n\u00eb burime si Habr, keni vendosur se flannel, ve\u00e7an\u00ebrisht me m\u00ebnyr\u00ebn host-gateway, \u00ebsht\u00eb m\u00eb e mira q\u00eb mund t\u00eb zgjidhni. <\/p>\n
    <\/p>\n
    \u00c7far\u00eb t\u00eb b\u00ebjm\u00eb? <\/p>\n
    <\/p>\n
    Mund t\u00eb provoni t\u00eb ri-deploy nj\u00eb zgjidhje rrjeti q\u00eb \u00ebsht\u00eb n\u00eb klasterin tuaj Kubernetes, ose t\u00eb provoni ta ndryshoni me di\u00e7ka m\u00eb funksionale. P\u00ebr shembull, me t\u00eb nj\u00ebjt\u00ebn Calico. Por dua t\u00eb them menj\u00ebher\u00eb, se detyra e ndryshimit t\u00eb zgjidhjes rrjeti n\u00eb nj\u00eb klaster Kubernetes n\u00eb funksion \u00ebsht\u00eb mjaft e komplikuar. E kam zgjidhur dy her\u00eb (t\u00eb dyja her\u00ebt, megjithat\u00eb, n\u00eb m\u00ebnyr\u00eb teorike), por madje ne n\u00eb Sl\u00ebrma kemi treguar si ta b\u00ebjm\u00eb k\u00ebt\u00eb. p\u00ebr ata q\u00eb m\u00ebsojm\u00eb, ne kemi treguar se si t\u00eb ndryshohet zgjidhja rrjeti n\u00eb klasterin Kubernetes. N\u00eb princip mund t\u00eb provoni t\u00eb b\u00ebni k\u00ebshtu, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb mos ket\u00eb nd\u00ebrprerje n\u00eb klasterin e prodhimit. Por ndoshta nuk do t'ju rezultoj\u00eb asgj\u00eb. <\/p>\n
    <\/p>\n
    Dhe problemi n\u00eb t\u00eb v\u00ebrtet\u00eb zgjidhet shum\u00eb leht\u00eb. N\u00eb klaster ka certifikata, dhe ju e dini se certifikatave tuaja do t'u skadoj\u00eb afati pas nj\u00eb viti. N\u00eb p\u00ebrgjith\u00ebsi, zgjidhja normale me certifikatat n\u00eb klaster \u00ebsht\u00eb \u2014 pse t\u00eb shqet\u00ebsohemi, do t\u00eb ngrem\u00eb nj\u00eb klaster t\u00eb ri af\u00ebr, le t\u00eb skadoj\u00eb e vjetra, dhe gjith\u00e7ka do t\u00eb ri-deplojohet. Megjithat\u00eb, kur t\u00eb skadoj\u00eb, do t\u00eb kemi nj\u00eb dit\u00eb q\u00eb do t\u00eb q\u00ebndroj\u00eb, por do t\u00eb kemi nj\u00eb klaster t\u00eb ri. <\/p>\n
    <\/p>\n
    Kur t\u00eb ngrini klasterin e ri, nj\u00ebher\u00ebsh vendosni Calico n\u00eb vend t\u00eb flannel. <\/p>\n
    <\/p>\n
    \u00c7far\u00eb duhet t\u00eb b\u00ebni n\u00ebse keni certifikata t\u00eb l\u00ebshuara p\u00ebr nj\u00ebqind vjet dhe nuk planifikoni t\u00eb ridispononi klasterin? Ka nj\u00eb gj\u00eb q\u00eb quhet Kube-RBAC-Proxy. Kjo \u00ebsht\u00eb nj\u00eb zhvillim shum\u00eb i bukur, q\u00eb lejon t\u00eb integrohet si nj\u00eb container sidecar n\u00eb \u00e7do pod n\u00eb klasterin Kubernetes. Dhe n\u00eb fakt, ajo shton autorizimin p\u00ebr k\u00ebt\u00eb pod p\u00ebrmes RBAC t\u00eb Kubernetesit. <\/p>\n
    <\/p>\n
    Ka nj\u00eb problem. M\u00eb par\u00eb, n\u00eb operatorin Prometheus, kjo zgjidhje Kube-RBAC-Proxy ishte e integruar. Por m\u00eb von\u00eb u hoq. Tani versionet moderne mb\u00ebshteten n\u00eb at\u00eb q\u00eb keni nj\u00eb politik\u00eb rrjeti dhe e mbyllni duke e p\u00ebrdorur at\u00eb. Prandaj do t'ju duhet t\u00eb rishkruani pak kart\u00ebn. N\u00eb t\u00eb v\u00ebrtet\u00eb, n\u00ebse hyni n\u00eb ky repo<\/a><\/noindex>, ka shembuj se si t\u00eb p\u00ebrdoret si sidecars, dhe kartat do t\u00eb duhet t\u00eb rishkruhen minimalisht. <\/p>\n
    <\/p>\n
    Ka edhe nj\u00eb problem t\u00eb vog\u00ebl. Jo vet\u00ebm Prometheus i jep metrikat e tij kujtdo. T\u00eb gjith\u00eb komponent\u00ebt e klasterit Kubernetes gjithashtu din\u00eb t\u00eb japin metrikat e tyre. <\/p>\n
    <\/p>\n
    Por si\u00e7 e thash\u00eb m\u00eb par\u00eb, n\u00ebse nuk mund t\u00eb aksesoni klasterin dhe t\u00eb mbledhni informacion, mund t\u00eb d\u00ebmtoni pak. <\/p>\n
    <\/p>\n
    Tani do t\u00eb tregoj shpejt dy m\u00ebnyra se si mund ta d\u00ebmtoni sh\u00ebndetin e klasterit Kubernetes. <\/p>\n
    <\/p>\n
    Do t\u00eb qeshni kur ta d\u00ebgjoni k\u00ebt\u00eb, jan\u00eb dy raste nga jeta reale. <\/p>\n
    <\/p>\n
    Shtimi i par\u00eb. Shterja e burimeve. <\/p>\n
    <\/p>\n
    Po fillojm\u00eb nj\u00eb pod special tjet\u00ebr. Ai do t\u00eb ket\u00eb nj\u00eb seksion t\u00eb till\u00eb. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Si\u00e7 e dini, k\u00ebrkesat jan\u00eb sasia e CPU-s\u00eb dhe memories q\u00eb rezervohen n\u00eb host p\u00ebr pod-et specifike me k\u00ebrkesa. N\u00ebse kemi nj\u00eb host me kat\u00ebr b\u00ebrthama n\u00eb klasterin Kubernetes, dhe aty vjen nj\u00eb pod me k\u00ebrkesa p\u00ebr kat\u00ebr CPU, at\u00ebher\u00eb do t\u00eb thot\u00eb se asnj\u00eb pod tjet\u00ebr me k\u00ebrkesa nuk mund t\u00eb hyj\u00eb n\u00eb k\u00ebt\u00eb host. <\/p>\n
    <\/p>\n
    N\u00ebse e filloj nj\u00eb pod t\u00eb till\u00eb, m\u00eb pas do t\u00eb jap urdhrin: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Asnj\u00eb tjet\u00ebr nuk do t\u00eb mund t\u00eb deplohet n\u00eb klasterin Kubernetes. Sepse n\u00eb t\u00eb gjitha nodet do t\u00eb p\u00ebrfundojn\u00eb k\u00ebrkesat. Dhe k\u00ebshtu do ta ndaloj klasterin tuaj Kubernetes. N\u00ebse e b\u00ebj k\u00ebt\u00eb n\u00eb mbr\u00ebmje, mund t'i ndaloj deploimet p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb. <\/p>\n
    <\/p>\n
    N\u00ebse ne e shohim p\u00ebrs\u00ebri dokumentacionin e Kubernetes, do t\u00eb shohim nj\u00eb gj\u00eb q\u00eb quhet Limit Range. Ai p\u00ebrcakton burimet p\u00ebr objektet e klasterit. Ju mund t\u00eb shkruani nj\u00eb objekt Limit Range n\u00eb formatin yaml, ta zbatoni n\u00eb hap\u00ebsira t\u00eb caktuara em\u00ebrtimi \u2014 dhe m\u00eb pas n\u00eb k\u00ebt\u00eb hap\u00ebsir\u00eb em\u00ebrtimi mund t\u00eb thoni se keni burime p\u00ebr pod-\u00ebt q\u00eb jan\u00eb me default, maksimale dhe minimale.<\/p>\n
    <\/p>\n
    Me nj\u00eb gj\u00eb t\u00eb till\u00eb ne mund t\u00eb kufizojm\u00eb p\u00ebrdoruesit n\u00eb hap\u00ebsira t\u00eb caktuara produktesh n\u00eb komandat p\u00ebr t\u00eb specifikuar gj\u00ebra t\u00eb pad\u00ebshiruara n\u00eb pod-\u00ebt e tyre. Por fatkeq\u00ebsisht, edhe n\u00ebse i thoni p\u00ebrdoruesit q\u00eb nuk mund t\u00eb krijoni pod-\u00eb me k\u00ebrkesa m\u00eb t\u00eb m\u00ebdha se nj\u00eb CPU, ka nj\u00eb komand\u00eb t\u00eb shk\u00eblqyer scale, ose p\u00ebrmes panelit ata mund t\u00eb b\u00ebjn\u00eb shkall\u00ebzim.<\/p>\n
    <\/p>\n
    Dhe nga kjo rrjedh m\u00ebnyra e dyt\u00eb. Aktivizojm\u00eb 11 111 111 111 111 pod-\u00eb. K\u00ebto jan\u00eb nj\u00ebmb\u00ebdhjet\u00eb miliard\u00eb. Nuk \u00ebsht\u00eb se e kam shpikur k\u00ebt\u00eb num\u00ebr, por sepse vet\u00eb e kam par\u00eb. <\/p>\n
    <\/p>\n
    Nj\u00eb histori e v\u00ebrtet\u00eb. Von\u00eb n\u00eb mbr\u00ebmje po p\u00ebrgatitesha t\u00eb largohem nga zyrja. Shikoj, n\u00eb nj\u00eb qoshe jan\u00eb disa zhvillues dhe po b\u00ebjn\u00eb di\u00e7ka nervoze me laptop\u00ebt e tyre. Po i afrohem dhe e pyes: \u00ab\u00c7far\u00eb po ndodh me ju?\u00bb<\/p>\n
    <\/p>\n
    Pak m\u00eb her\u00ebt, rreth or\u00ebs n\u00ebnt\u00eb t\u00eb mbr\u00ebmjes, nj\u00eb nga zhvilluesit po p\u00ebrgatitej t\u00eb shkonte n\u00eb sht\u00ebpi. Ai vendosi: \"Tani do ta p\u00ebrmir\u00ebsoj aplikacionin tim deri n\u00eb nj\u00eb.\" Shtypi nj\u00eb, por interneti u ngadal\u00ebsua pak. Ai e shtypi s\u00ebrish numrin nj\u00eb, e pati t\u00eb v\u00ebshtir\u00eb ta shtypte, dhe e klikoi Enter. E provokoi \u00e7do gj\u00eb q\u00eb mundi. At\u00ebher\u00eb interneti u zgjuan \u2014 dhe gjith\u00e7ka filloi t\u00eb p\u00ebrmir\u00ebsohej deri n\u00eb at\u00eb num\u00ebr. <\/p>\n
    <\/p>\n
    Megjithat\u00eb, kjo histori nuk ndodhi n\u00eb Kubernetes, at\u00ebher\u00eb ishte Nomad. Kjo p\u00ebrfundoi me p\u00ebrpjekjet tona p\u00ebr t\u00eb ndaluar Nomad nga p\u00ebrpjekjet e tij t\u00eb vazhdueshme p\u00ebr t\u00eb p\u00ebrmir\u00ebsuar, Nomad u p\u00ebrgjigj se nuk do t\u00eb ndalte dhe nuk do t\u00eb b\u00ebnte asgj\u00eb tjet\u00ebr. \"Jam lodhur, po largohem.\" Dhe u t\u00ebrhoq. <\/p>\n
    <\/p>\n
    Natyrisht, un\u00eb provova t\u00eb b\u00ebj t\u00eb nj\u00ebjt\u00ebn gj\u00eb n\u00eb Kubernetes. Nj\u00ebzet e nj\u00eb miliard podash Kubernetes nuk u k\u00ebnaq\u00ebn, ai tha: \"Nuk mundem. Tejkalon kapacitetet e brendshme.\" Por 1 000 000 000 podash ia doli. <\/p>\n
    <\/p>\n
    N\u00eb p\u00ebrgjigje t\u00eb nj\u00eb miliard kub, ai nuk u hodh n\u00eb vete. Ai me t\u00eb v\u00ebrtet\u00eb filloi t\u00eb b\u00ebj\u00eb skalimin. Sa m\u00eb shum\u00eb q\u00eb procesi p\u00ebrparonte, aq m\u00eb shum\u00eb koh\u00eb i duhej p\u00ebr t\u00eb krijuar pods t\u00eb rinj. Por prap\u00eb procesi po ndodhte. Problemi i vet\u00ebm \u00ebsht\u00eb se n\u00ebse un\u00eb mund t\u00eb filloj pods pa kufij n\u00eb hap\u00ebsir\u00ebn time emrin, edhe pa k\u00ebrkesat dhe kufizimet, mund t\u00eb filloj me disa detyra nj\u00eb num\u00ebr t\u00eb till\u00eb pods, sa q\u00eb me k\u00ebto detyra nodet do t\u00eb fillojn\u00eb t\u00eb grumbullojn\u00eb n\u00eb kujtes\u00eb dhe CPU. Kur un\u00eb filloj kaq shum\u00eb pods, informacioni nga ata duhet t\u00eb shkoj\u00eb n\u00eb depo, dometh\u00ebn\u00eb n\u00eb etcd. Dhe kur shum\u00eb informacion arrin atje, depoja fillon t\u00eb jap\u00eb shum\u00eb ngadal\u00eb \u2014 dhe Kubernetes fillon t\u00eb ket\u00eb vonesa. <\/p>\n
    <\/p>\n
    Dhe nj\u00eb problem tjet\u00ebr... Si\u00e7 e dini, element\u00ebt menaxhues t\u00eb Kubernetes-it nuk jan\u00eb nj\u00eb gj\u00eb e vetme qendrore, por disa komponent\u00eb. Atje ve\u00e7an\u00ebrisht ka nj\u00eb menaxher kontrolli, nj\u00eb programues dhe k\u00ebshtu me radh\u00eb. T\u00eb gjith\u00eb k\u00ebta do fillojn\u00eb t\u00eb kryejn\u00eb pun\u00eb t\u00eb panevojshme paralelisht, e cila me kalimin e koh\u00ebs do t\u00eb marr\u00eb gjithnj\u00eb e m\u00eb shum\u00eb dhe m\u00eb shum\u00eb koh\u00eb. Menaxher kontrolli do t\u00eb krijoj\u00eb pod-e t\u00eb reja. Programuesi do t\u00eb p\u00ebrpiqet t'u gjej\u00eb atyre nj\u00eb nod t\u00eb ri. Probabiliteti \u00ebsht\u00eb q\u00eb nodet e reja n\u00eb klasterin tuaj do t\u00eb p\u00ebrfundojn\u00eb s\u00eb shpejti. Klasteri i Kubernetes-it do t\u00eb filloj\u00eb t\u00eb punoj\u00eb gjithnj\u00eb e m\u00eb ngadal\u00eb.<\/p>\n
    <\/p>\n
    Por un\u00eb krijova nj\u00eb hap m\u00eb shum\u00eb. Si\u00e7 e dini, n\u00eb Kubernetes ka nj\u00eb gj\u00eb q\u00eb quhet sh\u00ebrbim. Po ashtu, n\u00eb m\u00ebnyr\u00eb standarde n\u00eb klasterat tuaj, sh\u00ebrbimi, me siguri, punon me ndihm\u00ebn e IP tables. <\/p>\n
    <\/p>\n
    N\u00ebse lan\u00e7oni nj\u00eb miliard pod-e, p\u00ebr shembull, dhe pastaj me ndihm\u00ebn e nj\u00eb skripti e detyroni Kubernetes-in t\u00eb krijoj\u00eb sh\u00ebrbime t\u00eb reja: <\/p>\n
    <\/p>\n
    for i in {1..1111111}; do\n    kubectl expose deployment test --port 80  \n        --overrides=\"{\"apiVersion\": \"v1\", \n           \"metadata\": {\"name\": \"nginx$i\"}}\"; \ndone <\/code><\/pre>\n
    <\/p>\n
    N\u00eb t\u00eb gjitha nodet e klasterit, gjithmon\u00eb do t\u00eb generehen rregulla t\u00eb reja iptables pothuajse nj\u00ebkoh\u00ebsisht. N\u00eb fakt, p\u00ebr \u00e7do sh\u00ebrbim do t\u00eb krijohet nga nj\u00eb miliard rregullash iptables. <\/p>\n
    <\/p>\n
    E kam kontrolluar k\u00ebt\u00eb me disa mij\u00ebra, deri n\u00eb disa dhjet\u00ebra. Problemi \u00ebsht\u00eb se n\u00eb k\u00ebt\u00eb prag, \u00ebsht\u00eb mjaft e v\u00ebshtir\u00eb t\u00eb lidhesh me SSH n\u00eb nod. Sepse pakot, duke kaluar n\u00ebp\u00ebr nj\u00eb num\u00ebr t\u00eb till\u00eb t\u00eb zinxhir\u00ebve, fillojn\u00eb t\u00eb ndihen keq. <\/p>\n
    <\/p>\n
    Dhe gjithashtu zgjidhet me ndihm\u00ebn e Kubernetes. Ka nj\u00eb objekt q\u00eb quhet 'Resource quota'. P\u00ebrcakton numrin e burimeve t\u00eb disponueshme dhe objekteve p\u00ebr nj\u00eb namespace n\u00eb klaster. Ne mund t\u00eb krijojm\u00eb nj\u00eb objekt YAML n\u00eb \u00e7do namespace t\u00eb klasterit Kubernetes. Me an\u00eb t\u00eb k\u00ebtij objekti, mund t\u00eb themi se p\u00ebr k\u00ebt\u00eb namespace jan\u00eb alokuar nj\u00eb num\u00ebr i caktuar k\u00ebrkesash, kufij, dhe m\u00eb pas mund t\u00eb themi se n\u00eb k\u00ebt\u00eb namespace \u00ebsht\u00eb e mundur t\u00eb krijohen 10 sh\u00ebrbime dhe 10 pod. Dhe zhvilluesi mund t\u00eb kaloj\u00eb or\u00eb t\u00eb t\u00ebra gjat\u00eb mbr\u00ebmjeve. Kubernetes do t'i thot\u00eb: \"Nuk mund t\u00eb shkall\u00ebzoni pod\u00ebt tuaj n\u00eb nj\u00eb kaq t\u00eb madhe, sepse kalon kufizimin e burimeve\". E gjitha, problemi zgjidhet. Dokumentacioni ndodhet k\u00ebtu<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Nj\u00eb problem i mundsh\u00ebm lidhur me k\u00ebt\u00eb gjithashtu paraqitet. E ndjeni se sa e v\u00ebshtir\u00eb b\u00ebhet t\u00eb krijoni nj\u00eb hap\u00ebsir\u00eb n\u00eb Kubernetes. P\u00ebr ta krijuar at\u00eb, na nevojitet t\u00eb merremi parasysh shum\u00eb gj\u00ebra.<\/p>\n
    <\/p>\n
    Kota e burimeve + Kufiri i Rangut + RBAC
    \n\u2022 Krijojm\u00eb hap\u00ebsir\u00ebn
    \n\u2022 Krijojm\u00eb brenda kufirit t\u00eb rangut
    \n\u2022 Krijojm\u00eb brenda kot\u00ebs s\u00eb burimeve
    \n\u2022 Krijojm\u00eb llogarin\u00eb e sh\u00ebrbimit p\u00ebr CI
    \n\u2022 Krijojm\u00eb rolebinding p\u00ebr CI dhe p\u00ebrdoruesit
    \n\u2022 Opsionale, nisnim pods e nevojshme <\/p>\n
    <\/p>\n
    Prandaj, duke shfryt\u00ebzuar k\u00ebt\u00eb rast, do t\u00eb doja t\u00eb ndaj zhvillimet e mia. Ka nj\u00eb gj\u00eb, e quajtur operator SDK. Kjo \u00ebsht\u00eb nj\u00eb m\u00ebnyr\u00eb p\u00ebr t\u00eb shkruar operator\u00eb n\u00eb klasterin Kubernetes. Mund t\u00eb shkruani operator\u00eb me ndihm\u00ebn e Ansible.<\/p>\n
    <\/p>\n
    Fillimisht, ne kishim shkruar me Ansible, pastaj pash\u00eb se ekziston operator SDK dhe e kam rib\u00ebr\u00eb rolin e Ansible n\u00eb operator. Ky operator lejon krijimin e nj\u00eb objekti n\u00eb klasterin Kubernetes, i cili quhet komand\u00eb. Brenda komand\u00ebs, ai lejon t\u00eb p\u00ebrshkruajm\u00eb ambientin n\u00eb yaml p\u00ebr k\u00ebt\u00eb komand\u00eb. Dhe brenda ambientit t\u00eb komand\u00ebs ai lejon t\u00eb p\u00ebrcaktojm\u00eb se sa burime po alokojm\u00eb. <\/p>\n
    <\/p>\n
    E vog\u00ebl leht\u00ebsuese e gjith\u00eb k\u00ebtij procesi t\u00eb komplikuar<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Dhe p\u00ebr n\u00eb fund. \u00c7far\u00eb t\u00eb b\u00ebjm\u00eb me t\u00eb gjith\u00eb k\u00ebt\u00eb?
    \nN\u00eb radh\u00eb t\u00eb par\u00eb. Politika e Siguris\u00eb s\u00eb Pod-eve \u00ebsht\u00eb e mir\u00eb. Dhe pavar\u00ebsisht se asnj\u00eb nga instaluar\u00ebt e Kubernetes deri m\u00eb tani nuk i p\u00ebrdor ato, megjithat\u00eb, duhet t'i p\u00ebrdorni n\u00eb klasteret tuaj. <\/p>\n
    <\/p>\n
    Politika e Rrjetit nuk \u00ebsht\u00eb ndonj\u00eb ve\u00e7ori tjet\u00ebr e panevojshme. Kjo \u00ebsht\u00eb ajo q\u00eb n\u00eb klaster \u00ebsht\u00eb v\u00ebrtet e nevojshme. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota \u2014 \u00ebsht\u00eb koha ta p\u00ebrdorni. Ne e kemi filluar k\u00ebt\u00eb prej koh\u00ebsh, dhe mendova se t\u00eb gjith\u00eb k\u00ebshtu e praktikojn\u00eb. Doli se \u00ebsht\u00eb nj\u00eb rast\u00ebsi. <\/p>\n
    <\/p>\n
    P\u00ebrve\u00e7 asaj q\u00eb p\u00ebrmenda gjat\u00eb prezantimit, ka ve\u00e7ori t\u00eb papublikueshme q\u00eb lejojn\u00eb sulmin ndaj klasterit. S\u00eb fundi doli nj\u00eb analiz\u00eb e madhe e vulnerabiliteteve t\u00eb Kubernetes<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Disa gj\u00ebra jan\u00eb aq t\u00eb pik\u00eblluara dhe t\u00eb dhimbshme. Si\u00e7 \u00ebsht\u00eb, n\u00ebn disa kushte, uzurpator\u00ebt n\u00eb klasterin e Kubernetes mund t\u00eb japin p\u00ebrmbajtjen e direktoris\u00eb warlocks, madje p\u00ebr nj\u00eb p\u00ebrdorues t\u00eb paautorizuar. <\/p>\n
    <\/p>\n
    K\u00ebtu<\/a><\/noindex> jan\u00eb instrukcione p\u00ebr t\u00eb riprodhuar gjith\u00e7ka q\u00eb kam folur. Ka skedar\u00eb me shembuj prodhimi, si duken ResourceQuota, Politika e Siguris\u00eb s\u00eb Pod-eve. Dhe gjith\u00e7ka mund t\u00eb provoni. <\/p>\n
    <\/p>\n
    Faleminderit t\u00eb gjith\u00ebve.<\/p>\n
    Burimi: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019. \u042d\u0442\u043e\u0442 \u0434\u043e\u043a\u043b\u0430\u0434 \u2014 \u0447\u0430\u0441\u0442\u044c \u043e\u0434\u043d\u043e\u0439 \u0438\u0437 \u0442\u0435\u043c \u0443\u0433\u043b\u0443\u0431\u043b\u0435\u043d\u043d\u043e\u0433\u043e \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u00ab\u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430\u00bb. \u0421\u043b\u0451\u0440\u043c \u0411\u0430\u0437\u043e\u0432\u044b\u0439: \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 Kubernetes \u043f\u0440\u043e\u0445\u043e\u0434\u0438\u0442 \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 18-20 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430: \u0437\u0430\u0433\u043b\u044f\u0434\u044b\u0432\u0430\u0435\u043c \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442 Kubernetes \u2014 \u041c\u043e\u0441\u043a\u0432\u0430, 22-24 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041e\u043d\u043b\u0430\u0439\u043d: \u043e\u0431\u0430 \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u0434\u043e\u0441\u0442\u0443\u043f\u0435\u043d \u0432\u0441\u0435\u0433\u0434\u0430. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29423,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39203","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Riparojm\u00eb p\u00ebrgjith\u00ebsit\u00eb n\u00eb klasterin Kubernetes. Lezione dhe transkript nga DevOpsConf | ProHoster","description":"Pavel Selivanov, arkitekt i zgjidhjeve n\u00eb Southbridge dhe m\u00ebsues n\u00eb Slyerm, mbajti nj\u00eb leksion n\u00eb DevOpsConf 2019. Ky leksion \u00ebsht\u00eb pjes\u00eb e nj\u00eb prej temave t\u00eb thelluara t\u00eb kursit p\u00ebr Kubernetes \"Slyerm Mega\". Slyerm Baz\u00eb: nj\u00eb hyrje n\u00eb Kubernetes do t\u00eb zhvillohet n\u00eb Mosk\u00eb nga 18-20 n\u00ebntor. Slyerm Mega: hedhim nj\u00eb v\u00ebshtrim n\u00ebn kapu\u00e7in e Kubernetes \u2014 Mosk\u00eb, 22-24 n\u00ebntor. Slyerm Online: t\u00eb dy kursit p\u00ebr Kubernetes jan\u00eb gjithmon\u00eb t\u00eb disponueshme.","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0417\u0430\u0434\u0435\u043b\u044b\u0432\u0430\u0435\u043c \u0434\u044b\u0440\u044b \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u0414\u043e\u043a\u043b\u0430\u0434 \u0438 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0441 DevOpsConf | ProHoster","og:description":"\u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019. \u042d\u0442\u043e\u0442 \u0434\u043e\u043a\u043b\u0430\u0434 \u2014 \u0447\u0430\u0441\u0442\u044c \u043e\u0434\u043d\u043e\u0439 \u0438\u0437 \u0442\u0435\u043c \u0443\u0433\u043b\u0443\u0431\u043b\u0435\u043d\u043d\u043e\u0433\u043e \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u00ab\u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430\u00bb. \u0421\u043b\u0451\u0440\u043c \u0411\u0430\u0437\u043e\u0432\u044b\u0439: \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 Kubernetes \u043f\u0440\u043e\u0445\u043e\u0434\u0438\u0442 \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 18-20 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430: \u0437\u0430\u0433\u043b\u044f\u0434\u044b\u0432\u0430\u0435\u043c \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442 Kubernetes \u2014 \u041c\u043e\u0441\u043a\u0432\u0430, 22-24 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041e\u043d\u043b\u0430\u0439\u043d: \u043e\u0431\u0430 \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u0434\u043e\u0441\u0442\u0443\u043f\u0435\u043d \u0432\u0441\u0435\u0433\u0434\u0430.","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:28:25+00:00","article:modified_time":"2019-10-31T19:28:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39203","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:15:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:43","updated":"2026-01-24 01:15:20"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/39203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}