Mengatur Sumber Daya Komputasi untuk Container

Saat kamu membuat spesifikasi sebuah Pod, kamu dapat secara opsional menentukan seberapa banyak CPU dan memori (RAM) yang dibutuhkan oleh setiap Container. Saat Container-Container menentukan request (permintaan) sumber daya, scheduler dapat membuat keputusan yang lebih baik mengenai Node mana yang akan dipilih untuk menaruh Pod-Pod. Dan saat limit (batas) sumber daya Container-Container telah ditentukan, maka kemungkinan rebutan sumber daya pada sebuah Node dapat dihindari. Untuk informasi lebih lanjut mengenai perbedaan request dan limit, lihat QoS Sumber Daya.

Jenis-jenis sumber daya

CPU dan memori masing-masing merupakan jenis sumber daya (resource type). Sebuah jenis sumber daya memiliki satuan dasar. CPU ditentukan dalam satuan jumlah core, dan memori ditentukan dalam satuan bytes. Jika kamu menggunakan Kubernetes v1.14 keatas, kamu dapat menentukan sumber daya huge page. Huge page adalah fitur khusus Linux di mana kernel Node mengalokasikan blok-blok memori yang jauh lebih besar daripada ukuran page bawaannya.

Sebagai contoh, pada sebuah sistem di mana ukuran page bawaannya adalah 4KiB, kamu dapat menentukan sebuah limit, hugepages-2Mi: 80Mi. Jika kontainer mencoba mengalokasikan lebih dari 40 huge page berukuran 20MiB (total 80MiB), maka alokasi tersebut akan gagal.

Catatan: Kamu tidak dapat melakukan overcommit terhadap sumber daya hugepages-*. Hal ini berbeda dari sumber daya memory dan cpu (yang dapat di-overcommit).

CPU dan memori secara kolektif disebut sebagai sumber daya komputasi, atau cukup sumber daya saja. Sumber daya komputasi adalah jumlah yang dapat diminta, dialokasikan, dan dikonsumsi. Mereka berbeda dengan sumber daya API. Sumber daya API, seperti Pod dan Service adalah objek-objek yang dapat dibaca dan diubah melalui Kubernetes API Server.

Request dan Limit Sumber daya dari Pod dan Container

Setiap Container dari sebuah Pod dapat menentukan satu atau lebih dari hal-hal berikut:

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.limits.hugepages-<size>
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
spec.containers[].resources.requests.hugepages-<size>

Walaupun requests dan limits hanya dapat ditentukan pada Container individual, akan lebih mudah untuk membahas tentang request dan limit sumber daya dari Pod. Sebuah request/limit sumber daya Pod untuk jenis sumber daya tertentu adalah jumlah dari request/limit sumber daya pada jenis tersebut untuk semua Container di dalam Pod tersebut.

Arti dari CPU

Limit dan request untuk sumber daya CPU diukur dalam satuan cpu. Satu cpu, dalam Kubernetes, adalah sama dengan:

1 vCPU AWS
1 Core GCP
1 vCore Azure
1 vCPU IBM
1 Hyperthread pada sebuah prosesor Intel bare-metal dengan Hyperthreading

Request dalam bentuk pecahan diizinkan. Sebuah Container dengan spec.containers[].resources.requests.cpu bernilai 0.5 dijamin mendapat setengah CPU dibandingkan dengan yang meminta 1 CPU. Ekspresi nilai 0.1 ekuivalen dengan ekspresi nilai 100m, yang dapat dibaca sebagai "seratus milicpu". Beberapa orang juga membacanya dengan "seratus milicore", dan keduanya ini dimengerti sebagai hal yang sama. Sebuah request dengan angka di belakang koma, seperti 0.1 dikonversi menjadi 100m oleh API, dan presisi yang lebih kecil lagi dari 1m tidak dibolehkan. Untuk alasan ini, bentuk 100m mungkin lebih disukai.

CPU juga selalu diminta dalam jumlah yang mutlak, tidak sebagai jumlah yang relatif; 0.1 adalah jumlah CPU yang sama pada sebuah mesin single-core, dual-core, atau 48-core.

Arti dari Memori

Limit dan request untuk memory diukur dalam satuan bytes. Kamu dapat mengekspresikan memori sebagai plain integer atau sebagai sebuah fixed-point integer menggunakan satu dari sufiks-sufiks berikut: E, P, T, G, M, K. Kamu juga dapat menggunakan bentuk pangkat dua ekuivalennya: Ei, Pi, Ti, Gi, Mi, Ki. Sebagai contoh, nilai-nilai berikut kurang lebih sama:

128974848, 129e6, 129M, 123Mi

Berikut sebuah contoh. Pod berikut memiliki dua Container. Setiap Container memiliki request 0.25 cpu dan 64MiB (2²⁶ bytes) memori. Setiap Container memiliki limit 0.5 cpu dan 128MiB memori. Kamu dapat berkata bahwa Pod tersebut memiliki request 0.5 cpu dan 128MiB memori, dan memiliki limit 1 cpu dan 265MiB memori.

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Bagaimana Pod-Pod dengan request sumber daya dijadwalkan

Saat kamu membuat sebuah Pod, Kubernetes scheduler akan memilih sebuah Node untuk Pod tersebut untuk dijalankan. Setiap Node memiliki kapasitas maksimum untuk setiap jenis sumber daya: jumlah CPU dan memori yang dapat disediakan oleh Node tersebut untuk Pod-Pod. Scheduler memastikan bahwa, untuk setiap jenis sumber daya, jumlah semua request sumber daya dari Container-Container yang dijadwalkan lebih kecil dari kapasitas Node tersebut. Perlu dicatat bahwa walaupun penggunaan sumber daya memori atau CPU aktual/sesungguhnya pada Node-Node sangat rendah, scheduler tetap akan menolak untuk menaruh sebuah Pod pada sebuah Node jika pemeriksaan kapasitasnya gagal. Hal ini adalah untuk menjaga dari kekurangan sumber daya pada sebuah Node saat penggunaan sumber daya meningkat suatu waktu, misalnya pada saat titik puncak traffic harian.

Bagaimana Pod-Pod dengan limit sumber daya dijalankan

Saat Kubelet menjalankan sebuah Container dari sebuah Pod, Kubelet tersebut mengoper limit CPU dan memori ke runtime kontainer.

Ketika menggunakan Docker:

spec.containers[].resources.requests.cpu diubah menjadi nilai core-nya, yang mungkin berbentuk angka pecahan, dan dikalikan dengan 1024. Nilai yang lebih besar antara angka ini atau 2 digunakan sebagai nilai dari flag --cpu-shares pada perintah docker run.
spec.containers[].resources.limits.cpu diubah menjadi nilai millicore-nya dan dikalikan dengan 100. Nilai hasilnya adalah jumlah waktu CPU yang dapat digunakan oleh sebuah kontainer setiap 100 milidetik. Sebuah kontainer tidak dapat menggunakan lebih dari jatah waktu CPU-nya selama selang waktu ini.

Catatan: Periode kuota bawaan adalah 100ms. Resolusi minimum dari kuota CPU adalah 1 milidetik.
spec.containers[].resources.limits.memory diubah menjadi sebuah bilangan bulat, dan digunakan sebagai nilai dari flag --memory dari perintah docker run.

Jika sebuah Container melebihi batas memorinya, Container tersebut mungkin akan diterminasi. Jika Container tersebut dapat diulang kembali, Kubelet akan mengulangnya kembali, sama seperti jenis kegagalan lainnya.

Jika sebuah Container melebihi request memorinya, kemungkinan Pod-nya akan dipindahkan kapanpun Node tersebut kehabisan memori.

Sebuah Container mungkin atau mungkin tidak diizinkan untuk melebihi limit CPU-nya untuk periode waktu yang lama. Tetapi, Container tersebut tidak akan diterminasi karena penggunaan CPU yang berlebihan.

Untuk menentukan apabila sebuah Container tidak dapat dijadwalkan atau sedang diterminasi karena limit sumber dayanya, lihat bagian Penyelesaian Masalah.

Memantau penggunaan sumber daya komputasi

Penggunaan sumber daya dari sebuah Pod dilaporkan sebagai bagian dari kondisi Pod.

Jika monitoring opsional diaktifkan pada klaster kamu, maka penggunaan sumber daya Pod dapat diambil dari sistem monitoring kamu.

Penyelesaian Masalah

Pod-Pod saya berkondisi Pending (tertunda) dengan event message failedScheduling

Jika scheduler tidak dapat menemukan Node manapun yang muat untuk sebuah Pod, Pod tersebut tidak akan dijadwalkan hingga ditemukannya sebuah tempat yang muat. Sebuah event akan muncul setiap kali scheduler gagal menemukan tempat untuk Pod tersebut, seperti berikut:

kubectl describe pod frontend | grep -A 3 Events

Events:
  FirstSeen LastSeen   Count  From          Subobject   PathReason      Message
  36s   5s     6      {scheduler }              FailedScheduling  Failed for reason PodExceedsFreeCPU and possibly others

Pada contoh di atas, Pod bernama "frontend" gagal dijadwalkan karena kekurangan sumber daya CPU pada Node tersebut. Pesan kesalahan yang serupa dapat juga menunjukkan kegagalan karena kekurangan memori (PodExceedsFreeMemroy). Secara umum, jika sebuah Pod berkondisi Pending (tertunda) dengan sebuah pesan seperti ini, ada beberapa hal yang dapat dicoba:

Tambah lebih banyak Node pada klaster.
Terminasi Pod-Pod yang tidak dibutuhkan untuk memberikan ruangan untuk Pod-Pod yang tertunda.
Periksa jika nilai request Pod tersebut tidak lebih besar dari Node-node yang ada. Contohnya, jika semua Node memiliki kapasitas cpu: 1, maka Pod dengan request cpu: 1.1 tidak akan pernah dijadwalkan.

Kamu dapat memeriksa kapasitas Node-Node dan jumlah-jumlah yang telah dialokasikan dengan perintah kubectl describe nodes. Contohnya:

kubectl describe nodes e2e-test-node-pool-4lw4

Name:            e2e-test-node-pool-4lw4
[ ... lines removed for clarity ...]
Capacity:
 cpu:                               2
 memory:                            7679792Ki
 pods:                              110
Allocatable:
 cpu:                               1800m
 memory:                            7474992Ki
 pods:                              110
[ ... beberapa baris dihapus untuk kejelasan ...]
Non-terminated Pods:        (5 in total)
  Namespace    Name                                  CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------    ----                                  ------------  ----------  ---------------  -------------
  kube-system  fluentd-gcp-v1.38-28bv1               100m (5%)     0 (0%)      200Mi (2%)       200Mi (2%)
  kube-system  kube-dns-3297075139-61lj3             260m (13%)    0 (0%)      100Mi (1%)       170Mi (2%)
  kube-system  kube-proxy-e2e-test-...               100m (5%)     0 (0%)      0 (0%)           0 (0%)
  kube-system  monitoring-influxdb-grafana-v4-z1m12  200m (10%)    200m (10%)  600Mi (8%)       600Mi (8%)
  kube-system  node-problem-detector-v0.1-fj7m3      20m (1%)      200m (10%)  20Mi (0%)        100Mi (1%)
Allocated resources:
  (Total limit mungkin melebihi 100 persen, misalnya, karena _overcommit_.)
  CPU Requests    CPU Limits    Memory Requests    Memory Limits
  ------------    ----------    ---------------    -------------
  680m (34%)      400m (20%)    920Mi (12%)        1070Mi (14%)

Pada keluaran di atas, kamu dapat melihat bahwa jika sebuah Pod meminta lebih dari 1120m CPU atau 6.23Gi memori, Pod tersebut tidak akan muat pada Node tersebut.

Dengan melihat pada bagian Pods, kamu dapat melihat Pod-Pod mana saja yang memakan sumber daya pada Node tersebut. Jumlah sumber daya yang tersedia untuk Pod-Pod kurang dari kapasitas Node, karena daemon sistem menggunakan sebagian dari sumber daya yang ada. Kolom allocatable pada NodeStatus memberikan jumlah sumber daya yang tersedia untuk Pod-Pod. Untuk lebih lanjut, lihat Sumber daya Node yang dapat dialokasikan.

Fitur kuota sumber daya dapat disetel untuk membatasi jumlah sumber daya yang dapat digunakan. Jika dipakai bersama dengan Namespace, kuota sumber daya dapat mencegah suatu tim menghabiskan semua sumber daya.

Container saya diterminasi

Container kamu mungkin diterminasi karena Container tersebut melebihi batasnya. Untuk memeriksa jika sebuah Container diterminasi karena ia melebihi batas sumber dayanya, gunakan perintah kubectl describe pod pada Pod yang bersangkutan:

kubectl describe pod simmemleak-hra99

Name:                           simmemleak-hra99
Namespace:                      default
Image(s):                       saadali/simmemleak
Node:                           kubernetes-node-tf0f/10.240.216.66
Labels:                         name=simmemleak
Status:                         Running
Reason:
Message:
IP:                             10.244.2.75
Replication Controllers:        simmemleak (1/1 replicas created)
Containers:
  simmemleak:
    Image:  saadali/simmemleak
    Limits:
      cpu:                      100m
      memory:                   50Mi
    State:                      Running
      Started:                  Tue, 07 Jul 2015 12:54:41 -0700
    Last Termination State:     Terminated
      Exit Code:                1
      Started:                  Fri, 07 Jul 2015 12:54:30 -0700
      Finished:                 Fri, 07 Jul 2015 12:54:33 -0700
    Ready:                      False
    Restart Count:              5
Conditions:
  Type      Status
  Ready     False
Events:
  FirstSeen                         LastSeen                         Count  From                              SubobjectPath                       Reason      Message
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {scheduler }                                                          scheduled   Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    implicitly required container POD   pulled      Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    implicitly required container POD   created     Created with docker id 6a41280f516d
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    implicitly required container POD   started     Started with docker id 6a41280f516d
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    spec.containers{simmemleak}         created     Created with docker id 87348f12526a

Pada contoh di atas, Restart Count: 5 menunjukkan bahwa Container simmemleak pada Pod tersebut diterminasi dan diulang kembali sebanyak lima kali.

Kamu dapat menggunakan perintah kubectl get pod dengan opsi -o go-template=... untuk mengambil kondisi dari Container-Container yang sebelumnya diterminasi:

kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}'  simmemleak-hra99

Container Name: simmemleak
LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]

Kamu dapat lihat bahwa Container tersebut diterminasi karena reason:OOM Killed, di mana OOM merupakan singkatan dari Out Of Memory, atau kehabisan memori.

Penyimpanan lokal sementara

FEATURE STATE: Kubernetes v1.23 [beta]

Kubernetes versi 1.8 memperkenalkan sebuah sumber daya baru, ephemeral-storage untuk mengatur penyimpanan lokal yang bersifat sementara. Pada setiap Node Kubernetes, direktori root dari Kubelet (secara bawaan /var/lib/kubelet) dan direktori log (/var/log) ditaruh pada partisi root dari Node tersebut. Partisi ini juga digunakan bersama oleh Pod-Pod melalui volume emptyDir, log kontainer, lapisan image, dan lapisan kontainer yang dapat ditulis.

Partisi ini bersifat "sementara" dan aplikasi-aplikasi tidak dapat mengharapkan SLA kinerja (misalnya Disk IOPS) dari partisi ini. Pengelolaan penyimpanan lokal sementara hanya berlaku untuk partisi root; partisi opsional untuk lapisan image dan lapisan yang dapat ditulis berada di luar ruang lingkup.

Catatan: Jika sebuah partisi runtime opsional digunakan, partisi root tidak akan menyimpan lapisan image ataupun lapisan yang dapat ditulis manapun.

Menyetel request dan limit dari penyimpanan lokal sementara

Setiap Container dari sebuah Pod dapat menentukan satu atau lebih dari hal-hal berikut:

spec.containers[].resources.limits.ephemeral-storage
spec.containers[].resources.requests.ephemeral-storage

Limit dan request untuk ephemeral-storage diukur dalam satuan bytes. Kamu dapat menyatakan penyimpanan dalam bilangan bulat biasa, atau sebagai fixed-point integer menggunakan satu dari sufiks-sufiks ini: E, P, T, G, M, K. Kamu jika dapat menggunakan bentuk pangkat dua ekuivalennya: Ei, Pi, Ti, Gi, Mi, Ki. Contohnya, nilai-nilai berikut kurang lebih sama:

128974848, 129e6, 129M, 123Mi

Contohnya, Pod berikut memiliki dua Container. Setiap Container memiliki request 2GiB untuk penyimpanan lokal sementara. Setiap Container memiliki limit 4GiB untuk penyimpanan lokal sementara. Maka, Pod tersebut memiliki jumlah request 4GiB penyimpanan lokal sementara, dan limit 8GiB.

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
  - name: wp
    image: wordpress
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"

Bagaimana Pod-Pod dengan request ephemeral-storage dijadwalkan

Saat kamu membuat sebuah Pod, Kubernetes scheduler memilih sebuah Node di mana Pod tersebut akan dijalankan. Setiap Node memiliki jumlah maksimum penyimpanan lokal sementara yang dapat disediakan. Untuk lebih lanjut, lihat "Hal-hal yang dapat dialokasikan Node".

Scheduler memastikan bahwa jumlah dari request-request sumber daya dari Container-Container yang dijadwalkan lebih kecil dari kapasitas Node.

Bagaimana Pod-Pod dengan limit ephemeral-storage dijalankan

Untuk isolasi pada tingkat kontainer, jika lapisan yang dapat ditulis dari sebuah Container dan penggunaan log melebihi limit penyimpanannya, maka Pod tersebut akan dipindahkan. Untuk isolasi pada tingkat Pod, jika jumlah dari penyimpanan lokal sementara dari semua Container dan juga volume emptyDir milik Pod melebihi limit, maka Pod teresebut akan dipindahkan.

Memantau penggunaan ephemeral-storage

Saat penyimpanan lokal sementara digunakan, ia dipantau terus-menerus oleh Kubelet. Pemantauan dilakukan dengan cara memindai setiap volume emptyDir, direktori log, dan lapisan yang dapat ditulis secara periodik. Dimulai dari Kubernetes 1.15, volume emptyDir (tetapi tidak direktori log atau lapisan yang dapat ditulis) dapat, sebagai pilihan dari operator klaster, dikelola dengan menggunakan project quotas. Project quotas aslinya diimplementasikan dalam XFS, dan baru-baru ini telah diubah ke ext4fs. Project quotas dapat digunakan baik untuk monitoring dan pemaksaan; sejak Kubernetes 1.16, mereka tersedia sebagai fitur alpha untuk monitoring saja.

Quota lebih cepat dan akurat dibandingkan pemindaian direktori. Saat sebuah direktori ditentukan untuk sebuah proyek, semua berkas yang dibuat pada direktori tersebut dibuat untuk proyek tersebut, dan kernel hanya perlu melacak berapa banyak blok yang digunakan oleh berkas-berkas pada proyek tersebut. Jika sebuah berkas dibuat dan dihapus, tetapi tetap dengan sebuah file descriptor yang terbuka, maka berkas tersebut tetap akan memakan ruangan penyimpanan. Ruangan ini akan dilacak oleh quota tersebut, tetapi tidak akan terlihat oleh sebuah pemindaian direktori.

Kubernetes menggunakan ID proyek yang dimulai dari 1048576. ID-ID yang digunakan akan didaftarkan di dalam /etc/projects dan /etc/projid. Jika ID-ID proyek pada kisaran ini digunakan untuk tujuan lain pada sistem, ID-ID proyek tersebut harus terdaftar di dalam /etc/projects dan /etc/projid untuk mencegah Kubernetes menggunakan ID-ID tersebut.

Untuk mengaktifkan penggunaan project quotas, operator klaster harus melakukan hal-hal berikut:

Aktifkan feature gate LocalStorageCapacityIsolationFSQuotaMonitoring=true pada konfigurasi Kubelet. Nilainya secara bawaan false pada Kubernetes 1.16, jadi harus secara eksplisit disetel menjadi true.
Pastikan bahwa partisi root (atau partisi opsional runtime) telah dibangun (build) dengan mengaktifkan project quotas. Semua sistem berkas (filesystem) XFS mendukung project quotas, tetapi sistem berkas ext4 harus dibangun secara khusus untuk mendukungnya
Pastikan bahwa partisi root (atau partisi opsional runtime) ditambatkan (mount) dengan project quotas yang telah diaktifkan.

Membangun dan menambatkan sistem berkas dengan project quotas yang telah diaktifkan

Sistem berkas XFS tidak membutuhkan tindakan khusus saat dibangun; mereka secara otomatis telah dibangun dengan project quotas yang telah diaktifkan.

Sistem berkas ext4fs harus dibangun dengan mengaktifkan quotas, kemudian mereka harus diaktifkan pada sistem berkas tersebut.

% sudo mkfs.ext4 other_ext4fs_args... -E quotatype=prjquota /dev/block_device
% sudo tune2fs -O project -Q prjquota /dev/block_device

Untuk menambatkan sistem berkasnya, baik ext4fs dan XFS membutuhkan opsi prjquota disetel di dalam /etc/fstab:

/dev/block_device	/var/kubernetes_data	defaults,prjquota	0	0

Sumber daya yang diperluas

Sumber daya yang diperluas (Extended Resource) adalah nama sumber daya di luar domain kubernetes.io. Mereka memungkinkan operator klaster untuk menyatakan dan pengguna untuk menggunakan sumber daya di luar sumber daya bawaan Kubernetes.

Ada dua langkah untuk menggunakan sumber daya yang diperluas. Pertama, operator klaster harus menyatakan sebuah Extended Resource. Kedua, pengguna harus meminta sumber daya yang diperluas tersebut di dalam Pod.

Mengelola sumber daya yang diperluas

Sumber daya yang diperluas pada tingkat Node

Sumber daya yang diperluas pada tingkat Node terikat pada Node.

Sumber daya Device Plugin yang dikelola

Lihat Device Plugin untuk cara menyatakan sumber daya device plugin yang dikelola pada setiap node.

Sumber daya lainnya

Untuk menyatakan sebuah sumber daya yang diperluas tingkat Node, operator klaster dapat mengirimkan permintaan HTTP PATCH ke API server untuk menentukan kuantitas sumber daya yang tersedia pada kolom status.capacity untuk Node pada klaster. Setelah itu, status.capacity pada Node akan memiliki sumber daya baru tersebut. Kolom status.allocatable diperbarui secara otomatis dengan sumber daya baru tersebut secara asynchrounous oleh Kubelet. Perlu dicatat bahwa karena scheduler menggunakan nilai status.allocatable milik Node saat mengevaluasi muat atau tidaknya Pod, mungkin ada waktu jeda pendek antara melakukan PATCH terhadap kapasitas Node dengan sumber daya baru dengan Pod pertama yang meminta sumber daya tersebut untuk dapat dijadwalkan pada Node tersebut.

Contoh:

Berikut sebuah contoh yang menunjukkan bagaimana cara menggunakan curl untuk mengirim permintaan HTTP yang menyatakan lima sumber daya "example.com/foo" pada Node k8s-node-1 yang memiliki master k8s-master.

curl --header "Content-Type: application/json-patch+json" \
--request PATCH \
--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \
http://k8s-master:8080/api/v1/nodes/k8s-node-1/status

Catatan: Pada permintaan HTTP di atas, ~1 adalah encoding untuk karakter / pada jalur (path) patch. Nilai jalur operasi tersebut di dalam JSON-Patch diinterpretasikan sebagai sebuah JSON-Pointer. Untuk lebih lanjut, lihat IETF RFC 6901, bagian 3.

Sumber daya yang diperluas pada tingkat klaster

Sumber daya yang diperluas pada tingkat klaster tidak terikat pada Node. Mereka biasanya dikelola oleh scheduler extender, yang menangani penggunaan sumber daya dan kuota sumber daya.

Kamu dapat menentukan sumber daya yang diperluas yang ditangani oleh scheduler extender pada konfigurasi kebijakan scheduler.

Contoh:

Konfigurasi untuk sebuah kebijakan scheduler berikut menunjukkan bahwa sumber daya yang diperluas pada tingkat klaster "example.com/foo" ditangani oleh scheduler extender.

Scheduler mengirim sebuah Pod ke scheduler extender hanya jika Pod tersebut meminta "example.com/foo".
Kolom ignoredByScheduler menentukan bahwa scheduler tidak memeriksa sumber daya "example.com/foo" pada predikat PodFitsResources miliknya.

{
  "kind": "Policy",
  "apiVersion": "v1",
  "extenders": [
    {
      "urlPrefix":"<extender-endpoint>",
      "bindVerb": "bind",
      "managedResources": [
        {
          "name": "example.com/foo",
          "ignoredByScheduler": true
        }
      ]
    }
  ]
}

Menggunakan sumber daya yang diperluas

Pengguna dapat menggunakan sumber daya yang diperluas di dalam spesifikasi Pod seperti CPU dan memori. Scheduler menangani akuntansi sumber daya tersebut agar tidak ada alokasi untuk yang melebihi jumlah yang tersedia.

API server membatasi jumlah sumber daya yang diperluas dalam bentuk bilangan bulat. Contoh jumlah yang valid adalah 3, 3000m, dan 3Ki. Contoh jumlah yang tidak valid adalah 0.5 dan 1500m.

Catatan: Sumber daya yang diperluas menggantikan Opaque Integer Resource. Pengguna dapat menggunakan prefiks nama domain selain kubernetes.io yang sudah dipakai.

Untuk menggunakan sebuah sumber daya yang diperluas di sebuah Pod, masukkan nama sumber daya tersebut sebagai nilai key dari map spec.containers[].resources.limit pada spesifikasi Container.

Catatan: Sumber daya yang diperluas tidak dapat di-overcommit, sehingga request dan limit nilainya harus sama jika keduanya ada di spesifikasi sebuah Container.

Sebuah Pod hanya dijadwalkan jika semua request sumber dayanya terpenuhi, termasuk CPU, memori, dan sumber daya yang diperluas manapun. Pod tersebut akan tetap berada pada kondisi PENDING selama request sumber daya tersebut tidak terpenuhi.

Contoh:

Pod di bawah meminta 2 CPU dan 1 "example.com/foo" (sebuah sumber daya yang diperluas).

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: myimage
    resources:
      requests:
        cpu: 2
        example.com/foo: 1
      limits:
        example.com/foo: 1

Selanjutnya

Dapatkan pengalaman langsung menentukan sumber daya memori untuk Container dan Pod.
Dapatkan pengalaman langsung menentukan sumber daya CPU untuk Container dan Pod.
Container API
ResourceRequirements

Last modified July 10, 2020 at 10:24 PM PST: Replace EN links to ID links (0c799ef757)

Mengatur Sumber Daya Komputasi untuk Container

Jenis-jenis sumber daya

Request dan Limit Sumber daya dari Pod dan Container

Arti dari CPU

Arti dari Memori

Bagaimana Pod-Pod dengan request sumber daya dijadwalkan

Bagaimana Pod-Pod dengan limit sumber daya dijalankan

Memantau penggunaan sumber daya komputasi

Penyelesaian Masalah

Pod-Pod saya berkondisi Pending (tertunda) dengan event message failedScheduling

Container saya diterminasi

Penyimpanan lokal sementara

Menyetel request dan limit dari penyimpanan lokal sementara

Bagaimana Pod-Pod dengan request ephemeral-storage dijadwalkan

Bagaimana Pod-Pod dengan limit ephemeral-storage dijalankan

Memantau penggunaan ephemeral-storage

Membangun dan menambatkan sistem berkas dengan project quotas yang telah diaktifkan

Sumber daya yang diperluas

Mengelola sumber daya yang diperluas

Sumber daya yang diperluas pada tingkat Node

Sumber daya Device Plugin yang dikelola

Sumber daya lainnya

Sumber daya yang diperluas pada tingkat klaster

Menggunakan sumber daya yang diperluas

Selanjutnya

Masukan