GKE NEG Readiness Gate 因 Windows 容器和 Readiness Probe 而失败答案

【问题标题】：GKE NEG Readiness Gate Failing with Windows Containers and Readiness ProbeGKE NEG Readiness Gate 因 Windows 容器和 Readiness Probe 而失败
【发布时间】：2020-07-14 23:18:53
【问题描述】：

我遇到了一个问题：

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

我有一个网络端点组 (NEG)，由 GKE 中的 Ingress 资源定义和 VPC 原生集群创建。

当我通过暴露 NodePort 或提供 LoadBalancer 类型的服务来规避 CNLB 时，网站可以毫无问题地解决。

describe 中的所有 pod 条件看起来都不错： pod readiness

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

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

当从同一 VPC 中的其他容器或虚拟机访问这些端点时，/health.htm 会以 200 响应。这是来自同一命名空间中的一个容器，尽管我使用 Linux 虚拟机复制了这一点，但不是在集群中，而是在同一个 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 Containers 或 Readiness Probes：https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing#using-pod-readiness-feedback

任何建议将不胜感激。我已经花了两天时间解决这个问题，我确信这很明显，但我看不出问题所在。

【问题讨论】：

是否可以切换到 linux 容器？如果是这样，我们可以为您提供解决方案
您是否允许无处不在的入口/出口？所有防火墙和 Kubernetes 网络策略？还允许在集群上和负载均衡器之间进行往返？
不幸的是，我无法切换到 linux 容器，因为我们正在运行的应用程序是 asp.net 而不是 .net core，我们无法将其移植到 .net core @AbdennourTOUMI跨度>
@Rico 是的，它所在的集群纯粹用于研究在 GKE 中运行我们的 asp.net 站点的可行性，所以我没有配置任何网络策略。我已经允许所有端口上的所有流量从 35.191.0.0/16 和 130.211.0.0/22 到我的 VPC 中的任何实例，这是 Google 负载均衡器根据本页文档发送流量的 IP 范围：cloud.google.com/load-balancing/docs/health-checks 我可以还要确认没有其他防火墙规则会接管优先级并拒绝流量。
一定是某处的防火墙规则。您可以随时咨询 GKE 支持。

标签： kubernetes google-kubernetes-engine windows-container gke-networking

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

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

似乎您的应用在端口 80 上报告了 healthCheck，但在 /health.htm 路径上。

您需要通过 BackendConfig CRD 添加自定义健康检查。看看这个链接 [1]。您可以在同一页面中找到如何将 BackendConfig 关联到 Ingress

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

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

【讨论】：

【解决方案3】：

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

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

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

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

云 TPU (--enable-tpu) 图像流与网络端点组的入口节点内可见性（--enable-intra-node-visibility） IP伪装代理 Kubernetes alpha 集群 (--enable-kubernetes-alpha) 节点本地 DNS 缓存 E类IP地址的私人使用公共 IP 地址的私有使用网络策略日志记录 Kubernetes service.spec.sessionAffinity 点 VM GPU（--加速器）

https://cloud.google.com/kubernetes-engine/docs/concepts/windows-server-gke https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#container-native_load_balancing

【讨论】：