{"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\/et\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"Kattime Kubernetes'i klastri auke. Ettekanne ja transkriptsioon DevOpsConf'ist","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, Southbridge lahenduste arhitekt ja Sl\u0451\u0440m'i \u00f5petaja, esines DevOpsConf 2019 konverentsil ettekandega. See ettekande on osa s\u00fcvitsi mineva kursuse teemadest Kubernetes'e kohta \"Sl\u0451\u0440m Mega\".<\/p>\n

<\/p>\n

Sl\u0451\u0440m Basic: sissejuhatus Kubernetes'sse<\/a><\/noindex> toimub Moskvas 18-20. novembril.
\nSl\u0451\u0440m Mega: piilume Kubernetes'e masinasse<\/a><\/noindex> \u2014 Moskvas, 22-24. novembril.
\nSl\u0451\u0440m Online: m\u00f5lemad kursused Kubernetes'e kohta<\/a><\/noindex> on alati saadaval.<\/p>\n

\n

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

Allpool \u2014 ettekande dekodeerimine.<\/p>\n

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

Tere p\u00e4evast, kolleegid ja nende toetajad. T\u00e4na r\u00e4\u00e4gin ma turvalisusest.<\/p>\n

<\/p>\n

Ma n\u00e4en, et saalis on t\u00e4na palju turbeeksperte. Vabandan ette, kui kasutan turvamaailmast termineid, mis ei pruugi teie jaoks harjumusp\u00e4raselt k\u00f5lada. <\/p>\n

<\/p>\n

Nii juhtus, et umbes pool aastat tagasi sattus mulle k\u00e4tte \u00fcks avalik Kubernetes'i klaster. Avalik \u2014 t\u00e4hendab, et seal on n-\u00f6 erinevad namespaces, kus on kasutajad, kes on isoleeritud oma namespaces. K\u00f5ik need kasutajad kuuluvad erinevatele ettev\u00f5tetele. Eeldati, et seda klastrit tuleb kasutada CDN-ina. See t\u00e4hendab, et teile antakse klaster, antakse sinna kasutaja, tulete oma namespace'i, ja panne oma esik\u00fcljed \u00fcles. <\/p>\n

<\/p>\n

Minu eelmisel ettev\u00f5ttel oli sama teenus m\u00fc\u00fcgis. Mind paluti katsetada klastrit, et n\u00e4ha, kas selline lahendus sobib v\u00f5i mitte. <\/p>\n

<\/p>\n

Sisenesin sellesse klastrisse. Mul anti piiratud \u00f5igused, piiratud namespace. Seal m\u00f5isteti, mis on turvalisus. Nad lugesid, mis on Kubernetes'e Role-based access control (RBAC) \u2014 ja seadistati nii, et ma ei saanud pod'e eraldi k\u00e4ivitada d\u00e9ployement'itest. Ei m\u00e4leta, millist \u00fclesannet ma p\u00fc\u00fcdsin lahendada, kui \u00fcritasin k\u00e4ivitada pod'i ilma d\u00e9ployement'ita, aga ma t\u00f5eliselt tahtsin lihtsalt pod'i k\u00e4ivitada. Otsustasin \u00f5nne nimel vaadata, millised \u00f5igused mul klastris on, mida ma saan teha, mida mitte, ja mida nad seal seadistanud on. Samuti r\u00e4\u00e4gin, mis neil RBAC-s valesti on seadistatud. <\/p>\n

<\/p>\n

Nii juhtus, et kahe minuti p\u00e4rast sain admini \u00f5igused nende klastrisse, vaatasin k\u00f5ikidesse naaber-namespacetesse, n\u00e4gin seal jooksmas tootmisfrontide ettev\u00f5tteid, kes olid juba teenuse ostnud ja d\u00e9ployinud. Ma pidin end vaevu tagasi hoidma, et mitte kellelegi fronti minna ja peamise lehe alla mingit roppust panna. <\/p>\n

<\/p>\n

Kannan n\u00e4idete abil, kuidas ma seda tegin ja kuidas sellest end kaitsta. <\/p>\n

<\/p>\n

Aga k\u00f5igepealt tutvustan end. Minu nimi on Pavel Selivanov. Olen ettev\u00f5tte Southbridge arhitekt. Tunnen h\u00e4sti Kubernetes, DevOpsi ja igasuguseid uusi trende. Meie insenerid Southbridge'is arendavad neid s\u00fcsteeme ning mina annan n\u00f5u. <\/p>\n

<\/p>\n

Lisaks oma p\u00f5hitegevusele k\u00e4ivitasime hiljuti projektid, mida nimetame SLErroriteks. P\u00fc\u00fcame oma oskusi Kubernetesega tuua laiemale publikule, \u00f5petades inimesi ka K8s-iga t\u00f6\u00f6tama. <\/p>\n

<\/p>\n

Millest ma t\u00e4na r\u00e4\u00e4gin. Ettekande teema on ilmselge \u2013 Kubernetes'i klastri turvalisus. Kuid tahan kohe \u00f6elda, et see teema on v\u00e4ga ulatuslik \u2014 seet\u00f5ttu tahan kohe selgelt \u00f6elda, millest ma ei kavatse r\u00e4\u00e4kida. Ma ei r\u00e4\u00e4gi kulunud m\u00f5istetest, mis on internetis juba sada korda l\u00e4bi k\u00e4idud, nagu RBAC ja sertifikaadid. <\/p>\n

<\/p>\n

Ma r\u00e4\u00e4gin sellest, mis muretseb mind ja mu kolleege Kubernetes'i klastri turvalisuse osas. Me n\u00e4eme neid probleeme nii Kubernetes'i klastrite pakkujates kui ka klientides, kes meie juurde tulevad. Ja ka klientides, kes tulevad meile teistest n\u00f5ustamisettev\u00f5tetest. See t\u00e4hendab, et trag\u00f6\u00f6dia ulatus on tegelikult v\u00e4ga suur. <\/p>\n

<\/p>\n

Kolm p\u00f5hipunkti, millest ma t\u00e4na r\u00e4\u00e4gin: <\/p>\n

<\/p>\n

    \n
  1. Kasutajate \u00f5igused vs pod'ide \u00f5igused. Kasutajate ja pod'ide \u00f5igused ei ole sama asi. <\/li>\n
  2. Klastri teabe kogumine. N\u00e4itan, et saame koguda kogu vajaliku teabe klassdist, ilma et meil oleks eraldi \u00f5igusi. <\/li>\n
  3. DoS-r\u00fcnnak klassdile. Kui me ei suuda teavet koguda, saame siiski klasse toimetada. R\u00e4\u00e4gin DoS-r\u00fcnnakutest klastri halduskomponentidele. <\/li>\n<\/ol>\n

    <\/p>\n

    Veel \u00fcks \u00fcldine asi, millest ma mainin \u2014 millega ma seda k\u00f5ike testisin, mille kohta ma kindlasti v\u00f5in \u00f6elda, et k\u00f5ik t\u00f6\u00f6tab.<\/p>\n

    <\/p>\n

    Aluseks v\u00f5tame Kubernetes klastrite seadistamise Kubespray abil. Kui keegi ei tea, siis see on tegelikult rollide kogum Ansible'ile. Kasutame seda pidevalt t\u00f6\u00f6s. Hea selle juures on see, et saame selle igale poole peale panna \u2014 nii riistvarale kui ka kuhugi pilve. \u00dcks installerimisviis sobib p\u00f5him\u00f5tteliselt k\u00f5ikjale. <\/p>\n

    <\/p>\n

    Selles klastris on mul Kubernetes v1.14.5. Kogu kubernerite klaster, mida kaalume, on jagatud nimedevaheks (namespace), kus iga nimedevahe kuulub eraldi meeskonnale ning igal meeskonnaliikmel on ligip\u00e4\u00e4s oma nimedevahe. Nad ei saa minna teistesse nimedevahesesse, ainult oma. Kuid on olemas adminni konto, millel on \u00f5igused kogu klastrile. <\/p>\n

    <\/p>\n

    \"Kattime<\/p>\n

    <\/p>\n

    Lubasin, et esimesena saame adminni \u00f5igused klastris. Me vajame spetsiaalselt ette valmistatud podi, mis purustab Kubernetes'e klastri. K\u00f5ik, mida peame tegema, on see rakendada Kubernetes'e klastrisse. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    See pod j\u00f5uab meile \u00fchele Kubernetes'e klastrite k\u00f5rgemale masinale. Ja klaster toob meile p\u00e4rast seda r\u00f5\u00f5muga tagasi faili nimega admin.conf. Kubernerites on selle failis talletatud k\u00f5ik adminni sertifikaadid ja seadistatud klastrite API. Nii lihtne on saada adminni ligip\u00e4\u00e4s , arvan, et 98% Kubernetes'e klastritest. <\/p>\n
    <\/p>\n
    Kordan, et selle podi tegi \u00fcks arendaja teie klastris, kellel on ligip\u00e4\u00e4s oma ettepanekute juurutamiseks \u00fches v\u00e4ikeses nimedevahes, ta on t\u00e4ielikult piiratud RBAC. Tal ei olnud mingeid \u00f5igusi. Siiski tagastati sertifikaat. <\/p>\n
    <\/p>\n
    N\u00fc\u00fcd r\u00e4\u00e4gime spetsiaalselt ettevalmistatud podist. K\u00e4ivitame selle igasuguste kujutistega. N\u00e4iteks v\u00f5tame debian:jessie. <\/p>\n
    <\/p>\n
    Meil on selline asi: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    Mis on toleration? Kuberneete klastris on meistrid tavaliselt m\u00e4rgitud asjaga, mida nimetatakse taint ('m\u00fcrg' inglise keeles). Selle \u00abm\u00fcrgi\u00bb p\u00f5hisisu on see, et meistrinodele ei saa pod'e m\u00e4\u00e4rata. Kuid keegi ei takista igal pod'il m\u00e4rkida, et ta on \u00abm\u00fcrgile\u00bb talutav. Toleration jaotis \u00fctleb just seda, et kui m\u00f5nel nodil on NoSchedule, siis meie pod on sellise m\u00fcrgiga talutav \u2014 ja ei tekki mingeid probleeme. <\/p>\n
    <\/p>\n
    Edasi liikudes, me \u00fctleme, et meie pod ei ole lihtsalt talutav, vaid soovib spetsiaalselt minna meistrile. Sest meistrites asub k\u00f5ige maitsvam asi, mida me vajame \u2014 k\u00f5ik sertifikaadid. Seet\u00f5ttu me \u00fctleme nodeSelector \u2014 ja meil on standardne silt meistrites, mis v\u00f5imaldab valida k\u00f5igist klastrinodidest just need nodid, mis on meistrid. <\/p>\n
    <\/p>\n
    Just nende kahe jaotisega j\u00f5uab pod kindlasti meistrile. Ja tal lubatakse seal elada. <\/p>\n
    <\/p>\n
    Kuid lihtsalt meistrile tulles ei piisa. See ei anna meile midagi. Seet\u00f5ttu on meil kaks olulist aspekti:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Me t\u00e4psustame, et meie pod, mille me k\u00e4ivitame, elab tuuma nimeteenuses, v\u00f5rgunimeteenuses ja PID nimeteenuses. Niipea kui pod k\u00e4ivitub meistril, n\u00e4eb ta k\u00f5iki selle s\u00f5lme reaalseid, t\u00f6\u00f6tavaid liidesi, kuulab kogu liiklust ja n\u00e4eb k\u00f5iki protsesside PID-sid.<\/p>\n
    <\/p>\n
    Edasi on vaid v\u00e4ike asi. V\u00f5tate etcd ja loete, mida soovite. <\/p>\n
    <\/p>\n
    K\u00f5ige huvitavam on see Kubernetes'i funktsioon, mis seal vaikimisi olemas on. <\/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
    Ja selle m\u00f5te on see, et me v\u00f5ime podis, mille me k\u00e4ivitame, isegi ilma \u00f5igusteta sellele klastrile, \u00f6elda, et soovime luua hostPath t\u00fc\u00fcpi mahutit. See t\u00e4hendab, et v\u00f5tame tee hostist, millel me k\u00e4ivitume \u2014 ja kasutame seda mahutina. Ja kui edasi nimetame selle name: host. Kogu see hostPath monteeritakse podi sisse. Antud n\u00e4ites vahemikku \/host. <\/p>\n
    <\/p>\n
    Kordan veel kord. Me \u00fctlesime podile tulla meistrisse, saada seal hostNetwork ja hostPID \u2014 ja kogu meistri juur monteeritakse selle podi sisse. <\/p>\n
    <\/p>\n
    Te m\u00f5istate, et Debianis t\u00f6\u00f6tab meil bash ja see bash t\u00f6\u00f6tab meie juures rootina. See t\u00e4hendab, et saime just root-\u00f5igused meistrile, omamata samas mingeid \u00f5igusi Kuberneteses.<\/p>\n
    <\/p>\n
    Edasi on kogu \u00fclesanne minna konteinerisse kausta \/host\/etc\/kubernetes\/pki, kui ma ei eksi, ja v\u00f5tta sealt k\u00f5ik klastrite meistrisertifikaadid, et vastavalt saada klastrihalduriks. <\/p>\n
    <\/p>\n
    Kui sellele lahku vaadata, on need \u00fched k\u00f5ige ohtlikumad \u00f5igused konteinerites \u2014 olenemata kasutaja \u00f5igustest:
    \n\"Kattime<\/p>\n
    <\/p>\n
    Kui mul on \u00f5igused konteinerite k\u00e4ivitamiseks m\u00f5nes klastrinimi ruumis, siis on sellel konteineril need \u00f5igused vaikimisi olemas. Ma saan k\u00e4ivitada privileegitud konteinerid, mis t\u00e4hendab sisuliselt k\u00f5iki \u00f5igusi, praktiliselt root-\u00f5igused s\u00f5lmes. <\/p>\n
    <\/p>\n
    Minu lemmik on Root kasutaja. Aga Kubernetesi jaoks on olemas v\u00f5imalus Run As Non-Root. See on nagu kaitse h\u00e4kkerite eest. Kas teate, mis on \"moldova viirus\"? Kui te olete kogemata h\u00e4kker ja olete tulnud minu Kubernetesi klastrisse, siis palume me, vaesed administraatorid: \"Palun m\u00e4rkige oma podides, millega te minu klastrit h\u00e4kkida plaanite, run as non-root. Sest muidu v\u00f5ib juhtuda, et k\u00e4itate protsessi oma podis rootina ja on v\u00e4ga lihtne mind h\u00e4kkida. Palun kaitske end ise.\" <\/p>\n
    <\/p>\n
    Host path volume \u2014 minu arvates k\u00f5ige kiirem viis soovitud tulemuse saavutamiseks Kubernetesi klastrist. <\/p>\n
    <\/p>\n
    Aga mida k\u00f5igega selle teete? <\/p>\n
    <\/p>\n
    M\u00f5tted, mis peaksid tulema igale normaalsele administraatorile, kes kohtub Kubernetesega: \"Ah, ma \u00fctlesin, Kubernetesi ei t\u00f6\u00f6ta. Seal on augud. Ja kogu asi on jama.\" Tegelikult on olemas selline asi nagu dokumentatsioon, ja kui sinna vaadata, siis seal on jagu Pod Security Policy<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    See on selline yaml-objekt, mida saame luua Kubernetes'i klastri raames, mis kontrollib turvaaspekte just pod'ide m\u00e4\u00e4ratlemisel. See t\u00e4hendab, et see kontrollib \u00f5igusi kasutada erinevaid hostNetwork, hostPID ja teatud t\u00fc\u00fcpi volume, mis on pod'ides k\u00e4ivitamisel. Pod Security Policy abil saab k\u00f5ike seda kirjeldada. <\/p>\n
    <\/p>\n
    Pod Security Policy k\u00f5ige huvitavam osa on see, et Kubernetes'i klastri k\u00f5ik PSP-d pole lihtsalt kirjeldatud, vaid need on vaikimisi v\u00e4lja l\u00fclitatud. Pod Security Policy lubatakse admission plugin'i abil.<\/p>\n
    <\/p>\n
    Nii et juurutame klastri Pod Security Policy, \u00fctleme, et meil on teatud teenus pod'id nimetehnikas, millele p\u00e4\u00e4sevad ligi ainult adminnid. \u00dctleme, et k\u00f5igil teistel pod'idel on piiratud \u00f5igused. Sest t\u00f5en\u00e4oliselt pole arendajatele vaja teie klastris privileegitud pod'e k\u00e4ivitada. <\/p>\n
    <\/p>\n
    Ja tundub, et k\u00f5ik on h\u00e4sti. Meie Kubernetes'i klastrit ei saa kahe minuti jooksul h\u00e4kkida. <\/p>\n
    <\/p>\n
    Kuid probleem on. T\u00f5en\u00e4oliselt, kui teil on Kubernetes'i klaster, siis on sellesse installitud j\u00e4lgimiss\u00fcsteem. Ma julgen isegi ennustada, et kui teie klastri j\u00e4lgimise s\u00fcsteem on olemas, siis see on nimega Prometheus. <\/p>\n
    <\/p>\n
    See, mida ma praegu r\u00e4\u00e4kima hakkan, kehtib nii Prometheus-operatori kui ka puhta Prometheuse kohta. K\u00fcsimus on selles, et kui ma ei suuda klastrisse administraatorit nii kiiresti saada, siis t\u00e4hendab see, et pean rohkem otsima. Ja ma saan otsida teie j\u00e4lgimise abil.<\/p>\n
    <\/p>\n
    T\u00f5en\u00e4oliselt on k\u00f5ik lugenud samu artikleid Habr's ja j\u00e4lgimine asub nimiruumis monitoring. Helm chart on k\u00f5igil enam-v\u00e4hem sama nimega. Eeldan, et kui teete helm install stable\/prometheus, siis on teil umbkaudu sama nimed. Ja t\u00f5en\u00e4oliselt ei pea ma teie klastris DNS-nime \u00e4ra arvama. Sest see on standardne. <\/p>\n
    <\/p>\n
    \"Kattime<\/p>\n
    <\/p>\n
    Edasi on meil mingi dev ns, kus saab k\u00e4ivitada mingit podi. Ja sealt podist on v\u00e4ga lihtne teha j\u00e4rgmist: <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    prometheus-kube-state-metrics on \u00fcks Prometheuse eksportija, mis kogub m\u00f5\u00f5dikuid Kubernetes'i API-st. Seal on v\u00e4ga palju andmeid selle kohta, mis teil klastris on k\u00e4imas, millised need on ja millised probleemid teil nende tegemisega on. <\/p>\n
    <\/p>\n
    Lihtsaks n\u00e4iteks: <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\u00abkube-system»,pod=»kube-apiserver-k8s- 1″,container=»kube-apiserver»,image= <\/p>\n
    <\/p>\n
    «gcr.io\/google-containers\/kube-apiserver:v1.14.5» <\/strong><\/p>\n
    <\/p>\n
    ,image_id=»docker-pullable:\/\/gcr.io\/google-containers\/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1 <\/p>\n
    <\/p>\n
    Lihtsa curl p\u00e4ringu tegemisega privileegideta podist saad sellist teavet. Kui te ei tea, millises versioonis Kubernetes on k\u00e4ivitatud, siis see r\u00e4\u00e4gib teile selle lihtsalt. <\/p>\n
    <\/p>\n
    Ja k\u00f5ige huvitavam on see, et lisaks sellele, et te p\u00f6\u00f6rdute kube-state-metrics'i poole, v\u00f5ite samal ajal p\u00f6\u00f6rduda ka Prometheus'e poole otse. Te saate sealt koguda m\u00f5\u00f5dikud. Te v\u00f5ite isegi ehitada sealt m\u00f5\u00f5dikud. Teoreetiliselt v\u00f5ite koostada sellise p\u00e4ringu klastrist Prometheus'e suunas, mis lihtsalt sulgeb selle. Ja teie j\u00e4lgimine peatub t\u00e4ielikult klastrist. <\/p>\n
    <\/p>\n
    Ja n\u00fc\u00fcd tekib k\u00fcsimus, kas m\u00f5ni v\u00e4line j\u00e4lgimine j\u00e4lgib teie j\u00e4lgimist. Just n\u00fc\u00fcd sain ma v\u00f5imaluse tegutseda Kubernetes'i klastris ilma mingite tagaj\u00e4rgedeta. Te isegi ei saa teada, et ma seal tegutsen, kuna j\u00e4lgimist ei ole enam. <\/p>\n
    <\/p>\n
    Sarnaselt PSP-le v\u00f5ib tunduda, et probleem on selles, et k\u00f5ik need moodsad tehnoloogiad \u2013 Kubernetes, Prometheus \u2013 lihtsalt ei toimi ja on t\u00e4is vigu. Tegelikult ei ole see nii. <\/p>\n
    <\/p>\n
    On selline asi nagu \u2013 Network Policy<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Kui olete normaalne administraator, siis t\u00f5en\u00e4oliselt teate Network Policy-st, et see on j\u00e4rjekordne yaml, mida klastris on ja nii palju. Ja Network Policies pole kindlasti vajalikud. Ja isegi kui olete lugenud, mis on Network Policy, et see on Kubernetes'i yaml-tulem\u00fc\u00fcr, mis v\u00f5imaldab piirata juurdep\u00e4\u00e4su namespace'de vahel, pod'ide vahel, siis olete kindlasti otsustanud, et yaml-formaadis tulem\u00fc\u00fcr Kubernetes'is on j\u00e4rgmiste abstraktsioonide peal\u2026 Ei-ei. See pole t\u00f5eliselt vajalik. <\/p>\n
    <\/p>\n
    Isegi kui teie turbespetsialistidele ei ole r\u00e4\u00e4gitud, et teie Kubernetesega saab v\u00e4ga lihtsalt ja mugavalt tulem\u00fc\u00fcri luua, seejuures v\u00e4ga granuleeritud. Kui nad ei tea seda veel ja ei k\u00fcsi teilt: \u201eNoh, andke, andke\u2026\u201c Igal juhul on Network Policy teil vajalik, et sulgeda juurdep\u00e4\u00e4s teatud teeninduskohtadele, mis teie klastrist on v\u00f5imalik k\u00fclastada ilma mingisuguse volituse olemasoluta. <\/p>\n
    <\/p>\n
    Nagu eespool mainitud, saab kube state metricsi t\u00f5mmata mistahes Kubernetes'i klastris asuvast nimiruumist, omamata selleks mingeid \u00f5igusi. V\u00f5rgupoliitikad on blokeerinud juurdep\u00e4\u00e4su k\u00f5ikidest teistest nimiruumidest j\u00e4lgimisnimiruumi ja nagu niisugune: puudub juurdep\u00e4\u00e4s, puuduvad probleemid. K\u00f5ikides chartides, olgu need siis tavaline Prometheus v\u00f5i see, mis on operaatori kaudu, on helm'i v\u00e4\u00e4rtustes lihtsalt v\u00f5imalus lihtsalt sisse l\u00fclitada v\u00f5rgupoliitikad nende jaoks. Lihtsalt tuleb sisse l\u00fclitada ja need hakkavad t\u00f6\u00f6tama. <\/p>\n
    <\/p>\n
    Siin on t\u00f5esti \u00fcks probleem. Normaalne administraator oleks t\u00f5en\u00e4oliselt otsustanud, et v\u00f5rgupoliitikad ei ole vajalikud. Lugedes igasuguseid artikleid platformidelt nagu Habr, otsustasite, et flannel, eriti host-gateway re\u017eiimis, on parim, mida valida saate. <\/p>\n
    <\/p>\n
    Mis teha? <\/p>\n
    <\/p>\n
    Saate proovida \u00fcmber paigaldada oma Kubernetes klastris olevat v\u00f5rgu lahendust ja asendada see millegagi funktsionaalsemaga. N\u00e4iteks sama Calico. Kuid tahan kohe \u00f6elda, et v\u00f5rgu lahenduse vahetamine t\u00f6\u00f6tavas Kubernetes klastris on \u00fcsna keeruline \u00fclesanne. Olen seda kaks korda lahendanud (m\u00f5lemal korral teoreetiliselt), kuid isegi Sl\u00f5rvadel n\u00e4itasime, kuidas seda teha. Meie \u00f5pikutes n\u00e4itasime, kuidas vahetada v\u00f5rgu lahendust Kubernetes klastris. \u00dches\u00f5naga, v\u00f5ite proovida teha nii, et tootmisklastri puhul ei tekiks katkestusi. Kuid t\u00f5en\u00e4oliselt ei \u00f5nnestu teil see. <\/p>\n
    <\/p>\n
    Ja probleem lahendatakse tegelikult v\u00e4ga lihtsalt. Klaster sisaldab sertifikaate, ja teate, et teie sertifikaadid aeguvad aasta p\u00e4rast. Tavaline lahendus sertifikaatide puhul klastris on see, et meil pole p\u00f5hjust muretseda \u2014 me t\u00f5stame \u00fcles uue klastri, vanas lastakse lihtsalt aeguda, ja seej\u00e4rel k\u00f5ik paigaldame \u00fcmber. T\u00f5si, kui see aegub, v\u00f5ib meil n\u00e4dal aega asjad seisma j\u00e4\u00e4da, aga v\u00e4hemalt on uus klaster. <\/p>\n
    <\/p>\n
    Kui t\u00f5state \u00fcles uue klastri, pange ka Calico asemele flannel. <\/p>\n
    <\/p>\n
    Mida teha, kui teil on sertifikaadid, mis on v\u00e4ljastatud sadaks aastaks ja te ei kavatse klastrit \u00fcmber paigutada? On olemas selline asi nagu Kube-RBAC-Proxy. See on v\u00e4ga lahe areng, mis v\u00f5imaldab end integreerida sidecar konteinerina igasse pod'i Kubernetes klastris. Ja see tegelikult lisab sellele pod'ile autentimise l\u00e4bi Kubernetes'e RBAC-i. <\/p>\n
    <\/p>\n
    \u00dcks probleem on. Varasemalt oli Prometheuse operaatoris see lahendus Kube-RBAC-Proxy sisse ehitatud. Kuid siis seda enam ei olnud. Praegused versioonid toetuvad sellele, et teil on olemas v\u00f5rgu poliitika ja saate neid kasutades sulgeda. Seet\u00f5ttu tuleb veidi chart'u \u00fcmber kirjutada. Kui te sitouute sellesse repositooriumi<\/a><\/noindex>, seal on n\u00e4ited, kuidas seda sidecar'idena kasutada, ja chardi tuleb minimaalselt \u00fcmber kirjutada. <\/p>\n
    <\/p>\n
    On veel \u00fcks v\u00e4ike probleem. Mitte ainult Prometheus ei edasta oma m\u00f5\u00f5dikuid kellelegi. K\u00f5ik Kubernetes klastri komponendid oskavad samuti oma m\u00f5\u00f5dikuid edastada. <\/p>\n
    <\/p>\n
    Aga nagu ma juba \u00fctlesin, kui ei saa juurdep\u00e4\u00e4su klastrile ja teavet koguda, siis v\u00e4hemalt saab kahju teha. <\/p>\n
    <\/p>\n
    Nii et ma n\u00e4itan kiiresti kahte viisi, kuidas Kubernetes klastrit kahjustada. <\/p>\n
    <\/p>\n
    Te naerate, kui ma seda r\u00e4\u00e4gin, need on kaks t\u00f5elist juhtumit. <\/p>\n
    <\/p>\n
    Esimene viis. Ressursside ammendumine. <\/p>\n
    <\/p>\n
    K\u00e4ivitame veel \u00fche spetsiaalse poodi. Sellel on selline osa. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Nagu te teate, on requests see arv CPU ja m\u00e4lu, mis hostis reserveeritakse konkreetsete podide jaoks, millel on requests. Kui meil on neljatuumaline host Kubernetes klastris ja sinna tuleb pod, millel on neli CPU requests, siis ei saa sinna rohkem pod'e sellel hostil olla. <\/p>\n
    <\/p>\n
    Kui ma k\u00e4ivitada sellise poodi, siis teen k\u00e4su: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Siis ei saa keegi enam Kubernetes klastrisse deployida. Sest k\u00f5igil nodidel saavad requests otsa. Ja niimoodi ma peatan teie Kubernetes klastrit. Kui ma seda \u00f5htul teen, siis v\u00f5in deploy'id \u00fcsna pikaks ajaks peatada. <\/p>\n
    <\/p>\n
    Kui vaatame veel kord Kubernetes'i dokumentatsiooni, siis m\u00e4rkame seal m\u00f5istet, mida nimetatakse Limit Range. See seab ressursside piirangud klastrite objektidele. Saate kirjutada yaml-faili Limit Range objekti, rakendada selle teatud namespace'idesse \u2014 ja p\u00e4rast saate \u00f6elda, et antud namespace'is on podide jaoks vaikimisi, maksimaalsed ja minimaalsed ressursid.<\/p>\n
    <\/p>\n
    Sellise lahenduse abil saame piirata kasutajaid konkreetsetes toote namespace'ides, sundides nende podide ressursin\u00f5udeid v\u00e4hem rikastama. Kuid kahjuks, isegi kui \u00fctlete kasutajale, et nad ei tohi k\u00e4ivitada pod'e, mille n\u00f5uded \u00fcletavad \u00fchte CPU-d, on olemas selline tore k\u00e4sk scale, v\u00f5i nad saavad seda teha ka l\u00e4bi dashboadi.<\/p>\n
    <\/p>\n
    Ja siit tulebki teine meetod. K\u00e4ivitame 11 111 111 111 111 pod'i. See t\u00e4hendab \u00fcksteist miljardit. See ei ole sellep\u00e4rast, et ma sellist numbrit v\u00e4lja m\u00f5tlesin, vaid kuna ma ise olen seda n\u00e4inud. <\/p>\n
    <\/p>\n
    T\u00f5eline lugu. Hilja \u00f5htul, kui ma juba kontorist lahkuma valmis olin, n\u00e4gin, et nurga taga istus grupp arendajaid ja tegelesid millegagi oma s\u00fclearvutites. Astusin poisid juurde ja k\u00fcsisin: \u201eMis teiega juhtus?\u201d<\/p>\n
    <\/p>\n
    Veidi varem, kell 9 \u00f5htul, kavatses \u00fcks arendajatest koju minna. Ja otsustas: \"Ma skaleerin oma rakendust n\u00fc\u00fcd \u00fchele.\" Vajutas \u00fchte, kuid internet hakkas natuke t\u00f5rkeid andma. Ta vajutas veel kord \u00fchte, ta surus \u00fchte, kl\u00f5psas Enterile. Ta n\u00e4ppis k\u00f5ike, millesse sai. Siis internet taastus \u2014 ja k\u00f5ik hakkas skaleerima sellele numbrile. <\/p>\n
    <\/p>\n
    T\u00f5si, see lugu ei toimunud Kuberneteses, toona oli see Nomad. See l\u00f5ppes sellega, et tunni jooksul meie katsetest peatada Nomad selle j\u00e4rjepidevatest skaleerimise katsetest vastas Nomad, et skaleerimist ei l\u00f5petata ja millegagi muuga tegeleda ei soovita. \"Ma olen v\u00e4sinud, ma lahkun.\" Ja sulgus. <\/p>\n
    <\/p>\n
    Ma loomulikult proovisin teha sama Kuberneteses. \u00dcksteist miljardit podi Kuberneteses ei r\u00f5\u00f5mustanud, ta \u00fctles: \"Ei saa. \u00dcletab sisemised limiidid.\" Aga 1 000 000 000 podi suutis. <\/p>\n
    <\/p>\n
    \u00dcks miljard kuupi ei kadunud. See t\u00f5epoolest hakkas skaleerima. Mida kaugemal protsess edasi liikudes, seda rohkem aega kulus uute podide loomisele. Kuid protsess ikkagi j\u00e4tkus. Ainuke probleem on see, et kui ma saan oma nimespatsioonis piiramatult pod'e k\u00e4ivitada, siis isegi ilma p\u00e4ringute ja piiranguteta v\u00f5in ma k\u00e4ivitada nii palju pod'e, et nende kaudu hakkab m\u00e4lu ja protsessori kasutuse osas node'de potentsiaal kuhjuma. Kui ma k\u00e4ivitada nii palju pod'e, peavad neist saadud andmed j\u00f5udma salvestisse, teisis\u00f5nu etcd-sse. Ja kui sinna j\u00f5uab liiga palju teavet, hakkab salvestis liiga aeglaselt reageerima \u2014 ja Kubernetesel hakkavad tekkima viivitused. <\/p>\n
    <\/p>\n
    Ja veel \u00fcks probleem \u2026 Nagu teate, Kubernetes'i haldamise elemendid ei ole \u00fcks keskne seade, vaid mitu komponenti. Seal on eelk\u00f5ige manager controller, scheduler ja nii edasi. K\u00f5ik need tegelased hakkavad samal ajal tegema ebaolulist, m\u00f5ttetut t\u00f6\u00f6d, mis aja jooksul hakkab v\u00f5tma j\u00e4rjest rohkem ja rohkem aega. Manager controller loob uusi pod'e. Scheduler p\u00fc\u00fcab neile leida uut s\u00f5lme. Uued s\u00f5lmed teie klastris on t\u00f5en\u00e4oliselt varsti otsas. Kubernetes'i klaster hakkab t\u00f6\u00f6tama j\u00e4rjest aeglasemalt.<\/p>\n
    <\/p>\n
    Aga ma otsustasin minna veel kaugemale. Nagu te teate, on Kubernetes'is selline asi nagu teenus. Ja t\u00f5en\u00e4oliselt t\u00f6\u00f6tab teie klastrites teenus vaikimisi IP tabelite kaudu. <\/p>\n
    <\/p>\n
    Kui k\u00e4ivitada n\u00e4iteks miljard pod'i ja seej\u00e4rel sundida Kubernetes'it looma uusi teenuseid skripti abil: <\/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
    Klastri k\u00f5ikidel s\u00f5lmedel genereeritakse umbes samal ajal pidevalt uusi iptables reegleid. Iga teenuse jaoks genereeritakse miljard iptables reeglit. <\/p>\n
    <\/p>\n
    Olen seda kontrollinud paaril tuhandel, kuni k\u00fcmneni. Probleem on selles, et juba selle piiri peal on ssh-le s\u00f5lmele ligip\u00e4\u00e4s \u00fcsna keeruline. Kuna paketid, l\u00e4bides sellise arvu ahelate kaudu, hakkavad end mitte v\u00e4ga h\u00e4sti tundma. <\/p>\n
    <\/p>\n
    Seda saab lahendada ka Kubetnetese abil. Seal on selline objekt nagu Resource quota. See m\u00e4\u00e4rab neesp\u00e4isale saadaval olevate ressursside ja objektide arvu klastri sees. Saame luua yaml objekti igas Kubetnetese neesp\u00e4isalas. Selle objekti abil saame \u00f6elda, et meil on selle neesp\u00e4isa jaoks m\u00e4\u00e4ratud kindel hulk p\u00e4ringuid, limite ja edasi saame \u00f6elda, et selles neesp\u00e4isas on v\u00f5imalik luua 10 teenust ja 10 poodi. Ja arendaja saab vaid koguda \u00f5htuti. Kubetnetes \u00fctleb talle: 'Teie poode ei ole v\u00f5imalik kasvatada sellesse hulka, kuna see \u00fcletab ressursside kvota.' K\u00f5ik, probleem on lahendatud. Dokumentatsioon siin<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    \u00dcks probleemne moment seondub sellega. Tunnete, kui keeruliseks muutub nimi ruumi loomine Kuberneteses. Selle loomiseks peame arvestama paljude faktoritega.<\/p>\n
    <\/p>\n
    Ressursikvoot + Piirangute vahemik + RBAC
    \n\u2022 Loome nimi ruumi
    \n\u2022 Loome sisemised piirangute vahemikud
    \n\u2022 Loome sisemised ressursikvoodid
    \n\u2022 Loome service accounti CI jaoks
    \n\u2022 Loome rolli sidumise CI ja kasutajate jaoks
    \n\u2022 Soovi korral k\u00e4ivitame vajalikud teeninduspodid <\/p>\n
    <\/p>\n
    Seega, kasutades v\u00f5imalust, sooviksin jagada oma arendusi. On olemas selline asi, mida nimetatakse operaatori SDK-ks. See on viis kirjutada Kuberneteses operaatorite jaoks. Saate kirjutada operaatorid Ansible'i abil.<\/p>\n
    <\/p>\n
    Alguses oli see kirjutatud Ansible'is ja siis vaatasin, et olemas on operaatori SDK, ja kirjutasin Ansible'i rolli operaatoriks \u00fcle. See operaator v\u00f5imaldab luua Kuberneteses objekti, mida nimetatakse k\u00e4suks. K\u00e4su sees lubab see kirjeldada YAML-is keskkonda sellele k\u00e4sule. Ja k\u00e4su keskkonnas lubab see kirjeldada, kui palju ressursse me eraldame. <\/p>\n
    <\/p>\n
    V\u00e4ike kergendus kogu selle keerulise protsessi jaoks<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Ja l\u00f5petuseks. Mida k\u00f5igega sellel teha?
    \nEsiteks. Pod Security Policy on hea. Ja kuigi \u00fckski Kubernetes'e paigaldaja ei kasuta neid siiani, on oluline neid siiski oma klastrites rakendada. <\/p>\n
    <\/p>\n
    Network Policy ei ole lihtsalt veel \u00fcks tarbetu funktsioon. See on midagi, mida kluster t\u00f5eliselt vajab. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota \u2014 aeg oleks need kasutusele v\u00f5tta. Me oleme neid juba pikka aega kasutanud ja ma olin kindel, et k\u00f5ik kasutavad neid, aga selgus, et see on haruldus. <\/p>\n
    <\/p>\n
    Lisaks sellele, millest ma oma ettekandes r\u00e4\u00e4kisin, on olemas dokumenteerimata funktsioonid, mis v\u00f5imaldavad klastrit r\u00fcnnata. Hiljuti ilmus suur anal\u00fc\u00fcs Kubernetes'e haavatavustest.<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    M\u00f5ned asjad on nii kurvad ja h\u00e4irivad. N\u00e4iteks v\u00f5ivad Kubernetes'e klastris teatud tingimustel kubeletid kinkida warlocks kausta sisu volitamata kasutajale. <\/p>\n
    <\/p>\n
    Siin<\/a><\/noindex> Seal on juhised, kuidas reprodutseerida k\u00f5ike, millest ma r\u00e4\u00e4kisin. Seal on failid tootmisn\u00e4idistega, kuidas ResourceQuota ja Pod Security Policy v\u00e4lja n\u00e4evad. Ja seda k\u00f5ike saab katsetada. <\/p>\n
    <\/p>\n
    Ait\u00e4h k\u00f5igile.<\/p>\n
    Allikas: 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\udd47K\u00fcberturvalisuse l\u00fcngad Kubernetes'i klastris. Ettekande ja protokoll DevOpsConf'ist | ProHoster","description":"Pavel Selivanov, Southbridge'i lahenduste arhitekt ja SLRM \u00f5petaja, esines DevOpsConf 2019 konverentsil ettekandega. See ettekand on osa s\u00fcvitsi mineva kursuse teemadest Kubernetes \u201eSLRM Mega\u201d. SLRM Baas: sissejuhatus Kubernetesesse toimub Moskvas 18-20. novembril. SLRM Mega: vaatame, mis peitub Kubernetes'e kapoti all \u2014 Moskvas, 22-24. novembril. SLRM Online: m\u00f5lemad Kubernetes'e kursused on alati saadaval.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0417\u0430\u0434\u0435\u043b\u044b\u0432\u0430\u0435\u043c \u0434\u044b\u0440\u044b \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u0414\u043e\u043a\u043b\u0430\u0434 \u0438 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0441 DevOpsConf | ProHoster","og:description":"\u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019. \u042d\u0442\u043e\u0442 \u0434\u043e\u043a\u043b\u0430\u0434 \u2014 \u0447\u0430\u0441\u0442\u044c \u043e\u0434\u043d\u043e\u0439 \u0438\u0437 \u0442\u0435\u043c \u0443\u0433\u043b\u0443\u0431\u043b\u0435\u043d\u043d\u043e\u0433\u043e \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u00ab\u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430\u00bb. \u0421\u043b\u0451\u0440\u043c \u0411\u0430\u0437\u043e\u0432\u044b\u0439: \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 Kubernetes \u043f\u0440\u043e\u0445\u043e\u0434\u0438\u0442 \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 18-20 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430: \u0437\u0430\u0433\u043b\u044f\u0434\u044b\u0432\u0430\u0435\u043c \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442 Kubernetes \u2014 \u041c\u043e\u0441\u043a\u0432\u0430, 22-24 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041e\u043d\u043b\u0430\u0439\u043d: \u043e\u0431\u0430 \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u0434\u043e\u0441\u0442\u0443\u043f\u0435\u043d \u0432\u0441\u0435\u0433\u0434\u0430.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:28:25+00:00","article:modified_time":"2019-10-31T19:28:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39203","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:15:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:43","updated":"2026-01-24 01:15:20"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/39203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}