Kubernetes - Dienst hat trotz übereinstimmender Label-Selektoren keine Endpunkte, identischer Headless-Dienst erhält Endpunkte

Question

Ich stelle das folgende Statefulset bereit, inklusive zweier verschiedener Dienste. Ein Dienst für den Clusterzugriff auf die Pods ( crdb-service.yaml) und ein Dienst für die interne Kommunikation der Pods ( crdb.yaml).

crdb-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: crdb-service
  labels:
    app: crdb
spec:
  ports:
  - port: 26257
    targetPort: 26257
    name: grpc
  - port: 80
    targetPort: 8080
    name: http
  selector:
    app: crdb

crdb.yaml

apiVersion: v1
kind: Service
metadata:
  name: crdb
  labels:
    app: crdb
  annotations:
    service.alpha.kubernetes.io/tolerate-unready-endpoints: "true"
    prometheus.io/scrape: "true"
    prometheus.io/path: "_status/vars"
    prometheus.io/port: "8080"
spec:
  ports:
  - port: 26257
    targetPort: 26257
    name: grpc
  - port: 8080
    targetPort: 8080
    name: http
  publishNotReadyAddresses: true
  clusterIP: None
  selector:
    app: crdb

statefulset.yaml

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: crdb
  labels:
    app: crdb
spec:
  serviceName: "crdb"
  replicas: 5
  template:
    metadata:
      labels:
        app: crdb
    spec:
      serviceAccountName: crdb
      containers:
      - name: crdb
        image: cockroachdb/cockroach:v19.1.2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 26257
          name: grpc
        - containerPort: 8080
          name: http
        livenessProbe:
          httpGet:
            path: "/health"
            port: http
            scheme: HTTPS
          initialDelaySeconds: 30
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: "/health?ready=1"
            port: http
            scheme: HTTPS
          initialDelaySeconds: 10
          periodSeconds: 5
          failureThreshold: 2
        volumeMounts:
        - name: datadir
          mountPath: /cockroach/cockroach-data
        - name: certs
          mountPath: /cockroach/cockroach-certs
        env:
        - name: STATEFULSET_NAME
          value: "crdb"
        - name: STATEFULSET_FQDN
          value: "crdb.default.svc.cluster.local"
        - name: COCKROACH_CHANNEL
          value: kubernetes-secure
        command:
          - "/bin/bash"
          - "-ecx"
          - "exec /cockroach/cockroach start --logtostderr --certs-dir /cockroach/cockroach-certs --advertise-host $(hostname -f) --http-host 0.0.0.0 --join crdb-0.crdb,crdb-1.crdb,crdb-2.crdb,crdb-3.crdb,crdb-4.crdb --cache 25% --max-sql-memory 25%"
      terminationGracePeriodSeconds: 60
      volumes:
      - name: datadir
        persistentVolumeClaim:
          claimName: datadir
      - name: certs
        emptyDir: {}
  podManagementPolicy: Parallel
  updateStrategy:
    type: RollingUpdate
  volumeClaimTemplates:
  - metadata:
      name: datadir
    spec:
      accessModes:
        - "ReadWriteOnce"
      storageClassName: local-crdb-space
      resources:
        requests:
          storage: 1800Gi

Nun überprüfe ich die eingesetzten Dienste:

$ kubectl describe service crdb
Name:              crdb
Namespace:         default
Labels:            app=crdb
Annotations:       kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"prometheus.io/path":"_status/vars","prometheus.io/port":"8080","prometheus.io/scrape":"...
                   prometheus.io/path=_status/vars
                   prometheus.io/port=8080
                   prometheus.io/scrape=true
                   service.alpha.kubernetes.io/tolerate-unready-endpoints=true
Selector:          app=crdb
Type:              ClusterIP
IP:                None
Port:              grpc  26257/TCP
TargetPort:        26257/TCP
Endpoints:         10.244.10.24:26257,10.244.2.23:26257,10.244.3.18:26257 + 2 more...
Port:              http  8080/TCP
TargetPort:        8080/TCP
Endpoints:         10.244.10.24:8080,10.244.2.23:8080,10.244.3.18:8080 + 2 more...
Session Affinity:  None
Events:            <none>

$ kubectl describe service crdb-service
Name:              crdb-service
Namespace:         default
Labels:            app=crdb
Annotations:       kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"crdb"},"name":"crdb-service","namespace":"default"},"spec":{"ports":[...
Selector:          app=crdb
Type:              ClusterIP
IP:                10.100.71.172
Port:              grpc  26257/TCP
TargetPort:        26257/TCP
Endpoints:         
Port:              http  80/TCP
TargetPort:        8080/TCP
Endpoints:         
Session Affinity:  None
Events:            <none>

Das Endpoints-Feld des Cluster-Dienstes ist leer, obwohl die exakt gleichen Label-Selektoren vorhanden sind.https://github.com/kubernetes/kubernetes/issues/11795 https://kubernetes.io/docs/tasks/debug-application-cluster/debug-servicebringt die Ursache nicht ans Licht.

Einige zusätzliche Informationen, die möglicherweise mit dem vorliegenden Problem zusammenhängen. Ich habe meinen Cluster von 1.13 -> 1.14 -> 1.15 aktualisiert. Die Pods laufen auf Knoten, die dem Cluster kürzlich hinzugefügt wurden. Zuvor gab es ein Netzwerkproblem für Pods, die auf den neuen Knoten bereitgestellt wurden (kein Zugriff aufgrund eines DNS-Fehlers, das wurde durch die Einstellung net.ipv4.ip_forward = 1auf den neuen Knoten gelöst).

Wie kann ich erreichen, dass der Dienst die Pods erkennt?

Answer 1

NVM, habe gerade 2 Stunden verschwendet. Es ist einfach das Feld publishNotReadyAddresses: true, das dem Dienst hinzugefügt werden muss, damit Pods ihre IP beim Start veröffentlichen.