Балансировщик нагрузки GCP HTTP (S), игнорирующий спецификацию GKE readinessProbe - PullRequest
Новая
       21

Балансировщик нагрузки GCP HTTP (S), игнорирующий спецификацию GKE readinessProbe

0 голосов
/ 26 февраля 2020

Я уже видел этот вопрос ; AFAIK Я делаю все в ответах там.

Используя GKE, я развернул вход на основе балансировщика нагрузки GCP HTTP (S) для кластера kubernetes, содержащего два почти идентичных развертывания: производственное и экземпляры разработки одного и того же приложения.

Я настроил выделенный порт в каждом шаблоне модуля для использования для проверок работоспособности балансировщиком нагрузки, чтобы на них не влияли перенаправления из пути root в основном HTTP порт. Однако проверки работоспособности постоянно завершаются неудачей.

Начиная с этих документов Я добавил параметр readinessProbe в мои развертывания, которые балансировщик нагрузки, похоже, полностью игнорирует. .

Я проверил, что сервер на :p-ready (9292; выделенный порт проверки работоспособности) работает правильно, используя следующее (в отдельных терминалах): 

➜ kubectl port-forward deployment/d-an-server p-ready
➜ curl http://localhost:9292/ -D -
HTTP/1.1 200 OK
content-length: 0
date: Wed, 26 Feb 2020 01:21:55 GMT

Что я пропустил?

Несколько замечаний по приведенным ниже конфигам:

  • Переменные ${...} ниже заполняются сценарием сборки как часть развертывания.
  • Второй сервис (s-an-server-dev) является почти точной копией первого (со своим собственным развертыванием) только с суффиксами -dev на именах и метках.

Развертывание 

apiVersion: "apps/v1"
kind: "Deployment"
metadata:
  name: "d-an-server"
  namespace: "default"
  labels:
    app: "a-an-server"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: "a-an-server"
  template:
    metadata:
      labels:
        app: "a-an-server"
    spec:
      containers:
        - name: "c-an-server-app"
          image: "gcr.io/${PROJECT_ID}/an-server-app:${SHORT_SHA}"
          ports:
            - name: "p-http"
              containerPort: 8080
            - name: "p-ready"
              containerPort: 9292
          readinessProbe:
            httpGet:
              path: "/"
              port: "p-ready"
            initialDelaySeconds: 30

Сервис 

apiVersion: "v1"
kind: "Service"
metadata:
  name: "s-an-server"
  namespace: "default"
spec:
  ports:
    - port: 8080
      targetPort: "p-http"
      protocol: "TCP"
      name: "sp-http"
  selector:
    app: "a-an-server"
  type: "NodePort"

Вход 

apiVersion: "networking.k8s.io/v1beta1"
kind: "Ingress"
metadata:
  name: "primary-ingress"
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "primary-static-ipv4"
    networking.gke.io/managed-certificates: "appname-production-cert,appname-development-cert"
spec:
  rules:
    - host: "appname.example.com"
      http:
        paths:
          - backend:
              serviceName: "s-an-server"
              servicePort: "sp-http"
    - host: "dev.appname.example.com"
      http:
        paths:
          - backend:
              serviceName: "s-an-server-dev"
              servicePort: "sp-http-dev"

1 Ответ

2 голосов
/ 26 февраля 2020

Я думаю, что здесь происходит, что вход GKE вообще не проинформирован о порте 9292. Вы имеете в виду sp-http во входе, который относится к порту 8080.

Вам необходимо убедиться в следующем:

1. Поле targetPort службы должно указывать на значение или имя containerPort порта pod.

2. Датчик готовности должен быть выставлен на порту, соответствующем servicePort, указанному в Ingress.

...