Namespaces und Quotas

Einführung

Ein Kubernetes-Cluster ist wie ein großes Wohnhaus.

Wenn alle in der Eingangshalle wohnen würden, wäre es chaotisch. Sie wüssten nicht, wem welches Möbelstück gehört, und ein lauter Nachbar könnte alle anderen stören.

Namespaces teilen einen Cluster logisch auf. So können verschiedene Teams, Umgebungen oder Anwendungen ihre Ressourcen getrennt organisieren.

ResourceQuotas begrenzen, wie viele bestimmte Ressourcen ein Namespace verbrauchen darf. Dadurch lässt sich verhindern, dass ein Team oder eine Workload die gemeinsam genutzte Kapazität des Clusters vollständig aufbraucht.

In diesem Lab werden Sie:

ein neues „Apartment“ (Namespace) mit dem Namen dev erstellen;
ein strenges „Stromlimit“ (ResourceQuota) für dieses Apartment festlegen;
versuchen, Möbel (Pods) in das Apartment zu stellen, und prüfen, ob sie hineinpassen.

Einen Namespace erstellen

In diesem Schritt erstellen Sie einen neuen Namespace, um die Ressourcen eines Entwicklungsteams zu isolieren.

Ein Namespace ist eine logische Grenze innerhalb eines Clusters und kein separater Cluster. Teams verwenden weiterhin dieselbe Control Plane und dieselben zugrunde liegenden Nodes. Namen, Richtlinien und viele Ressourcenansichten können jedoch getrennt werden, damit die Arbeit übersichtlich bleibt.

Standardmäßig wird alles im Namespace default abgelegt – in unserer Analogie in der Eingangshalle. Sehen Sie sich zunächst an, welche Namespaces derzeit existieren:

kubectl get namespaces

Sie sollten default, kube-system (dort befinden sich die Hausverwalter) und einige weitere Namespaces sehen.

Erstellen Sie nun das Apartment dev:

kubectl create namespace dev

Überprüfen Sie, ob es existiert:

kubectl get namespaces

In der Liste wird dev angezeigt. Es ist derzeit ein leeres Apartment ohne Wände und ohne Limits – Sie können beliebige Ressourcen darin ablegen.

Ressourcenlimits anwenden

Jetzt müssen wir die Regeln festlegen. Das dev-Team soll nicht die gesamte CPU- und Speicherkapazität des Clusters aufbrauchen.

Dazu erstellen wir ein ResourceQuota-Objekt. Damit legen wir fest: „Im Namespace dev dürfen höchstens 2 CPUs und 2Gi Speicher verwendet werden.“

Quotas sind in gemeinsam genutzten Clustern besonders wichtig, weil CPU und Arbeitsspeicher begrenzt sind. Ohne Quotas könnte eine besonders ressourcenintensive Workload mehr als ihren fairen Anteil verbrauchen und den Cluster für alle anderen unzuverlässig machen. Quotas dienen daher nicht nur der Abrechnung. Sie sind auch ein Werkzeug zur Stabilisierung.

Erstellen Sie eine Datei mit dem Namen quota.yaml:

nano quota.yaml

Fügen Sie die folgende Konfiguration ein:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

Speichern Sie die Datei und beenden Sie den Editor (Ctrl+X, Y, Enter).

Wenden Sie diese Regel auf den Cluster an:

kubectl apply -f quota.yaml

Sie können die Details der Regel anzeigen. Dabei sehen Sie das „Hard“-Limit (den von Ihnen festgelegten Wert) und den aktuell verwendeten Wert unter „Used“ (derzeit 0).

kubectl describe resourcequota dev-quota --namespace=dev

Einen Pod bereitstellen

Nachdem die Regeln festgelegt sind, versuchen wir nun, einzuziehen.

Wichtige Regel: Wenn für ein Apartment ein Limit gilt, muss für jedes Möbelstück, das Sie hineinbringen, seine Größe angegeben sein. In Kubernetes bedeutet das: Wenn für einen Namespace ein Quota gilt, muss jeder Pod explizite resources-Angaben für Requests und Limits enthalten. Andernfalls wird Ihnen der Hausverwalter (Kubernetes) den Zutritt verwehren.

Hier treffen zwei verwandte Konzepte aufeinander. Ein Request teilt dem Scheduler mit, wie viele Ressourcen dem Pod bei seiner Platzierung garantiert zur Verfügung stehen sollen. Ein Limit bezeichnet die maximale Ressourcenmenge, die der Container verwenden darf. Quotas addieren diese Requests und Limits innerhalb eines Namespace, damit die Gesamtsumme die festgelegten Richtlinien nicht überschreitet.

Erstellen Sie eine Datei mit dem Namen pod.yaml:

nano pod.yaml

Fügen Sie die folgende Konfiguration ein. Beachten Sie, dass die Größe dieses Pods ausdrücklich angegeben wird:

apiVersion: v1
kind: Pod
metadata:
  name: dev-pod
  namespace: dev ## <-- Putting it in the 'dev' apartment
spec:
  containers:
    - name: nginx
      image: nginx
      resources:
        requests:
          memory: "128Mi"
          cpu: "250m"
        limits:
          memory: "256Mi"
          cpu: "500m"

Speichern Sie die Datei und beenden Sie den Editor (Ctrl+X, Y, Enter).

Stellen Sie den Pod bereit:

kubectl apply -f pod.yaml

Prüfen Sie, ob der Pod im Namespace dev ausgeführt wird:

kubectl get pods --namespace=dev

Warten Sie, bis in der Spalte STATUS der Wert Running angezeigt wird.

Prüfen Sie anschließend erneut die Quota-Nutzung. Der Wert in der Spalte „Used“ ist jetzt gestiegen.

kubectl describe resourcequota dev-quota --namespace=dev

Damit verfolgen Sie erfolgreich, wie die Ressourcennutzung auf Ihr festgelegtes Budget angerechnet wird.

Isolation überprüfen

Überprüfen wir zum Schluss, ob die „Wände“ unseres Apartments tatsächlich vorhanden sind.

Bei der Namespace-Isolation geht es hauptsächlich um Namen, Richtlinien und den Geltungsbereich von Operationen. Sie bedeutet nicht, dass die Workloads standardmäßig auf physisch getrennten Geräten ausgeführt werden. Dieser Unterschied wird später wichtig, wenn Sie die Auswahl von Nodes und stärkere Isolationsmechanismen kennenlernen.

Wir haben dev-pod im Namespace dev abgelegt. Im Eingangsbereich (default) sollte er nicht sichtbar sein.

Listen Sie die Pods im Namespace default auf:

kubectl get pods

Sie sollten No resources found in default namespace sehen (oder zumindest nicht den Pod dev-pod).

Prüfen Sie nun, ob im Namespace default ein Quota vorhanden ist:

kubectl get resourcequota

Sie sollten keine Ausgabe erhalten. Das festgelegte Stromlimit gilt nur für das Apartment dev, nicht für das gesamte Wohnhaus.

Damit ist bestätigt, dass Namespaces eine echte Isolation für Ihre Teams bereitstellen.

Zusammenfassung

In diesem Lab haben Sie die Rolle eines Hausverwalters für Ihren Kubernetes-Cluster übernommen.

Sie haben erfolgreich:

einen privaten Namespace (dev) für ein Team erstellt;
eine strenge ResourceQuota (ein Stromlimit) festgelegt, um übermäßigen Verbrauch zu verhindern;
eine Anwendung bereitgestellt, die diese Limits einhält;
überprüft, dass die Wände zwischen den Namespaces die Ressourcen voneinander isolieren.

Auf diese Weise können große Organisationen einen einzigen Kubernetes-Cluster mit Hunderten von Teams gemeinsam nutzen, ohne dass sich die Teams gegenseitig in die Quere kommen.