🥇Kubernetes ish faoliyatini yaxshilash bo‘yicha to‘qqizta maslahat

Hammaga salom! Mening ismim Oleg Sidorenkov, men DomClick-da infratuzilma bo'yicha guruh rahbari sifatida ishlayman. Biz Cubedan uch yildan ortiq vaqtdan beri sotuvda foydalanamiz va shu vaqt ichida u bilan turli xil qiziqarli daqiqalarni boshdan kechirdik. Bugun men sizga qanday qilib to'g'ri yondashuv bilan klasteringiz uchun vanil Kubernetesdan ko'proq unumdorlikni siqib chiqarishingiz mumkinligini aytaman. Doim harakatga tayyor!

Siz hammangiz yaxshi bilasizki, Kubernetes konteyner orkestratsiyasi uchun kengaytiriladigan ochiq kodli tizimdir; yaxshi yoki server muhitida mikroservislaringizning hayot aylanishini boshqarish orqali sehrgarlik qiladigan 5 ta ikkilik. Bundan tashqari, bu juda moslashuvchan vosita bo'lib, uni turli vazifalar uchun maksimal moslashtirish uchun Lego konstruktori kabi yig'ish mumkin.

Va hamma narsa yaxshi ko'rinadi: serverlarni klasterga tashlang, o'tin kabi olov qutisiga va qayg'uni bilmang. Ammo agar siz atrof-muhit uchun bo'lsangiz, unda siz shunday deb o'ylaysiz: "Qanday qilib pechkada olovni ushlab turishim va o'rmonga pushaymon bo'lishim mumkin?". Boshqacha qilib aytganda, infratuzilmani yaxshilash va xarajatlarni kamaytirish yo'llarini qanday topish mumkin.

1. Jamoa va dastur resurslarini kuzatib boring

Eng keng tarqalgan, ammo samarali usullardan biri so'rovlar/cheklovlarni joriy qilishdir. Ilovalarni nomlar bo'shliqlari va nomlar bo'shliqlarini ishlab chiqish guruhlari bo'yicha ajrating. Protsessor vaqtini, xotirani, vaqtinchalik saqlashni iste'mol qilish uchun qiymatlarni o'rnatishdan oldin dasturni o'rnating.

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

Tajriba orqali biz shunday xulosaga keldik: chegaralardan so'rovlarni ikki martadan ko'proq oshirmaslik kerak. Klasterning hajmi so'rovlar asosida hisoblab chiqiladi va agar siz ilovalarga resurslardagi farqni, masalan, 5-10 marta bersangiz, u holda tuguningiz podalar bilan to'ldirilganda va to'satdan yuk olganida nima bo'lishini tasavvur qiling. Hech narsa yaxshi emas. Eng kamida, tejamkorlik va maksimal darajada, siz ishchi bilan xayrlashasiz va podalar harakatlana boshlagandan so'ng, qolgan tugunlarda tsiklik yuk olasiz.

Bundan tashqari, yordam bilan limitranges Siz konteyner uchun manba qiymatlarini boshida o'rnatishingiz mumkin - minimal, maksimal va standart:

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

Bir buyruq klasterning barcha resurslarini qabul qila olmasligi uchun nomlar maydoni resurslarini cheklashni unutmang:

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

Ta'rifdan ko'rinib turibdiki resourcequotas, agar ops buyrug'i yana 10 protsessorni iste'mol qiladigan podlarni o'rnatmoqchi bo'lsa, rejalashtiruvchi buni amalga oshirishga ruxsat bermaydi va xato qiladi:

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

Shunga o'xshash muammoni hal qilish uchun siz vositani yozishingiz mumkin, masalan, kabi bu, bu buyruq resurslari holatini saqlashi va topshirishi mumkin.

2. Eng yaxshi fayl xotirasini tanlang

Bu erda men doimiy hajmlar mavzusiga va Kubernetes ishchi tugunlarining disk quyi tizimiga to'xtalmoqchiman. Umid qilamanki, ishlab chiqarishda HDD-da hech kim "Cube" dan foydalanmaydi, lekin ba'zida oddiy SSD ham etarli emas. Biz shunday muammoga duch keldikki, jurnallar kirish-chiqarish operatsiyalari orqali diskni o'ldiradi va bu erda juda ko'p echimlar mavjud emas:

Yuqori unumdor SSD-lardan foydalaning yoki NVMe-ga o'ting (agar siz o'zingizning uskunangizni boshqarsangiz).
Ro'yxatga olish darajasini pasaytiring.
Diskni zo'rlaydigan podkalarni "aqlli" muvozanatlashtiring (podAntiAffinity).

Yuqoridagi skrinshotda access_logs jurnali yoqilganda disk bilan nginx-ingress-controller ostida nima sodir bo'lishi ko'rsatilgan (~12k logs/sek). Bunday holat, albatta, ushbu tugundagi barcha ilovalarning degradatsiyasiga olib kelishi mumkin.

PVga kelsak, afsuski, men hamma narsani sinab ko'rmadim turlari Doimiy hajmlar. Sizga mos keladigan eng yaxshi variantdan foydalaning. Tarixan, bizning mamlakatimizda xizmatlarning kichik bir qismi RWX hajmlarini talab qilishi sodir bo'ldi va uzoq vaqt oldin ular bu vazifa uchun NFS xotirasidan foydalanishni boshladilar. Arzon va... yetarli. Albatta, u va men bo'kni yedik - baraka topamiz, lekin biz uni sozlashni o'rgandik va boshim endi og'rimaydi. Va iloji bo'lsa, S3 ob'ekt xotirasiga o'ting.

3. Optimallashtirilgan tasvirlarni yaratish

Kubernetes ularni tezroq olishi va ularni samaraliroq bajarishi uchun konteyner uchun optimallashtirilgan tasvirlardan foydalanish yaxshidir.

Optimallashtirish tasvirlarni anglatadi:

faqat bitta dasturni o'z ichiga oladi yoki faqat bitta funktsiyani bajaradi;
kichik o'lchamlar, chunki katta tasvirlar tarmoq orqali yomonroq uzatiladi;
Kubernetes ishlamay qolganda chora ko'rish uchun foydalanishi mumkin bo'lgan sog'liq va tayyorlik so'nggi nuqtalariga ega bo'ling;
konfiguratsiya xatolariga nisbatan ancha chidamli konteynerga mos operatsion tizimlardan (masalan, Alpine yoki CoreOS) foydalaning;
ko'p bosqichli tuzilmalardan foydalaning, shunda siz qo'shilgan manbalarni emas, balki faqat kompilyatsiya qilingan ilovalarni o'rnatishingiz mumkin.

Tasvirlarni tezda tekshirish va optimallashtirish imkonini beruvchi ko'plab vositalar va xizmatlar mavjud. Ularni doimo yangilab turish va xavfsiz saqlash muhimdir. Natijada siz quyidagilarni olasiz:

Butun klasterda tarmoq yukini kamaytirish.
Konteynerni ishga tushirish vaqti qisqardi.
Butun Docker registringizning kichikroq hajmi.

4. DNS keshidan foydalaning

Agar biz yuqori yuklar haqida gapiradigan bo'lsak, unda klasterning DNS tizimini sozlamasdan, hayot juda yomon. Bir vaqtlar Kubernetes ishlab chiquvchilari kube-dns yechimini qo'llab-quvvatlaganlar. Bu bizning mamlakatimizda ham amalga oshirildi, ammo bu dastur unchalik mos kelmadi va kerakli ishlashni bermadi, garchi vazifa oddiy ko'rinadi. Keyin korednlar paydo bo'ldi, biz unga o'tdik va qayg'uni bilmasdik, keyinchalik u K8-larda standart DNS xizmatiga aylandi. Bir nuqtada biz DNS tizimiga 40 ming rpsgacha o'sdik va bu yechim ham etarli emas edi. Lekin, omadli tasodif bilan Nodelocaldns chiqdi, aka tugun mahalliy keshi, aka NodeLocal DNSCache.

Nima uchun biz undan foydalanamiz? Linux yadrosida xatolik mavjud bo'lib, u UDP orqali NAT-ni ulash orqali bir necha marta kirishda ulanish jadvallariga yozish uchun poyga holatiga olib keladi va NAT orqali trafikning bir qismi yo'qoladi (Hizmat orqali har bir safar NAT). Nodelocaldns bu muammoni NAT-dan xalos bo'lish va yuqori oqim DNS-ga TCP ulanishini yangilash, shuningdek yuqori oqim DNS so'rovlarini lokal ravishda keshlash (shu jumladan qisqa 5 soniya salbiy kesh) orqali hal qiladi.

5. Podkalarni gorizontal va vertikal ravishda avtomatik ravishda masshtablash

Ishonch bilan ayta olasizmi, barcha mikroservislaringiz yukni ikki-uch baravar oshirishga tayyor? Ilovalaringizga resurslarni qanday qilib to'g'ri taqsimlash kerak? Bir nechta podkastlarni ish yukidan tashqarida ushlab turish ortiqcha bo'lishi mumkin, ammo ularni orqaga qarab ushlab turish xizmatga traffikning to'satdan ko'payishi tufayli to'xtab qolish xavfini tug'diradi. kabi xizmatlar Gorizontal Pod Autoscaler и Vertical Pod Autoscaler.

VPA haqiqiy foydalanish asosida konteynerlaringizning so'rovlarini/cheklarini avtomatik ravishda oshirish imkonini beradi. Qanday qilib foydali bo'lishi mumkin? Agar sizda biron sababga ko'ra gorizontal ravishda kengaytirib bo'lmaydigan Podlar bo'lsa (bu mutlaqo ishonchli emas), uning resurslarini o'zgartirish uchun VPA-ga ishonishga harakat qilishingiz mumkin. Uning xususiyati metrik-serverdan olingan tarixiy va joriy ma'lumotlarga asoslangan tavsiyalar tizimidir, shuning uchun agar siz so'rovlarni/cheklovlarni avtomatik ravishda o'zgartirishni xohlamasangiz, shunchaki konteynerlaringiz uchun tavsiya etilgan resurslarni kuzatishingiz va protsessor va xotirani tejash uchun sozlamalarni optimallashtirishingiz mumkin. klasterda.

Rasm https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 dan olingan

Kubernetesdagi rejalashtiruvchi har doim so'rovlarga asoslanadi. U erda qanday qiymat qo'ysangiz ham, rejalashtiruvchi unga asoslangan mos tugunni qidiradi. Limit qiymati kubletga podni qachon bostirish yoki o'ldirish kerakligini bilish uchun kerak. Va yagona muhim parametr so'rovlar qiymati bo'lgani uchun VPA u bilan ishlaydi. Ilovangizni vertikal ravishda o'lchaganingizda, qanday so'rovlar bo'lishi kerakligini aniqlaysiz. Va keyin chegaralar bilan nima sodir bo'ladi? Ushbu parametr ham mutanosib ravishda o'lchanadi.

Misol uchun, bu erda odatiy pod sozlamalari:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

Tavsiya mexanizmi ilovangiz to'g'ri ishlashi uchun 300 m CPU va 500 Mi kerakligini aniqlaydi. Siz ushbu sozlamalarni olasiz:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

Yuqorida aytib o'tilganidek, bu manifestdagi so'rovlar/cheklovlar nisbati asosida mutanosib masshtablash:

CPU: 200m → 300m: nisbat 1:1.75;
Xotira: 250Mi → 500Mi: 1:2 nisbat.

Bilan bog'liq HPA, keyin ish mexanizmi yanada shaffof bo'ladi. Protsessor va xotira kabi ko'rsatkichlar uchun chegaralar o'rnatiladi va agar barcha replikatsiyalarning o'rtacha qiymati chegaradan oshsa, qiymat chegaradan pastga tushmaguncha yoki maksimal replika soniga yetguncha dastur +1 pod shkalasi bilan o'rnatiladi.

Rasm https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 dan olingan

Protsessor va xotira kabi odatiy ko'rsatkichlarga qo'shimcha ravishda siz o'zingizning shaxsiy Prometey ko'rsatkichlari uchun chegaralarni o'rnatishingiz va ular bilan ishlashingiz mumkin, agar bu sizning ilovangizni qachon o'lchashni aniqlashning eng to'g'ri usuli deb hisoblasangiz. Ilova belgilangan metrik chegaradan pastroqda barqarorlashgandan so'ng, HPA Podlarni minimal nusxalar soniga yoki yuk chegaraga to'g'ri kelguniga qadar qisqartirishni boshlaydi.

6. Node Affinity va Pod Affinity haqida unutmang

Hamma tugunlar bir xil uskunada ishlamaydi va barcha podkastlar hisoblashni talab qiluvchi ilovalarni ishga tushirishi shart emas. Kubernetes yordamida tugunlar va podkastlarning ixtisoslashuvini belgilash imkonini beradi Tugunga yaqinlik и Podga yaqinlik.

Agar sizda hisoblash intensiv operatsiyalari uchun mos tugunlar bo'lsa, maksimal samaradorlik uchun ilovalarni tegishli tugunlarga bog'lash yaxshiroqdir. Buning uchun foydalaning nodeSelector tugun belgisi bilan.

Aytaylik, sizda ikkita tugun bor: biri bilan CPUType=HIGHFREQ va ko'p sonli tezkor yadrolar, boshqasi bilan MemoryType=HIGHMEMORY ko'proq xotira va tezroq ishlash. Eng oson yo'li - tugunga pod joylashtirishni tayinlash HIGHFREQbo'limga qo'shish orqali spec shunga o'xshash selektor:

…
nodeSelector:
	CPUType: HIGHFREQ

Buni amalga oshirishning qimmatroq va o'ziga xos usuli - foydalanish nodeAffinity dalada affinity razdela spec. Ikkita variant mavjud:

requiredDuringSchedulingIgnoredDuringExecution: qattiq sozlash (rejalashtiruvchi faqat ma'lum tugunlarda podkastlarni joylashtiradi (va boshqa joyda));
preferredDuringSchedulingIgnoredDuringExecution: yumshoq sozlama (rejalashtiruvchi muayyan tugunlarga joylashtirishga harakat qiladi va agar u muvaffaqiyatsiz bo'lsa, keyingi mavjud tugunga joylashtirishga harakat qiladi).

Siz tugun belgilarini boshqarish uchun maxsus sintaksisni belgilashingiz mumkin, masalan, In, NotIn, Exists, DoesNotExist, Gt yoki Lt. Biroq, yorliqlarning uzun ro'yxatidagi murakkab usullar tanqidiy vaziyatlarda qaror qabul qilishni sekinlashtirishini unutmang. Boshqacha qilib aytganda, ortiqcha murakkablashmang.

Yuqorida ta'kidlab o'tilganidek, Kubernetes sizga joriy podslarni bog'lashni o'rnatish imkonini beradi. Ya'ni, siz ma'lum podalar bilan bir xil mavjudlik zonasida (bulutlar uchun tegishli) yoki tugunlarda boshqa podalar bilan birga ishlashini ta'minlashingiz mumkin.

В podAffinity cheklovlar affinity razdela spec misolidagi kabi bir xil maydonlar mavjud nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. Faqatgina farq shundaki matchExpressions podlarni o'sha yorliqli podkastda ishlayotgan tugunga bog'laydi.

Ko'proq Kubernetes maydonni taklif qiladi podAntiAffinity, bu esa, aksincha, podani o'ziga xos podalar bilan tugunga bog'lamaydi.

Ifodalar haqida nodeAffinity xuddi shunday maslahat berilishi mumkin: qoidalarni oddiy va mantiqiy saqlashga harakat qiling, pod spetsifikatsiyasini murakkab qoidalar to'plami bilan ortiqcha yuklashga urinmang. Klaster shartlariga mos kelmaydigan, rejalashtiruvchiga qo'shimcha yuk olib keladigan va umumiy ish faoliyatini yomonlashtiradigan qoida yaratish juda oson.

7. Taints & Tolerations

Rejalashtiruvchini boshqarishning yana bir usuli bor. Agar sizda yuzlab tugunlar va minglab mikroservislar mavjud bo'lgan katta klasteringiz bo'lsa, ba'zi podslarni ma'lum tugunlar tomonidan joylashtirishning oldini olish juda qiyin.

Qoidalarni taqiqlash mexanizmi - bu bilan yordam beradi. Misol uchun, ma'lum bir stsenariylarda ba'zi tugunlarning podlarni ishlashini oldini olishingiz mumkin. Muayyan tugunga bo'yoq qo'llash uchun variantdan foydalaning taint kubectl ichida. Kalit va qiymatni belgilang, so'ngra o'xshashni belgilang NoSchedule yoki NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

Shuni ham ta'kidlash kerakki, ifloslanish mexanizmi uchta asosiy ta'sirni qo'llab-quvvatlaydi: NoSchedule, NoExecute и PreferNoSchedule.

NoSchedule pod spetsifikatsiyasida tegishli yozuv mavjud bo'lmaguncha, degan ma'noni anglatadi tolerations, uni tugunga o'rnatib bo'lmaydi (ushbu misolda node10).
PreferNoSchedule - soddalashtirilgan versiya NoSchedule. Bunday holda, rejalashtiruvchi mos yozuvga ega bo'lmagan podlarni ajratmaslikka harakat qiladi. tolerations har bir tugun uchun, lekin bu qattiq chegara emas. Agar klasterda resurslar bo'lmasa, podlar ushbu tugunga joylasha boshlaydi.
NoExecute - bu ta'sir mos yozuvga ega bo'lmagan podkalarni zudlik bilan evakuatsiya qilishni boshlaydi tolerations.

Qizig'i shundaki, bu xatti-harakatni bardoshlik mexanizmi yordamida bekor qilish mumkin. Bu "taqiqlangan" tugun mavjud bo'lganda qulay va siz unga faqat infratuzilma xizmatlarini joylashtirishingiz kerak. Buni qanday qilish kerak? Faqat tegishli bardoshlik mavjud bo'lgan podlarga ruxsat bering.

Pod spetsifikatsiyasi qanday ko'rinishga ega:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

Bu keyingi qayta joylashtirish paytida pod aynan shu tugunga tegadi degani emas, bu tugunga yaqinlik mexanizmi emas va nodeSelector. Ammo bir nechta xususiyatlarni birlashtirib, siz juda moslashuvchan rejalashtirishni sozlashingiz mumkin.

8. Podni joylashtirish ustuvorligini o'rnating

Pod-to-tugun ulanishlarini sozlaganingiz uchun, bu barcha podkalar bir xil ustuvorlik bilan ishlanishi kerak degani emas. Misol uchun, siz ba'zi podlarni boshqalardan oldin joylashtirishni xohlashingiz mumkin.

Kubernetes Pod Priority va Preemptionni o'rnatishning turli usullarini taklif qiladi. Sozlama bir necha qismlardan iborat: ob'ekt PriorityClass va maydon tavsiflari priorityClassName pod spetsifikatsiyasida. Bir misolni ko'rib chiqing:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

Biz yaratamiz PriorityClass, unga nom, tavsif va qiymat bering. Oliy value, ustuvorlik qanchalik baland. Qiymat 32 1 000 000 dan kichik yoki unga teng boʻlgan har qanday 000 bitli butun son boʻlishi mumkin. Yuqori qiymatlar muhim tizim boʻlaklari uchun ajratilgan, ularni odatda oldindan ajratib boʻlmaydi. Ko'chirish faqat yuqori ustuvor podkastning burilish joyi bo'lmasa sodir bo'ladi, keyin ma'lum bir tugundagi ba'zi podalar evakuatsiya qilinadi. Agar ushbu mexanizm siz uchun juda qattiq bo'lsa, unda siz variantni qo'shishingiz mumkin preemptionPolicy: Never, va keyin hech qanday imtiyoz bo'lmaydi, pod navbatda birinchi bo'ladi va rejalashtiruvchi buning uchun bepul resurslarni topishini kuting.

Keyinchalik, biz podkast yaratamiz, unda biz nomni belgilaymiz priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority

Siz o'zingiz xohlagancha ko'plab ustuvor sinflarni yaratishingiz mumkin, garchi bunga berilmaslik tavsiya etiladi (aytaylik, o'zingizni past, o'rta va yuqori ustuvorlik bilan cheklang).

Shunday qilib, agar kerak bo'lsa, nginx-ingress-controller, coredns va boshqalar kabi muhim xizmatlarni joylashtirish samaradorligini oshirishingiz mumkin.

9. ETCD klasteringizni optimallashtiring

ETCDni butun klasterning miyasi deb atash mumkin. Ushbu ma'lumotlar bazasining ishlashini yuqori darajada ushlab turish juda muhim, chunki "Cube" da operatsiyalar tezligi unga bog'liq. ETCD klasterini kube-apiserverga minimal kechikish uchun asosiy tugunlarda saqlash juda standart va shu bilan birga yaxshi yechim bo'ladi. Agar buning iloji bo'lmasa, ETCD ni iloji boricha yaqinroq, ishtirokchilar o'rtasida yaxshi tarmoqli kengligi bilan joylashtiring. Shuningdek, ETCD ning qancha tugunlari klasterga zarar bermasdan tushishi mumkinligiga e'tibor bering.

Yodda tutingki, klasterdagi ishtirokchilar sonining haddan tashqari ko'payishi ishlash hisobiga xatoga chidamlilikni oshirishi mumkin, hamma narsa me'yorda bo'lishi kerak.

Agar xizmatni sozlash haqida gapiradigan bo'lsak, unda bir nechta tavsiyalar mavjud:

Klaster o'lchamiga asoslangan yaxshi uskunaga ega bo'ling (o'qishingiz mumkin shu yerda).
Agar siz bir juft DC yoki tarmoq o'rtasida klasterni yoygan bo'lsangiz va disklar juda ko'p narsani xohlasa, bir nechta parametrlarni o'zgartiring (o'qishingiz mumkin). shu yerda).

xulosa

Ushbu maqolada bizning jamoamiz rioya qilishga harakat qiladigan fikrlar tasvirlangan. Bu harakatlarning bosqichma-bosqich tavsifi emas, balki klasterning umumiy xarajatlarini optimallashtirish uchun foydali bo'lishi mumkin bo'lgan variantlar. Har bir klaster o'ziga xos tarzda noyob ekanligi aniq va sozlash echimlari juda xilma-xil bo'lishi mumkin, shuning uchun sizdan fikr-mulohazalarni olish qiziqarli bo'ladi: Kubernetes klasteringizni qanday kuzatasiz, uning ish faoliyatini qanday yaxshilaysiz. Tajribangizni sharhlarda baham ko'ring, buni bilish qiziqarli bo'ladi.

Manba: www.habr.com

To'qqiz Kubernetes ishlash bo'yicha maslahatlar