Die virtuelle Netzwerkschicht in Google Distributed Cloud (GDC) (air-gapped) steuert die Konnektivität, Firewalls, Diensterkennung, Lastverteilung und Beobachtbarkeit zwischen virtuellen Maschinen und Pods, die in einer GDC-Organisation ausgeführt werden.
GDC-Netzwerkmodell
GDC enthält zwei Ebenen von Multi-Tenancy-Konzepten: Organisationen und Projekte. Projekte sind in Organisationen vorhanden und Sie stellen alle virtualisierten und containerisierten Arbeitslasten in einem bestimmten Projekt innerhalb einer Organisation bereit.
Organisationsnetzwerk
Jede Organisation in GDC hat ihr eigenes isoliertes virtuelles Netzwerk. Das virtuelle Netzwerk innerhalb der Organisation ist ein flacher IP-Bereich, d. h., alle Arbeitslasten in der Organisation haben eine direkte IP-Adressverbindung zueinander. Mit Projektnetzwerkrichtlinien können Sie den Zugriff zwischen Arbeitslasten in verschiedenen Projekten in der Organisation steuern.
GDC isoliert jede Organisation auf Netzwerkebene von allen anderen Organisationen. Arbeitslasten in einer Organisation haben keine direkte IP-Adressverbindung zu Arbeitslasten in einer anderen Organisation.
Eine Organisation hat zwei verschiedene IP-Bereiche: einen internen und einen externen Bereich. Der externe IP-Bereich ist von außerhalb der Organisation erreichbar und der interne IP-Bereich ist nur innerhalb der Organisation zugänglich. Arbeitslasten wird immer eine IP-Adresse aus dem internen Bereich der Organisation zugewiesen, d. h., sie sind standardmäßig nicht von außerhalb der Organisation zugänglich. Sie müssen eingehenden und ausgehenden Traffic für Arbeitslasten explizit aktivieren. Verwenden Sie dazu die in Abschnitt Projektnetzwerk beschriebenen Einschränkungen für eingehenden und ausgehenden Traffic.
Projektnetzwerk
Sie stellen alle virtuellen Maschinen (VMs) und containerisierten Arbeitslasten in einem Projekt bereit. Projekte bieten eine Netzwerksegmentierungsgrenze innerhalb der Organisation.
Arbeitslasten innerhalb eines Projekts können direkt miteinander kommunizieren. Die Standardnetzwerkrichtlinie verhindert jedoch die Kommunikation zwischen Arbeitslasten in verschiedenen Projekten. Projektnetzwerkrichtlinien (ProjectNetworkPolicy) lassen Sie konfigurieren, welche Projekte in der Organisation miteinander kommunizieren können. Wenn die Projektnetzwerkrichtlinie dies zulässt, können Arbeitslasten in der Organisation die jeweils andere auf der L3-Netzwerkschicht über ihre IP-Adressen erreichen. Sie müssen Einschränkungen für eingehenden und ausgehenden Traffic für jede Arbeitslast, die eingehenden oder ausgehenden Traffic benötigt, explizit aktivieren.
Load-Balancer konfigurieren
Load-Balancer verteilen den Traffic auf die Backend-Arbeitslasten Ihrer Anwendung und sorgen so für Stabilität und Verfügbarkeit. Erstellen Sie externe und interne Load-Balancer für Pod- und VM-Arbeitslasten. GDC bietet drei Methoden zum Konfigurieren von Load-Balancern. Weitere Informationen finden Sie unter Load-Balancer verwalten.
Einschränkungen für eingehenden Traffic
Der Mechanismus zum Freigeben von Arbeitslasten außerhalb der Organisation unterscheidet sich je nachdem, ob die Arbeitslast auf VMs oder Containern basiert.
Sie geben VM-basierte Arbeitslasten außerhalb der Organisation mit der Funktion für den externen VM-Zugriff frei. Sie aktivieren diese Funktion für jede VM. Jede VM erhält eine eigene IP-Adresse aus dem externen Bereich der Organisation.
Containerisierte Arbeitslasten geben Sie dagegen mit der Funktion für externe Load-Balancer außerhalb der Organisation frei. Sie können einen externen Load-Balancer erstellen und GDC weist eine externe IP-Adresse zu. Anschließend kann der Traffic auf eine Reihe von Backend-Pod-Arbeitslasten verteilt werden.
Einschränkungen für ausgehenden Traffic
Sie müssen ausgehenden Traffic für jedes Projekt und jede Arbeitslast explizit aktivieren, damit die Kommunikation außerhalb der Organisation möglich ist. Wenn Sie ausgehenden Traffic aktivieren, wird die IP-Adresse von Arbeitslasten beim Herstellen einer Verbindung außerhalb der Organisation mithilfe von Network Address Translation (NAT) in eine externe IP-Adresse geändert. Weitere Informationen zum Zulassen von ausgehendem Traffic finden Sie unter NAT-Übersicht.
Modell zur Durchsetzung von Netzwerkrichtlinien
Der Sicherheitsstatus für Arbeitslasten innerhalb einer Organisation ist die Kombination aus Standard- und benutzerdefinierten Projektnetzwerkrichtlinien.
Die Durchsetzung von Richtlinien basiert auf Layer-3- und Layer-4-Trafficflüssen. Ein Fluss beschreibt eine 5-Tupel-Verbindung wie folgt:
- Quell-IP-Adresse
- Ziel-IP-Adresse
- Quellport
- Zielport
- Protokoll, z. B.
TCP,UDPoderIPIP
Netzwerkrichtlinien erzwingen ausgehenden Traffic für Traffic am Knoten, der die Quellarbeitslast hostet, und eingehenden Traffic, wenn der Traffic am Knoten ankommt, der die Zielarbeitslast hostet. Um eine Verbindung herzustellen, müssen Sie daher zulassen, dass die Richtlinie die Quelle für das Ziel verlässt und vom Ziel aus an der Quelle ankommt.
Antworttraffic, z. B. das SYN-ACK-Segment (Synchronize-Acknowledge), das auf ein SYN-Segment antwortet, unterliegt nicht der Durchsetzung. Antworttraffic ist daher immer zulässig, wenn der initiierende Traffic zulässig ist. Aus diesem Grund werden Zeitüberschreitungen bei der Verbindung aufgrund der Durchsetzung von Richtlinien nur vom Client beobachtet, der die Verbindung initiiert. Abgelehnter Traffic wird entweder während der ausgehenden Datenübertragung vom Quellknoten oder der eingehenden Datenübertragung am Zielknoten verworfen. Die empfangende Arbeitslast beobachtet die Verbindung nie.
Die Durchsetzung basiert auf zulässigen Richtlinienregeln, die additiv sind. Die resultierende Durchsetzung für eine Arbeitslast ist eine „beliebige Übereinstimmung“ für den Trafficfluss mit der Kombination aller Richtlinien, die auf diese Arbeitslast angewendet werden. Wenn mehrere Richtlinien vorhanden sind, werden die auf jede Arbeitslast angewendeten Regeln additiv kombiniert. Traffic ist zulässig, wenn er mindestens einer der Regeln entspricht. Es gibt keine Ablehnungsregeln, nur Zulassungsregeln.
Wenn eine Netzwerkrichtlinie einen Fluss ablehnt, erhalten Sie kein Antwortpaket und es kommt zu einer Zeitüberschreitung bei der Verbindung. Aus diesem Grund sind abgelehnte oder zurückgesetzte Verbindungen auf Protokollebene oder HTTP-Fehler kein direktes Ergebnis der Durchsetzung von Netzwerkrichtlinien.
Weitere Informationen zu Kubernetes-Netzwerkrichtlinien finden Sie unter https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-two-sorts-of-pod-isolation.