Kf ist eng in Kubernetes und Istio eingebunden, um für eine zuverlässige Erzwingung von Netzwerkrichtlinien zu sorgen.
Standardmäßig werden Kf-Arbeitslasten im Kubernetes-Cluster ausgeführt und Adressen mit Kubernetes DNS aufgelöst. Dieser DNS-Resolver versucht zuerst, Adressen im Cluster aufzulösen. Wenn dort keine gefunden werden, versucht er eine externe Auflösung.
Jede Kf-Anwendung wird mit einem Envoy-Sidecar ausgeführt, der von Istio oder Anthos Service Mesh (ASM) eingeschleust wird. Dieser Sidecar-Proxy führt den gesamten Netzwerk-Traffic in den und aus dem Kubernetes-Pod durch.
Jeder Kubernetes-Pod wird auf einem Knoten ausgeführt – einer physischen oder virtuellen Maschine, die für die Verwaltung der Container-Images in einem Pod zuständig ist. Knoten sind in einem physischen oder virtuellen Netzwerk vorhanden.
Gemeinsam bilden sie eine Hierarchie von Systemen, auf die Sie Netzwerkrichtlinien anwenden können. Diese sind unten aufgeführt (von allgemeineren bis zu sehr detaillierten Richtlinien).
Richtlinien auf Netzwerkebene
Der Arbeitslastschutz beginnt mit dem Netzwerk, in dem Ihr GKE-Cluster installiert ist.
Wenn Sie Kf in einem GKE-Cluster in Google Cloud ausführen, empfiehlt Kf Folgendes:
- GKE-Cluster in einem VPC-Netzwerk (Virtual Private Cloud) platzieren
- Der private Google-Zugriff sollte aktiviert sein.
- Cloud NAT zur Steuerung des ausgehenden Traffics verwenden
Richtlinien auf Knotenebene
Mithilfe von Kubernetes-Netzwerkrichtlinien lassen sich Richtlinien für Container einrichten, die auf einem Knoten ausgeführt werden. Diese entsprechen am ehesten Cloud Foundry-Netzwerkrichtlinien.
Netzwerkrichtlinien werden von einem Kubernetes-Add-on unterstützt. Wenn Sie einen eigenen GKE-Cluster einrichten, müssen Sie die Erzwingung von Netzwerkrichtlinien aktivieren.
Kf kennzeichnet Anwendungen mit kf.dev/networkpolicy=app und Builds mit kf.dev/networkpolicy=build.
Dadurch können Sie Netzwerkrichtlinien direkt auf Pods ausrichten, in denen Anwendungen oder Builds ausgeführt werden.
In jedem Kf-Bereich werden zu Beginn zwei Netzwerkrichtlinien erstellt: eine für Anwendungen und eine für Builds. Sie können die Konfiguration in den Feldern spec.networkConfig.(app|build)NetworkPolicy.(in|e)gress des Bereichs ändern.
Für diese Felder kann einer der folgenden Werte festgelegt werden:
| Enum-Wert | Beschreibung |
|---|---|
PermitAll |
Lässt den gesamten Traffic zu. |
DenyAll |
Lehnt den gesamten Traffic ab. |
Standardmäßig verwendet Kf eine freizügige Netzwerkrichtlinie. Dadurch kann Kf die folgenden Funktionen nutzen:
- Nord-Süd-Routing zum Ingress-Gateway des Clusters
- Ausgehender Traffic zum Internet, zum Beispiel zum Abrufen von Buildpacks
- Ost-West-Routing zwischen Anwendungen
- Zugriff auf den Kubernetes-DNS-Server
- Zugriff auf Container Registries
- Direkter Zugriff auf das VPC-Netzwerk
- Zugriff auf Google-Dienste wie Cloud Logging
- Zugriff auf den Workload Identity-Server für die automatische Rotation von Anmeldedaten
Service Mesh-Richtlinien
Wenn Sie eine fein abgestufte Netzwerksteuerung, Authentifizierung, Autorisierung und Beobachtbarkeit benötigen, können Sie Richtlinien mit Anthos Service Mesh anwenden.
Ein Service Mesh ist eine Infrastrukturebene, die eine verwaltete, beobachtbare und geschützte Kommunikation zwischen Ihren Diensten ermöglicht. Damit können Sie zuverlässige Unternehmensanwendungen erstellen, die aus vielen Mikrodiensten in der ausgewählten Infrastruktur bestehen.
Hier finden Sie eine Liste der unterstützten Funktionen.