Menggunakan kuota resource hierarkis

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

Pengontrol Hierarki memperluas konsep kuota resource per namespace untuk mendukung hierarki namespace. Objek HierarchicalResourceQuota membatasi resource gabungan di seluruh namespace di suatu subtree, yang memungkinkan administrator membatasi konsumsi resource di beberapa namespace yang terkait.

Jika kuota resource hierarki diaktifkan, Pengontrol Hierarki menginstal dua memvalidasi webhook penerimaan , satu untuk benar-benar memberlakukan batas konsumsi sumber daya dan yang lainnya untuk memvalidasi kuota resource hierarkis.

Mengaktifkan kuota resource hierarki

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

  1. Instal Hierarchy Controller, menggunakan Config Sync 1.6.2 atau yang lebih baru.

  2. Di 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 resource hierarkis kuota dapat digunakan di cluster Anda.

Untuk memastikan bahwa kuota resource hierarki telah diaktifkan, ikuti langkah-langkah berikut:

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

    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 bahwa objek ResourceQuota baru yang disebut gke-hc-hrq telah 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 secara otomatis dihapus:

    kubectl get resourcequota gke-hc-hrq -n default
    

    Output:

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

Menggunakan kuota resource hierarki

Menetapkan kuota

Menetapkan HierarchicalResourceQuota sama dengan menetapkan ResourceQuota, tetapi dengan apiVersion dan kind yang berbeda; Oleh karena itu, Anda Anda dapat mengatur batas 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 yang disebut team-b, yang semuanya diwakili oleh namespace hierarkis sebagai berikut:

kubectl hns tree team-a

Output:

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

Jika Anda ingin membatasi jumlah configmaps di team-a, tetapi tanpa membatasi jumlah dalam turunan, 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 dalam team-a dan digabungkan dengan turunan, ganti apiVersion dan kind di contoh:

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

Tetapi, setiap upaya lebih lanjut untuk membuat configmap baru di salah satu dari tiga namespace gagal, termasuk dalam namespace 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 saat ini dan penggunaan HierarchicalResourceQuota, 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 dalam ancestor. Mengubah hierarki namespace akan memicu penghitungan ulang penggunaan kuota berapa pun.

Menghapus namespace dari subtree dengan kuota hierarki

Saat namespace dipindahkan dari subtree dengan kuota hierarkis di ancestor-nya, data tersebut tidak lagi tunduk kuota, dan resource-nya dihapus dari tingkat tinggi.

Misalnya, jika team-b dihapus dari subhierarki sebelumnya, tidak akan ada batas pemakaian configmap di team-b. Penggunaan kuota hierarkis direset ke 0, yang berarti bahwa team-a dan service-a sekarang dapat memakai satu total configmap lebih banyak.

Menambahkan namespace ke subtree dengan kuota hierarki

Jika namespace ditambahkan ke subtree dengan kuota hierarkis, namespace tersebut akan diubah ke kuota hierarki, dan penggunaan resourcenya ditambahkan ke tingkat tinggi.

Misalnya, jika namespace lain ditambahkan ke subpohon sebelumnya, Konsumsi configmap diizinkan di 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 subtree, bahkan jika penggunaan namespace baru melebihi batas dalam kuota hierarkis. Namun, jika batas terlampaui, penggunaan resource lebih lanjut diblokir sampai penggunaannya turun di bawah batas, atau sampai batasnya akan dimunculkan. Hal ini serupa dengan perilaku ResourceQuota Kubernetes saat diterapkan, yang lebih rendah dari penggunaan yang ada dalam namespace.

Aturan umum

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

  • Jika beberapa kuota resource hierarkis berlaku untuk namespace yang sama, kuota batasan resource dipatuhi.
  • Jika Anda membuat batas yang lebih rendah dari jumlah yang sudah digunakan resource, resource yang ada tidak akan dihapus, tapi resource mendatang dilarang sampai penggunaan turun di bawah batas atau batas akan dimunculkan.

Pemecahan masalah

InternalError saat menggunakan resource

Saat menggunakan resource, misalnya, saat membuat configmap, mungkin berhenti merespons selama 10 detik, dan Anda akan mendapatkan error berikut pesan:

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

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

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

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

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

Langkah selanjutnya