Menggunakan kuota resource hierarkis

Kuota resource Kubernetes adalah alat bagi administrator untuk memastikan pembagian resource yang adil di antara pengguna yang berbeda. Kuota resource, yang ditentukan oleh objek ResourceQuota, memberikan batasan yang membatasi konsumsi resource gabungan dalam satu namespace.

Pengontrol Hierarki memperluas konsep kuota resource per namespace untuk mendukung namespace hierarkis. Objek HierarchicalResourceQuota membatasi konsumsi resource gabungan di semua namespace dalam sub-hierarki, sehingga administrator dapat membatasi konsumsi resource di beberapa namespace terkait.

Saat kuota resource hierarkis diaktifkan, Hierarchy Controller akan menginstal dua memvalidasi webhook, satu untuk benar-benar menerapkan batas konsumsi resource dan satu lagi untuk memvalidasi kuota resource hierarkis itu sendiri.

Aktifkan kuota resource hierarkis

Kuota resource hierarkis disediakan oleh Pengontrol Hierarki. Untuk mengaktifkan kuota resource hierarkis, ikuti langkah-langkah berikut:

  1. Instal Pengontrol Hierarki, menggunakan Config Sync 1.6.2 atau yang lebih baru.

  2. Dalam file konfigurasi untuk ConfigManagement Operator, di objek spec.hierarchyController, tetapkan nilai enableHierarchicalResourceQuota ke true:

    # config-management.yaml

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  hierarchyController:
    enabled: true
    # Set to true to enable hierarchical resource quotas:
    enableHierarchicalResourceQuota: true
  # ...other fields...

  3. Terapkan konfigurasi:

    kubectl apply -f config-management.yaml

    Setelah sekitar satu menit, Pengontrol Hierarki dan kuota resource hierarkis dapat digunakan di cluster Anda.

Untuk memastikan kuota resource hierarkis sudah diaktifkan, ikuti langkah-langkah berikut:

  1. Buat objek HierarchicalResourceQuota dalam namespace apa pun, seperti berikut:

    cat > example-hrq.yaml <<EOF
apiVersion: hierarchycontroller.configmanagement.gke.io/v1alpha1
kind: HierarchicalResourceQuota
metadata:
  name: example-hrq
spec:
  hard:
    configmaps: "1"
EOF

kubectl apply -f example-hrq.yaml -n default

  2. Pastikan objek ResourceQuota baru yang disebut gke-hc-hrq telah dibuat dalam namespace dengan spec.hard yang sama dari 1 configmap, misalnya:

    kubectl describe resourcequota gke-hc-hrq -n default

    Output:

    Name:           gke-hc-hrq
Namespace:      default
Resource        Used    Hard
--------        ----    ----
configmaps      0       1

  3. Pembersihan:

    kubectl delete hrq -n default example-hrq

    Pastikan objek yang dibuat secara otomatis telah dihapus:

    kubectl get resourcequota gke-hc-hrq -n default

    Output:

    Error from server (NotFound): resourcequotas "gke-hc-hrq" not found

Menggunakan kuota resource hierarkis

Menetapkan kuota

Menetapkan HierarchicalResourceQuota sama seperti menetapkan ResourceQuota reguler, tetapi dengan apiVersion dan kind yang berbeda. Oleh karena itu, Anda dapat menetapkan batas resource di kolom spec.hard seperti pada ResourceQuota.

Pertimbangkan tim bernama team-a yang memiliki layanan bernama service-a dan memiliki subtim bernama team-b, yang semuanya direpresentasikan oleh namespace hierarkis sebagai berikut:

kubectl hns tree team-a

Output:

team-a
├── service-a
└── team-b

Jika Anda ingin membatasi jumlah configmaps dalam team-a, tetapi tanpa membatasi jumlah pada turunan mana pun, Anda dapat membuat ResourceQuota biasa seperti berikut:

cat > team-a-rq.yaml <<EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-rq
  namespace: team-a
spec:
  hard:
    configmaps: "1"
EOF

kubectl apply -f team-a-rq.yaml

Sebaliknya, untuk membatasi jumlah total configmaps dalam team-a dan turunannya, ganti apiVersion dan kind pada contoh sebelumnya:

cat > team-a-hrq.yaml <<EOF
# Modify the following two lines:
apiVersion: hierarchycontroller.configmanagement.gke.io/v1alpha1
kind: HierarchicalResourceQuota
# Everything below this line remains the same
metadata:
  name: team-a-hrq
  namespace: team-a
spec:
  hard:
    configmaps: "1"

EOF

kubectl apply -f team-a-hrq.yaml

Upaya pertama untuk membuat configmap di salah satu dari tiga namespace ini berhasil. Misalnya, kita mungkin memilih untuk membuat configmap di salah satu namespace turunan:

kubectl create configmap config-1 --from-literal key=value -n team-b

Output:

confimap/config-1 created

Namun, setiap upaya lebih lanjut untuk membuat configmap baru di salah satu dari tiga namespace akan gagal, termasuk pada namespace yang seinduk atau induk:

kubectl create configmap config-2 --from-literal key=value -n service-a
kubectl create configmap config-2 --from-literal key=value -n team-a

Output untuk keduanya:

Error from server (Forbidden): admission webhook "resourcesquotasstatus.hierarchycontroller.configmanagement.gke.io" denied the request: exceeded hierarchical quota in namespace "team-a": "team-a-hrq", requested: configmaps=1, used: configmaps=1, limited: configmaps=1

Periksa kuota

Untuk melihat batas dan penggunaan HierarchicalResourceQuota saat ini, gunakan perintah kubectl describe untuk melihat kuota resource reguler:

kubectl describe hrq team-a-hrq -n team-a

Output:

# ...other fields...
Spec:
  Hard:
    Configmaps:  1
Status:
  Hard:
    Configmaps:  1
  Used:
    Configmaps:  1

Memperbarui hierarki namespace

Namespace selalu bergantung pada HierarchicalResourceQuota apa pun pada ancestornya. Mengubah hierarki namespace akan memicu penghitungan ulang penggunaan kuota.

Menghapus namespace dari subhierarki yang memiliki kuota hierarki

Jika dipindahkan dari subhierarki dengan kuota hierarkis pada ancestornya, namespace tidak lagi tunduk pada kuota ini, dan resource-nya akan dihapus dari penggunaan kuota.

Misalnya, jika team-b dihapus dari sub-hierarki sebelumnya, tidak akan ada batasan pada konsumsi configmap di team-b. Penggunaan kuota hierarkis direset ke 0, yang berarti team-a dan service-a kini dapat memakai satu lagi configmap secara total.

Menambahkan namespace ke subhierarki dengan kuota hierarki

Saat ditambahkan ke subhierarki dengan kuota hierarkis, namespace akan mengikuti kuota hierarkis dan penggunaan resource-nya ditambahkan ke penggunaan kuota.

Misalnya, jika namespace lain ditambahkan ke subhierarki sebelumnya, penggunaan configmap lagi tidak diizinkan dalam namespace yang baru ditambahkan. Demikian pula, setiap penggunaan configmap yang ada dalam namespace yang baru ditambahkan akan ditambahkan ke penggunaan kuota hierarkis.

Kuota hierarki tidak mencegah Anda memindahkan namespace baru ke sub-hierarki, meskipun penggunaan namespace baru tersebut melampaui batas kuota hierarki. Namun, jika batas terlampaui, penggunaan resource lebih lanjut akan diblokir hingga penggunaan tersebut berada di bawah batas, atau hingga batas tersebut dinaikkan. Hal ini serupa dengan perilaku ResourceQuota Kubernetes saat dikenai batas yang lebih rendah dari penggunaan yang ada dalam namespace.

Aturan umum

Kuota resource hierarkis memiliki perilaku yang mirip dengan kuota resource Kubernetes dalam kasus pojok. Contoh:

  • Jika beberapa kuota resource hierarkis berlaku untuk namespace yang sama, batas resource yang paling ketat akan diterapkan.
  • Jika Anda membuat batas yang lebih rendah dari jumlah resource yang sudah dipakai, resource yang ada tidak akan dihapus, tetapi konsumsi resource di masa mendatang dilarang sampai penggunaan turun di bawah batas atau batas dinaikkan.

Pemecahan masalah

InternalError ketika menggunakan resource

Misalnya, saat Anda menggunakan resource, saat membuat configmap, permintaan Anda mungkin berhenti merespons selama 10 detik, dan Anda mendapatkan pesan error berikut:

Error from server (InternalError): Internal error occurred: resource quota evaluates timeout

Anda tidak akan melihat pesan error ini kecuali jika Pod gke-hc-controller-manager dalam keadaan buruk.

Untuk memperbaiki masalah ini, administrator yang memiliki izin dapat menghapus Pod dengan langsung menggunakan awalan gke-hc-controller-manager- di namespace hnc-system. Pod dimulai ulang secara otomatis. Sebelum Pod siap, perhatikan hal-hal berikut:

Jika cara ini tidak memperbaiki masalah, laporkan kepada kami untuk dianalisis, sebaiknya dengan log yang bisa Anda peroleh menggunakan hal berikut:

kubectl logs -n hnc-system deployment/gke-hc-controller-manager -c manager

Langkah selanjutnya