ALB ルーティングのカスタマイズ

Kubernetes Ingress イメージを実行する ALB のデフォルト設定を変更します。

場合によっては、 Kubernetes NGINX アノテーション (nginx.ingress.kubernetes.io/<annotation>) を追加して、Ingress のルーティングをカスタマイズできます。 Kubernetes NGINX アノテーションは、常にリソース内のすべてのサービス・パスに適用され、アノテーション内でサービス名を指定することはできません。カスタム IBM Cloud Kubernetes Service アノテーション(ingress.bluemix.net/<annotation>)はサポートされていません。

Kubernetes 2022年1月31日以降に作成されたクラスタ上のIngressコントローラ（ALB）は、デフォルトでスニペットアノテーション（例えば、）を持つIngressリソースを処理しません。これは、すべての新しいクラスタがALBのにのコンフィギュレーションでデプロイされるためです。 nginx.ingress.kubernetes.io/configuration-snippet ConfigMap allow-snippet-annotations: "false" ここで推奨される構成スニペットを追加する場合は、ALB の ConfigMap (kube-system/ibm-k8s-controller-config) を編集し、 allow-snippet-annotations: "false" を allow-snippet-annotations: "true" に変更する必要があります。

ホスト・ヘッダーへのサーバー・ポートの追加

要求がバックエンド・アプリに転送される前にサーバー・ポートをクライアント要求に追加するには、サーバー・スニペットのアノテーションで、または ibm-k8s-controller-config ConfigMap フィールドとして、プロキシーを外部サービスに構成します。

プライベート ALB を使用した着信要求のルーティング

プライベート ALB を使用して着信要求をアプリにルーティングするには、 Ingress リソースで private-iks-k8s-nginx クラス・アノテーションを指定します。プライベート ALB は、このクラスのリソースを使用するように構成されます。

kubernetes.io/ingress.class: "private-iks-k8s-nginx"

App ID を使用したアプリケーションの認証

特定の Kubernetes Ingress フィールドを変更してアプリの認証を強制するように、 IBM Cloud App ID を使用して Ingress を構成します。詳しくは、アプリへの App ID 認証の追加を参照してください。

クライアント要求本体の最大サイズの設定

クライアントが要求の一部として送信できる本文の最大サイズを設定するには、以下の Kubernetes Ingress リソース・アノテーションを使用します。

nginx.ingress.kubernetes.io/proxy-body-size: 8m

クライアント応答データ・バッファリングの有効化および無効化

データがクライアントに送信される間、応答データのALBへの保存を無効または有効にすることができる。この設定はデフォルトで無効になります。有効にするには、以下の Ingress リソース・アノテーションを設定します。

nginx.ingress.kubernetes.io/proxy-buffering: "on"

接続と読み込みのタイムアウトのカスタマイズ

バックエンド・アプリが使用不可と見なされるまでに、ALB がバックエンド・アプリへの接続とバックエンド・アプリからの読み取りを待機する時間を設定するには、以下のアノテーションを使用します。

nginx.ingress.kubernetes.io/proxy-connect-timeout: 62

nginx.ingress.kubernetes.io/proxy-read-timeout: 62

エラー・アクションのカスタマイズ

ALBが特定の HTTP エラーに対して実行できるカスタムアクションを指定するには、 custom-http-errors フィールドを設定します。

デフォルトの HTTP と HTTPS ポートを変更する

HTTP （ポート80）および HTTPS （ポート443）のネットワークトラフィックのデフォルトポートを変更するには、以下の Kubernetes Ingress ibm-ingress-deploy-config ConfigMap フィールドを使用して、各ALBサービスを変更します。

フィールド設定の例。

httpPort=8080
httpsPort=8443

要求ヘッダーのカスタマイズ

要求をバックエンド・アプリに転送する前にヘッダー情報をクライアント要求に追加するには、以下の Kubernetes ibm-k8s-controller-config configmap フィールドを使用します。

proxy-set-headers: "ingress-nginx/custom-headers"

custom-headers ConfigMap の要件については、この例を参照のこと。

応答ヘッダーのカスタマイズ

クライアント応答をクライアントに送信する前にヘッダー情報をクライアント応答に追加するには、以下のアノテーションを使用します。

nginx.ingress.kubernetes.io/configuration-snippet: |
    more_set_headers "Request-Id: $req_id";

外部サービスへのパス定義の追加

IBM Cloudでホストされるサービスなどの外部サービスへのパス定義を追加するには、ロケーション・スニペットで外部サービスへのプロキシーを構成します。または、プロキシーを外部サービスへの永続リダイレクトに置き換えます。

非セキュア要求のリダイレクト

デフォルトでは、安全でない HTTP クライアントのリクエストは HTTPS にリダイレクトされます。この設定を無効にするには、以下のフィールドとアノテーションを使用します。

ibm-k8s-controller-config ConfigMap フィールド
```
ssl-redirect: "false"
```

Ingress リソース・アノテーション:

nginx.ingress.kubernetes.io/ssl-redirect: "false"

有効化と無効化 HTTP Strict Transport Security

ドメインへのアクセスに HTTPS のみ使用するようにブラウザーを設定します。デフォルトでは、このオプションは有効です。

最大年齢とサブドメインの粒度を追加するには、このNGINXブログを参照してください。
無効にするには、 ibm-k8s-controller-config configmap フィールドを設定する。
```
hsts: false
```

キープアライブ要求の最大数の設定

1 つのキープアライブ接続を介して処理できる要求の最大数を設定するには、以下の Kubernetes ibm-k8s-controller-config configmap フィールドを使用します。

keep-alive-requests: 100

Kubernetes Ingressの keep-alive-requests のデフォルト値は 100、 IBM Cloud Kubernetes Service Ingressの 4096 のデフォルト値よりはるかに小さい。 Ingress のセットアップを IBM Cloud Kubernetes Service Ingress から Kubernetes Ingress にマイグレーションした場合は、既存のパフォーマンス・テストに合格するために keep-alive-requests を変更しなければならない場合があります。

キープアライブ要求の最大タイムアウトの設定

クライアントと ALB プロキシー・サーバーの間でキープアライブ接続を開いたままにする最大時間を設定するには、以下の Kubernetes ibm-k8s-controller-config configmap フィールドを使用します。

keep-alive: 60

ラージ・クライアント・ヘッダー・バッファーの最大数の設定

ラージ・クライアント要求ヘッダーを読み取るバッファーの最大数とサイズを設定するには、以下の Kubernetes ibm-k8s-controller-config configmap フィールドを使用します。

large-client-header-buffers: 4 8k

ALB が要求 URI と一致する方法の変更

ALB がアプリ・パスに対して要求 URI を突き合わせる方法を変更するには、以下の Kubernetes Ingress リソース・アノテーションを使用します。

nginx.ingress.kubernetes.io/use-regex: "true"

詳しくは、このブログを参照してください。

カスタム・ロケーション・ブロック構成の追加

サービスのカスタム・ロケーション・ブロック構成を追加するには、以下の Kubernetes Ingress リソース・アノテーションを使用します。

nginx.ingress.kubernetes.io/configuration-snippet: |
    more_set_headers "Request-Id: $req_id";

相互認証の構成

ALB の相互認証を構成するには、以下の Kubernetes Ingress リソース・アノテーションを使用します。相互認証はカスタム・ポートに適用できず、HTTPS ポートに適用する必要があることに注意してください。

nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
nginx.ingress.kubernetes.io/auth-tls-error-page: "http://www.mysite.com/error-cert.html"
nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"

プロキシー・バッファー・サイズの構成

応答の最初の部分を読み取るプロキシー・バッファーのサイズを構成するには、以下の Kubernetes Ingress リソース・アノテーションを使用します。

nginx.ingress.kubernetes.io/proxy-buffer-size: "8k"

プロキシー・バッファー番号の構成

ALB のプロキシー・バッファーの数を構成するには、以下の Kubernetes Ingress リソース・アノテーションを使用します。

nginx.ingress.kubernetes.io/proxy-buffers-number: "4"

ビジー・プロキシー・バッファー・サイズの構成

使用中にできるプロキシー・バッファーのサイズを構成するには、ロケーション・スニペットを使用します。詳細については、 NGINX のドキュメントを参照してください。

ALB が要求を渡すことができる場合の構成

ALB が要求を次のアップストリーム・サーバーに渡すことができるタイミングを設定するには、以下の Kubernetes Ingress フィールドを使用します。

グローバル設定: ibm-k8s-controller-config ConfigMap フィールド:

retry-non-idempotent: true
proxy-next-upstream: error timeout http_500

リソースごとの設定: Ingress リソース・アノテーション:

nginx.ingress.kubernetes.io/proxy-next-upstream: http_500
nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: 50
nginx.ingress.kubernetes.io/proxy-next-upstream-tries: 3

速度制限

サービスの定義済みキーごとの要求処理速度と接続数を制限するには、Ingress リソース・速度制限のアノテーションを使用します。

応答ヘッダーの削除

レスポンスがクライアントに送信される前に、バックエンドのエンドアプリからクライアントのレスポンスに含まれるヘッダー情報を削除することができます。ロケーション・スニペットで応答ヘッダーの削除を構成するか、 ibm-k8s-controller-config ConfigMapで proxy_hide_header フィールドを構成スニペットとして使用します。

パスの再書き込み

ALB ドメイン・パス上の着信ネットワーク・トラフィックを、バックエンド・アプリが listen する別のパスにルーティングするには、以下の Kubernetes Ingress リソース・アノテーションを使用します。

nginx.ingress.kubernetes.io/rewrite-target: /newpath

サーバー・ブロック構成のカスタマイズ

カスタム・サーバー・ブロック構成を追加するには、以下の Kubernetes Ingress リソース・アノテーションを使用します。

nginx.ingress.kubernetes.io/server-snippet: |
    location = /health {
    return 200 'Healthy';
    add_header Content-Type text/plain;
    }

着信ネットワーク・トラフィックのルーティング

スティッキー Cookie を使用して着信ネットワーク・トラフィックを常に同じアップストリーム・サーバーにルーティングするには、以下の Kubernetes Ingress リソース・アノテーションを使用します。

nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "cookie_name1"
nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
nginx.ingress.kubernetes.io/configuration-snippet: |
  more_set_headers "Set-Cookie: HttpOnly";

Kubernetes Ingress コントローラーは、デフォルトでスティッキー Cookie に Secure 属性と HttpOnly 属性を追加します。これは変更できません。

SSL サービス・サポートによるトラフィックの暗号化を許可する

HTTPS を必要とする上流アプリケーションへのトラフィックを暗号化する SSL サービスをサポートするには、 Kubernetes イングレスリソースバックエンドプロトコルアノテーションとバックエンド証明書認証アノテーションを使用します。

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
nginx.ingress.kubernetes.io/proxy-ssl-secret: app1-ssl-secret
nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: 5
nginx.ingress.kubernetes.io/proxy-ssl-name: proxy-ssl-name=mydomain.com
nginx.ingress.kubernetes.io/proxy-ssl-verify: true

非標準 TCP ポートを使用したアプリへのアクセス

標準以外の TCP ポートを介してアプリにアクセスするには、以下の手順を実行します。

tcp-services 構成マップを作成して、以下の例のポートのような TCP ポートを指定します。 tcp-services ConfigMap, の要件については、このブログを参照のこと。
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: tcp-services
  namespace: kube-system
data:
  9000: "<namespace>/<service>:8080"
```
kube-system 名前空間に構成マップを作成します。
```
kubectl apply -f tcp-services.yaml -n kube-system
```
tcp-services 構成マップibm-ingress-deploy-configにフィールドとして構成マップを指定します。
```
"tcpServicesConfig":"kube-system/tcp-services"
```
各 ALB サービスを変更して、ポートを追加します。

アップストリーム・キープアライブ要求の最大数の設定

1 つのキープアライブ接続を介して処理できる要求の最大数を設定するには、以下の Kubernetes ibm-k8s-controller-config ConfigMap フィールドを使用します。

upstream-keepalive-requests: 32

アップストリーム・キープアライブの最大タイムアウトの設定

ALB プロキシー・サーバーとアプリのアップストリーム・サーバーの間でキープアライブ接続を開いたままにする最大時間を設定するには、以下の Kubernetes ibm-k8s-controller-config configmap フィールドを使用します。

upstream-keepalive-timeout: 32

ALB デプロイメントのカスタマイズ

ibm-ingress-deploy-config 構成マップを作成して、Kubernetes Ingress イメージを実行する ALB のデプロイメントをカスタマイズします。

各 ALB を公開するサービスの名前を取得します。
- クラシック・クラスター:
```
kubectl get svc -n kube-system | grep alb
```
- VPC クラスター: 出力で、public-crc204dl7w0qf6n6sp7tug のようなフォーマットのサービス名を探します。
```
kubectl get svc -n kube-system | grep LoadBalancer
```

Ingressのデプロイメントをカスタマイズするために ConfigMap

ibm-ingress-deploy-config 構成マップの YAML ファイルを作成します。 ALB ID ごとに、以下のオプション設定を 1 つ以上指定できます。なお、構成しようとしている設定だけを指定すればよく、すべての設定を指定する必要はありません。
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: ibm-ingress-deploy-config
  namespace: kube-system
data:
  <alb1-id>: '{"deepInspect":"<true|false>", "defaultBackendService":"<service_name>", "defaultCertificate":"<namespace>/<secret_name>", "defaultConfig":"<namespace>/<configmap-name>","enableSslPassthrough":"<true|false>", "httpPort":"<port>", "httpsPort":"<port>", "ingressClass":"<class>", "logLevel":<log_level>, "replicas":<number_of_replicas>, "tcpServicesConfig":"<kube-system/tcp-services>", "enableIngressValidation":"<true|false>"}'
  <alb2-id>: '{"deepInspect":"<true|false>", "defaultBackendService":"<service_name>", "defaultCertificate":"<namespace>/<secret_name>", "enableSslPassthrough":"<true|false>", "httpPort":"<port>", "httpsPort":"<port>", "ingressClass":"<class>","logLevel":<log_level>, "replicas":<number_of_replicas>, "tcpServicesConfig":"<kube-system/tcp-services>", "enableIngressValidation":"<true|false>"}'
```
deepInspect

Ingress オブジェクト・セキュリティー・ディープ・インスペクターを有効または無効にします。有効にすると、ALB は処理前に Ingress リソースの構成値を検査します。詳しくは、 ingress-nginx ソース・コードを参照してください。

この機能は、ALB バージョン 1.2.0 以降で使用可能であり、デフォルトで有効になっています。

defaultBackendService

ホストが構成されていなかったり、一致するホストが見つからなかったりする場合に要求を受け取るための、オプションのデフォルト・サービスの名前を指定します。このサービスは、404 メッセージを生成する IBM 提供のデフォルト・サービスを置き換えます。カスタムのエラー・ページを構成したり、接続をテストしたりするときにこのサービスを使用できます。

defaultCertificate

Ingress ALB で構成されている任意のサブドメインに適用されるデフォルトの TLS 証明書のシークレットで、形式は secret_namespace/secret_name のようになります。シークレットを作成するには、ibmcloud ks ingress secret create コマンドを実行します。別の TLS 証明書のシークレットが Ingress リソースの spec.tls セクションに指定されており、そのシークレットが Ingress リソースと同じ名前空間に存在する場合、そのシークレットが、このデフォルト・シークレットの代わりに適用されます。

defaultConfig

ALB のデフォルトの構成マップを指定します。使用する構成マップの場所を namespace/configmap-name の形式で入力します。例えば、kube-system/ibm-k8s-controller-config です。

enableAnnotationValidation

Ingress オブジェクト・アノテーションの検証を有効または無効にします。有効にすると、ALB は処理前に Ingress リソース内のアノテーション値を検証します。詳しくは、 ingress-nginx ソース・コードを参照してください。

この機能は、ALB バージョン 1.9.0 以降で使用可能であり、デフォルトで有効になっています。

enableSslPassthrough

ALB の SSL パススルーを有効にします。 TLS 接続は終了せず、何もしないで通過します。

httpPort, httpsPort

開きたい HTTP ポートまたは HTTPS ポートを追加することによって、Ingress ALB のデフォルト以外のポートを公開します。

ingressClass

Ingress リソースで public-iks-k8s-nginx または private-iks-k8s-nginx 以外のクラスを指定した場合は、そのクラスを指定します。

logLevel

使用するログ・レベルを指定します。以下の値から選択します。

2: **diff** コマンドを使用して NGINX 内の構成の変更を表示することにより、詳細を表示します。

3: サービス、Ingress ルール、エンドポイントの変更に関する詳細を JSON 形式で表示します。

5: NGINX をデバッグモードで設定する。

ロギングについて詳しくは、デバッグ・ロギングを参照してください。

replicas

デフォルトでは、各 ALB のレプリカは 2 つです。 ALB ポッド数を増やすことで、ALB の処理能力をスケールアップします。詳しくは、ALB ポッドのレプリカ数を増やすを参照してください。

tcpServicesConfig

標準以外の TCP ポートを介してアプリ・サービスにアクセスする方法についての情報が設定されている構成マップとその構成マップが属する名前空間を、kube-system/tcp-services のように指定します。

enableIngressValidation

この ALB の Ingress 検証 Webhook のデプロイメントを有効にします。 Webhook は、無効な構成を防ぐために、クラスターに適用される前に Ingress リソースを検証します。 (ALB は、公開する Ingress クラスに属する Ingress リソースのみを処理します。) デフォルト: "false"。
クラスターに ibm-ingress-deploy-config 構成マップを作成します。
```
kubectl create -f ibm-ingress-deploy-config.yaml
```
変更を反映させるために、ALB を更新します。変更が ALB に適用されるまでに、最大で 5 分かかることがあるので注意してください。
```
ibmcloud ks ingress alb update -c <cluster_name_or_ID>
```
標準以外の HTTP ポート、HTTPS ポート、または TCP ポートを指定した場合は、各 ALB サービスでポートを開く必要があります。
1. ステップ 1 で見つけた各 ALB サービスについて、YAML ファイルを編集します。
```
kubectl edit svc -n kube-system <alb_svc_name>
```
2. spec.ports セクションで、開くポートを追加します。デフォルトでは、ポート 80 と 443 が開きます。 80 と 443 を開いたままにする場合は、それらをこのファイルから削除しないでください。指定しないポートは閉じられます。 nodePort を指定しないでください。ポートを追加して変更を適用した後に、nodePort が自動的に割り当てられます。
```
...
ports:
- name: port-80
  nodePort: 32632
  port: 80
  protocol: TCP
  targetPort: 80
- name: port-443
  nodePort: 32293
  port: 443
  protocol: TCP
  targetPort: 443
- name: <new_port>
  port: <port>
  protocol: TCP
  targetPort: <port>
...
```
3. ファイルを保存して閉じます。変更が自動的に適用されます。

Ingress クラスのカスタマイズ

Ingress クラスで、クラス名を Ingress コントローラーのタイプに関連付けます。 IngressClass リソースを使用して、Ingress クラスをカスタマイズします。

アプリへの App ID 認証の追加

でIngressを設定することで、アプリの認証を強制することができます。 IBM Cloud App ID.

既存の App ID インスタンスを選択するか、新しいインスタンスを作成します。

App ID インスタンスは、クラスター内の 1 つの名前空間のみで使用できます。複数の名前空間で Ingress リソースの App ID を構成する場合は、このセクションのステップを繰り返して、各名前空間の Ingress リソースに対して固有の App ID インスタンスを指定します。
- 既存のインスタンスを使用するには、サービス・インスタンス名に 小文字 の英数字のみが含まれていること、およびその長さが 25 文字を超えないことを確認してください。名前を変更するには、サービス・インスタンスの詳細ページの「オプションを増やす」メニューから**「サービスの名前変更」**を選択します。
- 新しい App ID インスタンスをプロビジョンするには、以下のようにします。
  1. サービス名を、サービス・インスタンスの独自の固有名で置き換えます。サービスインスタンス名には、小文字の英数字のみを使用し、25文字以内でなければなりません。
  2. クラスターのデプロイ先と同じリージョンを選択します。
  3. 「作成」 をクリックします。
アプリのリダイレクト URL を追加します。リダイレクト URL は、アプリのコールバック・エンドポイントです。フィッシング攻撃を防止するために、IBM Cloud App ID は、要求 URL をリダイレクト URL の許可リストと照合します。
1. App ID 管理コンソールで、**「認証の管理 (Manage Authentication)」**にナビゲートします。
2. 「ID プロバイダータブで、ID プロバイダーが選択されていることを確認します。 ID プロバイダが選択されていない場合、ユーザは認証されず、アプリに匿名でアクセスするためのアクセストークンが発行される。
3. 「認証設定 (Authentication settings)」 タブで、アプリのリダイレクト URL を形式 https://<hostname>/oauth2-<App_ID_service_instance_name>/callback で追加します。サービス・インスタンス名の文字はすべて小文字で指定する必要があることに注意してください。
IBM Cloud App ID ログアウト機能を使用する場合は、/sign_out を形式 https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out でドメインに追加し、この URL をリダイレクト URL リストに組み込む必要があります。カスタムのログアウトページを使用したい場合は、 ConfigMap の OAuth2-Proxy を whitelist_domains に設定する必要があります。 rd 照会パラメーターを指定して https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out エンドポイントを呼び出すか、カスタム・ログアウト・ページで X-Auth-Request-Redirect ヘッダーを設定します。詳しくは、サインアウトを参照してください。
App ID サービス・インスタンスをクラスターにバインドします。このコマンドはサービス・インスタンス用のサービス・キーを作成するが、 --key オプションを指定して既存のサービス・キー認証情報を使用することもできる。サービス・インスタンスを、Ingress リソースが存在するのと同じ名前空間にバインドするようにしてください。サービス・インスタンス名の文字はすべて小文字で指定する必要があることに注意してください。
```
ibmcloud ks cluster service bind --cluster <cluster_name_or_ID> --namespace <namespace> --service <App_ID_service_instance_name> [--key <service_instance_key>]
```
サービスがクラスターに正常にバインドされると、サービス・インスタンスの資格情報を保持するクラスター・シークレットが作成されます。 CLI 出力例:
```
ibmcloud ks cluster service bind --cluster mycluster --namespace mynamespace --service appid1
Binding service instance to namespace...
OK
Namespace:    mynamespace
Secret name:  binding-<service_instance_name>
```
クラスターで ALB OAuth プロキシー・アドオンを有効にします。このアドオンは、Kubernetes リソース (App ID サービス・インスタンスの OAuth2-Proxy デプロイメント、OAuth2-Proxy デプロイメントの構成を格納するシークレット、App ID インスタンスのために着信要求を OAuth2-Proxy デプロイメントにルーティングするよう ALB を構成する Ingress リソース) を作成および管理します。それらのリソースの名前はそれぞれ oauth2- で始まります。
1. alb-oauth-proxyアドオンを有効にします。
```
ibmcloud ks cluster addon enable alb-oauth-proxy --cluster <cluster_name_or_ID>
```
2. ALB OAuth プロキシー・アドオンの状況が Addon Ready であることを確認します。
```
ibmcloud ks cluster addon ls --cluster <cluster_name_or_ID>
```
App ID 認証を追加するアプリの Ingress リソースで、リソース名の長さが 25 文字を超えていないことを確認します。次に、以下のアノテーションを metadata.annotations セクションに追加します。
1. 以下の auth-url アノテーションを追加します。このアノテーションは、App ID インスタンスの OAuth2-Proxy の URL を指定します。これは、App ID の OIDC リライング・パーティー (RP) として機能します。サービス・インスタンス名の文字はすべて小文字で指定する必要があることに注意してください。
```
...
annotations:
   nginx.ingress.kubernetes.io/auth-url: https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth
...
```
2. OAuth2-Proxy によって使用される認証 Cookie が 4 KB を超えることがあります。そのため、2 つの部分に分割されています。 OAuth2-Proxy が両方の Cookie を適切に更新できるようにするには、以下のスニペットを追加する必要があります。
```
...
annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
    auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
    access_by_lua_block {
        if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
        ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
        end
    }
...
```
3. アプリに Authorization ヘッダーで送信するトークンを選択します。 IDおよびアクセストークンの詳細については、 App ID のドキュメントを参照してください。
  - ID Token のみを送信するには、以下のアノテーションを追加する：
```
...
annotations:
    nginx.ingress.kubernetes.io/auth-response-headers: Authorization
...
```
  - Access Token のみを送信するには、 configuration-snippet 注釈に以下の情報を追加する。 (これにより、ステップ 5.2のスニペットが拡張されます。)
```
...
annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
    auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
    auth_request_set $access_token $upstream_http_x_auth_request_access_token;
    access_by_lua_block {
        if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
        ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
        end
        if ngx.var.access_token ~= "" then
        ngx.req.set_header("Authorization", "Bearer " .. ngx.var.access_token)
        end
    }
...
```
  - Access Token と ID Token を送信するには、 configuration-snippet 注釈に以下の情報を追加する。 (これにより、ステップ 5.2のスニペットが拡張されます。)
```
...
 annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
    auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
    auth_request_set $access_token $upstream_http_x_auth_request_access_token;
    auth_request_set $id_token $upstream_http_authorization;
    access_by_lua_block {
        if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
        ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
        end
        if ngx.var.id_token ~= "" and ngx.var.access_token ~= "" then
        ngx.req.set_header("Authorization", "Bearer " .. ngx.var.access_token .. " " .. ngx.var.id_token:match("%s*Bearer%s*(.*)"))
        end
    }
...
```
4. オプション: API ストラテジーに加えて、または API ストラテジーの代わりにアプリが Web アプリ・ストラテジーをサポートする場合は、nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2-<App_ID_service_instance_name>/start?rd=$escaped_request_uri アノテーションを追加します。サービスインスタンス名の文字はすべて小文字でなければならないことに注意してください。
  - このアノテーションを指定したときにクライアントの認証が失敗すると、クライアントは App ID インスタンスの OAuth2-Proxy の URL にリダイレクトされます。 App ID の OIDC リライング・パーティー (RP) として機能するこの OAuth2-Proxy によって、クライアントが認証のために App ID ログイン・ページにリダイレクトされます。
  - このアノテーションが指定されていないと、クライアントは有効なベアラー・トークンで認証する必要があります。クライアントの認証が失敗すると、クライアントの要求は 401 Unauthorized エラー・メッセージで拒否されます。
Ingress リソースを再適用して、App ID 認証を実施します。適切なアノテーションが設定された Ingress リソースが再適用されると、OAuth2-Proxy デプロイメントのデプロイ、そのデプロイメントのサービスの作成、OAuth2-Proxy デプロイメント・メッセージのルーティングを構成するための別個の Ingress リソースの作成が、ALB OAuth プロキシー・アドオンによって行われます。これらのアドオン・リソースは削除しないでください。
```
kubectl apply -f <app_ingress_resource>.yaml -n namespace
```
App ID 認証がアプリに実施されていることを確認します。
- アプリが Web アプリ戦略をサポートしている場合: Web ブラウザーでアプリの URL にアクセスします。 App ID が正しく適用されている場合は、App ID 認証ログイン・ページにリダイレクトされます。
- アプリが API 戦略をサポートしている場合: アプリへの要求の許可ヘッダーに Bearer アクセス・トークンを指定します。アクセス・トークンを取得するには、App ID の資料を参照してください。 App ID が正しく適用されている場合、要求は正常に認証され、アプリに経路指定されます。許可ヘッダーにアクセス・トークンを指定せずにアプリに要求を送信した場合や App ID によってアクセス・トークンが受け入れられない場合、要求は拒否されます。
オプション： クラスタ上でネットワーク・ポリシーまたは別のファイアウォール・ソリューションを使用して送信トラフィックを制限している場合は、クラスタから AppID's パブリック・サービスへのアクセスを許可する必要があります。このサービスのIPアドレス範囲を取得するには、カスタマーサポートにリクエストを送信してください。

オプション: OAuth2-Proxy のデフォルト動作をカスタマイズするには、Kubernetes 構成マップを作成します。

変更する OAuth2-Proxy 設定の値を指定する構成マップ YAML ファイルを作成します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: oauth2-<App_ID_service_instance_name>
  namespace: <ingress_resource_namespace>
data:
  auth_logging: <true|false>
  # Log all authentication attempts.
  auth_logging_format:
  # Format for authentication logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#logging-configuration
  cookie_csrf_expire: "15m"
  # Expiration time for CSRF cookie. Default is "15m".
  cookie_csrf_per_request: <true|false>
  # Enable multiple CSRF cookies per request, making it possible to have parallel requests. Default is "false".
  cookie_domains:
  # A list of optional domains to force cookies to. The longest domain that matches the request’s host is used. If there is no match for the request’s host, the shortest domain is used. Example: sub.domain.com,example.com
  cookie_expire: "168h0m0s"
  # Expiration time for cookies. Default: "168h0m0s".
  cookie_samesite: ""
  # SameSite attribute for cookies. Supported values: "lax", "strict", "none", or "".
  email_domains: ""
  # Authenticate IDs that use the specified email domain. To authenticate IDs that use any email domain, use "*". Default: "". Example: example.com,example2.com
  pass_access_token: <true|false>
  # Pass the OAuth access token to the backend app via the X-Forwarded-Access-Token header.
  request_logging: <true|false>
  # Log all requests to the backend app.
  request_logging_format:
  # Format for request logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#request-log-format
  scope:
  # Scope of the OAuth authentication. For more info, see https://oauth.net/2/scope/
  set_authorization_header: <true|false>
  # Set the Authorization Bearer response header when the app responds to the Ingress ALB, such when using the NGINX auth_request mode.
  set_xauthrequest: <true|false>
  # Set X-Auth-Request-User, X-Auth-Request-Email, and X-Auth-Request-Preferred-Username response headers when the app responds to the Ingress ALB, such as when using the NGINX auth_request mode.
  standard_logging: <true|false>
  # Log standard runtime information.
  standard_logging_format:
  # Format for standard logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#standard-log-format
  tls_secret_name:
  # The name of a secret that contains the server-side TLS certificate and key to enable TLS between the OAuth2-Proxy and the Ingress ALB. By default, the TLS secret defined in your Ingress resources is used.
  whitelist_domains:
  # Allowed domains for redirection after authentication. Default: "". Example: example.com,*.example2.com For more info, see: https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#command-line-options
  oidc_extra_audiences:
  # Additional audiences which are allowed to pass verification.
  cookie_refresh:
  # Refresh the cookie after this duration. Example: "15m". To use this feature, you must enable "Refresh token" for the AppID instance. For more info, see: /docs/appid?topic=appid-managing-idp&interface=ui#idp-token-lifetime

構成マップ・リソースをアドオンに適用します。変更が自動的に適用されます。
```
kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
```

ALB OAuth Proxyアドオンのバージョンごとの変更点一覧については、 IBM Cloud ALB OAuth Proxyアドオンの変更履歴をご参照ください。

ALB OAuth Proxy アドオンのアップグレード

ALB OAuth Proxyアドオンをアップグレードするには、まずアドオンを無効にし、アドオンを再度有効にしてバージョンを指定する必要があります。

アドオンが無効になっていても、監視対象 OAuth2 Proxy インスタンスがクラスター上に残っているため、アップグレード・プロセスは中断されません。

アドオンを無効にします。

ibmcloud ks cluster addon disable alb-oauth-proxy --cluster <cluster_name_or_ID>

使用可能なアドオン・バージョンをリストし、使用するバージョンを決定します。
```
ibmcloud ks cluster addon versions --addon alb-oauth-proxy
```
アドオンを有効にして、--version オプションを指定します。バージョンを指定しないと、デフォルト・バージョンが有効になります。
```
ibmcloud ks cluster addon enable alb-oauth-proxy --cluster <cluster_name_or_ID> [--version <version>]
```

ソース IP アドレスの保持

デフォルトでは、クライアント要求のソース IP アドレスは Ingress ALB によって保持されません。ソース IP アドレスを保持するには、VPC クラスターで PROXY プロトコルを有効にするか、クラシック・クラスターで externalTrafficPolicy を変更します。

VPC クラスターでの PROXY プロトコルの有効化

VPCクラスタ内のクライアントリクエストのソースIPアドレスを保持するには、クラスタ内のIngress ALBを公開するすべてのロードバランサで NGINX PROXYプロトコルを有効にします。

オプション Cloud Internet Services (CIS) を使用している場合は、以下の手順を完了する。
1. CIS コンソールで、[ セキュリティ ] > [ 詳細設定 ] > [ True クライアント IP ヘッダー] をクリックして、[ True クライアント IP ヘッダー] 設定を有効にします。
2. kube-system/ibm-k8s-controller-config configmap を編集し、 allow-snippet-annotations: "true" を設定する。
3. 注釈の追加 nginx.ingress.kubernetes.io/server-snippet: real_ip_header CF-Connecting-IP;。
PROXY プロトコルを有効にします。このコマンドのパラメーターについて詳しくは、CLI リファレンスを参照してください。このコマンドを実行すると、更新された PROXY プロトコル構成で新しいロード・バランサーが作成されます。ロード・バランサーの再作成中には、それぞれのサブネットでロード・バランサーごとに 2 つの未使用の IP アドレスを使用できる必要があります。これらのロード・バランサーが作成されると、既存の ALB ロード・バランサーが削除されます。このロード・バランサーの再作成プロセスにより、サービスが中断する可能性があります。
```
ibmcloud ks ingress lb proxy-protocol enable --cluster <cluster_name_or_ID> --cidr <subnet_CIDR> --header-timeout <timeout>
```
クラスター内の ALB を公開するロード・バランサーを対象に PROXY プロトコルが有効になっていることを確認します。
```
ibmcloud ks ingress lb get --cluster <cluster_name_or_ID>
```
後で PROXY プロトコルを無効にするには、以下のコマンドを実行できます。
```
ibmcloud ks ingress lb proxy-protocol disable --cluster <cluster_name_or_ID>
```

クラシック・クラスターの `externalTrafficPolicy` の変更

クライアント要求のソース IP アドレスをクラシック・クラスターに保持します。

Classicクラスタでは、ALBのレプリカ数を2以上に増やすとレプリカ数が増えますが、'externalTrafficPolicy が'Local として設定されている場合、2以上のレプリカは使用されません。クラスタには2つのロードバランサーポッドしか存在せず（アクティブ-パッシブセットアップ）、このトラフィックポリシーのため、同じノード上のALBポッドにのみ受信トラフィックを転送します。

デフォルトでは、クライアント要求のソース IP アドレスは保持されません。アプリへのクライアント要求がクラスターに送信されると、その要求は、ALB を公開しているロード・バランサー・サービス・ポッドに転送されます。ロード・バランサー・サービス・ポッドと同じワーカー・ノードにアプリ・ポッドが存在しない場合、ロード・バランサーは異なるワーカー・ノード上のアプリ・ポッドに要求を転送します。パッケージのソース IP アドレスは、アプリ・ポッドが実行されるワーカー・ノードのパブリック IP アドレスに変更されます。

クライアントリクエストの元のソースIPアドレスを保持するには、ソースIP保持を有効にします。クライアントの IP を保持すると、例えば、アプリ・サーバーがセキュリティーやアクセス制御ポリシーを適用する必要がある場合などに役に立ちます。

ソースIPの保存が有効になると、ロードバランサはトラフィックを別のワーカーノード上のALBポッドに転送していたのを、同じワーカーノード上のALBポッドに転送するようになります。このシフト中にアプリのダウン時間が発生する可能性があります。 ALB を無効にした場合、ALB を公開するロード・バランサー・サービスに対して行ったソース IP の変更はすべて失われます。 ALB を再度有効にする場合、ソース IP を再度有効にする必要があります。

ソース IP の保持を有効にするには、Ingress ALB を公開するロード・バランサー・サービスを編集します。

1 つの ALB またはクラスター内のすべての ALB のソース IP の保持を有効にします。
- 1 つの ALB のソース IP の保持をセットアップするには、次の手順を実行します。
  1. ソース IP を有効にする ALB の ID を取得します。 ALB サービスは、パブリック ALB の場合は public-cr18e61e63c6e94b658596ca93d087eed9-alb1、プライベート ALB の場合は private-cr18e61e63c6e94b658596ca93d087eed9-alb1 のような形式になります。
```
kubectl get svc -n kube-system | grep alb
```
  2. ALB を公開するロード・バランサー・サービスの YAML を開きます。
```
kubectl edit svc <ALB_ID> -n kube-system
```
  3. spec の下で、externalTrafficPolicy の値を「Cluster」から「Local」に変更します。
  4. 構成ファイルを保存して閉じます。出力は、以下のようになります。
```
service "public-cr18e61e63c6e94b658596ca93d087eed9-alb1" edited
```
- クラスター内のすべてのパブリック ALB のソース IP 保持をセットアップするには、次のコマンドを実行します。
```
kubectl get svc -n kube-system | grep alb | awk '{print $1}' | grep "^public" | while read alb; do kubectl patch svc $alb -n kube-system -p '{"spec":{"externalTrafficPolicy":"Local"}}'; done
```
  出力例
```
"public-cr18e61e63c6e94b658596ca93d087eed9-alb1", "public-cr17e61e63c6e94b658596ca92d087eed9-alb2" patched
```
- クラスター内のすべてのプライベート ALB のソース IP 保持をセットアップするには、次のコマンドを実行します。
```
kubectl get svc -n kube-system | grep alb | awk '{print $1}' | grep "^private" | while read alb; do kubectl patch svc $alb -n kube-system -p '{"spec":{"externalTrafficPolicy":"Local"}}'; done
```
  出力例
```
"private-cr18e61e63c6e94b658596ca93d087eed9-alb1", "private-cr17e61e63c6e94b658596ca92d087eed9-alb2" patched
```
ソース IP が保持されていることを ALB ポッド・ログで確認します。
1. 変更した ALB のポッドの ID を取得します。
```
kubectl get pods -n kube-system | grep alb
```
2. その ALB ポッドのログを開きます。 client フィールドの IP アドレスが、ロード・バランサー・サービスの IP アドレスではなく、クライアント要求の IP アドレスであることを確認します。
```
kubectl logs <ALB_pod_ID> nginx-ingress -n kube-system
```
これで、バックエンド・アプリに送信された要求のヘッダーを見れば、x-forwarded-for ヘッダーでクライアント IP アドレスがわかるようになります。

ソース IP を保持しないようにする場合は、サービスに対して行った変更を戻します。

パブリック ALB のソース IP 保持を戻すには、次を実行します。

kubectl get svc -n kube-system | grep alb | awk '{print $1}' | grep "^public" | while read alb; do kubectl patch svc $alb -n kube-system -p '{"spec":{"externalTrafficPolicy":"Cluster"}}'; done

プライベート ALB のソース IP 保持を戻すには、次を実行します。

kubectl get svc -n kube-system | grep alb | awk '{print $1}' | grep "^private" | while read alb; do kubectl patch svc $alb -n kube-system -p '{"spec":{"externalTrafficPolicy":"Cluster"}}'; done

HTTP レベルで SSL プロトコルと SSL 暗号を構成する

ibm-k8s-controller-config 構成マップを編集して、グローバル HTTP レベルで SSL プロトコルと暗号を有効にします。

例えば、TLS 1.0 または 1.1 のサポートが必要なレガシー・クライアントをまだ使用する場合は、その TLS バージョンを手動で有効にして、TLS 1.2 と TLS 1.3 だけのデフォルト設定をオーバーライドする必要があります。

すべてのホストで有効なプロトコルを指定する場合、TLSv1.1 および TLSv1.2 パラメーター (1.1.13、1.0.12) は、OpenSSL 1.0.1 以上が使用されている場合にのみ使用できます。 TLSv1.3 パラメーター (1.13.0) は、TLSv1.3 対応版の OpenSSL 1.1.1 が使用されている場合にのみ使用できます。

構成マップを編集して SSL プロトコルおよび暗号を有効にするには、以下のようにします。

ibm-k8s-controller-config 構成マップ・リソースに対応する構成ファイルを編集します。
```
kubectl edit cm ibm-k8s-controller-config -n kube-system
```

SSL プロトコルおよび暗号を追加します。 OpenSSL ライブラリ暗号リスト形式に従って暗号をフォーマットする。

apiVersion: v1
data:
  ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2 TLSv1.3"
  ssl-ciphers: "HIGH:!aNULL:!MD5:!CAMELLIA:!AESCCM:!ECDH+CHACHA20"
kind: ConfigMap
metadata:
  name: ibm-k8s-controller-config
  namespace: kube-system

構成ファイルを保存します。
構成マップの変更が適用されたことを確認します。これらの変更は ALB に自動的に適用されます。
```
kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml
```

既存のクライアントへのカスタム証明書の送信

Server Name Indication (SNI) をサポートしないレガシー・デバイスがあり、Ingress リソース内のカスタム TLS 証明書を使用する場合は、カスタム TLS 証明書とカスタム TLS シークレットを使用するように ALB のサーバー設定を編集する必要があります。

クラシック・クラスターを作成すると、IBM 提供のデフォルトの Ingress シークレットに関する Let's Encrypt 証明書が生成されます。クラスター内でカスタム・シークレットを作成し、Ingress リソース内で TLS 終端用にこのカスタム・シークレットを指定すると、Ingress ALB はデフォルトの Let's Encrypt 証明書の代わりにカスタム・シークレットの証明書をクライアントに送信します。しかし、クライアントが SNI をサポートしていない場合、ALB のデフォルトのサーバー設定にデフォルトのシークレットがリストされるので、Ingress ALB のデフォルトは Let's Encrypt 証明書になります。 SNI をサポートしていないデバイスにカスタム証明書を送信するには、以下の手順に従って、ALB のデフォルト・サーバー設定をカスタム・シークレットに変更します。

デフォルトで生成される「Let 's Encrypt」証明書は、実動で使用するためのものではありません。実動ワークロードでは、独自のカスタム証明書を持ち込みます。

alb-default-server Ingress リソースを編集します。
```
kubectl edit ingress alb-default-server -n kube-system
```

spec.tls セクションで、hosts.secretName 設定の値を、カスタム証明書を格納するカスタム・シークレットの名前に変更します。例:

spec:
    rules:
    ...
    tls:
    - hosts:
    - invalid.mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    secretName: <custom_secret_name>

リソース・ファイルを保存します。
リソースがカスタム・シークレット名を指すようになったことを確認します。これらの変更は ALB に自動的に適用されます。
```
kubectl get ingress alb-default-server -n kube-system -o yaml
```

接続処理の微調整

client-header-timeout、 client-body-timeout、 keep-alive の設定は、クライアント、Ingressコントローラー、バックエンドサーバー間の接続がアクティブな状態を維持する時間を決定する重要な設定である。これらのタイムアウトは、リクエスト処理を最適化する上で重要な役割を果たす。特に、長く続くクライアント接続、バックエンドサーバーからの応答の遅れ、貴重なリソースが不必要に占有されないようにすることなどに対処する。

client-header-timeout は、サーバーが完全なクライアントヘッダーを待つ最大時間を定義する。同様に、 client-body-timeout は、クライアントがリクエスト本文を送るまでサーバーが待つ時間を示す。これらのタイムアウトはいずれも、 keep-alive パラメータと一致しなければならない。このパラメータは、サーバーが次のリクエストを待っている間、どれだけの時間コネクションをオープンにしておくかを規定する。これらのタイムアウトがキープアライブ設定と一致しない場合、NGINXは接続を終了し、予期しないクライアントの動作やリクエストの失敗を引き起こす可能性があります。

上記のパラメーターは、 kube-system 名前空間の ibm-k8s-controller-config ConfigMap で設定できる。

apiVersion: v1
kind: ConfigMap
metadata:
  name: ibm-k8s-controller-config
  namespace: kube-system
data:
  ...
  client-body-timeout: "100"
  client-header-timeout: "100"
  keep-alive: "100"

詳細は client-header-timeout, client-body-timeout および keep-aliveNginx オプションを参照のこと。

タイムアウトの調整

クラスタが IBM Cloud Cloud Internet Services (CIS) / Cloudflareで公開され、Webアプリケーションファイアウォール（WAF）またはグローバルロードバランシングを使用している場合は、接続の早期終了を防ぐために、 kube-system 名前空間内にある ibm-k8s-controller-config リソースの client-header-timeout、 client-body-timeout 、 keep-alive パラメータを900秒を超える値に設定する必要があります。詳細については、 Cloudflareのドキュメントを参照してください。

kube-system 名前空間内の ibm-k8s-controller-config ConfigMap の client-header-timeout、 client-body-timeout、 keep-alive パラメータを更新する。各パラメーターを905秒に設定するコマンドの例を以下に示す：
```
kubectl patch cm --patch '{"data": {"client-header-timeout": "905", "client-body-timeout": "905", "keep-alive": "905"}}' --type=merge -n kube-system ibm-k8s-controller-config
```
VPCクラスタのみ ：VPCロードバランサーのアイドル接続タイムアウトも変更する必要があります。 public-cr<clusterid> LoadBalancer サービスのタイムアウトを調整する。 910秒に設定するコマンドの例は以下の通り：
```
kubectl annotate svc -n kube-system public-cr<clusterid> service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout="910"
```

ALB のパフォーマンスの調整

Ingress ALB のパフォーマンスを最適化するために、必要に応じてデフォルト設定を変更できます。

ログ・バッファリングとフラッシュ・タイムアウトの有効化

デフォルトでは、Ingress ALB は要求の到着時に各要求をログに記録します。頻繁に使用される環境がある場合は、要求が到着するたびに各要求をログに記録していると、ディスク入出力の使用率が大幅に増加します。連続的なディスク入出力を回避するには、ibm-k8s-controller-config Ingress 構成マップを編集して、ALB のログ・バッファリングとフラッシュ・タイムアウトを有効にします。バッファリングが有効になっている場合、ALB は、ログ・エントリーごとに個別の書き込み操作を実行する代わりに、一連のエントリーをバッファーに入れて、1 回の操作でまとめてファイルに書き込みます。

ibm-k8s-controller-config 構成マップを編集します。
```
kubectl edit cm ibm-k8s-controller-config -n kube-system
```
ALB がバッファーの内容をログに書き込むときのしきい値を設定します。
- バッファー・サイズ: buffer フィールドを追加して、ALB がバッファーの内容をログ・ファイルに書き込む前にバッファーに保持できるログ・メモリーの量を設定します。例えば、デフォルト値の 100KB を使用すると、ALB はバッファーのログ・ファイルの内容が 100KB に達するたびにバッファーの内容をログに書き込みます。
- 時間間隔: flush フィールドを追加して、ALB がログ・ファイルに書き込む頻度を設定します。例えば、デフォルト値の 5m を使用すると、ALB は 5 分ごとにログ・ファイルにバッファーの内容を書き込みます。
- 時間間隔またはバッファー・サイズ: flush と buffer の両方が設定されている場合、ALB は、最初に満たされたしきい値パラメーターに基づいて、ログ・ファイルにバッファーの内容を書き込みます。
```
apiVersion: v1
kind: ConfigMap
data:
    access-log-params: "buffer=100KB, flush=5m"
  metadata:
name: ibm-k8s-controller-config
...
```
構成ファイルを保存して閉じます。これらの変更は ALB に自動的に適用されます。
ALB のログに、設定したメモリー・サイズまたは時間間隔に従って書き込まれたバッファー内容が記録されていることを確認します。
```
kubectl logs -n kube-system <ALB_ID> -c nginx-ingress
```

キープアライブ接続の数または期間の変更

キープアライブ接続によって、接続を開いたり閉じたりするのに必要な CPU とネットワークの使用量を減らせれば、パフォーマンスに大きな影響を及ぼせます。 ALB のパフォーマンスを最適化するには、ALB とクライアントのキープアライブ接続の最大数と、キープアライブ接続を持続できる時間を変更します。

ibm-k8s-controller-config 構成マップを編集します。
```
kubectl edit cm ibm-k8s-controller-config -n kube-system
```
keep-alive-requests および keep-alive の値を変更します。
- keep-alive-requests: Ingress ALB に対して接続を開いておくことができるキープアライブ・クライアント接続の数。デフォルトは 100 です。
- keep-alive: キープアライブ・クライアント接続を Ingress ALB に対して開いておくタイムアウト (秒)。デフォルトは 75 です。
```
apiVersion: v1
data:
  keep-alive-requests: 100
  keep-alive: 75
kind: ConfigMap
metadata:
  name: ibm-k8s-controller-config
  ...
```
構成ファイルを保存して閉じます。これらの変更は ALB に自動的に適用されます。
構成マップの変更が適用されたことを確認します。
```
kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml
```

同時接続の数またはワーカー・プロセスの数の変更

1 つの ALB の NGINX ワーカー・プロセスが処理できる同時接続の数または 1 つの ALB に対して発生するワーカー・プロセスの数のデフォルト設定を変更します。

それぞれの ALB には、クライアント接続を処理し、ALB が公開するアプリのアップストリーム・サーバーと通信する NGINX ワーカー・プロセスがあります。 ALB ごとのワーカー・プロセスの数またはワーカー・プロセスが処理できる接続数を変更して、ALB が処理できるクライアントの最大数を管理できます。 maximum clients = worker_processes * worker_connections という式を使用して、クライアントの最大接続数を計算します。

max-worker-connections フィールドは、1 つの ALB の NGINX ワーカー・プロセスが処理できる同時接続の最大数を設定します。デフォルト値は16384です。 max-worker-connections パラメーターには、クライアントとの接続だけでなく、ALB がプロキシー処理するすべての接続が含まれています。また、同時接続の実際の数は、max-worker-open-files パラメーターによって設定されるオープン・ファイルの最大数の制限を超えることはできません。 max-worker-connections の値を 0 に設定した場合は、代わりに max-worker-open-files の値が使用されます。
worker-processes フィールドは、1 つの ALB の NGINX ワーカー・プロセスの最大数を設定します。デフォルト値は "auto" です。これは、ワーカー・プロセスの数が ALB がデプロイされているワーカー・ノード上のコアの数と一致することを示します。ワーカー・プロセスで高いレベルの I/O 操作を実行する必要がある場合は、この値を数値に変更できます。

ibm-k8s-controller-config 構成マップを編集します。
```
kubectl edit cm ibm-k8s-controller-config -n kube-system
```

max-worker-connections または worker-processes の値を変更します。

apiVersion: v1
data:
  max-worker-connections: 16384
  worker-processes: "auto"
kind: ConfigMap
metadata:
  name: ibm-k8s-controller-config
  ...

構成ファイルを保存します。これらの変更は ALB に自動的に適用されます。
構成マップの変更が適用されたことを確認します。
```
kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml
```

ワーカー・プロセスのオープン・ファイル数の変更

ALB の各ワーカー・ノード・プロセスによって開くことができるファイル数のデフォルトの最大値を変更します。

それぞれの ALB には、クライアント接続を処理し、ALB が公開するアプリのアップストリーム・サーバーと通信する NGINX ワーカー・プロセスがあります。ワーカー・プロセスが、開くことができるファイルの最大数に達した場合は、NGINX ログに Too many open files というエラーが表示されることがあります。デフォルトでは、max-worker-open-files パラメーターは 0 に設定されています。これは、system limit of maximum open files / worker-processes - 1024 の式の値が使用されることを示します。この値を別の整数に変更すると、この式は適用されなくなります。

ibm-k8s-controller-config 構成マップを編集します。
```
kubectl edit cm ibm-k8s-controller-config -n kube-system
```

max-worker-open-files の値を変更します。

apiVersion: v1
data:
  max-worker-open-files: 0
kind: ConfigMap
metadata:
  name: ibm-k8s-controller-config
  ...

構成ファイルを保存します。これらの変更は ALB に自動的に適用されます。
構成マップの変更が適用されたことを確認します。
```
kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml
```

カーネルのパフォーマンスの調整

Ingress ALB のパフォーマンスを最適化するには、ワーカー・ノードで Linux カーネルの sysctl パラメーターを変更することもできます。ワーカー・ノードには、最適化されたカーネルの調整が自動的にプロビジョンされるため、特定のパフォーマンス最適化要件がある場合にのみこの設定を変更します。

ALB ルーティングのカスタマイズ

ホスト・ヘッダーへのサーバー・ポートの追加

プライベート ALB を使用した着信要求のルーティング

App ID を使用したアプリケーションの認証

クライアント要求本体の最大サイズの設定

クライアント応答データ・バッファリングの有効化および無効化

接続と読み込みのタイムアウトのカスタマイズ

エラー・アクションのカスタマイズ

デフォルトの HTTP と HTTPS ポートを変更する

要求ヘッダーのカスタマイズ

応答ヘッダーのカスタマイズ

外部サービスへのパス定義の追加

非セキュア要求のリダイレクト

有効化と無効化 HTTP Strict Transport Security

キープアライブ要求の最大数の設定

キープアライブ要求の最大タイムアウトの設定

ラージ・クライアント・ヘッダー・バッファーの最大数の設定

ALB が要求 URI と一致する方法の変更

カスタム・ロケーション・ブロック構成の追加

相互認証の構成

プロキシー・バッファー・サイズの構成

プロキシー・バッファー番号の構成

ビジー・プロキシー・バッファー・サイズの構成

ALB が要求を渡すことができる場合の構成

速度制限

応答ヘッダーの削除

パスの再書き込み

サーバー・ブロック構成のカスタマイズ

着信ネットワーク・トラフィックのルーティング

SSL サービス・サポートによるトラフィックの暗号化を許可する

非標準 TCP ポートを使用したアプリへのアクセス

アップストリーム・キープアライブ要求の最大数の設定

アップストリーム・キープアライブの最大タイムアウトの設定

ALB デプロイメントのカスタマイズ

Ingressのデプロイメントをカスタマイズするために ConfigMap

Ingress クラスのカスタマイズ

アプリへの App ID 認証の追加

ALB OAuth Proxy アドオンのアップグレード

ソース IP アドレスの保持

VPC クラスターでの PROXY プロトコルの有効化

クラシック・クラスターの externalTrafficPolicy の変更

HTTP レベルで SSL プロトコルと SSL 暗号を構成する

既存のクライアントへのカスタム証明書の送信

接続処理の微調整

タイムアウトの調整

ALB のパフォーマンスの調整

ログ・バッファリングとフラッシュ・タイムアウトの有効化

キープアライブ接続の数または期間の変更

同時接続の数またはワーカー・プロセスの数の変更

ワーカー・プロセスのオープン・ファイル数の変更

カーネルのパフォーマンスの調整

クラシック・クラスターの `externalTrafficPolicy` の変更