{"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":"Si t\u00eb mbyllni boshll\u00ebqet n\u00eb nj\u00eb klaster Kubernetes. Referat dhe transkriptim nga DevOpsConf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, arkitekt zgjidhjesh n\u00eb Southbridge dhe lektor i Slurm, mbajti nj\u00eb referat n\u00eb DevOpsConf 2019. Ky referat \u00ebsht\u00eb pjes\u00eb e nj\u00eb prej temave t\u00eb kursit t\u00eb avancuar p\u00ebr Kubernetes \u201cSlurm Mega\u201d.<\/p>\n

<\/p>\n

Slurm Basic: hyrje n\u00eb Kubernetes<\/a><\/noindex> mbahet n\u00eb Mosk\u00eb m\u00eb 18-20 n\u00ebntor.
\nSlurm Mega: nj\u00eb v\u00ebshtrim n\u00ebn kapakun e Kubernetes<\/a><\/noindex> \u2014 Mosk\u00eb, 22-24 n\u00ebntor.
\nSlurm Online: t\u00eb dy kurset p\u00ebr Kubernetes<\/a><\/noindex> \u00ebsht\u00eb i disponuesh\u00ebm gjithmon\u00eb.<\/p>\n

\n

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

M\u00eb posht\u00eb \u00ebsht\u00eb transkriptimi i referatit.<\/p>\n

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

Mir\u00ebdita, koleg\u00eb dhe t\u00eb gjith\u00eb ata q\u00eb merren me k\u00ebt\u00eb fush\u00eb. Sot do t\u00eb flas p\u00ebr sigurin\u00eb.<\/p>\n

<\/p>\n

Shoh q\u00eb sot n\u00eb sall\u00eb ka shum\u00eb specialist\u00eb t\u00eb siguris\u00eb. Ju k\u00ebrkoj ndjes\u00eb paraprakisht n\u00ebse disa terma nga bota e siguris\u00eb nuk do t\u2019i p\u00ebrdor tamam ashtu si\u00e7 jeni m\u00ebsuar ju. <\/p>\n

<\/p>\n

Rreth gjasht\u00eb muaj m\u00eb par\u00eb, m\u00eb ra n\u00eb dor\u00eb nj\u00eb klaster publik Kubernetes. Publik do t\u00eb thot\u00eb q\u00eb aty kishte nj\u00eb num\u00ebr t\u00eb caktuar namespacesh, n\u00eb k\u00ebto namespace kishte users, t\u00eb izoluar secili brenda namespace-it t\u00eb vet. T\u00eb gjith\u00eb k\u00ebta p\u00ebrdorues i p\u00ebrkisnin kompanive t\u00eb ndryshme. Ideja ishte q\u00eb ky klaster t\u00eb p\u00ebrdorej si CDN. Pra, ju japin klasterin, ju japin nj\u00eb p\u00ebrdorues, ju hyni n\u00eb namespace-in tuaj dhe deployoni frontend-et tuaja. <\/p>\n

<\/p>\n

K\u00ebt\u00eb sh\u00ebrbim u p\u00ebrpoq\u00ebn t\u2019ia shisnin kompanis\u00eb sime t\u00eb m\u00ebparshme. Mua m\u00eb k\u00ebrkuan ta testoja klasterin p\u00ebr t\u00eb kuptuar n\u00ebse nj\u00eb zgjidhje e till\u00eb ishte e p\u00ebrshtatshme apo jo. <\/p>\n

<\/p>\n

Hyra n\u00eb at\u00eb klaster. M\u00eb dhan\u00eb t\u00eb drejta t\u00eb kufizuara dhe nj\u00eb namespace t\u00eb kufizuar. Ata e kuptonin \u00e7far\u00eb \u00ebsht\u00eb siguria. Kishin lexuar p\u00ebr Role-based access control (RBAC) n\u00eb Kubernetes dhe e kishin shtr\u00ebnguar aq shum\u00eb, sa nuk mund t\u00eb nisja pods ve\u00e7mas nga deployments. Nuk e mbaj mend m\u00eb \u00e7far\u00eb detyre po p\u00ebrpiqesha t\u00eb zgjidhja duke nisur nj\u00eb pod pa deployment, por doja shum\u00eb t\u00eb nisja thjesht nj\u00eb pod. Vendosa, sa p\u00ebr prov\u00eb, t\u00eb shihja \u00e7far\u00eb t\u00eb drejtash kisha n\u00eb klaster, \u00e7far\u00eb mund t\u00eb b\u00ebja e \u00e7far\u00eb jo, dhe \u00e7far\u00eb kishin konfiguruar aty. Po ashtu do t\u2019ju tregoj edhe \u00e7far\u00eb kishin t\u00eb konfiguruar gabim n\u00eb RBAC. <\/p>\n

<\/p>\n

Dhe k\u00ebshtu ndodhi q\u00eb pas dy minutash mora t\u00eb drejta administratori n\u00eb klasterin e tyre, pash\u00eb t\u00eb gjitha namespaces fqinje dhe aty gjeta frontend-e production t\u00eb kompanive q\u00eb e kishin bler\u00eb tashm\u00eb sh\u00ebrbimin dhe ishin deployuar. Mezi e p\u00ebrmbajta veten q\u00eb t\u00eb mos hyja te frontend-i i dikujt dhe t\u00eb mos vendosja ndonj\u00eb fjal\u00eb banale n\u00eb faqen kryesore. <\/p>\n

<\/p>\n

Do t\u2019ju tregoj me shembuj si e b\u00ebra k\u00ebt\u00eb dhe si duhet t\u00eb mbroheni prej saj. <\/p>\n

<\/p>\n

Por s\u00eb pari, po prezantohem. Quhem Pavel Selivanov. Jam arkitekt n\u00eb Southbridge. Merrem me Kubernetes, DevOps dhe gjith\u00eb ato gj\u00ebra moderne. Bashk\u00eb me inxhinier\u00ebt e Southbridge i nd\u00ebrtojm\u00eb t\u00eb gjitha k\u00ebto, nd\u00ebrsa un\u00eb merrem me konsulenc\u00eb. <\/p>\n

<\/p>\n

P\u00ebrve\u00e7 aktivitetit ton\u00eb kryesor, s\u00eb fundmi kemi nisur edhe projekte q\u00eb quhen Slurm. Po p\u00ebrpiqemi ta sjellim p\u00ebrvoj\u00ebn ton\u00eb me Kubernetes m\u00eb pran\u00eb audienc\u00ebs s\u00eb gjer\u00eb, q\u00eb t\u2019u m\u00ebsojm\u00eb edhe t\u00eb tjer\u00ebve si t\u00eb punojn\u00eb me K8s. <\/p>\n

<\/p>\n

P\u00ebr \u00e7far\u00eb do t\u00eb flas sot. Tema e prezantimit \u00ebsht\u00eb e qart\u00eb \u2014 siguria e nj\u00eb klasteri Kubernetes. Por dua ta them menj\u00ebher\u00eb se kjo \u00ebsht\u00eb nj\u00eb tem\u00eb shum\u00eb e gjer\u00eb, ndaj po e sqaroj q\u00eb tani se p\u00ebr \u00e7far\u00eb nuk do t\u00eb flas. Nuk do t\u00eb ndalem te termat e konsumuar, q\u00eb n\u00eb internet jan\u00eb p\u00ebrtypur tashm\u00eb qindra her\u00eb. Si RBAC dhe certifikatat. <\/p>\n

<\/p>\n

Do t\u00eb flas p\u00ebr at\u00eb q\u00eb m\u00eb shqet\u00ebson mua dhe koleg\u00ebt e mi te siguria n\u00eb nj\u00eb klaster Kubernetes. K\u00ebto probleme i shohim si te ofruesit q\u00eb ofrojn\u00eb klaster\u00eb Kubernetes, ashtu edhe te klient\u00ebt q\u00eb vijn\u00eb tek ne. Madje edhe te klient\u00ebt q\u00eb na vijn\u00eb nga kompani t\u00eb tjera konsulence dhe administrimi. Pra, n\u00eb fakt p\u00ebrmasat e problemit jan\u00eb shum\u00eb t\u00eb m\u00ebdha. <\/p>\n

<\/p>\n

Vet\u00ebm tre pika p\u00ebr t\u00eb cilat do t\u00eb flas sot: <\/p>\n

<\/p>\n

    \n
  1. T\u00eb drejtat e p\u00ebrdoruesve kundrejt t\u00eb drejtave t\u00eb pod-eve. T\u00eb drejtat e p\u00ebrdoruesve dhe t\u00eb drejtat e pod-eve nuk jan\u00eb e nj\u00ebjta gj\u00eb. <\/li>\n
  2. Mbledhja e informacionit p\u00ebr klasterin. Do t\u00eb tregoj se si nga klasteri mund t\u00eb merret i gjith\u00eb informacioni i nevojsh\u00ebm, edhe pa pasur privilegje t\u00eb ve\u00e7anta n\u00eb t\u00eb. <\/li>\n
  3. Sulm DoS ndaj klasterit. Edhe n\u00ebse nuk arrijm\u00eb t\u00eb mbledhim informacion, prap\u00ebseprap\u00eb mund ta rr\u00ebzojm\u00eb klasterin. Do t\u00eb flas p\u00ebr sulmet DoS ndaj elementeve t\u00eb kontrollit t\u00eb klasterit. <\/li>\n<\/ol>\n

    <\/p>\n

    Edhe nj\u00eb gj\u00eb e p\u00ebrgjithshme q\u00eb do ta p\u00ebrmend \u00ebsht\u00eb se ku i kam testuar t\u00eb gjitha k\u00ebto, pra mbi \u00e7far\u00eb baze mund t\u00eb them me siguri se e gjith\u00eb kjo funksionon.<\/p>\n

    <\/p>\n

    Si baz\u00eb marrim instalimin e nj\u00eb klasteri Kubernetes me ndihm\u00ebn e Kubespray. N\u00ebse dikush nuk e di, n\u00eb thelb \u00ebsht\u00eb nj\u00eb grup rolesh p\u00ebr Ansible. Ne e p\u00ebrdorim vazhdimisht n\u00eb pun\u00ebn ton\u00eb. E mira e tij \u00ebsht\u00eb se mund t\u00eb vendoset kudo: si n\u00eb server\u00eb fizik\u00eb, ashtu edhe n\u00eb cloud. Nj\u00eb m\u00ebnyr\u00eb instalimi \u00ebsht\u00eb praktikisht e p\u00ebrshtatshme p\u00ebr gjith\u00e7ka. <\/p>\n

    <\/p>\n

    N\u00eb k\u00ebt\u00eb klaster do t\u00eb kem Kubernetes v1.14.5. I gjith\u00eb klasteri Kubernetes q\u00eb do t\u00eb shqyrtojm\u00eb \u00ebsht\u00eb i ndar\u00eb n\u00eb namespace, dhe secili namespace i p\u00ebrket nj\u00eb ekipi t\u00eb ve\u00e7ant\u00eb; n\u00eb \u00e7do namespace kan\u00eb qasje vet\u00ebm an\u00ebtar\u00ebt e atij ekipi. Ata nuk mund t\u00eb hyjn\u00eb n\u00eb namespace t\u00eb tjera, vet\u00ebm n\u00eb t\u00eb vetin. Por ekziston nj\u00eb llogari administratori q\u00eb ka t\u00eb drejta n\u00eb t\u00eb gjith\u00eb klasterin. <\/p>\n

    <\/p>\n

    \"Si<\/p>\n

    <\/p>\n

    Premtova q\u00eb hapi i par\u00eb do t\u00eb ishte marrja e t\u00eb drejtave t\u00eb administratorit n\u00eb klaster. Na duhet nj\u00eb pod i p\u00ebrgatitur posa\u00e7\u00ebrisht, q\u00eb do t\u00eb komprometoj\u00eb klasterin Kubernetes. Gjith\u00e7ka q\u00eb duhet t\u00eb b\u00ebjm\u00eb \u00ebsht\u00eb ta aplikojm\u00eb at\u00eb n\u00eb klasterin Kubernetes. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Ky pod do t\u00eb vendoset n\u00eb nj\u00eb nga master\u00ebt e klasterit Kubernetes. Pas k\u00ebsaj, klasteri do t\u00eb na kthej\u00eb me k\u00ebnaq\u00ebsi nj\u00eb skedar q\u00eb quhet admin.conf. N\u00eb Kubernetes, n\u00eb k\u00ebt\u00eb skedar ruhen t\u00eb gjitha certifikatat e administratorit, si edhe konfigurimi i API-s\u00eb s\u00eb klasterit. Kaq thjesht mund t\u00eb merret qasje administratori, mendoj, n\u00eb rreth 98% t\u00eb klaster\u00ebve Kubernetes. <\/p>\n
    <\/p>\n
    Po e p\u00ebrs\u00ebris: k\u00ebt\u00eb pod e krijoi nj\u00eb zhvillues n\u00eb klasterin tuaj, i cili ka t\u00eb drejt\u00eb t\u00eb deployoj\u00eb aplikacionet e veta n\u00eb nj\u00eb namespace t\u00eb vog\u00ebl, plot\u00ebsisht t\u00eb kufizuar nga RBAC. Nuk kishte fare privilegje. Megjithat\u00eb, certifikata u kthye. <\/p>\n
    <\/p>\n
    Tani p\u00ebr pod-in e p\u00ebrgatitur posa\u00e7\u00ebrisht. E nisim mbi \u00e7far\u00ebdo image. P\u00ebr shembull, le t\u00eb marrim debian:jessie. <\/p>\n
    <\/p>\n
    Kemi di\u00e7ka 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 toleration? Master\u00ebt n\u00eb nj\u00eb klaster Kubernetes zakonisht sh\u00ebnohen me di\u00e7ka q\u00eb quhet taint. Thelbi i k\u00ebtij taint \u00ebsht\u00eb q\u00eb ai tregon se n\u00eb nyjet master nuk lejohen t\u00eb caktohen pod-e. Por asgj\u00eb nuk e pengon q\u00eb n\u00eb \u00e7do pod t\u00eb specifikohet se ai e toleron k\u00ebt\u00eb taint. Seksioni Toleration pik\u00ebrisht k\u00ebt\u00eb thot\u00eb: n\u00ebse n\u00eb nj\u00eb nyje \u00ebsht\u00eb vendosur NoSchedule, at\u00ebher\u00eb pod-i yn\u00eb e toleron at\u00eb taint dhe nuk ka asnj\u00eb problem. <\/p>\n
    <\/p>\n
    M\u00eb tej, themi se pod-i yn\u00eb jo vet\u00ebm q\u00eb e toleron k\u00ebt\u00eb, por d\u00ebshiron t\u00eb shkoj\u00eb n\u00eb m\u00ebnyr\u00eb t\u00eb q\u00ebllimshme te master\u00ebt. Sepse pik\u00ebrisht te master\u00ebt ndodhet ajo q\u00eb na duhet m\u00eb shum\u00eb: t\u00eb gjitha certifikatat. Prandaj p\u00ebrdorim nodeSelector, dhe n\u00eb master\u00eb kemi nj\u00eb label standard q\u00eb na lejon t\u00eb zgjedhim nga t\u00eb gjitha nyjet e klasterit pik\u00ebrisht ato q\u00eb jan\u00eb master. <\/p>\n
    <\/p>\n
    Me k\u00ebto dy seksione, pod-i do t\u00eb vendoset patjet\u00ebr n\u00eb master. Dhe do t\u00eb lejohet t\u00eb q\u00ebndroj\u00eb atje. <\/p>\n
    <\/p>\n
    Por vet\u00ebm vendosja n\u00eb master nuk mjafton. Kjo nuk na jep asgj\u00eb. Prandaj m\u00eb tej kemi edhe k\u00ebto dy gj\u00ebra:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Ne po p\u00ebrcaktojm\u00eb q\u00eb pod-i yn\u00eb, t\u00eb cilin e nisim, do t\u00eb ekzistoj\u00eb n\u00eb namespace-in e kernelit, n\u00eb namespace-in e rrjetit dhe n\u00eb namespace-in PID. Sapo pod-i t\u00eb niset n\u00eb master, ai do t\u00eb mund t\u00eb shoh\u00eb t\u00eb gjitha nd\u00ebrfaqet reale e aktive 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 gjitha proceseve.<\/p>\n
    <\/p>\n
    M\u00eb pas gjith\u00e7ka \u00ebsht\u00eb e thjesht\u00eb. Merrni etcd dhe lexoni \u00e7far\u00eb t\u00eb doni. <\/p>\n
    <\/p>\n
    M\u00eb interesantja \u00ebsht\u00eb se kjo \u00ebsht\u00eb nj\u00eb ve\u00e7ori e Kubernetes q\u00eb ekziston aty si parazgjedhje. <\/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 \u00ebsht\u00eb q\u00eb n\u00eb pod-in q\u00eb nisim, edhe pa pasur t\u00eb drejta n\u00eb k\u00ebt\u00eb klaster, mund t\u00eb deklarojm\u00eb se duam t\u00eb krijojm\u00eb nj\u00eb volume t\u00eb tipit hostPath. Kjo do t\u00eb thot\u00eb t\u00eb marrim nj\u00eb shteg nga host-i ku do t\u00eb nisim pod-in dhe ta p\u00ebrdorim si volume. M\u00eb pas i japim emrin name: host. T\u00eb gjith\u00eb k\u00ebt\u00eb hostPath e montojm\u00eb brenda pod-it. N\u00eb k\u00ebt\u00eb shembull, n\u00eb direktorin\u00eb \/host. <\/p>\n
    <\/p>\n
    Po e p\u00ebrs\u00ebris edhe nj\u00eb her\u00eb. I tham\u00eb pod-it t\u00eb shkonte n\u00eb master, t\u00eb merrte aty hostNetwork dhe hostPID, dhe t\u00eb montonte t\u00eb gjith\u00eb root-in e master-it brenda k\u00ebtij pod-i. <\/p>\n
    <\/p>\n
    Ju e kuptoni q\u00eb n\u00eb Debian kemi t\u00eb nisur bash, dhe ky bash ekzekutohet si root. Pra, sapo mor\u00ebm root n\u00eb master, pa pasur ndonj\u00eb lloj t\u00eb drejte n\u00eb klasterin Kubernetes.<\/p>\n
    <\/p>\n
    M\u00eb pas e gjith\u00eb detyra \u00ebsht\u00eb t\u00eb hyni n\u00eb pod, n\u00eb direktorinin\u00eb \/host \/etc\/kubernetes\/pki, n\u00ebse nuk gaboj, t\u00eb merrni prej andej t\u00eb gjitha certifikatat e master-it t\u00eb klasterit dhe, rrjedhimisht, t\u00eb b\u00ebheni 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, pavar\u00ebsisht se \u00e7far\u00eb t\u00eb drejtash ka p\u00ebrdoruesi:
    \n\"Si<\/p>\n
    <\/p>\n
    N\u00ebse kam t\u00eb drejt\u00eb t\u00eb nis nj\u00eb pod n\u00eb nj\u00eb namespace t\u00eb caktuar t\u00eb klasterit, at\u00ebher\u00eb ky pod i ka k\u00ebto t\u00eb drejta si parazgjedhje. Un\u00eb mund t\u00eb nis pod-e t\u00eb privilegjuar, dhe kjo do t\u00eb thot\u00eb praktikisht t\u00eb gjitha t\u00eb drejtat, pothuajse root n\u00eb node. <\/p>\n
    <\/p>\n
    E preferuara ime \u00ebsht\u00eb Root user. Nd\u00ebrsa Kubernetes ka nj\u00eb opsion t\u00eb till\u00eb si Run As Non-Root. \u00cbsht\u00eb nj\u00eb lloj mbrojtjeje kund\u00ebr hakerit. E dini \u00e7far\u00eb \u00ebsht\u00eb \u201cvirusi moldav\u201d? N\u00ebse rast\u00ebsisht je haker dhe ke hyr\u00eb n\u00eb klasterin tim Kubernetes, ne administrator\u00ebt e shkret\u00eb t\u00eb lutemi: \u201cT\u00eb lutem, specifiko n\u00eb pod-et me t\u00eb cilat do t\u00eb sulmosh klasterin tim q\u00eb t\u00eb p\u00ebrdoret run as non-root. P\u00ebrndryshe, mund t\u00eb ndodh\u00eb q\u00eb ta nisesh procesin n\u00eb pod-in t\u00ebnd si root dhe do ta kesh shum\u00eb t\u00eb leht\u00eb t\u00eb m\u00eb sulmosh. T\u00eb lutem, mbrohu nga vetja vet\u00eb\u201d. <\/p>\n
    <\/p>\n
    Host path volume \u2014 sipas meje, \u00ebsht\u00eb m\u00ebnyra m\u00eb e shpejt\u00eb p\u00ebr t\u00eb arritur rezultatin e d\u00ebshiruar nga nj\u00eb klaster Kubernetes. <\/p>\n
    <\/p>\n
    Por \u00e7far\u00eb duhet b\u00ebr\u00eb me gjith\u00eb k\u00ebt\u00eb? <\/p>\n
    <\/p>\n
    Mendimet q\u00eb duhet t\u2019i vijn\u00eb \u00e7do administratori normal kur p\u00ebrballet me Kubernetes: \u00abJa pra, e thash\u00eb un\u00eb, Kubernetes nuk funksionon. Ka vrima. Dhe i gjith\u00eb Kubi \u00ebsht\u00eb kot\u00bb. N\u00eb fakt, ekziston nj\u00eb gj\u00eb e quajtur dokumentacion dhe, n\u00ebse e hapni, aty ka nj\u00eb seksion Pod Security Policy<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Ky \u00ebsht\u00eb nj\u00eb objekt yaml q\u00eb mund ta krijojm\u00eb n\u00eb nj\u00eb klaster Kubernetes dhe q\u00eb kontrollon aspektet e siguris\u00eb pik\u00ebrisht n\u00eb p\u00ebrshkrimin e pod-eve. Pra, n\u00eb praktik\u00eb ai kontrollon t\u00eb drejtat p\u00ebr p\u00ebrdorimin e gj\u00ebrave si hostNetwork, hostPID, lloje t\u00eb caktuara t\u00eb volume-ve, t\u00eb cilat pod-et i kan\u00eb gjat\u00eb nisjes. Me Pod Security Policy e gjith\u00eb kjo mund t\u00eb p\u00ebrshkruhet. <\/p>\n
    <\/p>\n
    Gj\u00ebja m\u00eb interesante te Pod Security Policy \u00ebsht\u00eb se n\u00eb klasterin Kubernetes, te t\u00eb gjith\u00eb instaluesit, PSP jo vet\u00ebm q\u00eb nuk \u00ebsht\u00eb i p\u00ebrshkruar fare, por \u00ebsht\u00eb thjesht i \u00e7aktivizuar si parazgjedhje. Pod Security Policy aktivizohet me ndihm\u00ebn e admission plugin.<\/p>\n
    <\/p>\n
    N\u00eb rregull, le t\u00eb deploy-ojm\u00eb Pod Security Policy n\u00eb klaster dhe t\u00eb p\u00ebrcaktojm\u00eb se kemi disa pod-e sh\u00ebrbimi n\u00eb nj\u00eb namespace ku kan\u00eb akses vet\u00ebm administrator\u00ebt. Nd\u00ebrsa p\u00ebr t\u00eb gjith\u00eb t\u00eb tjer\u00ebt, pod-et do t\u00eb ken\u00eb t\u00eb drejta t\u00eb kufizuara. Sepse ka shum\u00eb t\u00eb ngjar\u00eb q\u00eb zhvilluesve t\u00eb mos u duhet t\u00eb ekzekutojn\u00eb pod-e t\u00eb privilegjuar n\u00eb klasterin tuaj. <\/p>\n
    <\/p>\n
    Dhe duket sikur gjith\u00e7ka \u00ebsht\u00eb n\u00eb rregull. Dhe klasteri yn\u00eb Kubernetes nuk mund t\u00eb komprometohet p\u00ebr dy minuta. <\/p>\n
    <\/p>\n
    Ka nj\u00eb problem. Ka shum\u00eb t\u00eb ngjar\u00eb q\u00eb, n\u00ebse keni nj\u00eb klaster Kubernetes, at\u00ebher\u00eb n\u00eb klasterin tuaj \u00ebsht\u00eb instaluar monitorim. Madje guxoj t\u00eb parashikoj se, n\u00ebse n\u00eb klasterin tuaj ka monitorim, ai quhet Prometheus. <\/p>\n
    <\/p>\n
    Ajo q\u00eb do t\u00eb tregoj tani do t\u00eb jet\u00eb e vlefshme si p\u00ebr Prometheus Operator, ashtu edhe p\u00ebr Prometheus t\u00eb instaluar n\u00eb form\u00ebn e tij t\u00eb past\u00ebr. \u00c7\u00ebshtja \u00ebsht\u00eb se, n\u00ebse nuk mund t\u00eb marr kaq shpejt akses administratori n\u00eb klaster, kjo do t\u00eb thot\u00eb se m\u00eb duhet t\u00eb k\u00ebrkoj m\u00eb shum\u00eb. Dhe mund ta b\u00ebj k\u00ebt\u00eb k\u00ebrkim me ndihm\u00ebn e monitorimit tuaj.<\/p>\n
    <\/p>\n
    Me shum\u00eb gjas\u00eb, t\u00eb gjith\u00eb kan\u00eb lexuar t\u00eb nj\u00ebjtat artikuj n\u00eb Habr dhe monitorimi ndodhet n\u00eb namespace monitoring. Helm chart quhet pothuajse nj\u00ebsoj te t\u00eb gjith\u00eb. Supozoj se, n\u00ebse b\u00ebni helm install stable\/prometheus, do t\u00eb merrni af\u00ebrsisht t\u00eb nj\u00ebjtat emra. Dhe madje ka shum\u00eb mund\u00ebsi q\u00eb t\u00eb mos m\u00eb duhet as t\u00eb hamend\u00ebsoj emrin DNS n\u00eb klasterin tuaj. Sepse ai \u00ebsht\u00eb standard. <\/p>\n
    <\/p>\n
    \"Si<\/p>\n
    <\/p>\n
    M\u00eb pas kemi nj\u00eb dev ns, ku mund t\u00eb niset 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 q\u00eb mbledh metrika nga vet\u00eb API i Kubernetes. Aty ka shum\u00eb t\u00eb dh\u00ebna p\u00ebr at\u00eb q\u00eb po ekzekutohet n\u00eb cluster-in tuaj, \u00e7far\u00eb \u00ebsht\u00eb dhe \u00e7far\u00eb problemesh keni me t\u00eb. <\/p>\n
    <\/p>\n
    Si shembull i thjesht\u00eb: <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\u00abkube-system\u00bb,pod=\u00abkube-apiserver-k8s- 1\u00bb,container=\u00abkube-apiserver\u00bb,image= <\/p>\n
    <\/p>\n
    \u00abgcr.io\/google-containers\/kube-apiserver:v1.14.5\u00bb <\/strong><\/p>\n
    <\/p>\n
    ,image_id=\u00abdocker-pullable:\/\/gcr.io\/google-containers\/kube-apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a9638ee634989\u00bb,container_id=\u00abdocker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2853397d7daf08e72c22d3cf8b\u00bb} 1 <\/p>\n
    <\/p>\n
    Duke b\u00ebr\u00eb nj\u00eb k\u00ebrkes\u00eb t\u00eb thjesht\u00eb curl nga nj\u00eb pod jo i privilegjuar, mund t\u00eb merrni pik\u00ebrisht nj\u00eb informacion t\u00eb till\u00eb. N\u00ebse nuk e dini se n\u00eb cilin version t\u00eb Kubernetes po punoni, ai do t\u2019jua tregoj\u00eb fare leht\u00eb. <\/p>\n
    <\/p>\n
    Dhe m\u00eb interesantja \u00ebsht\u00eb se, p\u00ebrve\u00e7se i drejtoheni kube-state-metrics, po aq leht\u00eb mund t\u2019i drejtoheni edhe vet\u00eb Prometheus drejtp\u00ebrdrejt. Mund t\u00eb mblidhni metrika prej tij. Madje mund t\u00eb nd\u00ebrtoni edhe metrika prej andej. Teorikisht, mund t\u00eb nd\u00ebrtoni nga cluster-i edhe nj\u00eb k\u00ebrkes\u00eb t\u00eb till\u00eb drejt Prometheus q\u00eb thjesht ta rr\u00ebzoj\u00eb at\u00eb. Dhe monitorimi juaj do t\u00eb ndaloj\u00eb s\u00eb funksionuari fare p\u00ebr cluster-in. <\/p>\n
    <\/p>\n
    Dhe k\u00ebtu lind tashm\u00eb pyetja n\u00ebse monitorimi juaj monitorohet nga ndonj\u00eb sistem i jasht\u00ebm monitorimi. Sapo mora mund\u00ebsin\u00eb t\u00eb veproj n\u00eb cluster-in Kubernetes pa asnj\u00eb pasoj\u00eb p\u00ebr veten time. Madje as nuk do ta kuptoni q\u00eb po veproj aty, sepse monitorimi nuk ekziston m\u00eb. <\/p>\n
    <\/p>\n
    Ashtu si me PSP, krijohet p\u00ebrshtypja sikur problemi q\u00ebndron te fakti se t\u00eb gjitha k\u00ebto teknologji moderne \u2014 Kubernetes, Prometheus \u2014 thjesht nuk funksionojn\u00eb dhe jan\u00eb plot me vrima. N\u00eb fakt, jo. <\/p>\n
    <\/p>\n
    Ekziston nj\u00eb gj\u00eb e till\u00eb \u2014 Network Policy<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    N\u00ebse jeni nj\u00eb administrator normal, me shum\u00eb gjas\u00eb p\u00ebr Network Policy dini vet\u00ebm se \u00ebsht\u00eb edhe nj\u00eb YAML tjet\u00ebr, nga ata q\u00eb n\u00eb cluster ka tashm\u00eb plot e p\u00ebrplot. Dhe se Network Policies nuk duhen fare. Edhe n\u00ebse e keni lexuar se \u00e7far\u00eb \u00ebsht\u00eb Network Policy, q\u00eb \u00ebsht\u00eb nj\u00eb firewall YAML i Kubernetes, i cili ju lejon t\u00eb kufizoni t\u00eb drejtat e aksesit midis namespace-ve dhe midis pod-eve, me siguri keni vendosur se nj\u00eb firewall n\u00eb format YAML n\u00eb Kubernetes, mbi nj\u00eb shtres\u00eb tjet\u00ebr abstraksioni... Jo, jo. Kjo me siguri nuk duhet. <\/p>\n
    <\/p>\n
    Edhe n\u00ebse specialist\u00ebt tuaj t\u00eb siguris\u00eb nuk ju kan\u00eb th\u00ebn\u00eb se me Kubernetes-in tuaj mund t\u00eb nd\u00ebrtoni shum\u00eb leht\u00eb nj\u00eb firewall, madje shum\u00eb t\u00eb detajuar. N\u00ebse ende nuk e din\u00eb k\u00ebt\u00eb dhe nuk ju ngacmojn\u00eb me: \u00abHajde, na jepni\u2026\u00bb, gjithsesi ju duhen Network Policy q\u00eb t\u00eb kufizoni aksesin te disa pika sh\u00ebrbimi, t\u00eb cilat mund t\u00eb arrihen nga klasteri juaj pa pasur asnj\u00eb autorizim. <\/p>\n
    <\/p>\n
    Si n\u00eb shembullin q\u00eb p\u00ebrmenda, kube state metrics mund t\u00eb arrihet nga \u00e7do namespace n\u00eb klasterin Kubernetes pa pasur asnj\u00eb t\u00eb drejt\u00eb p\u00ebr k\u00ebt\u00eb. Network policies e mbyll\u00ebn aksesin nga t\u00eb gjith\u00eb namespace-et e tjera drejt namespace-it t\u00eb monitorimit dhe kaq: s\u2019ka akses, s\u2019ka problem. N\u00eb t\u00eb gjitha chart-et q\u00eb ekzistojn\u00eb, si te Prometheus standard ashtu edhe te ai q\u00eb vjen n\u00eb operator, n\u00eb Helm values ka thjesht nj\u00eb opsion p\u00ebr t\u2019i aktivizuar network policies p\u00ebr to. Mjafton ta aktivizoni dhe ato do t\u00eb funksionojn\u00eb. <\/p>\n
    <\/p>\n
    Megjithat\u00eb, k\u00ebtu ka nj\u00eb problem. Si nj\u00eb admin klasik me p\u00ebrvoj\u00eb, me shum\u00eb gjas\u00eb keni vendosur se network policies nuk ju duhen. Dhe pasi keni lexuar artikuj t\u00eb ndrysh\u00ebm n\u00eb burime si Habr, keni vendosur se flannel, sidomos n\u00eb regjimin host-gateway, \u00ebsht\u00eb zgjedhja m\u00eb e mir\u00eb q\u00eb mund t\u00eb b\u00ebni. <\/p>\n
    <\/p>\n
    \u00c7far\u00eb t\u00eb b\u00ebjm\u00eb? <\/p>\n
    <\/p>\n
    Mund t\u00eb provoni ta rideploy-oni zgjidhjen e rrjetit q\u00eb keni n\u00eb klasterin tuaj Kubernetes, pra ta z\u00ebvend\u00ebsoni me di\u00e7ka m\u00eb funksionale. P\u00ebr shembull, me Calico. Por dua ta them menj\u00ebher\u00eb: detyra p\u00ebr t\u00eb ndryshuar zgjidhjen e rrjetit n\u00eb nj\u00eb klaster Kubernetes n\u00eb prodhim nuk \u00ebsht\u00eb aspak e thjesht\u00eb. Un\u00eb e kam zgjidhur dy her\u00eb k\u00ebt\u00eb \u00e7\u00ebshtje (edhe pse t\u00eb dyja her\u00ebt teorikisht), madje edhe n\u00eb Slurm kemi treguar si b\u00ebhet. P\u00ebr pjes\u00ebmarr\u00ebsit tan\u00eb n\u00eb trajnim kemi demonstruar si t\u00eb ndryshohet zgjidhja e rrjetit n\u00eb nj\u00eb klaster Kubernetes. N\u00eb parim, mund t\u00eb p\u00ebrpiqeni ta b\u00ebni pa downtime n\u00eb klasterin e prodhimit. Por me shum\u00eb gjas\u00eb nuk do t\u2019ia dilni. <\/p>\n
    <\/p>\n
    Dhe n\u00eb fakt problemi zgjidhet shum\u00eb thjesht. N\u00eb klaster ka certifikata dhe ju e dini q\u00eb ato do t\u00eb skadojn\u00eb pas nj\u00eb viti. Zakonisht zgjidhja tipike p\u00ebr certifikatat n\u00eb klaster \u00ebsht\u00eb: pse t\u00eb lodhemi, ngrem\u00eb nj\u00eb klaster t\u00eb ri pran\u00eb tij, t\u00eb vjetri le t\u00eb skadoj\u00eb dhe i rideploy-ojm\u00eb t\u00eb gjitha. E v\u00ebrteta \u00ebsht\u00eb se, kur t\u00eb skadojn\u00eb, p\u00ebr nj\u00eb dit\u00eb gjith\u00e7ka do t\u00eb q\u00ebndroj\u00eb jasht\u00eb funksionit, por ama do t\u00eb kemi nj\u00eb klaster t\u00eb ri. <\/p>\n
    <\/p>\n
    Kur t\u00eb ngrini klasterin e ri, vendosni nj\u00ebkoh\u00ebsisht Calico n\u00eb vend t\u00eb flannel. <\/p>\n
    <\/p>\n
    \u00c7far\u00eb t\u00eb b\u00ebni n\u00ebse certifikatat tuaja jan\u00eb l\u00ebshuar p\u00ebr nj\u00ebqind vjet dhe nuk keni nd\u00ebrmend ta rideploy-oni klasterin? Ekziston nj\u00eb mjet i quajtur Kube-RBAC-Proxy. \u00cbsht\u00eb nj\u00eb zgjidhje shum\u00eb e mir\u00eb q\u00eb mund t\u00eb integrohet si sidecar container me \u00e7do pod n\u00eb klasterin Kubernetes. N\u00eb praktik\u00eb, ajo i shton atij pod-i autorizimin p\u00ebrmes RBAC t\u00eb vet\u00eb Kubernetes. <\/p>\n
    <\/p>\n
    Ka vet\u00ebm nj\u00eb problem. M\u00eb par\u00eb, n\u00eb Prometheus Operator, kjo zgjidhje Kube-RBAC-Proxy ishte e integruar. Por m\u00eb pas u hoq. Tani versionet moderne mb\u00ebshteten te fakti q\u00eb ju keni network policy dhe e kufizoni aksesin p\u00ebrmes tyre. Prandaj do t\u00eb duhet t\u00eb rishkruani pak chart-in. N\u00eb fakt, n\u00ebse hyni te k\u00ebt\u00eb depo<\/a><\/noindex>, aty ka shembuj se si t\u00eb p\u00ebrdoret si sidecar, dhe chart-et do t\u00eb duhet t\u00eb ndryshohen shum\u00eb pak. <\/p>\n
    <\/p>\n
    Ka edhe nj\u00eb problem tjet\u00ebr t\u00eb vog\u00ebl. Jo vet\u00ebm Prometheus i ekspozon metrikat e veta kujtdo. Edhe t\u00eb gjith\u00eb komponent\u00ebt e klasterit Kubernetes din\u00eb t\u2019i ekspozojn\u00eb metrikat e tyre. <\/p>\n
    <\/p>\n
    Por si\u00e7 e thash\u00eb edhe m\u00eb par\u00eb, n\u00ebse nuk mund t\u00eb marr\u00ebsh akses n\u00eb klaster dhe t\u00eb mbledh\u00ebsh informacion, t\u00eb pakt\u00ebn mund t\u00eb b\u00ebsh d\u00ebm. <\/p>\n
    <\/p>\n
    Prandaj do t\u2019ju tregoj shpejt dy m\u00ebnyra se si mund t\u2019ia prishni sh\u00ebndetin nj\u00eb klasteri Kubernetes. <\/p>\n
    <\/p>\n
    Do t\u00eb qeshni kur t\u2019jua tregoj k\u00ebt\u00eb, sepse jan\u00eb dy raste nga jeta reale. <\/p>\n
    <\/p>\n
    M\u00ebnyra e par\u00eb. Shterimi i burimeve. <\/p>\n
    <\/p>\n
    Nisim edhe nj\u00eb pod t\u00eb posa\u00e7\u00ebm. 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, requests \u00ebsht\u00eb sasia e CPU dhe memories q\u00eb rezervohet n\u00eb host p\u00ebr pod-et p\u00ebrkat\u00ebse. N\u00ebse kemi nj\u00eb host me kat\u00ebr b\u00ebrthama n\u00eb klasterin Kubernetes dhe aty vendoset nj\u00eb pod me requests prej kat\u00ebr CPU, at\u00ebher\u00eb asnj\u00eb pod tjet\u00ebr me requests nuk do t\u00eb mund t\u00eb vendoset m\u00eb n\u00eb at\u00eb host. <\/p>\n
    <\/p>\n
    N\u00ebse nis nj\u00eb pod t\u00eb till\u00eb dhe pastaj ekzekutoj komand\u00ebn: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    At\u00ebher\u00eb askush tjet\u00ebr nuk do t\u00eb mund t\u00eb deploy-oj\u00eb m\u00eb n\u00eb klasterin Kubernetes. Sepse n\u00eb t\u00eb gjitha nyjet do t\u00eb mbarojn\u00eb requests. Dhe n\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb un\u00eb do ta ndal klasterin tuaj Kubernetes. N\u00ebse e b\u00ebj k\u00ebt\u00eb n\u00eb mbr\u00ebmje, mund t\u2019i bllokoj deploy-et p\u00ebr nj\u00eb koh\u00eb goxha t\u00eb gjat\u00eb. <\/p>\n
    <\/p>\n
    N\u00ebse i hedhim edhe nj\u00eb her\u00eb nj\u00eb sy dokumentacionit t\u00eb Kubernetes, do t\u00eb shohim nj\u00eb mekaniz\u00ebm q\u00eb quhet Limit Range. Ai p\u00ebrcakton kufijt\u00eb e burimeve p\u00ebr objektet e klasterit. Mund t\u00eb krijoni nj\u00eb objekt Limit Range n\u00eb YAML, ta aplikoni n\u00eb namespace t\u00eb caktuara dhe m\u00eb pas, brenda atij namespace-i, t\u00eb p\u00ebrcaktoni vlera t\u00eb parazgjedhura, maksimale dhe minimale t\u00eb burimeve p\u00ebr pod-et.<\/p>\n
    <\/p>\n
    Me k\u00ebt\u00eb mekaniz\u00ebm mund t\u2019i kufizojm\u00eb p\u00ebrdoruesit n\u00eb namespace-et konkrete t\u00eb produkteve ose ekipeve, q\u00eb t\u00eb mos vendosin \u00e7far\u00ebdo parametrash t\u00eb pap\u00ebrshtatsh\u00ebm te pod-et e tyre. Por, p\u00ebr fat t\u00eb keq, edhe n\u00ebse i thoni p\u00ebrdoruesit se nuk lejohet t\u00eb nis\u00eb pod-e me requests mbi nj\u00eb CPU, ekziston komanda scale, ose mund ta b\u00ebjn\u00eb scaling edhe p\u00ebrmes dashboard-it.<\/p>\n
    <\/p>\n
    Dhe prej k\u00ebtej vjen m\u00ebnyra num\u00ebr dy: t\u00eb nisim 11 111 111 111 111 pod-e. Jan\u00eb nj\u00ebmb\u00ebdhjet\u00eb miliard\u00eb. Jo sepse e shpika un\u00eb k\u00ebt\u00eb num\u00ebr, por sepse e kam par\u00eb vet\u00eb. <\/p>\n
    <\/p>\n
    Histori e v\u00ebrtet\u00eb. Nj\u00eb mbr\u00ebmje von\u00eb po b\u00ebhesha gati t\u00eb largohesha nga zyra. Shoh q\u00eb n\u00eb nj\u00eb cep rrinte nj\u00eb grup zhvilluesish dhe po b\u00ebnin di\u00e7ka me nxitim n\u00eb laptop\u00ebt e tyre. Afrohem te djemt\u00eb dhe i pyes: \u00ab\u00c7far\u00eb ka ndodhur?\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 b\u00ebhej gati t\u00eb shkonte n\u00eb sht\u00ebpi. Dhe vendosi: \u00abTani do ta b\u00ebj scale aplikacionin tim n\u00eb nj\u00eb\u00bb. Shtypi nj\u00ebshen, por interneti u ngadal\u00ebsua pak. E shtypi edhe nj\u00eb her\u00eb nj\u00ebshen, e mbajti t\u00eb shtypur, klikoi Enter. Preku gjith\u00e7ka q\u00eb mundi. Pastaj interneti u rikthye \u2014 dhe gjith\u00e7ka filloi t\u00eb b\u00ebnte scale drejt atij numri. <\/p>\n
    <\/p>\n
    N\u00eb t\u00eb v\u00ebrtet\u00eb, kjo histori nuk ndodhi n\u00eb Kubernetes; n\u00eb at\u00eb koh\u00eb ishte Nomad. P\u00ebrfundoi k\u00ebshtu: pas nj\u00eb ore p\u00ebrpjekjesh tona p\u00ebr ta ndaluar Nomad-in nga p\u00ebrpjekjet k\u00ebmb\u00ebngul\u00ebse p\u00ebr t\u00eb b\u00ebr\u00eb scale, Nomad u p\u00ebrgjigj se nuk do t\u00eb ndalonte s\u00eb b\u00ebri scale dhe nuk do t\u00eb merrej me asgj\u00eb tjet\u00ebr. \u00abU lodha, po iki\u00bb. Dhe u mbyll. <\/p>\n
    <\/p>\n
    Natyrisht, provova t\u00eb b\u00ebja t\u00eb nj\u00ebjt\u00ebn gj\u00eb edhe n\u00eb Kubernetes. Nj\u00ebmb\u00ebdhjet\u00eb miliard\u00eb pod-e nuk e g\u00ebzuan Kubernetes-in; ai tha: \u00abNuk mundem. Tejkalon kufijt\u00eb e brendsh\u00ebm\u00bb. Por 1 000 000 000 pod-e i p\u00ebrballoi. <\/p>\n
    <\/p>\n
    Si p\u00ebrgjigje ndaj nj\u00eb miliardi, Kube nuk u bllokua n\u00eb vetvete. N\u00eb fakt, ai filloi t\u00eb shkall\u00ebzohej. Sa m\u00eb tej shkonte procesi, aq m\u00eb shum\u00eb koh\u00eb i duhej p\u00ebr t\u00eb krijuar pod-e t\u00eb reja. Megjithat\u00eb, procesi vazhdonte. Problemi i vet\u00ebm \u00ebsht\u00eb se, n\u00ebse n\u00eb namespace-in tim mund t\u00eb nis pa kufi pod-e, at\u00ebher\u00eb edhe pa requests dhe limits mund t\u00eb l\u00ebshoj aq shum\u00eb pod-e me disa detyra, saq\u00eb p\u00ebr shkak t\u00eb tyre nodet do t\u00eb fillojn\u00eb t\u00eb mbingarkohen nga memoria dhe CPU. Kur nisim kaq shum\u00eb pod-e, informacioni prej tyre duhet t\u00eb shkoj\u00eb n\u00eb storage, dometh\u00ebn\u00eb n\u00eb etcd. Dhe kur aty mb\u00ebrrin tep\u00ebr shum\u00eb informacion, storage fillon t\u00eb p\u00ebrgjigjet shum\u00eb ngadal\u00eb \u2014 dhe Kubernetes fillon t\u00eb ngadal\u00ebsohet ndjesh\u00ebm. <\/p>\n
    <\/p>\n
    Dhe ka edhe nj\u00eb problem tjet\u00ebr\u2026 Si\u00e7 e dini, komponent\u00ebt e menaxhimit t\u00eb Kubernetes nuk jan\u00eb nj\u00eb mekaniz\u00ebm i vet\u00ebm qendror, por disa komponent\u00eb t\u00eb ve\u00e7ant\u00eb. Aty jan\u00eb, n\u00eb ve\u00e7anti, controller manager, scheduler e t\u00eb tjer\u00eb. T\u00eb gjith\u00eb k\u00ebta do t\u00eb fillojn\u00eb nj\u00ebkoh\u00ebsisht t\u00eb kryejn\u00eb pun\u00eb t\u00eb panevojshme dhe joefektive, e cila me kalimin e koh\u00ebs do t\u00eb marr\u00eb gjithnj\u00eb e m\u00eb shum\u00eb koh\u00eb. Controller manager do t\u00eb krijoj\u00eb pod-e t\u00eb reja. Scheduler do t\u00eb p\u00ebrpiqet t\u2019u gjej\u00eb nj\u00eb node t\u00eb re. Nodet e reja n\u00eb cluster-in tuaj, me shum\u00eb gjas\u00eb, do t\u00eb mbarojn\u00eb shpejt. Cluster-i Kubernetes do t\u00eb filloj\u00eb t\u00eb punoj\u00eb gjithnj\u00eb e m\u00eb ngadal\u00eb.<\/p>\n
    <\/p>\n
    Por vendosa t\u00eb shkoj edhe m\u00eb tej. Si\u00e7 e dini, n\u00eb Kubernetes ekziston nj\u00eb mekaniz\u00ebm q\u00eb quhet service. Dhe, si parazgjedhje, n\u00eb cluster-et tuaja, me shum\u00eb gjas\u00eb, service funksionon p\u00ebrmes IP tables. <\/p>\n
    <\/p>\n
    N\u00ebse nisen, p\u00ebr shembull, nj\u00eb miliard pod-e dhe m\u00eb pas me ndihm\u00ebn e nj\u00eb skripti detyrohet Kubernetes t\u00eb krijoj\u00eb service 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 cluster-it, pothuajse nj\u00ebkoh\u00ebsisht, do t\u00eb gjenerohen gjithnj\u00eb e m\u00eb shum\u00eb rregulla t\u00eb reja iptables. Madje, p\u00ebr \u00e7do service do t\u00eb gjenerohet nga nj\u00eb miliard rregullash iptables. <\/p>\n
    <\/p>\n
    E kam testuar gjith\u00eb k\u00ebt\u00eb n\u00eb disa mij\u00ebra, deri n\u00eb rreth dhjet\u00eb mij\u00eb. Problemi \u00ebsht\u00eb se tashm\u00eb n\u00eb k\u00ebt\u00eb nivel b\u00ebhet mjaft e v\u00ebshtir\u00eb t\u00eb lidheni me node-n p\u00ebrmes SSH. Sepse paketat, duke kaluar n\u00ebp\u00ebr kaq shum\u00eb zinxhir\u00eb, fillojn\u00eb t\u00eb mos funksionojn\u00eb edhe aq mir\u00eb. <\/p>\n
    <\/p>\n
    Edhe kjo zgjidhet me Kubernetes. Ekziston nj\u00eb objekt i till\u00eb si Resource quota. Ai p\u00ebrcakton sasin\u00eb e burimeve dhe objekteve t\u00eb disponueshme p\u00ebr namespace-in n\u00eb cluster. Ne mund t\u00eb krijojm\u00eb nj\u00eb objekt yaml n\u00eb \u00e7do namespace t\u00eb cluster-it Kubernetes. Me ndihm\u00ebn e k\u00ebtij objekti mund t\u00eb p\u00ebrcaktojm\u00eb q\u00eb p\u00ebr k\u00ebt\u00eb namespace jan\u00eb caktuar nj\u00eb sasi e caktuar requests, limits, dhe m\u00eb pas mund t\u00eb themi q\u00eb n\u00eb k\u00ebt\u00eb namespace mund t\u00eb krijohen 10 service dhe 10 pod. Dhe zhvilluesi mund t\u00eb provoj\u00eb sa t\u00eb doj\u00eb ta rris\u00eb me nga nj\u00eb. Kubernetes do t\u2019i thot\u00eb: \u00abNuk mund t\u2019i shkall\u00ebzoni pod-et tuaja n\u00eb nj\u00eb num\u00ebr t\u00eb till\u00eb, sepse tejkalohet resource quota\u00bb. Kaq, problemi u zgjidh. Dokumentacioni \u00ebsht\u00eb k\u00ebtu<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Megjithat\u00eb, k\u00ebtu lind nj\u00eb moment problematik. E kuptoni sa e nd\u00ebrlikuar b\u00ebhet krijimi i nj\u00eb namespace n\u00eb Kubernetes. P\u00ebr ta krijuar, duhet t\u00eb marrim parasysh shum\u00eb gj\u00ebra.<\/p>\n
    <\/p>\n
    Resource quota + Limit Range + RBAC
    \n\u2022 Krijojm\u00eb namespace
    \n\u2022 Krijojm\u00eb brenda LimitRange
    \n\u2022 Krijojm\u00eb brenda ResourceQuota
    \n\u2022 Krijojm\u00eb serviceaccount p\u00ebr CI
    \n\u2022 Krijojm\u00eb rolebinding p\u00ebr CI dhe p\u00ebrdoruesit
    \n\u2022 Opsionalisht nisim pod-et e nevojshme t\u00eb sh\u00ebrbimit <\/p>\n
    <\/p>\n
    Prandaj, meq\u00eb ra fjala, dua t\u00eb ndaj me ju zgjidhjet e mia. Ekziston nj\u00eb mjet q\u00eb quhet operator SDK. Kjo \u00ebsht\u00eb nj\u00eb m\u00ebnyr\u00eb p\u00ebr t\u00eb shkruar operator\u00eb p\u00ebr Kubernetes brenda cluster-it. Operator\u00ebt mund t\u2019i shkruani me Ansible.<\/p>\n
    <\/p>\n
    N\u00eb fillim e kishim shkruar me Ansible, por m\u00eb pas pash\u00eb q\u00eb ekziston operator SDK dhe e rishkrova rolin Ansible si operator. Ky operator lejon krijimin n\u00eb cluster-in Kubernetes t\u00eb nj\u00eb objekti q\u00eb quhet ekip. Brenda ekipit ai lejon t\u00eb p\u00ebrshkruhet n\u00eb yaml mjedisi p\u00ebr k\u00ebt\u00eb ekip. Dhe brenda mjedisit t\u00eb ekipit mund t\u00eb p\u00ebrshkruhet se sa burime ndajm\u00eb. <\/p>\n
    <\/p>\n
    Nj\u00eb mjet i vog\u00ebl q\u00eb e thjeshton gjith\u00eb k\u00ebt\u00eb proces t\u00eb nd\u00ebrlikuar<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Dhe n\u00eb p\u00ebrfundim. \u00c7far\u00eb t\u00eb b\u00ebjm\u00eb me gjith\u00eb k\u00ebt\u00eb?
    \nS\u00eb pari. Pod Security Policy \u00ebsht\u00eb gj\u00eb e mir\u00eb. Dhe pavar\u00ebsisht se deri m\u00eb sot asnj\u00eb nga instaluesit e Kubernetes nuk i p\u00ebrdor, gjithsesi ju duhet t\u2019i p\u00ebrdorni n\u00eb cluster-at tuaj. <\/p>\n
    <\/p>\n
    Network Policy nuk \u00ebsht\u00eb ndonj\u00eb ve\u00e7ori tjet\u00ebr e panevojshme. \u00cbsht\u00eb di\u00e7ka q\u00eb i duhet realisht cluster-it. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota \u2014 ka ardhur koha t\u2019i p\u00ebrdorni. Ne kemi koh\u00eb q\u00eb i p\u00ebrdorim dhe p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb kam qen\u00eb i bindur se i p\u00ebrdorin t\u00eb gjith\u00eb. Doli q\u00eb kjo \u00ebsht\u00eb e rrall\u00eb. <\/p>\n
    <\/p>\n
    P\u00ebrve\u00e7 asaj q\u00eb p\u00ebrmenda gjat\u00eb prezantimit, ka ve\u00e7ori t\u00eb padokumentuara q\u00eb mund\u00ebsojn\u00eb sulmin ndaj klasterit. S\u00eb fundi doli nj\u00eb analiz\u00eb e madhe e cenueshm\u00ebrive t\u00eb Kubernetes<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Disa gj\u00ebra jan\u00eb aq t\u00eb trishta dhe zhg\u00ebnjyese. P\u00ebr shembull, n\u00eb disa kushte kubelet-et n\u00eb nj\u00eb klaster Kubernetes mund t\u00eb japin p\u00ebrmbajtjen e direktoris\u00eb warlocks, madje edhe nj\u00eb p\u00ebrdoruesi t\u00eb paautorizuar. <\/p>\n
    <\/p>\n
    K\u00ebtu<\/a><\/noindex> ndodhen udh\u00ebzimet se si t\u00eb riprodhoni gjith\u00e7ka p\u00ebr t\u00eb cil\u00ebn fola. Aty gjenden skedar\u00eb me shembuj production se si duken ResourceQuota dhe Pod Security Policy. Dhe t\u00eb gjitha k\u00ebto mund t\u2019i provoni vet\u00eb. <\/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\udd47Mbyllim vrimat n\u00eb klasterin Kubernetes. Prezantimi dhe transkriptimi nga DevOpsConf | ProHoster","description":"Pavel Selivanov, arkitekt zgjidhjesh n\u00eb Southbridge dhe lektor i Slurm, mbajti nj\u00eb prezantim n\u00eb DevOpsConf 2019.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}