Zum Inhalt

mögliche Labor Umgebung

Hier soll eine mögliche Umgebung beschrieben werden um die benötigten Randbedingungen und deren Bereitstellungen evaluieren zu können.

mögliche Kubernetes Labor Umgebungmögliche Kubernetes Labor UmgebungKubernetes Clusterkube-system[Namespace]external-dns[Namespace]cert-manager[Namespace]app01[Namespace]external-secrets[Namespace] Kubernetes API KubeletErstellung von Pods, Servicesund anderen Ressourcen Storage Class CoreDNS API-Manager etcd Controler Scheduler extdns-lab cert-manager TLS-Secrets app01web.domain.lab web.app01.svc FE-Pod Ressourcen ConfigMap Secret ExternalSecret Volume VolumeClaim external-secret-operatorACME-CASmallstep Step-CAPowerDNSSecretStoreOpenBaoRepositoryGiteaRegistrygoHarborBuild-SystemGitOps-SystemUserDevOpexterner Zugriff auf Applikation DeploymentHTTPSACME RequestCert ResponseAnnotationapp01web.domain.lab INCNAME<Ingress-Hostname>service: webPush ImageDarstellung ist sehr grob umrissen und dient nur der Veranschaulichung für das Zusammenspiel der Komponenten
mögliche Kubernetes Labor Umgebungmögliche Kubernetes Labor UmgebungKubernetes Clusterkube-system[Namespace]external-dns[Namespace]cert-manager[Namespace]app01[Namespace]external-secrets[Namespace] Kubernetes API KubeletErstellung von Pods, Servicesund anderen Ressourcen Storage Class CoreDNS API-Manager etcd Controler Scheduler extdns-lab cert-manager TLS-Secrets app01web.domain.lab web.app01.svc FE-Pod Ressourcen ConfigMap Secret ExternalSecret Volume VolumeClaim external-secret-operatorACME-CASmallstep Step-CAPowerDNSSecretStoreOpenBaoRepositoryGiteaRegistrygoHarborBuild-SystemGitOps-SystemUserDevOpexterner Zugriff auf Applikation DeploymentHTTPSACME RequestCert ResponseAnnotationapp01web.domain.lab INCNAME<Ingress-Hostname>service: webPush ImageDarstellung ist sehr grob umrissen und dient nur der Veranschaulichung für das Zusammenspiel der Komponenten

Neben dem eigentlichen Kubernetes-Cluster sind hier folgende Rand-Systeme aufgezeigt:

  • Git Repository - hier wird der eigentlich Code zur Container-Erstellung, den Pipelines und der Manifeste revisionssicher abgelegt und gepflegt.
  • Build-System (z.B. Jenkins) - ein Jenkins kann hier mehrere Aufgaben erfüllen:
    • Builds von Container-Images
    • Controller für Deployments direkt aus einer Pipeline (CI/CD)
  • ArgoCD - GitOps Tool zum automatisierten Deployment von Helm-Charts
  • Container Registry - wird benötigt um (eigene) Container-Images für den Cluster bereitzustellen.
  • PowerDNS - dieser DNS-Server ist in der Lage via API dynamisch die Resource-Records für den FQDN der via Ingress bereitgestellten Applikationen imm DNS-System zu erstellen. Hierfür wird im Cluster eine External-DNS Komponente (pro DNS-System, wenn mehr als eine DNS-Struktur zum tragen kommt) mit eingerichtet. (Eine DNS-Struktur besteht zumeist mindestens aus einem authoritativen Server und seinem Recursor - theoretisch können mehrere DNS-Strukturen mit verschiedenen Domains gleichermaßen von einem Cluster aus bedient werden.)
  • ACME-CA - wird benötigt um die Zertifikate für TLS und HTTPS-Zugriffe zu erzeugen und entsprechend im Cluster mit einzusetzen.
  • Secret-Store (z.B. OpenBao als Fork von HashiCorp Vault) - managebare Secrets, die in mehreren Tools und im Cluster genutzt werden können. Gerade mit OpenBao/HashiCorp Vault gibt es einen sehr umfangreichen Secret-Store, der fast als Quasi-Standard (Best Practies) sehr verbreitet ist. Daneben ist Passbolt nur ein Key/Value Store auf Basis ähnlich KeePass - hierbei aber der Vorteil, dass es Browser-Plugins gibt und die darin enthaltenen Credentials auch generell bei Anmeldungen an Web-Apps genutzt werden können (es kann eine mehrfach und verteile Pflege von Credentials vermieden werden - ein Export in eine KeePass-Datei ist ebenfalls möglich).

Weitere ggf. benötigte Komponenten:

  • Proxy - es empfiehlt sich gerade zu Beginn einen Proxy zur Verfügung zu haben um öffentliche Container-Images und andere öffentliche Ressourcen wie beispielsweise Helm-Repositories nutzen zu können.
  • (NFS-)Fileserver - um nicht gleich mit einem Storage-Cluster mit CephFS beginnen zu müssen, oder sich bereits mit speziellen Hersteller-Komponenten der bis dato verfügbaren Storage-Umgebung herumzuschlagen, empfiehlt es sich mit einem simplen NFS-Server und dem NFS-subdir-external-provisioner seine ersten Storage-Classes zu erstellen.
    • eine Alternative wäre hierbei mit Longhorn oder OpenEBS einen im Cluster mit aufgebauten Storage-Cluster einzusetzen - dabei sollte man aber einen Mehrbedarf der benötigten Ressourcen bei den Worker-Nodes mit berücksichtigen.