自訂 ALB 遞送

修改執行 Kubernetes Ingress 映像檔之 ALB 的預設值。

有時，您可以透過新增 Kubernetes NGINX 註釋 (nginx.ingress.kubernetes.io/<annotation>) 來自訂 Ingress 的遞送。Kubernetes NGINX 註釋一律會套用至資源中的所有服務路徑，且您無法在註釋內指定服務名稱。不支援自訂 IBM Cloud Kubernetes Service 註釋 (ingress.bluemix.net/<annotation>)。

依預設，在 2022 年 1 月 31 日或之後建立的叢集上的 Kubernetes Ingress Controller (ALB) 不會處理具有 Snippet 註釋 (例如，nginx.ingress.kubernetes.io/configuration-snippet) 的 Ingress 資源，因為所有新叢集都使用 ALB 的 ConfigMap中的 allow-snippet-annotations: "false" 配置部署。如果您在這裡新增任何建議的配置 Snippet，則需要編輯 ALB 的 ConfigMap (kube-system/ibm-k8s-controller-config)，並將 allow-snippet-annotations: "false" 變更為 allow-snippet-annotations: "true"。

將伺服器埠新增至主機標頭

若要在將要求轉遞至後端應用程式之前，將伺服器埠新增至用戶端要求，請在伺服器 Snippet 註釋中配置 Proxy 至外部服務，或配置為 ibm-k8s-controller-config ConfigMap 欄位。

使用專用 ALB 遞送送入要求

若要使用專用 ALB 將送入要求遞送至應用程式，請在 Ingress 資源中指定 private-iks-k8s-nginx 類別註釋。專用 ALB 配置為搭配使用資源與此類別。

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

使用 App ID 鑑別應用程式

使用 IBM Cloud App ID 配置 Ingress，以透過變更特定 Kubernetes 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 (port 80) 和 HTTPS (port 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中所管理的服務)，請在位置 Snippet中配置外部服務的 Proxy。或者，將 Proxy 取代為永久重新導向至外部服務。

重新導向不安全的要求

預設情況下，不安全的 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
```

設定保留作用中要求數目上限

若要設定可透過一個保留作用中連線提供的要求數上限，請使用下列 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 Proxy 伺服器之間保持開啟的時間上限，請使用下列 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"

配置 Proxy 緩衝區大小

若要配置讀取回應第一部分的 Proxy 緩衝區大小，請使用下列 Kubernetes Ingress 資源註釋。

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

配置 Proxy 緩衝區號碼

若要配置 ALB 的 Proxy 緩衝區數目，請使用下列 Kubernetes Ingress 資源註釋。

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

配置忙碌 Proxy 緩衝區大小

如果要配置可能忙碌的 Proxy 緩衝區大小，請使用位置 Snippet。如需相關資訊，請參閱 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 資源註釋來限制速率。

移除回應標頭

您可以在客戶端回應傳送至客戶端之前，從後端終端應用程式移除包含在客戶端回應中的標頭資訊。在位置 Snippet中配置回應標頭移除，或使用 proxy_hide_header 欄位作為 ibm-k8s-controller-config ConfigMap中的配置 Snippet。

重新編寫路徑

若要將 ALB 網域路徑上的送入網路資料流量遞送至後端應用程式所接聽的不同路徑，請使用下列 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 控制器會將 Secure 及 HttpOnly 屬性新增至組合 Cookie，無法變更。

容許 SSL 服務支援加密資料流量

若要允許 SSL 服務支援為您需要 HTTPS 的上游應用程式加密流量，請使用 Kubernetes Ingress 資源後端通訊協定註解和後端證書驗證註解。

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 ConfigMap 以指定 TCP 埠，例如下列範例埠。對於要求 tcp-servicesConfigMap,看這個部落格。

apiVersion: v1
kind: ConfigMap
metadata:
  name: tcp-services
  namespace: kube-system
data:
  9000: "<namespace>/<service>:8080"

在 kube-system 名稱空間中建立 ConfigMap。

kubectl apply -f tcp-services.yaml -n kube-system

指定 tcp-services ConfigMap 作為 ibm-ingress-deploy-config ConfigMap 中的欄位。
```
"tcpServicesConfig":"kube-system/tcp-services"
```
修改每一個 ALB 服務以新增埠。

設定上游保留作用中要求的數目上限

若要設定可透過一個保留作用中連線提供的要求數上限，請使用下列 Kubernetes ibm-k8s-controller-config ConfigMap 欄位。

upstream-keepalive-requests: 32

設定上游保留作用中逾時上限

若要設定 ALB Proxy 伺服器與應用程式上游伺服器之間保持開啟保留作用中連線的時間上限，請使用下列 Kubernetes ibm-k8s-controller-config configmap 欄位。

upstream-keepalive-timeout: 32

自訂 ALB 部署

透過建立 ibm-ingress-deploy-config ConfigMap，自訂執行 Kubernetes Ingress 映像檔之 ALB 的部署。

取得公開每一個 ALB 的服務名稱。
- 標準叢集：
```
kubectl get svc -n kube-system | grep alb
```
- VPC 叢集: 在輸出中，尋找已格式化的服務名稱，例如 public-crc204dl7w0qf6n6sp7tug。
```
kubectl get svc -n kube-system | grep LoadBalancer
```

建立 ConfigMap 以自訂 Ingress 部署

建立 ibm-ingress-deploy-config ConfigMap的 YAML 檔案。對於每一個 ALB ID，您可以指定下列一或多個選用設定。請注意，您只能指定您要配置的設定，而不需要指定所有設定。
```
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

預設 TLS 憑證套用至使用 Ingress ALB 配置的任何子網域的密碼，格式為 secret_namespace/secret_name。若要建立密鑰，您可以執行 ibmcloud ks ingress secret create 指令。如果在 Ingress 資源的 spec.tls 區段中指定不同 TLS 憑證的密鑰，且該密鑰存在於與 Ingress 資源相同的名稱空間中，則會套用該密鑰而非此預設密鑰。

defaultConfig

指定 ALB 的預設 configmap。以 namespace/configmap-name 格式輸入您要使用的 configmap 的位置。例如，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: 以 JSON 格式顯示服務、Ingress 規則、端點變更的相關詳細資料。

5: 以除錯模式配置 NGINX。

如需記載的相關資訊，請參閱除錯記載。

replicas

依預設，每一個 ALB 都有 2 個抄本。增加 ALB Pod 數目，以擴增 ALB 處理功能。如需相關資訊，請參閱增加 ALB Pod 抄本數目。

tcpServicesConfig

指定 ConfigMap 及 ConfigMap 所在的名稱空間，例如 kube-system/tcp-services，其中包含透過非標準 TCP 埠來存取應用程式服務的相關資訊。

enableIngressValidation

針對此 ALB 啟用 Ingress 驗證 Webhook 的部署。在叢集上套用 Webhook 之前，會先驗證 Ingress 資源，以防止配置無效。 (ALB 只會處理屬於它所公開的 Ingress 類別的 Ingress 資源。) 預設值："false"。
在叢集裡建立 ibm-ingress-deploy-config ConfigMap。
```
kubectl create -f ibm-ingress-deploy-config.yaml
```
若要取得變更，請更新 ALB。請注意，可能需要長達 5 分鐘才能將變更套用至 ALB。
```
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 鑑別新增至應用程式

透過使用 IBM Cloud App ID配置 Ingress，對應用程式施行鑑別。

選擇現有實例，或建立新的 App ID 實例。

App ID 實例只能在叢集裡的一個名稱空間中使用。如果您想要針對多個名稱空間中的 Ingress 資源配置 App ID，請重複本節中的步驟，以針對每一個名稱空間中的 Ingress 資源指定唯一 App ID 實例。
- 若要使用現有實例，請確保服務實例名稱僅包含小寫英數字元，且其長度不超過 25 個字元。若要變更名稱，請從服務實例詳細資料頁面上的其他選項功能表中選取 重新命名服務。
- 若要佈建新的 App ID 實例，請執行下列動作：
  1. 將服務名稱改成您自己的服務實例唯一名稱。服務實例名稱必須只包含小寫字母數字字符，且不能超過 25 個字元。
  2. 選擇叢集部署所在的相同地區。
  3. 按一下建立。
新增應用程式的重新導向 URL。重新導向 URL 是應用程式的回呼端點。為了防止釣魚攻擊，IBM Cloud App ID 會根據重定向 URL 的允許清單驗證請求 URL。
1. 在 App ID 管理主控台，導覽至管理鑑別。
2. 在身分提供者標籤中，確保已選取身分提供者。如果沒有選擇身分提供者，使用者將不會被驗證，但會獲發一個存取標記，用於匿名存取應用程式。
3. 在「驗證設定」標籤中，為您的應用程式新增重定向 URL，格式為 https://<hostname>/oauth2-<App_ID_service_instance_name>/callback。請注意，服務實例名稱中的所有字母都必須指定為小寫。
如果您使用 IBM Cloud App ID 登出功能，則必須以 https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out 的格式將 /sign_out 附加到您的網域名稱，並將此 URL 包含在重定向 URL 清單中。如果要使用自訂登出頁面，必須在 ConfigMap 中設定 whitelist_domains，以便 OAuth2-Proxy。使用 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 Proxy 附加程式。此附加程式會建立並管理下列 Kubernetes 資源: App ID 服務實例的 OAuth2-Proxy 部署、包含 OAuth2-Proxy 部署配置的密鑰，以及配置 ALB 以將送入要求遞送至 App ID 實例的 OAuth2-Proxy 部署的 Ingress 資源。每一個資源的名稱都以 oauth2- 開頭。
1. 啟用 alb-oauth-proxy 附加程式。
```
ibmcloud ks cluster addon enable alb-oauth-proxy --cluster <cluster_name_or_ID>
```
2. 驗證 ALB OAuth Proxy 附加程式的狀態為 Addon Ready。
```
ibmcloud ks cluster addon ls --cluster <cluster_name_or_ID>
```

在您要新增 App ID 鑑別之應用程式的 Ingress 資源中，請確定資源名稱長度不超過 25 個字元。然後，將下列註釋新增至 metadata.annotations 區段。

新增下列 auth-url 註釋。此註解指定 URL 的 OAuth2-Proxy 用於您的 App ID 範例，它是 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
...
```

有時 OAuth2-Proxy 使用的鑑別 Cookie 超過 4 KB。因此，它分成兩個部分。必須新增下列 Snippet，以確保 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
    }
...

選擇要在 Authorization 標頭中傳送至應用程式的記號。如需 ID 及存取記號的相關資訊，請參閱 App ID 文件。

若只要傳送 ID Token，請新增下列註釋:

...
annotations:
    nginx.ingress.kubernetes.io/auth-response-headers: Authorization
...

若只要傳送 Access Token，請將下列資訊新增至 configuration-snippet 註釋。 (這會從步驟 5.2延伸 Snippet。)

...
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延伸 Snippet。)

...
 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
    }
...

選用項目: 如果您的應用程式除了 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。這個 OAuth2-Proxy，作為 App ID 的 OIDC 信賴方 (RP)，會將用戶端重定向到您的 App ID 登入頁面進行驗證。
- 如果您未指定此註釋，則用戶端必須使用有效的載送記號進行鑑別。如果用戶端鑑別失敗，則會拒絕用戶端的要求，並顯示 401 Unauthorized 錯誤訊息。

重新套用 Ingress 資源以施行 App ID 鑑別。重新套用具有適當註釋的 Ingress 資源之後，ALB OAuth Proxy 附加程式會部署 OAuth2-Proxy 部署，為部署建立服務，並建立個別 Ingress 資源來配置 OAuth2-Proxy 部署訊息的遞送。請勿刪除這些附加程式資源。
```
kubectl apply -f <app_ingress_resource>.yaml -n namespace
```
驗證已對您的應用程式施行 App ID 鑑別。
- 如果您的應用程式支援 Web 應用程式策略：在網頁瀏覽器中存取您的應用程式 URL。如果 App ID 應用正確，您會被重定向到 App ID 驗證登入頁面。
- 如果您的應用程式支援 API 策略: 在應用程式要求的 Authorization 標頭中指定 Bearer 存取記號。若要取得存取記號，請參閱 App ID 文件。如果已正確套用 App ID，則會順利鑑別要求並將其遞送至您的應用程式。如果您將要求傳送至應用程式，但 Authorization 標頭中沒有存取記號，或 App ID未接受存取記號，則會拒絕要求。
可選：如果您在群集上使用網路政策或其他防火牆解決方案來限制外送流量，則必須確定允許從群集存取 AppID's 公共服務。若要取得此服務的 IP 位址範圍，請透過客戶支援提交申請。

選用項目: 您可以透過建立 Kubernetes ConfigMap來自訂 OAuth2-Proxy 的預設行為。

建立 ConfigMap YAML 檔案，以指定您要變更的 OAuth2-Proxy 設定值。

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

將 ConfigMap 資源套用至您的附加程式。您的變更會自動套用。
```
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 位址

依預設，Ingress ALB 不會保留用戶端要求的來源 IP 位址。若要保留來源 IP 位址，您可以啟用 VPC 叢集中的 PROXY 通訊協定或在標準叢集中變更 externalTrafficPolicy。

在 VPC 叢集裡啟用 PROXY 通訊協定

若要保留 VPC 叢集裡用戶端要求的來源 IP 位址，您可以針對在叢集裡公開 Ingress ALB 的所有負載平衡器啟用 NGINX PROXY 通訊協定。

可選如果您使用 Cloud Internet Services (CIS)，請完成下列步驟。
1. 在 CIS 主控台中啟用 True client IP header 設定，方法是按一下安全性 > 進階 > True client IP header。
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 通訊協定配置來建立新的負載平衡器。負載平衡器重新啟用時，每個子網路中必須有兩個未使用的 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 位址。

在經典集群中，將 ALB 副本計數增加到 2 以上會增加副本數量，但當 externalTrafficPolicy 配置為 Local 時，不會使用任何超過 2 的副本。叢集上僅存在 2 個負載平衡器 Pod（採用主動-被動設定），且由於此流量策略，僅將傳入流量轉送至同一節點上的 ALB Pod。

依預設，不會保留用戶端要求的來源 IP 位址。將應用程式的用戶端要求傳送至叢集時，會將該要求遞送至可公開 ALB 之負載平衡器服務的 Pod。如果沒有應用程式 Pod 存在於與負載平衡器服務 Pod 相同的工作者節點上，則負載平衡器會將要求轉遞至不同工作者節點上的應用程式 Pod。套件的來源 IP 位址會變更為應用程式 Pod 執行所在之工作者節點的公用 IP 位址。

若要保留用戶端要求的原始來源 IP 位址，您可以啟用來源 IP 保留。舉例來說，當應用程式伺服器必須套用安全及存取控制原則時，保留用戶端的 IP 是很有用的。

啟用來源 IP 保留後，負載平衡器將從將流量轉送至不同工作節點上的 ALB pod 轉移到相同工作節點上的 ALB pod。在此輪班期間，您的應用程式可能會遇到關閉時間。如果停用 ALB，則對用於公開 ALB 的負載平衡器服務進行的任何來源 IP 變更都將遺失。當您重新啟用 ALB 時，必須重新啟用來源 IP。

若要啟用來源 IP 保留，請編輯用於公開 Ingress ALB 的負載平衡器服務：

啟用叢集裡單一 ALB 或所有 ALB 的來源 IP 保留。

若要設定單一 ALB 的來源 IP 保留，請執行下列動作：
1. 取得您要啟用來源 IP 的 ALB ID。 ALB 服務的格式類似 public-cr18e61e63c6e94b658596ca93d087eed9-alb1（若為公用 ALB）或 private-cr18e61e63c6e94b658596ca93d087eed9-alb1（若為專用 ALB）。
```
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 Pod 日誌中。
1. 取得您已修改的 ALB Pod ID。
```
kubectl get pods -n kube-system | grep alb
```
2. 開啟該 ALB Pod 的日誌。驗證 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 ConfigMap，在全域 HTTP 層級啟用 SSL 通訊協定和密碼。

例如，如果您仍有舊式用戶端需要 TLS 1.0 或 1.1 支援，則必須手動啟用這些 TLS 版本，以僅置換 TLS 1.2 及 TLS 1.3 的預設值。

當您指定所有主機的已啟用通訊協定時，只有在使用 OpenSSL 1.0.1 或更新版本時，TLSv1.1 及 TLSv1.2 參數（1.1.13、1.0.12）才有作用。只有在使用以 TLSv1.3 支援所建置的 OpenSSL 1.1.1 時，TLSv1.3 參數 (1.13.0) 才有作用。

若要編輯 ConfigMap，以啟用 SSL 通訊協定及密碼，請執行下列動作：

編輯 ibm-k8s-controller-config ConfigMap 資源的設定檔。
```
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

儲存配置檔。
驗證已套用 ConfigMap 變更。變更會自動套用至 ALB。
```
kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml
```

將自訂憑證傳送至舊式用戶端

如果您擁有不支援伺服器名稱指示 (SNI) 的舊設備，並且您在 Ingress 資源中使用自訂 TLS 證書，則必須編輯 ALB 的伺服器設定以使用您的自訂 TLS 憑證和自訂 TLS 金鑰。

當您建立標準叢集時，會針對 IBM 所提供的預設 Ingress 密碼產生 Let's Encrypt 憑證。如果您在叢集裡建立自訂密碼，並在 Ingress 資源中指定此自訂密碼來進行 TLS 終止，則 Ingress ALB 會將自訂密碼的憑證傳送至用戶端，而非預設 Let's Encrypt 憑證。不過，如果用戶端不支援 SNI，則 Ingress ALB 預設為 Let's Encrypt 憑證，因為預設密碼會列在 ALB 的預設伺服器設定中。若要將自訂證書傳送至不支援 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 參數一致，該參數會規範伺服器在等待進一步請求時保持連線開啟的時間。如果這些超時與 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 會在每一個要求到達時記載每一個要求。如果您有大量使用的環境，在每一個要求送達時記載它，可大幅增加磁碟 I/O 使用率。為了避免連續的磁碟 I/O，您可以透過編輯 ibm-k8s-controller-config Ingress ConfigMap 來啟用 ALB 的日誌緩衝和刷新超時。當啟用緩衝時，ALB 會緩衝處理一連串項目並以單一作業將其全部寫到檔案中，而不是對每一個日誌項目執行個別的寫入作業。

編輯 ibm-k8s-controller-config ConfigMap。

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 ConfigMap。

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。

驗證已套用 ConfigMap 變更。

kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml

變更同時連線或工作者處理程序的數目

變更一個 ALB 的 NGINX 工作者處理程序可以處理的同時連線數或一個 ALB 可以發生的工作者處理程序數的預設值。

每個 ALB 都有 NGINX 工作者處理程序，用於處理用戶端連線並與 ALB 所公開應用程式的上游伺服器進行通訊。透過變更每個 ALB 的工作者處理程序數目或工作者處理程序可以處理的連線數目，您可以管理 ALB 可以處理的用戶端數目上限。使用下列公式計算用戶端連線數上限: maximum clients = worker_processes * worker_connections。

max-worker-connections 欄位設定一個 ALB 的 NGINX 工作者處理程序可以處理的同時連線數上限。預設值為 16384。請注意，max-worker-connections 參數包括 ALB Proxy 的所有連線，而不只是與用戶端的連線。此外，實際同時連線數不能超出開啟檔案數上限的限制(由 max-worker-open-files 參數設定)。如果您將 max-worker-connections 的值設為 0，則會改用 max-worker-open-files 的值。
worker-processes 欄位設定一個 ALB 的 NGINX 工作者處理程序數目上限。預設值為 "auto"，表示工作者處理程序數目符合部署 ALB 之工作者節點上的核心數目。如果工作者處理程序必須執行高階 I/0 作業，則可以將此值變更為數字。

編輯 ibm-k8s-controller-config ConfigMap。

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。

驗證已套用 ConfigMap 變更。

kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml

變更工作者處理程序的開啟檔案數目

變更 ALB 的每一個工作者節點處理程序可以開啟的檔案數預設上限。

每個 ALB 都有 NGINX 工作者處理程序，用於處理用戶端連線並與 ALB 所公開應用程式的上游伺服器進行通訊。如果工作者處理程序達到可開啟的檔案數目上限，您可能會在 NGINX 日誌中看到 Too many open files 錯誤。依預設，max-worker-open-files 參數設為 0，表示使用下列公式中的值: system limit of maximum open files / worker-processes - 1024。如果您將值變更為另一個整數，則公式不再適用。

編輯 ibm-k8s-controller-config ConfigMap。

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。

驗證已套用 ConfigMap 變更。

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 的方式

新增自訂位置區塊配置

配置交互鑑別

配置 Proxy 緩衝區大小

配置 Proxy 緩衝區號碼

配置忙碌 Proxy 緩衝區大小

配置 ALB 何時可以傳遞要求

速率限制

移除回應標頭

重新編寫路徑

自訂伺服器區塊配置

遞送送入的網路資料流量

容許 SSL 服務支援加密資料流量

使用非標準 TCP 埠存取應用程式

設定上游保留作用中要求的數目上限

設定上游保留作用中逾時上限

自訂 ALB 部署

建立 ConfigMap 以自訂 Ingress 部署

自訂 Ingress 類別

將 App ID 鑑別新增至應用程式

升級 ALB OAuth Proxy 附加程式

保留來源 IP 位址

在 VPC 叢集裡啟用 PROXY 通訊協定

變更標準叢集中的 externalTrafficPolicy

配置 HTTP 層次的 SSL 通訊協定及 SSL 密碼

將自訂憑證傳送至舊式用戶端

微調連線處理

調整超時

調整 ALB 效能

啟用日誌緩衝和清除逾時

變更保留作用中連線的數目或持續時間

變更同時連線或工作者處理程序的數目

變更工作者處理程序的開啟檔案數目

調整核心效能

變更標準叢集中的 `externalTrafficPolicy`