O notebook Jupyter no kubernetes não consegue se conectar ao serviço docker externo

O notebook Jupyter no kubernetes não consegue se conectar ao serviço docker externo

Estou executando um pod kubernetes (kubeflow + k8s) com um notebook jupyter e um serviço docker fora do servidor kubernetes. No momento, estou tentando me conectar a um serviço sql, mas ele continua recebendo ConnectionResetError, tanto o firewall quanto o docker estão expondo a porta necessária, mas o O k8s continua não conseguindo se conectar, qual poderia ser o problema? (diga-me se precisar de mais detalhes).

Obrigado.

Responder1

Como mencionado nos comentários

Da perspectiva do istio, para fazer isso funcionar, você teria que adicionarEntrada de serviçoportanto, os pods injetados pelo istio podem se comunicar com o banco de dados externo.

ServiceEntry permite adicionar entradas adicionais ao registro de serviço interno do Istio, para que os serviços descobertos automaticamente na malha possam acessar/rotear para esses serviços especificados manualmente. Uma entrada de serviço descreve as propriedades de um serviço (nome DNS, VIPs, portas, protocolos, terminais). Esses serviços podem ser externos à malha (por exemplo, APIs da web) ou serviços internos da malha que não fazem parte do registro de serviços da plataforma (por exemplo, um conjunto de VMs conversando com serviços no Kubernetes). Além disso, os terminais de uma entrada de serviço também podem ser selecionados dinamicamente usando o campo workloadSelector. Esses endpoints podem ser cargas de trabalho de VM declaradas usando o objeto WorkloadEntry ou pods do Kubernetes. A capacidade de selecionar pods e VMs em um único serviço permite a migração de serviços de VMs para Kubernetes sem a necessidade de alterar os nomes DNS existentes associados aos serviços.

Há um exemplo no istiodocumentação.

Observe que você pode encontrarMySQL não consegue se conectar após instalar o Istio. Isso ocorre por causa do modo PERMISSIVE, que não funciona com MySQL. Você pode ver mensagens de erro comoERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0.

Existem duas opções para resolver o problema.

1.Desative o TLS mútuo.

Escolha esta opção se não quiser o TLS mútuo do Istio. Você consegue isso desabilitando explicitamente o TLS mútuo no serviço MySQL.

$ 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.Ative o TLS mútuo no modo STRICT.

Se você deseja proteção TLS mútua para MySQL, habilite o TLS mútuo usando uma regra de destino e uma política de autenticação.

$ 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

informação relacionada