WZ-IT verbindet Cluster-Networking, Ingress und Gateway, DNS und TLS mit identitätsbasiertem Zugriff über NetBird. So werden öffentliche Dienste sicher veröffentlicht und interne Dienste nicht unnötig ins Internet gestellt.
Die genannten Namen sind Marken ihrer jeweiligen Inhaber: NetBird (NetBird GmbH). WZ-IT ist ein unabhängiger Dienstleister und steht in keiner geschäftlichen, partnerschaftlichen oder vertraglichen Beziehung zu diesen Unternehmen. Wir bieten unabhängige Migrations-, Installations-, Hosting- und Betriebsdienstleistungen an.
Kubernetes-Angebot
Vom Zielbild über Infrastruktur und Deployments bis zum laufenden Betrieb. Jede Seite vertieft einen Teil derselben verantworteten Plattform.
Kubernetes-Networking und Secure Access lösen unterschiedliche Aufgaben. Wir gestalten die Übergänge bewusst, damit interne Admin- und Businessdienste privat bleiben und öffentliche Anwendungen einen kontrollierten Eintrittspunkt erhalten.
CNI, Services, Network Policies, Namespaces und Egress-Regeln steuern Kommunikation innerhalb der Plattform.
Ingress oder Gateway API, Load Balancer, DNS, Zertifikate, Rate Limits und optional vorgelagerte Schutzdienste.
Cluster-API, Dashboards und interne Services über NetBird Routing Peers, Network Resources und Zugriffs-Policies.
OIDC, Gruppen, Rollen, Geräte und Dienstleisterzugänge werden an konkrete Ressourcen und Zwecke gebunden.
Aus Nutzern, Standorten, Diensten, Protokollen und Anforderungen an die Nachvollziehbarkeit entsteht das Zugangsmodell. Daraus folgen Ingress, private Netze, NetBird-Policies und administrative Zugangswege.
Public, Partner, intern, administrativ und Cluster-Infrastruktur unterscheiden.
Identitäten, Netze, Mandanten, Standorte und Datenflüsse abgrenzen.
Ingress/Gateway oder privaten NetBird-Zugang passend zum Dienst wählen.
RBAC, Network Policies, SSO/MFA und NetBird Policies konsistent umsetzen.
Zugriffe, Zertifikate, Routen und Änderungen überwachen und widerrufbar halten.
Vom Paketfluss im Cluster bis zum Browser oder Administrationsgerät betrachten wir den vollständigen Weg und seine Verantwortungsgrenzen.
Cilium oder passendes CNI, Namespace-Grenzen, Default-Deny, notwendige Flows und Netzwerk-Observability.
Traefik, ingress-nginx oder Gateway API mit Load Balancing, TLS, Weiterleitungen und kontrollierter Veröffentlichung.
cert-manager, DNS-Automation, interne und öffentliche Zonen sowie nachvollziehbarer Zertifikatslebenszyklus.
Routing Peers und Network Resources für Cluster-API, Dashboards, interne Anwendungen und Dienstleisterzugänge.
Identity Provider, Gruppen und Rollen über Kubernetes, Plattformtools und private Zugänge konsistent abbilden.
Flows, Fehler, Latenzen, Zertifikate und Erreichbarkeit so überwachen, dass Ursachen auffindbar bleiben.
Neben dem Cluster benötigen Anwendungen definierte Prozesse für Delivery, Zugriff, Observability, Wiederherstellung und technische Verantwortung.
GitOps, CI/CD, getrennte Umgebungen, Freigaben und reproduzierbare Rollbacks.
CNI, Network Policies, Ingress oder Gateway, DNS, TLS und private Zugänge.
OIDC, RBAC, Secrets, Image-Prüfung, Policies und nachvollziehbare Änderungen.
Metriken, Logs, Traces, Alerting und SLOs für Plattform und Anwendungen.
Clusterzustand, persistente Daten, Restore-Tests und ein dokumentierter Wiederanlauf.
Updates, CVE-Bewertung, Kapazität, Kosten und ein vereinbartes Betriebsmodell.
Wissensdatenbank
Abgrenzung
CNI und Network Policies regeln die Kommunikation der Workloads. NetBird schafft einen privaten, identitätsbasierten Zugangsweg zu ausgewählten Ressourcen. Für öffentlich erreichbare Anwendungen bleiben Ingress oder Gateway API der reguläre Produktionspfad.
Wechseln Sie zu dem Teil der Plattform, der für Ihr Vorhaben gerade entscheidend ist.
Klare Antworten zu Architektur, Umsetzung, Verantwortlichkeiten und laufendem Betrieb.
Ja. Über Routing Peers und Network Resources können ausgewählte Services oder Netze für berechtigte NetBird-Nutzer erreichbar werden. Identitäten und Policies begrenzen, wer auf welche Ressource zugreifen darf.
Nein. Ein CNI stellt das Pod- und Service-Netzwerk bereit und setzt Network Policies innerhalb des Clusters um. NetBird ergänzt die Architektur für privaten Zugriff von Benutzern, Geräten oder Standorten auf ausgewählte Ressourcen.
Typischerweise über einen Load Balancer und Ingress Controller oder Gateway API, ergänzt um DNS, TLS, Rate Limits und bei Bedarf WAF- oder DDoS-Schutz. Interne Verwaltungsdienste erhalten einen getrennten privaten Zugang.
Ja. Abhängig von Infrastruktur und Clusterdesign kann der API-Endpunkt nur über Managementnetze oder NetBird erreichbar gemacht werden. Zugriffe werden zusätzlich mit Kubernetes-Authentifizierung und RBAC abgesichert.
Ja. NetBird, WireGuard und klassische Routing- oder Site-to-Site-Konzepte können Standorte und private Netze anbinden. Dabei werden Routen, Zugriffs-Policies, DNS und Failure-Verhalten gemeinsam geplant.
Wir ordnen öffentliche, interne und administrative Zugänge und entwerfen daraus Netzwerk, Exposure und Identity-Policies.
Kein Risiko: Im schlechtesten Fall gehen Sie mit mehr Klarheit über Ihr Projekt heraus als vorher.


„Die Beratung von WZ-IT zu unserer Azure-Migration war schon im Erstgespräch fachlich sehr fundiert und völlig unverbindlich - wir haben eine Menge mitgenommen.“
Ob konkrete IT-Herausforderung oder einfach eine Idee - wir freuen uns auf den Austausch. In einem kurzen Gespräch prüfen wir gemeinsam, ob und wie Ihr Projekt zu WZ-IT passt.
Timo Wevelsiep & Robin Zins
Geschäftsführer
