Я знаю, что Ingress требуется служба в работоспособном состоянии, чтобы обслуживать ее содержимое через HTTP (S), и для этого я настроил ReadinessProbe для развертывания моей рабочей нагрузки:
readinessProbe:
failureThreshold: 10
httpGet:
path: /api/healthz
port: 4400
scheme: HTTPS
periodSeconds: 30
successThreshold: 1
timeoutSeconds: 20
По сути, у меня есть веб-сервер, который обслуживает запросы HTTPS на порту. 4400
и я настроил healthz
ресурс для возврата ответа HTTP 200. Мой веб-сервер прослушивает входящие соединения на портах:
Теперь для доступа к этим портам у меня есть служба GKE (myService
), который нацелен на веб-сервер, в частности:
ports:
- name: port-1
nodePort: 31277
port: 80
protocol: TCP
targetPort: 4300
- name: port-2
nodePort: 32167
port: 443
protocol: TCP
targetPort: 4400
Теперь, если я создам новый сервис Ingress (myIngress
) относится к myService
GCP возвращает мне эту конфигурацию Kubernetes:
spec:
backend:
serviceName: my-service
servicePort: port-2
rules:
- host: test-domain-name-here.net
http:
paths:
- backend:
serviceName: my-service
servicePort: port-2
tls:
- secretName: letsencrypt-custom-cert
Как вы можете видеть здесь, он нацелен на servicePort port-2
:
GKE создал (автоматически) новую внутреннюю службу для этой входящей конфигурации с именем k8s-be-32167--XXXX
, который нацелен на port-2
32167
, и самое главное Проверка работоспособности балансировки нагрузки Kubernetes L7 по умолчанию который должен следить за состоянием здоровья - готовность - службы.
Проблема в том, что эта проверка работоспособности должна проверять порт. 32167
используя HTTPS, а не HTTP и всякий раз, когда я пытаюсь установить эту проверку работоспособности для HTTPS через пару минут, GCP сбрасывает все до значений по умолчанию, что очень раздражает !!!
В настоящее время целевые пулы допускают только проверки работоспособности HTTP, и при этом устаревший стиль, вы можете взглянуть на это документация который показывает допустимые концепции и протоколы проверки работоспособности.
Кроме того, я нашел это трекер проблем где вы можете следить и оставлять свои комментарии, чтобы знать, когда HTTPS будет разрешен / поддерживаться для проверок работоспособности.