GKE NEG准备就绪门在Windows容器和准备就绪探测器中出现故障

Question

我遇到了一个问题：

获取健康检查以成功。尝试使用容器本机负载平衡（CNLB）时，在IIS容器中运行的Net app。

我有一个网络endpoint组（NEG），由GKE中的入口资源定义和VPC本机集群创建。

当我通过公开NodePort或制作LoadBalancer类型的服务来规避CNLB时，站点会毫无问题地解决。

所有的吊舱条件从一个描述看起来不错：吊舱准备就绪

运行时会显示网络endpoint描述endpoint：就绪地址

这是由负载平衡器生成的运行状况检查：GCP运行状况检查

当从同一VPC中的其他容器或VM命中这些endpoint时，/health.htm以200响应。这是来自同一命名空间中的容器，尽管我使用LinuxVM复制了它，不是在集群中，而是在同一VPC中：endpoint响应

但尽管如此，健康检查报告了我的NEG中的POD不健康：不健康终点

堆栈驱动程序日志确认请求超时，但我不确定为什么当endpoint响应其他实例而不是LB时：堆栈驱动程序健康检查日志

我确认GKE创建了看起来正确的防火墙规则，应该允许从LB到Pod的流量：防火墙

以下是我正在与之合作的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                 

入口是非常基本的，因为我们在这个网站上没有真正需要多条路线，但是，我怀疑我们在这里有什么问题。

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就绪反馈

任何建议都将不胜感激。我花了两天时间在这个问题上，我相信这很明显，但我就是看不出问题所在。

Answer 1

您可以参考此GCP文件。注意：Windows Server节点池不支持此功能。

功能限制Windows Server容器尚不支持某些Kubernetes功能。此外，某些功能是特定于Linux的，不适用于Windows。有关支持和不支持的Kubernetes功能的完整列表，请参阅Kubernetes文档。

除了不受支持的Kubernetes特性外，还有一些GKE特性不受支持。

对于GKE群集，Windows Server节点池不支持以下功能：

云tpu（--启用tpu）具有网络endpoint组的图像流入口节点内可见性（--启用节点内可见性）IP伪装代理Kubernetes alpha群集（--启用Kubernetes alpha）节点本地DNS缓存私有使用E类IP地址私有使用公共IP地址网络策略日志记录Kubernetes服务。spec.sessionAffinity Spot VMs GPU（--加速器）

https://cloud.google.com/kubernetes-engine/docs/concepts/windows-server-gke https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#container-native\u load\u平衡

Answer 2

创建入口时，生成的HC探测器将默认在与应用程序相同的服务端口和路径上执行HealthCheck。在这种情况下，路径上的端口80/

似乎您的应用程序报告它在端口80上是健康检查，但在/health.htm路径上。

您需要通过BackendConfig CRD添加自定义healthCheck。请查看此链接[1]。您可以在同一页中找到如何将BackendConfig与入口关联

您使用的是什么版本的GKE？从您使用的入口API来看，这似乎是一个旧版本。

[1]https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features#direct_health

Answer 3

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

经过进一步调查，我发现使用LoadBalancer服务的Windows容器可以工作，但使用带有NEGS的入口的Windows容器是一个限制，因此，我打开了一个内部案例来更新公共文档[1]。

因为，入口NEG将无法工作（根据限制），我建议您使用您提到的任何选项，要么公开NodePort，要么创建LoadBalancer类型的服务。