Cluster für IPv4 und IPv6 aktivieren
Erfahren Sie, was Sie über die IPv4- und IPv6-Adressen wissen müssen, wenn Sie die Kubernetes Engine (OKE) verwenden.
Wenn Sie Kubernetes Engine zum Erstellen von Kubernetes-Clustern verwenden (Version 1.29 oder höher), geben Sie an, welche IP-Adressfamilie beim Zuweisen von IP-Adressen verwendet werden soll, um die Kommunikation mit dem Cluster und innerhalb des Clusters zu ermöglichen. Sie können Folgendes angeben:
- Nur die IPv4-Adressfamilie
- sowohl die Adressfamilie IPv4 als auch die Adressfamilie IPv6
Über IPv4
Das Internetprotokoll IPv4 ist ein Standard zur Identifizierung von Geräten in einem Netzwerk, indem jedem Gerät eine eindeutige IP-Adresse zugewiesen wird. IPv4 verfügt über einen Adressraum von 32 Bit (232), der mehr als 4,2 Milliarden eindeutige IP-Adressen bereitstellt. Eine IPv4-Adresse ist ein 32-Bit-Wert, der üblicherweise als vier Segmente mit 8 Bit (als Oktette bezeichnet) formatiert ist, die durch einen Punkt getrennt sind, wobei jedes Segment ein Dezimalwert zwischen 0 und 255 ist. Beispiel: 203.0.113.2.
Eine IPv4-Adresse besteht aus zwei Teilen: einem Netzwerkteil (oder "Präfix"), um ein Netzwerk zu identifizieren, und einem Hostteil, um ein einzelnes Gerät in diesem Netzwerk zu identifizieren. Wie viel der IPv4-Adresse zur Verwendung als Netzwerkteil verfügbar ist, wird durch ein CIDR-Suffix angegeben, das nach einem Schrägstrich an die IPv4-Adresse angehängt wird. Beispiel: /24 gibt an, dass die ersten 24 Bit (die ersten drei Segmente von acht Bit) der Adresse IPv4 den Netzwerkteil der Adresse bilden, sodass die restlichen 8 Bit (das letzte Segment) für den Hostteil der Adresse verfügbar bleiben.
Beispiel: 203.0.113.2/24:
- 203.0.113 ist der Netzwerkteil (oder "Präfix") der Adresse
- .2 ist der Hostteil der Adresse
- 203.0.113.2 ist die Adresse eines einzelnen Geräts.
- 203.0.113.0/24 ist ein "CIDR-Block", der den gesamten Adressbereich darstellt, der dasselbe Netzwerkpräfix verwenden kann. In diesem Fall enthält der CIDR-Block alle IP-Adressen zwischen 203.0.113.0 und 203.0.113.255
Die Verbreitung von mit dem Internet verbundenen Geräten erschöpft den Pool der verfügbaren IPv4-Adressen und ist ein Grund für die umfassende Einführung von IPv6.
Über IPv6
IPv6 ist der Nachfolger von IPv4 und hat einen viel größeren Adressraum von 128 Bit (2128), der eindeutige IP-Adressen von 3,4 x 1038 bereitstellt. Eine IPv6-Adresse ist ein 128-Bit-Wert, der als acht Gruppen mit 16 Bit (sog. Hektets) formatiert und durch Doppelpunkte getrennt ist. Dabei ist jede Gruppe ein Hexadezimalwert zwischen 0000 und ffff. Beispiel: 2001:0db8:0123:1111:abcd:ef01:2345:6789.
Eine IPv6-Adresse besteht aus zwei Teilen: einem Netzwerkteil (oder "Präfix"), um ein Netzwerk zu identifizieren, und einem Hostteil, um ein einzelnes Gerät in diesem Netzwerk zu identifizieren. Wie viel der IPv6-Adresse zur Verwendung als Netzwerkteil verfügbar ist, wird durch ein CIDR-Suffix angegeben, das nach einem Schrägstrich an die IPv6-Adresse angehängt wird. Beispielsweise weist /64 darauf hin, dass die ersten 64 Bit (die ersten vier Gruppen von 16 Bit) den Netzwerkteil der Adresse bilden, wobei die restlichen 64 Bit (die zweiten vier Gruppen von 16 Bit) zur Bildung des Hostteils der Adresse zur Verfügung stehen.
Nehmen wir 2001:0db8:0123:1111:abcd:ef01:2345:6789/64 als Beispiel:
- 2001:0db8:0123:1111 ist der Netzwerkteil (oder "Präfix") der Adresse
- abcd:ef01:2345:6789 ist der Hostteil der Adresse
- 2001:0db8:0123:1111:abcd:ef01:2345:6789 ist die Adresse eines einzelnen Geräts
- 2001:0db8:0123:1111:0000:0000:0000:0000/64 ist ein "CIDR-Block", der den gesamten Adressbereich darstellt, der dasselbe Netzwerkpräfix verwenden kann. In diesem Fall enthält der CIDR-Block alle IP-Adressen zwischen 2001:0db8:0123:1111:0000:0000:0000:0000 und 2001:0db8:0123:1111:ffff:ffff:ffff:ffff
Der Adressraum IPv6 ist in Kategorien unterteilt, wie z.B. die Unicast-Kategorie Die Unicast-Kategorie umfasst:
- Globale Unicast-Adressen (GUAs), die global einzigartig sind und im Internet routbar sind.
- Unique-local Unicast Addresses (ULAs), die für die lokale Kommunikation innerhalb eines Netzwerks vorgesehen sind.
Neben einem viel größeren Adressraum, der das Problem der Erschöpfung der Adresse IPv4 löst, bietet IPv6 weitere Vorteile gegenüber IPv4, darunter:
- IPv6 ist sicherer als IPv4, mit integrierter Unterstützung für Datenverschlüsselung und -authentifizierung.
- IPv6 bietet ein effizienteres Routing als IPv4.
- IPv6 bietet schnellere Datenübertragungsgeschwindigkeiten als IPv4.
OCI-Support für IPv6
Oracle Cloud Infrastructure unterstützt sowohl die IPv4-Adressierung als auch die IPv6-Adressierung.
OCI-VCNs unterstützen die reine IPv4-Adressierung sowie die IPv4- und IPv6-Adressierung für "Dual Stack". Jedes VCN verfügt immer über mindestens ein privates IPv4 CIDR. Sie können IPv6 während der VCN-Erstellung aktivieren. Sie können auch ein IPv6-Präfix zu einem Nur-IPv4-VCN hinzufügen, während Sie IPv6 aktivieren. Beim Erstellen eines Subnetzes eines IPv6-fähigen VCN können Sie Folgendes für das Subnetz aktivieren:
- Nur IPv4-Adressen (als ein einzelnes Stack-Subnetz IPv4 bezeichnet)
- sowohl IPv4- als auch IPv6-Adressen (als Subnetz IPv4/IPv6 mit dualem Stack bezeichnet)
- Nur IPv6-Adressen (als ein einzelnes Stack-Subnetz IPv6 bezeichnet)
Ein IPv6-fähiges VCN kann eine Mischung aus IPv4-Subnetzen mit einzelnem Stack, IPv6-Subnetzen mit einzelnem Stack und IPv4/IPv6-Subnetzen mit dualem Stack aufweisen.
Weitere Informationen zu IPv6 und OCI im Allgemeinen finden Sie unter IPv6-Adressen.
Kubernetes-Unterstützung für IPv4 und IPv6
Kubernetes unterstützt das Single-Stack-Netzwerk IPv4, das Single-Stack-Netzwerk IPv6 oder das Dual-Stack-Netzwerk.
Weitere Informationen zur Unterstützung von IPv4 und IPv6 in Kubernetes finden Sie in der Kubernetes-Dokumentation unter IPv4/IPv6 dual-stack.
Kubernetes-Engine-Unterstützung für IPv4 und IPv6
In früheren Versionen der Kubernetes Engine (unterstützt Cluster, auf denen Kubernetes-Versionen vor Version 1.29 ausgeführt werden) können Sie nur Cluster erstellen, die für IPv4 aktiviert sind. In einem IPv4-fähigen Cluster werden dem Kubernetes-API-Endpunkt, dem Load Balancer, den Worker-Knoten sowie den im Cluster ausgeführten Pods und Services des Clusters IPv4-Adressen zugewiesen. Bei der Kommunikation mit dem Cluster und innerhalb des Clusters wird nur die IPv4-Adressierung verwendet (alle zugewiesenen IPv6-Adressen werden ignoriert).
In Versionen der Kubernetes-Engine, die Cluster mit Kubernetes-Versionen 1.29 oder höher unterstützen, können Sie Folgendes erstellen:
- IPv4 Einzelstackcluster, nur für IPv4 aktiviert.
- IPv4/IPv6-Dual-Stack-Cluster, aktiviert für IPv4 und IPv6 (manchmal einfach als Dual-Stack-Cluster bezeichnet).
Wenn Sie ein Cluster erstellen, geben Sie die IP-Adressfamilie des Clusters an:
- Wenn Sie nur IPv4 als IP-Adressfamilie des Clusters angeben, erstellen Sie ein IPv4-Einzelstackcluster.
- Wenn Sie sowohl IPv4 als auch IPv6 als IP-Adressfamilien des Clusters angeben, erstellen Sie ein Dual-Stackcluster IPv4/IPv6.
Wenn Sie ein IPv4-Einzelstackcluster erstellen, können Sie ein IPv4-fähiges VCN für das Cluster angeben, oder Sie können ein VCN angeben, das sowohl für IPv4 als auch für IPv6 aktiviert ist.
Wenn Sie ein Dual-Stack-Cluster IPv4/IPv6 erstellen, muss das für das Cluster angegebene VCN sowohl für IPv4 als auch für IPv6 aktiviert sein. Darüber hinaus können Sie ein IPv4/IPv6-Dual-Stackcluster erstellen:
- Control-Plane-Knoten und Worker-Knoten müssen Kubernetes-Version 1.29 oder höher ausführen.
- Worker-Knoten müssen auf einem OKE-Image mit einer Build-Nummer von 754 oder höher basieren.
- Alle Subnetze des IPv4/IPv6-Dualstacks, die Sie für den Kubernetes-API-Endpunkt, den Load Balancer, die Worker-Knoten und die Podkommunikation angeben, müssen öffentliche Subnetze sein.
- Das Cluster muss ein neues Cluster oder ein "VCN-natives Cluster" sein. Das heißt, ein Cluster, dessen Kubernetes-API-Endpunkt in Ihr eigenes VCN integriert ist (siehe In VCN-native Cluster migrieren). Cluster mit Kubernetes-API-Endpunkten, die nicht in Ihr eigenes VCN integriert sind, können keine Dual-Stack-Cluster IPv4/IPv6 sein.
IPv4-Einzelstackcluster und IPv4/IPv6-Doppelstackcluster erstellen
Wenn Sie ein Cluster erstellen, geben Sie die IP-Adressfamilie des Clusters entweder als IPv4 oder als IPv4 und IPv6 an.
Sie können IPv4-Einzelstackcluster und IPv4/IPv6-Doppelstackcluster mit folgendem Befehl erstellen:
- Konsole: Mit dem Benutzerdefinierten Workflow erstellen können Sie das Cluster erstellen. Die IP-Adressfamilien des Clusters werden aus der von Ihnen getroffenen Auswahl abgeleitet.
- CLI: Verwenden Sie den Befehl oci ce cluster create, um das Cluster zu erstellen, und nehmen Sie den Parameter
--ip-families
auf, um die IP-Adressfamilien des Clusters explizit im folgenden Format anzugeben:oci ce cluster create --compartment-id <compartment-ocid> --kubernetes-version <kubernetes-version> --name <cluster-name> --vcn-id <vcn-ocid> --ip-families='["<ip-family-1>", "<ip-family-2>"]' [OPTIONS]
Beispiel:
oci ce cluster create --compartment-id ocid1.compartment.oc1..aaaaaaaay______t6q --kubernetes-version v1.31.1 --name Finance-Cluster --vcn-id ocid1.vcn.oc1.iad.aaaaaae___yja --ip-families='["IPv4", "IPv6"]'
- API: Führen Sie den Vorgang CreateCluster aus, um das Cluster zu erstellen und die IP-Adressfamilien des Clusters anzugeben.
Clusterbezogene Ressourcen und IP-Adressen
Der Kubernetes-API-Endpunkt, die Worker-Knoten und die Podkommunikation eines Clusters erben die für das Cluster angegebene IP-Adressfamilie. In einem Dual-Stack-Cluster IPv4/IPv6 verwenden also der Kubernetes-API-Endpunkt, die Worker-Knoten und die Podkommunikation sowohl die IPv4-Adressfamilie als auch die IPv6-Adressfamilie.
Die Subnetze, die Sie für den Kubernetes-API-Endpunkt des Clusters, für seine Worker-Knoten und für die Podkommunikation angeben, müssen wie folgt mit der IP-Adressfamilie des Clusters kompatibel sein:
- Ein IPv4-Einzelstackcluster ist sowohl mit einem IPv4-Einzelstacksubnetz als auch mit einem IPv4/IPv6-Dual-Stack-Subnetz kompatibel. Sie können also ein IPv4-Subnetz mit einem einzelnen Stack oder ein IPv4/IPv6-Subnetz mit zwei Stacks für den Kubernetes-API-Endpunkt des Clusters, für seine Worker-Knoten und für die Podkommunikation angeben.
- Ein IPv4/IPv6-Dual-Stack-Cluster ist nur mit einem IPv4/IPv6-Dual-Stack-Subnetz kompatibel. Sie müssen also ein öffentliches Subnetz des doppelten Stacks IPv4/IPv6 für den Kubernetes-API-Endpunkt des Clusters, für seine Worker-Knoten und für die Podkommunikation angeben. Sie können kein IPv4-Single-Stack-Subnetz für den Kubernetes-API-Endpunkt eines IPv4/IPv6-Dual-Stack-Clusters, für seine Worker-Knoten und für die Podkommunikation angeben.
Nachdem Subnetze für den Kubernetes-API-Endpunkt, die Worker-Knoten und die Podkommunikation des Clusters angegeben wurden, die mit der IP-Adressfamilie des Clusters kompatibel sind:
- Wenn Sie ein einzelnes Stack-Subnetz IPv4 für die Ressource auswählen, erhält die Ressource nur eine IPv4-Adresse.
- Wenn Sie ein Dual-Stack-Subnetz IPv4/IPv6 für die Ressource auswählen, erhält die Ressource sowohl eine IPv4-Adresse als auch eine IPv6-Adresse.
Beachten Sie Folgendes:
- Sie können die IP-Adressfamilie des Load Balancers eines Clusters unabhängig von der IP-Adressfamilie des Clusters angeben. Beispiel: Sie können einen Dual-Stack-Load Balancer IPv4/IPv6 für ein IPv4-Single-Stack-Cluster erstellen (siehe IP-Adressfamilien für Load Balancer und Network Load Balancer angeben).
- Jedes Dual-Stack-Subnetz IPv4/IPv6, das Sie für den Kubernetes-API-Endpunkt, den Load Balancer, die Worker-Knoten und die Podkommunikation angeben, muss ein öffentliches Subnetz sein. Das öffentliche Subnetz erfordert ein NAT-Gateway zur IPv4-Adressierung und ein Internetgateway zur IPv6-Adressierung.
- Wenn einem Subnetz IPv4/IPv6 mit zwei Stacks mehrere IPv6-Präfixe zugewiesen sind, verwendet die Kubernetes-Engine das erste für das Subnetz definierte Präfix IPv6.
- Kubernetes Engine unterstützt sowohl GUA- als auch ULA-IPv6-Präfixe.
Zusätzliche IAM-Policy für den Zugriff auf Ressourcen mit IPv6-Adressen
Um zu ermöglichen, dass ein Cluster IPv6-Adressen für den Zugriff auf Ressourcen verwendet, fügen Sie eine Policy-Anweisung wie die folgende in eine IAM-Policy ein:
Allow any-user to use ipv6s in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }
Kubernetes-API-Endpunkt-IP-Adressen
Der Kubernetes-API-Endpunkt eines Clusters erbt die für das Cluster angegebene IP-Adressfamilie. In einem IPv4/IPv6-Dual-Stack-Cluster verwendet der Kubernetes-API-Endpunkt also sowohl die IPv4-Adressfamilie als auch die IPv6-Adressfamilie.
Geben Sie daher ein Subnetz für den Kubernetes-API-Endpunkt an, das mit der IP-Adressfamilie des Clusters kompatibel ist:
- Wenn Sie ein Subnetz für den Kubernetes-API-Endpunkt angeben, der zur Unterstützung der IPv4-Adressierung konfiguriert ist (entweder ein IPv4-Einzelstacksubnetz oder ein IPv4/IPv6-Dual-Stack-Subnetz), wird dem Kubernetes-API-Endpunkt automatisch eine verfügbare IPv4-Adresse als private Adresse zugewiesen.
- Um dem Kubernetes-API-Endpunkt eine öffentliche IPv4-Adresse zuzuweisen, müssen Sie ein öffentliches Subnetz für den Kubernetes-API-Endpunkt angeben, der zur Unterstützung der IPv4-Adressierung konfiguriert ist (entweder ein IPv4-Single-Stack-Subnetz oder ein IPv4/IPv6-Dual-Stack-Subnetz). Wenn Sie ein solches öffentliches Subnetz angegeben haben und angeben, dass Sie eine öffentliche IPv4-Adresse zuweisen möchten, wird eine verfügbare IPv4-Adresse im Subnetz automatisch dem Kubernetes-API-Endpunkt als öffentliche Adresse zugewiesen.
- Um dem Kubernetes-API-Endpunkt sowohl eine IPv4-Adresse als auch eine IPv6-Adresse zuzuweisen, müssen Sie ein öffentliches Subnetz des doppelten Stacks IPv4/IPv6 für den Kubernetes-API-Endpunkt angeben. Eine verfügbare IPv4-Adresse und eine IPv6-Adresse im Subnetz werden dem Kubernetes-API-Endpunkt automatisch zugewiesen.
Beachten Sie, dass die Adressfamilie des Subnetzes, das Sie für den Kubernetes-API-Endpunkt angeben, mit der IP-Adressfamilie des Clusters kompatibel sein muss. Ein IPv4-Einzelstackcluster ist sowohl mit einem IPv4-Einzelstack-Subnetz als auch mit einem IPv4/IPv6-Dual-Stack-Subnetz kompatibel. Ein IPv4/IPv6-Dual-Stack-Cluster ist nur mit einem IPv4/IPv6-Dual-Stack-Subnetz kompatibel.
IP-Adressen des Load Balancers
Standardmäßig erbt der Load Balancer eines Clusters die für das Cluster angegebene IP-Adressfamilie. In einem Dual-Stackcluster IPv4/IPv6 verwendet der Load Balancer also sowohl die IPv4-Adressfamilie als auch die IPv6-Adressfamilie.
Geben Sie wie folgt ein Subnetz für den Load Balancer des Clusters an:
- Um dem Load Balancer nur eine IPv4-Adresse zuzuweisen, geben Sie ein IPv4-Subnetz mit einem einzelnen Stack oder ein IPv4/IPv6-Subnetz mit zwei Stacks an. Eine verfügbare IPv4-Adresse im Subnetz wird dem Load Balancer automatisch zugewiesen.
- Um dem Load Balancer sowohl eine IPv4-Adresse als auch eine IPv6-Adresse zuzuweisen, geben Sie ein Dual-Stack-Subnetz IPv4/IPv6 an. Eine verfügbare IPv4-Adresse und eine IPv6-Adresse im Subnetz werden dem Load Balancer automatisch zugewiesen.
Beachten Sie, dass die Adressfamilie des Subnetzes, das Sie für einen Load Balancer angeben, nicht mit der IP-Adressfamilie des Clusters kompatibel sein muss. Sie können einen Dual-Stack-Load Balancer IPv4/IPv6 für ein IPv4-Single-Stack-Cluster erstellen (siehe IP-Adressfamilien für Load Balancer und Network Load Balancer angeben).
Weitere Informationen finden Sie unter:
IP-Adressen des Worker-Knotens
Die Knotenpools und Worker-Knoten eines Clusters erben die für das Cluster angegebene IP-Adressfamilie. In einem IPv4/IPv6-Dual-Stack-Cluster verwenden also ein Knotenpool und seine Worker-Knoten sowohl die IPv4-Adressfamilie als auch die IPv6-Adressfamilie.
Geben Sie daher ein Subnetz für die Worker-Knoten an, das mit der IP-Adressfamilie des Clusters kompatibel ist:
- Um Worker-Knoten nur IPv4-Adressen zuzuweisen, geben Sie ein IPv4-Subnetz mit einem einzelnen Stack oder ein IPv4/IPv6-Subnetz mit einem dualen Stack für den Knotenpool an. Verfügbare IPv4-Adressen im Subnetz werden den Worker-Knoten automatisch zugewiesen.
- Um den Worker-Knoten sowohl IPv4-Adressen als auch IPv6-Adressen zuzuweisen, geben Sie ein IPv4/IPv6-Subnetz mit dualem Stack für den Knotenpool an. Die verfügbaren IPv4- und IPv6-Adressen im Subnetz werden den Worker-Knoten automatisch zugewiesen.
Beachten Sie, dass die Adressfamilie des Subnetzes, das Sie für Worker-Knoten angeben, mit der IP-Adressfamilie des Clusters kompatibel sein muss. Ein IPv4-Einzelstackcluster ist sowohl mit einem IPv4-Einzelstack-Subnetz als auch mit einem IPv4/IPv6-Dual-Stack-Subnetz kompatibel. Ein IPv4/IPv6-Dual-Stack-Cluster ist nur mit einem IPv4/IPv6-Dual-Stack-Subnetz kompatibel.
IP-Adressen für Podkommunikation
Ein Clusterpod verwendet die für das Cluster angegebene IP-Adressfamilie für die Podkommunikation. In einem Dual-Stackcluster IPv4/IPv6 verwendet die Podkommunikation also sowohl die IPv4-Adressfamilie als auch die IPv6-Adressfamilie.
Geben Sie daher ein Subnetz für die Podkommunikation an, das mit der IP-Adressfamilie des Clusters kompatibel ist:
- Wenn die Pods nur IPv4-Adressen haben und verwenden sollen, geben Sie ein IPv4-Subnetz mit einzelnem Stack oder ein IPv4/IPv6-Subnetz mit dualem Stack an. Verfügbare IPv4-Adressen im Subnetz werden den Pods automatisch zugewiesen.
- Wenn die Pods sowohl IPv4- als auch IPv6-Adressen haben und verwenden sollen, geben Sie ein Subnetz mit zwei Stacks IPv4/IPv6 an. Die verfügbaren IPv4- und IPv6-Adressen im Subnetz werden den Pods automatisch zugewiesen.
Beachten Sie, dass die Adressfamilie des Subnetzes, das Sie für die Podkommunikation angeben, mit der IP-Adressfamilie des Clusters kompatibel sein muss. Ein IPv4-Einzelstackcluster ist sowohl mit einem IPv4-Einzelstack-Subnetz als auch mit einem IPv4/IPv6-Dual-Stack-Subnetz kompatibel. Ein IPv4/IPv6-Dual-Stack-Cluster ist nur mit einem IPv4/IPv6-Dual-Stack-Subnetz kompatibel.
Weitere Überlegungen zur Podnetzwerkkonfiguration
Wenn Sie die Podkommunikation in einer IPv4- oder IPv6-Umgebung konfigurieren, können sich bestimmte Hosteinstellungen auf die Weiterleitung des Traffics auswirken. Insbesondere können die folgenden Kernel-Parameter deaktiviert sein (auf 0
gesetzt), was sich auf den Podnetzwerktraffic für die jeweiligen IP-Adressfamilien auswirkt:
/proc/sys/net/ipv4/ip_forward
(für IPv4-Podtraffic)/proc/sys/net/ipv6/conf/all/forwarding
(für IPv6-Podtraffic)
Wenn diese Einstellungen deaktiviert sind, kann die Podkommunikation für die entsprechende IP-Adressfamilie die Netzwerkschnittstellen des Hosts nicht durchlaufen. Es werden Versuche unternommen, diese Parameter zu aktivieren, indem ihre Werte auf 1
gesetzt werden, um eine korrekte Podtrafficweiterleitung sowohl für IPv4 als auch für IPv6 sicherzustellen. Benutzerdefinierte Hostkonfigurationen (z.B. Dateien in /etc/sysctl.d/
) können diese Einstellungen jedoch außer Kraft setzen, was zu Netzwerkunterbrechungen führt.
Wenn Sie Probleme bei der Podkommunikation beobachten, wie Traffic, der nicht zwischen Pods oder von Pods an den Host weitergeleitet wird, prüfen Sie die Werte der relevanten Kernelparameter. Stellen Sie sicher, dass sie für die betroffene IP-Adressfamilie auf 1
gesetzt sind. Passen Sie widersprüchliche Konfigurationen in /etc/sysctl.d/
oder zugehörigen Dateien an, um das Problem zu beheben.
Services auf IPv4-fähigen Clustern und IPv6-fähigen Clustern bereitstellen
Wenn Sie einen Service in einem Kubernetes-Cluster bereitstellen, wird dem Service eine IP-Adresse (und Adressfamilie) aus dem IP-Bereich des Serviceclusters des Clusters zugewiesen. Ein Servicecluster-IP-Bereich ist ein Bereich von IP-Adressen, von denen virtuelle IP-Adressen (ClusterIPs) Services zugewiesen werden können, sodass auf die Services im Cluster zugegriffen werden kann. Ein Kubernetes-Cluster kann Folgendes enthalten:
- nur ein IP-Bereich des IPv4-Serviceclusters
- einen IP-Bereich des IPv4-Serviceclusters und einen IP-Bereich des IPv6-Serviceclusters
Kubernetes Engine erstellt Servicecluster-IP-Bereiche für ein Cluster entsprechend den IP-Adressfamilien, die Sie beim Definieren des Clusters angegeben haben:
- Wenn Sie IPv4 als IP-Familie des Clusters angegeben haben, erstellt die Kubernetes-Engine einen IP-Bereich des IPv4-Serviceclusters für das Cluster.
- Wenn Sie sowohl IPv4 als auch IPv6 als IP-Familien des Clusters angegeben haben, erstellt die Kubernetes-Engine sowohl einen IP-Bereich des IPv4-Serviceclusters als auch einen IP-Bereich des IPv6-Serviceclusters für das Cluster.
Standardmäßig wird neuen Services, die in einem Cluster bereitgestellt werden, eine IP-Adresse aus dem IP-Bereich des ersten Serviceclusters zugewiesen, der für das Cluster angegeben ist. Sie können jedoch das Feld spec.ipFamilyPolicy
im Servicemanifest verwenden, um anzugeben, welcher Servicecluster-IP-Bereich verwendet wird (IPv4 oder IPv6):
- Legen Sie
ipFamilyPolicy: SingleStack
fest, um IP-Adressen für den Service aus dem für das Cluster angegebenen IP-Bereich des ersten Serviceclusters zuzuweisen. Wenn das Cluster sowohl einen IP-Bereich des IPv4-Serviceclusters als auch einen IP-Bereich des IPv6-Serviceclusters aufweist, legen Sie das Feldspec.ipFamilies
im Servicemanifest fest, wenn Sie explizit angeben möchten, welcher IP-Bereich des Serviceclusters verwendet werden soll. -
Legen Sie
ipFamilyPolicy: PreferDualStack
fest, um dem Service sowohl IPv4- als auch IPv6-Adressen zuzuweisen, wenn der Service in einem Cluster mit einem IP-Bereich des IPv4-Service und eines IPv6-Serviceclusters bereitgestellt wird. Legen Sie das Feldspec.ipFamilies
im Servicemanifest fest, wenn Sie explizit angeben möchten, welche der beiden IP-Adressen als primäre IP-Adresse des Service verwendet werden sollen.Wenn der Service andernfalls in einem Cluster bereitgestellt wird, das nur über einen Servicecluster-IP-Bereich verfügt, wird dem Service aus diesem Servicecluster-IP-Bereich eine IP-Adresse zugewiesen.
-
Legen Sie
ipFamilyPolicy: RequireDualStack
fest, um dem Service sowohl IPv4- als auch IPv6-Adressen zuzuweisen, wenn der Service in einem Cluster mit einem IP-Bereich des IPv4-Service und eines IPv6-Serviceclusters bereitgestellt wird. Legen Sie das Feldspec.ipFamilies
im Servicemanifest fest, wenn Sie explizit angeben möchten, welche der beiden IP-Adressen als primäre IP-Adresse des Service verwendet werden sollen.Wenn das Cluster nur über einen Servicecluster-IP-Bereich verfügt, stellen Sie den Service andernfalls nicht bereit.
Die Tabelle zeigt die Interaktion zwischen der IP-Adressfamilie des Clusters, den Einstellungen von spec.ipFamilyPolicy
und spec.ipFamilies
im Servicemanifest und der IP-Adressfamilie, aus der IP-Adressen dem Service zugewiesen werden. Beachten Sie, dass nur gültige Kombinationen angezeigt werden.
IP-Adressfamilie des Clusters | ipFamilyPolicy gesetzt auf: |
ipFamilies gesetzt auf: |
Von Service zugewiesene IP-Adressen aus dieser IP-Adressfamilie |
---|---|---|---|
IPv4 | SingleStack |
IPv4 |
IPv4 |
IPv4 und IPv6 | SingleStack |
IPv4 |
IPv4 |
IPv4 und IPv6 | SingleStack |
IPv6 |
IPv6 |
IPv4 | PreferDualStack |
IPv4 |
IPv4 |
IPv4 und IPv6 | PreferDualStack |
IPv4 |
IPv4 |
IPv4 und IPv6 | PreferDualStack |
IPv6 |
IPv6 |
IPv4 und IPv6 | PreferDualStack |
IPv4,IPv6 |
IPv4(primär) und IPv6 |
IPv4 und IPv6 | PreferDualStack |
IPv6,IPv4 |
IPv6(primär) und IPv4 |
IPv4 und IPv6 | RequireDualStack |
IPv4,IPv6 |
IPv4(primär) und IPv6 |
IPv4 und IPv6 | RequireDualStack |
IPv6,IPv4 |
IPv6(primär) und IPv4 |
Beachten Sie, dass den Services kubernetes.default und kube-dns.kube-system, die automatisch in jedem Cluster bereitgestellt werden, IP-Adressen zugewiesen werden, die mit der IP-Familie des Clusters übereinstimmen.
Weitere Informationen zur Unterstützung von IPv4 und IPv6 in Kubernetes finden Sie in der Kubernetes-Dokumentation unter IPv4/IPv6 dual-stack.