Конфигурация внешнего балансировщика нагрузки GKE, NEG пусты, проверки работоспособности не работают

Я работаю над развертыванием в GKE, это мое первое развертывание, поэтому я новичок в этих концепциях, но я понимаю, куда они идут с инструментами, просто нужен опыт, чтобы быть уверенным.

Во-первых, у меня есть кластер с пятью службами, две из которых я хочу предоставить через внешний балансировщик нагрузки. Я определил аннотацию для Gcloud, чтобы настроить их при балансировке нагрузки, и, похоже, она работает. Я также установил аннотацию для настройки групп конечных точек сети для служб. Вот как он настроен, как в манифестах развертывания и обслуживания.

---
#api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    kompose.cmd: kompose convert -f ./docker-compose.yml
    kompose.version: 1.21.0 ()
  creationTimestamp: null
  labels:
    io.kompose.service: api
  name: api
spec:
  replicas: 1
  selector:
    matchLabels:
      io.kompose.service: api
  strategy:
    type: Recreate
  template:
    metadata:
      annotations:
        kompose.cmd: kompose convert -f ./docker-compose.yml
        kompose.version: 1.21.0 ()
      creationTimestamp: null
      labels:
        io.kompose.service: api
    spec:
      containers:
      - args:
        - bash
        - -c
        - node src/server.js
        env:
        - name: NODE_ENV
          value: production
        - name: TZ
          value: America/New_York
        image: gcr.io/<PROJECT_ID>/api
        imagePullPolicy: Always
        name: api
        ports:
        - containerPort: 8087
        resources: {}
      restartPolicy: Always
      serviceAccountName: ""
status: {}

---
#api-service.yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
    cloud.google.com/neg: '{"ingress": true}'
  creationTimestamp: null
  labels:
    io.kompose.service: api
  name: api
spec:
  type: LoadBalancer
  ports:
  - name: "8087"
    port: 8087
    targetPort: 8087
status:
  loadBalancer: {}

Я думаю, что здесь может отсутствовать какая-то конфигурация, но я не уверен.

Я также видел, где я могу определить проверки живучести в yaml, добавив

livenessProbe:
      httpGet:
        path: /healthz
        port: 8080

У меня также мой вход настроен следующим образом:

---
# master-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: master-application-ingress
  annotations:
    ingress.kubernetes.io/secure-backends: "true"
spec:
  rules:
  - http:
      paths:
      - path: /api
        backend:
          serviceName: api
          servicePort: 8087
  - http:
      paths:
      - path: /ui
        backend:
          serviceName: ui
          servicePort: 80

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

Кроме того, у меня проблема с NEG, созданным пустой аннотацией, или это нормально с NEG, созданным в манифесте?


kubernetes google-cloud-platform google-kubernetes-engine gke-networking
person Chris Rutherford    schedule 23.06.2020    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Проверка работоспособности создается на основе вашего readinessProbe, а не livenessProbe. . Перед созданием входящего ресурса убедитесь, что в спецификации вашего модуля настроен readinessProbe.

Что касается пустого NEG, это может быть связано с несоответствием Health Check. NEG будет полагаться на функцию ворот готовности (объясняется здесь), поскольку у вас определен только livenessProbe, вполне возможно, что проверка работоспособности неправильно сконфигурирована и, следовательно, завершится ошибкой.

У вас также должен быть внутренний IP-адрес для внутреннего LB, который вы создали, можете ли вы таким образом получить доступ к модулям? Если оба не работают, скорее всего, проблема заключается в проверке работоспособности, поскольку NEG не добавляет модули в группу, которую считает не готовой.

person Patrick W    schedule 23.06.2020

arrow_upward
0
arrow_downward

Теперь вы также можете создать BackendConfig как отдельную декларацию Kubernetes. Мой пример:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: cms-backend-config
  namespace: prod
spec:
  healthCheck:
    checkIntervalSec: 60
    port: 80
    type: HTTP #case-sensitive
    requestPath: /your-healthcheck-path
  connectionDraining:
    drainingTimeoutSec: 60

У меня вообще нет явно определенных зондов готовности / живучести, и все работает. Я также заметил, что между GKE и остальной частью GCP все еще иногда возникают сбои. Я помню, что мне потребовалось воссоздать как свои развертывания, так и вход с нуля в какой-то момент после того, как я некоторое время поигрался с разными вариантами.
То, что я тоже сделал, и это могло быть основной причиной, по которой я начал видеть конечные точки в автоматически регистрируемых NEG к входящему запросу добавляется серверная часть по умолчанию, чтобы не регистрировать отдельное значение по умолчанию в Load Balancer:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: prod-ingress
  namespace: prod
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.global-static-ip-name: load-balancer-ip
    networking.gke.io/managed-certificates: my-certificate
spec:
  backend:
    serviceName: my-service
    servicePort: 80
  rules:
    - host: "example.com"
      http:
        paths:
          - path: /
            backend:
              serviceName: my-service
              servicePort: 80
person yuranos    schedule 06.12.2020