☰

K3s - dial tcp 10.43.0.1:443: connect: Verbindung abgelehnt

tag-icon • tag-icon k3s
K3s - dial tcp 10.43.0.1:443: connect: Verbindung abgelehnt

Ich habe einen eingebetteten K3s-Multimastercluster wie folgt erstellt:

Hostname: k3s01

curl -sfL https://get.k3s.io | K3S_TOKEN=xxx INSTALL_K3S_EXEC="server --disable servicelb --disable traefik --bind-address=10.0.0.4 --tls-san 10.0.0.4 --node-external-ip=168.119.x.x --node-ip=10.0.0.4 --flannel-iface=enp7s0 --advertise-address=PUBIP-OF-LB --cluster-init" sh -

Hostname: k8s02

curl -sfL https://get.k3s.io | K3S_TOKEN=xxx INSTALL_K3S_EXEC="server --disable servicelb --disable traefik --bind-address=10.0.0.2 --tls-san 10.0.0.2 --node-ip 10.0.0.2 --node-external-ip=168.119.x.x  --flannel-iface=enp7s0 --server=https://10.0.0.4:6443" sh -

Hostname: k8s03

curl -sfL https://get.k3s.io | K3S_TOKEN=xxx INSTALL_K3S_EXEC="server --disable servicelb --disable traefik --bind-address=10.0.0.3 --tls-san 10.0.0.3 --node-ip 10.0.0.3 --node-external-ip=168.119.x.x  --flannel-iface=enp7s0 --server=https://10.0.0.4:6443" sh -

Ich kann mich von meinem lokalen Rechner aus mit kubectl über die LB-IP verbinden! LB: tcp 6443 -> 6443

Ich kann kubectl auch von jedem der oben genannten Knoten aus verwenden. Ich habe CSI für Hetzner bereitgestellt, das funktioniert auch einwandfrei. Getestet mit ihrer Testbereitstellung!

Nach all dem (was bisher gut funktioniert) habe ich jedoch versucht, ingress-nginx zu installieren. Die Bereitstellung startete ohne Probleme. Ich habe jedoch festgestellt, dass es ein Problem bei der Kommunikation mit dem API-Server innerhalb des Clusters gibt, wie das folgende Protokoll des ingress-nginx-Controllers zeigt:

E1204 11:42:25.216392       8 leaderelection.go:321] error retrieving resource lock ingress-nginx/ingress-controller-leader-nginx: Get "https://10.43.0.1:443/api/v1/namespaces/ingress-nginx/configmaps/ingress-controller-leader-nginx": dial tcp 10.43.0.1:443: connect: connection refused

Hm, seltsam! Ok, lass uns ein paar Checks machen:

kubectl get svc kubernetes -o yaml

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2020-12-04T11:22:25Z"
  labels:
    component: apiserver
    provider: kubernetes
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          .: {}
          f:component: {}
          f:provider: {}
      f:spec:
        f:clusterIP: {}
        f:ports:
          .: {}
          k:{"port":443,"protocol":"TCP"}:
            .: {}
            f:name: {}
            f:port: {}
            f:protocol: {}
            f:targetPort: {}
        f:sessionAffinity: {}
        f:type: {}
    manager: k3s
    operation: Update
    time: "2020-12-04T11:22:25Z"
  name: kubernetes
  namespace: default
  resourceVersion: "10434"
  selfLink: /api/v1/namespaces/default/services/kubernetes
  uid: f0993556-3b7f-40aa-a293-45170cb03002
spec:
  clusterIP: 10.43.0.1
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 6443
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

Sieht toll aus.

kubectl get endpoints -o yaml

apiVersion: v1
items:
- apiVersion: v1
  kind: Endpoints
  metadata:
    creationTimestamp: "2020-12-04T11:22:25Z"
    labels:
      endpointslice.kubernetes.io/skip-mirror: "true"
    managedFields:
    - apiVersion: v1
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:labels:
            .: {}
            f:endpointslice.kubernetes.io/skip-mirror: {}
        f:subsets: {}
      manager: k3s
      operation: Update
      time: "2020-12-04T11:23:39Z"
    name: kubernetes
    namespace: default
    resourceVersion: "808"
    selfLink: /api/v1/namespaces/default/endpoints/kubernetes
    uid: cb450392-b4c9-4c2f-bfde-1a3b20ac4b5d
  subsets:
  - addresses:
    - ip: 167.233.x.x
    - ip: 168.119.x.x
    - ip: 168.119.x.x
    ports:
    - name: https
      port: 6443
      protocol: TCP
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Ok, warum gibt es hier Pub-IPs? Überprüfen wir es von innerhalb eines Pods aus, um eine der IPs direkt aufzurufen:

kubectl exec -it ingress-controler-pod-xxxx -- bash

bash-5.0$ curl https://167.233.x.x:6443 --insecure
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "Unauthorized",
  "reason": "Unauthorized",
  "code": 401
}bash-5.0$ curl https://10.43.0.1:443
curl: (7) Failed to connect to 10.43.0.1 port 443: Connection refused

Ok... das ist seltsam!

Manchmal treten auch Fehler auf wie:

Error from server: error dialing backend: dial tcp: lookup k8s02: Try again

erscheint, wenn ich versuche, exex in einen Pod einzubinden oder Protokolle anzuzeigen. Das passiert nur, wenn ich versuche, dies mit einem Ziel-Pod zu tun, der auf einem anderen Host läuft.

Stimmt etwas mit DNS nicht?

cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad

Ich kann meine Hosts nicht anhand ihres Namens auflösen. Allerdings habe ich im K3s-Setup gerade IPs angegeben. Benötige ich funktionierendes DNS zwischen meinen Hosts? Stimmt etwas mit meinen K3s-Installationsparametern nicht?

Antwort1

Ich hatte ein ähnliches Problem, das durch eine falsch konfigurierte DNS-Auflösung verursacht wurde. Überprüfen Sie, ob Sie die Hostnamen der Knoten untereinander auflösen können.

verwandte Informationen