web-dev-qa-db-ja.com

Kubernetes Ingress（GCE）が502エラーを返し続ける

GCE KubernetesでIngressをセットアップしようとしています。しかし、イングレスで定義されたIPアドレスとパスの組み合わせにアクセスすると、次の502エラーが引き続き発生します。

Ingress 502 error

実行すると次のようになります：_kubectl describe ing --namespace dpl-staging_

_Name:           dpl-identity
Namespace:      dpl-staging
Address:        35.186.221.153
Default backend:    default-http-backend:80 (10.0.8.5:8080)
TLS:
  dpl-identity terminates
Rules:
  Host  Path    Backends
  ----  ----    --------
  *
        /api/identity/*     dpl-identity:4000 (<none>)
Annotations:
  https-forwarding-rule:    k8s-fws-dpl-staging-dpl-identity--5fc40252fadea594
  https-target-proxy:       k8s-tps-dpl-staging-dpl-identity--5fc40252fadea594
  url-map:          k8s-um-dpl-staging-dpl-identity--5fc40252fadea594
  backends:         {"k8s-be-31962--5fc40252fadea594":"HEALTHY","k8s-be-32396--5fc40252fadea594":"UNHEALTHY"}
Events:
  FirstSeen LastSeen    Count   From                SubObjectPath   Type        Reason  Message
  --------- --------    -----   ----                -------------   --------    ------  -------
  15m       15m     1   {loadbalancer-controller }          Normal      ADD dpl-staging/dpl-identity
  15m       15m     1   {loadbalancer-controller }          Normal      CREATE  ip: 35.186.221.153
  15m       6m      4   {loadbalancer-controller }          Normal      Service no user specified default backend, using system default
_

問題はdpl-identity:4000 (<none>)だと思います。 _dpl-identity_の代わりに_<none>_サービスのIPアドレスを見るべきではありませんか？

これが私のサービスの説明です：_kubectl describe svc --namespace dpl-staging_

_Name:           dpl-identity
Namespace:      dpl-staging
Labels:         app=dpl-identity
Selector:       app=dpl-identity
Type:           NodePort
IP:             10.3.254.194
Port:           http    4000/TCP
NodePort:       http    32396/TCP
Endpoints:      10.0.2.29:8000,10.0.2.30:8000
Session Affinity:   None
No events.
_

また、実行結果は次のとおりです。_kubectl describe ep -n dpl-staging dpl-identity_

_Name:       dpl-identity
Namespace:  dpl-staging
Labels:     app=dpl-identity
Subsets:
  Addresses:        10.0.2.29,10.0.2.30
  NotReadyAddresses:    <none>
  Ports:
    Name    Port    Protocol
    ----    ----    --------
    http    8000    TCP

No events.
_

ここに私のdeployment.yamlがあります：

_apiVersion: v1
kind: Secret
metadata:
  namespace: dpl-staging
  name: dpl-identity
type: Opaque
data:
  tls.key: <base64 key>
  tls.crt: <base64 crt>
---
apiVersion: v1
kind: Service
metadata:
  namespace: dpl-staging
  name: dpl-identity
  labels:
    app: dpl-identity
spec:
  type: NodePort
  ports:
    - port: 4000
      targetPort: 8000
      protocol: TCP
      name: http
  selector:
    app: dpl-identity
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  namespace: dpl-staging
  name: dpl-identity
  labels:
    app: dpl-identity
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: dpl-identity
  rules:
  - http:
      paths:
        - path: /api/identity/*
          backend:
            serviceName: dpl-identity
            servicePort: 4000
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  namespace: dpl-staging
  name: dpl-identity
kind: Ingress
metadata:
  namespace: dpl-staging
  name: dpl-identity
  labels:
    app: dpl-identity
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: dpl-identity
  rules:
  - http:
      paths:
        - path: /api/identity/*
          backend:
            serviceName: dpl-identity
            servicePort: 4000
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  namespace: dpl-staging
  name: dpl-identity
  labels:
    app: dpl-identity
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: dpl-identity
    spec:
      containers:
      - image: gcr.io/munpat-container-engine/dpl/identity:0.4.9
        name: dpl-identity
        ports:
        - containerPort: 8000
          name: http
        volumeMounts:
        - name: dpl-identity
          mountPath: /data
      volumes:
      - name: dpl-identity
        secret:
          secretName: dpl-identity
_
kubernetesgoogle-cloud-platformgoogle-kubernetes-enginegoogle-compute-engine
18
Moon

バックエンドk8s-be-32396--5fc40252fadea594は"UNHEALTHY"。

バックエンドがUNHEALTHYの場合、イングレスはトラフィックを転送しません。これにより、表示されている502エラーが発生します。

ヘルスチェックに合格していないため、UNHEALTHYとしてマークされます。k8s-be-32396--5fc40252fadea594のヘルスチェック設定をチェックして、ポッドに適切かどうかを確認できます。URIまたはポートをポーリングしている可能性があります。 200応答を返していません。これらの設定は、[Compute Engine]> [ヘルスチェック]にあります。

正しい場合は、ブラウザとコンテナの間に多くのステップがあり、トラフィックを誤って渡す可能性があるため、kubectl exec -it PODID -- bash（またはAlpineを使用している場合はash）を実行し、localhostが期待どおりに応答するかどうかを確認するためにlocalhostをカーリングしてみてください。サービスをNodePortタイプからLoadBalancerに変更して、ブラウザからサービスIPに直接アクセスできるかどうかを確認してください。

27
Simon I

私は同じ問題を抱えていました。サービスの正常性を検証するために、イングレスの前に数分待たなければならなかったことがわかりました。誰かが同じことをしてreadinessProbeやlinvenessProbeなどのすべてのステップを実行する場合、イングレスがNodePortであるサービスを指していることを確認し、黄色の警告アイコンが緑色に変わるまで数分かかります。また、StackDriverのログを確認して、何が起こっているのかをよりよく理解してください。私のreadinessProbeとlivenessProbeは/login、gceクラス用。だから、/healthz。

2
Mauricio

同じ問題があり、livenessProbeもreadinessPorbeを有効にした後も持続しました。これは、基本認証に関連するものでした。基本認証をlivenessProbeとreadinessPorbeに追加しましたが、GCE HTTP（S）ロードバランサーにはそのための構成オプションがありません。

他にもいくつかの種類の問題があるようです。コンテナーポートを8080に設定し、サービスポートを80に設定しても、GKEイングレスコントローラーでは機能しませんでした（問題の内容を明確に示すことはできませんでした）。概して、可視性はほとんどないように思えます。可視性に関しては、独自のイングレスコンテナを実行する方が良いオプションです。

私のプロジェクトでは Traefik を選択しました。箱から出してすぐに機能し、Let's Encrypt統合を有効にしたいと思います。 Traefikマニフェストに対して行った唯一の変更は、サービスオブジェクトを調整して、クラスターの外部からUIへのアクセスを無効にし、外部ロードバランサーを介してアプリを公開することでした（GCE TCP LB）また、TraefikはKubernetesのネイティブです.Heptio Contourを試してみましたが、すぐに動作しなかったものがありました（次回新しいバージョンがリリースされたときに試してみます）。

1
errordeveloper

kubernetesドキュメントの "Limitations" セクションには、次のように記載されています。

すべてのKubernetesサービスは、「/」またはGLBCの--health-check-path argumentで指定したカスタム値の200ページを提供する必要があります。

https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/cluster-loadbalancing/glbc#limitations

0
morgane1806

私は問題を解決しました

  1. イングレス定義からサービスを削除する
  2. イングレスを展開kubectl apply -f ingress.yaml
  3. イングレス定義にサービスを追加します
  4. イングレスを再度展開する

基本的に、私はロイのアドバイスに従い、それをオフにしてから再びオンにしようとしました。

0
Halil Kaskavalci

問題は実際にヘルスチェックであり、名前ベースの仮想ホストを使用して、ドメインからのイングレスから2つの別個のバックエンドサービスへのプロキシリクエストをリバースするアプリでは「ランダム」に見えました。両方ともLets Encryptおよびkube-legoを使用して保護されました。私の解決策は、イングレスを共有するすべてのサービスのヘルスチェックのパスを標準化し、deployment.ymlファイルでreadinessProbeおよびlivenessProbe構成を宣言することでした。

Googleクラウドクラスターノードバージョン1.7.8でこの問題に直面し、私が経験したものに非常に似ているこの問題を見つけました：* https://github.com/jetstack/kube-lego/issues/27

gceとkube-legoを使用していますが、バックエンドサービスのヘルスチェックは/にあり、kube-legoは/healthzにあります。 gce ingressを使用したヘルスチェックのパスが異なるため、/healthzパターンに一致するようにバックエンドサービスを更新する価値があるので、すべて同じ（またはGithubのコメントの1人がkubeを更新したと述べています） -legoは/）を渡します。

0
Mike S.