Kubernetes — у сервиса нет конечных точек, несмотря на соответствующие селекторы меток, идентичный Headless Service получает конечные точки

2024-7-19 • tag-icon

Kubernetes — у сервиса нет конечных точек, несмотря на соответствующие селекторы меток, идентичный Headless Service получает конечные точки

Я развертываю следующий statefulset, включающий две разные службы. Одна служба для доступа кластера к модулям ( crdb-service.yaml) и одна служба для внутренней связи модулей ( 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

Теперь я проверяю развернутые службы:

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

Поле конечных точек кластерной службы пусто, несмотря на то, что у него точно такие же селекторы меток. Проверкаhttps://github.com/kubernetes/kubernetes/issues/11795 https://kubernetes.io/docs/tasks/debug-application-cluster/debug-serviceне раскрывает причину.

Дополнительная информация, которая может быть связана с рассматриваемой проблемой. Я обновил свой кластер с 1.13 -> 1.14 -> 1.15. Поды работают на узлах, которые были недавно добавлены в кластер. Раньше была проблема с сетью для подов, развернутых на новых узлах (нет доступа из-за сбоя DNS, решил это настройкой net.ipv4.ip_forward = 1на новых узлах)

Как мне заставить сервис распознавать модули?

решение1

NVM, только что потратил 2 часа. Это просто поле publishNotReadyAddresses: true, которое нужно добавить в сервис для pod'ов, публикующих свой IP при запуске.

решение1

Связанный контент