{"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\u00f5uannet Kubernetes'e j\u00f5udluse parandamiseks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00f5uannet Kubernetes&#039;e j\u00f5udluse 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 Sidorenkov ja ma t\u00f6\u00f6tan ettev\u00f5ttes DomKlik infrastruktuuri meeskonna juhina. Oleme juba \u00fcle kolme aasta kasutanud 'Kuubikut' tootmises ning selle aja jooksul oleme selle kasutamisel kogenud palju erinevaid huvitavaid hetki. T\u00e4na r\u00e4\u00e4gin teile, kuidas \u00f5ige l\u00e4henemise korral saate 'tavalise' Kubernetesest veelgi rohkem j\u00f5udlust oma klastrile v\u00e4lja pigistada. Valmis, juba! <\/p>\n<p>Te k\u00f5ik teate, et Kubernetes on skaleeritav avatud l\u00e4htekoodiga s\u00fcsteem konteinerite orkestreerimiseks; v\u00f5i nagu 5 binaari, mis loovad maagia, hallates teie mikroteenuste eluts\u00fckli serverikeskkonnas. See on ka \u00fcsna paindlik t\u00f6\u00f6riist, mida saab koguda nagu Lego klotsid, et maksimeerida kohandamist erinevate \u00fclesannete jaoks.<\/p>\n<p>Ja tundub, et k\u00f5ik on h\u00e4sti: viska serverid klastrisse nagu k\u00fcttepuid ahju ja \u00e4ra muretse. Kuid kui hoolid keskkonnast, siis m\u00f5tle: 'Kuidas ma saan ahjus tuld hoida ja metsa s\u00e4\u00e4sta?'. Teisis\u00f5nu, kuidas leida viise infrastruktuuri parandamiseks ja kulude k\u00e4rpimiseks.<\/p>\n<h2>1. J\u00e4lgige meeskondade ja rakenduste ressursse<\/h2>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00f5uannet Kubernetes&#039;e j\u00f5udluse parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/91e2e60b47ee985b024532c8b685230c.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>\u00dcks k\u00f5ige m\u00f5istlikumaid, kuid t\u00f5husamaid meetodeid on requests\/limits'i rakendamine. Jagage rakendusi nimedega ruumidesse ja nimetage ruumid arendusmeeskondade j\u00e4rgi. 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>Kogemuste p\u00f5hjal oleme j\u00f5udnud j\u00e4reldusele, et ei tasu \u00fcletada soove piiridele rohkem kui kahekordse erinevusega. Klasteri maht arvutatakse soovide p\u00f5hjal ja kui m\u00e4\u00e4rate rakendustele ressursivahe, n\u00e4iteks 5\u201310 korda, siis kujutage ette, mis juhtub teie s\u00f5lmega, kui see t\u00e4itub podidega ja saab j\u00e4rsku koormuse. Mitte midagi head. Minimaalselt throttling, maksimaalselt h\u00fcvasti t\u00f6\u00f6tajaga ja hakkate saama ts\u00fcklilist koormust teistele s\u00f5lmedele p\u00e4rast seda, kui podid hakkavad liikuma.<\/p>\n<p>Lisaks saab abil <code>limitranges<\/code> v\u00f5ite alguses m\u00e4\u00e4rata konteinerile ressursiv\u00e4\u00e4rtused - minimaalsed, maksimaalsed ja vaikev\u00e4\u00e4rtused:<\/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>\u00c4rge unustage piirata nimede ruumi ressursse, et \u00fcks meeskond ei saaks k\u00f5ik klastrite ressursid endale v\u00f5tta:<\/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 kohaselt <code>resourcequotas<\/code>, kui ops meeskond soovib v\u00e4lja lasta pod'e, mis tarvitavad veel 10 cpu, siis ajakava ei luba seda teha ja tagastab 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>Sarnaste probleemide lahendamiseks v\u00f5ib kirjutada t\u00f6\u00f6riista, n\u00e4iteks nagu <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/pauljamm\/team-operator\">see<\/a><\/noindex>, mis suudab salvestada ja commit'ida meeskonna ressursse.<\/p>\n<h2>2. Valige optimaalne failihaldus<\/h2>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00f5uannet Kubernetes&#039;e j\u00f5udluse parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/c7f8bdbf5490acc9061695a6d608015e.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Siin sooviksin puudutada p\u00fcsivate mahtude ja Kubernetes worker-node diskis\u00fcsteemi teemat. Loodan, et keegi ei kasuta \u201eKuberneete\u201d HDD-l, kuid vahel ei ole tavaline SSD enam piisav. Oleme avanud probleemi, kus logid tapavad ketast sisend-v\u00e4ljund toimingute t\u00f5ttu, ja siin pole lahendusi eriti palju: <\/p>\n<ul>\n<li>\n<p>Kasutage k\u00f5rgtehnoloogilisi SSD-sid v\u00f5i minge NVMe (kui te ise hallate oma riistvara).<\/p>\n<\/li>\n<li>\n<p>V\u00e4hendage logimise taset.<\/p>\n<\/li>\n<li>\n<p>Tehke \u201enutikas\u201d pod'ide tasakaalustus, mis koormavad ketast (<code>podAntiAffinity<\/code>).<\/p>\n<\/li>\n<\/ul>\n<p>\u00dclemine ekraan n\u00e4itab, mis juhtub nginx-ingress-controller'i all, kui access_logs logimine on sisse l\u00fclitatud (~12 tuhat logi\/sekundis). Selline olukord v\u00f5ib loomulikult viia k\u00f5igi selle nodi rakenduste halvenemiseni.<\/p>\n<p>Mis puutub PV-desse, siis kahjuks ei ole ma proovinud k\u00f5iki <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/persistent-volumes\/#types-of-persistent-volumes\">t\u00fc\u00fcpe<\/a><\/noindex> P\u00fcsivad mahud. Valige endale sobivaim variant. Meil on historiliselt v\u00e4lja kujunenud, et v\u00e4ike osa teenustest vajab RWX-mahtu ja juba ammu on selle jaoks kasutusel NFS-salvestus. Odav ja\u2026 piisab. Muidugi, me oleme sellega omajagu vaeva n\u00e4inud \u2014 olgu tere, aga oleme \u00f5ppinud seda h\u00e4\u00e4lestama ja peavalu enam ei oma. Ja kui see on v\u00f5imalik, siis minge \u00fcle S3 objektisalvestusele.<\/p>\n<h2>3. Koguge optimeeritud pilte<\/h2>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00f5uannet Kubernetes&#039;e j\u00f5udluse parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/c25ce405d1eb4c01f031e18b0bfa4836.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Parim on kasutada konteineritele optimeeritud pilte, et Kubernetes saaks neid kiiremini hankida ja t\u00f5husamalt k\u00e4itada.&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\u00e4ikese suurusega, sest suured pildid edastatakse v\u00f5rgus halvemini;<\/p>\n<\/li>\n<li>\n<p>omavad l\u00f5pp-punkte t\u00f6\u00f6kindluse ja valmiduse kontrollimiseks, mille abil Kubernetes saab ettev\u00f5tta samme h\u00e4irete korral;<\/p>\n<\/li>\n<li>\n<p>kasutavad konteineris\u00f5bralikke operatsioonis\u00fcsteeme (nt Alpine v\u00f5i CoreOS), mis on konfigureerimisvigade suhtes vastupidavamad;<\/p>\n<\/li>\n<li>\n<p>kasutavad mitmeastmelisi kogumisi, et saaksite juurutada ainult kompileeritud rakendusi, mitte kaasnevaid l\u00e4htekoode.<\/p>\n<\/li>\n<\/ul>\n<p>On palju t\u00f6\u00f6riistu ja teenuseid, mis v\u00f5imaldavad pilte jooksvalt kontrollida ja optimeerida. Oluline on hoida neid alati ajakohasena ja turvalisuse m\u00f5ttes kontrollituna. L\u00f5puks saate: <\/p>\n<ol>\n<li>\n<p>V\u00f5rgu koormuse v\u00e4hendamine kogu klastril.<\/p>\n<\/li>\n<li>\n<p>Konteineri k\u00e4ivitamise aja l\u00fchendamine.<\/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\u00f5uannet Kubernetes&#039;e j\u00f5udluse parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/9f4384462a77dc528d7911c56f684f2d.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Kui r\u00e4\u00e4kida k\u00f5rgest koormusest, siis ilma klastrite DNS-s\u00fcsteemi h\u00e4\u00e4lestamiseta on elu \u00fcsna vilets. Kui kunagi ammu toetasid Kubernetes arendajad oma lahendust kube-dns. See rakendus paigaldati ka meile, kuid seda tarkvara ei h\u00e4\u00e4lestatud eriti ja see ei andnud vajalikku j\u00f5udlust, kuigi \u00fclesanne tundus olevat lihtne. Siis ilmus coredns, millele me \u00fcle l\u00e4ksime ja muretsesime v\u00e4hem, sellest sai ka K8s-i vaikimisi DNS-teenus. \u00dchel hetkel j\u00f5udsime 40 000 rps DNS-s\u00fcsteemi ja sellest lahendusest ei piisanud enam. Aga \u00f5nnelikul juhusel 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 k\u00e4rjes on bug, mis mitme samaaegse p\u00e4ringu korral conntrack NAT kaudu UDP-lt viib v\u00f5istlusseisundisse conntrack-tabelisse kirjutamisel, mille t\u00f5ttu osa liiklusest NAT kaudu kaob (iga p\u00e4ring l\u00e4bi teenuse on NAT). Nodelocaldns lahendab selle probleemi, k\u00f5rvaldades NAT-i ja uue \u00fchenduse loomise TCP kaudu upstream DNS-iga ning kohaliku DNS-p\u00e4ringute vahem\u00e4lu, sealhulgas l\u00fchikese 5-sekundilise negatiivse vahem\u00e4lu.<\/p>\n<h2>5. Skaalake pod'ide horisontaalset ja vertikaalset automaatset skaleerimist<\/h2>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00f5uannet Kubernetes&#039;e j\u00f5udluse 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 kolmeks koormuse kasvuks? Kuidas m\u00e4\u00e4rata \u00f5igesti oma rakendustele ressursse? Kaks pod'i, mis t\u00f6\u00f6tavad \u00fcle koormuse, v\u00f5ivad osutuda liigseks, kuid kitsas hoidmine t\u00e4hendab, et olete riskis teenusele \u00e4kilise suure liikluse t\u00f5ttu seisaku saamisega. Kuldeesm\u00e4rki aitavad saavutada skaleerimist teenuseid, nagu <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/tasks\/run-application\/horizontal-pod-autoscale\/\">Horizontal Pod Autoscaler<\/a><\/noindex> ja <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/autoscaler\/tree\/master\/vertical-pod-autoscaler\">Vertical Pod Autoscaler<\/a><\/noindex>. <\/p>\n<p><strong>VPA<\/strong> v\u00f5imaldab automaatset t\u00f5stmist teie konteinerite requests\/limits pod'is vastavalt tegelikule kasutusele. Kuidas see v\u00f5ib olla kasulik? Kui teil on pod'e, mida mingil p\u00f5hjusel ei saa horisontaalselt skaleerida (mis ei ole eriti usaldusv\u00e4\u00e4rne), siis v\u00f5ite proovida usaldada VPA-le oma ressursside muutmist. Selle erip\u00e4ra 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 konteinerite jaoks ja optimeerida seadeid, et s\u00e4\u00e4sta protsessorit ja m\u00e4lu klastris. <\/p>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00f5uannet Kubernetes&#039;e j\u00f5udluse parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/3965950aa3315faa4bb3e3ff5bd61955.png\" style=\"display:block;margin: 0 auto;\" \/>Pilt on saadud aadressilt https:\/\/levelup.gitconnected.com\/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231<\/p>\n<p>Kubernetes'i planifikaator p\u00f5hineb alati requests'il. Olgu see, mis tahes v\u00e4\u00e4rtus, mida te sinna panete, planifikaator otsib sobivat s\u00f5lme vastavalt sellele. Limit'i v\u00e4\u00e4rtused on vajalikud k\u00fcblile, et m\u00f5ista, millal piirata v\u00f5i tappa pod. Kuna ainus oluline parameeter on requests'i v\u00e4\u00e4rtus, t\u00f6\u00f6tab VPA sellega. Iga kord, kui m\u00e4\u00e4rate oma rakendusele vertikaalse skaleerimise, m\u00e4\u00e4rate, millised peaksid olema requests'id. Aga mis saab siis limit'itest? See parameeter skaleeritakse proportsionaalselt.<\/p>\n<p>N\u00e4iteks siin on tavalised pod'i seaded:<\/p>\n<pre><code>ressursid:\n   taotlused:\n     m\u00e4lu: 250Mi\n     cpu: 200m\n   piirangud:\n     m\u00e4lu: 500Mi\n     cpu: 350m<\/code><\/pre>\n<p>Soovitusmehhanism m\u00e4\u00e4rab, et teie rakendusele on vajalik normaalne t\u00f6\u00f6ks 300m CPU ja 500Mi. Te saate j\u00e4rgmised seaded:<\/p>\n<pre><code>ressursid:\n   taotlused:\n     m\u00e4lu: 500Mi\n     cpu: 300m\n   piirangud:\n     m\u00e4lu: 1000Mi\n     cpu: 525m<\/code><\/pre>\n<p>Nagu eelnevalt mainitud, on see proportsionaalne skaleerimine, mis p\u00f5hineb taotluste\/piirangute suhte mansiifis:<\/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>Mis puudutab <strong>HPA<\/strong>, siis siin t\u00f6\u00f6mehhanism on l\u00e4bipaistvam. Seatud on k\u00fcnnise v\u00e4\u00e4rtused m\u00f5\u00f5dikute jaoks, nagu n\u00e4iteks CPU ja m\u00e4lu, ja kui k\u00f5ikide replikate keskmine v\u00e4\u00e4rtus \u00fcletab k\u00fcnnise, skaleeritakse rakendus +1 podini, kuni v\u00e4\u00e4rtus langeb k\u00fcnnisest madalamale v\u00f5i kuni maksimaalne replikate arv on saavutatud.<\/p>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00f5uannet Kubernetes&#039;e j\u00f5udluse parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/f7a3fa28177d66be925867e38f5bbed6.png\" style=\"display:block;margin: 0 auto;\" \/>Pilt on saadud 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\u00f5dikutele, nagu CPU ja m\u00e4lu, saate seada k\u00fcnniseid oma kohandatud m\u00f5\u00f5dikutele Prometheuses ja t\u00f6\u00f6tada nendega, kui arvate, et see on k\u00f5ige t\u00e4psem m\u00e4\u00e4ratlemine, kui tuleb teie rakendust skaleerida. Kui rakendus stabiliseerub m\u00e4\u00e4ratud m\u00f5\u00f5diku alla, hakkab HPA skaleerima pode allapoole minimaalse replikate arvuni v\u00f5i kuni olek, mil 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\u00f5uannet Kubernetes&#039;e j\u00f5udluse parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/e718191d9e8ff25fd3b2d65cba9b3b73.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Kaugl\u00fclitused, kus toimub t\u00f6\u00f6tlemine, ei t\u00f6\u00f6ta k\u00f5ik \u00fchesugustes seadmetes, ja mitte k\u00f5ik podid ei pea jooksutama rakendusi, mis n\u00f5uavad intensiivseid arvutusi. Kubernetes v\u00f5imaldab m\u00e4\u00e4rata node'id ja podid spetsialiseerimisega. <strong>Node Affinity<\/strong> ja <strong>Pod Affinity<\/strong>.<\/p>\n<p>Kui teil on node'id, mis sobivad intensiivsete arvutuste jaoks, on maksimaalse efektiivsuse tagamiseks parem siduda rakendused vastavatele node'idele. Selleks kasutage <code>nodeSelector<\/code> sildi m\u00e4\u00e4ratluses.<\/p>\n<p>Oletame, et teil on kaks node'i: \u00fcks, millel on <code>CPUType=HIGHFREQ<\/code> ja palju kiireid tuumasid, teine, millel on <code>MemoryType=HIGHMEMORY<\/code> palju m\u00e4lu ja k\u00f5rgem j\u00f5udlus. Lihtsaim on m\u00e4\u00e4rata pod'i rakendamine node'ile <code>HIGHFREQ<\/code>, lisades jaotisesse <code>spec<\/code> selline valija:<\/p>\n<pre><code>\u2026\nnodeSelector:\n\tCPUType: HIGHFREQ<\/code><\/pre>\n<p>Rohkem kulukas ja spetsiifiline viis seda teha on kasutada <code>nodeAffinity<\/code> v\u00e4ljal <code>affinity<\/code> jaotises <code>spec<\/code>. On kaks varianti:<\/p>\n<ul>\n<li>\n<p><code>requiredDuringSchedulingIgnoredDuringExecution<\/code>: rangeerimine (planeerija rakendab pode ainult kindlates node'ides (ja mitte kuskil mujal));<\/p>\n<\/li>\n<li>\n<p><code>preferredDuringSchedulingIgnoredDuringExecution<\/code>: pehme kohandamine (planifier p\u00fc\u00fcab juurutada konkreetsetele s\u00f5lmedele ning kui see ei \u00f5nnestu, siis p\u00fc\u00fcab ta juurutada j\u00e4rgmisele saadaval olevale s\u00f5lmele).<\/p>\n<\/li>\n<\/ul>\n<p>Saate m\u00e4\u00e4rata konkreetse s\u00f5lme m\u00e4rgendusjuhtimise s\u00fcntaksit, 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 pikkades m\u00e4rgendusloendites aeglustavad kriitilistes olukordades otsuste tegemist. Teisis\u00f5nu, \u00e4rge keerake seda keeruliseks.<\/p>\n<p>Kuidas mainitud, v\u00f5imaldab Kubernetes m\u00e4\u00e4rata jooksvaid podide sidumisi. See t\u00e4hendab, et saate seadistada teatud podide t\u00f6\u00f6tamise koos teiste podidega samas k\u00e4ttesaadavuse tsoonis (aktuaalne pilveteenustes) v\u00f5i s\u00f5lmedes.<\/p>\n<p>Uues <code>podAffinity<\/code> v\u00e4ljad <code>affinity<\/code> jaotises <code>spec<\/code> on saadaval samad v\u00e4ljad nagu <code>nodeAffinity<\/code>: <code>requiredDuringSchedulingIgnoredDuringExecution<\/code><strong> <\/strong>ja <code>preferredDuringSchedulingIgnoredDuringExecution<\/code>. Ainus erinevus on see, et <code>matchExpressions<\/code> sidub podid s\u00f5lmega, millel juba t\u00f6\u00f6tab pod sellise sildiga.<\/p>\n<p>Kubernetes pakub ka v\u00e4lja <code>podAntiAffinity<\/code>, mis seevastu ei seo podi teatud podidega olevate s\u00f5lmega.<\/p>\n<p>Mis puudutab v\u00e4ljendeid, <code>nodeAffinity<\/code> on sama n\u00f5uanne: p\u00fc\u00fcdke s\u00e4ilitada lihtsust ja loogilisust regulaatsioonides, \u00e4rge proovige \u00fcle koormata podide spetsiifikatsiooni keeruliste reeglite kogumiga. On v\u00e4ga lihtne luua reegel, mis ei vasta klastritingimustele, luues lisakoormust planeerijale ja v\u00e4hendades \u00fcldist j\u00f5udlust.<\/p>\n<h2>7. Taints &amp; Tolerations<\/h2>\n<p>On veel \u00fcks viis planeerija juhtimiseks. Kui teil on suur klaster, mis sisaldab sadu s\u00f5lmi ja tuhandeid mikroteenuseid, on v\u00e4ga keeruline mitte lubada teatud podide asukohaks teatud s\u00f5lmed.<\/p>\n<p>Sellele aitab kaasa taintide mehhanism \u2014 keeldude reeglid. N\u00e4iteks v\u00f5ib teatud stsenaariumites keelata teatud s\u00f5lmedel oma podide k\u00e4itamise. Tainti rakendamiseks konkreetsele s\u00f5lmele peate kasutama valikut <code>taint<\/code> kubectl'is. M\u00e4\u00e4rake v\u00f5ti ja v\u00e4\u00e4rtus 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 on oluline m\u00e4rkida, et taintide mehhanism toetab kolme p\u00f5hiefekti: <code>NoSchedule<\/code>, <code>NoExecute<\/code> ja <code>PreferNoSchedule<\/code><strong>. <\/strong><\/p>\n<ul>\n<li>\n<p><code>NoSchedule<\/code><strong> <\/strong>signifitseerib, et kuni podi spesifikatsioonis ei ole vastavat kirjet <code>tolerations<\/code>, ei saa ta olla juurutatud s\u00f5lmesse (selles 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 pole vastavat kirjet <code>tolerations<\/code> s\u00f5lmele, kuid see ei ole range piirang. Kui klastris ei ole ressursse, hakkavad podid sellel s\u00f5lmel juurutama.<\/p>\n<\/li>\n<li>\n<p><code>NoExecute<\/code><strong> <\/strong>\u2014 see efektiga aktiveerib kohe sadamate evakueerimise, millel pole vastavat kirjet <code>tolerations<\/code>.<\/p>\n<\/li>\n<\/ul>\n<p>Huvitav, et sellist k\u00e4itumist saab tagasi v\u00f5tta tolerantside mehhanismi abil. See on mugav, kui on olemas \"keelatud\" s\u00f5lm ja teil on vaja paigutada sinna ainult infrastruktuuri teenuseid. Kuidas seda teha? Lubada ainult need sadamad, millel on sobiv tolerants.<\/p>\n<p>Nii n\u00e4eb v\u00e4lja sadama 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\u00e4rgmise redeploy korral paigutatakse sadam just sellele s\u00f5lmele, see ei ole Node Affinity mehhanism ja <code>nodeSelector<\/code>. Kuid kombineerides mitmeid funktsioone, v\u00f5ite saavutada v\u00e4ga painduva planeerija seadistuse.<\/p>\n<h2>8. Seadistage sadamate juurutamise prioriteet<\/h2>\n<p>See, et olete seadistanud sadamate sidumise s\u00f5lmedega, ei t\u00e4henda, et k\u00f5ik sadamad peaksid olema t\u00f6\u00f6tlemisel sama prioriteediga. N\u00e4iteks v\u00f5ite soovida juurutada teatud sadamaid varem kui teisi.<\/p>\n<p>Kubernetes pakub erinevaid viise sadamate prioriteetide seadistamiseks (Pod Priority and Preemption). Seadistus koosneb mitmest osast: objektist <code>PriorityClass<\/code><strong> <\/strong>ja v\u00e4lja kirjeldusega <code>priorityClassName<\/code><strong> <\/strong>sadama spetsifikatsioonis. Vaatame n\u00e4idet:<\/p>\n<pre><code>apiVersion: scheduling.k8s.io\\\/v1\nkind: PriorityClass\nmetadata:\n  name: high-priority\nvalue: 99999\nglobalDefault: false\ndescription: \"See prioriteediklass peaks olema kasutusel ainult v\u00e4ga oluliste sadamate jaoks\"<\/code><\/pre>\n<p>Loome <code>PriorityClass<\/code>, anname sellele nime, kirjelduse ja v\u00e4\u00e4rtuse.<strong> <\/strong>Mida k\u00f5rgem <code>value<\/code>, seda k\u00f5rgem prioriteet. V\u00e4\u00e4rtus v\u00f5ib olla \u00fcksk\u00f5ik milline 32-bitine t\u00e4isarv, mis on v\u00e4iksem v\u00f5i v\u00f5rdne 1 000 000 000. K\u00f5rgemad v\u00e4\u00e4rtused on reserveeritud kriitiliselt olulistele s\u00fcsteemi sadamatele, mida tavaliselt ei saa eemaldada.<strong> <\/strong>Eemaldamine toimub ainult siis, kui k\u00f5rge prioriteediga sadamal pole kohta, kuhu juurutada, siis osa sadamatest teatud s\u00f5lmel evakueeritakse. Kui see mehhanism on teie jaoks liiga rangetu, v\u00f5ite lisada valiku <code>preemptionPolicy: Never<\/code>, ja siis ei toimu eemaldamisi, sadam ootab esimesena j\u00e4rjekorras ja ootab, kuni planeerija leiab talle vabad ressursid.<\/p>\n<p>Edasi loome sadama, 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>Saate luua piiramatult prioriteediklasse, kuigi soovitatav on j\u00e4\u00e4da m\u00f5\u00f5dukaks (n\u00e4iteks piirduda madala, keskmise ja k\u00f5rge prioriteediga). <\/p>\n<p>Seega, vajaduse korral suudate t\u00f5sta kriitiliste teenuste, nagu nginx-ingress-controller, coredns jms, t\u00f5husust.<\/p>\n<h2>9. Optimeerige ETCD-klaster<\/h2>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00f5uannet Kubernetes&#039;e j\u00f5udluse parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/f5917adfa943c789b6c784f43305851b.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>ETCD-d v\u00f5ib nimetada kogu klastriteks. On v\u00e4ga oluline hoida selle andmebaasi t\u00f6\u00f6 kvaliteet k\u00f5rge, kuna just temast s\u00f5ltub operatsioonide kiirus 'Kubes'. Tavaline ja samas \u00fcsna m\u00f5istlik lahendus on hoida ETCD klaster master-node'ides, et minimeerida latentsust kube-apiserverisse. Kui see ei ole v\u00f5imalik, siis asetage ETCD v\u00f5imalikult l\u00e4hedale, tagades hea l\u00e4bilaskev\u00f5ime osalejate vahel. Samuti j\u00e4lgige, kui palju ETCD s\u00f5lmi v\u00f5ib v\u00e4lja kukkuda ilma, et klaster kannataks.<\/p>\n<p><img decoding=\"async\" alt=\"\u00dcheksa n\u00f5uannet Kubernetes&#039;e j\u00f5udluse parandamiseks\" src=\"\/wp-content\/uploads\/2020\/10\/cdd2c32eefed253c6ff774899c367ccc.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Pidage meeles, et \u00fcleliigne osalejate arvu suurendamine klastris v\u00f5ib t\u00f5sta j\u00e4tkusuutlikkust tootlikkuse arvelt; k\u00f5ik peaks olema m\u00f5\u00f5dukas.<\/p>\n<p>Kui r\u00e4\u00e4kida teenuse seadistamisest, siis soovitusi on v\u00e4he:<\/p>\n<ol>\n<li>\n<p>Omama head riistvara vastavalt klastrite suurusele (v\u00f5ite lugeda <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/etcd-io\/etcd\/blob\/master\/Documentation\/op-guide\/hardware.md\">siit<\/a><\/noindex>).<\/p>\n<\/li>\n<li>\n<p>Reguleerida m\u00f5ningaid parameetreid, kui olete klastrit jaotanud mitme andmekeskuse vahel v\u00f5i teie v\u00f5rk ja kettad j\u00e4tavad soovida (v\u00f5ite lugeda <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/etcd-io\/etcd\/blob\/master\/Documentation\/tuning.md\">siit<\/a><\/noindex>).<\/p>\n<\/li>\n<\/ol>\n<h2>Kokkuv\u00f5te<\/h2>\n<p>Selles artiklis kirjeldatakse punkte, mille j\u00e4rgimist meie meeskond p\u00fc\u00fcab. See ei ole samm-sammuline tegevusjuhend, vaid v\u00f5imalused, mis v\u00f5ivad olla kasulikud klastrite haldamise kulude optimeerimiseks. Selge on, et iga klaster on omamoodi ainulaadne ja seadistuslahendused v\u00f5ivad oluliselt erineda, seega oleks huvitav saada tagasisidet: kuidas te j\u00e4lgite oma Kubernetes klastrit, mille abil te selle t\u00f6\u00f6d parandate. Jagage oma kogemusi kommentaarides, oleks huvitav neid kuulda. <\/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 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442!\" \/>\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) 5.0.1.1\" \/>\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!\" \/>\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'e tootlikkuse t\u00f5stmiseks | ProHoster","description":"Tere k\u00f5igile!","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!","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","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\/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}]}}