---
title: "Kubernetes Skalierung in der Google Cloud"
description: "Erfahre anhand eines API-Praxisbeispiels, wie der Horizontal Pod Autoscaler eingerichtet werden kann."
canonical_url: "https://www.blueshoe.de/blog/kubernetes-skalierung-gke/"
---

In diesem Artikel geht es um die Möglichkeit, Kubernetes Workloads in der Google Cloud einfach und nachhaltig zu skalieren.

![Blueshoe und FastAPI: Dokumentation mit Programmierbeispielen](/img/blogs/gke-hpa.svg)

<global-title :size="lg" className="mb-5">

Skalierung der API - zu viel und zu wenig

</global-title>

<global-paragraph>

Kubernetes erlaubt es bereits auf einfache Art und Weise, Workloads zu skalieren. Für diesen Artikel wird eine zustandslose (stateless) Application angenommen - eine simple REST API.

</global-paragraph>

<global-paragraph>

Diese ist in Form eines Deployments mit 4 Replicas (je 125 mCPU und 250 Mi Memory) im GKE Autopilot Cluster vorhanden.

</global-paragraph>

<global-paragraph>

**Problemstellung:** Nachts laufen diese 4 Replicas nahezu ohne Last. Am Tag reichen diese teilweise nicht aus.

</global-paragraph>

<global-paragraph>

**Lösung:** Automatische Skalierung der Services basierend auf deren Auslastung.

</global-paragraph>

<global-paragraph>

*Im schlechtesten Falle werden die Applikationen während hoher Last noch OOM Killed - weil sie zu viel Speicher verbrauchen.*

</global-paragraph>

<global-button :color="blue" :label="Erfahre mehr über unsere Infrastrukur-Entwicklungsdienste" :url="/loesungen/cloud-infrastruktur-beratung/" className="mb-6">



</global-button>

<global-title :size="md" className="mb-5" :color="text-bs-blue" :font="font-oswald" :tag="h3">

Wie viel CPU oder Arbeitsspeicher brauchen meine Pods?

</global-title>

<global-paragraph>

Bevor die Skalierung konfiguriert wird, ist es wichtig herauszufinden, - was eigentlich
typische Metriken für das Verhalten der zu skalierenden Applikation sind . Verbraucht diese viel CPU oder viel Arbeitsspeicher? Gibt es eine andere Metrik, welche mir Aufschluss über die Auslastung gibt (z.B. *Request Queue*-Länge)?

</global-paragraph>

![GKE Metrics](/img/blogs/gke-hpa-1.png)

<global-paragraph className="mb-4">

Ein einfacher Blick in die Google Cloud Dashboards unserer REST API zeigt, dass der Arbeitsspeicher schwankt und die CPU ab einem bestimmten Zeitpunkt eine recht konstante Auslastung hat. Die blaue Linie zeigt die tatsächliche Auslastung, die rote Linie die Limits.
Der Arbeitsspeicher scheint hier deutlich volatiler und näher an seinen Limits - für die Skalierung unserer Applikation in Kubernetes wird der Memory als Grundlage genutzt.

</global-paragraph>

<global-paragraph>

Nun ist zwar klar, welche Metrik hergenommen wird, allerdings noch nicht, was die notwendigen Parameter sind. Die Memory Auslastung fällt selten unter 250 MB, was bedeutet, dass mindestens 2 Pods ständig verfügbar sein sollten.
Wir laufen selten, aber zuverlässig an die Kapazitätsgrenze der aktuell 4 verfügbaren Replicas. Also nehmen wir mit etwas Puffer maximal 6 Replicas als höchste Auslastung an.

</global-paragraph>

<global-paragraph>

*Anmerkung: Stark fluktuierende Auslastung des Arbeitsspeichers deutet auf Probleme in der Applikation hin. In diesem Falle ein Memory-Leak einer Abhängigkeit, welche nicht verändert werden kann.*

</global-paragraph>

<global-title :size="md" className="mb-5" :color="text-bs-blue" :font="font-oswald" :tag="h3">

Skalierung in Kubernetes: der Horizontal Pod Autoscaler

</global-title>

<global-paragraph>

Die Google Cloud erlaubt sowohl vertikale als auch horizontale Skalierung von Workloads. Vertikale Skalierung bedeutet, dass die verfügbaren Ressourcen (CPU, Memory) von Pods skaliert werden. Horizontale Skalierung erzeugt und entfernt ganze Pods desselben Deployments.

</global-paragraph>

![Google Cloud Menu](/img/blogs/gke-hpa-2.png)

<global-paragraph>

Die grundlegenden Parameter sind schnell erstellt - das Minimum und Maximum der Skalierung der API ist mit den folgenden 2 Feldern erledigt:

</global-paragraph>

![HPA Configure 1](/img/blogs/gke-hpa-3.png)

<global-call-an-expert :bg="bg-bs-blue">
<template v-slot:buttonBlockTitle="">

Wir können auch Deine Apps dynamisch an den Bedarf anpassen.

</template>
</global-call-an-expert>

<global-paragraph>

Doch was ist nun die Baseline für die Skalierung selbst? Es wird einfach - für unser Beispiel - eine gewünschte “Idealauslastung” pro Pod festgelegt. Das Limit eines jeden Pods liegt bei 250 MB. Mit einer Auslastung von 80% oder 200 MB kommen wir (mit etwas Puffer) an die Belastungsgrenze des Services und brauchen eine neue Instanz.

</global-paragraph>

![HPA Configure Metrics](/img/blogs/gke-hpa-4.png)

<global-paragraph className="mb-4">

Da das definierte Minimum 2 Pods sind - wird, sobald die Memory Auslastung im Schnitt 400 MB überschreitet, ein weiterer Pod hinzu skaliert. Wird diese dann wieder unterschritten, so entfernt der Horizontal Pod Autoscaler (HPA) diesen auch wieder.

</global-paragraph>

<global-paragraph>

Für alle Kubernetes Experten - natürlich lässt sich der HPA auch über Kubernetes Ressourcen definieren und somit als Konfiguration im Cluster hinterlegen - das typische DevOps Vorgehen.

</global-paragraph>

<blog-code className="mb-5">

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: store-autoscale
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: store-autoscale
  minReplicas: 2
  maxReplicas: 6
  metrics:
    - resource:
        name: memory
        target:
          averageValue: 200
          type: AverageValue
```

</blog-code>

<global-title :size="lg" className="mb-5">

Fazit

</global-title>

<global-paragraph className="mb-8">

Mit ein paar Klicks - oder auch einer einfachen Kubernetes Ressourcen - lassen sich Kosten sparen und die Lastspitzen der REST API einfach abfangen.

</global-paragraph>

## Sitemap

See the full [sitemap](/sitemap.md) for all pages.