🥇Cara mengakses sumber Kubernetes Pod

Ganjaran oleh Tohad

Apabila bermula dengan Kubernetes, adalah perkara biasa untuk melupakan tentang menyediakan sumber kontena. Pada ketika ini, sudah cukup untuk memastikan imej Docker berfungsi dan boleh digunakan ke gugusan Kubernetes.

Tetapi kemudian aplikasi itu perlu digunakan dalam kelompok pengeluaran bersama-sama dengan aplikasi lain. Untuk melakukan ini, anda perlu memperuntukkan sumber untuk bekas dan pastikan bahawa terdapat cukup daripadanya untuk menjalankan dan menjalankan aplikasi, dan aplikasi lain yang sedang berjalan tidak akan mengalami masalah.

Pasukan Kubernetes aaS daripada Mail.ru menterjemah artikel tentang sumber kontena (CPU & MEM), permintaan dan had sumber. Anda akan mempelajari faedah tetapan ini dan perkara yang berlaku jika anda tidak menetapkannya.

Sumber pengkomputeran

Kami mempunyai dua jenis sumber dengan unit berikut:

Unit pemprosesan pusat (CPU) - teras;
Memori (MEM) - bait.

Sumber ditentukan untuk setiap bekas. Dalam fail Pod YAML berikut, anda akan melihat bahagian sumber yang mengandungi sumber yang diminta dan had:

Sumber Pod yang Diminta = jumlah sumber yang diminta untuk semua bekas;
Had Sumber Pod = Jumlah semua Had Sumber 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

Contoh Sumber Diminta dan Terhad

Bidang resources.requested daripada spesifikasi Pod adalah salah satu elemen yang digunakan untuk mencari nod yang dikehendaki. Anda sudah boleh merancang penempatan Pod untuknya. Bagaimanakah anda mencari nod yang sesuai?

Kubernetes terdiri daripada beberapa komponen, termasuk nod induk atau nod induk (Satah Kawalan Kubernetes). Nod induk mempunyai beberapa proses: kube-apiserver, kube-controller-manager dan kube-scheduler.

Proses penjadual kube bertanggungjawab untuk menyemak pod yang baru dibuat dan mencari kemungkinan nod pekerja yang sepadan dengan semua permintaan pod, termasuk bilangan sumber yang diminta. Senarai nod yang ditemui oleh kube-scheduler disenaraikan. Pod dijadualkan pada nod dengan markah tertinggi.

Di manakah Pod ungu akan diletakkan?

Dalam gambar anda dapat melihat bahawa penjadual kube harus menjadualkan Pod ungu baharu. Kelompok Kubernetes mengandungi dua nod: A dan B. Seperti yang anda lihat, penjadual kube tidak boleh menjadualkan Pod pada nod A - sumber yang tersedia (tidak diminta) tidak sepadan dengan permintaan Pod ungu. Jadi, memori 1 GB yang diminta oleh Pod ungu tidak akan muat pada nod A, kerana memori yang tersedia ialah 0,5 GB. Tetapi nod B mempunyai sumber yang mencukupi. Akibatnya, kube-scheduler memutuskan bahawa destinasi Pod ungu ialah nod B.

Sekarang kita tahu bagaimana sumber yang diminta mempengaruhi pilihan nod untuk menjalankan Pod. Tetapi apakah kesan sumber marginal?

Had sumber ialah sempadan yang tidak boleh dilalui oleh CPU/MEM. Walau bagaimanapun, sumber CPU adalah fleksibel, jadi bekas yang mencapai had CPU mereka tidak akan menyebabkan Pod keluar. Sebaliknya, pendikit CPU akan bermula. Jika had penggunaan MEM dicapai, bekas akan dihentikan kerana OOM-Killer dan dimulakan semula jika dibenarkan oleh tetapan RestartPolicy.

Sumber yang diminta dan maksimum secara terperinci

Komunikasi sumber antara Docker dan Kubernetes

Cara terbaik untuk menerangkan cara permintaan sumber dan had sumber berfungsi ialah dengan memperkenalkan hubungan antara Kubernetes dan Docker. Dalam imej di atas anda boleh melihat bagaimana medan Kubernetes dan bendera permulaan Docker berkaitan.

Ingatan: permintaan dan had

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

Seperti yang dinyatakan di atas, memori diukur dalam bait. Berdasarkan dokumentasi Kubernetes, kita boleh menentukan memori sebagai nombor. Biasanya ia adalah integer, contohnya 2678 - iaitu, 2678 bait. Anda juga boleh menggunakan akhiran G и Gi, perkara utama adalah untuk diingat bahawa mereka tidak setara. Yang pertama ialah perpuluhan dan yang kedua ialah binari. Seperti contoh yang disebutkan dalam dokumentasi k8s: 128974848, 129e6, 129M, 123Mi - mereka boleh dikatakan setara.

Pilihan Kubernetes limits.memory sepadan dengan bendera --memory daripada Docker. Dalam kes request.memory Tiada anak panah untuk Docker kerana Docker tidak menggunakan medan ini. Anda mungkin bertanya, adakah ini perlu? Ya perlu. Seperti yang saya katakan sebelum ini, bidang itu penting untuk Kubernetes. Berdasarkan maklumat daripadanya, kube-scheduler memutuskan nod mana untuk menjadualkan Pod.

Apakah yang berlaku jika anda menetapkan memori yang tidak mencukupi untuk permintaan?

Jika bekas telah mencapai had memori yang diminta, maka Pod diletakkan dalam kumpulan Pod yang berhenti apabila tiada memori yang mencukupi dalam nod.

Apakah yang berlaku jika anda menetapkan had memori terlalu rendah?

Jika bekas melebihi had memori, ia akan ditamatkan kerana OOM-Killed. Dan akan dimulakan semula jika boleh berdasarkan RestartPolicy di mana nilai lalainya Always.

Apakah yang berlaku jika anda tidak menentukan memori yang diminta?

Kubernetes akan mengambil nilai had dan menetapkannya sebagai nilai lalai.

Apakah yang boleh berlaku jika anda tidak menentukan had ingatan?

Bekas tidak mempunyai sekatan; ia boleh menggunakan seberapa banyak memori yang dikehendaki. Jika dia mula menggunakan semua memori yang tersedia bagi nod, maka OOM akan membunuhnya. Bekas itu kemudiannya akan dimulakan semula jika boleh berdasarkan RestartPolicy.

Apakah yang berlaku jika anda tidak menentukan had ingatan?

Ini ialah senario kes terburuk: penjadual tidak tahu berapa banyak sumber yang diperlukan oleh bekas, dan ini boleh menyebabkan masalah serius pada nod. Dalam kes ini, adalah baik untuk mempunyai had lalai pada ruang nama (ditetapkan oleh LimitRange). Tiada had lalai - Pod tidak mempunyai had, ia boleh menggunakan seberapa banyak memori yang dikehendaki.

Jika memori yang diminta adalah lebih daripada yang boleh ditawarkan oleh nod, Pod tidak akan dijadualkan. Penting untuk diingati Requests.memory - bukan nilai minimum. Ini ialah perihalan jumlah memori yang mencukupi untuk memastikan bekas berjalan secara berterusan.

Ia biasanya disyorkan untuk menetapkan nilai yang sama untuk request.memory и limit.memory. Ini memastikan bahawa Kubernetes tidak akan menjadualkan Pod pada nod yang mempunyai memori yang mencukupi untuk menjalankan Pod tetapi tidak mencukupi untuk menjalankannya. Perlu diingat: Perancangan Kubernetes Pod hanya mengambil kira requests.memoryDan limits.memory tidak mengambil kira.

CPU: permintaan dan had

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

Dengan CPU semuanya menjadi lebih rumit. Kembali kepada gambar hubungan antara Kubernetes dan Docker, anda boleh melihatnya request.cpu sepadan dengan --cpu-shares, sedangkan limit.cpu sepadan dengan bendera cpus dalam Docker.

CPU yang diminta oleh Kubernetes didarabkan dengan 1024, perkadaran kitaran CPU. Jika anda ingin meminta 1 teras penuh, anda mesti menambah cpu: 1seperti yang ditunjukkan di atas.

Meminta kernel penuh (perkadaran = 1024) tidak bermakna bekas anda akan menerimanya. Jika mesin hos anda hanya mempunyai satu teras dan anda menjalankan lebih daripada satu bekas, maka semua bekas mesti berkongsi CPU yang tersedia di antara mereka. Bagaimana ini berlaku? Jom tengok gambar.

Permintaan CPU - Sistem Teras Tunggal

Mari bayangkan anda mempunyai sistem hos teras tunggal yang menjalankan bekas. Ibu (Kubernetes) membakar pai (CPU) dan ingin membahagikannya antara kanak-kanak (bekas). Tiga kanak-kanak mahukan pai keseluruhan (kadaran = 1024), seorang lagi kanak-kanak mahu separuh pai (512). Ibu mahu berlaku adil dan membuat pengiraan yang mudah.

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

Berdasarkan pengiraan, tiga kanak-kanak akan menerima 28% daripada teras, dan bukan keseluruhan teras. Anak keempat akan mendapat 14% daripada isirong penuh, bukan separuh. Tetapi perkara akan berbeza jika anda mempunyai sistem berbilang teras.

Permintaan CPU - Sistem Berbilang Teras (4).

Dalam imej di atas anda dapat melihat bahawa tiga kanak-kanak mahukan pai keseluruhan, dan seorang mahu separuh. Memandangkan ibu membakar empat pai, setiap anaknya akan mendapat seberapa banyak yang mereka mahu. Dalam sistem berbilang teras, sumber pemproses diedarkan merentasi semua teras pemproses yang tersedia. Jika bekas dihadkan kepada kurang daripada satu teras CPU penuh, ia masih boleh menggunakannya pada 100%.

Pengiraan di atas dipermudahkan untuk memahami cara CPU diagihkan antara bekas. Sudah tentu, selain bekas itu sendiri, terdapat proses lain yang juga menggunakan sumber CPU. Apabila proses dalam satu bekas terbiar, orang lain boleh menggunakan sumbernya. CPU: "200m" sepadan dengan CPU: 0,2, yang bermaksud kira-kira 20% daripada satu teras.

Sekarang mari kita bercakap tentang limit.cpu. CPU yang dihadkan oleh Kubernetes didarab dengan 100. Hasilnya ialah jumlah masa yang boleh digunakan oleh bekas setiap 100 µs (cpu-period).

limit.cpu sepadan dengan bendera Docker --cpus. Ini adalah gabungan baru yang lama --cpu-period и --cpu-quota. Dengan menetapkannya, kami menunjukkan bilangan sumber CPU yang tersedia yang boleh digunakan secara maksimum oleh bekas sebelum pendikitan bermula:

cpus - gabungan cpu-period и cpu-quota. cpus = 1.5 bersamaan dengan penetapan cpu-period = 100000 и cpu-quota = 150000;
Tempoh CPU - tempoh Penjadual CPU CFS, lalai 100 mikrosaat;
kuota cpu - bilangan mikrosaat di dalam cpu-period, yang dibatasi oleh bekas.

Apakah yang berlaku jika anda memasang CPU yang diminta tidak mencukupi?

Jika bekas memerlukan lebih daripada yang telah dipasang, ia akan mencuri CPU daripada proses lain.

Apa yang berlaku jika anda menetapkan had CPU terlalu rendah?

Memandangkan sumber CPU boleh laras, pendikit akan dihidupkan.

Apakah yang berlaku jika anda tidak menentukan permintaan CPU?

Seperti memori, nilai permintaan adalah sama dengan had.

Apakah yang berlaku jika anda tidak menentukan had CPU?

Bekas akan menggunakan seberapa banyak CPU yang diperlukan. Jika dasar CPU lalai (LimitRange) ditakrifkan dalam ruang nama, maka had ini juga digunakan untuk bekas.

Apakah yang berlaku jika anda tidak menentukan sama ada permintaan atau had CPU?

Seperti ingatan, ini adalah senario terburuk. Penjadual tidak mengetahui berapa banyak sumber yang diperlukan oleh bekas anda, dan ini boleh menyebabkan masalah serius pada nod. Untuk mengelakkan ini, anda perlu menetapkan had lalai untuk ruang nama (LimitRange).

Ingat: jika anda meminta lebih banyak CPU daripada yang boleh disediakan oleh nod, Pod tidak akan dijadualkan. Requests.cpu - bukan nilai minimum, tetapi nilai yang mencukupi untuk memulakan Pod dan berfungsi tanpa kegagalan. Jika aplikasi tidak melakukan pengiraan yang rumit, pilihan terbaik ialah memasang request.cpu <= 1 dan melancarkan seberapa banyak replika yang diperlukan.

Jumlah ideal sumber yang diminta atau had sumber

Kami belajar tentang had sumber pengkomputeran. Kini tiba masanya untuk menjawab soalan: "Berapa banyak sumber yang Pod saya perlukan untuk menjalankan aplikasi tanpa sebarang masalah? Apakah jumlah yang ideal?

Malangnya, tiada jawapan yang jelas untuk soalan-soalan ini. Jika anda tidak tahu cara aplikasi anda berfungsi atau berapa banyak CPU atau memori yang diperlukan, pilihan terbaik ialah memberikan aplikasi banyak memori dan CPU dan kemudian menjalankan ujian prestasi.

Selain ujian prestasi, pantau tingkah laku aplikasi dalam pemantauan selama seminggu. Jika graf menunjukkan bahawa aplikasi anda menggunakan sumber yang lebih sedikit daripada yang anda minta, anda boleh mengurangkan jumlah CPU atau memori yang diminta.

Sebagai contoh lihat ini Papan pemuka Grafana. Ia memaparkan perbezaan antara sumber yang diminta atau had sumber dan penggunaan sumber semasa.

Kesimpulan

Meminta dan mengehadkan sumber membantu memastikan kluster Kubernetes anda sihat. Konfigurasi had yang betul meminimumkan kos dan memastikan aplikasi berjalan sepanjang masa.

Secara ringkasnya, terdapat beberapa perkara yang perlu diingat:

Sumber yang diminta ialah konfigurasi yang diambil kira pada masa permulaan (apabila Kubernetes merancang untuk menjadi hos aplikasi). Sebaliknya, mengehadkan sumber adalah penting pada masa jalan—apabila aplikasi sudah berjalan pada nod.
Berbanding dengan memori, CPU adalah sumber terkawal. Jika CPU tidak mencukupi, Pod anda tidak akan ditutup dan mekanisme pendikit akan dihidupkan.
Sumber yang diminta dan had sumber bukanlah nilai minimum dan maksimum! Dengan menentukan sumber yang diminta, anda memastikan bahawa aplikasi akan berjalan tanpa masalah.
Amalan yang baik ialah menetapkan permintaan memori sama dengan had memori.
Ok pemasangan diminta CPU <=1, jika aplikasi tidak melakukan pengiraan yang rumit.
Jika anda meminta lebih banyak sumber daripada yang tersedia pada nod, Pod tidak akan dijadualkan ke nod itu.
Untuk menentukan jumlah yang betul bagi sumber/had sumber yang diminta, gunakan ujian dan pemantauan beban.

Saya harap artikel ini membantu anda memahami konsep asas pengehadan sumber. Dan anda akan dapat menggunakan pengetahuan ini dalam kerja anda.

Semoga Berjaya!

Apa lagi yang perlu dibaca:

Sumber: www.habr.com

Cara mengakses sumber Kubernetes Pod