GKE NEG Readiness Failing with Windows Containers and Readiness

Question

我遇到了一个问题：

尝试使用容器本机负载平衡(CNLB)时，获取运行状况检查以使在IIS容器中运行的.Net应用程序成功。

我有一个由GKE中的入口资源定义创建的网络端点组(NEG)，其中包含一个VPC本机群集。

当我通过公开NodePort或创建LoadBalancer类型的服务来绕过CNLB时，站点解决了问题。

describe中的所有pod条件看起来都很好：pod readiness

在运行describe endpoints：ready addresses时显示网络端点

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

当从同一VPC中的其他容器或虚拟机命中这些端点时，/health.htm以200作为响应。下面是来自相同名称空间的容器的代码，尽管我已经使用Linux重现了它，不是在集群中，而是在相同的VPC中：endpoint responds

但尽管如此，健康检查报告我的NEG中的pods不健康：Unhealthy Endpoints

堆栈驱动程序日志确认请求超时，但我不确定为什么端点会响应其他实例，而不是LB：Stackdriver Health Check Log

我确认GKE创建了看起来正确的防火墙规则，它应该允许从LB到pods的流量：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                 

入口是非常基本的，因为我们在这个站点上并不需要多个路由，然而，我怀疑我们在这里遇到了什么问题。

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 Containers或Readiness：https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing#using-pod-readiness-feedback

任何建议都将不胜感激。我已经花了两天的时间在这个问题上，我相信这是显而易见的，但我就是看不到问题所在。

Answer 1

显然没有文档记录，但在撰写本文时，该功能还不能与Windows容器一起使用。我联系了一位GCP工程师，他们提供了以下内容：

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

由于Ingress + NEG不起作用(根据限制)，我建议您使用您提到的任何选项，要么公开NodePort，要么创建LoadBalancer类型的服务。

Answer 2

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

看起来你的应用报告它在端口80上是healthCheck，但在/health.htm路径上。

您将需要通过BackendConfig CRD添加自定义healthCheck。看看这个链接1.你可以在同一页中找到如何将BackendConfig关联到入口

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

1