Pod-IP, ClusterIP oder interner Load Balancer für VPN-Nutzer

Mit dem VPC CNI kann ein Pod eine Adresse aus dem VPC erhalten, und ein VPN-Nutzer mit der richtigen Route erreicht sie direkt. Das lässt den direkten Pod-Zugriff wie die einfachste Option wirken, und das ist er auch, bis der Pod ersetzt wird. Die Adresse, an die sich ein Nutzer erinnert, sollte zur Anwendung gehören, nicht zu einem Replikat. Der Vergleich der drei Einstiegspunkte läuft darauf hinaus, welches Objekt die Adresse besitzt und was weiter funktionieren muss, wenn die Workload umzieht.

Wählen Sie zuerst nach dem Lebenszyklus, dann danach, was das Netzwerk tun muss, damit der Einstieg erreichbar wird.

Drei Einstiege, drei Lebenszyklen

Eine Pod-IP gehört einem Pod: Sie wird mit ihm zugeteilt und freigegeben, wenn er endet. Eine ClusterIP gehört einem Service und ist virtuell, sie ist nur dort sinnvoll, wo das Service-Routing des Clusters existiert. Ein interner Load Balancer gehört einer Cloud-Ressource, die der Controller des Clusters mit Backends programmiert. Diese Eigentumsmodelle sagen den Fehler voraus, den Sie bekommen: eine veraltete Adresse, einen unerreichbaren Namen oder eine veraltete Backend-Menge.

Schreiben Sie den Vergleich auf, bevor Sie wählen. Sind der Eigentümer und der Fehler benannt, trifft die Wahl sich meist von selbst.

Direkter Pod-Zugriff: nützlich, vorübergehend

Direkter Zugriff ist für eine kontrollierte Prüfung wirklich nützlich: ein Administrator, eine kurze Sitzung, ein bestimmter Port. Für Nutzer ist er aber ein schlechter Vertrag, weil die Adresse ein Implementierungsdetail ist, das sich bei jedem Rollout ändert. Und eine davon in einem Wiki festzuhalten, ist der Weg, auf dem aus einem funktionierenden Dienst ein Gerücht wird.

Er lädt auch zu breiten Regeln ein. Die Erlaubnis für einen Administrator, einen Pod zu erreichen, ist keine Erlaubnis für jede Adresse im Subnetz des Knotens, und meistens wird die zweite geschrieben.

ClusterIP: von Grund auf clustergebunden

Eine ClusterIP funktioniert, weil die Dataplane des Clusters das Routing für sie innerhalb des Clusters programmiert. Von einem Laptop im VPN bedeutet die Adresse nichts, sofern etwas sie nicht bewusst offenlegt. Ein Name, der auf svc.cluster.local endet, gehört zum Cluster-DNS, sodass seine Kopie auf einem Client mit anderem Resolver einen nicht existierenden Namen erzeugt statt eines Routingfehlers.

ClusterIP bleibt der richtige Einstieg für Aufrufer innerhalb des Clusters, einschließlich anderer Workloads. Er ist nur kein Veröffentlichungsmechanismus für Nutzer außerhalb der Routing-Domäne des Clusters.

Interner Load Balancer: der veröffentlichte Pfad

Ein interner Load Balancer gibt Ihnen eine stabile private Adresse und einen Namen, auf den Ihre eigene Zone zeigen kann, während der Controller die Backend-Menge aktuell hält, wie der EKS-Leitfaden zum Load Balancing beschreibt. Das ist der Einstieg, der einen gewöhnlichen Pod-Ersatz übersteht, ohne dass jemand ein Dokument bearbeitet. Er kostet eine Cloud-Ressource, eine Controller-Konfiguration und eine Route aus dem VPN, und genau diese Teile unterschätzen die Leute.

Verwenden Sie das Controller-Modell, das der Cluster tatsächlich ausführt. Annotationen, die für eine Integration geschrieben wurden, gelten nicht für eine andere.

Wer die Quelladresse ist

Sicherheitsgruppen sehen die Quelle, die an ihrer Grenze ankommt, und das kann je nach VPN- und Load-Balancing-Pfad der verbundene Client oder eine übersetzte Adresse sein. Auf EC2-basierten Knoten erben gewöhnliche VPC-CNI-Pods standardmäßig die Gruppen der ENI des Knotens, während unterstützte Konfigurationen Pod-spezifische Gruppen anhängen können. Schreiben Sie Regeln für den dokumentierten Pfad statt für eine geratene Laptop-Adresse.

Halten Sie den eigenen Listener und die Authentifizierung der Anwendung als getrennte Kontrollen. Eine Netzwerkregel, die den Fluss erlaubt, ist keine Autorisierungsentscheidung und sollte nicht als solche behandelt werden.

Was Nutzer bekommen sollten

Geben Sie Nutzern einen Dienstnamen, keine Adresse. Veröffentlichen Sie den Namen in der privaten Zone, zeigen Sie damit auf den internen Einstieg und testen Sie dann, indem Sie einen Backend-Pod ersetzen, während ein Client denselben Namen offen hält. Diese Übung prüft die Eigenschaft, auf die es ankommt: dieselbe Anwendung nach einem routinemäßigen Deployment zu erreichen.

Halten Sie den direkten Pod-Zugriff als dokumentierte betriebliche Ausnahme mit eigenem Umfang, weit weg von den nutzerseitigen Anleitungen.