{"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\/hu\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"A Kubernetes klaszter hi\u00e1nyoss\u00e1gainak bet\u00f6m\u00e9se. El\u0151ad\u00e1s \u00e9s jegyzet a DevOpsConf-r\u00f3l.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, a solutions architect at Southbridge and a Slurm instructor, gave a presentation at DevOpsConf 2019. This presentation is part of one of the advanced topics in the Kubernetes course 'Slurm Mega'.<\/p>\n

<\/p>\n

Slurm Alap: Bevezet\u00e9s a Kubernetes-be<\/a><\/noindex> Moszkv\u00e1ban zajlik, november 18-20.
\nSlurm Mega: Benevez\u00e9s a Kubernetes motorh\u00e1zteteje al\u00e1<\/a><\/noindex> \u2014 Moszkva, november 22-24.
\nSlurm Online: mindk\u00e9t tanfolyam a Kubernetesr\u0151l<\/a><\/noindex> mindig el\u00e9rhet\u0151.<\/p>\n

\n

\r\n \"Vide\u00f3\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

A folytat\u00e1sban \u2013 a besz\u00e1mol\u00f3 feldolgoz\u00e1sa.<\/p>\n

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

J\u00f3 napot k\u00edv\u00e1nok, koll\u00e9g\u00e1k \u00e9s szimpatiz\u00e1nsaik. Ma a biztons\u00e1gr\u00f3l fogok mes\u00e9lni.<\/p>\n

<\/p>\n

L\u00e1tom, hogy sok biztons\u00e1gi szakember van a teremben. El\u0151re is eln\u00e9z\u00e9st k\u00e9rek, ha a biztons\u00e1g vil\u00e1g\u00e1b\u00f3l sz\u00e1rmaz\u00f3 kifejez\u00e9seket nem pontosan \u00fagy haszn\u00e1lom, ahogy az \u00f6n\u00f6kn\u00e9l megszokott. <\/p>\n

<\/p>\n

\u00dagy alakult, hogy k\u00f6r\u00fclbel\u00fcl f\u00e9l \u00e9vvel ezel\u0151tt kezembe ker\u00fclt egy nyilv\u00e1nos Kubernetes klaszter. Nyilv\u00e1nos \u2013 ez azt jelenti, hogy van benne n sz\u00e1m\u00fa namespace, \u00e9s ezekben a namespace-ekben vannak felhaszn\u00e1l\u00f3k, akik a saj\u00e1t namespace-j\u00fckbe vannak izol\u00e1lva. Mindezek a felhaszn\u00e1l\u00f3k k\u00fcl\u00f6nb\u00f6z\u0151 c\u00e9gekhez tartoznak. Na, \u00e9s azt felt\u00e9telezt\u00e9k, hogy ezt a klasztert CDN-k\u00e9nt kell haszn\u00e1lni. Teh\u00e1t adnak egy klasztert, adnak oda egy felhaszn\u00e1l\u00f3t, te pedig bem\u00e9sz a saj\u00e1t namespace-edbe \u00e9s telep\u00edted a frontendjeidet. <\/p>\n

<\/p>\n

Kor\u00e1bbi c\u00e9gem megpr\u00f3b\u00e1lt egy ilyen szolg\u00e1ltat\u00e1st eladni. K\u00e9rtek, hogy n\u00e9zzem meg, hogy megfelel\u0151-e a megold\u00e1s. <\/p>\n

<\/p>\n

Bementem a klaszterbe. Korl\u00e1tozott jogosults\u00e1gokat kaptam, korl\u00e1tozott namespace-t. Az emberek tudt\u00e1k, mi az a biztons\u00e1g. Olvast\u00e1k, mi az a Role-based access control (RBAC) a Kubernetesben \u2013 \u00e9s \u00fagy \u00e1ll\u00edtott\u00e1k be, hogy nem tudtam podokat ind\u00edtani deploymentek n\u00e9lk\u00fcl. Nem eml\u00e9kszem, mi volt a feladat, amit megpr\u00f3b\u00e1ltam megoldani, amikor podot akartam futtatni deployment n\u00e9lk\u00fcl, de nagyon szerettem volna egyszer\u0171en csak egy podot ind\u00edtani. Gondoltam, megn\u00e9zem, milyen jogaim vannak a klaszterben, mit tehetek \u00e9s mit nem, \u00e9s azt\u00e1n elmondom, mi van rosszul be\u00e1ll\u00edtva az RBAC-ban. <\/p>\n

<\/p>\n

\u00dagy alakult, hogy k\u00e9t percen bel\u00fcl admin jogosults\u00e1got kaptam a klaszterhez, belen\u00e9ztem az \u00f6sszes szomsz\u00e9dos namespace-be, \u00e9s l\u00e1ttam, hogy ott a c\u00e9gek m\u00e1r fut\u00f3 production frontendjei, akik m\u00e1r megv\u00e1s\u00e1rolt\u00e1k a szolg\u00e1ltat\u00e1st \u00e9s telep\u00edtettek. Alig tudtam meg\u00e1llni, hogy ne ker\u00fcljek valakinek a frontend oldal\u00e1ra \u00e9s ne helyezzek el valami tr\u00e1g\u00e1r sz\u00f3t a f\u0151oldalon. <\/p>\n

<\/p>\n

P\u00e9ld\u00e1kon kereszt\u00fcl meg fogom mutatni, hogyan csin\u00e1ltam, \u00e9s hogyan kellene v\u00e9dekezni ellene. <\/p>\n

<\/p>\n

De szeretek bemutatkozni. A nevem Pavel Selivanov. A Southbridge c\u00e9g \u00e9p\u00edt\u00e9sze vagyok. \u00c9rtek a Kuberneteshez, a DevOpshoz \u00e9s egy\u00e9b divatos dolgokhoz. A Southbridge m\u00e9rn\u00f6keivel mindezt megval\u00f3s\u00edtjuk, \u00e9n pedig tan\u00e1csot adok. <\/p>\n

<\/p>\n

F\u0151 tev\u00e9kenys\u00e9g\u00fcnk mellett nemr\u00e9g ind\u00edtottunk egy projektet, amit Slurmoknak h\u00edvunk. Az a c\u00e9lunk, hogy a Kubernetes kezel\u00e9si k\u00e9pess\u00e9geinket egy kicsit a k\u00f6zn\u00e9p el\u00e9 t\u00e1rjuk, \u00e9s m\u00e1s embereket is megtan\u00edtsunk dolgozni a K8s-sel. <\/p>\n

<\/p>\n

A mai besz\u00e9dem t\u00e9m\u00e1ja egy\u00e9rtelm\u0171 \u2013 a Kubernetes klaszter biztons\u00e1ga. De azonnal szeretn\u00e9m hangs\u00falyozni, hogy ez egy nagyon nagy t\u00e9ma \u2014 \u00e9s ez\u00e9rt r\u00f6gt\u00f6n szeretn\u00e9m tiszt\u00e1zni, hogy mir\u0151l biztosan nem fogok besz\u00e9lni. Nem fogok elavult kifejez\u00e9sekr\u0151l besz\u00e9lni, amik m\u00e1r sz\u00e1zszor elhangzottak az interneten. Mindenf\u00e9le RBAC \u00e9s tan\u00fas\u00edtv\u00e1nyok. <\/p>\n

<\/p>\n

Arr\u00f3l fogok besz\u00e9lni, ami engem \u00e9s koll\u00e9g\u00e1imat foglalkoztat a Kubernetes klaszter biztons\u00e1g\u00e1val kapcsolatban. Ezeket a probl\u00e9m\u00e1kat l\u00e1tjuk a Kubernetes klasztereket ny\u00fajt\u00f3 szolg\u00e1ltat\u00f3kn\u00e1l \u00e9s a hozz\u00e1nk \u00e9rkez\u0151 \u00fcgyfelekn\u00e9l is. S\u0151t, m\u00e9g az olyan \u00fcgyfelekn\u00e9l is, akik m\u00e1s tan\u00e1csad\u00f3 adminisztr\u00e1tori c\u00e9gekt\u0151l \u00e9rkeznek hozz\u00e1nk. Teh\u00e1t a trag\u00e9dia m\u00e9rt\u00e9ke igaz\u00e1b\u00f3l nagyon nagy. <\/p>\n

<\/p>\n

Csak h\u00e1rom pont, amir\u0151l ma besz\u00e9lni fogok: <\/p>\n

<\/p>\n

    \n
  1. Felhaszn\u00e1l\u00f3i jogosults\u00e1gok vs pod jogosults\u00e1gok. A felhaszn\u00e1l\u00f3i jogosults\u00e1gok \u00e9s a pod jogosults\u00e1gok nem ugyanazok. <\/li>\n
  2. Inform\u00e1ci\u00f3gy\u0171jt\u00e9s a klaszterr\u0151l. Megmutatom, hogy a klaszterb\u0151l minden inform\u00e1ci\u00f3t \u00f6ssze lehet gy\u0171jteni, an\u00e9lk\u00fcl, hogy k\u00fcl\u00f6nleges jogosults\u00e1gokkal rendelkezn\u00e9nk. <\/li>\n
  3. DoS-t\u00e1mad\u00e1s a klaszterre. Ha nem tudjuk \u00f6sszegy\u0171jteni az inform\u00e1ci\u00f3t, akkor is k\u00e9pesek vagyunk a klasztert le\u00e1ll\u00edtani. Besz\u00e9lni fogok a klaszter vez\u00e9rl\u0151elemeit \u00e9rint\u0151 DoS-t\u00e1mad\u00e1sokr\u00f3l. <\/li>\n<\/ol>\n

    <\/p>\n

    Egy m\u00e1sik \u00e1ltal\u00e1nos dolog, amir\u0151l eml\u00edt\u00e9st teszek \u2014 amin mindezt teszteltem, amin biztosan elmondhatom, hogy m\u0171k\u00f6dik.<\/p>\n

    <\/p>\n

    Alapul vessz\u00fck a Kubernetes klaszter telep\u00edt\u00e9s\u00e9t Kubespray seg\u00edts\u00e9g\u00e9vel. Ha valaki nem tudn\u00e1, ez gyakorlatilag egy szerepk\u00e9szlet az Ansible-hoz. Az alkalmaz\u00e1s sor\u00e1n folyamatosan haszn\u00e1ljuk. El\u0151ny\u00f6s abban, hogy b\u00e1rhova telep\u00edthet\u0151 \u2014 ak\u00e1r fizikai g\u00e9pekre, ak\u00e1r felh\u0151be. Egy telep\u00edt\u00e9si m\u00f3d alapvet\u0151en mindenhez alkalmas. <\/p>\n

    <\/p>\n

    Ebben a klaszterben nekem Kubernetes v1.14.5 lesz. Az eg\u00e9sz Kubernetes klaszter, amelyet megvizsg\u00e1lunk, n\u00e9vkiterjeszt\u00e9sekre van felosztva, mindegyik n\u00e9vkiterjeszt\u00e9s egy k\u00fcl\u00f6n csapathoz tartozik, \u00e9s a csapat tagjainak hozz\u00e1f\u00e9r\u00e9s\u00fck van mindegyik n\u00e9vkiterjeszt\u00e9shez. A k\u00fcl\u00f6nb\u00f6z\u0151 n\u00e9vkiterjeszt\u00e9sekhez nem tudnak eljutni, csak a saj\u00e1tjukhoz. De van egy adminisztrat\u00edv fi\u00f3k, amelynek joga van az eg\u00e9sz klaszterre. <\/p>\n

    <\/p>\n

    \"A<\/p>\n

    <\/p>\n

    Meg\u00edg\u00e9rtem, hogy els\u0151k\u00e9nt az adminisztr\u00e1tori jogok megszerz\u00e9se lesz a klaszterhez. Sz\u00fcks\u00e9g\u00fcnk van egy k\u00fcl\u00f6nlegesen elk\u00e9sz\u00edtett podra, amely meg fogja t\u00f6rni a Kubernetes klasztert. Minden, amit tenn\u00fcnk kell, az az, hogy alkalmazzuk a Kubernetes klaszterre. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Ez a pod egy a Kubernetes klaszter egyik mester\u00e9re fog \u00e9rkezni. A klaszter pedig \u00f6r\u00f6mmel visszak\u00fcldi nek\u00fcnk a admin.conf nev\u0171 f\u00e1jlt. A Kubernetes f\u0151 f\u00e1jlj\u00e1ban t\u00e1rolva vannak az \u00f6sszes adminisztr\u00e1tori tan\u00fas\u00edtv\u00e1ny, \u00e9s a klaszter API-ja is be van \u00e1ll\u00edtva. \u00cdgy egyszer\u0171en lehet adminisztr\u00e1tori hozz\u00e1f\u00e9r\u00e9st szerezni, gondolom, a Kubernetes klaszterek 98%-\u00e1hoz. <\/p>\n
    <\/p>\n
    Ism\u00e9tlem, ezt a podot egy fejleszt\u0151 k\u00e9sz\u00edtette az \u00d6n klaszter\u00e9ben, aki hozz\u00e1f\u00e9r\u00e9ssel rendelkezik saj\u00e1t aj\u00e1nl\u00e1sainak telep\u00edt\u00e9s\u00e9re egy kis n\u00e9vkiterjeszt\u00e9sen bel\u00fcl, mindez RBAC al\u00e1 van zs\u00fafolva. Nem voltak jogai. De ennek ellen\u00e9re a tan\u00fas\u00edtv\u00e1ny visszaker\u00fclt. <\/p>\n
    <\/p>\n
    Most pedig a speci\u00e1lisan elk\u00e9sz\u00edtett podr\u00f3l. Ind\u00edtsuk el b\u00e1rmilyen k\u00e9pen. P\u00e9ld\u00e1ul vegy\u00fck a debian:jessie-t. <\/p>\n
    <\/p>\n
    Van nek\u00fcnk egy ilyen dolog: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    Mi az a toler\u00e1ci\u00f3? A Kubernetes klaszterekben a mesterek \u00e1ltal\u00e1ban olyan dologgal vannak megjel\u00f6lve, amit taintnek neveznek (ez angolul \"fert\u0151z\u00e9s\"). A \"fert\u0151z\u00e9s\" l\u00e9nyege, hogy a mester csom\u00f3pontokra nem lehet podokat hozz\u00e1rendelni. De senki sem akad\u00e1lyozza meg, hogy b\u00e1rmely podban jelezz\u00fck, hogy toler\u00e1lja a \"fert\u0151z\u00e9st\". A Toleration szakasz \u00e9ppen azt mondja, hogy ha valamilyen csom\u00f3ponton NoSchedule van be\u00e1ll\u00edtva, akkor a podunk toler\u00e1ns a ilyen fert\u0151z\u00e9sre \u2013 \u00e9s semmi probl\u00e9ma. <\/p>\n
    <\/p>\n
    Ezenk\u00edv\u00fcl azt mondjuk, hogy podunk nemcsak toler\u00e1ns, hanem kifejezetten mesterre is akar ker\u00fclni. Mivel a mesterekn\u00e9l tal\u00e1lhat\u00f3 a leg\u00ednycsikland\u00f3bb, amire sz\u00fcks\u00e9g\u00fcnk van \u2013 minden tan\u00fas\u00edtv\u00e1ny. Ez\u00e9rt nodeSelector-t mondunk \u2013 \u00e9s van egy szabv\u00e1nyos c\u00edmke a mestereken, amely lehet\u0151v\u00e9 teszi, hogy a klaszter \u00f6sszes csom\u00f3pontj\u00e1b\u00f3l pontosan azokat v\u00e1lasszuk, amelyek mesterek. <\/p>\n
    <\/p>\n
    \u00cdgy ezekkel a k\u00e9t szekci\u00f3val a pod biztosan eljuthat a mesterhez. \u00c9s engedni fogj\u00e1k ott lakni. <\/p>\n
    <\/p>\n
    De csak annyira, hogy a mesterhez eljussunk, nem el\u00e9g. Ez nem fog semmit adni. Ez\u00e9rt a k\u00f6vetkez\u0151 k\u00e9t dolog van:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Megmondjuk, hogy a pod, amelyet ind\u00edtunk, a kernel n\u00e9vt\u00e9rben, a h\u00e1l\u00f3zati n\u00e9vt\u00e9rben \u00e9s a PID n\u00e9vt\u00e9rben fog \u00e9lni. Miut\u00e1n a pod elindul a masteren, l\u00e1thatja ennek a node-nak az \u00f6sszes val\u00f3s, \u00e9l\u0151 interf\u00e9sz\u00e9t, figyelheti az \u00f6sszes forgalmat \u00e9s l\u00e1thatja az \u00f6sszes folyamat PID-j\u00e9t.<\/p>\n
    <\/p>\n
    A k\u00f6vetkez\u0151 l\u00e9p\u00e9s a kisebbik. Vegye az etcd-t, \u00e9s olvassa el, amit szeretne. <\/p>\n
    <\/p>\n
    A leg\u00e9rdekesebb \u2014 ez a Kubernetes k\u00e9pess\u00e9ge, amely alap\u00e9rtelmez\u00e9s szerint ott van. <\/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
    A l\u00e9nyege az, hogy a podban, amelyet ind\u00edtunk, m\u00e9g a clusterhez val\u00f3 jogok n\u00e9lk\u00fcl is megmondhatjuk, hogy egy hostPath t\u00edpus\u00fa volume-ot szeretn\u00e9nk l\u00e9trehozni. Ez azt jelenti, hogy a hoston tal\u00e1lhat\u00f3 utat, amelyen elindulunk \u2014 \u00e9s ezt volume-k\u00e9nt vessz\u00fck. Ezt k\u00f6vet\u0151en nevezz\u00fck el name: host-nak. Az \u00f6sszes hostPath-ot bel\u00fcl a podba szerelj\u00fck. Ebben a p\u00e9ld\u00e1ban a \/host mapp\u00e1ba. <\/p>\n
    <\/p>\n
    M\u00e9g egyszer hangs\u00falyozom. Megmondtuk a podnak, hogy j\u00f6jj\u00f6n a masterre, kapja meg a hostNetwork \u00e9s hostPID-t \u2014 \u00e9s az eg\u00e9sz master rootj\u00e1t szerelje be ebbe a podba. <\/p>\n
    <\/p>\n
    \u00c9rted, hogy a debianon elind\u00edtottuk a bash-t, \u00e9s ez a bash rootk\u00e9nt fut. Teh\u00e1t \u00e9ppen megszerezt\u00fck a root jogokat a masterre, mik\u00f6zben nem rendelkez\u00fcnk jogokkal a Kubernetes klaszterben.<\/p>\n
    <\/p>\n
    A k\u00f6vetkez\u0151 feladat az, hogy bel\u00e9pj\u00fcnk a podba a \/host \/etc\/kubernetes\/pki mapp\u00e1ba, ha nem t\u00e9vedek, ott elhozzuk az \u00f6sszes master tan\u00fas\u00edtv\u00e1nyt a klaszterhez, \u00e9s \u00edgy adminisztr\u00e1torokk\u00e1 v\u00e1lunk a klaszterben. <\/p>\n
    <\/p>\n
    Ha \u00fagy n\u00e9zz\u00fck, ezek az egyik legvesz\u00e9lyesebb jogok a podokban \u2014 f\u00fcggetlen\u00fcl att\u00f3l, hogy milyen jogai vannak a felhaszn\u00e1l\u00f3nak:
    \n\"A<\/p>\n
    <\/p>\n
    Ha jogom van elind\u00edtani egy podot a klaszter valamilyen n\u00e9vt\u00e9rben, akkor annak a podnak ezek a jogai alap\u00e9rtelmez\u00e9s szerint megvannak. Lehet, hogy privileg\u00e1lt podokat ind\u00edthatok, \u00e9s ez gyakorlatilag az \u00f6sszes jog, szinte root a node-on. <\/p>\n
    <\/p>\n
    A kedvencem \u2014 Root user. A Kubernetes-nek van egy ilyen opci\u00f3ja: Run As Non-Root. Ez egyfajta v\u00e9delem a hackerek ellen. Tudja, mi az a 'mald\u00e1v v\u00edrus'? Ha hacker vagy, \u00e9s bel\u00e9pt\u00e9l a Kubernetes klaszterembe, akkor mi, szeg\u00e9ny adminisztr\u00e1torok, k\u00e9rj\u00fck: 'K\u00e9rj\u00fck, jelezd a podjaidban, amelyeket haszn\u00e1lsz, hogy run as non-root. Mert k\u00fcl\u00f6nben \u00fagy fogsz elind\u00edtani egy folyamatot a pododban rootk\u00e9nt, hogy nagyon k\u00f6nnyen felt\u00f6rheted a rendszert. K\u00e9rj\u00fck, v\u00e9dd meg magad!'. <\/p>\n
    <\/p>\n
    A host path volume \u2014 v\u00e9lem\u00e9nyem szerint a leggyorsabb m\u00f3dja a k\u00edv\u00e1nt eredm\u00e9ny el\u00e9r\u00e9s\u00e9nek a Kubernetes klaszterb\u0151l. <\/p>\n
    <\/p>\n
    De mit kezdj\u00fcnk mindezzel? <\/p>\n
    <\/p>\n
    Gondolatok, amelyek b\u00e1rmely norm\u00e1lis adminisztr\u00e1tor fej\u00e9ben meg kell, hogy forduljanak, aki tal\u00e1lkozik a Kubernetes-szel: \u201eAha, mondtam, hogy a Kubernetes nem m\u0171k\u00f6dik. Tele van hib\u00e1kkal. Az eg\u00e9sz Kubernetes egy rak\u00e1s h\u00fclyes\u00e9g.\u201d Val\u00f3j\u00e1ban l\u00e9tezik egy dolog, a dokument\u00e1ci\u00f3, \u00e9s ha abba belen\u00e9z\u00fcnk, tal\u00e1lunk egy szakaszt. Pod Biztons\u00e1gi Politika<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Ez egy yaml-objektum \u2014 ezt l\u00e9trehozhatjuk a Kubernetes klaszterben \u2014 amely a podok biztons\u00e1gi aspektusait szab\u00e1lyozza. Vagyis l\u00e9nyeg\u00e9ben ellen\u0151rzi azokat a jogokat, amelyek k\u00fcl\u00f6nb\u00f6z\u0151 hostNetwork, hostPID, bizonyos t\u00edpus\u00fa volume-k haszn\u00e1lat\u00e1ra vonatkoznak, ami a podok ind\u00edt\u00e1sakor van. A Pod Biztons\u00e1gi Politika seg\u00edts\u00e9g\u00e9vel mindez le\u00edrhat\u00f3. <\/p>\n
    <\/p>\n
    A Pod Biztons\u00e1gi Politik\u00e1ban a leg\u00e9rdekesebb az, hogy a Kubernetes klaszterben az \u00f6sszes telep\u00edt\u0151 PSP nincs egyszer\u0171en defini\u00e1lva, alap\u00e9rtelmezetten ki van kapcsolva. A Pod Biztons\u00e1gi Politika aktiv\u00e1l\u00e1sa egy admission plugin seg\u00edts\u00e9g\u00e9vel t\u00f6rt\u00e9nik.<\/p>\n
    <\/p>\n
    Rendben, telep\u00edts\u00fck a Pod Biztons\u00e1gi Politika-t a klaszterbe, mondjuk, hogy van p\u00e1r szolg\u00e1ltat\u00e1si podunk abban a n\u00e9vt\u00e9rben, amelyhez csak az adminisztr\u00e1torok f\u00e9rhetnek hozz\u00e1. Mondjuk, hogy minden m\u00e1s podnak korl\u00e1tozott jogai vannak. Mert val\u00f3sz\u00edn\u0171leg a fejleszt\u0151knek nincsen sz\u00fcks\u00e9g\u00fck arra, hogy privilegiz\u00e1lt pod-okat ind\u00edtsanak a klaszter\u00e9ben. <\/p>\n
    <\/p>\n
    \u00c9s \u00fagy t\u0171nik, hogy minden rendben van. A Kubernetes klaszter\u00fcnket nem lehet k\u00e9t perc alatt felt\u00f6rni. <\/p>\n
    <\/p>\n
    Van egy probl\u00e9ma. Val\u00f3sz\u00edn\u0171leg, ha van Kubernetes klasztered, akkor abban be van \u00e1ll\u00edtva monitoroz\u00e1s. Merem \u00e1ll\u00edtani, hogy ha a klaszteredben van monitoroz\u00e1s, az a neve Prometheus. <\/p>\n
    <\/p>\n
    Amit most fogok mondani, \u00e9rv\u00e9nyes lesz a Prometheus-operatorra \u00e9s a tiszta form\u00e1ban telep\u00edtett Prometheus-ra is. A k\u00e9rd\u00e9s az, hogy ha a klaszterhez nem tudok \u00edgy gyorsan adminisztr\u00e1tort kapni, akkor t\u00f6bbet kell keresnem. A keres\u00e9st a monitoroz\u00e1sod seg\u00edts\u00e9g\u00e9vel v\u00e9gezhetem el.<\/p>\n
    <\/p>\n
    Val\u00f3sz\u00edn\u0171leg mindenki ugyanazokat a cikkeket olvasta a Habr-n, \u00e9s a monitoroz\u00e1s a monitoring n\u00e9vt\u00e9rben tal\u00e1lhat\u00f3. A Helm chartok mind hasonl\u00f3an nevezik el ezeket. Felt\u00e9telezem, hogy ha v\u00e9grehajtod a helm install stable\/prometheus parancsot, akkor k\u00f6r\u00fclbel\u00fcl azonos neveket kapsz. \u00c9s val\u00f3sz\u00edn\u0171leg a DNS-nevet a klaszteredben nem kell kital\u00e1lnom. Mert az alap\u00e9rtelmezett. <\/p>\n
    <\/p>\n
    \"A<\/p>\n
    <\/p>\n
    Ezut\u00e1n van egy dev ns, amelyben elind\u00edthat\u00f3 egy pod. Ebb\u0151l a podb\u00f3l nagyon k\u00f6nnyen \u00edgy lehet tov\u00e1bbmenn\u00fcnk: <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    A prometheus-kube-state-metrics az egyik prom\u00e9theusz-export\u00e1l\u00f3, amely a Kubernetes API-j\u00e1b\u00f3l gy\u0171jti a metrik\u00e1kat. Nagyon sok adat van arr\u00f3l, mi fut a klaszteredben, milyen t\u00edpus\u00fa, \u00e9s milyen probl\u00e9m\u00e1id vannak vele. <\/p>\n
    <\/p>\n
    P\u00e9ld\u00e1nak egyszer\u0171en: <\/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:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a9638ee634989″,container_id=»docker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2853397d7daf08e72c22d3cf8b»} 1 <\/p>\n
    <\/p>\n
    Ha egyszer\u0171 curl k\u00e9r\u00e9st ind\u00edtasz egy nem privilegiz\u00e1lt podb\u00f3l, akkor ilyen inform\u00e1ci\u00f3kat kaphatsz. Ha nem tudod, melyik Kubernetes verzi\u00f3ban futsz, akkor az k\u00f6nnyen elmes\u00e9li neked. <\/p>\n
    <\/p>\n
    A leg\u00e9rdekesebb az, hogy a kube-state-metrics lek\u00e9rdez\u00e9se mellett ugyanazzal a sikerrel k\u00f6zvetlen\u00fcl a Prometheushoz is fordulhatsz. Onnan is gy\u0171jthetsz metrik\u00e1kat. S\u0151t, elm\u00e9letileg olyan lek\u00e9rdez\u00e9st is l\u00e9trehozhatsz a klaszterb\u0151l a Prometheusban, amely egyszer\u0171en le\u00e1ll\u00edtja azt. \u00c9s akkor a monitoring teljesen le\u00e1ll a klaszterr\u0151l. <\/p>\n
    <\/p>\n
    Itt m\u00e1r felmer\u00fcl a k\u00e9rd\u00e9s, hogy valamilyen k\u00fcls\u0151 monitoring figyeli-e a monitoringodat. \u00c9pp most szereztem lehet\u0151s\u00e9get arra, hogy a Kubernetes klaszteren bel\u00fcl k\u00f6vetkezm\u00e9nyek n\u00e9lk\u00fcl tev\u00e9kenykedjek. Te m\u00e9g csak nem is fogod tudni, hogy \u00e9n ott tev\u00e9kenykedem, mivel m\u00e1r nincs monitoring. <\/p>\n
    <\/p>\n
    Pontosan \u00fagy, ahogy a PSP-n\u00e9l, az az \u00e9rz\u00e9sem, hogy minden ilyen men\u0151 technol\u00f3gia \u2014 Kubernetes, Prometheus \u2014 egyszer\u0171en nem m\u0171k\u00f6dik, \u00e9s tele van lyukakkal. Val\u00f3j\u00e1ban nem \u00edgy van. <\/p>\n
    <\/p>\n
    Van egy dolog \u2014 H\u00e1l\u00f3zati Szab\u00e1lyzat<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Ha norm\u00e1lis adminisztr\u00e1tor vagy, val\u00f3sz\u00edn\u0171leg tudod, hogy a H\u00e1l\u00f3zati Szab\u00e1lyzat egy \u00fajabb yaml, ami a klaszterben am\u00fagy is b\u0151ven van. A H\u00e1l\u00f3zati Szab\u00e1lyzatok pedig bizonyos nem sz\u00fcks\u00e9gesek. \u00c9s ha m\u00e9g olvastad is, hogy mi az a H\u00e1l\u00f3zati Szab\u00e1lyzat, hogy ez a Kubernetes yaml t\u0171zfala, amely korl\u00e1tozza a hozz\u00e1f\u00e9r\u00e9si jogokat a n\u00e9vt\u00e9r k\u00f6z\u00f6tt, podok k\u00f6z\u00f6tt, akkor biztosan \u00fagy gondoltad, hogy egy yaml form\u00e1tum\u00fa t\u0171zfal a Kubernetesben egy \u00fajabb absztrakci\u00f3\u2026 Nem, ez t\u00e9nyleg nem sz\u00fcks\u00e9ges. <\/p>\n
    <\/p>\n
    M\u00e9g ha a biztons\u00e1gi szakembereiteknek nem is mondt\u00e1k el, hogy a Kubernetes seg\u00edts\u00e9g\u00e9vel nagyon k\u00f6nnyen \u00e9s egyszer\u0171en lehet t\u0171zfalat \u00e9p\u00edteni, r\u00e1ad\u00e1sul nagyon granularisan, ha m\u00e9g nem tudj\u00e1k, \u00e9s nem kicsiny\u00edtik le a dolgot: \u201eNa, adjatok, adjatok\u2026\u201d, akkor is sz\u00fcks\u00e9getek van a Network Policy-ra az olyan szolg\u00e1ltat\u00e1si helyek hozz\u00e1f\u00e9r\u00e9s\u00e9nek lez\u00e1r\u00e1s\u00e1hoz, amelyeket a klasztereteken kereszt\u00fcl meg lehet \u00e9rinteni, an\u00e9lk\u00fcl hogy b\u00e1rmilyen hiteles\u00edt\u00e9setek lenne. <\/p>\n
    <\/p>\n
    Ahogy az el\u0151z\u0151 p\u00e9ld\u00e1ban is eml\u00edtettem, a kube state metrics-et b\u00e1rmelyik n\u00e9vt\u00e9rb\u0151l el\u00e9rhetj\u00fck a Kubernetes klaszterben, an\u00e9lk\u00fcl hogy b\u00e1rmilyen jogunk lenne r\u00e1. A network policy-k lez\u00e1rt\u00e1k a hozz\u00e1f\u00e9r\u00e9st az \u00f6sszes t\u00f6bbi n\u00e9vt\u00e9rb\u0151l a monitoroz\u00e1si n\u00e9vt\u00e9rhez, \u00e9s ennyi: ha nincs hozz\u00e1f\u00e9r\u00e9s, nincsenek probl\u00e9m\u00e1k. Az \u00f6sszes chartban, ami el\u00e9rhet\u0151, legyen sz\u00f3 a standard Prometheusr\u00f3l vagy arr\u00f3l, ami az operatorban tal\u00e1lhat\u00f3, egyszer\u0171en van lehet\u0151s\u00e9g a values f\u00e1jlban a network policy-k enged\u00e9lyez\u00e9s\u00e9re. Csak be kell kapcsolni, \u00e9s m\u0171k\u00f6dni fognak. <\/p>\n
    <\/p>\n
    Itt van egy probl\u00e9ma. Norm\u00e1l adminisztr\u00e1tork\u00e9nt val\u00f3sz\u00edn\u0171leg \u00fagy d\u00f6nt\u00f6ttetek, hogy a network policy-k nem sz\u00fcks\u00e9gesek. \u00c9s miut\u00e1n olvastatok k\u00fcl\u00f6nf\u00e9le cikkeket olyan forr\u00e1sokon, mint a Habr, \u00fagy gondolt\u00e1tok, hogy a flannel, k\u00fcl\u00f6n\u00f6sen a host-gateway m\u00f3dban, a legjobb v\u00e1laszt\u00e1s, amit megtehettek. <\/p>\n
    <\/p>\n
    Mit tegy\u00fcnk? <\/p>\n
    <\/p>\n
    Megpr\u00f3b\u00e1lhatj\u00e1tok \u00fajra telep\u00edteni a h\u00e1l\u00f3zati megold\u00e1st, ami a Kubernetes klaszteretekben van, \u00e9s kicser\u00e9lni valami funkcion\u00e1lisabbra. P\u00e9ld\u00e1ul a Calico-ra. De azonnal felh\u00edvom a figyelmeteket arra, hogy a h\u00e1l\u00f3zati megold\u00e1s megv\u00e1ltoztat\u00e1s\u00e1nak feladata egy m\u0171k\u00f6d\u0151 Kubernetes klaszterben meglehet\u0151sen nem trivialis. K\u00e9tszer is megpr\u00f3b\u00e1ltam ezt (mindk\u00e9t alkalommal elm\u00e9letben), de m\u00e9g a Slurmokon is bemutattuk, hogyan kell ezt csin\u00e1lni. Az oktat\u00f3inknak megmutattuk, hogyan lehet megv\u00e1ltoztatni a h\u00e1l\u00f3zati megold\u00e1st egy Kubernetes klaszterben. Elvileg megpr\u00f3b\u00e1lhatj\u00e1tok \u00fagy csin\u00e1lni, hogy a termel\u00e9si klaszterben ne legyen le\u00e1ll\u00e1s. De val\u00f3sz\u00edn\u0171leg nem fog siker\u00fclni. <\/p>\n
    <\/p>\n
    A probl\u00e9ma val\u00f3j\u00e1ban nagyon egyszer\u0171en megoldhat\u00f3. A klaszterben vannak tan\u00fas\u00edtv\u00e1nyok, \u00e9s tudj\u00e1tok, hogy a tan\u00fas\u00edtv\u00e1nyok egy \u00e9v m\u00falva lej\u00e1rnak. Nos, a norm\u00e1lis megold\u00e1s a klaszterben a tan\u00fas\u00edtv\u00e1nyokkal az, hogy mi\u00e9rt is agg\u00f3dn\u00e1nk, emel\u00fcnk egy \u00faj klasztert, a r\u00e9git hagyjuk lej\u00e1rni, \u00e9s minden visszat\u00f6ltj\u00fck. Igaz, amikor lej\u00e1r, egy napig le\u00e1ll, de legal\u00e1bb van egy \u00faj klaszter. <\/p>\n
    <\/p>\n
    Amikor \u00faj klasztert emeltek, egy\u00fattal a Calicot is tegy\u00e9tek a flannel hely\u00e9re. <\/p>\n
    <\/p>\n
    Mi a teend\u0151, ha a tan\u00fas\u00edtv\u00e1nyok sz\u00e1z \u00e9vre sz\u00f3lnak, \u00e9s nem tervezi a klaszter \u00e1tdeploy\u00e1l\u00e1s\u00e1t? L\u00e9tezik egy Kube-RBAC-Proxy nev\u0171 dolog. Ez egy nagyon klassz fejleszt\u00e9s, amely lehet\u0151v\u00e9 teszi, hogy sidecar kont\u00e9nerr\u00e9 \u00e9p\u00fclj\u00f6n be b\u00e1rmely podba a Kubernetes klaszterben. Val\u00f3j\u00e1ban hozz\u00e1adja a Kubernetes RBAC-j\u00e1n kereszt\u00fcli hiteles\u00edt\u00e9st ehhez a podhoz. <\/p>\n
    <\/p>\n
    Van egy probl\u00e9ma. Kor\u00e1bban a Prometheus oper\u00e1torban ez a Kube-RBAC-Proxy megold\u00e1s be volt \u00e9p\u00edtve. De azt\u00e1n elt\u0171nt. Jelenleg a modern verzi\u00f3k arra t\u00e1maszkodnak, hogy van network policy, \u00e9s ezzel z\u00e1rj\u00e1k le a dolgokat. Ez\u00e9rt kicsit \u00e1t kell \u00edrni a chartokat. Val\u00f3j\u00e1ban, ha bel\u00e9p a ez a repozit\u00f3rium<\/a><\/noindex>, ott tal\u00e1l p\u00e9ld\u00e1kat arra, hogyan lehet ezt sidecar-k\u00e9nt haszn\u00e1lni, \u00e9s a chartokat minim\u00e1lisan kell \u00e1t\u00edrni. <\/p>\n
    <\/p>\n
    Van m\u00e9g egy kisebb probl\u00e9ma. Nem csak a Prometheus adja ki a metrik\u00e1it b\u00e1rkinek. Az \u00f6sszes klaszter komponens, a Kubernetes klaszter is k\u00e9pes kiadni a saj\u00e1t metrik\u00e1it. <\/p>\n
    <\/p>\n
    De ahogy m\u00e1r mondtam, ha nem tud hozz\u00e1f\u00e9rni a klaszterhez \u00e9s inform\u00e1ci\u00f3t gy\u0171jteni, akkor legal\u00e1bb k\u00e1rt tehet. <\/p>\n
    <\/p>\n
    Sz\u00f3val gyorsan bemutatok k\u00e9t m\u00f3dot, ahogyan a Kubernetes klaszter eg\u00e9szs\u00e9g\u00e9t t\u00f6nkre lehet tenni. <\/p>\n
    <\/p>\n
    Nevess majd, amikor ezt elmondom, ez k\u00e9t eset a val\u00f3s \u00e9letb\u0151l. <\/p>\n
    <\/p>\n
    Els\u0151 m\u00f3dszer. Az er\u0151forr\u00e1sok kimer\u00edt\u00e9se. <\/p>\n
    <\/p>\n
    Ind\u00edtunk egy \u00faj speci\u00e1lis podot. Ennek a k\u00f6vetkez\u0151 szekci\u00f3ja lesz. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Ahogy tudod, a requests az a CPU \u00e9s mem\u00f3ria mennyis\u00e9g, amely a hoszton rezerv\u00e1l\u00f3dik a konkr\u00e9t podok sz\u00e1m\u00e1ra, akik k\u00e9rik. Ha van egy n\u00e9gy magos hoszt a Kubernetes klaszterben, \u00e9s \u00e9rkezik egy pod, amely n\u00e9gy CPU-ra k\u00e9r, akkor t\u00e4hendab, hogy t\u00f6bb pod nem tud \u00e9rkezni, amelyiknek requests-a van e hosztra. <\/p>\n
    <\/p>\n
    Ha elind\u00edtok egy ilyen podot, majd kiadom a parancsot: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Akkor senki sem tud a Kubernetes klaszterbe deploy\u00e1lni. Mert az \u00f6sszes node-ban elfogynak a requests-ok. \u00cdgy meg tudom \u00e1ll\u00edtani az \u00d6n Kubernetes klaszter\u00e9t. Ha ezt este csin\u00e1lom, akkor a deployok el\u00e9g hossz\u00fa ideig \u00e1llni fognak. <\/p>\n
    <\/p>\n
    Ha ism\u00e9t megn\u00e9zz\u00fck a Kubernetes dokument\u00e1ci\u00f3j\u00e1t, akkor tal\u00e1lkozunk egy olyan dologgal, amit Limit Range-nek h\u00edvnak. Ez az er\u0151forr\u00e1sokat \u00e1ll\u00edtja be a klaszter objektumai sz\u00e1m\u00e1ra. \u00cdrhatsz egy Limit Range YAML objektumot, alkalmazhatod azt adott n\u00e9vterekre - \u00e9s ezut\u00e1n ebben a n\u00e9vt\u00e9rben megmondhatod, hogy neked van alap\u00e9rtelmezett, maxim\u00e1lis \u00e9s minim\u00e1lis er\u0151forr\u00e1sod a podok sz\u00e1m\u00e1ra.<\/p>\n
    <\/p>\n
    Ezzel a dologgal korl\u00e1tozhatjuk a felhaszn\u00e1l\u00f3kat a speci\u00e1lis term\u00e9kn\u00e9vt\u00e9rben a podjaikban b\u00e1rminem\u0171 felesleges er\u0151forr\u00e1sok megad\u00e1s\u00e1ban. De sajnos, m\u00e9g ha elmondod a felhaszn\u00e1l\u00f3nak, hogy nem ind\u00edthat podokat, amelyek k\u00e9rnek egy CPU-n\u00e1l t\u00f6bbet, van egy nagyszer\u0171 parancs a sk\u00e1l\u00e1z\u00e1sra, vagy a dashboardon kereszt\u00fcl is v\u00e9grehajthatj\u00e1k a sk\u00e1l\u00e1z\u00e1st.<\/p>\n
    <\/p>\n
    Innen ered a m\u00e1sodik lehet\u0151s\u00e9g. 11 111 111 111 111 pod ind\u00edt\u00e1sa. Ez tizenegy milli\u00e1rd. Nem az\u00e9rt mondom ezt a sz\u00e1mot, mert kital\u00e1ltam, hanem mert \u00e9n magam is l\u00e1ttam. <\/p>\n
    <\/p>\n
    Val\u00f3di t\u00f6rt\u00e9net. K\u00e9s\u0151 este, m\u00e1r k\u00e9sz\u00fcltem hazaindulni az irod\u00e1b\u00f3l. N\u00e9zem, hogy a sarokban \u00fccs\u00f6r\u00f6g egy csoport fejleszt\u0151, \u00e9s valamit l\u00e1zasan csin\u00e1lnak a laptopjaikkal. Odamegyek hozz\u00e1juk \u00e9s megk\u00e9rdezem: \u00abMi t\u00f6rt\u00e9nt veletek?\u00bb<\/p>\n
    <\/p>\n
    Kicsit kor\u00e1bban, este kilenc k\u00f6r\u00fcl az egyik fejleszt\u0151 haza akart menni. Azt mondta: \u00abMost sk\u00e1l\u00e1zom az alkalmaz\u00e1somat egyre\u00bb. Megnyomta az egyet, de az internet egy kicsit akadozott. M\u00e1sodszor is r\u00e1nyomott az egyre, nyomta az egyet, r\u00e1kattintott az Enterre. Nyomkodta mindent, amit tudott. Azt\u00e1n az internet \u00e9letre kelt - \u00e9s minden elkezdett sk\u00e1l\u00e1z\u00f3dni erre a sz\u00e1mra. <\/p>\n
    <\/p>\n
    Igaz, ez a t\u00f6rt\u00e9net nem Kubernetes-en zajlott, akkoriban Nomad volt. Az lett a v\u00e9ge, hogy egy \u00f3ra pr\u00f3b\u00e1lkoz\u00e1s ut\u00e1n a Nomad, hogy meg\u00e1ll\u00edtsuk a kitart\u00f3 sk\u00e1l\u00e1z\u00e1st, v\u00e1laszolt, hogy nem fog sk\u00e1l\u00e1zni \u00e9s semmi m\u00e1ssal nem fog foglalkozni. \u00abF\u00e1radt vagyok, most m\u00e1r megyek\u00bb. Azt\u00e1n le\u00e1llt. <\/p>\n
    <\/p>\n
    Term\u00e9szetesen megpr\u00f3b\u00e1ltam ugyanezt megtenni Kubernetes-en. Tizenegy milli\u00e1rd pod nem \u00f6rvendeztette meg a Kubernetes-t, azt mondta: \u00abNem tudom. Meghaladja a bels\u0151 korl\u00e1tokat\u00bb. De 1 000 000 000 podot siker\u00fclt elind\u00edtani. <\/p>\n
    <\/p>\n
    Az egyik milli\u00e1rd pod nem t\u0171nt el. Val\u00f3ban elkezdte sk\u00e1l\u00e1zni a dolgot. Ahogy a folyamat el\u0151rehaladt, egyre t\u00f6bb id\u0151 ment el az \u00faj podok l\u00e9trehoz\u00e1s\u00e1ra. De a folyamat tov\u00e1bbra is zajlott. Az egyetlen probl\u00e9ma az, hogy ha a saj\u00e1t n\u00e9vt\u00e9rben korl\u00e1tlanul ind\u00edthatok podokat, akkor ak\u00e1r k\u00e9r\u00e9s \u00e9s limit n\u00e9lk\u00fcl is olyan sok podot tudok l\u00e9trehozni bizonyos feladatokkal, hogy ezek a feladatok a csom\u00f3pontok mem\u00f3ri\u00e1j\u00e1t \u00e9s CPU-j\u00e1t kezdik el elfoglalni. Amikor ennyi podot ind\u00edtok, az inform\u00e1ci\u00f3nak be kell ker\u00fclnie a t\u00e1rol\u00f3ba, vagyis az etcd-be. Ha t\u00fal sok inform\u00e1ci\u00f3 \u00e9rkezik oda, a t\u00e1rol\u00f3 kezd t\u00fal lassan v\u00e1laszolni \u2014 \u00e9s a Kubernetes akadozni kezd. <\/p>\n
    <\/p>\n
    De van egy m\u00e1sik probl\u00e9ma... Ahogy tudj\u00e1tok, a Kubernetes vez\u00e9rl\u0151elemei nem egy k\u00f6zponti dolog, hanem t\u00f6bb komponens. Ott van p\u00e9ld\u00e1ul a controller manager, scheduler \u00e9s \u00edgy tov\u00e1bb. Ezek az elemek egyszerre kezdenek el felesleges haszontalan munk\u00e1t v\u00e9gezni, ami id\u0151vel egyre t\u00f6bb id\u0151t fog ig\u00e9nybe venni. A controller manager \u00faj podokat fog l\u00e9trehozni. A scheduler megpr\u00f3b\u00e1l \u00faj csom\u00f3pontot tal\u00e1lni sz\u00e1mukra. Az \u00faj csom\u00f3pontok val\u00f3sz\u00edn\u0171leg hamarosan elfogynak a klaszterben. A Kubernetes klaszter egyre lassabban fog m\u0171k\u00f6dni.<\/p>\n
    <\/p>\n
    De \u00fagy d\u00f6nt\u00f6ttem, hogy m\u00e9g tov\u00e1bb megyek. Ahogy tudj\u00e1tok, a Kubernetes-ben van egy dolog, amit szolg\u00e1ltat\u00e1snak h\u00edvnak. Nos, a legt\u00f6bb klaszterben val\u00f3sz\u00edn\u0171leg a szolg\u00e1ltat\u00e1s IP t\u00e1bl\u00e1zat (IP tables) seg\u00edts\u00e9g\u00e9vel m\u0171k\u00f6dik. <\/p>\n
    <\/p>\n
    Ha mondjuk elind\u00edtok egy milli\u00e1rd podot, majd egy kis szkript seg\u00edts\u00e9g\u00e9vel r\u00e1k\u00e9nyszer\u00edtem a Kubernetest, hogy \u00faj szolg\u00e1ltat\u00e1sokat hozzon l\u00e9tre: <\/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
    A klaszter \u00f6sszes csom\u00f3pontj\u00e1n k\u00f6r\u00fclbel\u00fcl egyszerre \u00fajabb \u00e9s \u00fajabb iptables szab\u00e1lyok fognak l\u00e9trej\u00f6nni. Minden szolg\u00e1ltat\u00e1sra k\u00f6r\u00fclbel\u00fcl egy milli\u00e1rd iptables szab\u00e1ly fog l\u00e9trej\u00f6nni. <\/p>\n
    <\/p>\n
    Ezt az eg\u00e9szet t\u00f6bb ezer, ak\u00e1r t\u00edzezer podn\u00e1l teszteltem. A probl\u00e9ma az, hogy m\u00e1r ezen a szinten az SSH kapcsolatot l\u00e9trehozni a csom\u00f3ponthoz meglehet\u0151sen neh\u00e9zz\u00e9 v\u00e1lik. Mert a csomagok, amikor ennyi l\u00e1ncon haladnak \u00e1t, nem \u00e9rzik j\u00f3l magukat. <\/p>\n
    <\/p>\n
    \u00c9s ez is megoldhat\u00f3 a Kubernetes seg\u00edts\u00e9g\u00e9vel. Van egy olyan objektum, mint a Resource quota. Ez meg\u00e1llap\u00edtja a rendelkez\u00e9sre \u00e1ll\u00f3 er\u0151forr\u00e1sok \u00e9s objektumok sz\u00e1m\u00e1t a n\u00e9vter\u00fcleten a klaszterben. K\u00e9sz\u00edthet\u00fcnk yaml objektumot a klaszter minden n\u00e9vt\u00e9rben. Ezzel az objektummal megmondhatjuk, hogy a n\u00e9vt\u00e9rhez meghat\u00e1rozott sz\u00e1m\u00fa k\u00e9r\u00e9s, limit van kijel\u00f6lve, \u00e9s tov\u00e1bb\u00e1 megmondhatjuk, hogy ebben a n\u00e9vt\u00e9rben lehet l\u00e9trehozni 10 szolg\u00e1ltat\u00e1st \u00e9s 10 podot. A fejleszt\u0151 m\u00e9g est\u00e9nk\u00e9nt is kedv\u00e9re dolgozhat. A Kubernetes azt mondja neki: \u201eNem lehet annyi podot sk\u00e1l\u00e1zni, mert t\u00fall\u00e9pi az er\u0151forr\u00e1s kv\u00f3t\u00e1t\u201d. Ennyi, a probl\u00e9ma megoldva. Itt tal\u00e1lhat\u00f3 a dokument\u00e1ci\u00f3<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Egy probl\u00e9m\u00e1s pont ezzel kapcsolatban mer\u00fcl fel. \u00c9rezni lehet, hogy mennyire neh\u00e9z lesz l\u00e9trehozni egy n\u00e9vteret a Kubernetesben. A l\u00e9trehoz\u00e1s\u00e1hoz sok mindent figyelembe kell venn\u00fcnk.<\/p>\n
    <\/p>\n
    Resource quota + Limit Range + RBAC
    \n\u2022 L\u00e9trehozzuk a nevezt\u00e9r\u00e9t
    \n\u2022 L\u00e9trehozzuk a limitrange-t bel\u00fcl
    \n\u2022 L\u00e9trehozzuk a resourcequota-t bel\u00fcl
    \n\u2022 L\u00e9trehozzuk a serviceaccount-ot a CI sz\u00e1m\u00e1ra
    \n\u2022 L\u00e9trehozzuk a rolebindingot a CI \u00e9s a felhaszn\u00e1l\u00f3k sz\u00e1m\u00e1ra
    \n\u2022 Opcion\u00e1lisan elind\u00edtjuk a sz\u00fcks\u00e9ges szolg\u00e1ltat\u00f3 podokat <\/p>\n
    <\/p>\n
    Ez\u00e9rt szeretn\u00e9m megragadni a lehet\u0151s\u00e9get, hogy megosszam a fejleszt\u00e9seimet. Van egy dolog, amit operator SDK-nak h\u00edvnak. Ez egy m\u00f3d arra, hogy oper\u00e1torokat \u00edrjunk a Kubernetes klaszterbe. Oper\u00e1torokat \u00edrhatunk Ansible seg\u00edts\u00e9g\u00e9vel.<\/p>\n
    <\/p>\n
    Eleinte Ansible-n \u00edrtuk, majd megn\u00e9ztem, hogy van operator SDK, \u00e9s \u00e1t\u00edrtam az Ansible szerepet oper\u00e1torra. Ez az oper\u00e1tor lehet\u0151v\u00e9 teszi, hogy l\u00e9trehozzunk egy objektumot a Kubernetes klaszterben, amelyet parancsnak h\u00edvnak. A parancs belsej\u00e9ben lehet\u0151s\u00e9g van a yaml k\u00f6rnyezet\u00e9nek le\u00edr\u00e1s\u00e1ra. A parancs k\u00f6rnyezet\u00e9ben pedig le\u00edrhatjuk, hogy mennyi er\u0151forr\u00e1st biztos\u00edtunk. <\/p>\n
    <\/p>\n
    Kicsi megk\u00f6nny\u00edt\u0151je ennek a bonyolult folyamatnak<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    \u00c9s v\u00e9g\u00fcl. Mit tegy\u00fcnk mindezzel?
    \nEls\u0151. A Pod Security Policy \u2013 ez j\u00f3. \u00c9s b\u00e1r a Kubernetes telep\u00edt\u0151k egyike sem haszn\u00e1lja \u0151ket a mai napig, a klasztereitekben m\u00e9gis haszn\u00e1lni kell \u0151ket. <\/p>\n
    <\/p>\n
    A Network Policy \u2013 nem egy \u00fajabb felesleges funkci\u00f3. Val\u00f3ban sz\u00fcks\u00e9ges a klaszterben. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota \u2013 ideje lenne haszn\u00e1lni. R\u00e9g\u00f3ta haszn\u00e1ljuk ezeket, \u00e9s sok\u00e1ig biztos voltam benne, hogy mindenki ezt alkalmazza. Kider\u00fclt, hogy ez ritkas\u00e1g. <\/p>\n
    <\/p>\n
    Ami eml\u00edtettem a prezent\u00e1ci\u00f3 sor\u00e1n, vannak nem dokument\u00e1lt funkci\u00f3k, amelyek lehet\u0151v\u00e9 teszik a klaszter t\u00e1mad\u00e1s\u00e1t. Nemr\u00e9giben megjelent nagy Kubernetesi sebezhet\u0151s\u00e9gi elemz\u00e9s<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    N\u00e9h\u00e1ny dolog annyira szomor\u00fa \u00e9s b\u00e1nt\u00f3. P\u00e9ld\u00e1ul bizonyos k\u00f6r\u00fclm\u00e9nyek k\u00f6z\u00f6tt a klaszterben l\u00e9v\u0151 kubeletek kiadhatj\u00e1k a warlocks k\u00f6nyvt\u00e1r tartalm\u00e1t, \u00e9s ezt nem hiteles\u00edtett felhaszn\u00e1l\u00f3knak is. <\/p>\n
    <\/p>\n
    Itt<\/a><\/noindex> tal\u00e1lhat\u00f3k az utas\u00edt\u00e1sok arr\u00f3l, hogyan lehet reproduk\u00e1lni mindazt, amit elmondtam. Ott vannak a f\u00e1jlok, amelyek a termel\u00e9si p\u00e9ld\u00e1kat tartalmazz\u00e1k, p\u00e9ld\u00e1ul, hogy hogyan n\u00e9z ki a ResourceQuota, Pod Security Policy. \u00c9s mindez k\u00e9zzelfoghat\u00f3. <\/p>\n
    <\/p>\n
    Mindenkinek k\u00f6sz\u00f6n\u00f6m.<\/p>\n
    Forr\u00e1s: 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\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\udd47A Kubernetes klaszter hi\u00e1nyoss\u00e1gainak bet\u00f6mk\u00f6d\u00e9se. El\u0151ad\u00e1s \u00e9s \u00e1t\u00edr\u00e1s a DevOpsConf | ProHoster rendezv\u00e9nyr\u0151l","description":"Pavel Selivanov, a Southbridge megold\u00e1sarchitekt\u00e1ja \u00e9s a Slurm oktat\u00f3ja, el\u0151ad\u00e1st tartott a DevOpsConf 2019-en.","canonical_url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hu_HU","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\/hu\/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\/hu\/wp-json\/wp\/v2\/posts\/39203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/comments?post=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}