10 Kesalahan Umum Nalika Nggunakake Kubernetes

Cathetan. nerjemahake.: Penulis artikel iki minangka insinyur saka perusahaan Ceko cilik, pipetail. Padha ngatur kanggo sijine bebarengan dhaftar apik saka [kadhangkala banal, nanging isih] masalah banget mencet lan misconceptions related kanggo operasi saka klompok Kubernetes.

Sajrone pirang-pirang taun nggunakake Kubernetes, kita wis nggarap akeh klompok (loro sing dikelola lan ora dikelola - ing GCP, AWS lan Azure). Swara wektu, kita wiwit sok dong mirsani sing sawetara kesalahane terus bola. Nanging, ora ana rasa isin babagan iki: kita wis nindakake paling akeh dhewe!

Artikel kasebut ngemot kesalahan sing paling umum lan uga nyebutake carane mbenerake.

1. Resources: panjalukan lan watesan

Item iki temtunipun pantes manungsa waé paling cedhak lan Panggonan pisanan ing dhaftar.

request CPU biasane salah siji ora kasebut ing kabeh utawa duwe nilai kurang banget (kanggo nyelehake polong ing saben simpul sabisa). Mangkono, simpul dadi overloaded. Sajrone beban dhuwur, daya pangolahan simpul digunakake kanthi lengkap lan beban kerja tartamtu mung nampa apa sing "dijaluk" dening CPU throttling. Iki ndadékaké tambah latensi aplikasi, wektu entek, lan akibat sing ora nyenengake. (Waca liyane babagan iki ing terjemahan anyar liyane: "Watesan CPU lan throttling agresif ing Kubernetes"- kb. transl.)

BestEffort (banget ora dianjurake):

resources: {}

Panjaluk CPU sing sithik banget (banget ora dianjurake):

   resources:
      Requests:
        cpu: "1m"

Ing sisih liya, anané watesan CPU bisa nyebabake siklus jam sing ora wajar kanthi polong, sanajan prosesor simpul ora diisi kanthi lengkap. Maneh, iki bisa nyebabake tambah telat. Kontroversi terus watara parameter CPU CFS kuota ing kernel Linux lan CPU throttling gumantung ing watesan nyetel, uga mateni kuota CFS ... Alas, watesan CPU bisa nimbulaké masalah liyane saka padha bisa ngatasi. Informasi liyane babagan iki bisa ditemokake ing link ing ngisor iki.

Pilihan sing berlebihan (kaluwihan) masalah memori bisa mimpin kanggo masalah luwih gedhe. Tekan watesan CPU mbutuhake nglewati siklus jam, nalika tekan watesan memori mbutuhake mateni pod. Apa sampeyan tau ngamati OOMkill? Ya bener sing kita omongke.

Apa sampeyan pengin nyilikake kemungkinan kedadeyan kasebut? Aja over-allocate memori lan nggunakake QoS Dijamin (Quality of Service) kanthi nyetel panjalukan memori kanggo watesan (kaya ing conto ing ngisor iki). Waca liyane babagan iki ing Henning Jacobs presentations (Lead Engineer ing Zalando).

Burstable (kasempatan luwih dhuwur kanggo OOMkill):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

Dijamin:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

Apa sing bisa mbantu nalika nyetel sumber daya?

Kanthi bantuan saka metrik-server sampeyan bisa ndeleng konsumsi sumber daya CPU saiki lan panggunaan memori dening pods (lan wadhah nang). Paling kamungkinan, sampeyan wis nggunakake. Mung mbukak printah ing ngisor iki:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

Nanging, dheweke mung nuduhake panggunaan saiki. Bisa menehi gambaran kasar babagan urutan gedhene, nanging pungkasane sampeyan butuh sajarah owah-owahan ing metrik liwat wektu (kanggo njawab pitakonan kaya: "Apa beban CPU puncak?", "Apa beban wingi esuk?", lsp). Kanggo iki sampeyan bisa nggunakake Prometheus, DataDog lan piranti liyane. Dheweke mung entuk metrik saka server metrik lan nyimpen, lan pangguna bisa takon lan ngrancang kanthi cocog.

VerticalPodAutoscaler Nanging ngidini otomatisasi proses iki. Iki nglacak riwayat panggunaan CPU lan memori lan nyetel panjalukan lan watesan anyar adhedhasar informasi kasebut.

Nggunakake daya komputasi kanthi efisien dudu tugas sing gampang. Iku kaya muter Tetris kabeh wektu. Yen sampeyan mbayar akeh banget kanggo daya komputasi kanthi konsumsi rata-rata sing sithik (ujare ~ 10%), disaranake ndeleng produk adhedhasar AWS Fargate utawa Kubelet Virtual. Dibangun ing model tagihan tanpa server / bayar saben panggunaan, sing bisa uga luwih murah ing kahanan kasebut.

2. Liveness lan siyap probe

Kanthi gawan, mriksa liveness lan kesiapan ora diaktifake ing Kubernetes. Lan kadhangkala dheweke lali kanggo nguripake ...

Nanging kepiye carane sampeyan bisa miwiti maneh layanan yen ana kesalahan fatal? Lan kepiye carane load balancer ngerti yen polong wis siyap nampa lalu lintas? Utawa bisa nangani lalu lintas luwih akeh?

Tes iki asring bingung karo siji liyane:

• Urip - mriksa "survivability", sing miwiti maneh pod yen gagal;
• Kesiapan - mriksa kesiapan, yen gagal, sambungan pod saka layanan Kubernetes (iki bisa dicenthang nggunakake kubectl get endpoints) lan lalu lintas ora teka nganti mriksa sabanjure rampung kanthi sukses.

Loro-lorone iki mriksa Dilaksanakake sajrone siklus urip POD. Iku penting banget.

A misconception umum yaiku probe kesiapan mung mbukak nalika wiwitan supaya balancer bisa ngerti yen pod wis siap (Ready) lan bisa miwiti ngolah lalu lintas. Nanging, iki mung salah sawijining pilihan kanggo nggunakake.

Liyane iku kamungkinan saka nemokake metu sing lalu lintas ing polong gedhe banget lan overloads iku (utawa pod nindakake petungan intensif sumber daya). Ing kasus iki, mriksa kesiapan mbantu nyuda beban ing pod lan "kelangan" iku. Kasil rampung mriksa kesiapan ing mangsa ngarep ngidini nambah beban ing pod maneh. Ing kasus iki (yen tes kesiapan gagal), kegagalan tes liveness bakal banget kontraproduktif. Napa miwiti maneh pod sing sehat lan kerja keras?

Mulane, ing sawetara kasus, ora ana mriksa sing luwih apik tinimbang ngaktifake parameter sing ora dikonfigurasi kanthi bener. Kaya kasebut ing ndhuwur, yen liveness mriksa salinan mriksa kesiapan, banjur sampeyan ing alangan gedhe. Pilihan sing bisa ditindakake yaiku ngatur mung tes kesiapanlan urip mbebayani ninggalake aside.

Loro-lorone jinis pamriksaan kasebut ora bakal gagal nalika dependensi umum gagal, yen ora, iki bakal nyebabake kacilakan (kaya longsor) kabeh polong. Ing tembung liya, aja cilaka awakmu.

3. LoadBalancer kanggo saben layanan HTTP

Kemungkinan, sampeyan duwe layanan HTTP ing kluster sampeyan sing pengin diterusake menyang jagad njaba.

Yen sampeyan mbukak layanan minangka type: LoadBalancer, controller (gumantung ing panyedhiya layanan) bakal nyedhiyani lan rembugan LoadBalancer external (ora kudu mlaku ing L7, nanging malah ing L4), lan iki bisa mengaruhi biaya (alamat IPv4 statis eksternal, daya komputerisasi, tagihan saben detik. ) amarga kudu nggawe akeh sumber daya kasebut.

Ing kasus iki, iku luwih logis nggunakake siji mbukak balancer external, layanan mbukak minangka type: NodePort. Utawa luwih apik, nggedhekake kaya nginx-ingress-controller (utawa traefik), sing bakal dadi siji-sijine NodePort endpoint gadhah external mbukak balancer lan bakal rute lalu lintas ing kluster nggunakake ingress- sumber daya Kubernetes.

Layanan intra-cluster (mikro) liyane sing sesambungan karo siji liyane bisa "komunikasi" nggunakake layanan kaya KlusterIP lan mekanisme panemuan layanan sing dibangun liwat DNS. Cukup aja nganggo DNS/IP umum, amarga iki bisa nyebabake latensi lan nambah biaya layanan awan.

4. Autoscaling kluster tanpa njupuk menyang akun fitur

Nalika nambahake simpul lan mbusak saka kluster, sampeyan ora kudu ngandelake sawetara metrik dhasar kayata panggunaan CPU ing simpul kasebut. Planning Pod kudu njupuk menyang akun akeh watesan, kayata afinitas pod/node, taint lan toleransi, panjalukan sumber daya, QoS, lsp. Nggunakake autoscaler eksternal sing ora nggatekake nuansa kasebut bisa nyebabake masalah.

Mbayangno sing polong tartamtu kudu dijadwal, nanging kabeh daya CPU kasedhiya dijaluk / disassembled lan polong macet ing negara Pending. Autoscaler eksternal ndeleng beban CPU saiki rata-rata (dudu sing dijaluk) lan ora miwiti ekspansi (skala) - ora nambah simpul liyane. Akibaté, pod iki ora bakal dijadwal.

Ing kasus iki, mbalikke skala (skala in) - njabut simpul saka kluster tansah luwih angel kanggo ngleksanakake. Mbayangno yen sampeyan duwe pod stateful (kanthi panyimpenan terus-terusan disambungake). Volume terus-terusan biasane duweke zona kasedhiyan tartamtu lan ora ditiru ing wilayah kasebut. Mangkono, yen autoscaler eksternal mbusak simpul karo pod iki, panjadwal ora bakal bisa gawe jadwal pod iki ing simpul liyane, amarga iki mung bisa rampung ing zona kasedhiyan ngendi panyimpenan terus-terusan dumunung. Pod bakal macet ing negara Pending.

Banget populer ing komunitas Kubernetes cluster-autoscaler. Iku mlaku ing kluster, ndhukung API saka panyedhiya maya utama, njupuk menyang akun kabeh Watesan lan bisa ukuran ing kasus ndhuwur. Sampeyan uga bisa nggedhekake nalika njaga kabeh watesan sing disetel, saéngga ngirit dhuwit (sing bakal digunakake kanggo kapasitas sing ora digunakake).

5. Nglirwakake kemampuan IAM / RBAC

Ati-ati nggunakake pangguna IAM karo rahasia ngengkel kanggo mesin lan aplikasi. Ngatur akses sementara nggunakake peran lan akun layanan (Akun layanan).

Kita asring nemoni kasunyatan manawa kunci akses (lan rahasia) dikodekake hardcode ing konfigurasi aplikasi, uga nglirwakake rotasi rahasia sanajan duwe akses menyang Cloud IAM. Gunakake peran lan akun layanan IAM tinimbang pangguna yen cocog.

Lali babagan kube2iam lan langsung menyang peran IAM kanggo akun layanan (kaya sing diterangake ing cathetan saka jeneng sing padha Štěpán Vraný):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

Siji anotasi. Ora angel, ta?

Uga, aja menehi hak istimewa kanggo akun layanan lan profil conto admin и cluster-adminyen dheweke ora butuh. Iki sethitik liyane angel kanggo ngleksanakake, utamané ing RBAC K8s, nanging mesthi worth gaweyan.

6. Aja ngandelake anti-afinitas otomatis kanggo pods

Mbayangno yen sampeyan duwe telung replika saka sawetara penyebaran ing simpul. Node tiba, lan bebarengan karo kabeh replika. Kahanan sing ora nyenengake, ta? Nanging kenapa kabeh replika ing simpul sing padha? Apa ora Kubernetes mesthine nyedhiyakake kasedhiyan dhuwur (HA)?!

Sayange, panjadwal Kubernetes, kanthi inisiatif dhewe, ora tundhuk karo aturan eksistensi sing kapisah (anti afinitas) kanggo polong. Padha kudu diterangake kanthi jelas:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

Mekaten. Saiki pod bakal dijadwalake ing macem-macem simpul (kondisi iki mung dicenthang sajrone jadwal, nanging ora sajrone operasi - mula requiredDuringSchedulingIgnoredDuringExecution).

Ing kene kita ngomong babagan podAntiAffinity ing macem-macem node: topologyKey: "kubernetes.io/hostname", - lan ora bab zona kasedhiyan beda. Kanggo ngleksanakake HA lengkap, sampeyan kudu digali luwih jero menyang topik iki.

7. Nglirwakake PodDisruptionBudgets

Bayangake sampeyan duwe beban produksi ing kluster Kubernetes. Secara periodik, simpul lan kluster dhewe kudu dianyari (utawa dibubarake). PodDisruptionBudget (PDB) kaya perjanjian jaminan layanan antarane administrator kluster lan pangguna.

PDB ngidini sampeyan ngindhari gangguan layanan sing disebabake kekurangan node:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

Ing conto iki, sampeyan, minangka pangguna kluster, nyatakake marang admin: "Hei, aku duwe layanan zookeeper, lan apa wae sing sampeyan lakoni, aku pengin duwe paling ora 2 replika layanan iki tansah kasedhiya."

Sampeyan bisa maca liyane babagan iki kene.

8. Multiple pangguna utawa lingkungan ing kluster umum

Kubernetes namespaces (spasi jeneng) ora nyedhiyakake insulasi sing kuwat.

Kesalahpahaman sing umum yaiku yen sampeyan masang beban non-prod menyang siji ruang jeneng lan mbukak prod menyang liyane, banjur padha ora bakal mengaruhi saben liyane ing sembarang cara... Nanging, tingkat isolasi tartamtu bisa digayuh kanthi nggunakake panjalukan / watesan sumber daya, nyetel kuota, lan nyetel priorityClasses. Sawetara isolasi "fisik" ing bidang data diwenehake dening afinitas, toleransi, taint (utawa nodeselectors), nanging pemisahan kasebut cukup atos ngleksanakake.

Sing kudu nggabungake loro jinis beban kerja ing kluster sing padha kudu ngatasi kerumitan. Yen ora ana perlu kuwi, lan sampeyan bisa saged kanggo duwe siji kluster maneh (ngomong, ing awan umum), banjur luwih becik nglakoni. Iki bakal entuk tingkat insulasi sing luwih dhuwur.

9. externalTrafficPolicy: Cluster

Kerep banget kita ndeleng manawa kabeh lalu lintas ing kluster kasebut liwat layanan kaya NodePort, sing kabijakan standar disetel externalTrafficPolicy: Cluster... Iku tegese NodePort mbukak ing saben simpul ing kluster, lan sampeyan bisa nggunakake sembarang kanggo sesambungan karo layanan sing dikarepake (set pods).

Ing wektu sing padha, polong nyata sing ana gandhengane karo layanan NodePort sing kasebut ing ndhuwur biasane mung kasedhiya ing tartamtu subset saka simpul kasebut. Kanthi tembung liyane, yen aku nyambung menyang simpul sing ora duwe pod sing dibutuhake, bakal nerusake lalu lintas menyang simpul liyane, nambah hop lan nambah latensi (yen node dumunung ing zona kasedhiyan / pusat data sing beda, latensi bisa cukup dhuwur; Kajaba iku, biaya lalu lintas egress bakal mundhak).

Ing tangan liyane, yen layanan Kubernetes tartamtu wis pesawat privasi externalTrafficPolicy: Local, banjur NodePort mbukak mung ing simpul kasebut ing ngendi pods sing dibutuhake bener-bener mlaku. Nalika nggunakake imbangan mbukak external sing mriksa negara (pemeriksaan kesehatan) titik pungkasan (carane AWS ELB), Dheweke bakal ngirim lalu lintas mung kanggo simpul perlu, kang bakal duwe efek ono gunane ing telat, kabutuhan komputerisasi, egress tagihan (lan akal sehat dictates padha).

Ana kemungkinan gedhe sampeyan wis nggunakake kaya traefik utawa nginx-ingress-controller minangka titik pungkasan NodePort (utawa LoadBalancer, sing uga nggunakake NodePort) kanggo rute lalu lintas ingress HTTP, lan nyetel pilihan iki bisa Ngartekno nyuda latensi kanggo panjalukan kuwi.

В publikasi iki Sampeyan bisa mangerteni sing luwih lengkap babagan externalTrafficPolicy, kaluwihan lan cacat.

10. Aja diikat menyang klompok lan aja nyiksa pesawat kontrol

Sadurunge, biasane nelpon server kanthi jeneng sing tepat: Anton, HAL9000 lan Colossus ... Dina iki wis diganti dening pengenal kui acak. Nanging, pakulinan kasebut tetep, lan saiki jeneng sing cocog menyang klompok.

Crita khas (adhedhasar acara nyata): kabeh diwiwiti kanthi bukti konsep, mula kluster kasebut duwe jeneng bangga testing… Taun-taun wis liwati lan isih digunakake ing produksi, lan kabeh wong wedi nyentuh.

Ora ana sing nyenengake babagan kluster sing dadi kewan, mula disaranake mbusak kanthi periodik nalika latihan Recovery bilai (iki bakal mbantu chaos engineering - kira-kira. transl.). Kajaba iku, ora bakal lara kanggo nggarap lapisan kontrol (pesawat kontrol). Wedi kanggo ndemek dheweke dudu tandha apik. lsp mati? Wong lanang, sampeyan pancen ana masalah!

Ing tangan liyane, sampeyan ora kudu digawa adoh karo manipulating iku. Kanthi wektu lapisan kontrol bisa dadi alon. Paling kamungkinan, iki amarga akeh obyek sing digawe tanpa rotasi (kahanan umum nalika nggunakake Helm karo setelan gawan, kang kok negara ing configmaps/rahasia ora dianyari - minangka asil, ewu obyek nglumpukake ing. lapisan kontrol) utawa kanthi panyuntingan obyek kube-api (kanggo skala otomatis, kanggo CI / CD, kanggo ngawasi, log acara, pengontrol, lsp).

Kajaba iku, disaranake mriksa perjanjian SLA / SLO karo panyedhiya Kubernetes sing dikelola lan nggatekake jaminan kasebut. Vendor bisa njamin kasedhiyan lapisan kontrol (utawa subkomponen sawijining), nanging ora wektu tundha p99 panjalukan sing dikirim menyang. Ing tembung liyane, sampeyan bisa mlebu kubectl get nodes, lan nampa jawaban mung sawise 10 menit, lan iki ora bakal nglanggar syarat-syarat persetujuan layanan.

11. Bonus: nggunakake tag paling anyar

Nanging iki wis klasik. Akhir-akhir iki kita wis nemoni teknik iki kurang asring, amarga akeh sing wis sinau saka pengalaman pait, wis mandheg nggunakake tag :latest lan miwiti pinning versi. Hore!

ECR njaga immutability saka tag gambar; Disaranake sampeyan familiarize dhewe karo fitur sing luar biasa iki.

Ringkesan

Aja nyana kabeh bisa sewengi: Kubernetes dudu panacea. Aplikasi ala bakal tetep kaya iki sanajan ing Kubernetes (lan mbokmenawa bakal dadi luwih elek). Carelessness bakal mimpin kanggo kerumitan gedhe banget, karya alon lan ngepenakke saka lapisan kontrol. Kajaba iku, sampeyan duwe risiko ditinggal tanpa strategi pemulihan bencana. Aja ngarep-arep Kubernetes nyedhiyakake isolasi lan kasedhiyan dhuwur saka kothak. Luangake sawetara wektu nggawe aplikasi sampeyan pancen asli awan.

Sampeyan bisa kenal karo pengalaman sing ora sukses saka macem-macem tim ing kumpulan crita iki dening Henning Jacobs.

Sing pengin nambah dhaptar kesalahan sing diwenehake ing artikel iki bisa hubungi kita ing Twitter (@MarekBartik, @MstrsObserver).

PS saka penerjemah

Waca uga ing blog kita:

• «Ngrancang Kluster Kubernetes: Sepira kudu ana?";
• «ABC Keamanan ing Kubernetes: Authentication, Wewenang, Auditing";
• «Autoscaling lan manajemen sumber daya ing Kubernetes"(review lan laporan video);
• «ConfigMaps ing Kubernetes: nuansa sing kudu dingerteni".

Source: www.habr.com