gpt4 book ai didi

kubernetes - GKE NEG Readiness Gate 因 Windows 容器和 Readiness Probe 而失败

转载 作者:行者123 更新时间:2023-12-02 12:26:47 28 4
gpt4 key购买 nike

我遇到了一个问题:

在尝试使用容器 native 负载平衡 (CNLB) 时,为在 IIS 容器中运行的 .Net 应用成功进行健康检查。

我有一个网络端点组 (NEG),它是由 GKE 中的入口资源定义创建的,带有 VPC 原生集群。

当我通过公开 NodePort 或提供 LoadBalancer 类型的服务来规避 CNLB 时,该站点可以毫无问题地解析。

描述中的所有 pod 条件看起来都不错: pod readiness

运行 describe endpoints 时出现网络端点:ready addresses

这是负载均衡器生成的健康检查:GCP Health Check

当从同一 VPC 中的其他容器或 VM 访问这些端点时,/health.htm 以 200 响应。这是来自同一命名空间中的容器,尽管我已经使用 Linux VM 重现了它,但不是在集群中,而是在同一个 VPC 中:endpoint responds

但尽管如此,健康检查报告我的 NEG 中的 pod 不健康:Unhealthy Endpoints

stackdriver 日志确认请求超时,但我不确定为什么端点响应其他实例而不是 LB:Stackdriver Health Check Log

而且我确认 GKE 创建了看起来像正确的防火墙规则,应该允许从 LB 到 pod 的流量:firewall

这是我正在使用的 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

如有任何建议,我们将不胜感激。我花了两天时间研究这个问题,我确信这很明显,但我就是看不出问题所在。

最佳答案

显然它没有记录,但在撰写本文时此功能不适用于 Windows 容器。我能够与 GCP 工程师取得联系,他们提供了以下信息:

After further investigation, I have found that Windows containers using LoadBalancer service works but, Windows containers using Ingress with NEGS is a limitation so, I have opened an internal case for updating the public documentation [1].

Since, Ingress + NEG will not work (per the limitation), I suggest you to use any option you mentioned either exposing the NodePort or making a service of type LoadBalancer.

关于kubernetes - GKE NEG Readiness Gate 因 Windows 容器和 Readiness Probe 而失败,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/62905371/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com