{"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":"T\u00e4idame Kubernetes klastris esinevaid puuduj\u00e4\u00e4ke. Ettekanne ja t\u00f5lge DevOpsConfilt.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, lahenduste arhitekt Southbridge'is ja Slurma \u00f5petaja, esitles ettekannet DevOpsConf 2019. See ettekand on osa s\u00fcvainte kursusest Kubernetes \"Slurma Mega\".<\/p>\n

<\/p>\n

Slurma Baas: sissejuhatus Kubernetesesse<\/a><\/noindex> toimub Moskvas 18.-20. novembril.
\nSlurma Mega: vaatame Kubernetes'e kapoti alla<\/a><\/noindex> \u2014 Moskvas, 22.-24. novembril.
\nSlurma Veebis: m\u00f5lemad kursused Kubernetesest<\/a><\/noindex> saadaval igal ajal.<\/p>\n

\n

\r\n \"M\u00e4ngi\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

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

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

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

<\/p>\n

N\u00e4en, et saalis on t\u00e4na palju turvaeksperte. Vabandan ette, kui kasutan turvamaailmast termineid, mis ei pruugi teie jaoks tuttavad olla. <\/p>\n

<\/p>\n

Nii juhtus, et umbes kuus kuud tagasi sattusin ma \u00fchte avalikku Kubernetes'e klastrisse. Avalik \u2014 t\u00e4hendab, et seal on n-\u00f6 erinevad namespaces, milles on kasutajad, kes on oma namespaces eraldi. K\u00f5ik need kasutajad kuuluvad erinevatesse ettev\u00f5tetesse. Eeldati, et seda klastrit kasutatakse CDN-ina. See t\u00e4hendab, et teile antakse klaster, antakse sinna kasutaja, te tulete oma namespace'i, deponeerite oma esindused. <\/p>\n

<\/p>\n

Minu endisele ettev\u00f5ttele p\u00fc\u00fcti sellist teenust m\u00fc\u00fca. Ja mind paluti uurida, kas see lahendus sobib v\u00f5i mitte. <\/p>\n

<\/p>\n

L\u00e4ksin ma selle klastrisse. Mul anti piiratud \u00f5igused, piiratud namespace. Seal olid inimesed, kes m\u00f5istsid, mis on turvalisus. Nad olid lugenud, mis on Kubernetes'e p\u00f5hine juurdep\u00e4\u00e4su kontroll (RBAC) \u2014 ja nad olid selle seadnud nii, et ma ei saanud k\u00e4itada pod'e eraldi deployement'idest. Ei m\u00e4leta, missugust \u00fclesannet ma \u00fcritasin lahendada, k\u00e4itades pod'i ilma deployement'ita, aga mulle v\u00e4ga meeldis lihtsalt pod'iga katsetada. Otsustasin juhuslikult uurida, mis \u00f5igused mul klastris on, mida ma saan ja mida mitte, mida nad seal kokku keeranud olid. \u00dchtlasi r\u00e4\u00e4gin, mis on nende RBAC-is valesti seadistatud. <\/p>\n

<\/p>\n

Nii juhtus, et kahe minuti p\u00e4rast sain adminni \u00f5igused nende klastrisse, vaatasin k\u00f5iki naaber namespaces'e, n\u00e4gin seal t\u00f6\u00f6tavaid tootmisfrontte ettev\u00f5tetelt, kes olid juba teenuse ostnud ja oma asjad \u00fcles seadnud. Pidin end vaevu tagasi hoidma, et mitte kellegi veebilehe esilehele sobitada m\u00f5nda roppust. <\/p>\n

<\/p>\n

R\u00e4\u00e4gin n\u00e4idete abil, kuidas ma seda tegin ja kuidas sellise asja eest kaitsta. <\/p>\n

<\/p>\n

Aga alustuseks tutvustan end. Minu nimi on Pavel Selivanov. Olen Southbridge'i arhitekt. Ma oskan Kubernetesest, DevOpsist ja muudest trendikatest asjadest r\u00e4\u00e4kida. Koos Southbridge'i inseneridega ehitame me seda k\u00f5ike, mina teen konsultatsioone. <\/p>\n

<\/p>\n

Peale p\u00f5hitegevuse oleme hiljuti k\u00e4ivitanud projektid, mida nimetatakse Sl\u00f6rmideks. Me proovime oma oskusi Kuberneteses natuke laiemalt jagada, \u00f5petada teisi inimesi ka K8s-iga t\u00f6\u00f6tama. <\/p>\n

<\/p>\n

Millest ma t\u00e4na r\u00e4\u00e4gin. Esitluse teema on ilmne \u2014 Kubernetes'i klastrite turvalisus. Kuid tahan kohe \u00f6elda, et see teema on v\u00e4ga suur \u2014 ja seet\u00f5ttu tahan kohtuda nende punktidega, millest ma kindlasti ei r\u00e4\u00e4gi. Ma ei hakka r\u00e4\u00e4kima kulunud terminoloogiatest, mis on internetis juba sada korda l\u00e4bi vaieldud. K\u00f5ik sellised RBAC'id ja sertifikaadid. <\/p>\n

<\/p>\n

R\u00e4\u00e4gin sellest, mis muret teeb mulle ja mu kolleegidele Kubernetes'i klastrite turvalisuses. N\u00e4eme neid probleeme nii Kubernetese klastreid pakkuvatelt teenusepakkujatelt kui ka klientidelt, kes meile p\u00f6\u00f6rduvad. Ja isegi klientidelt, kes tulevad meile teistelt konsultatsioonihaldusettev\u00f5tetelt. Seega, trag\u00f6\u00f6dia ulatus on tegelikult v\u00e4ga suur. <\/p>\n

<\/p>\n

Kokku kolm punkti, millest ma t\u00e4na r\u00e4\u00e4gin: <\/p>\n

<\/p>\n

    \n
  1. Kasutajate \u00f5igused vs pod'ide \u00f5igused. Kasutajate \u00f5igused ja pod'ide \u00f5igused \u2014 see pole sama asi. <\/li>\n
  2. Teabe kogumine klastrist. N\u00e4itan, et klastrist saab kogu vajaliku teabe koguda, ilma eriliste \u00f5igusteta. <\/li>\n
  3. DoS-r\u00fcnnak klastrile. Kui me ei saa teavet koguda, suudame siiski klastrit kokku varistada. R\u00e4\u00e4gin DoS-r\u00fcnnakutest klastrite juhtkomponentide peale. <\/li>\n<\/ol>\n

    <\/p>\n

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

    <\/p>\n

    V\u00f5tame aluseks Kubernetes'i klastrite loomise Kubespray abil. Kui keegi ei tea, siis see on tegelikult Ansible'i jaoks m\u00f5eldud rollide kogum. Kasutame seda pidevalt t\u00f6\u00f6s. See on hea, sest seda saab rakendada igasugustele seadmetele \u2014 nii metallile kui ka pilve. \u00dcks installatsiooni viis sobib igasuguste jaoks. <\/p>\n

    <\/p>\n

    Selles klastris on mul Kubernetes v1.14.5. Kogu Kubase klaster, mida me vaatame, on jagatud nime ruumideks, iga nime ruum kuulub erinevale meeskonnale, ja igal meeskonna liikmel on juurdep\u00e4\u00e4s oma nime ruumile. Nad ei saa siseneda teistesse nime ruumidesse, vaid ainult oma. Kuid on olemas \u00fche adminni konto, millel on \u00f5igused kogu klastrile. <\/p>\n

    <\/p>\n

    \"T\u00e4idame<\/p>\n

    <\/p>\n

    Lubasin, et esimesena saadakse adminni \u00f5igused klastrile. Meile on vajalik spetsiaalselt ette valmistatud pod, mis l\u00f5hub Kubernetes klastrit. K\u00f5ik, mida peame tegema, on see klastrisse rakendada. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    See pod saabub \u00fche klastrite Kubernetes juhtkonda. Ja klaster tagastab meile seej\u00e4rel faili nimega admin.conf. Selles failis hoitakse k\u00f5iki adminni sertifikaate ja samal ajal on seadistatud klastrite API. Nii lihtne on saada adminni juurdep\u00e4\u00e4s, ma arvan, et 98% Kubernetes klastritest. <\/p>\n
    <\/p>\n
    Korraks, see pod tegi \u00fcks arendaja teie klastris, kellel on juurdep\u00e4\u00e4s oma ettepanekute rakendamiseks \u00fchte v\u00e4ikesse nime ruumi, ta on t\u00e4ielikult RBAC poolt piiratud. Tal polnud mingeid \u00f5igusi. Kuid sellest hoolimata tagastati sertifikaat. <\/p>\n
    <\/p>\n
    N\u00fc\u00fcd r\u00e4\u00e4kides spetsiaalselt ette valmistatud podist. K\u00e4ivitame selle mis tahes pildiga. 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? Kubernetes klastris on juhid tavaliselt m\u00e4rgitud asjaga, mida nimetatakse taint (\"saaste\" inglise keeles). Selle \"saaste\" m\u00f5te on see, et juhitavaid s\u00fcdamikke ei saa m\u00e4\u00e4rata podide jaoks. Kuid keegi ei takista igas podis m\u00e4rkida, et ta on saaste suhtes tolerantne. Toleration sektsioon \u00fctleb just seda, et kui m\u00f5nel s\u00fcdamekesel on NoSchedule, siis on meie pod sellele saastele tolerantne \u2014 ja mingeid probleeme ei teki. <\/p>\n
    <\/p>\n
    Edasi, me \u00fctleme, et meie pod ei ole lihtsalt tolerantne, vaid soovib tungida spetsiaalselt juhile. Kuna juhil on k\u00f5ik maitsvamad asjad, mida me vajame \u2014 k\u00f5ik sertifikaadid. Seet\u00f5ttu \u00fctleme nodeSelector \u2014 ja meil on standardne label juhtidel, mis v\u00f5imaldab valida kogu klastrist just need s\u00fcdamikud, mis on juhid. <\/p>\n
    <\/p>\n
    Just selliste kahe sektsiooni puhul tuleb pod kindlasti juhile. Ja talle lubatakse seal elada. <\/p>\n
    <\/p>\n
    Kuid lihtsalt juhile j\u00f5udmine ei ole piisav. See ei pruugi midagi anda. Seet\u00f5ttu on meil sellised kaks asja:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Me m\u00e4rgime, et meie pod, mille me k\u00e4ivitame, elab kerni namespaces, network namespaces ja PID namespaces. Kui pod on masternodes k\u00e4ivitunud, suudab see n\u00e4ha k\u00f5iki t\u00f5elisi, elavaid liideseid selle nodi peal, kuulata kogu liiklust ja n\u00e4ha k\u00f5iki protsesside PID-sid.<\/p>\n
    <\/p>\n
    Edasi on j\u00e4\u00e4nud v\u00e4ike asi. V\u00f5tke etcd ja looge, mida soovite. <\/p>\n
    <\/p>\n
    K\u00f5ige huvitavam on see, et see on Kubernetes'e v\u00f5imalus, mis on seal vaikimisi olemas. <\/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 olemus on see, et me saame podis, mille me k\u00e4ivitame, isegi ilma \u00f5igusteta sellele klastrile, \u00f6elda, et soovime luua hostPath t\u00fc\u00fcpi volume. See t\u00e4hendab, et viimased teeme raja hostist, kus me k\u00e4ivitume \u2014 ja v\u00f5tame selle volume'ina. Edasi nimetame selle name: host. Kogu hostPath monteerime podi sisse. K\u00e4esoleval juhul kausta \/host. <\/p>\n
    <\/p>\n
    Kordan veel kord. Me \u00fctlesime podile tulla masternodele, saada hostNetwork ja hostPID \u2014 ning monteerida kogu master root sellesse podi. <\/p>\n
    <\/p>\n
    Sa aru, et Debiani s\u00fcsteemis meil t\u00f6\u00f6tab bash ja see bash t\u00f6\u00f6tab meil rootina. See t\u00e4hendab, et saime just ruuti masterisse, omamata mingit \u00f5igust Kubernetes'e klastris.<\/p>\n
    <\/p>\n
    Edasi on kogu \u00fclesanne minna podisse kausta \/host \/etc\/kubernetes\/pki, kui ma ei eksi, ning v\u00f5tta sealt k\u00f5ik klastrimasteri sertifikaadid ja seega saada klastrihalduriks. <\/p>\n
    <\/p>\n
    Kui sellesse vaadata, siis need on \u00fcheks k\u00f5ige ohtlikumaks \u00f5iguseks podides \u2014 hoolimata sellest, millised \u00f5igused on kasutajal:
    \n\"T\u00e4idame<\/p>\n
    <\/p>\n
    Kui mul on \u00f5igused k\u00e4ivitada pod mingis klastrinamespace'is, siis on selle podi \u00f5igused vaikimisi olemas. Ma saan k\u00e4ivitada privileegitud pode, mis antud juhul on k\u00f5ik \u00f5igused, praktiliselt root nodi. <\/p>\n
    <\/p>\n
    Minu lemmik on Root user. Ja Kubernetesel on selline valik nagu Run As Non-Root. See on nagu kaitse h\u00e4kkerite eest. Kas te teate, mis on 'Moldova viirus'? Kui te olete \u00e4kki h\u00e4kker ja tulite minu Kubernetes'e klastrisse, siis me, vaesed administraatorid, palume: \"Palun m\u00e4\u00e4rake oma podides, millega te hakkate mu klastrit h\u00e4kkima, run as non-root. Vastasel juhul v\u00f5ib juhtuda, et k\u00e4ivitate protsessi oma podis rootina ja teil on v\u00e4ga lihtne mind h\u00e4kkida. Palun kaitske end ise.\" <\/p>\n
    <\/p>\n
    Host path volume \u2014 minu arvates on see k\u00f5ige kiirem viis saada soovitud tulemus Kubernetes'e klastrist. <\/p>\n
    <\/p>\n
    Aga mis nendega k\u00f5igega teha? <\/p>\n
    <\/p>\n
    M\u00f5tted, mis peaksid tulema iga normaalse administraatori juurde, kes seisab silmitsi Kubernetesega: \u201eAha, ma \u00fctlesin ju, et Kubernetes ei t\u00f6\u00f6ta. Seal on augud. Ja kogu Kubernetes on jama.\u201c Tegelikult on olemas selline asi nagu dokumentatsioon, ja kui sinna vaadata, siis seal on jaotis Pod Security Policy<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    See on selline yaml-objekt \u2014 me saame seda luua Kubernetes'e klastris \u2014 mis kontrollib turvaaspekte just podide kirjelduses. See t\u00e4hendab, et see kontrollib \u00f5igusi hostNetwork, hostPID ja teatud t\u00fc\u00fcpi volume'ite kasutamiseks, mis on podides k\u00e4ivitamisel. Pod Security Policy abil saab k\u00f5ik need aspektid kirjeldada. <\/p>\n
    <\/p>\n
    K\u00f5ige huvitavam Pod Security Policy juures on see, et Kubernetes'e klastri k\u00f5ik PSP-d ei ole mitte lihtsalt kuidagi m\u00e4\u00e4ratletud, vaid nad on vaikimisi v\u00e4lja l\u00fclitatud. Pod Security Policy aktiveeritakse admission plugin'i abil.<\/p>\n
    <\/p>\n
    Olgu, deployime klastrisse Pod Security Policy, \u00fctleme, et meil on teenuslikud podid mingis nimepaikuses, kuhu p\u00e4\u00e4sevad ligi ainult adminnid. \u00dctleme, et k\u00f5igil \u00fclej\u00e4\u00e4nud podidel on piiratud \u00f5igused. Sest t\u00f5en\u00e4oliselt ei vaja arendajad teie klastris privileege \u00e4ratavaid pode. <\/p>\n
    <\/p>\n
    Ja meil tundub, et k\u00f5ik on h\u00e4sti. Ja meie Kubernetes'e klastrit ei saa kahe minutiga h\u00e4kkida. <\/p>\n
    <\/p>\n
    Kuid on probleem. T\u00f5en\u00e4oliselt, kui teil on Kubernetes'e klaster, siis on teie klastris installitud j\u00e4lgimine. Ma isegi julgen ennustada, et kui teie klastris on j\u00e4lgimine, siis kutsutakse seda Prometheuseks. <\/p>\n
    <\/p>\n
    See, mida ma praegu r\u00e4\u00e4gin, kehtib nii Prometheus operaatori kui ka puhta Prometheuse kohta. K\u00fcsimus on selles, et kui ma ei saa nii kiiresti administraatorit klastrisse, siis t\u00e4hendab see, et pean rohkem otsima. Ja ma saan otsida oma j\u00e4lgimise abil.<\/p>\n
    <\/p>\n
    T\u00f5en\u00e4oliselt on k\u00f5ik lugenud samu artikleid Habr's ja j\u00e4lgimine on nimepaikuses monitoring. Helm chart k\u00f5igil on enam-v\u00e4hem sama nimega. Ma arvan, et kui teete helm install stable\/prometheus, siis \u00fctlete, et teil on umbes samad nimed. Ja isegi t\u00f5en\u00e4oliselt ei pea ma teie klastris DNS-nime \u00e4ra arvama. Sest see on standardne. <\/p>\n
    <\/p>\n
    \"T\u00e4idame<\/p>\n
    <\/p>\n
    Edasi on meil mingi dev ns, kus saab k\u00e4ivitada mingi 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 eksportijatest, mis kogub m\u00f5\u00f5dikud Kubernetes API-st. Seal on palju andmeid selle kohta, mis on teie klastris k\u00e4imas, milline see on ja millised probleemid teil sellega on. <\/p>\n
    <\/p>\n
    Lihtsa n\u00e4itena: <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\"kube-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
    Lihtsa curl p\u00e4ringu tegemine mitteprivilegeeritud podist v\u00f5imaldab saada sellist teavet. Kui te ei tea, millises Kubernetes versioonis te olete, siis see r\u00e4\u00e4gib teile kergesti. <\/p>\n
    <\/p>\n
    Ja k\u00f5ige huvitavam on see, et lisaks sellele, et te p\u00f6\u00f6rdute kube-state-metrics poole, v\u00f5ite sama h\u00e4sti p\u00f6\u00f6rduda ka otse Prometheuse poole. Te saate sealt m\u00f5\u00f5dikud koguda. Te isegi saate sealt m\u00f5\u00f5dikud genereerida. Teoreetiliselt saate koostada sellise p\u00e4ringu klastrist Prometheusse, mis lihtsalt v\u00e4ljal\u00fclitab selle. Ja teie j\u00e4lgimine l\u00f5petab klastrist \u00fcldse t\u00f6\u00f6tamise. <\/p>\n
    <\/p>\n
    Ja siin tekib k\u00fcsimus, kas m\u00f5ni v\u00e4line j\u00e4lgimine j\u00e4lgib teie j\u00e4lgimist. Just n\u00fc\u00fcd sain v\u00f5imaluse tegutseda Kubernetes klastris t\u00e4ielikult tagaj\u00e4rgedeta. Te isegi ei saa teada, et ma seal tegutsemisega olen, kuna j\u00e4lgimist lihtsalt ei ole. <\/p>\n
    <\/p>\n
    Just nagu PSP-ga, on tunne, et probleem on selles, et k\u00f5ik need moes tehnoloogiad \u2014 Kubernetes, Prometheus \u2014 nad lihtsalt ei t\u00f6\u00f6ta ja on t\u00e4is auke. Tegelikult ei ole. <\/p>\n
    <\/p>\n
    On olemas selline asi \u2014 Network Policy<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Kui te olete normaalne admin, siis t\u00f5en\u00e4oliselt teate, et Network Policy on j\u00e4rjekordne yaml, mida klastris on juba piisavalt. Ja Network Policies ei ole t\u00f5en\u00e4oliselt vajalikud. Ja isegi kui te lugesite, mis on Network Policy, et see on Kubernetes yaml-tuli, mis v\u00f5imaldab piirata juurdep\u00e4\u00e4su \u00f5iguslikke suhteid nimede vahel, podide vahel, siis te olete kindlasti otsustanud, et yaml-formaadis tuli Kuberneteses j\u00e4rgmistes abstraktsioonides... Ei-ei. See ei ole kindlasti vajalik. <\/p>\n
    <\/p>\n
    Isegi kui teie turbespetsialistid ei tea, et teie Kuberneteses on v\u00e4ga lihtne ja kerge ehitada tulem\u00fc\u00fcri, veelgi detailsemalt. Kui nad seda veel ei tea ja ei torma k\u00fcsima: \"No andke, andke...\" Siiski on Network Policy teil vajalik, et piirata juurdep\u00e4\u00e4su teatud teenuskohtadele, millesse v\u00f5ib teie klastri kaudu ligip\u00e4\u00e4su saada, ilma igasuguse autoriseerimiseta. <\/p>\n
    <\/p>\n
    Nagu n\u00e4idatud n\u00e4ites, on v\u00f5imalik kube state metrics'i kasutada igast nimiruumist Kuberneteses, ilma et selleks \u00f5iguseid oleks. Network policies on piiranud juurdep\u00e4\u00e4su k\u00f5igist teistest nimiruumidest j\u00e4lgimise nimiruumi, ja nagu ka k\u00f5ik: ei ole juurdep\u00e4\u00e4su, ei ole probleemi. K\u00f5ikides olemasolevates chartides, nii standartse Prometheuse kui ka selle Prometheuse puhul, mis on operaatoris, on lihtsalt values failis olemas valik, et aktiveerida network policies nende jaoks. Lihtsalt tuleb aktiveerida ja need hakkavad t\u00f6\u00f6le. <\/p>\n
    <\/p>\n
    T\u00f5si, siin on \u00fcks probleem. Normaalsena tavatavate adminnina on t\u00f5en\u00e4oliselt otsustanud, et network policies ei ole vajalikud. Ja lugedes igasuguseid artikleid ressurssidelt nagu Habr, otsustasite, et flannel, eriti host-gateway re\u017eiimis, on parim valik, mida saate teha. <\/p>\n
    <\/p>\n
    Mida teha? <\/p>\n
    <\/p>\n
    V\u00f5ite proovida taastada oma Kuberneteses oleva v\u00f5rgu lahenduse, proovida asendada seda millegi funktsionaalsemaga. N\u00e4iteks Calicoga. Kuid \u00f6elda tuleb, et v\u00f5rgu lahenduse vahetamine t\u00f6\u00f6tavas Kuberneteses ei ole just triviaalne \u00fclesanne. Olen selle kaks korda lahendanud (m\u00f5lemad korrad k\u00fcll teoreetiliselt), aga meil oli isegi Slurmides n\u00e4idatud, kuidas seda teha. Meie koolitatavatele n\u00e4itasime, kuidas vahetada v\u00f5rgu lahendust Kuberneteses. P\u00f5him\u00f5tteliselt v\u00f5ite proovida teha nii, et tootmisklastris ei esineks seisakut. Kuid t\u00f5en\u00e4oliselt ei \u00f5nnestu teil midagi. <\/p>\n
    <\/p>\n
    Probleemi lahendamine on tegelikult v\u00e4ga lihtne. Klaster sisaldab sertifikaate, ja te teate, et teie sertifikaadid l\u00e4hevad aasta p\u00e4rast kehtetuks. Noh, ja tavaliselt on klastris normaalne lahendus sertifikaatide puhul \u2014 miks peaksime vaeva n\u00e4gema, t\u00f5stame k\u00f5rvale uue klastri, vanas laseme sellel minna, ja k\u00f5ik taask\u00e4ivitame. T\u00f5si, kui see aegub, seisab meil p\u00e4ev aega, kuid selle v\u00f5rra uue klastriga. <\/p>\n
    <\/p>\n
    Uut klastri t\u00f5stes, asetage samal ajal Calico flanneli asemel. <\/p>\n
    <\/p>\n
    Mida teha, kui teil on sertifikaadid, mis on v\u00e4lja antud sajaks aastaks ja te ei plaani klastrit \u00fcle deponeerida? On olemas selline asi nagu Kube-RBAC-Proxy. See on t\u00f5eliselt \u00e4ge arendamine, mis v\u00f5imaldab end sisestada sidecar konteinerina \u00fcksk\u00f5ik millisesse pod'i Kubernetes klastris. Ja see annab tegelikult sellele pod'ile autoriseerimise l\u00e4bi Kubernetes'i RBAC-i. <\/p>\n
    <\/p>\n
    \u00dcks probleem on. Varem oli Prometheuse operaatoris see Kube-RBAC-Proxy lahendus sisse ehitatud. Kuid seda pole enam. T\u00e4nap\u00e4evaste versioonide puhul l\u00e4htutakse sellest, et teil on olemas v\u00f5rgu poliitika ja te sulgete nende abil. Seet\u00f5ttu tuleb natuke graafikut \u00fcmber kirjutada. Tegelikult, kui te k\u00fclastate seda repot<\/a><\/noindex>, seal on n\u00e4ited, kuidas seda kasutada sidecar'ideena, ja graafikut tuleb minimaalselt \u00fcmber kirjutada. <\/p>\n
    <\/p>\n
    On veel \u00fcks v\u00e4ike probleem. Mitte ainult Prometheus ei anna oma m\u00f5\u00f5tmeid kellelegi. K\u00f5ik Kubernetes klastri komponendid oskavad ka oma m\u00f5\u00f5tmeid anda. <\/p>\n
    <\/p>\n
    Aga nagu ma juba \u00fctlesin, kui te ei saa klastrile ligi ja teavet koguda, siis saate v\u00e4hemalt kahjulik olla. <\/p>\n
    <\/p>\n
    Seega n\u00e4itan kiiresti kahte viisi, kuidas Kubernetes klastrit kahjustada. <\/p>\n
    <\/p>\n
    Te naerate, kui ma seda r\u00e4\u00e4gin, need on kaks juhtumit reaalsest elust. <\/p>\n
    <\/p>\n
    Esimene meetod. Ressursside kurnamine. <\/p>\n
    <\/p>\n
    K\u00e4ivitame veel \u00fche spetsiaalse pod'i. Sellel on selline sektsioon. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Kuidas te teate, requests \u2014 see on see CPU ja m\u00e4lu maht, mis hostis reserveeritakse konkreetsete pod'ide jaoks koos requests'iga. Kui meil on neli tuuma host Kubernetes klastris ja sinna tuleb pod, mille requests on neli CPU, siis ei saa sellele hostile enam \u00fchtegi muud pod'i koos requests'iga tulla. <\/p>\n
    <\/p>\n
    Kui ma k\u00e4itan sellise pod'i, siis annan k\u00e4su: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Siis ei saa keegi enam Kubernetes klastrisse deponeerida. Sest k\u00f5igil s\u00f5lmedel l\u00f5ppevad requests. Ja seel\u00e4bi peatan teie Kubernetes klastrit. Kui ma seda \u00f5htul teen, siis v\u00f5ivad depood \u00fcsna pikaks ajaks peatuda. <\/p>\n
    <\/p>\n
    Kui vaatame veel kord Kubernetes'e dokumentatsiooni, siis n\u00e4eme m\u00f5istet, mida kutsutakse Limit Range'iks. See m\u00e4\u00e4ratleb ressursid klastrielementidele. Sa saad kirjutada yaml objekti Limit Range, rakendada selle kindlatesse nimiruumi ja seej\u00e4rel selle nimiruumi \u00f6elda, et sul on pod'de jaoks vaikimisi, maksimaalsed ja minimaalsed ressursid.<\/p>\n
    <\/p>\n
    Selle abil saame piirata kasutajaid konkreetses tootenimiruumi meeskondade v\u00f5imalustes m\u00e4\u00e4rata oma pod'idesse igasuguseid jama. Kuid kahjuks, isegi kui sa \u00fctled kasutajale, et ei tohi k\u00e4ivitada pod'e, mille n\u00f5uded \u00fcletavad \u00fchte CPU-d, on olemas selline imeline k\u00e4sk scale, v\u00f5i nad v\u00f5ivad seda teha ka dashboardi kaudu.<\/p>\n
    <\/p>\n
    Ja sealt tulebki number kaks. K\u00e4ivitame 11 111 111 111 111 pod'i. See on \u00fcksteist miljardit. See ei ole sellep\u00e4rast, et ma sellist numbrit v\u00e4lja m\u00f5tlesin, vaid seet\u00f5ttu, et ma olen seda ise n\u00e4inud. <\/p>\n
    <\/p>\n
    T\u00f5eline lugu. Hilisel \u00f5htul olin juba lahkumiseks valmis. Vaatan, et nurga taga istub grupp arendajaid ja tegeleb millegagi arvutitega. L\u00e4hene ja k\u00fcsin: \u201eMis teil juhtus?\u201d<\/p>\n
    <\/p>\n
    Veidi varem, umbes kell \u00fcheksa \u00f5htul, olid \u00fche arendaja plaanid koju minna. Ta m\u00f5tles: \u201eMa skaleerin oma rakendust \u00fchekohaliseks.\u201d Vajutas \u00fchekohale, kuid internet veidi viibis. Ta vajutas veel kord \u00fchekohale, ta surus \u00fchekohale, kl\u00f5psas Enter'ile. Ta proovis k\u00f5ike, mis tal v\u00f5imalik oli. Siis internet \u00e4rkas ellu \u2014 ja k\u00f5ik hakkas skaleeruma sellele numbrile. <\/p>\n
    <\/p>\n
    T\u00f5si, see lugu ei toimunud Kubernetes'es, tookord oli see Nomad. See l\u00f5ppes sellega, et p\u00e4rast tunni jagu katseid Nomad'it peatada, teatas Nomad, et ta ei lakka skaleerumast ja ei hakkagi millegagi muuga tegelema. \u201eMa olen v\u00e4sinud, ma lahkun.\u201d Ja sulges ennast. <\/p>\n
    <\/p>\n
    J\u00f5udsin loomulikult proovida sama teha ka Kubernetes'es. \u00dcksteist miljardit pod'i Kubernetes mind r\u00f5\u00f5mustanud, ta \u00fctles: \u201eEi saa. \u00dcletab sise limite.\u201d Kuid 1 000 000 000 pod'i suutis. <\/p>\n
    <\/p>\n
    Vastupidiselt ei piirdunud \u00fcks miljard Pod'i endasse. Ta t\u00f5epoolest hakkas skaleeruma. Mida edasi protsess liikuda j\u00f5udis, seda rohkem aega l\u00e4ks uute podide loomisele. Kuid protsess j\u00e4tkus. Ainuke probleem on see, et kui ma saan oma nimiruumis piiramatult pod'e k\u00e4ivitada, siis isegi ilma n\u00f5udmiste ja piiranguteta saan ma k\u00e4ivitada nii palju pod'e, et nende \u00fclesannetega hakkavad noodid m\u00e4lus ja CPU-s kokku langema. Kui ma k\u00e4ivitan nii palju pod'e, peab teave nendest j\u00f5udma salvestusse, nimelt etcd. Ja kui sinna j\u00f5uab liiga palju teavet, hakkab salvestus liiga aeglaselt andmeid v\u00e4ljastama \u2014 ja Kubernetesel algavad probleemid. <\/p>\n
    <\/p>\n
    Ja veel \u00fcks probleem... Nagu te teate, Kubernetes'e juhtimisseadmed ei ole lihtsalt \u00fcks keskmine element, vaid mitu kompoonent. Seal on eriti kontrollija, ajakava jne. K\u00f5ik need t\u00fc\u00fcbid hakkavad samal ajal t\u00e4itma tarbetut t\u00fchist t\u00f6\u00f6d, mis aja jooksul hakkab n\u00f5udma \u00fcha rohkem aega. Kontrollija hakkab uusi pod'e looma. Ajakava p\u00fc\u00fcab neile leida uut nooti. Uued noodid teie klastris on t\u00f5en\u00e4oliselt varsti otsakorral. Kubernetes alustab \u00fcha aeglasemat t\u00f6\u00f6d.<\/p>\n
    <\/p>\n
    Kuid ma otsustasin minna veelgi kaugemale. Nagu te teate, on Kubernetes'es \u00fcks element, mida nimetatakse teenuseks. Noh, ja t\u00f5en\u00e4oliselt t\u00f6\u00f6tavad teie klastrites teenused IPTables'i abil. <\/p>\n
    <\/p>\n
    Kui me n\u00e4iteks k\u00e4ivitame \u00fche miljardi pod'i ja siis skripti abil sundida Kubernetes'e looma uusi teenuseid: <\/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\u00f5igil noodidel genereeritakse ligikaudu samal ajal j\u00e4rjest uusi ja uusi IPTables'i reegleid. Iga teenuse puhul genereeritakse umbes miljard IPTables'i reeglit. <\/p>\n
    <\/p>\n
    Ma kontrollisin k\u00f5iki neid asju paaritel tuhandetel, kuni k\u00fcmme. Ja probleem on see, et juba sellel l\u00e4vel on sissetoomine SSH nooti \u00fcsna problemaatiline. Kuna paketid, l\u00e4bides sellist arvu ahelaid, hakkavad end mitte v\u00e4ga h\u00e4sti tundma. <\/p>\n
    <\/p>\n
    Jah, see k\u00f5ik lahendatakse Kubernetes'e abil. Seal on selline objekt nagu Resource quota. See m\u00e4\u00e4rab inimruumile ligip\u00e4\u00e4setavate ressursside ja objektide arvu klastri piires. Me saame luua YAML objekti igas Kubernetes'i nimiruumis. Selle objekti abil saame \u00f6elda, et antud nimiruumile on eraldatud kindel arv n\u00f5udmisi, limiite, ja edasi saame \u00f6elda, et selles nimiruumis on v\u00f5imalik luua 10 teenust ja 10 konteinerit. Ja arendaja v\u00f5ib igal \u00f5htul muretult puhkama minna. Kubernetes \u00fctleb talle: \u201eEi, sa ei saa oma konteinereid sellisesse arvu skaleerida, kuna see \u00fcletab ressursikvooti.\u201c K\u00f5ik, probleem on lahendatud. Dokumentatsioon siin<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    \u00dcks probleemne hetk sellega seoses tekib. Tunnete, kui keeruliseks muutub Kubernetes'es nimiruumide loomine. Selleks, et seda luua, peame arvestama paljude asjadega.<\/p>\n
    <\/p>\n
    Resource quota + Limit Range + RBAC
    \n\u2022 Loome nimiruum
    \n\u2022 Loome sees limitrange
    \n\u2022 Loome sees resourcequota
    \n\u2022 Loome serviceaccount'i CI jaoks
    \n\u2022 Loome rolebinding'i CI ja kasutajate jaoks
    \n\u2022 Valikuliselt k\u00e4ivitame vajalikud teeninduskonteinerid <\/p>\n
    <\/p>\n
    Seet\u00f5ttu tahan ma kasutada juhust ja jagada oma arengutegevusi. On olemas selline asi nagu operaatori SDK. See on viis kirjutada Kubernetes'e klastri jaoks operaatorite loomise v\u00f5imalusi. Te saate kirjutada operaatorite abil Ansible'iga.<\/p>\n
    <\/p>\n
    Esialgu oli meil kirjutatud Ansible peale, kuid hiljem vaatasin, et on olemas operaatori SDK ja t\u00f5lgendasin Ansible'i rolli operaatoriks. See operaator v\u00f5imaldab meil luua Kubernetes'e klastri objekti, mida nimetatakse k\u00e4suks. K\u00e4su sees v\u00f5imaldab see YAML formaadis keskkonda selle k\u00e4su jaoks kirjeldada. Ja k\u00e4su keskkonnas v\u00f5imaldab see kirjeldada, kui palju ressursse me eraldame. <\/p>\n
    <\/p>\n
    V\u00e4ike lihtsustaja kogu selle keerulise protsessi jaoks<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Ja l\u00f5petuseks. Mida k\u00f5igega selle kohta teha?
    \nEsiteks. Pod Security Policy \u2013 see on hea. Ja kuigi \u00fckski Kubernetes'i installija ei kasuta neid siiani, on siiski teie klastrites neid vaja kasutada. <\/p>\n
    <\/p>\n
    Network Policy \u2013 see ei ole lihtsalt veel \u00fcks tarbetu funktsioon. See on midagi, mis on klastri jaoks t\u00f5eliselt vajalik. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota \u2013 aeg on hakata kasutama. Me oleme juba seda kasutanud ja olin pikka aega kindel, et k\u00f5ik rakendavad seda. Olin eksinud, see on haruldane. <\/p>\n
    <\/p>\n
    Lisaks sellele, millest ma oma ettekandes r\u00e4\u00e4kisin, on olemas dokumenteerimata funktsioonid, mis v\u00f5imaldavad r\u00fcnnata klastrit. Hiljuti ilmus suur anal\u00fc\u00fcs Kubernetes'e haavatavustest<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    M\u00f5ned asjad on nii kurvad ja solvad. N\u00e4iteks teatavatel tingimustel v\u00f5ivad klastris oleva kubelet'id anda warlocks kausta sisu, ja seda autoriseerimata kasutajale. <\/p>\n
    <\/p>\n
    Siin<\/a><\/noindex> seal on juhised, kuidas k\u00f5ik, millest ma r\u00e4\u00e4kisin, taastada. Seal on failid toodangun\u00e4idistega, kuidas ResourceQuota ja Pod Security Policy v\u00e4lja n\u00e4evad. Ja k\u00f5ike seda saab Katsuda. <\/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\udd47Kubernetes'e klastrite augud. Ettekanne ja \u00fclevaate tekst DevOpsConf-ist | ProHoster","description":"Pavel Selivanov, Southbridge'i lahenduste arhitekt ja Slyrma \u00f5petaja, esines ettekandega DevOpsConf 2019.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}