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-CAPowerDNSSecretStoreRepositoryRegistryBuild-SystemGitOps-SystemUserDevOpexterner Zugriff auf Applikation Deployment           HTTPS  ACME RequestCert ResponseAnnotationapp01web.domain.labIN CNAME<Ingress-Hostname>   service: web             Push Image          Darstellung 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-CAPowerDNSSecretStoreRepositoryRegistryBuild-SystemGitOps-SystemUserDevOpexterner Zugriff auf Applikation Deployment           HTTPS  ACME RequestCert ResponseAnnotationapp01web.domain.labIN CNAME<Ingress-Hostname>   service: web             Push Image          Darstellung 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 (CI/CD)
  • 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.

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 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.