Gardener Kubernetes

Die Gardener-Plattform der noris Sovereign Cloud (nSC) automatisiert Verwaltung und Betrieb von Kubernetes-Clustern als Service. Weitere Informationen finden Sie in der Gardener-Dokumentation.

Erste Schritte

Dieser Abschnitt führt Sie durch die Schritte zum Erstellen, Zugreifen auf und Verwalten Ihres ersten Kubernetes-Clusters mit der nSC.

Zugriff auf das Dashboard

Unser Dashboard in Nürnberg (“NBG”) ist hier verfügbar: dashboard.ingress.garden-runtime.k8s.nsc02.noris.cloud

Cluster erstellen

Falls Sie Zugriff auf mehrere Projekte haben, stellen Sie sicher, dass Sie das richtige Projekt aus dem Dropdown in der linken Seitenleiste auswählen:

Klicken Sie oben auf die Schaltfläche „+”, um mit dem Erstellen eines neuen Kubernetes-Clusters zu beginnen, in der Gardener-Terminologie „Shoot” genannt.

Konfiguration

Über die Cluster-Konfigurationsoberfläche können Sie die Cluster-Einstellungen an Ihre Bedürfnisse anpassen. Zur besseren Übersichtlichkeit werden hier nur die Einstellungen dokumentiert, die üblicherweise Aufmerksamkeit erfordern.

Infrastruktur

Gardener unterstützt derzeit nur unser eigenes nSC OpenStack als Infrastruktur-Provider. Sollte Ihr Anwendungsfall eine Bereitstellung bei gängigen Hyperscalern erfordern, kontaktieren Sie bitte Ihren Vertriebsansprechpartner für ein Angebot.

Cluster-Details

Cluster name: Gardener generiert einen zufälligen Standardnamen für Ihren Cluster, Sie können aber auch einen eigenen angeben.

Kubernetes version: Cluster können mit unterschiedlichen Kubernetes-Versionen erstellt werden. Es wird empfohlen, stets die neueste unterstützte Version zu verwenden. Beachten Sie hierzu unsere Richtlinie zu unterstützten Kubernetes-Versionen weiter unten.

Cluster purpose: Diese Option gibt den beabsichtigten Verwendungszweck bzw. die Produktionsreife des Clusters an. Weitere Informationen zu den verschiedenen Konfigurationen je nach Zweck finden Sie unter Shoot Purposes.

Control Plane High Availability

Gardener unterstützt hochverfügbare Control Planes. Das Aktivieren dieser Funktion richtet einen dreiknotigen etcd-Cluster ein, verteilt über unsere Rechenzentren innerhalb derselben Geolokation. Wenn Sie Konformität mit dem SovereignCloudStack-kompatiblen KaaS-Standard benötigen, muss diese Einstellung aktiviert sein. Ist sie deaktiviert, wird stattdessen ein einzelner etcd-Knoten verwendet.

DNS-Konfiguration

Dies ist eine erweiterte Konfiguration, die weiter unten im Abschnitt DNS näher erläutert wird. Einsteiger können dies zunächst ignorieren.

Worker

Group Name: Gardener generiert einen zufälligen Namen für Ihre Worker-Gruppe, Sie können aber auch einen eigenen angeben.

Machine Type: Wählen Sie den OpenStack-Flavor für Ihre Kubernetes-Worker-VMs. Eine Übersicht aller verfügbaren Flavors finden Sie unter Instanz-Flavors, dort können alle Optionen frei ausgewählt werden. Ein Wechsel des Flavors nach der Ersteinrichtung wird unterstützt; Gardener ersetzt daraufhin die VMs.

Machine Image: Ähnlich wie bei der Kubernetes-Version wird hier das Betriebssystem-Image festgelegt. Es wird empfohlen, stets die neueste unterstützte Version zu verwenden. Beachten Sie hierzu unsere Richtlinie zu unterstützten Machine Images weiter unten.

Volume Type: Wählen Sie den Volume-Typ für das Root-Volume Ihrer Worker-VMs. Eine Übersicht der verfügbaren Storage-Typen einschließlich rbd_fast und LUKS finden Sie unter Storage-Typen.

Volume Size: Legen Sie die Größe des Root-Volumes fest. Wir empfehlen 50 GB oder mehr. Geringere Werte können ebenfalls funktionieren, können aber bei hohem Logvolumen zu gering sein.

Autoscaling: Cluster mit mindestens einer Worker-Gruppe, bei der minimum < maximum Knoten konfiguriert sind, erhalten ein Autoscaler-Deployment, das eine dynamische Skalierung der Worker-Knoten je nach Bedarf ermöglicht. Erwägen Sie eine Erhöhung der Knotenanzahl, um die Auswirkungen eines einzelnen Knotenausfalls in Ihrem Cluster zu verringern.

Max. Surge: Cluster, die über mehrere Zonen verteilt sind, sollten diese Einstellung mindestens auf die Summe aller genutzten Zonen setzen, unsere übliche Empfehlung ist 3.

Zones: Ähnlich wie bei Control Plane High Availability oben können Sie Ihre Worker über verschiedene Rechenzentren innerhalb derselben Geolokation verteilen. Beachten Sie, dass PVCs in ihrer jeweiligen Availability Zone verbleiben und nicht zwischen Zonen repliziert werden. Falls Sie replizierten Speicher benötigen, ziehen Sie unseren S3-Speicher in Betracht.

Wartung

Gardener konfiguriert ein Wartungsfenster für automatisierte Cluster-Updates für:

• Kubernetes-Patch-Releases (Major- und Minor-Upgrades müssen manuell ausgelöst werden)
• Worker-Node-OS-Images

Der Standardwert dieses Zeitfensters kann sich zwischen Cluster-Erstellungen unterscheiden. Wird diese Option deaktiviert, ist der Benutzer selbst dafür verantwortlich, Updates manuell auszulösen, beachten Sie hierzu unsere Richtlinien zu unterstützten Kubernetes-Versionen und unterstützten Machine Images. Weitere Details finden Sie unter Shoot Maintenance in der Gardener-Dokumentation.

Hibernation

Falls Ihr Cluster nicht durchgehend laufen muss, können Sie einen Hibernation-Zeitplan konfigurieren, um Ihre Compute-Ressourcen automatisch auf null herunterzuskalieren. Bitte beachten Sie, dass Hibernation einer fairen Nutzung unterliegt und künftig eingeschränkt werden kann.

Erweiterte Konfiguration - YAML

Über den YAML-Tab können Sie die generierten Gardener Custom Resources direkt bearbeiten. So lassen sich Einstellungen vornehmen, die in der Konfigurationsoberfläche nicht verfügbar sind. Spätere Teile dieser Anleitung bitten Sie oft, Code-Ausschnitte zur Shoot-Deklaration hinzuzufügen, dafür ist dieser Tab gedacht.

Das volle Spektrum an Optionen zeigt die Upstream-Beispiel-Shoot-Konfiguration. OpenStack-spezifische Einstellungen sind zusätzlich in der Dokumentation des OpenStack-Providers beschrieben.

Netzwerk-Sizing

Das Standard-Netzwerklayout für Shoot-Cluster ist wie folgt. Dies kann in der Shoot-Deklaration angepasst werden:

10.44.0.0/24 for nodes
10.98.0.0/18 for services
10.194.0.0/18 for pods

Cluster, die mit diesen Netzwerkbereichen erstellt werden, sind in ihrer Größe begrenzt auf:

254 nodes (110 pods and 256 volumes per node)
Which results in 27.940 pods and 16.384 services

Um diese Grenzen zu erhöhen, setzen Sie die Netzwerkbereiche entsprechend in der YAML-Konfiguration des Shoots während der Shoot-Deklaration. Diese Einstellungen können bei bestehenden Clustern nicht nachträglich geändert werden, bitte konfigurieren Sie sie daher bereits bei der Cluster-Erstellung passend.

Bitte verwenden Sie keine der folgenden Präfixe, da diese für unsere Infrastruktur reserviert sind:

10.42.0.0/15
10.96.0.0/15
10.192.0.0/15

Zugriff auf einen Cluster

Um dieser Anleitung zu folgen, benötigen Sie folgende CLI-Tools:

• kubectl
• gardenlogin
• kubelogin (“oidc-login”)

Wir empfehlen, stets die aktuellsten Versionen dieser Tools zu verwenden.

Sobald der Cluster fertig gebootstrapt ist, können Sie den kubectl-Zugriff einrichten. Gardener unterstützt eine sichere Authentifizierung via OIDC mit gardenlogin und kubelogin. gardenctl kann als Ersatz für gardenlogin dienen; der Einfachheit halber wird in dieser Anleitung nur gardenlogin erklärt.

gardenlogin konfigurieren

Erstellen Sie die Konfigurationsdatei ~/.garden/gardenctl-v2.yaml mit folgendem Inhalt:

gardens:
  - identity: garden01-prod-nsc02
    kubeconfig: ~/.garden/kubeconfig-garden.yaml

Die in gardenctl-v2.yaml referenzierte Kubeconfig können Sie hier konfigurieren und herunterladen: dashboard.ingress.garden-runtime.k8s.nsc02.noris.cloud/account

kubectl verwenden

Sie können die passenden Kubeconfigs für Ihre Cluster über die Cluster-Übersicht herunterladen, indem Sie auf das Schlüsselsymbol klicken.

Laden Sie die Datei „Kubeconfig - Gardenlogin” herunter.

Speichern Sie sie im Verzeichnis ~/.kube/. Wenn Sie nur einen einzelnen Cluster verwalten, können Sie die Datei in ~/.kube/config umbenennen. Andernfalls gibt es mehrere Möglichkeiten, kubectl zu konfigurieren, eine Option ist, die Umgebungsvariable KUBECONFIG auf eine bestimmte Datei zeigen zu lassen:

❯ export KUBECONFIG=~/.kube/kubeconfig-gardenlogin--<project_id>--<cluster_name>.yaml

Login

Nach erfolgreicher Installation der benötigten Tools sollten Sie folgende Programme über compgen -c | grep kubectl in Ihrem PATH finden:

❯ compgen -c | grep kubectl
kubectl-oidc_login
kubectl-gardenlogin
kubectl

Zusätzlich wurden im Rahmen dieser Anleitung folgende Dateien erstellt:

• ~/.garden/gardenctl-v2.yaml
• ~/.garden/kubeconfig-garden.yaml
• ~/.kube/config (oder der von Ihnen gewählte Name)

Sie können nun auf Ihren ersten Cluster zugreifen:

❯ kubectl get nodes
NAME
shoot--example--example-worker-r6tfb-z1-76469-ttt8g
shoot--example--example-worker-r6tfb-z1-76469-xb9dv

Second Day Operations

Lifecycle-Management

Kubernetes

Unsere unterstützten Versionen sind während der Cluster-Erstellung leicht am „supported”-Flag erkennbar. Wir versuchen, den Vorgaben des Upstream-Kubernetes-Projekts eng zu folgen. Es ist unser Ziel, das jeweils neueste Patch-Release der drei aktuellsten Kubernetes-Minor-Versionen zu unterstützen. Die neueste Minor-Version kann zunächst nur als Preview verfügbar sein, während wir an der vollständigen Unterstützung arbeiten, für Preview-Releases bieten wir keine SLAs.

Alle Releases außer dem aktuellsten erhalten ein Ablaufdatum. Veraltete Patch-Releases werden als deprecated markiert. Wenn Sie automatische Kubernetes-Upgrades konfiguriert haben, werden Ihre Shoot-Cluster im Wartungsfenster auf das aktuellste Patch-Release aktualisiert.

Nach Erreichen des Ablaufdatums werden Shoot-Cluster mit einer veralteten Kubernetes-Version zwangsweise auf ein unterstütztes Minor-Release aktualisiert, unabhängig von der automatischen Update-Konfiguration. Da Upstream-Kubernetes aktiv veraltete Funktionen entfernt, empfehlen wir, Upgrades vorab zu testen und die Upstream-Release Notes sowie Deprecation Notices zu verfolgen.

Flatcar

Ihre unterstützte Version ist während der Cluster-Erstellung leicht am „supported”-Flag erkennbar. Wir streben an, das aktuellste Flatcar-Stable-Release zu unterstützen und die jeweils letzten 3 Images zur Installation bereitzuhalten. Die neueste Minor-Version kann zunächst nur als Preview verfügbar sein, während wir an der vollständigen Unterstützung arbeiten, für Preview-Releases bieten wir keine SLAs.

Ältere Releases werden mit einem Ablaufdatum als deprecated markiert. Wenn Sie automatische OS-Upgrades konfiguriert haben, werden Flatcar-Worker-Nodes mit veralteten Releases im nächsten Wartungsfenster auf das aktuellste Minor-Release aktualisiert.

Nach Erreichen des Ablaufdatums werden Worker-Nodes mit veralteten Flatcar-OS-Images zwangsweise auf eine unterstützte Version aktualisiert, unabhängig von der automatischen Update-Konfiguration. Die Auswirkungen von OS-Image-Upgrades auf Container-Workloads sind zwar selten, wir empfehlen dennoch, Upstream-Änderungen im Blick zu behalten und Upgrades vorab zu testen.

Storage-Optionen

Dokumentation zu den Storage-Optionen finden Sie unter OpenStack.

Control-Plane-Logs

Auf Control-Plane-Logs kann einfach über das Webinterface zugegriffen werden:

Suchen Sie nach "log":

Dieses Tool enthält Logs Ihres Control Planes, z.B. von etcd, MachineControllerManager, CSI-Driver und Cluster-Autoscaler. Logs Ihrer eigenen Pods, die auf Worker-Nodes laufen, werden dort nicht vorgehalten.

Gardener betreibt zudem eingebettete Prometheus- und Grafana-Instanzen für Control-Plane-Metriken, die über das Gardener-Dashboard zugänglich sind. Weitere Details finden Sie in der Gardener-Monitoring-Dokumentation.

Workload-Monitoring

Für das Monitoring Ihrer Workloads können Sie den Standard-Stack aus Prometheus, Grafana und Alertmanager selbst über den kube-prometheus-stack Helm-Chart in Ihren Shoot-Cluster installieren.

Netzwerk-Observability

Unser Standard-CNI Cilium bietet mit Hubble ein kostenloses Open-Source-Feature zur Netzwerk-Observability:

Um es zu nutzen, fügen Sie Folgendes zu Ihrer Shoot-Deklaration hinzu:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  networking:
    type: cilium
    providerConfig:
      overlay:
        enabled: true
      hubble:
        enabled: true

Anschließend können Sie mit folgendem Befehl auf ein Web-Frontend Ihrer Netzwerkflüsse auf Ihrem lokalen Rechner zugreifen. Die Cilium-Binärdatei erhalten Sie über die Cilium-CLI-Releases.

❯ cilium hubble ui
ℹ️  Opening "http://localhost:12000" in your browser...

Netzwerk - Node-zu-Node-Verschlüsselung

Um Node-zu-Node-Verschlüsselung in Cilium mittels WireGuard zu aktivieren (siehe Cilium-Dokumentation zur transparenten Verschlüsselung), deklarieren Sie die Verschlüsselung in Ihrem Shoot-Manifest:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  networking:
    type: cilium
    providerConfig:
      apiVersion: cilium.networking.extensions.gardener.cloud/v1alpha1
      kind: NetworkConfig
      encryption:
        enabled: true
        mode: wireguard

OpenStack Server Groups

Gardener erlaubt es Benutzern, über folgende Zusätze zur Shoot-Deklaration eine Server Group zu erstellen. Diese machen das darunterliegende OpenStack auf den Cluster aufmerksam und können hilfreich sein, um die Workload über mehrere Hardware-Knoten zu verteilen.

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  provider:
    type: openstack
    workers:
      - ...
        providerConfig:
          apiVersion: openstack.provider.extensions.gardener.cloud/v1alpha1
          kind: WorkerConfig
          serverGroup:
            policy: soft-anti-affinity

Registry Cache

Unser CRI, containerd, unterstützt die Verwendung von Registry-Mirrors. Diese Funktion hilft, Registry-Rate-Limits (z.B. hub.docker.com) zu umgehen und einen zentralen Container-Security-Scanner zu integrieren. Beispiel:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  extensions:
  - type: registry-mirror
    providerConfig:
      apiVersion: mirror.extensions.gardener.cloud/v1alpha1
      kind: MirrorConfig
      mirrors:
      - upstream: docker.io
        hosts:
        - host: "https://mirror.gcr.io"
          capabilities: ["pull"]

DNS

Standardmäßig erstellt unser openstack-designate eine Subdomain für Ihren Cluster:

Gardener bietet integrierte Hilfsmittel zur komfortablen Verwaltung von DNS-Einträgen:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  extensions:
  - type: shoot-dns-service

Fügen Sie anschließend folgende Annotationen zu Ihren Ingress-Deklarationen hinzu:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: registry
  annotations:
    # Let Gardener manage external DNS records for this Ingress.
    dns.gardener.cloud/dnsnames: "*" # Use "*" to collect domain names from .spec.rules[].host
    dns.gardener.cloud/ttl: "60"
    dns.gardener.cloud/class: garden

Für fortgeschrittenere Anwendungsfälle werfen Sie einen Blick in die vollständige Upstream-Dokumentation.

Eigene Subdomain nutzen

Die Nutzung einer eigenen Subdomain kann auf verschiedene Arten erfolgen:

a) Wenn Sie eine Subdomain Ihrer eigenen Domain an unseren OpenStack-DNS-Dienst „Designate” delegieren möchten, eröffnen Sie bitte ein Support-Ticket.

b) Alternativ kann Gardener DNS-Einträge über folgende externe DNS-Provider verwalten. Bitte beachten Sie, dass wir für externe DNS-Server keine SLAs anbieten können:

• openstack-designate
• aws-route53
• azure-dns
• azure-private-dns
• google-clouddns
• alicloud-dns
• infoblox-dns
• netlify-dns
• rfc2136

Die Zugangs-Secrets für Ihren externen DNS-Provider können Sie unter „Secrets” in der Gardener-UI hinzufügen.

Zertifikate

Gardener bietet integrierte Hilfsmittel, um kostenlose Zertifikate komfortabel über DNS-basierte Let’s-Encrypt-Challenges anzufordern. Dieses Beispiel zeigt zusätzlich das Erstellen der entsprechenden Einträge, da die Zertifikatserstellung entsprechende DNS-Einträge voraussetzt:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  extensions:
  - type: shoot-cert-service
    providerConfig:
      apiVersion: service.cert.extensions.gardener.cloud/v1alpha1
      kind: CertConfig
      issuers:
        - email: example@yourdomain.de
          name: custom-issuer # issuer name must be specified in every custom issuer request, must not be "garden"
          server: 'https://acme-staging-v02.api.letsencrypt.org/directory' # please test with staging first, then switch to prod letsencrypt
  - type: shoot-dns-service

Fügen Sie anschließend folgende Annotationen zu Ihren Ingress-Deklarationen hinzu:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: registry
  annotations:
    # Let Gardener manage external DNS records for this Ingress.
    dns.gardener.cloud/dnsnames: "*" # Use "*" to collect domain names from .spec.rules[].host
    dns.gardener.cloud/ttl: "60"
    dns.gardener.cloud/class: garden
    # Let Gardener manage Certificates.
    cert.gardener.cloud/purpose: managed
    cert.gardener.cloud/issuer: custom-issuer
    cert.gardener.cloud/commonName: "*.ingress.<yourClusterDomain>"
    cert.gardener.cloud/dnsrecord-class: garden # optional, only required on Garden runtime cluster
...

Für fortgeschrittene Anwendungsfälle werfen Sie einen Blick in die vollständige Upstream-Dokumentation, zum Beispiel die Nutzung des Service-Typs LoadBalancer oder das Anfordern eines Zertifikats als Secret.

Istio Service Mesh

Die Zertifikat- und DNS-Erweiterungen sind auch nützlich für die Installation eines Istio Service Mesh.

Loadbalancer

Das Erstellen von Service-Objekten vom Typ LoadBalancer erzeugt einen Load Balancer in OpenStack und nutzt ihn für Ihren Service. Ein häufiges Problem ist, dass sich die zugehörige Floating IP beim Löschen und erneuten Anwenden eines Service ändern kann. Um dies zu verhindern, muss eine Floating IP manuell in OpenStack angelegt und beim Erstellen des Service angegeben werden:

apiVersion: 'v1'
kind: 'Service'
metadata:
  annotations:
    loadbalancer.openstack.org/keep-floatingip: "true"
    loadbalancer.openstack.org/load-balancer-address: <floatingip>
spec:
  type: 'LoadBalancer'
  loadBalancerIP: <floatingip>

Bei Ingress-Ressourcen muss dies für den Service des Ingress-Controllers gesetzt werden.

Datensicherung und -wiederherstellung

Bitte beachten Sie, dass die nSC von Kunden erstellte Inhalte nicht sichert. Es liegt in der Verantwortung des Kunden, seine Daten zu sichern, beispielsweise Metadaten (Deklarationen von Services, Ingresses, Pods usw.), den Inhalt von PVs (z.B. postgre-01) und den Inhalt von S3-Buckets. Velero ist ein beliebtes Open-Source-Tool, das dabei unterstützen kann.

Sicherheit - SSH-Zugriff deaktivieren

Der SSH-Zugriff kann deaktiviert werden, indem Sie folgende Einstellung in der Shoot-Deklaration angeben:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  provider:
    workersSettings:
      sshAccess:
        enabled: false

Sicherheit - etcd-Verschlüsselung

Die nSC sichert das etcd des Shoots regelmäßig. Dieses Backup wird für Migrationen von Control Planes zwischen Seeds und die automatisierte etcd-Wiederherstellung genutzt. Bitte beachten Sie, dass dies auf Best-Effort-Basis erfolgt und die letztendliche Verantwortung für die Sicherung von Benutzerdaten beim Kunden liegt.

Shoot-Deklarationen können festlegen, welche etcd-Felder verschlüsselt werden müssen. Secrets werden immer verschlüsselt:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  kubernetes:
    kubeAPIServer:
      encryptionConfig:
        resources:
          - configmaps

Details stehen in der Gardener-Dokumentation zur etcd-Verschlüsselung.

Sicherheit - Seccomp Profile RuntimeDefault

Gardener erlaubt es Benutzern, das Standard-seccompProfile vom uneingeschränkten Unconfined auf das restriktivere RuntimeDefault umzustellen, indem Sie Folgendes in Ihrer Shoot-Deklaration angeben:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  kubernetes:
    kubelet:
      seccompDefault: true

Details stehen in der Gardener-Dokumentation zum Seccomp-Profil.

Sicherheit - PodSecurity Admission Plugins

Gardener erlaubt es Benutzern, ihre PodSecurity-Admission-Standardwerte in der Shoot-Deklaration zu konfigurieren. Diese kommen zum Einsatz, wenn eine Anwendung keine Mode-Labels setzt:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  kubernetes:
    kubeAPIServer:
      admissionPlugins:
      - name: PodSecurity
        config:
          apiVersion: pod-security.admission.config.k8s.io/v1
          kind: PodSecurityConfiguration
          # Level label values must be one of:
          # - "privileged" (default)
          # - "baseline"
          # - "restricted"
          defaults:
            enforce: "baseline"
            audit: "baseline"
            warn: "baseline"
          exemptions:
            # Array of authenticated usernames to exempt.
            usernames: []
            # Array of runtime class names to exempt.
            runtimeClasses: []
            # Array of namespaces to exempt.
            namespaces: []

Details stehen in der Gardener-Dokumentation zu Pod Security.

Strukturierte Authentifizierung für Ihren Shoot hinzufügen

In Gardener authentifizierte Benutzer erhalten volle Admin-Rechte innerhalb Ihres Shoot-Clusters. Dieser Teil der Anleitung beschreibt ein funktionierendes Beispiel dafür, wie Sie OIDC und RBAC implementieren könnten, um zusätzliche, weniger privilegierte Benutzer in Gruppen zu trennen. Ausführlichere Informationen finden Sie in den Gardener-Dokumenten.

Falls Sie noch keinen OIDC-Provider haben, können Sie dem Abschnitt OIDC-Authentifizierung unserer IAM-Anleitung folgen, um Zitadel entsprechend zu konfigurieren.

Passen Sie eine ConfigMap an, die Ihre strukturierte Authentifizierung beschreibt:

apiVersion: v1
kind: ConfigMap
metadata:
  name: name-of-configmap-containing-authentication-config
  namespace: garden-5mc4xk5nxp
data:
  config.yaml: |
    apiVersion: apiserver.config.k8s.io/v1beta1
    kind: AuthenticationConfiguration
    jwt:
    - issuer:
        url: 'https://id.nbg.nsc.noris.cloud'
        audiences:
        - "1234567890987654321"
        audienceMatchPolicy: MatchAny
      claimMappings:
        username:
          claim: preferred_username
          prefix: ws#
        groups:
          claim: roles
          prefix: ws#
        uid:
          claim: sub

Um Ihre ConfigMap auf Ihr Projekt anzuwenden: kubectl -n garden-<your-project> --kubeconfig ~/.garden/kubeconfig-garden.yaml apply <your-configmap.yaml>

Sie können den Namen Ihrer ConfigMap anpassen und sollten namespace auf den Kubernetes-Namespace des virtuellen Gardens Ihres Projekts anpassen. Passen Sie issuer.url auf die URL Ihres OIDC-Issuers an (falls Sie unser Zitadel nutzen, finden Sie den „issuer”-Schlüssel unter dem OIDC-Konfigurations-Endpunkt Ihres IDP: id.nbg.nsc.noris.cloud/.well-known/openid-configuration). Konfigurieren Sie außerdem die OIDC-ClientId unter audiences passend zu Ihrem OIDC-Provider.

Präfixe für Username und Groups können Sie frei wählen, sollten sie aber beim Setzen von RoleBindings/ClusterRoleBindings im Hinterkopf behalten.

Während der Shoot-Erstellung können Sie nun auf die neu erstellte ConfigMap verweisen. Klicken Sie auf das „+“-Zeichen, um einen neuen Shoot zu erstellen.

Klicken Sie auf „YAML”, um zur erweiterten Ansicht zu wechseln.

Passen Sie die Shoot-Konfiguration nach Belieben an und fügen Sie folgendes Objekt hinzu:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
...
spec:
  kubernetes:
    kubeAPIServer:
      structuredAuthentication:
        configMapName: name-of-configmap-containing-authentication-config
...

Der Name der ConfigMap sollte mit dem Namen übereinstimmen, den Sie bei der Anpassung der ConfigMap gewählt haben.

ClusterRoleBinding/RoleBinding zu Ihrem Shoot hinzufügen

Fügen Sie das RoleBinding/ClusterRoleBinding entsprechend Ihrem RBAC-Modell hinzu. In unserem Beispiel erhält jemand, der von Zitadel die Rolle cluster-admin in seinem ID-Token zugewiesen bekommt, durch das folgende ClusterRoleBinding in Ihrem Shoot auch die Rolle cluster-admin in Kubernetes:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: some-name-for-my-oidc-admin-clusterrolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: ws#cluster-admin

Um Ihr ClusterRoleBinding auf Ihr Projekt anzuwenden: kubectl -n garden-<your-project> --kubeconfig ~/.garden/kubeconfig-garden.yaml apply <your-ClusterRolebinding.yaml>

API-Dokumentation

Maßgeblich ist die offizielle Gardener-API-Referenz. Es wird empfohlen, zum Git-Branch zu wechseln, der zur aktuellen Gardener-Version passt, wie im Screenshot gezeigt:

Um API-Elemente einfach zu inspizieren, bietet kubectl auch praktische Shortcuts über folgende Befehle, zum Beispiel:

kubectl api-resources
kubectl explain pods --recursive

Sicherheitshinweise / CVEs

Bitte informieren Sie sich über diese Benachrichtigungskanäle, wenn Sie über die neuesten Gardener-Sicherheitshinweise auf dem Laufenden bleiben möchten.

Erweiterungen

Die Gardener-Plattform kann um folgende zusätzliche Erweiterungen ergänzt werden. Falls Sie diese Funktionalität wünschen, kontaktieren Sie uns bitte für ein Angebot.

• extension-shoot-networking-filter: Firewalls, z.B. Blackholing
• shoot-rsyslog-relp: Weiterleitung von Audit-Logs an einen entfernten relp-Server
• shoot-falco-service: Anomalieerkennung
• shoot-lakom-service: Erzwingen der Container-Image-Signierung

Cluster löschen

Um einen Cluster zu löschen, klicken Sie auf die drei Punkte links in der Cluster-Übersicht und wählen Sie „Delete Cluster”.

Das Löschen wird ausführlich in der Upstream-Dokumentation erläutert. Das Löschen der VMs erfolgt über die üblichen OpenStack-VM-Löschmechanismen.