Ingress を使用して外部アプリケーション ロードバランサを設定する

ウェブ アプリケーションをデプロイする

次のマニフェストでは、ポート 8080 で HTTP サーバー上でサンプル ウェブ アプリケーション コンテナ イメージを実行する Deployment を記述しています。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: default
spec:
  selector:
    matchLabels:
      run: web
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        imagePullPolicy: IfNotPresent
        name: web
        ports:
        - containerPort: 8080
          protocol: TCP

リソースをクラスタに適用します。

kubectl apply -f web-deployment.yaml

クラスタ内での Deployment の公開

次のマニフェストでは、web Deployment をコンテナ クラスタ内でアクセス可能にする Service が記述されています。

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: default
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    run: web
  type: NodePort

1. リソースをクラスタに適用します。

   kubectl apply -f web-service.yaml
   

   このコマンドで NodePort タイプの Service を作成すると、クラスタ内のすべてのノードで、ランダムに選択された上位ポート番号（32640 など）を使用して Service を利用できるようになります。

2. Service が作成され、ノードポートが割り当てられたことを確認します。

   kubectl get service web
   

   出力:

   NAME      TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
   web       NodePort   10.35.245.219   <none>        8080:32640/TCP   5m
   

   このサンプル出力では、web Service のノードポートは 32640 です。また、この Service には外部 IP アドレスが割り振られていないことに注意してください。デフォルトで GKE ノードに外部からアクセスすることはできないため、この Service を作成しても、インターネットからアプリケーションにアクセスできるようにはなりません。

HTTP(S) ウェブサーバー アプリケーションを公開するには、Ingress リソースを作成する必要があります。

Ingress リソースの作成

Ingress は、外部 HTTP(S) トラフィックを内部サービスにルーティングするためのルールと構成の集合をカプセル化する Kubernetes リソースです。

GKE では、Ingress は Cloud Load Balancing を使用して実装されます。クラスタで Ingress を作成すると、GKE により HTTP(S) ロードバランサが作成され、トラフィックをアプリケーションにルーティングするように構成されます。

次のマニフェストでは、トラフィックを web Service に転送する Ingress リソースが記述されています。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: basic-ingress
spec:
  defaultBackend:
    service:
      name: web
      port:
        number: 8080

リソースをクラスタに適用します。

kubectl apply -f basic-ingress.yaml

このマニフェストをデプロイすると、Kubernetes によってクラスタに Ingress リソースが作成されます。GKE Ingress コントローラでは、Ingress の情報に従って HTTP(S) ロードバランサを作成して構成し、すべての外部 HTTP トラフィック（ポート 80）を、公開した web NodePort Service にルーティングします。

アプリケーションへのアクセス

次のコマンドを実行して、アプリケーションに対応するロードバランサの外部 IP アドレスを調べます。

kubectl get ingress basic-ingress

NAME            HOSTS     ADDRESS         PORTS     AGE
basic-ingress   *         203.0.113.12    80        2m

ブラウザでアプリケーションの外部 IP アドレスを開くと、次のような書式なしテキストの HTTP レスポンスが表示されます。

Hello, world!
Version: 1.0.0
Hostname: web-6498765b79-fq5q5

Google Cloud コンソールの [負荷分散] にアクセスすると、GKE Ingress コントローラによって作成されたネットワーキング リソースを調べることができます。

（省略可）静的 IP アドレスの構成

ドメイン名でウェブサーバーを公開する場合、アプリケーションの外部 IP アドレスを変化しない静的 IP アドレスにする必要があります。

デフォルトで、Ingress によって公開される HTTP アプリケーションに GKE が割り振るのはエフェメラル外部 IP アドレスです。エフェメラル アドレスは変化する可能性があります。長期間使用する予定のウェブ アプリケーションでは、静的外部 IP アドレスを使用する必要があります。

Ingress リソースに静的 IP を構成した場合、Ingress を削除しても、それに関連付けられている静的 IP アドレスは削除されないことに注意してください。構成した静的 IP アドレスを再び使用する予定がない場合は、クリーンアップが必要になります。

静的 IP アドレスを構成するには、次の手順を行います。

1. web-static-ip という静的外部 IP アドレスを予約します。

   gcloud

   gcloud compute addresses create web-static-ip --global
   

   Config Connector

   注: この手順には Config Connector が必要です。Config Connector をクラスタにインストールするには、インストール手順を実施してください。

   apiVersion: compute.cnrm.cloud.google.com/v1beta1
   kind: ComputeAddress
   metadata:
     name: web-static-ip
   spec:
     location: global

   このマニフェストをデプロイするには、マニフェストを compute-address.yaml というファイル名でマシンにダウンロードしてから、次のコマンドを実行します。

   kubectl apply -f compute-address.yaml

2. basic-ingress-static.yaml マニフェストは、web-static-ip という名前の静的 IP リソースを使用するためのアノテーションを Ingress に追加します。

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: basic-ingress
     annotations:
       kubernetes.io/ingress.global-static-ip-name: "web-static-ip"
   spec:
     defaultBackend:
       service:
         name: web
         port:
           number: 8080

   マニフェストを確認します。

   cat basic-ingress-static.yaml
   

3. リソースをクラスタに適用します。

   kubectl apply -f basic-ingress-static.yaml
   

4. 外部 IP アドレスを確認します。

   kubectl get ingress basic-ingress
   

   web-static-ip リソースの予約済み IP アドレスを使用するようにアプリケーションの IP アドレスが変更されるまで待ちます。

   既存の Ingress リソースの更新、ロードバランサの再構成、および負荷分散ルールが世界中に伝播されるまで、数分かかることがあります。このオペレーションが完了すると、以前にアプリケーションに割り振られていたエフェメラル IP アドレスが解放されます。

（省略可）1 つのロードバランサで複数のアプリケーションに対応する

Ingress でルーティング ルールを構成することにより、単一のロードバランサとパブリック IP アドレスで複数のサービスを実行できます。同じ Ingress で複数のサービスをホストすると、インターネットに公開する Service ごとに追加のロードバランサ（課金対象のリソース）を作成しなくて済みます。

次のマニフェストでは、同じウェブ アプリケーションのバージョン 2.0 を使用した Deployment が記述されています。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web2
  namespace: default
spec:
  selector:
    matchLabels:
      run: web2
  template:
    metadata:
      labels:
        run: web2
    spec:
      containers:
      - image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
        imagePullPolicy: IfNotPresent
        name: web2
        ports:
        - containerPort: 8080
          protocol: TCP

リソースをクラスタに適用します。

kubectl apply -f web-deployment-v2.yaml

次のマニフェストでは、web2 と呼ばれる NodePort Service 上のクラスタに web2 を内部公開する Service が記述されています。

apiVersion: v1
kind: Service
metadata:
  name: web2
  namespace: default
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    run: web2
  type: NodePort

リソースをクラスタに適用します。

kubectl apply -f web-service-v2.yaml

以下に示すマニフェストは、次のような Ingress リソースを記述しています。

• /v2/ でパスが始まるリクエストを web2 Service にルーティングする。
• 他のすべてのリクエストを web Service にルーティングする。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: fanout-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: web
            port:
              number: 8080
      - path: /v2/*
        pathType: ImplementationSpecific
        backend:
          service:
            name: web2
            port:
              number: 8080

リソースをクラスタに適用します。

kubectl create -f fanout-ingress.yaml

Ingress をデプロイした後、kubectl get ingress fanout-ingress を実行してクラスタのパブリック IP アドレスを調べます。

次に、IP アドレスを参照して、両方のアプリケーションが同じロードバランサ上で到達可能であることを確認します。

• http://<IP_ADDRESS>/ に移動し、レスポンスに Version: 1.0.0 が含まれていることを確認します（リクエストは web Service にルーティングされる）。
• http://<IP_ADDRESS>/v2/ に移動し、レスポンスに Version: 2.0.0 が含まれていることを確認します（リクエストは web2 Service にルーティングされる）。

Ingress の path フィールドでサポートされているワイルドカード文字は「*」のみです。「*」はスラッシュ（「/」）の直後に置かれる必要があり、パターンの最後の文字でなければなりません。たとえば、/*、/foo/*、/foo/bar/* は有効なパターンですが、*、/foo/bar*、/foo/*/bar は有効ではありません。

より具体的なパターンのほうが、そうでないものよりも優先されます。/foo/* と /foo/bar/* の両方を使用すると、/foo/bar/bat が /foo/bar/* と比較されます。

パスの制限とパターン マッチングの詳細については、URL マップのドキュメントをご覧ください。

（省略可）サービスの可用性とレイテンシをモニタリングする

Google Cloud の稼働時間チェックでは、ユーザーの視点からアプリケーションのブラックボックス モニタリングを実行し、複数の外部 IP からロードバランサの IP アドレスへのレイテンシと可用性を決定します。これに対して、Google Cloud のヘルスチェックは Pod IP に対して内部チェックを実行し、インスタンス レベルでの可用性を決定します。この 2 つは補完的な関係にあり、アプリケーションの健全性を総合的に把握できます。

稼働時間チェックを作成するには、Google Cloud コンソール、Cloud Monitoring API を使用するか、Cloud Monitoring クライアント ライブラリを使用します。詳しくは、稼働時間チェックの管理をご覧ください。Google Cloud コンソールを使用して稼働時間チェックを作成する手順は次のとおりです。

1. Google Cloud コンソールの [Service と Ingress] ページに移動します。

   [Service と Ingress] に移動

2. 稼働時間チェックを作成する Service の名前をクリックします。

3. [稼働時間チェックの作成] をクリックします。

4. [稼働時間チェックの作成] ペインで、稼働時間チェックのタイトルを入力し、[次へ] をクリックして [ターゲット] 設定に進みます。

   稼働時間チェックの [ターゲット] フィールドには Service ロードバランサの情報を使用して自動的に入力されます。

   稼働時間チェックのすべてのフィールドの詳細については、稼働時間チェックの作成をご覧ください。

5. [次へ] をクリックして [レスポンスの検証] 設定に進みます。

6. [次へ] をクリックして [アラートと通知] セクションに進みます。

   稼働時間チェックをモニタリングするには、アラート ポリシーを作成するか、稼働時間チェック ダッシュボードを表示します。稼働時間チェックに失敗した場合は、アラート ポリシーによってメールまたは別のチャネルで通知されます。アラート ポリシーの概要については、アラートの概要をご覧ください。

7. [作成] をクリックします。

備考

デフォルトでは、Ingress は GET リクエストを / パスで実行してアプリケーションの状態を判断することで定期的なヘルスチェックを実行し、HTTP 200 レスポンスを待ちます。別のパスをチェックしたい場合、または別のレスポンス コードを待つ場合は、カスタム ヘルスチェック パスを使用できます。

Ingress は、次のような高度なユースケースをサポートしています。

• 名前ベースの仮想ホスティング: Ingress を使用して、複数のドメイン名およびサブドメインに対してロードバランサを再利用し、複数の Service を 1 つの IP アドレスとロードバランサで公開できます。これらのタスク用に Ingress を構成する方法については、簡単なファンアウトと名前ベースの仮想ホスティングの例をご覧ください。

• HTTPS 終端: Cloud Load Balancer を使用して HTTPS トラフィックを終端させるように Ingress を構成できます。

Ingress を削除すると、関連付けられているリソース（予約された静的 IP アドレスを除く）は GKE Ingress コントローラによって自動的にクリーンアップされます。