Ich betreibe einen Cluster, der von mehreren Teams gemeinsam genutzt wird, und möchte jedem Team eine Mindestmenge an Ressourcen, insbesondere Speicher, garantieren.
Im Anschluss an dieAnweisungenIch habe versucht, Folgendes in ihrem Namespace zu verwenden:
apiVersion: v1
kind: ResourceQuota
metadata:
name: mem-quota
spec:
hard:
requests.memory: 8Gb
Aus weiteren Dokumenten geht jedoch hervor, dass dies keine Garantie dafür ist, dass sie 8 GB Speicher für ihre Pods haben. Es bedeutet lediglich, dass die Summe der Pod- requests.memoryWerte 8 GB nicht überschreiten kann. Es ist möglich, dass sie 8 GB wie oben festgelegt haben, nur 4 GB verwenden und keinen neuen Pod erstellen können, wenn der Cluster an anderer Stelle voll ausgelastet ist und der neue Pod nicht geplant werden kann.
Außerdem kann ich beispielsweise auf einem Cluster mit nur 8 Gi Gesamtspeicher ein Repository ResourceQuotamit einem Wert von 16 Gi erstellen.requests.memory
Gibt es eine Möglichkeit, einem Team eine feste Speichermenge zu garantieren, die ausschließlich für den eigenen Gebrauch zur Verfügung steht?
Antwort1
Es bedeutet lediglich, dass die Summe der Anfragen ihrer Pods. Der Speicherwert darf 8 GB nicht überschreiten.
Ja, das ist die Logik für ResourceQuota. VonGrundlegendes zu Ressourcenkontingenten:
Ressourcenkontingente funktionieren folgendermaßen:
Benutzer stellen Anforderungen für Rechenressourcen an ihre Pods.Die Summe aller Ressourcenanforderungen aller Pods im selben Namespace darf kein festes Ressourcenlimit in einem Ressourcenkontingentdokument für den Namespace überschreiten.Beachten Sie, dass wir das Ressourcenkontingent früher anhand der Summe der Ressourcenlimits der Pods überprüft haben. Dies wurde jedoch geändert, um Ressourcenanforderungen zu verwenden. Die Abwärtskompatibilität für die zuvor erstellten Pods bleibt erhalten, da die Ressourcenanforderungen von Pods, die nur ein Ressourcenlimit angeben, standardmäßig ihren definierten Limits entsprechen. Dem Benutzer werden nur die Ressourcen in Rechnung gestellt, die er im Ressourcenkontingent im Vergleich zu seinen Limits anfordert, da die Anforderung die Mindestmenge an Ressourcen ist, die der Cluster während der Planung garantiert. Weitere Informationen zum Überbeanspruchen finden Sie unter Compute-Resources.
Wenn das Erstellen eines Pods dazu führen würde, dass der Namespace eine der im Ressourcenkontingent für diesen Namespace angegebenen Grenzen überschreitet, schlägt die Anforderung mit dem HTTP-Statuscode 403 FORBIDDEN fehl.
Wenn in einem Namespace Kontingente aktiviert sind und der Benutzer keine Anforderungen an den Pod für jede der Ressourcen angibt, für die Kontingente aktiviert sind, schlägt der POST des Pods mit dem HTTP-Statuscode 403 FORBIDDEN fehl. Tipp: Verwenden Sie den LimitRange-Zulassungscontroller, um Standardwerte für Grenzwerte zu erzwingen (dann entsprechen Ressourcenanforderungen standardmäßig den Grenzwerten, siehe Zulassungscontroller), bevor das Kontingent überprüft wird, um dieses Problem zu vermeiden.
Der Artikel wird jedoch in Fällen, in denen Sie Ressourcen separat aufteilen müssen, etwas erweitert. Und das ist noch nicht implementiert.
Kontingent und Clusterkapazität: Manchmal sind möglicherweise komplexere Richtlinien erforderlich, beispielsweise:
- Die gesamten Clusterressourcen proportional auf mehrere Teams aufteilen.
- Ermöglichen Sie jedem Mieter, die Ressourcennutzung nach Bedarf zu steigern, legen Sie jedoch ein großzügiges Limit fest, um eine versehentliche Erschöpfung der Ressourcen zu verhindern.
- Bedarf aus einem Namespace erkennen, Knoten hinzufügen und Kontingent erhöhen.
Solche Richtlinien könnten mit ResourceQuota als Baustein implementiert werden, indem ein „Controller“ geschrieben wird, der die Kontingentnutzung überwacht und die Kontingentgrenzen jedes Namespaces entsprechend anderer Signale anpasst.
Ich gehe davon aus, dass Sie eine benutzerdefinierte Logik in Ihrem eigenen Controller schreiben müssen.
Bitte schauen Sie sich auch anSo erzwingen Sie mithilfe von OPA, dass Kubernetes-Namespaces über ResourceQuotas verfügen