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) injiziert wird. Dieser Sidecar-Proxy führt den gesamten Netzwerktraffic in den und aus dem Kubernetes-Pod durch.
Jeder Kubernetes-Pod wird auf einem Knoten ausgeführt – eine physische oder virtuelle 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, mit denen 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 Privater 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 dem Knoten ausgeführt werden. Diese sind die engste Zuordnung zu Cloud Foundry-Netzwerkrichtlinien in Kubernetes.
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 erstellt Builds mit kf.dev/networkpolicy=build
.
Dadurch können Sie Netzwerkrichtlinien direkt auf Pods ausrichten, in denen Anwendungen oder Builds ausgeführt werden.
Jeder Kf-Space erstellt zu Beginn zwei Netzwerkrichtlinien, 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 Space ä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, z. B. 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 sichere 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.