{"id":97982,"date":"2020-10-23T14:42:15","date_gmt":"2020-10-23T12:42:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes"},"modified":"2020-11-18T00:58:47","modified_gmt":"2020-11-17T22:58:47","slug":"devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes","title":{"rendered":"\u00dcheksa n\u00e4pun\u00e4idet Kubernetes'i t\u00f5hususe parandamiseks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00e4pun\u00e4idet Kubernetes&#039;i t\u00f5hususe parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/92dc510aa9d785a31d310816b18bf854.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Tere k\u00f5igile! Minu nimi on Oleg Sidorov, t\u00f6\u00f6tan ettev\u00f5ttes DomClick infrastruktuurimeeskonna juhina. Oleme kasutanud \"Kubi\" tootmisversioonis juba rohkem kui kolm aastat ning selle aja jooksul oleme kogenud palju erinevaid huvitavaid hetki. T\u00e4na r\u00e4\u00e4gin teile, kuidas \u00f5ige l\u00e4henemisega saate \"puhtast\" Kubernetesest veel rohkem v\u00f5imsust v\u00e4lja v\u00f5tta oma klastri jaoks. Valmis, start, mine! <\/p>\n<p>Te k\u00f5ik teate, et Kubernetes on avatud koodiga, skaleeritav s\u00fcsteem konteinerite orkestreerimiseks; v\u00f5i noh, 5 binaarfaili, mis teevad imet, hallates teie mikroteenuste eluts\u00fcklit serverikeskkonnas. Lisaks on see \u00fcsna paindlik t\u00f6\u00f6riist, mida saab nagu Lego klotse kokku panna, et maksimaalselt kohandada erinevate \u00fclesannete jaoks.<\/p>\n<p>Ja tundub, et k\u00f5ik on h\u00e4sti: viska serverid klastri nagu palk tule, ja muret ei tunne. Kuid kui sa hoolid keskkonnast, siis m\u00f5tled: \u201eKuidas ma saan tuld ahjus hoida, kuid metsast s\u00e4\u00e4sta?\u201c. Teisis\u00f5nu, kuidas leida v\u00f5imalusi infrastruktuuri t\u00e4iustamiseks ja kulude v\u00e4hendamiseks.<\/p>\n<h2>1. J\u00e4lgige meeskondade ja rakenduste ressursikasutust<\/h2>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00e4pun\u00e4idet Kubernetes&#039;i t\u00f5hususe parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/91e2e60b47ee985b024532c8b685230c.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>\u00dcks k\u00f5ige tavalisemaid, kuid t\u00f5husaid meetodeid on piirangute ja n\u00f5udmiste seadmine. Jagage rakendusi nimev\u00e4ljade kaupa ning nimev\u00e4ljad arendusmeeskondade kaupa. M\u00e4\u00e4rake rakendusele enne juurutamist protsessori aja, m\u00e4lu ja ajutise salvestusruumi tarbimise v\u00e4\u00e4rtused.<\/p>\n<pre><code>resources:\n   requests:\n     memory: 2Gi\n     cpu: 250m\n   limits:\n     memory: 4Gi\n     cpu: 500m<\/code><\/pre>\n<p>Kogemusest oleme j\u00f5udnud j\u00e4reldusele, et n\u00f5udmised ei tohiks olla suuremad kui piirangud rohkem kui kaks korda. Klaster arvutatakse n\u00f5udmiste p\u00f5hjal, ja kui te m\u00e4\u00e4rate rakendustele ressursside erinevuse n\u00e4iteks 5-10 korda, siis kujutage ette, mis juhtub teie solgiga, kui see t\u00e4itub podidega ja \u00e4kitselt koormus suureneb. Midagi head ei juhtu. K\u00f5ige v\u00e4hem p\u00f5hjustab see trottlingut ja k\u00f5ige rohkem h\u00fcvasti peate te t\u00f6\u00f6tajaga ning saad pideva koormuse teistele solgidele, kui podid hakkavad liikuma.<\/p>\n<p>Lisaks saate <code>limitranges<\/code> Te v\u00f5ite konteinerile alguses m\u00e4\u00e4rata ressursside v\u00e4\u00e4rtused \u2013 minimaalsed, maksimaalsed ja vaikimisi:<\/p>\n<pre><code>\u279c  ~ kubectl describe limitranges --namespace ops\nName:       limit-range\nNamespace:  ops\nType        Resource           Min   Max   Default Request  Default Limit  Max Limit\/Request Ratio\n----        --------           ---   ---   ---------------  -------------  -----------------------\nContainer   cpu                50m   10    100m             100m           2\nContainer   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -\nContainer   memory             64Mi  40Gi  128Mi            128Mi          2<\/code><\/pre>\n<p>\u00c4ra unusta piirata nimeliku ruumi ressursse, et \u00fcks meeskond ei saaks kogu klastrite ressursse endale haarata:<\/p>\n<pre><code>\u279c  ~ kubectl describe resourcequotas --namespace ops\nName:                   resource-quota\nNamespace:              ops\nResource                Used          Hard\n--------                ----          ----\nlimits.cpu              77250m        80\nlimits.memory           124814367488  150Gi\npods                    31            45\nrequests.cpu            53850m        80\nrequests.memory         75613234944   150Gi\nservices                26            50\nservices.loadbalancers  0             0\nservices.nodeports      0             0<\/code><\/pre>\n<p>Nagu n\u00e4ha on kirjelduse j\u00e4rgi <code>resourcequotas<\/code>, kui ops meeskond soovib juurutada pod'e, mis tarbiks veel 10 cpu, siis planeerija ei lase seda teha ja annab vea:<\/p>\n<pre><code>Error creating: pods \"nginx-proxy-9967d8d78-nh4fs\" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10<\/code><\/pre>\n<p>Sarnase probleemi lahendamiseks saab kirjutada t\u00f6\u00f6riista, n\u00e4iteks nagu <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/pauljamm\/team-operator\">seda<\/a><\/noindex>, mis oskab salvestada ja fikseerida meeskondade ressursside olekuid.<\/p>\n<h2>2. Valige optimaalsed failide salvestamiseks<\/h2>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00e4pun\u00e4idet Kubernetes&#039;i t\u00f5hususe parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/c7f8bdbf5490acc9061695a6d608015e.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Siin tahaksin k\u00e4sitleda p\u00fcsivate mahtude ja Kubernetes'e worker-node'i ketas\u00fcsteemi teemat. Loodan, et keegi ei kasuta \u201eKubi\u201d HDD-l tootmises, kuid m\u00f5nikord ei piisa ka tavalise SSD kohta. Oleme sellise probleemiga silmitsi seisnud, et logid h\u00e4vitavad ketast sisse- ja v\u00e4ljundoperatsioonide t\u00f5ttu, ja lahendusi ei ole just palju: <\/p>\n<ul>\n<li>\n<p>Kasutage k\u00f5rgv\u00f5imekat SSD-d v\u00f5i viige \u00fcle NVMe-le (kui teil on oma riistvara k\u00e4sutuses).<\/p>\n<\/li>\n<li>\n<p>V\u00e4hendage logimise taset.<\/p>\n<\/li>\n<li>\n<p>Tehke \u201enutikas\u201d podide tasakaalustamine, mis koormavad ketast (<code>podAntiAffinity<\/code>).<\/p>\n<\/li>\n<\/ul>\n<p>\u00dclalloolev ekraan n\u00e4itab, mis juhtub nginx-ingress-controlleriga, kui ketas on logimise access_logs kostus (~12 tuhat logi\/s). See seisund v\u00f5ib muidugi p\u00f5hjustada k\u00f5igi rakenduste halvenemist selle node'i peal.<\/p>\n<p>Mis puutub PV-de, siis kahjuks ei ole ma k\u00f5iki <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/persistent-volumes\/#types-of-persistent-volumes\">liike proovinud<\/a><\/noindex> P\u00fcsivad mahud. Kasutage parimat varianti, mis sobib just teile. Meil on ajalooliselt nii kujunenud, et v\u00e4ike osa teenustest vajab RWX-mahuteid, ja juba ammu on selle \u00fclesande t\u00e4itmiseks kasutatud NFS-lao. Odav ja\u2026 piisab. Loomulikult oleme me sellega piisavalt kokku puutunud \u2014 ole terve, kuid oleme \u00f5ppinud seda timmima, ja peavalu on kadunud. Ja kui v\u00f5imalik, minge \u00fcle objektihoidla S3-le.<\/p>\n<h2>3. Koguge optimeeritud pilte<\/h2>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00e4pun\u00e4idet Kubernetes&#039;i t\u00f5hususe parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/c25ce405d1eb4c01f031e18b0bfa4836.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Parim on kasutada konteinerite jaoks optimeeritud pilte, et Kubernetes saaks neid kiiremini k\u00e4tte ja t\u00f5husamalt t\u00e4ita.&nbsp;<\/p>\n<p>Optimeeritus t\u00e4hendab, et pildid:<\/p>\n<ul>\n<li>\n<p>sisaldavad ainult \u00fchte rakendust v\u00f5i t\u00e4idavad ainult \u00fchte funktsiooni;<\/p>\n<\/li>\n<li>\n<p>on v\u00e4ikesed, sest suured pildid edastatakse halvemini v\u00f5rgus;<\/p>\n<\/li>\n<li>\n<p>on l\u00f5pp-punktid t\u00f6\u00f6kindluse ja valmiduse kontrollimiseks, millega Kubernetes saab ettev\u00f5tta mingit tegevust seisakute korral;<\/p>\n<\/li>\n<li>\n<p>kasutavad konteinerite s\u00f5bralikke operatsioonis\u00fcsteeme (nagu Alpine v\u00f5i CoreOS), mis on konfiguratsioonivigade suhtes vastupidavamad;<\/p>\n<\/li>\n<li>\n<p>kasutavad mitmeastmelisi kogumise meetodeid, et saaksite juurutada ainult kompileeritud rakendusi, mitte kaasnevaid l\u00e4htekode.<\/p>\n<\/li>\n<\/ul>\n<p>On palju t\u00f6\u00f6riistu ja teenuseid, mis v\u00f5imaldavad reaalajas pilte kontrollida ja optimeerida. Oluline on hoida need alati ajakohased ja turvaliseks kontrollitud. Selle tulemuseks on: <\/p>\n<ol>\n<li>\n<p>V\u00f5rgu koormuse v\u00e4henemine kogu klastrile.<\/p>\n<\/li>\n<li>\n<p>Konteineri k\u00e4ivitamise aja v\u00e4henemine.<\/p>\n<\/li>\n<li>\n<p>Teie kogu Docker registry v\u00e4iksem maht.<\/p>\n<\/li>\n<\/ol>\n<h2>4. Kasutage DNS-i vahem\u00e4lu<\/h2>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00e4pun\u00e4idet Kubernetes&#039;i t\u00f5hususe parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/9f4384462a77dc528d7911c56f684f2d.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Kui r\u00e4\u00e4kida k\u00f5rgetest koormustest, siis ilma klastris DNS-s\u00fcsteemi h\u00e4\u00e4lestamiseta on elu \u00fcsna kehv. Aegade alguses toetas Kubernetes oma lahendust kube-dns. See viidi ellu ka meie s\u00fcsteemis, kuid seda tarkvara ei h\u00e4\u00e4lestatud eriti ja see ei n\u00e4idanud vajalikke j\u00f5udluse tulemusi, kuigi \u00fclesanne n\u00e4ib olema lihtne. Siis tuli coredns, millele me \u00fclemineku tegime ja ei kahetsenud, kuna see sai hiljem K8s-is vaikimisi DNS-teenuseks. \u00dchel hetkel j\u00f5udsime 40 000 rps DNS-s\u00fcsteemile, ja sellest lahendusest hakkas samuti puudust tundma. Kuid \u00f5nneliku juhuse t\u00f5ttu ilmus Nodelocaldns, tuntud ka kui node local cache, samuti. <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/tasks\/administer-cluster\/nodelocaldns\/\">NodeLocal DNSCache<\/a><\/noindex>.<\/p>\n<p>Miks me seda kasutame? Linuxi tuumas on bug, mis mitme\u00fchenduse korral l\u00e4bi conntrack NAT UDP kaudu p\u00f5hjustab olekute konkurentsi kirjutamisel conntrack-tabelitesse, ja osa liiklusest NAT-i kaudu kaob (igal teenuse k\u00f5nelusel \u2013 see on NAT). Nodelocaldns lahendab selle probleemi, v\u00e4listades NAT-i ja v\u00e4rskendades \u00fchendust TCP-ga upstream DNS-iga, samuti kohaliku DNS-p\u00e4ringute vahem\u00e4llu salvestamise upstream-idele (sealhulgas l\u00fchike 5-sekundiline negatiivne vahem\u00e4lu).<\/p>\n<h2>5. Skaalige podid automaatselt horisontaalselt ja vertikaalselt<\/h2>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00e4pun\u00e4idet Kubernetes&#039;i t\u00f5hususe parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/3804a14685a55160fa7d9f3226eab1fa.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Kas saate kindlalt \u00f6elda, et k\u00f5ik teie mikroteenused on valmis kahekordseks v\u00f5i kolmekordseks koormuse kasvuks? Kuidas jagada ressursse oma rakendustele \u00f5igesti? Paari podi k\u00e4itamine t\u00f6\u00f6tamise koormusest \u00fcle v\u00f5ib osutuda liialdatuks, samas riskite, et \u00e4kilise liikluse kasvu korral teenusel tekib seisak. Kulda keskteed aitab saavutada sellised teenused nagu <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/tasks\/run-application\/horizontal-pod-autoscale\/\">Horisontaalne Pod Autoscaler<\/a><\/noindex> ja <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/autoscaler\/tree\/master\/vertical-pod-autoscaler\">Vertikaalne Pod Autoscaler<\/a><\/noindex>. <\/p>\n<p><strong>VPA<\/strong> v\u00f5imaldab automaatselt t\u00f5sta oma konteinerite requests\/limits podis, s\u00f5ltuvalt tegelikust kasutusest. Kuidas see kasulik on? Kui teil on podid, mida mingil p\u00f5hjusel ei saa horisontaalselt skaleerida (mis pole tavaliselt usaldusv\u00e4\u00e4rne), siis v\u00f5ite proovida usaldada VPA, et muuta selle ressursse. Selle funktsioon seisneb soovituste s\u00fcsteemis, mis p\u00f5hineb ajaloolistel ja praegustel andmetel metric-serverist, seega kui te ei soovi automaatselt muuta requests\/limits, saate lihtsalt j\u00e4lgida soovitatud ressursse oma konteineritele ja optimeerida seadeid, et s\u00e4\u00e4sta CPU-d ja m\u00e4lu klastris. <\/p>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00e4pun\u00e4idet Kubernetes&#039;i t\u00f5hususe parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/3965950aa3315faa4bb3e3ff5bd61955.png\" style=\"display:block;margin: 0 auto;\" \/>Pilt on v\u00f5etud aadressilt https:\/\/levelup.gitconnected.com\/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231<\/p>\n<p>Kubernetesi planeerija p\u00f5hineb alati requests'idel. \u00dcksk\u00f5ik, millise v\u00e4\u00e4rtuse sinna m\u00e4\u00e4rate, otsib planeerija sobivat s\u00f5lme l\u00e4htuvalt sellest. Limits v\u00e4\u00e4rtused on kubeletile vajalikud, et m\u00f5ista, millal pod'i piirata v\u00f5i l\u00f5petada. Ja kuna ainus oluline parameeter on requests v\u00e4\u00e4rtus, t\u00f6\u00f6tab VPA selle alusel. Iga kord, kui m\u00e4\u00e4rate rakenduse vertikaalses skaleerimises, m\u00e4\u00e4rate, millised peaksid olema requests. Aga mis juhtub siis limits'itega? See parameeter skaleeritakse ka proportsionaalselt.<\/p>\n<p>N\u00e4iteks siin on tavalised pod'i seadistused:<\/p>\n<pre><code>resources:\n   requests:\n     memory: 250Mi\n     cpu: 200m\n   limits:\n     memory: 500Mi\n     cpu: 350m<\/code><\/pre>\n<p>Soovituste mehhanism m\u00e4\u00e4rab, et teie rakendusele on normatiivseks t\u00f6\u00f6tamiseks vajalik 300m CPU ja 500Mi. Saate sellised seadistused:<\/p>\n<pre><code>resources:\n   requests:\n     memory: 500Mi\n     cpu: 300m\n   limits:\n     memory: 1000Mi\n     cpu: 525m<\/code><\/pre>\n<p>Nagu eelnevalt mainitud, toimub see proportsionaalne skaleerimine requests\/limits suhetes manifestis:<\/p>\n<ul>\n<li>\n<p>CPU: 200m \u2192 300m: suhe 1:1.75;<\/p>\n<\/li>\n<li>\n<p>M\u00e4lu: 250Mi \u2192 500Mi: suhe 1:2.<\/p>\n<\/li>\n<\/ul>\n<p>As for <strong>HPA<\/strong>, siis on siin t\u00f6\u00f6mehhanism selgem. K\u00fcnnise v\u00e4\u00e4rtused seadistatakse n\u00e4iteks protsessori ja m\u00e4lu kohta, ja kui k\u00f5igi replikate keskmine v\u00e4\u00e4rtus \u00fcletab k\u00fcnnise, siis rakendus skaleeritakse +1 pod v\u00e4hemalt seni, kuni v\u00e4\u00e4rtus langeb alla k\u00fcnnise v\u00f5i kuni maksimaalne replikate arv on saavutatud.<\/p>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00e4pun\u00e4idet Kubernetes&#039;i t\u00f5hususe parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/f7a3fa28177d66be925867e38f5bbed6.png\" style=\"display:block;margin: 0 auto;\" \/>Pilt on v\u00f5etud aadressilt https:\/\/levelup.gitconnected.com\/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231<\/p>\n<p>Lisaks tavap\u00e4rastele m\u00f5\u00f5dikutel, nagu protsessor ja m\u00e4lu, saate seadistada k\u00fcnnised oma kohandatud m\u00f5\u00f5dikutel Prometheuses ja t\u00f6\u00f6tada nendega, kui peate neid k\u00f5ige t\u00e4psemaks m\u00e4\u00e4ratluseks, millal rakendust skaleerida. Kui rakendus stabiliseerub allpool m\u00e4\u00e4ratud m\u00f5\u00f5tmispiiri, alustab HPA podide skaleerimist allapoole kuni minimaalsete replikate arvuni v\u00f5i kuni koormus vastab m\u00e4\u00e4ratud k\u00fcnnisele.<\/p>\n<h2>6. \u00c4rge unustage Node Affinity ja Pod Affinity<\/h2>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00e4pun\u00e4idet Kubernetes&#039;i t\u00f5hususe parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/e718191d9e8ff25fd3b2d65cba9b3b73.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>K\u00f5ik s\u00f5lmed ei t\u00f6\u00f6ta sama riistvara peal, k\u00f5igile podidele ei pea olema vajalikud intensiivsete arvutusvajadusega rakenduste t\u00e4itmine. Kubernetes v\u00f5imaldab m\u00e4\u00e4rata s\u00f5lmede ja podide spetsialiseerumist kasutades <strong>Node Affinity<\/strong> ja <strong>Pod Affinity<\/strong>.<\/p>\n<p>Kui teil on noodid, mis sobivad intensiivseteks arvutusteks, on parima efektiivsuse saavutamiseks parem rakendused vastavatele nootidele siduda. Selleks kasutage <code>nodeSelector<\/code> s\u00f5lmeliimiga.<\/p>\n<p>Oletame, et teil on kaks nooti: \u00fcks on varustatud <code>CPUType=HIGHFREQ<\/code> ja suure hulga kiirete tuumadega, teine aga on <code>MemoryType=HIGHMEMORY<\/code> suure hulga m\u00e4lu ja paremaga t\u00e4itmisv\u00f5imega. K\u00f5ige lihtsam on m\u00e4\u00e4rata podi juurutamine noodele <code>HIGHFREQ<\/code>, lisades sektsioonis <code>spec<\/code> sellise valiku:<\/p>\n<pre><code>\u2026\nnodeSelector:\n\tCPUType: HIGHFREQ<\/code><\/pre>\n<p>Rohkem kulukas ja spetsiifiline meetod selle tegemiseks on kasutada <code>nodeAffinity<\/code> v\u00e4ljal <code>affinity<\/code> sektsioonis <code>spec<\/code>. On kaks varianti:<\/p>\n<ul>\n<li>\n<p><code>requiredDuringSchedulingIgnoredDuringExecution<\/code>: rangeerimine (planeerija juurutab podid ainult konkreetsetele nodidele (ja mitte kuhugi mujale));<\/p>\n<\/li>\n<li>\n<p><code>preferredDuringSchedulingIgnoredDuringExecution<\/code>: pehme seadistus (planeerija p\u00fc\u00fcab juurutada konkreetsetele nodidele ning kui see ei \u00f5nnestu, proovib juurutada j\u00e4rgmisele k\u00e4ttesaadavale noodi).<\/p>\n<\/li>\n<\/ul>\n<p>Saate m\u00e4\u00e4rata kindla sildistamisjuhtimise s\u00fcntaksi, n\u00e4iteks <code>In<\/code>, <code>NotIn<\/code>, <code>Exists<\/code>, <code>DoesNotExist<\/code>, <code>Gt<\/code> v\u00f5i <code>Lt<\/code>. Kuid pidage meeles, et keerulised meetodid pikkade m\u00e4rgis\u00fcsteemide puhul aeglustavad otsuste tegemist kriitilistes olukordades. Teisis\u00f5nu, \u00e4rge keerutage asju liialt komplikeerituks.<\/p>\n<p>Nagu eelnevalt mainitud, v\u00f5imaldab Kubernetes seadistada praeguste podide sidumise. See t\u00e4hendab, et saate teha nii, et teatud podid t\u00f6\u00f6taksid koos teiste podidega samas saadavuspiirkonnas (mis on oluline pilveteenuste puhul) v\u00f5i noodides.<\/p>\n<p>V <code>podAffinity<\/code> v\u00e4ljad <code>affinity<\/code> sektsioonis <code>spec<\/code> saadaval on samad v\u00e4ljad nagu ka <code>nodeAffinity<\/code>: <code>requiredDuringSchedulingIgnoredDuringExecution<\/code><strong> <\/strong>ja <code>preferredDuringSchedulingIgnoredDuringExecution<\/code>. Ainuke erinevus on see, et <code>matchExpressions<\/code> sidumine paneb podid nodi k\u00fclge, kus juba t\u00f6\u00f6tab pod, millel on selline m\u00e4rk.<\/p>\n<p>Lisaks pakub Kubernetes v\u00e4lja <code>podAntiAffinity<\/code>, mis seevastu ei seosta podi nodiga, kus on teatud podid.<\/p>\n<p>V\u00e4ljendite osas <code>nodeAffinity<\/code> v\u00f5ib anda sama n\u00f5u: p\u00fc\u00fcdke hoida reeglid lihtsad ja loogilised, v\u00e4ltige podide spetsifikatsiooni liialt keeruliseks muutmist. On v\u00e4ga lihtne luua reegel, mis ei vasta klastritingimustele, luues lisakoormuse planeerijale ja v\u00e4hendades \u00fcldist j\u00f5udlust.<\/p>\n<h2>7. Taints &amp; Tolerations<\/h2>\n<p>On olemas veel \u00fcks v\u00f5imalus planeerija haldamiseks. Kui teil on suur klaster, kus on sadu s\u00f5lmi ja tuhandeid mikroteenuseid, on v\u00e4ga keeruline mitte lubada teatud podide paigutamist teatud s\u00f5lmedesse.<\/p>\n<p>Sellele aitab kaasa taint-mehhanism \u2014 keelavaid reegleid. N\u00e4iteks on teatud stsenaariumides v\u00f5imalik keelata teatud s\u00f5lmedel podide k\u00e4ivitamine. Taint'i rakendamiseks konkreetsele s\u00f5lmele tuleb kasutada valikut <code>taint<\/code> kubectl. N\u00e4idake v\u00f5tme ja v\u00e4\u00e4rtuse ning seej\u00e4rel taint nagu <code>NoSchedule<\/code> v\u00f5i <code>NoExecute<\/code>:<\/p>\n<pre><code>$ kubectl taint nodes node10 node-role.kubernetes.io\/ingress=true:NoSchedule<\/code><\/pre>\n<p>Samuti v\u00e4\u00e4rib m\u00e4rkimist, et taint-mehhanism toetab kolme peamist efekti: <code>NoSchedule<\/code>, <code>NoExecute<\/code> ja <code>PreferNoSchedule<\/code><strong>. <\/strong><\/p>\n<ul>\n<li>\n<p><code>NoSchedule<\/code><strong> <\/strong>t\u00e4hendab, et seni kuni podi spetsifikatsioonis ei ole vastavat kirjet <code>tolerations<\/code>, ei saa see olla s\u00f5lmes juurutatud (antud n\u00e4ites <code>node10<\/code>).<\/p>\n<\/li>\n<li>\n<p><code>PreferNoSchedule <\/code>\u2014 lihtsustatud versioon <code>NoSchedule<\/code>. Sel juhul p\u00fc\u00fcab planeerija mitte jaotada podisid, millel ei ole vastavat kirjet <code>tolerations<\/code> s\u00f5lmele, kuid see ei ole range piirang. Kui klastris ei ole ressursse, hakkavad podid selle s\u00f5lme juurutama.<\/p>\n<\/li>\n<li>\n<p><code>NoExecute<\/code><strong> <\/strong>\u2014 see efekt k\u00e4ivitab kohe podide evakueerimise, millel ei ole vastavat kirjet. <code>tolerations<\/code>.<\/p>\n<\/li>\n<\/ul>\n<p>Huvitav, et sellist k\u00e4itumist saab t\u00fchistada toleratsioonimehhanismi abil. See on mugav, kui on olemas \"keelatud\" s\u00f5lm ja soovite sellele paigutada ainult infrastruktuuri teenuseid. Kuidas seda teha? Luba ainult need podid, millel on sobiv toleratsioon.<\/p>\n<p>Nii n\u00e4eb v\u00e4lja podi spetsifikatsioon:<\/p>\n<pre><code>spec:\n   tolerations:\n     - key: \"node-role.kubernetes.io\/ingress\"\n        operator: \"Equal\"\n        value: \"true\"\n        effect: \"NoSchedule\"<\/code><\/pre>\n<p>See ei t\u00e4henda, et j\u00e4rgmisel redploy-l satub pod kindlasti sellele s\u00f5lmele, see ei ole Node Affinity mehhanism ja <code>nodeSelector<\/code>. Kuid kombineerides mitmeid funktsioone, saate saavutada v\u00e4ga paindlikud plaanijate seadistused.<\/p>\n<h2>8. Konfigureerige podide juurutamise prioriteet<\/h2>\n<p>See, et olete seadistatud podide seondumise s\u00f5lmedega, ei t\u00e4henda, et k\u00f5ik podid peaksid olema t\u00f6\u00f6deldud sama prioriteediga. N\u00e4iteks v\u00f5ite soovida juurutada teatud podid varem kui teised.<\/p>\n<p>Kubernetes pakub erinevaid viise podide prioriteedi seadistamiseks (Pod Priority and Preemption). Seadistamine koosneb mitmest osast: objektist <code>PriorityClass<\/code><strong> <\/strong>ja kirjelduse v\u00e4ljast <code>priorityClassName<\/code><strong> <\/strong>podi spetsifikatsioonis. Vaadakem n\u00e4iteks:<\/p>\n<pre><code>apiVersion: scheduling.k8s.io\/v1\nkind: PriorityClass\nmetadata:\n  name: high-priority\nvalue: 99999\nglobalDefault: false\ndescription: \"Seda prioriteed tuleb kasutada ainult v\u00e4ga t\u00e4htsate pod'ide jaoks\"<\/code><\/pre>\n<p>Me loome <code>PriorityClass<\/code>, anname sellele nime, kirjelduse ja v\u00e4\u00e4rtuse.<strong> <\/strong>Mida k\u00f5rgem <code>value<\/code>, seda k\u00f5rgem on prioriteet. V\u00e4\u00e4rtus v\u00f5ib olla mis tahes 32-bitine t\u00e4isarv, mis on v\u00e4iksem v\u00f5i v\u00f5rdne 1 000 000 000. K\u00f5rgemad v\u00e4\u00e4rtused on reserveeritud kriitilistele s\u00fcsteemipod'idele, mida \u00fcldiselt ei saa sunniviisil v\u00e4lja l\u00fclitada.<strong> <\/strong>V\u00e4ljal\u00fclitamine toimub ainult siis, kui k\u00f5rge prioriteediga pod'il pole kuhugi paigutuda, siis teatud s\u00f5lmedelt osad pod'id evakueeritakse. Kui see mehhanism tundub teile liiga j\u00e4ik, siis v\u00f5ite lisada valiku <code>preemptionPolicy: Never<\/code>, ja siis ei ole v\u00e4ljal\u00fclitamist, pod j\u00e4\u00e4b j\u00e4rjekorras esimeseks ja ootab, kuni planeerija leiab sellele vabade ressurside.<\/p>\n<p>Seej\u00e4rel loome pod'i, kus m\u00e4\u00e4rame nime <code>priorityClassName<\/code>:<\/p>\n<pre><code>apiVersion: v1\nkind: Pod\nmetadata:\n  name: static-web\n  labels:\n    role: myrole\n spec:\n  containers:\n    - name: web\n      image: nginx\n      ports:\n        - name: web\n          containerPort: 80\n          protocol: TCP\n  priorityClassName: high-priority\n          <\/code><\/pre>\n<p>V\u00f5ib luua piiramatult prioriteediklasside arvu, kuigi soovitatakse sellega mitte liialdada (n\u00e4iteks piirduda madala, keskmise ja k\u00f5rge prioriteediga). <\/p>\n<p>Seega, vajadusel saate t\u00f5sta kriitiliste teenuste, nagu nginx-ingress-controller, coredns jne, t\u00f5husust.<\/p>\n<h2>9. Optimeerige ETCD-klaster<\/h2>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00e4pun\u00e4idet Kubernetes&#039;i t\u00f5hususe parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/f5917adfa943c789b6c784f43305851b.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>ETCD v\u00f5ib olla kogu klastrite teaduse keskpunkt. On \u00e4\u00e4rmiselt oluline hoida selle andmebaasi t\u00f6\u00f6 kvaliteet k\u00f5rgel, kuna just sellest s\u00f5ltub operatsioonide kiirus \"Klastes\". Tavaline ja suhteliselt hea lahendus on hoida ETCD klaster peat\u00f6\u00f6tajatel, et tagada minimaalne viivitus kube-apiserverini. Kui see pole v\u00f5imalik, proovige paigutada ETCD nii l\u00e4hedale kui v\u00f5imalik, tagades osalejate vahel hea ribalaiuse. Samuti pidage meeles, kui palju ETCD s\u00f5lmi saab v\u00e4lja langeda ilma klastrile kahjustamata.<\/p>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00e4pun\u00e4idet Kubernetes&#039;i t\u00f5hususe parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/cdd2c32eefed253c6ff774899c367ccc.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Pidage meeles, et liiga paljude osalejate lisamine klastrisse v\u00f5ib suurendada rikke taluvust, kuid see v\u00f5ib p\u00e4rssida j\u00f5udlust \u2014 k\u00f5ik peaks olema m\u00f5\u00f5dukalt.<\/p>\n<p>Kui r\u00e4\u00e4kida teenuse seadistamisest, siis soovitusi on v\u00e4he:<\/p>\n<ol>\n<li>\n<p>Omada head riistvara, s\u00f5ltuvalt klastrite suurusest (v\u00f5ite lugeda) <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/etcd-io\/etcd\/blob\/master\/Documentation\/op-guide\/hardware.md\">siin<\/a><\/noindex>).<\/p>\n<\/li>\n<li>\n<p>Reguleerige m\u00f5ned seaded, kui olete klastrit levitanud paari andmeruumi vahel v\u00f5i kui teie v\u00f5rk ja kettad j\u00e4tavad soovida (saate lugeda <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/etcd-io\/etcd\/blob\/master\/Documentation\/tuning.md\">siin<\/a><\/noindex>).<\/p>\n<\/li>\n<\/ol>\n<h2>Kokkuv\u00f5te<\/h2>\n<p>Selles artiklis kirjeldatakse punkte, mida meie meeskond p\u00fc\u00fcab j\u00e4rgida. See ei ole samm-sammult juhend, vaid variandid, mis v\u00f5ivad aidata klastrikulu optimeerida. On selge, et iga klaster on omamoodi ainulaadne ja seadistamise lahendused v\u00f5ivad oluliselt erineda, seet\u00f5ttu oleks huvitav saada teilt tagasisidet: kuidas te j\u00e4lgite oma Kubernetes klastrit, millega te parandate selle t\u00f6\u00f6d. Jagage oma kogemusi kommentaarides, oleks huvitav neid teada. <\/p>\n<p>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/domclick\/blog\/520968\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041e\u043b\u0435\u0433 \u0421\u0438\u0434\u043e\u0440\u0435\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0414\u043e\u043c\u041a\u043b\u0438\u043a \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u043c \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b. \u041c\u044b \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0438\u0440\u0443\u0435\u043c \u00ab\u041a\u0443\u0431\u0438\u043a\u00bb \u0432 \u043f\u0440\u043e\u0434\u0435 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 \u0442\u0440\u0451\u0445 \u043b\u0435\u0442, \u0438 \u0437\u0430 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f \u043f\u0435\u0440\u0435\u0436\u0438\u043b\u0438 \u0441 \u043d\u0438\u043c \u043c\u043d\u043e\u0433\u043e \u0440\u0430\u0437\u043d\u044b\u0445 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u0445 \u043c\u043e\u043c\u0435\u043d\u0442\u043e\u0432. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u043f\u043e\u0432\u0435\u0434\u0430\u044e \u0432\u0430\u043c, \u043a\u0430\u043a \u043f\u0440\u0438 \u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u0435 \u043c\u043e\u0436\u043d\u043e \u0432\u044b\u0436\u0430\u0442\u044c \u0438\u0437 \u00ab\u0432\u0430\u043d\u0438\u043b\u044c\u043d\u043e\u0433\u043e\u00bb Kubernetes \u0435\u0449\u0451 \u0431\u043e\u043b\u044c\u0448\u0435 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0434\u043b\u044f \u0432\u0430\u0448\u0435\u0433\u043e \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430. Ready steady [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97983,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97982","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041e\u043b\u0435\u0433 \u0421\u0438\u0434\u043e\u0440\u0435\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0414\u043e\u043c\u041a\u043b\u0438\u043a \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u043c \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b. \u041c\u044b \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0438\u0440\u0443\u0435\u043c \u00ab\u041a\u0443\u0431\u0438\u043a\u00bb \u0432 \u043f\u0440\u043e\u0434\u0435 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 \u0442\u0440\u0451\u0445 \u043b\u0435\u0442, \u0438 \u0437\u0430 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f \u043f\u0435\u0440\u0435\u0436\u0438\u043b\u0438 \u0441 \u043d\u0438\u043c \u043c\u043d\u043e\u0433\u043e \u0440\u0430\u0437\u043d\u044b\u0445 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u0445 \u043c\u043e\u043c\u0435\u043d\u0442\u043e\u0432. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u043f\u043e\u0432\u0435\u0434\u0430\u044e \u0432\u0430\u043c, \u043a\u0430\u043a \u043f\u0440\u0438 \u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u0435 \u043c\u043e\u0436\u043d\u043e \u0432\u044b\u0436\u0430\u0442\u044c \u0438\u0437 \u00ab\u0432\u0430\u043d\u0438\u043b\u044c\u043d\u043e\u0433\u043e\u00bb Kubernetes \u0435\u0449\u0451 \u0431\u043e\u043b\u044c\u0448\u0435 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0434\u043b\u044f \u0432\u0430\u0448\u0435\u0433\u043e \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430. Ready steady\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0414\u0435\u0432\u044f\u0442\u044c \u0441\u043e\u0432\u0435\u0442\u043e\u0432 \u043f\u043e \u043f\u043e\u0432\u044b\u0448\u0435\u043d\u0438\u044e \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 Kubernetes | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041e\u043b\u0435\u0433 \u0421\u0438\u0434\u043e\u0440\u0435\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0414\u043e\u043c\u041a\u043b\u0438\u043a \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u043c \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b. \u041c\u044b \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0438\u0440\u0443\u0435\u043c \u00ab\u041a\u0443\u0431\u0438\u043a\u00bb \u0432 \u043f\u0440\u043e\u0434\u0435 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 \u0442\u0440\u0451\u0445 \u043b\u0435\u0442, \u0438 \u0437\u0430 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f \u043f\u0435\u0440\u0435\u0436\u0438\u043b\u0438 \u0441 \u043d\u0438\u043c \u043c\u043d\u043e\u0433\u043e \u0440\u0430\u0437\u043d\u044b\u0445 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u0445 \u043c\u043e\u043c\u0435\u043d\u0442\u043e\u0432. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u043f\u043e\u0432\u0435\u0434\u0430\u044e \u0432\u0430\u043c, \u043a\u0430\u043a \u043f\u0440\u0438 \u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u0435 \u043c\u043e\u0436\u043d\u043e \u0432\u044b\u0436\u0430\u0442\u044c \u0438\u0437 \u00ab\u0432\u0430\u043d\u0438\u043b\u044c\u043d\u043e\u0433\u043e\u00bb Kubernetes \u0435\u0449\u0451 \u0431\u043e\u043b\u044c\u0448\u0435 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0434\u043b\u044f \u0432\u0430\u0448\u0435\u0433\u043e \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430. Ready steady\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-10-23T12:42:15+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-11-17T22:58:47+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00dcheksa n\u00f5uannet Kubernetes j\u00f5udluse t\u00f5stmiseks | ProHoster","description":"Tere k\u00f5igile! Minu nimi on Oleg Sidorenkov, ma t\u00f6\u00f6tan ettev\u00f5ttes DomClick infrastruktuuri meeskonna juhina. Oleme \"Kubi\" tootmises kasutanud juba \u00fcle kolme aasta ja sel ajal oleme kogenud palju erinevaid huvitavaid hetki. T\u00e4na r\u00e4\u00e4gin teile, kuidas \u00f5ige l\u00e4henemisega saate \"puhtalt\" Kuberneteselt veelgi rohkem j\u00f5udlust v\u00e4lja pigistada teie klastrile. Valmis, start","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes","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\u0414\u0435\u0432\u044f\u0442\u044c \u0441\u043e\u0432\u0435\u0442\u043e\u0432 \u043f\u043e \u043f\u043e\u0432\u044b\u0448\u0435\u043d\u0438\u044e \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 Kubernetes | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041e\u043b\u0435\u0433 \u0421\u0438\u0434\u043e\u0440\u0435\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0414\u043e\u043c\u041a\u043b\u0438\u043a \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u043c \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b. \u041c\u044b \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0438\u0440\u0443\u0435\u043c \u00ab\u041a\u0443\u0431\u0438\u043a\u00bb \u0432 \u043f\u0440\u043e\u0434\u0435 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 \u0442\u0440\u0451\u0445 \u043b\u0435\u0442, \u0438 \u0437\u0430 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f \u043f\u0435\u0440\u0435\u0436\u0438\u043b\u0438 \u0441 \u043d\u0438\u043c \u043c\u043d\u043e\u0433\u043e \u0440\u0430\u0437\u043d\u044b\u0445 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u0445 \u043c\u043e\u043c\u0435\u043d\u0442\u043e\u0432. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u043f\u043e\u0432\u0435\u0434\u0430\u044e \u0432\u0430\u043c, \u043a\u0430\u043a \u043f\u0440\u0438 \u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u0435 \u043c\u043e\u0436\u043d\u043e \u0432\u044b\u0436\u0430\u0442\u044c \u0438\u0437 \u00ab\u0432\u0430\u043d\u0438\u043b\u044c\u043d\u043e\u0433\u043e\u00bb Kubernetes \u0435\u0449\u0451 \u0431\u043e\u043b\u044c\u0448\u0435 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0434\u043b\u044f \u0432\u0430\u0448\u0435\u0433\u043e \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430. Ready steady","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes","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":"2020-10-23T12:42:15+00:00","article:modified_time":"2020-11-17T22:58:47+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97982","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:08:27","updated":"2022-09-30 17:30:03"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/97982","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=97982"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/97982\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/97983"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=97982"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=97982"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=97982"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}