web-dev-qa-db-ja.com

Kubernetes Ingressを処理するGCE L7バランサーでカスタムヘルスチェックパスを取得する方法

GCEでKubernetes（サーバー1.6.4）内にgrafanaインスタンスをデプロイしようとしています。次のマニフェストを使用しています。

導入（ フルバージョン ）：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: grafana
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: grafana
    spec:
      initContainers:
        …                                
      containers:
        - name: grafana
          image: grafana/grafana
          readinessProbe:
            httpGet:
              path: /login
              port: 3000
          …

サービス：

apiVersion: v1
kind: Service
metadata:
  name: grafana
spec:
  selector:
    name: grafana
  ports:
    - protocol: TCP
      port: 3000
  type: NodePort

イングレス：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: grafana
spec:
  tls:
    - secretName: grafana.example.com
  backend:
    serviceName: grafana
    servicePort: 3000

Grafanaは/で302を提供しますが、デフォルトのGCE入力ヘルスチェックは/（ source ）で200を期待することがわかりました。ご覧のとおり、 Deployment （22行目）にカスタムreadinessProbeがあります。

これらのリソースをkube-apiserverに投稿すると、すべてがエラーなしで作成されます。具体的には、IngressはパブリックIP4アドレスを取得しますが、ヘルスチェックはカスタムアドレスではなくデフォルトの/パスで設定されますreadinessProbeで構成されます。このため、IngressのパブリックIP4アドレスをcurlした場合、502が返されます。

この問題は、GCEコンソールでプローブパスを/loginに手動で変更することで修正できます。

kubernetesgoogle-compute-enginekubernetes-health-check
15
mmoya

ここ からの引用：

GLBCでは、ポッド仕様内でポート（ケースでは3000）を定義する必要があります。

解決策は、カスタムportsを追加するほかに、ヘルスチェックに使用するポートをreadinessProbeで宣言することです。

containers:
  - name: grafana
    readinessProbe:
      httpGet:
        path: /login
        port: 3000
    ports:
      - name: grafana
        containerPort: 3000
    …
10
mmoya

ヘルスチェックのカスタマイズ

GLBCアドオンを使用

それはあなたの質問からははっきりしていませんが、 GCE Load-Balancer Controller (GLBC) Cluster Addon を使用している場合は、 ヘルスチェックパスをカスタマイズする を使用できます。

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

  • 200で'/'を返信します。内容は関係ありません。
  • サービスをサポートするポッドの準備プローブとして任意のURLを公開します。

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

GLBCアドオンページでは、制限セクションでこれについて言及しています。

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

GLBCアドオンなし

アドオンを使用していない場合、現在Kubernetesでは正常なヘルスチェックのために200パスで/ _GETリクエストを処理する必要があります。そうしないと、バックエンドでトラフィックが取得されません。

これには バグ の背景が少しあります。

Google Container Engine（GKE）

Google Container Engine（GKE）を使用している場合、ヘルスチェックのデフォルトの同じKubernetes要件 そこにも適用 。

Ingressを通じて公開されるサービスは、HTTP 200パス上のGETリクエストに対して/ステータスのレスポンスを提供する必要があります。これはヘルスチェックに使用されます。アプリケーションがHTTP 200で/を提供しない場合、バックエンドは異常とマークされ、トラフィックを取得できません。

あなたの本当の問題への答え

これをすべて述べた後、あなた（@mmoya）が回答で指摘したように、ポッドのポートの1つとして準備プローブに使用されるものと同じポートを追加すると、ポート自体が外部に公開されないため、問題が修正されますそれ以外の場合はポッド。これにより、Kubernetesは/からのヘルスチェックに依存するようになりました。

6
Tuxdude