Menggunakan kuota resource hierarkis

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

Hierarchy Controller memperluas konsep kuota resource per namespace untuk mendukung namespace hierarkis. Objek HierarchicalResourceQuota membatasi konsumsi resource agregat di seluruh namespace dalam sub-pohon, sehingga administrator dapat membatasi konsumsi resource di beberapa namespace terkait.

Jika kuota resource hierarkis diaktifkan, Pengontrol Hierarki akan menginstal dua webhook validasi izin , satu untuk benar-benar menerapkan batas penggunaan resource dan yang lainnya untuk memvalidasi kuota resource hierarkis itu sendiri.

Mengaktifkan 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 Operator ConfigManagement, dalam 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, kuota resource hierarki dan Pengontrol Hierarki dapat digunakan di cluster Anda.

Untuk memverifikasi bahwa kuota resource hierarkis diaktifkan, ikuti langkah-langkah berikut:

  1. Buat objek HierarchicalResourceQuota di namespace mana 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 dibuat di 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 otomatis 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 dengan menetapkan ResourceQuota reguler, tetapi dengan apiVersion dan kind yang berbeda; oleh karena itu, Anda dapat menetapkan batas pada resource di kolom spec.hard seperti yang Anda lakukan di ResourceQuota.

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

kubectl hns tree team-a

Output:

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

Jika ingin membatasi jumlah configmaps di team-a, tetapi tanpa membatasi jumlahnya di turunan apa pun, Anda dapat membuat ResourceQuota reguler sebagai 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 di team-a dan turunan yang digabungkan, ganti apiVersion dan kind dalam 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 dapat 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, upaya lebih lanjut untuk membuat configmap baru di salah satu dari tiga namespace tersebut gagal, termasuk di namespace saudara 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

Memeriksa 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 tunduk pada HierarchicalResourceQuota apa pun di ancestor-nya. Mengubah hierarki namespace akan memicu penghitungan ulang penggunaan kuota.

Menghapus namespace dari sub-pohon dengan kuota hierarkis

Jika namespace dipindahkan dari sub-pohon dengan kuota hierarkis di ancestor-nya, namespace tersebut tidak lagi tunduk pada kuota ini, dan resource-nya akan dihapus dari penggunaan kuota.

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

Menambahkan namespace ke sub-pohon dengan kuota hierarkis

Saat namespace ditambahkan ke sub-pohon dengan kuota hierarkis, namespace tersebut akan tunduk pada kuota hierarkis, dan penggunaan resource-nya akan ditambahkan ke penggunaan kuota.

Misalnya, jika namespace lain ditambahkan ke sub-pohon sebelumnya, tidak ada konsumsi configmap lebih lanjut yang diizinkan di namespace yang baru ditambahkan. Demikian pula, penggunaan configmap yang ada di namespace yang baru ditambahkan akan ditambahkan ke penggunaan kuota hierarkis.

Kuota hierarkis tidak mencegah Anda memindahkan namespace baru ke sub-pohon, meskipun penggunaan namespace baru melebihi batas dalam kuota hierarkis. Namun, jika batas terlampaui, penggunaan resource lebih lanjut akan dilarang hingga penggunaan turun di bawah batas, atau hingga batas dinaikkan. Hal ini mirip dengan perilaku ResourceQuota Kubernetes saat batas yang lebih rendah dari penggunaan yang ada di namespace diterapkan.

Aturan umum

Kuota resource hierarkis berperilaku mirip dengan kuota resource Kubernetes dalam kasus ekstrem. Contoh:

  • Jika beberapa kuota resource hierarkis berlaku untuk namespace yang sama, batas resource yang paling membatasi akan dipatuhi.
  • Jika Anda membuat batas yang lebih rendah dari jumlah resource yang sudah digunakan, resource yang ada tidak akan dihapus, tetapi penggunaan resource pada masa mendatang akan dilarang hingga penggunaan turun di bawah batas atau batas dinaikkan.

Pemecahan masalah

InternalError saat menggunakan resource

Saat menggunakan resource, misalnya, 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 status buruk.

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

Jika cara ini tidak menyelesaikan masalah, laporkan kepada kami untuk dianalisis, sebaiknya dengan log yang dapat Anda dapatkan menggunakan hal berikut:

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

Langkah selanjutnya