Вход на ГКЭ. Выполнить проверку работоспособности службы

Question

Я пытаюсь использовать входящий трафик для балансировщика нагрузки двух служб на движке Google Kubernetes:

вот конфигурация входящего трафика для этого:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: basic-ingress

spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: web
          servicePort: 8080
      - path: /v2/keys
        backend:
          serviceName: etcd-np
          servicePort: 2379

где веб - это пример службы из примеров Google:

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: default
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    run: web
  type: NodePort

----
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: default
spec:
  selector:
    matchLabels:
      run: web
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - image: gcr.io/google-samples/hello-app:1.0
        imagePullPolicy: IfNotPresent
        name: web
        ports:
        - containerPort: 8080
          protocol: TCP

Но второй сервис - это кластер ETCD с сервисом NodePort:

---
apiVersion: v1
kind: Service
metadata:
  name: etcd-np
spec:
  ports:
  - port: 2379
    targetPort: 2379
  selector:
    app: etcd
  type: NodePort

Но только первое правило входа работает правильно, я вижу в журналах:

ingress.kubernetes.io/backends: {"k8s-be-30195--ebfd7339a961462d":"UNHEALTHY","k8s-be-30553--ebfd7339a961462d":"HEALTHY","k8s-be-31529--ebfd7339a961462d":"HEALTHY"}

У меня etcd-np работает правильно, это не проблема etcd, я думаю, проблема в том, что сервер etcd отвечает 404 на GET / запрос, а некоторая проверка работоспособности на уровне входа не позволяет его использовать.

Вот почему у меня есть 2 вопроса:

1) Как я могу предоставить URL-адреса проверки работоспособности для каждого внутреннего пути при входе

2) Как я могу отладить такие проблемы. Сейчас я вижу

kubectl describe ingress basic-ingress
Name:             basic-ingress
Namespace:        default
Address:          4.4.4.4
Default backend:  default-http-backend:80 (10.52.6.2:8080)
Rules:
  Host        Path  Backends
  ----        ----  --------
  *           
              /*         web:8080 (10.52.8.10:8080)
              /v2/keys   etcd-np:2379 (10.52.0.2:2379,10.52.2.4:2379,10.52.8.4:2379)
Annotations:  ingress.kubernetes.io/backends:
                {"k8s-be-30195--ebfd7339a961462d":"UNHEALTHY","k8s-be-30553--ebfd7339a961462d":"HEALTHY","k8s-be-31529--ebfd7339a961462d":"HEALTHY"}
              ingress.kubernetes.io/forwarding-rule: k8s-fw-default-basic-ingress--ebfd7339a961462d
              ingress.kubernetes.io/target-proxy: k8s-tp-default-basic-ingress--ebfd7339a961462d
              ingress.kubernetes.io/url-map: k8s-um-default-basic-ingress--ebfd7339a961462d
Events:       <none>

Но он не предоставляет мне никакой информации об этом инциденте

UP

kubectl describe svc etcd-np

Name:                     etcd-np
Namespace:                default
Labels:                   <none>
Annotations:              Selector:  app=etcd
Type:                     NodePort
IP:                       10.4.7.20
Port:                     <unset>  2379/TCP
TargetPort:               2379/TCP
NodePort:                 <unset>  30195/TCP
Endpoints:                10.52.0.2:2379,10.52.2.4:2379,10.52.8.4:2379
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

Answer 1

Согласно do c.

Служба, предоставляемая через Ingress, должна отвечать на проверки работоспособности от балансировщика нагрузки. Любой контейнер, который является конечным пунктом назначения трафика с балансировкой нагрузки c, должен выполнить одно из следующих действий, чтобы указать, что он исправен:

1. Отправлять ответ со статусом HTTP 200 для Запросы GET на пути /.
2. Настройте проверку готовности HTTP. Отправлять ответ со статусом HTTP 200 на запросы GET по пути, указанному зондом готовности. Служба, предоставляемая через Ingress, должна указывать на тот же порт контейнера, на котором включена проверка готовности.

Например, предположим, что контейнер указывает эту проверку готовности:

...
readinessProbe:
  httpGet:
    path: /healthy

Затем, если обработчик для пути /healthy контейнера возвращает состояние HTTP 200, балансировщик нагрузки считает, что контейнер работает и исправен.

Теперь, поскольку ETCD имеет конечную точку работоспособности в /health зонд готовности будет выглядеть как

...
readinessProbe:
  httpGet:
    path: /health

Это становится немного сложнее, если mTLS включен в ETCD. Чтобы избежать этого, проверьте документы .