Saat memulai Kubernetes, sering kali kita lupa menyiapkan sumber daya container. Pada titik ini, cukup memastikan bahwa image Docker berfungsi dan dapat diterapkan ke cluster Kubernetes.
Namun nantinya aplikasi tersebut perlu di-deploy di cluster produksi bersama dengan aplikasi lainnya. Untuk melakukan ini, Anda perlu mengalokasikan sumber daya untuk wadah dan memastikan bahwa sumber daya tersebut cukup untuk membuat aplikasi aktif dan berjalan, dan aplikasi lain yang sedang berjalan tidak akan mengalami masalah.
Tim menerjemahkan artikel tentang sumber daya kontainer (CPU & MEM), permintaan dan batasan sumber daya. Anda akan mempelajari manfaat pengaturan ini dan apa yang terjadi jika Anda tidak mengaturnya.
Sumber daya komputasi
Kami memiliki dua jenis sumber daya dengan unit berikut:
- Unit pemrosesan pusat (CPU) - inti;
- Memori (MEM) - byte.
Sumber daya ditentukan untuk setiap kontainer. Pada file Pod YAML berikut, Anda akan melihat bagian resource yang berisi resource yang diminta dan dibatasi:
- Sumber Daya Pod yang Diminta = jumlah sumber daya yang diminta dari semua kontainer;
- Batas Sumber Daya Pod = Jumlah seluruh Batas 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: 1GiContoh Sumber Daya yang Diminta dan Terbatas
Lapangan resources.requested dari spesifikasinya Pod merupakan salah satu elemen yang digunakan untuk mencari node yang diinginkan. Anda sudah dapat merencanakan penerapan Pod untuknya. Bagaimana cara menemukan simpul yang cocok?
Kubernetes terdiri dari beberapa komponen, antara lain sebuah node master atau master node (Kubernetes Control Plane). Node master memiliki beberapa proses: kube-apiserver, kube-controller-manager dan kube-scheduler.
Proses kube-scheduler bertanggung jawab untuk meninjau pod yang baru dibuat dan menemukan kemungkinan node pekerja yang cocok dengan semua permintaan pod, termasuk jumlah sumber daya yang diminta. Daftar node yang ditemukan oleh kube-scheduler diberi peringkat. Pod dijadwalkan pada node dengan skor tertinggi.
Dimana Pod ungu akan ditempatkan?
Pada gambar Anda dapat melihat bahwa kube-scheduler harus menjadwalkan Pod ungu baru. Cluster Kubernetes berisi dua node: A dan B. Seperti yang bisa kamu lihat, kube-scheduler tidak dapat menjadwalkan sebuah Pod pada node A - sumber daya yang tersedia (tidak diminta) tidak sesuai dengan permintaan dari Pod ungu. Jadi, memori sebesar 1 GB yang diminta oleh Pod ungu tidak akan muat di node A, karena memori yang tersedia adalah 0,5 GB. Namun node B memiliki sumber daya yang cukup. Hasilnya, kube-scheduler memutuskan bahwa tujuan dari Pod ungu tersebut adalah node B.
Sekarang kita mengetahui bagaimana sumber daya yang diminta mempengaruhi pilihan node untuk menjalankan Pod. Namun apa dampak dari sumber daya marginal?
Batas sumber daya adalah batas yang tidak dapat dilewati oleh CPU/MEM. Namun, sumber daya CPU bersifat fleksibel, sehingga container yang mencapai batas CPU-nya tidak akan menyebabkan Pod keluar. Sebaliknya, pelambatan CPU akan dimulai. Jika batas penggunaan MEM tercapai, container akan dihentikan karena OOM-Killer dan dimulai ulang jika diizinkan oleh pengaturan RestartPolicy.
Sumber daya yang diminta dan maksimum secara detail
Komunikasi sumber daya antara Docker dan Kubernetes
Cara terbaik untuk menjelaskan cara kerja permintaan sumber daya dan batasan sumber daya adalah dengan memperkenalkan hubungan antara Kubernetes dan Docker. Pada gambar di atas, Anda dapat melihat keterkaitan kolom Kubernetes dan flag startup Docker.
Memori: permintaan dan batasan
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Seperti disebutkan di atas, memori diukur dalam byte. Berdasarkan , kita dapat menentukan memori sebagai angka. Biasanya berupa bilangan bulat, misalnya 2678 - yaitu 2678 byte. Anda juga dapat menggunakan sufiks G и Gi, hal utama yang harus diingat adalah bahwa keduanya tidak setara. Yang pertama adalah desimal dan yang kedua adalah biner. Seperti contoh yang disebutkan dalam dokumentasi k8s: 128974848, 129e6, 129M, 123Mi - mereka secara praktis setara.
Opsi Kubernetes limits.memory cocok dengan benderanya --memory dari Docker. Dalam kasus request.memory Tidak ada panah untuk Docker karena Docker tidak menggunakan kolom ini. Anda mungkin bertanya, apakah ini perlu? Ya, perlu. Seperti yang saya katakan sebelumnya, bidang ini penting bagi Kubernetes. Berdasarkan informasi darinya, kube-scheduler memutuskan node mana yang akan menjadwalkan Podnya.
Apa yang terjadi jika Anda menetapkan memori yang tidak mencukupi untuk suatu permintaan?
Jika container telah mencapai batas memori yang diminta, maka Pod tersebut ditempatkan pada sekelompok Pod yang berhenti ketika memori pada node tersebut tidak mencukupi.
Apa yang terjadi jika Anda menetapkan batas memori terlalu rendah?
Jika container melebihi batas memori, container akan dihentikan karena OOM-Killed. Dan akan restart jika memungkinkan berdasarkan RestartPolicy dimana nilai defaultnya Always.
Apa yang terjadi jika Anda tidak menentukan memori yang diminta?
Kubernetes akan mengambil nilai batas dan menetapkannya sebagai nilai default.
Apa yang terjadi jika Anda tidak menentukan batas memori?
Kontainer tidak memiliki batasan; ia dapat menggunakan memori sebanyak yang diinginkannya. Jika dia mulai menggunakan semua memori yang tersedia di node tersebut, maka OOM akan membunuhnya. Kontainer kemudian akan dimulai ulang jika memungkinkan berdasarkan RestartPolicy.
Apa yang terjadi jika Anda tidak menentukan batas memori?
Ini adalah skenario terburuk: penjadwal tidak mengetahui berapa banyak sumber daya yang dibutuhkan kontainer, dan ini dapat menyebabkan masalah serius pada node. Dalam hal ini, alangkah baiknya jika memiliki batasan default pada namespace (ditetapkan oleh LimitRange). Tidak ada batasan default - Pod tidak memiliki batasan, Pod dapat menggunakan memori sebanyak yang diinginkannya.
Jika memori yang diminta lebih besar dari yang dapat disediakan oleh node, maka Pod tidak akan dijadwalkan. Penting untuk mengingat hal itu Requests.memory - bukan nilai minimum. Ini adalah deskripsi jumlah memori yang cukup untuk menjaga container tetap berjalan.
Biasanya disarankan untuk menetapkan nilai yang sama request.memory и limit.memory. Hal ini memastikan bahwa Kubernetes tidak akan menjadwalkan Pod pada node yang memiliki cukup memori untuk menjalankan Pod tetapi tidak cukup untuk menjalankannya. Perlu diingat: Perencanaan Pod Kubernetes hanya memperhitungkan requests.memoryDan limits.memory tidak memperhitungkan.
CPU: permintaan dan batasan
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Dengan CPU, segalanya menjadi sedikit lebih rumit. Kembali ke gambaran hubungan antara Kubernetes dan Docker, Anda bisa melihatnya request.cpu соответствует --cpu-shares, sedangkan limit.cpu cocok dengan benderanya cpus di Docker.
CPU yang diminta Kubernetes dikalikan dengan 1024, yang merupakan proporsi siklus CPU. Jika ingin request 1 core full harus ditambah cpu: 1seperti yang ditunjukkan di atas.
Meminta kernel lengkap (proporsi = 1024) tidak berarti container Anda akan menerimanya. Jika mesin host Anda hanya memiliki satu inti dan Anda menjalankan lebih dari satu container, maka semua container harus berbagi CPU yang tersedia di antara mereka. Bagaimana ini bisa terjadi? Mari kita lihat gambarnya.
Permintaan CPU - Sistem Inti Tunggal
Bayangkan Anda memiliki sistem host inti tunggal yang menjalankan container. Ibu (Kubernetes) membuat kue (CPU) dan ingin membaginya kepada anak-anak (wadah). Tiga anak menginginkan satu kue utuh (proporsi = 1024), satu anak lagi menginginkan setengah kue (512). Ibu ingin bersikap adil dan membuat perhitungan sederhana.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Berdasarkan perhitungan, tiga anak akan mendapat 28% inti, bukan inti keseluruhan. Anak keempat akan mendapat 14% dari kernel penuh, bukan setengahnya. Namun segalanya akan berbeda jika Anda memiliki sistem multi-core.
Permintaan CPU - Sistem Multi-Core (4).
Pada gambar di atas Anda dapat melihat tiga anak menginginkan satu kue utuh, dan satu anak menginginkan setengahnya. Karena ibu membuat empat pai, masing-masing anaknya akan mendapatkan sebanyak yang mereka mau. Dalam sistem multi-inti, sumber daya prosesor didistribusikan ke seluruh inti prosesor yang tersedia. Jika sebuah container dibatasi kurang dari satu inti CPU penuh, container tersebut masih dapat menggunakannya 100%.
Perhitungan di atas disederhanakan untuk memahami bagaimana CPU didistribusikan di antara container. Tentu saja, selain container itu sendiri, ada proses lain yang juga menggunakan sumber daya CPU. Ketika proses dalam satu kontainer menganggur, yang lain dapat menggunakan sumber dayanya. CPU: "200m" соответствует CPU: 0,2, yang berarti sekitar 20% dari satu inti.
Sekarang mari kita bicara tentang limit.cpu. CPU yang dibatasi oleh Kubernetes dikalikan dengan 100. Hasilnya adalah jumlah waktu yang dapat digunakan oleh container setiap 100 µs (cpu-period).
limit.cpu cocok dengan bendera Docker --cpus. Ini adalah kombinasi baru dari yang lama --cpu-period и --cpu-quota. Dengan menyetelnya, kami menunjukkan berapa banyak sumber daya CPU yang tersedia yang dapat digunakan secara maksimal oleh container sebelum pembatasan dimulai:
- cpus - kombinasi
cpu-periodиcpu-quota. cpus = 1.5setara dengan pengaturancpu-period = 100000иcpu-quota = 150000; - Periode CPU - periode , default 100 mikrodetik;
- kuota cpu - jumlah mikrodetik di dalamnya
cpu-period, yang dibatasi oleh wadah.
Apa yang terjadi jika Anda menginstal CPU yang diminta tidak mencukupi?
Jika container membutuhkan lebih dari yang terpasang, container tersebut akan mencuri CPU dari proses lain.
Apa yang terjadi jika Anda menetapkan batas CPU terlalu rendah?
Karena sumber daya CPU dapat disesuaikan, pembatasan akan diaktifkan.
Apa yang terjadi jika Anda tidak menentukan permintaan CPU?
Seperti halnya memori, nilai permintaan sama dengan batasnya.
Apa yang terjadi jika Anda tidak menentukan batas CPU?
Kontainer akan menggunakan CPU sebanyak yang dibutuhkan. Jika kebijakan CPU default (LimitRange) ditentukan di namespace, maka batas ini juga digunakan untuk kontainer.
Apa yang terjadi jika Anda tidak menentukan permintaan atau batas CPU?
Mengenai memori, ini adalah skenario terburuk. Penjadwal tidak mengetahui berapa banyak sumber daya yang dibutuhkan kontainer Anda, dan ini dapat menyebabkan masalah serius pada node. Untuk menghindari hal ini, Anda perlu menetapkan batas default untuk namespace (LimitRange).
Ingat: jika kamu meminta lebih banyak CPU daripada yang dapat disediakan oleh node, Pod tidak akan dijadwalkan. Requests.cpu - bukan nilai minimum, namun nilai yang cukup untuk memulai Pod dan bekerja tanpa kegagalan. Jika aplikasi tidak melakukan perhitungan yang rumit, pilihan terbaik adalah menginstal request.cpu <= 1 dan meluncurkan replika sebanyak yang diperlukan.
Jumlah ideal sumber daya yang diminta atau batas sumber daya
Kami belajar tentang keterbatasan sumber daya komputasi. Sekarang saatnya menjawab pertanyaan: “Berapa banyak sumber daya yang dibutuhkan Pod saya untuk menjalankan aplikasi tanpa masalah? Berapa jumlah idealnya?
Sayangnya, tidak ada jawaban yang jelas atas pertanyaan-pertanyaan ini. Jika Anda tidak mengetahui cara kerja aplikasi Anda atau berapa banyak CPU atau memori yang dibutuhkan, opsi terbaik adalah memberikan aplikasi banyak memori dan CPU, lalu menjalankan tes kinerja.
Selain tes kinerja, pantau perilaku aplikasi dalam pemantauan selama seminggu. Jika grafik menunjukkan bahwa aplikasi Anda menggunakan sumber daya lebih sedikit dari yang diminta, Anda dapat mengurangi jumlah CPU atau memori yang diminta.
Sebagai contoh, lihat ini . Ini menampilkan perbedaan antara sumber daya yang diminta atau batas sumber daya dan penggunaan sumber daya saat ini.
Kesimpulan
Meminta dan membatasi sumber daya membantu menjaga cluster Kubernetes Anda tetap sehat. Konfigurasi batas yang tepat meminimalkan biaya dan menjaga aplikasi tetap berjalan setiap saat.
Singkatnya, ada beberapa hal yang perlu diingat:
- Sumber daya yang diminta adalah konfigurasi yang diperhitungkan pada saat startup (saat Kubernetes berencana menghosting aplikasi). Sebaliknya, membatasi sumber daya penting dilakukan pada saat runtime—ketika aplikasi sudah berjalan di node.
- Dibandingkan dengan memori, CPU adalah sumber daya yang diatur. Jika CPU tidak mencukupi, Pod Anda tidak akan dimatikan dan mekanisme pembatasan akan aktif.
- Sumber daya yang diminta dan batas sumber daya bukanlah nilai minimum dan maksimum! Dengan menentukan sumber daya yang diminta, Anda memastikan bahwa aplikasi akan berjalan tanpa masalah.
- Praktik yang baik adalah mengatur permintaan memori sama dengan batas memori.
- Oke instal diminta
CPU <=1, jika aplikasi tidak melakukan perhitungan yang rumit. - Jika kamu meminta lebih banyak sumber daya daripada yang tersedia pada sebuah node, maka Pod tidak akan pernah dijadwalkan ke node tersebut.
- Untuk menentukan jumlah sumber daya yang diminta/batas sumber daya yang tepat, gunakan pengujian dan pemantauan beban.
Saya harap artikel ini membantu Anda memahami konsep dasar keterbatasan sumber daya. Dan Anda akan dapat menerapkan pengetahuan ini dalam pekerjaan Anda.
Good Luck!
Apa lagi yang harus dibaca:
- .
- .
- .
Sumber: www.habr.com