BackendConfig によるバックエンド サービスの構成

このページでは、Kubernetes Ingress オブジェクトを使用して Google Cloud バックエンド サービス(または BackendConfig)の特定のプロパティを構成する方法について説明します。BackendConfig は、Google Cloud 機能の構成情報を保持するカスタム リソースです。

概要

GKE クラスタでは、Kubernetes Ingress オブジェクトを作成すると、GKE ingress コントローラが「起動」し、Google Cloud HTTP(S) ロードバランサが作成されます。 Ingress コントローラはロードバランサを構成し、さらにロードバランサに関連付けられた 1 つ以上のバックエンド サービスも構成します。

バックエンド サービスの構成情報は、BackendConfig という名前のカスタム リソースに保存されます。

バックエンド サービスのプロパティを構成するには:

  1. BackendConfig を作成します。
  2. サービスを作成し、そのポートの 1 つを BackendConfig に関連付けます。
  3. Ingress を作成して、Ingress を(サービス、ポート)ペアに関連付けます。

どのプロパティが構成可能かについては、内部負荷分散と外部負荷分散のどちらで Ingress を使用しているかによります。

外部 HTTP(S) ロードバランサの構成可能なプロパティ

GKE バージョン 1.11.3-gke.18 以降では、Ingress を使用してバックエンド サービスの次のプロパティを構成できます。

GKE バージョン 1.15.3-gke.1 以降では、Ingress を使用してバックエンド サービスの次のプロパティを構成できます。

内部 HTTP(S) ロードバランサの構成可能なプロパティ

BackendConfig を使用して、2 つの追加機能を使用するように内部 HTTP(S) ロードバランサを構成できます。

始める前に

作業を始める前に、次のことを確認してください。

次のいずれかの方法で gcloud のデフォルトの設定を指定します。

  • gcloud init。デフォルトの設定全般を確認する場合に使用します。
  • gcloud config。プロジェクト ID、ゾーン、リージョンを個別に設定する場合に使用します。

gcloud init の使用

  1. gcloud init を実行して、次の操作を行います。

    gcloud init

    リモート サーバーで SSH を使用している場合は、--console-only フラグを指定して、コマンドがブラウザを起動しないようにします。

    gcloud init --console-only
  2. 手順に従って gcloud を承認し、Google Cloud アカウントを使用します。
  3. 新しい構成を作成するか、既存の構成を選択します。
  4. Google Cloud プロジェクトを選択します。
  5. デフォルトの Compute Engine ゾーンを選択します。

gcloud config の使用

  • デフォルトのプロジェクト ID を設定します。
    gcloud config set project project-id
  • ゾーンクラスタを使用する場合は、デフォルトのコンピューティング ゾーンを設定します。
    gcloud config set compute/zone compute-zone
  • リージョン クラスタを使用する場合は、デフォルトのコンピューティング リージョンを設定します。
    gcloud config set compute/region compute-region
  • gcloud を最新バージョンに更新します。
    gcloud components update
  • Kubernetes の Ingress および Service リソースについて確認します。

  • BackendConfig カスタム リソースについて十分に理解します。

Deployment を作成する

BackendConfig とサービスを作成する前に、Deployment を作成する必要があります。Deployment のマニフェストは次のとおりです。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-bsc-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 2
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: gcr.io/google-samples/hello-app:1.0

このマニフェストを my-bsc-deployment.yaml という名前のファイルにコピーし、次のようにして Deployment を作成します。

kubectl apply -f my-bsc-deployment.yaml

BackendConfig の作成

BackendConfig のマニフェストを次に示します。マニフェストの内容は次のとおりです。

  • タイムアウトを 40 秒に設定しています。
  • 接続ドレイン タイムアウトを 60 秒に設定しています。
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-bsc-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60

このマニフェストを my-bsc-backendconfig.yaml という名前のファイルにコピーし、次のようにして BackendConfig を作成します。

kubectl apply -f my-bsc-backendconfig.yaml

サービスの作成

サービスのマニフェストを次に示します。

apiVersion: v1
kind: Service
metadata:
  name: my-bsc-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/backend-config: '{"ports": {"80":"my-bsc-backendconfig"}}'
spec:
  type: NodePort
  selector:
    purpose: bsc-config-demo
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080

この演習では、Service について次の点に注意することが重要です。

  • purpose: bsc-config-demo というラベルを持つすべてのポッドは Service のメンバーです。

  • Service の TCP ポート 80 が my-bsc-backendconfig という名前の BackendConfig に関連付けられています。これは、cloud.google.com/backend-config アノテーションで指定されています。

  • サービスのポート 80 に送信されたリクエストは、いずれかのメンバーポッド(ポート 8080)に転送されます。

マニフェストを my-bsc-service.yaml という名前のファイルに保存し、Service を作成します。

kubectl apply -f my-bsc-service.yaml

Ingress の作成

Ingress のマニフェストを次に示します。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-bsc-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: my-bsc-service
          servicePort: 80

マニフェストでは、my-bsc-service という名前の Service のポート 80 に受信リクエストがルーティングされることがわかります。

このマニフェストを my-bsc-ingress.yaml という名前のファイルにコピーし、次のようにして Ingress を作成します。

kubectl apply -f my-bsc-ingress.yaml

Ingress コントローラが HTTP(S) ロードバランサおよび関連するバックエンド サービスを構成するまで数分待ちます。

バックエンド サービスの表示

バックエンド サービスを表示するには、get service コマンドを使用するか、Ingress YAML ファイルを表示します。

get service コマンドを使用してバックエンド サービスを表示するには、次の手順を行います。

  1. 次のコマンドを実行します。

    kubectl get service my-bsc-service
    
  2. 出力に表示されたノードポートの値をメモしておきます。たとえば、次の出力では、ノードポートの値は 30936 です。

    NAME             TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
    my-bsc-service   NodePort   10.83.15.111   none          80:30936/TCP   2m
    
  3. Cloud プロジェクト内のバックエンド サービスを一覧表示します。

    gcloud compute backend-services list
    
  4. 出力で、バックエンド サービスの名前を探します。これは、サービスのノードポートを含む名前です。たとえば、ノードポートが 30936 の場合、バックエンド サービスの名前は次のようになります。

    NAME
    ...
    k8s-be-30936--078bc860bb6f7a2f
    ...
    
  5. バックエンド サービスの説明を設定します。

    gcloud compute backend-services describe backend-service-name --global
    

    backend-service-name はバックエンド サービスの名前です。

    構成したプロパティの値が出力に表示されます。

    connectionDraining: drainingTimeoutSec: 60 ... timeoutSec: 40
    

Ingress YAML ファイルからバックエンド サービスを見つけることもできます。ロードバランサを設定すると、Ingress コントローラは名前空間、サービス名、サービスポートを持つアノテーションを追加します。

Ingress YAML ファイルを使用してバックエンド サービスを表示するには、次の手順を行います。

  1. Ingress YAML ファイルを開きます。
  2. ingress.kubernetes.io/backends セクションを表示します。例:

     ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-bsc-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}
    

    ここで

    • "k8s1-27fde173-default-my-bsc-service-80-8d4ca500":"HEALTHY" は、my-bsc-service Kubernetes Service に関連したバックエンド サービスに関する情報を示しています。
      • k8s1-27fde173 は、クラスタの説明に使用されるハッシュです。
      • default は Kubernetes 名前空間です。
      • HEALTHY は、バックエンドが正常であることを示します。
    • "k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY" は、デフォルトのバックエンド(404 サーバー)に関連したバックエンド サービスに関する情報を示しています。
      • k8s1-27fde173 は、クラスタの説明に使用されるハッシュです。
      • kube-system は名前空間です。
      • default-http-backend Kubernetes Service の名前です。
      • 80 はホストのポートです。
      • HEALTHY は、バックエンドが正常であることを示します。

クライアント IP アフィニティの設定

BackendConfig を使用して、クライアント IP アフィニティを構成できます。

この演習を行うには、VPC ネイティブのクラスタが必要です。クライアント IP アフィニティは、ネットワーク エンドポイント グループをベースとする Service にのみ役立ち、ネットワーク エンドポイント グループには VPC ネイティブ クラスタが必要です。

クライアント IP アフィニティを設定するには、BackendConfig マニフェスト内の affinityType"CLIENT_IP" に設定します。

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-bsc-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60
  sessionAffinity:
    affinityType: "CLIENT_IP"

Service マニフェストに、次のような cloud.google.com/neg: '{"ingress": true}' アノテーションを含めます。

kind: Service
metadata:
  name: my-bsc-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
    cloud.google.com/backend-config: '{"ports": {"80":"my-bsc-backendconfig"}}'
...

HTTP アクセス ロギングの構成

Ingress は、クライアントからのすべての HTTP リクエストを Cloud Logging に記録できます。アクセス ロギングは、BackendConfig と、アクセス ロギングのサンプリング レートを使用して、有効または無効に設定できます。

アクセス ロギングを構成するには、BackendConfig の logging フィールドを使用します。ご使用の GKE のバージョンで、ロギングがデフォルトで「オン」に設定される場合、ロギングを有効にするために logging フィールドは必要ありません。アクセス ロギングは、GKE 1.18 より前のすべてのバージョンではデフォルトで「オン」に設定されていますが、1.16.8-gke.10 以降では構成可能なフィールドとして公開されています。バージョンごとのサポートの仕様については、logging リファレンスをご覧ください。

次の BackendConfig は、アクセス ロギングを有効にし、特定の Ingress リソースに対する HTTP リクエストのサンプルレートを 50% に設定します。sampleRate はオプションのフィールドですが、これが構成されている場合、enable: true を設定する必要があります。設定しなければ、enable: false と解釈されます。

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

BackendConfig を使用して、生成された Cookie アフィニティを構成できます。

この演習を行うには、VPC ネイティブのクラスタが必要です。生成された Cookie アフィニティは、ネットワーク エンドポイント グループをベースとする Service にのみ役立ち、ネットワーク エンドポイント グループには VPC ネイティブ クラスタが必要です。

生成された Cookie アフィニティを設定するには、BackendConfig マニフェスト内の affinityType"GENERATED_COOKIE" に設定します。また、affinityCookieTtlSec を使用して Cookie の期間を設定することもできます。

sessionAffinity:
  affinityType: "GENERATED_COOKIE"
  affinityCookieTtlSec: 50

Service マニフェストに、次のような cloud.google.com/neg: '{"ingress": true}' アノテーションを含めます。

kind: Service
metadata:
  name: my-bsc-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
    cloud.google.com/backend-config: '{"ports": {"80":"my-bsc-backendconfig"}}'
...

ユーザー定義のリクエスト ヘッダーの設定

外部負荷分散に Ingress を使用している場合は、BackendConfig を使用して、ユーザー定義リクエスト ヘッダーを構成できます。

ユーザー定義のリクエスト ヘッダーを有効にするには、BackendConfig リソースの customRequestHeaders プロパティにヘッダーのリストを指定します。ロードバランサは、バックエンドに転送するリクエストにヘッダーを追加します。

customRequestHeaders:
  headers:
  - "X-Client-Region:{client_region}"
  - "X-Client-City:{client_city}"
  - "X-Client-CityLatLong:{client_city_lat_long}"

Service マニフェストに、次のような cloud.google.com/neg: '{"ingress": true}' アノテーションを含めます。

kind: Service
metadata:
  name: my-bsc-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
    cloud.google.com/backend-config: '{"ports": {"80":"my-bsc-backendconfig"}}'
...

クリーンアップ

このページの演習を完了したら、アカウントで不要な請求が発生しないように、以下の手順でリソースを削除します。

この演習で作成した Kubernetes オブジェクトを削除します。

kubectl delete ingress my-bsc-ingress
kubectl delete service my-bsc-service
kubectl delete backendconfig my-bsc-backendconfig
kubectl delete deployment my-bsc-deployment

次のステップ