DNS-Proxy einrichten

Hinweis: Diese Anleitung gilt nur für Cloud Service Mesh mit Istio APIs und nicht für Google Cloud APIs. Weitere Informationen finden Sie unter Cloud Service Mesh – Übersicht.

DNS-Proxy ist eine Funktion, die die folgenden Möglichkeiten bietet:

1. DNS-Einträge von Services über Cluster hinweg in einer Multi-Cluster-Einrichtung weitergeben.
2. DNS-Einträge für ServiceEntry werden erstellt.

Kubernetes bietet die DNS-Auflösung nur für Services im lokalen Cluster. Wenn Sie die Namensauflösung für Services in einem Remote-Cluster bereitstellen oder einen internen Hostnamen mit ServiceEntry verwenden müssen, ohne einen zusätzlichen internen DNS-Server zu haben, bietet DNS-Proxy eine Möglichkeit, DNS-Namen für solche Fälle aufzulösen.

Hinweis :Diese Funktion ist über die 1.21.5-asm.39-Datenebene und im Rapid Release Channel verfügbar.

DNS-Proxy konfigurieren

So konfigurieren Sie den DNS-Proxy: Sie können entweder die Cluster- oder die Proxy-weite Konfiguration auswählen.

Clusterweite Konfiguration

Wenn Sie den DNS-Proxy im Cluster konfigurieren möchten, fügen Sie der ConfigMap für MeshConfig die ISTIO_META_DNS_CAPTURE-Proxy-Metadaten hinzu. Der Name des ConfigMap hat das Format istio-<revision_name>. Weitere Informationen zur Überarbeitung finden Sie in der Übersicht über die Überarbeitung.

apiVersion: v1
data:
  mesh: |-
    ...
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"        
    ...
kind: ConfigMap
metadata:
  name: istio-<revision_name>
  namespace: istio-system

Konfiguration pro Proxy

Wenn Sie den DNS-Proxy für einen Proxy konfigurieren möchten, fügen Sie die Metadatenanmerkung ISTIO_META_DNS_CAPTURE proxy wie folgt hinzu:

kind: Deployment
metadata:
  name: app1
  namespace: ns1
spec:
...
  template:
    metadata:
      annotations:
        proxy.istio.io/config: |
          proxyMetadata:
            ISTIO_META_DNS_CAPTURE: "true"
...

Wird überprüft

Führen Sie die Schritte aus, um zu prüfen, ob alles richtig konfiguriert ist.

Namensauflösung für Service über Cluster hinweg

Nach der Multi-Cluster-Einrichtung stellen Sie eine Service nur in einem der Cluster bereit, um die clusterübergreifende Namensauflösung zu prüfen.

Wenn Sie das folgende Beispiel Service ns1/svc1 haben, finden Sie ClusterIP in Service.

$ kubectl get -n ns1 svc1
kind: Service
metadata:
  name: svc1
  namespace: ns1
spec:
...
  ClusterIP: 210.200.1.1
...

Wenn Sie dann curl vom anderen Cluster zum Service verwenden, sollte die ClusterIP so aussehen:

curl -sS -v svc1.ns1.svc.cluster.local
*   Trying 210.200.1.1:80...

Namensauflösung für ServiceEntry

Fügen Sie einen ServiceEntry mit einem Hostnamen hinzu, der nicht in Ihrem DNS registriert ist. Im folgenden Beispiel wird die Namensauflösung mit der expliziten Adresse 192.168.123.123 überprüft.

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: test-service-entry
spec:
  addresses:
  - "192.168.123.123"
  hosts:
  - not-existing-hostname.internal
  ports:
  - name: http
    number: 80
    protocol: HTTP
EOF

Versuchen Sie dann, die DNS-Auflösung in einem Pod auszuführen, in dem DNS-Proxy aktiviert ist. Wenn Sie beispielsweise curl im Pod ausführen, sollte die IP-Adresse so angezeigt werden:

curl -sS -v not-existing-hostname.internal
*   Trying 192.168.123.123:80...

Automatische IP-Zuweisung für ServiceEntry

Wenn Sie ServiceEntry mit dem DNS-Proxy verwenden, können Sie optional die automatische IP-Zuweisung aktivieren. Wenn diese Option aktiviert ist, werden automatisch interne IP-Adressen (aus dem Bereich 240.240.0.0/16) für ServiceEntry-Hosts zugewiesen, für die in spec.addresses keine expliziten IP-Adressen angegeben sind.

Automatische IP-Zuweisung aktivieren

Wenn Sie die automatische IP-Zuweisung aktivieren möchten, folgen Sie der Anleitung für Ihre Implementierung der Steuerungsebene:

TRAFFIC_DIRECTOR

Konfigurieren Sie für die Implementierung der TRAFFIC_DIRECTOR-Steuerungsebene die automatische IP-Zuweisung im asm-options ConfigMap im Namespace istio-system, indem Sie ip_auto_allocation: "true" festlegen.

Hinweis :Bei TRAFFIC_DIRECTOR-Implementierungen wird die automatische IP-Zuweisung nur im Rapid-Release-Kanal unterstützt.

Das folgende Beispiel zeigt eine asm-options-ConfigMap mit aktivierter automatischer IP-Zuweisung:

apiVersion: v1
kind: ConfigMap
metadata:
  name: asm-options
  namespace: istio-system
data:
  # Enable IP auto-allocation for ServiceEntry (Rapid channel)
  ip_auto_allocation: "true"

Sie können diese Konfiguration auch mit kubectl patch anwenden:

kubectl patch configmap/asm-options -n istio-system --type merge \
  -p '{"data":{"ip_auto_allocation":"true"}}'

ISTIOD

Achtung:Die clusterinterne Cloud Service Mesh-Bereitstellung mit der ISTIOD-Steuerungsebene in GKE On Google Cloud wird nicht mehr unterstützt. Cloud Service Mesh mit einer clusterinternen Steuerungsebene in Google Distributed Cloud (nur Software) wird weiterhin wie unter Unterstützte Plattformen beschrieben unterstützt.

Achtung: Verwaltetes Cloud Service Mesh mit der ISTIOD-Steuerungsebenenimplementierung ist eingestellt. Sie müssen alle verwalteten ISTIOD-Flotten auf die TRAFFIC_DIRECTOR-Implementierung der Steuerungsebene modernisieren.

Bei Clustern, die die ISTIOD-Steuerungsebene (im Cluster oder verwaltet ISTIOD) verwenden, konfigurieren Sie die automatische IP-Zuweisung, indem Sie ISTIO_META_DNS_AUTO_ALLOCATE: "true" zu den Proxy-Metadaten in MeshConfig hinzufügen:

apiVersion: v1
data:
  mesh: |-
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"
        ISTIO_META_DNS_AUTO_ALLOCATE: "true"
kind: ConfigMap
metadata:
  name: istio-<revision_name>
  namespace: istio-system

Automatische IP-Zuweisung prüfen

So können Sie prüfen, ob die automatische IP-Zuweisung funktioniert:

Erstellen Sie vor der Bestätigung ein ServiceEntry, ohne spec.addresses anzugeben:

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: auto-allocated-service-entry
  namespace: ns1
spec:
  hosts:
  - auto-allocated.internal
  ports:
  - name: http
    number: 80
    protocol: HTTP
  resolution: DNS
EOF

Hinweis :Der erste Schritt kann nur geprüft werden, wenn Sie die TRAFFIC_DIRECTOR-Implementierung verwenden. Wenn Sie ISTIOD verwenden, fahren Sie mit dem zweiten Schritt fort.

1. Zugewiesene Adresse in status.addresses prüfen (nur TRAFFIC_DIRECTOR)

In der TRAFFIC_DIRECTOR-Implementierung weist der Controller eine VIP zu und füllt das Feld status.addresses des ServiceEntry aus:

$ kubectl get serviceentry auto-allocated-service-entry -n ns1 -o yaml

In der Ausgabe wird die zugewiesene Adresse unter status.addresses angezeigt:

status:
  addresses:
  - host: auto-allocated.internal
    value: 240.240.0.1

2. DNS-Auflösung über einen Pod testen (TRAFFIC_DIRECTOR und ISTIOD)

Senden Sie in beiden Implementierungen (TRAFFIC_DIRECTOR und ISTIOD) eine Anfrage von einem Pod, in dem der DNS-Proxy aktiviert ist, um zu prüfen, ob die Namensauflösung in die zugewiesene VIP aufgelöst wird:

$ kubectl exec deploy/curl -n ns1 -- curl -sS -v http://auto-allocated.internal

Der Verbindungsversuch sollte in der automatisch zugewiesenen VIP aufgelöst werden (z. B. 240.240.0.1:80):

*   Trying 240.240.0.1:80...