Ich betreibe einen Kubernetes-Pod (Kubeflow + K8s) mit einem Jupyter-Notebook und einem Docker-Dienst außerhalb des Kubernetes-Servers. Ich versuche gerade, eine Verbindung zu einem SQL-Dienst herzustellen, erhalte jedoch ständig einen ConnectionResetError. Sowohl die Firewall als auch das Docker geben den benötigten Port frei, aber K8s kann keine Verbindung herstellen. Was könnte das Problem sein? (Sagen Sie mir Bescheid, wenn Sie weitere Einzelheiten benötigen.)
Danke.
Antwort1
Wie in den Kommentaren erwähnt
Um dies zu ermöglichen, müssten Sie aus der Istio-Perspektive Folgendes hinzufügen:Serviceeintragdamit in Istio eingefügte Pods mit externen Datenbanken kommunizieren können.
ServiceEntry ermöglicht das Hinzufügen zusätzlicher Einträge in Istios internes Service-Register, sodass automatisch erkannte Services im Mesh auf diese manuell angegebenen Services zugreifen/sie weiterleiten können. Ein Service-Eintrag beschreibt die Eigenschaften eines Services (DNS-Name, VIPs, Ports, Protokolle, Endpunkte). Diese Services können extern zum Mesh sein (z. B. Web-APIs) oder Mesh-interne Services, die nicht Teil des Service-Registers der Plattform sind (z. B. eine Gruppe von VMs, die mit Services in Kubernetes kommunizieren). Darüber hinaus können die Endpunkte eines Service-Eintrags auch dynamisch ausgewählt werden, indem das Feld workloadSelector verwendet wird. Diese Endpunkte können VM-Workloads sein, die mit dem WorkloadEntry-Objekt oder Kubernetes-Pods deklariert wurden. Die Möglichkeit, sowohl Pods als auch VMs unter einem einzigen Service auszuwählen, ermöglicht die Migration von Services von VMs zu Kubernetes, ohne die vorhandenen DNS-Namen ändern zu müssen, die den Services zugeordnet sind.
Es gibt ein Beispiel in istioDokumentation.
Beachten Sie, dass Sie möglicherweiseMySQL kann nach der Installation von Istio keine Verbindung herstellen. Dies liegt am PERMISSIVE-Modus, der mit MySQL nicht funktioniert. Möglicherweise werden Fehlermeldungen angezeigt wieERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0.
Es gibt zwei Möglichkeiten, das Problem zu lösen.
1. Deaktivieren Sie Mutual TLS.
Wählen Sie diese Option, wenn Sie kein gegenseitiges TLS für Istio wünschen. Dies erreichen Sie, indem Sie das gegenseitige TLS für den MySQL-Dienst explizit deaktivieren.
$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: mysql-nomtls-peerauthn
spec:
selector:
matchLabels:
app: <YOUR-MYSQL-SERVICE> # The label of *your* K8s Service
mtls:
mode: DISABLE
EOF
2. Aktivieren Sie gegenseitiges TLS im STRICT-Modus.
Wenn Sie gegenseitigen TLS-Schutz für MySQL wünschen, aktivieren Sie gegenseitiges TLS mithilfe einer Zielregel und einer Authentifizierungsrichtlinie.
$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: mysql-mtls-peerauthn
spec:
selector:
matchLabels:
app: <YOUR-MYSQL-SERVICE> # The label of *your* K8s Service
mtls:
mode: STRICT
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: mysql-mtls-dr
spec:
host: YOUR-MYSQL-SERVICE # The name of *your* K8s Service
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
EOF