Kubernetes: el servicio no tiene puntos finales a pesar de que los selectores de etiquetas coinciden, el servicio sin cabeza idéntico obtiene puntos finales

Kubernetes: el servicio no tiene puntos finales a pesar de que los selectores de etiquetas coinciden, el servicio sin cabeza idéntico obtiene puntos finales

Estoy implementando el siguiente conjunto de estado, que incluye dos servicios diferentes. Un servicio para el acceso del clúster a los pods ( crdb-service.yaml) y un servicio para la comunicación interna de los 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

Ahora verifico los servicios implementados:

$ 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>

El campo de puntos finales del servicio de cluster está vacío, a pesar de tener exactamente los mismos selectores de etiquetas. Comprobaciónhttps://github.com/kubernetes/kubernetes/issues/11795 https://kubernetes.io/docs/tasks/debug-application-cluster/debug-serviceno descubre la causa.

Alguna información adicional que pueda estar relacionada con el tema en cuestión. Actualicé mi clúster desde 1.13 -> 1.14 -> 1.15. Los pods se ejecutan en nodos que se agregaron recientemente al clúster. Hubo un problema de red antes, para los pods implementados en los nuevos nodos (sin acceso debido a un DNS fallido, esto se resolvió configurándolo net.ipv4.ip_forward = 1en los nuevos nodos)

¿Cómo puedo hacer que el servicio reconozca los pods?

Respuesta1

NVM, solo perdí 2 horas. Es simplemente el campo publishNotReadyAddresses: trueque debe agregarse al servicio para los pods que publican su IP al inicio.

información relacionada