🥇Carane ngakses sumber daya Pod Kubernetes

Ganjaran dening Tohad

Nalika miwiti karo Kubernetes, iku umume lali babagan nyetel sumber daya wadhah. Ing titik iki, cukup kanggo mesthekake yen gambar Docker bisa digunakake lan bisa disebarake menyang kluster Kubernetes.

Nanging mengko aplikasi kasebut kudu disebarake ing kluster produksi bebarengan karo aplikasi liyane. Kanggo nindakake iki, sampeyan kudu nyedhiakke sumber daya kanggo wadhah lan priksa manawa ana cukup kanggo njaluk aplikasi munggah lan mlaku, lan aplikasi liyane mlaku ora bakal nemu masalah.

tim Kubernetes aaS saka Mail.ru nerjemahake artikel babagan sumber daya wadhah (CPU & MEM), panjalukan lan watesan sumber. Sampeyan bakal sinau keuntungan saka setelan kasebut lan apa sing kedadeyan yen sampeyan ora nyetel.

Sumber daya komputasi

Kita duwe rong jinis sumber daya kanthi unit ing ngisor iki:

Unit pangolahan pusat (CPU) - inti;
Memori (MEM) - bita.

Sumber daya ditemtokake kanggo saben wadhah. Ing file Pod YAML ing ngisor iki, sampeyan bakal weruh bagean sumber daya sing ngemot sumber daya sing dijaluk lan watesan:

Sumber Daya Pod Dijaluk = jumlah sumber daya sing dijaluk saka kabeh wadhah;
Watesan Sumber Daya Pod = Jumlah kabeh Watesan Sumber Daya Pod.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

Tuladha Sumber Daya Dijaluk lan Diwatesi

lapangan resources.requested saka spesifikasi Pod minangka salah sawijining unsur sing digunakake kanggo nemokake simpul sing dikarepake. Sampeyan wis bisa ngrancang penyebaran Pod kasebut. Kepiye carane nemokake simpul sing cocog?

Kubernetes kasusun saka sawetara komponen, kalebu master node utawa master node (Kubernetes Control Plane). Node master nduweni sawetara proses: kube-apiserver, kube-controller-manager lan kube-scheduler.

Proses kube-scheduler tanggung jawab kanggo mriksa polong sing mentas digawe lan nemokake kemungkinan node pekerja sing cocog karo kabeh panjaluk pod, kalebu jumlah sumber daya sing dijaluk. Dhaptar simpul sing ditemokake dening kube-scheduler diwenehi peringkat. Pod dijadwalake ing simpul kanthi skor paling dhuwur.

Ing endi bakal diselehake Pod ungu?

Ing gambar sampeyan bisa ndeleng manawa kube-scheduler kudu gawe jadwal Pod ungu anyar. Kluster Kubernetes ngandhut loro kelenjar: A lan B. Nalika sampeyan bisa ndeleng, kube-scheduler ora bisa gawe jadwal Pod ing simpul A - kasedhiya (unrequested) sumber daya ora cocog panjalukan saka Pod ungu. Dadi, memori 1 GB sing dijaluk Pod ungu ora cocog karo simpul A, amarga memori sing kasedhiya yaiku 0,5 GB. Nanging simpul B nduweni sumber daya sing cukup. Akibate, kube-scheduler mutusake yen tujuan Pod ungu yaiku simpul B.

Saiki kita ngerti kepiye sumber daya sing dijaluk mengaruhi pilihan simpul kanggo mbukak Pod. Nanging apa pengaruh sumber daya marginal?

Watesan sumber minangka wates sing ora bisa dilewati CPU / MEM. Nanging, sumber daya CPU fleksibel, saengga wadhah sing tekan watesan CPU ora bakal nyebabake Pod metu. Nanging, throttling CPU bakal diwiwiti. Yen watesan panggunaan MEM tekan, wadhah bakal mandheg amarga OOM-Killer lan diwiwiti maneh yen diijini dening setelan RestartPolicy.

Dijaluk lan sumber daya maksimum ing rinci

Komunikasi sumber daya antarane Docker lan Kubernetes

Cara paling apik kanggo nerangake carane panjaluk sumber daya lan watesan sumber daya bisa ditindakake yaiku ngenalake hubungan antarane Kubernetes lan Docker. Ing gambar ing ndhuwur sampeyan bisa ndeleng kepiye hubungane lapangan Kubernetes lan panji wiwitan Docker.

Memori: panyuwunan lan watesan

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

Kaya kasebut ing ndhuwur, memori diukur ing bita. Adhedhasar Dokumentasi Kubernetes, kita bisa nemtokake memori minangka nomer. Biasane iku integer, contone 2678 - sing, 2678 bita. Sampeyan uga bisa nggunakake suffix G и Gi, sing utama yaiku elinga yen ora padha. Kapisan desimal lan kaloro biner. Kaya conto sing kasebut ing dokumentasi k8s: 128974848, 129e6, 129M, 123Mi - padha sacoro prakteke padha.

Pilihan Kubernetes limits.memory cocog gendera --memory saka Docker. Ing kasus saka request.memory Ora ana panah kanggo Docker amarga Docker ora nggunakake lapangan iki. Sampeyan bisa uga takon, apa iki perlu? Ya perlu. Kaya sing dakkandhakake sadurunge, lapangan penting kanggo Kubernetes. Adhedhasar informasi kasebut, kube-scheduler mutusake simpul sing bakal dijadwalake Pod.

Apa sing kedadeyan yen sampeyan nyetel memori sing ora cukup kanggo panjaluk?

Yen wadhah wis tekan watesan memori sing dijaluk, banjur Pod diselehake ing klompok Pod sing mandheg nalika ora cukup memori ing simpul.

Apa sing kedadeyan yen sampeyan nyetel watesan memori sithik banget?

Yen wadhah ngluwihi watesan memori, iku bakal mungkasi amarga OOM-Killed. Lan bakal miwiti maneh yen bisa adhedhasar RestartPolicy ing ngendi nilai standar kasebut Always.

Apa sing kedadeyan yen sampeyan ora nemtokake memori sing dijaluk?

Kubernetes bakal njupuk nilai watesan lan nyetel minangka nilai standar.

Apa bisa kedadeyan yen sampeyan ora nemtokake watesan memori?

Wadhah kasebut ora ana watesan; bisa nggunakake memori kaya sing dikarepake. Yen dheweke wiwit nggunakake kabeh memori sing kasedhiya saka simpul, banjur OOM bakal matèni wong. Wadhah kasebut banjur bakal diwiwiti maneh yen bisa adhedhasar RestartPolicy.

Apa sing kedadeyan yen sampeyan ora nemtokake watesan memori?

Iki minangka skenario paling awon: panjadwal ora ngerti jumlah sumber daya sing dibutuhake, lan iki bisa nyebabake masalah serius ing simpul. Ing kasus iki, luwih becik duwe watesan standar ing ruang jeneng (diset dening LimitRange). Ora ana watesan standar - Pod ora ana watesan, bisa nggunakake memori kaya sing dikarepake.

Yen memori sing dijaluk luwih saka simpul bisa menehi, Pod ora bakal dijadwal. Iku penting kanggo elinga Requests.memory - ora nilai minimal. Iki minangka gambaran saka jumlah memori sing cukup kanggo njaga wadhah sing terus-terusan.

Biasane dianjurake kanggo nyetel nilai sing padha kanggo request.memory и limit.memory. Iki mesthekake yen Kubernetes ora bakal gawe jadwal Pod ing simpul sing duwe memori cukup kanggo mbukak Pod nanging ora cukup kanggo mbukak. Tetep wonten ing pikiran: Kubernetes Pod planning mung njupuk menyang akun requests.memorylan limits.memory ora njupuk menyang akun.

CPU: request lan watesan

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

Kanthi CPU kabeh iku sethitik liyane rumit. Bali menyang gambar hubungan antarane Kubernetes lan Docker, sampeyan bisa ndeleng request.cpu соответствует --cpu-shares, dene limit.cpu cocog gendera cpus ing Docker.

CPU sing dijaluk Kubernetes dikali 1024, proporsi siklus CPU. Yen sampeyan pengin njaluk 1 inti lengkap, sampeyan kudu nambah cpu: 1kaya sing dituduhake ing ndhuwur.

Njaluk kernel lengkap (proporsi = 1024) ora ateges wadhah sampeyan bakal nampa. Yen mesin host sampeyan mung duwe siji inti lan sampeyan mbukak luwih saka siji wadhah, mula kabeh wadhah kudu nuduhake CPU sing kasedhiya ing antarane. Kepiye kedadeyan iki? Ayo dideleng ing gambar.

Panjaluk CPU - Sistem Inti Tunggal

Ayo mbayangno yen sampeyan duwe sistem host siji-inti sing mbukak wadhah. Ibu (Kubernetes) panggang kue (CPU) lan pengin dibagi antarane bocah-bocah (wadhah). Bocah telu pengin pai kabeh (proporsi = 1024), bocah liyane pengin kue setengah (512). Ibu kepengin adil lan nggawe petungan sing gampang.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

Adhedhasar pitungan, telung bocah bakal nampa 28% saka inti, lan ora kabeh inti. Anak kaping papat bakal entuk 14% saka kernel lengkap, ora setengah. Nanging bakal beda yen sampeyan duwe sistem multi-inti.

Panjaluk CPU - Sistem Multi-Core (4).

Ing gambar ing ndhuwur sampeyan bisa ndeleng manawa bocah telu pengin kue kabeh, lan siji pengin setengah. Wiwit ibune nggawe pai papat, saben anak bakal entuk akeh sing dikarepake. Ing sistem multi-inti, sumber daya prosesor disebarake ing kabeh inti prosesor sing kasedhiya. Yen wadhah diwatesi kurang saka siji inti CPU lengkap, isih bisa digunakake ing 100%.

Petungan ndhuwur wis simplified kanggo ngerti carane CPU disebarake antarane kontaner. Mesthi, saliyane wadhah kasebut, ana proses liyane sing uga nggunakake sumber daya CPU. Nalika pangolahan ing siji wadhah ora aktif, wong liya bisa nggunakake sumber daya. CPU: "200m" соответствует CPU: 0,2, sing tegese kira-kira 20% saka siji inti.

Saiki ayo ngomong babagan limit.cpu. CPU sing diwatesi Kubernetes dikali 100. Asil kasebut yaiku jumlah wektu sing bisa digunakake wadhah saben 100 µs (cpu-period).

limit.cpu cocog flag Docker --cpus. Iki minangka kombinasi anyar saka lawas --cpu-period и --cpu-quota. Kanthi nyetel, kita nuduhake jumlah sumber daya CPU sing kasedhiya sing bisa digunakake kanthi maksimal sadurunge throttling diwiwiti:

bosus - kombinasi cpu-period и cpu-quota. cpus = 1.5 padha karo setelan cpu-period = 100000 и cpu-quota = 150000;
CPU-wektu - periode Penjadwal CPU CFS, standar 100 mikrodetik;
cpu-kuota - nomer microseconds nang cpu-period, sing diwatesi karo wadhah.

Apa sing kedadeyan yen sampeyan nginstal CPU sing ora cukup?

Yen wadhah mbutuhake luwih saka sing wis diinstal, bakal nyolong CPU saka proses liyane.

Apa sing kedadeyan yen sampeyan nyetel watesan CPU sithik banget?

Amarga sumber daya CPU bisa diatur, throttling bakal diuripake.

Apa sing kedadeyan yen sampeyan ora nemtokake panjalukan CPU?

Minangka memori, nilai panjalukan padha karo watesan.

Apa sing kedadeyan yen sampeyan ora nemtokake watesan CPU?

Wadhah kasebut bakal nggunakake CPU kaya sing dibutuhake. Yen kabijakan CPU standar (LimitRange) ditetepake ing ruang jeneng, banjur watesan iki uga digunakake kanggo wadhah kasebut.

Apa sing kedadeyan yen sampeyan ora nemtokake panjalukan utawa watesan CPU?

Kaya memori, iki minangka skenario paling ala. Penjadwal ora ngerti jumlah sumber daya sing dibutuhake, lan iki bisa nyebabake masalah serius ing simpul. Kanggo ngindhari iki, sampeyan kudu nyetel watesan standar kanggo spasi jeneng (LimitRange).

Elingi: yen sampeyan njaluk CPU luwih saka simpul bisa nyedhiyani, Pod ora bakal dijadwal. Requests.cpu - ora Nilai minimal, nanging nilai cukup kanggo miwiti Pod lan bisa tanpa gagal. Yen aplikasi ora nindakake petungan rumit, pilihan sing paling apik yaiku nginstal request.cpu <= 1 lan miwiti minangka akeh replika minangka needed.

Jumlah becik sumber daya utawa watesan sumber daya

Kita sinau babagan watesan sumber daya komputasi. Saiki wektune kanggo mangsuli pitakon: "Pinten sumber daya sing dibutuhake Pod kanggo mbukak aplikasi tanpa masalah? Apa jumlah becik?

Sayange, ora ana jawaban sing jelas kanggo pitakonan kasebut. Yen sampeyan ora ngerti cara aplikasi sampeyan bisa digunakake utawa pira CPU utawa memori sing dibutuhake, pilihan sing paling apik yaiku menehi aplikasi akeh memori lan CPU banjur mbukak tes kinerja.

Saliyane tes kinerja, ngawasi prilaku aplikasi sajrone ngawasi seminggu. Yen grafik nuduhake yen aplikasi sampeyan nggunakake sumber daya luwih sithik tinimbang sing dijaluk, sampeyan bisa nyuda jumlah CPU utawa memori sing dijaluk.

Minangka conto ndeleng iki Dashboard Grafana. Nampilake prabédan antarane sumber daya sing dijaluk utawa watesan sumber daya lan panggunaan sumber daya saiki.

kesimpulan

Njaluk lan matesi sumber daya mbantu supaya kluster Kubernetes tetep sehat. Konfigurasi watesan sing tepat nyilikake biaya lan supaya aplikasi tetep mlaku.

Ing ringkesan, ana sawetara perkara sing kudu dielingake:

Sumber daya sing dijaluk minangka konfigurasi sing dianggep nalika wiwitan (nalika Kubernetes ngrancang kanggo dadi tuan rumah aplikasi kasebut). Ing kontras, matesi sumber daya penting nalika runtime-nalika aplikasi wis mlaku ing simpul.
Dibandhingake karo memori, CPU minangka sumber daya sing diatur. Yen CPU ora cukup, Pod sampeyan ora bakal mati lan mekanisme throttling bakal urip.
Sumber daya sing dijaluk lan watesan sumber daya dudu nilai minimal lan maksimal! Kanthi nemtokake sumber daya sing dijaluk, sampeyan mesthekake yen aplikasi bakal mbukak tanpa masalah.
Praktek sing apik yaiku nyetel panjalukan memori sing padha karo watesan memori.
Ok instal dijaluk CPU <=1, yen aplikasi ora nindakake petungan rumit.
Yen sampeyan njaluk sumber daya luwih akeh tinimbang sing kasedhiya ing simpul, Pod ora bakal dijadwalake menyang simpul kasebut.
Kanggo nemtokake jumlah sing bener saka watesan sumber daya / sumber daya, nggunakake testing mbukak lan ngawasi.

Muga-muga artikel iki mbantu sampeyan ngerti konsep dhasar watesan sumber daya. Lan sampeyan bakal bisa nggunakake kawruh iki ing karya.

Good luck!

Apa maneh sing kudu diwaca:

Source: www.habr.com

Carane ngakses sumber daya Kubernetes Pod