2

問題が発生しています:

Container Native Load Balancing (CNLB) を使用しようとすると、IIS コンテナーで実行されている .Net アプリの正常性チェックが成功する。

VPC ネイティブ クラスタを使用して GKE の Ingress リソース定義によって作成されたネットワーク エンドポイント グループ（NEG）があります。

NodePort を公開するか、タイプ LoadBalancer のサービスを作成して CNLB を回避すると、サイトは問題なく解決されます。

説明からのすべてのポッドの状態は良好に見えます: ポッドの準備

実行時にネットワーク エンドポイントが表示されますdescribe endpoints:準備完了アドレス

これは、ロード バランサによって生成されるヘルス チェックです: GCP ヘルス チェック

同じ VPC 内の他のコンテナーまたは VM からこれらのエンドポイントをヒットすると、/health.htm は 200 で応答します。これは同じ名前空間内のコンテナーからのものですが、クラスター内ではなく同じ Linux VM でこれを再現しました。 VPC:エンドポイントが応答する

しかし、それにもかかわらず、ヘルス チェックは NEG のポッドが異常であると報告しています:異常なエンドポイント

Stackdriver ログは、リクエストがタイムアウトしていることを確認しますが、エンドポイントが他のインスタンスに応答しているが LB には応答していない理由はわかりません: Stackdriver Health Check Log

そして、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

このサイトでは複数のルートを実際に必要としないため、イングレスは非常に基本的なものですが、私たちが抱えている問題がここにあるのではないかと疑っています.

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

どんな提案でも大歓迎です。私はこれに2日間立ち往生しましたが、それは明らかだと確信していますが、問題がわかりません。

4

2 に答える 2

0

Ingress を作成すると、生成された HC プローブはデフォルトで、アプリと同じサービング ポートとパスで HealthCheck を実行します。この場合、パスのポート 80 /

あなたのアプリはポート 80 で healthCheck を報告しているようですが、パスは /health.htm です。

BackendConfig CRD を介してカスタム healthCheck を追加する必要があります。このリンクを見てください [1]。同じページで、BackendConfig を Ingress に関連付ける方法を見つけることができます

使用している GKE のバージョンは何ですか? 使用している Ingress API から判断すると、古いバージョンのようです。

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

于 2021-06-15T08:17:32.243 に答える