web-dev-qa-db-ja.com

GCEヘルスチェックの設定がデフォルトに戻ります

Kubernetes EngineのIngressを使用してGCPにロードバランサーを設定しました。

デフォルトでは、バックエンドサービスはすべてのインスタンスを異常として登録しました。ヘルスチェックをHTTPSプロトコルと/ healthz urlに更新しました。これは、ヘルスチェックのURLだからです。

数分間そのままにしておくと、バックエンドサービスはすべてのインスタンスが正常に動作していることを示し、ポッドが/ healthzで200応答を提供していることをログで確認します。

ページに移動すると、502エラーが表示されます。コンソールのヘルスチェックページに戻ると、ヘルスチェックが/でHTTPに戻りました。

ヘルスチェックがHTTPに戻った原因は何ですか？これは、10分間、ヘルスチェックが設定したhttpsをリクエストし続け、その後リクエストがhttpに戻ることを示すログです。

...
[W 180621 20:02:35 iostream:1451] SSL Error on 9 ('10.128.0.14', 48346): [SSL: HTTP_REQUEST] http request (_ssl.c:833)
[W 180621 20:02:35 iostream:1451] SSL Error on 9 ('10.128.0.13', 63030): [SSL: HTTP_REQUEST] http request (_ssl.c:833)
[I 180621 20:02:43 web:2106] 200 GET /healthz (10.128.0.14) 0.75ms
[I 180621 20:02:43 web:2106] 200 GET /healthz (10.128.0.13) 0.80ms
[I 180621 20:02:43 web:2106] 200 GET /healthz (10.128.0.14) 0.74ms
...
[I 180621 20:05:46 web:2106] 200 GET /healthz (10.128.0.13) 1.26ms
[I 180621 20:05:46 web:2106] 200 GET /healthz (10.128.0.14) 0.63ms
[I 180621 20:05:46 web:2106] 200 GET /healthz (10.128.0.15) 0.64ms
[W 180621 20:05:46 iostream:1451] SSL Error on 9 ('10.128.0.14', 49971): [SSL: HTTP_REQUEST] http request (_ssl.c:833)
[W 180621 20:05:46 iostream:1451] SSL Error on 9 ('10.128.0.15', 62893): [SSL: HTTP_REQUEST] http request (_ssl.c:833)
[W 180621 20:05:48 iostream:1451] SSL Error on 9 ('10.128.0.13', 52191): [SSL: HTTP_REQUEST] http request (_ssl.c:833)
[W 180621 20:05:48 iostream:1451] SSL Error on 9 ('10.128.0.13', 60549): [SSL: HTTP_REQUEST] http request (_ssl.c:833)

編集：私は問題のポッドの準備プローブを追加しています。これは、イングレスが接続されています。

readinessProbe:
  httpGet:
    port: 8902
    scheme: HTTPS
    path: /healthz
  initialDelaySeconds: 5
  periodSeconds: 10
  successThreshold: 1
google-cloud-platformgoogle-compute-enginegoogle-kubernetes-engine
3
lamorach

私がチェックしたところ、意図した動作を示しています。

Kubernetesはヘルスチェックを制御し、kubernetesクラスター内のデータからヘルスチェックを構成します。 Kubernetesは、gcloudを介してヘルスチェックに加えられた変更を認識しません。

したがって、それがチェックされ、変更が元に戻されるのは正常だと思います。

代わりに readinessProbe を使用するソリューション。

this もご覧ください。

ヘルスチェック

現在、すべてのサービスバックエンドは、GCEロードバランサーから送信されたHTTP（S）ヘルスチェックに合格するために、次の要件のいずれかを満たす必要があります。

  1. '/'に200を付けて応答します。内容は関係ありません。

  2. サービスをバッキングするポッドの準備プローブとして任意のURLを公開します。

Ingressコントローラーは、最初に互換性のある準備プローブを探します。見つかった場合は、それをGCEロードバランサーのHTTP（S）ヘルスチェックとして採用します。準備プローブがない場合、または準備プローブに特別なHTTPヘッダーが必要な場合、IngressコントローラーはGCEロードバランサーのHTTPヘルスチェックを「/」にポイントします。

2
GalloCedrone

同じ問題がありました。

問題は、readinessProbeがHTTPSのみに設定されていることでした

readinessProbe:
  httpGet:
    path: "/health?ready=1"
    port: 8080
    scheme: HTTPS

ただし、GCEバックエンドはサービスがHTTPに応答すると自動的に想定し、デフォルトでそこでヘルスチェックをスキャンします。

GKE Ingressの詳細とヒースチェックの応答 [〜＃〜]こちら[〜＃〜]

これを修正するには、HTTPSのみで応答するようにサービスを更新する必要がありました

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/app-protocols: '{"my-port-name":"HTTPS"}'
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: my-port-name

これにより、HTTPS経由でreadinessProbesをスキャンするためにイングレスが作成するバックエンドサービスが生成されます。

注：これを行う前にIngress、LoadBalancer、HealthCheckを破棄し、サービスに適用された更新に応答しないため、後で再作成してください。

1
wintheday

バックエンドはHTTPSプロトコルでのみ機能しているようですが、HTTPプロトコル用のIngressリソースをデプロイしました。マスターがマニフェストに準拠するように変更を元に戻すため、展開後に手動で構成を変更することは解決策ではありません。 このドキュメントごとに TLS秘密キーと証明書を含むシークレットを指定することにより、Ingressを保護できます。現在、Ingressは単一のTLSポート443のみをサポートしており、TLSの終了を前提としています。

0
3ec