У меня проблема:
Получение проверки работоспособности для успешного выполнения .Net-приложения, запущенного в контейнере IIS, при попытке использовать собственную балансировку нагрузки контейнера (CNLB).
У меня есть группа конечных точек сети (NEG), созданная определением ресурса Ingress в GKE с собственным кластером VPC.
Когда я обхожу CNLB, либо открывая NodePort, либо создавая службу типа LoadBalancer, сайт разрешается без проблем.
Все условия пакета из описания выглядят хорошо: готовность модуля
Конечные точки сети отображаются при запуске describe endpoints: готовых адресов
Это проверка работоспособности, которая создается балансировщиком нагрузки: Проверка работоспособности GCP
При обращении к этим конечным точкам из других контейнеров или виртуальных машин в том же VPC, /health.htm отвечает 200. Здесь из контейнера в том же пространстве имен, хотя я воспроизвел это с помощью виртуальной машины Linux, не в кластере, а в том же VPC: конечная точка отвечает
Но, несмотря на все это, проверка работоспособности сообщает о том, что модули в моем NEG неработоспособны: Нездоровые конечные точки < / а>
Журналы stackdriver подтверждают, что время ожидания запросов истекло, но я не уверен, почему, когда конечные точки отвечают другим экземплярам, но не LB: Журнал проверки работоспособности Stackdriver
И я подтвердил, что GKE создал то, что выглядит как правильное правило брандмауэра, которое должно разрешать трафик от LB к модулям: брандмауэр
Вот YAML, с которым я работаю:
Развертывание:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: subdomain.domain.tld
name: subdomain-domain-tld
namespace: subdomain-domain-tld
spec:
replicas: 3
selector:
matchLabels:
app: subdomain.domain.tld
template:
metadata:
labels:
app: subdomain.domain.tld
spec:
containers:
- image: gcr.io/ourrepo/ourimage
name: subdomain-domain-tld
ports:
- containerPort: 80
readinessProbe:
httpGet:
path: /health.htm
port: 80
initialDelaySeconds: 60
periodSeconds: 60
timeoutSeconds: 10
volumeMounts:
- mountPath: C:\some-secrets
name: some-secrets
nodeSelector:
kubernetes.io/os: windows
volumes:
- name: some-secrets
secret:
secretName: some-secrets
Услуга:
apiVersion: v1
kind: Service
metadata:
labels:
app: subdomain.domain.tld
name: subdomain-domain-tld-service
namespace: subdomain-domain-tld
spec:
ports:
- port: 80
targetPort: 80
selector:
app: subdomain.domain.tld
type: NodePort
Ingress чрезвычайно прост, поскольку у нас нет реальной необходимости в нескольких маршрутах на этом сайте, однако я подозреваю, что любые проблемы, которые у нас возникают, здесь.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: gce
labels:
app: subdomain.domain.tld
name: subdomain-domain-tld-ingress
namespace: subdomain-domain-tld
spec:
backend:
serviceName: subdomain-domain-tld-service
servicePort: 80
Последняя важная деталь: я попробовал шаги, представленные в этой документации, и они сработали, но они не идентичны моей ситуации, поскольку не используются ни контейнеры Windows, ни тесты готовности: https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing#using-pod-readiness-feedback.
Любые предложения будут ценны. Я два дня зацикливался на этом, и я уверен, что это очевидно, но я просто не вижу проблемы.
