ALB 라우팅 사용자 지정

Traefik 미들웨어 리소스, Ingress 어노테이션 및 ibm-ingress-deploy-config ConfigMap 를 사용하여 애플리케이션 로드 밸런서(ALB)가 라우팅, 헤더, 타임아웃, 인증 및 트래픽을 처리하는 방식을 사용자 정의할 수 있습니다.

호스트 헤더에 서버 포트 추가하기

기본적으로 Traefik은 Host 헤더를 대부분의 최신 앱과 호환되는 방식으로 처리합니다. Host 헤더에 포트를 포함하도록 수정하는 것은 권장되지 않습니다. 변경 사항을 적용하기 전에, Traefik이 기본적으로 헤더를 어떻게 처리하는지 확인하고, 언제 헤더를 덮어쓰는 것이 적절한지 파악하십시오.

Host 헤더의 기본 처리 방식

Host Traefik은 기본적으로 passHostHeader: true. Host 헤더에 포트 번호를 포함시키는 대신, 다음과 같은 별도의 전달 헤더를 자동으로 추가합니다:

  • X-Forwarded-Host
  • X-Forwarded-Port
구형 앱의 ‘ Host ’ 헤더 덮어쓰기

앱에서 Host 헤더에 포함된 포트가 필요한 경우, Traefik 헤더 미들웨어를 사용하여 해당 헤더를 덮어쓰십시오.

# Example (Kubernetes Middleware)
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-header
spec:
  headers:
    customRequestHeaders:
      Host: "legacy-app.example:8080"

Traefik Ingress 어노테이션을 사용하여 Ingress 리소스에 미들웨어를 적용하세요. CRD 처리가 활성화되어 있는지 확인하십시오(기본 설정). CRD 처리를 구성하려면 ‘ ibm-ingress-deploy-config ’의 ‘ ConfigMap ’ 및 ‘ processTraefikCRDs ’ 필드를 참조하십시오.

사설 ALB를 사용하여 들어오는 요청 라우팅하기

기본적으로 공용 ALB는 Ingress 리소스를 처리합니다. 들어오는 요청을 사설 ALB를 통해 라우팅하려면, Ingress 리소스의spec.ingressClassName ’ 필드에 ‘ private-iks-traefik ’ 클래스를 지정하십시오.

spec.ingressClassName: "private-iks-traefik"

앱 인증은 App ID

Traefik Ingress를 구성하여 IBM Cloud App ID 앱에 대한 인증을 적용하도록 Traefik Ingress를 구성하세요. 자세한 내용은 ‘앱에 App ID 인증 추가하기’를 참조하세요.

클라이언트 요청 본문의 최대 크기 설정

기본적으로 Traefik은 클라이언트 요청 본문 크기에 대한 제한을 적용하지 않습니다. 상한값을 설정하려면 버퍼링 미들웨어를 생성한 다음, 이를 Ingress 리소스에 적용하세요.

Traefik은 설정된 제한을 초과하는 모든 요청을 HTTP 413 응답으로 거부합니다.

  1. Traefik 버퍼링 미들웨어 리소스를 생성합니다. maxRequestBodyBytes 를 클라이언트가 전송할 수 있는 최대 바이트 수로 설정합니다. 다음 예제에서는 2MB(2097152바이트)로 제한을 설정합니다.

    # Example (Kubernetes Middleware)
    apiVersion: traefik.io/v1alpha1
    kind: Middleware
    metadata:
      name: limit
    spec:
      buffering:
        maxRequestBodyBytes: 2097152
    
  2. Traefik Ingress 어노테이션을 사용하여 Ingress 리소스에 미들웨어를 적용하세요.

클라이언트 응답 데이터 버퍼링 활성화

기본적으로 Traefik은 응답을 버퍼링하지 않고 직접 스트리밍합니다. 버퍼링 미들웨어를 사용하면 Traefik은 응답을 클라이언트에 전송하기 전에 메모리에 저장하거나 디스크에 기록할 수 있습니다. 대부분의 경우 응답 버퍼링을 권장하지 않으므로, 앱에서 이 미들웨어가 필요한 경우에만 사용하십시오.

응답 버퍼링을 활성화하려면 다음 단계를 수행하십시오

  1. Traefik 버퍼링 미들웨어 리소스를 생성합니다. maxResponseBodyBytes 을 최대 응답 크기(바이트 단위)로 설정하고, memResponseBodyBytes 을 응답이 메모리에 보관되지 않고 디스크에 기록되는 임계값으로 설정하십시오. 다음 예제에서는 총 5MB까지 버퍼링하며, 그중 처음 1MB는 메모리에 저장됩니다.

    # Example (Kubernetes Middleware)
    apiVersion: traefik.io/v1alpha1
    kind: Middleware
    metadata:
      name: response-buffer
    spec:
      buffering:
        maxResponseBodyBytes: 5242880    # 5 MB max response size
        memResponseBodyBytes: 1048576    # 1 MB in memory, then disk
    
  2. Traefik Ingress 어노테이션을 사용하여 Ingress 리소스에 미들웨어를 적용하세요.

타임아웃 조정

Traefik은 두 가지 유형의 타임아웃 제어 기능을 제공합니다. 하나는 클라이언트와 ALB 간의 타임아웃이고, 다른 하나는 ALB와 백엔드 앱 간의 타임아웃입니다. 병목 현상이 발생하는 위치에 따라 각각 별도로 구성하십시오.

클라이언트-ALB 간 타임아웃을 설정하려면, 해당 ibm-ingress-deploy-config ConfigMap 필드를 구성하십시오:

ALB와 백엔드 앱 간의 연결 및 읽기 타임아웃을 설정하려면, ServersTransport 를 사용하여 Traefik과 HTTP 서버 간의 전송 방식을 구성하십시오.

# Example (Kubernetes ServersTransport)
apiVersion: traefik.io/v1alpha1
kind: ServersTransport
metadata:
  name: mytransport
spec:
  forwardingTimeouts:
    dialTimeout: 30s
    responseHeaderTimeout: 10s
    idleConnTimeout: 90s

VPC 클러스터의 경우, 공용 ALB를 노출하는 로드 밸런서 서비스의 유휴 연결 시간 제한도 수정해야 합니다. CLUSTER_ID 을 자신의 클러스터 ID로 대체하십시오. 클러스터 ID는 ibmcloud ks cluster get --cluster CLUSTER_NAME_OR_ID 을 실행하여 확인할 수 있습니다. 다음 예제에서는 타임아웃을 910초로 설정합니다:

kubectl annotate svc -n kube-system public-cr<clusterid> service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout="910"

Traefik은 타임아웃 값으로 0 을 지원하며, 이 값을 설정하면 타임아웃이 비활성화됩니다.

VPC 로드 밸런서의 ‘ ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout ’ 어노테이션은 0 값을 지원하지 않습니다. 타임아웃 값은 50초에서 7200초(2시간) 사이로 설정할 수 있습니다. 2시간보다 긴 시간이 필요한 경우, 지원 요청을 제출하고 업무상 사유를 제시해 주십시오.

IBM Cloud Internet Services (CIS) 또는 Cloudflare를 통해 클러스터가 노출되어 있고, 웹 애플리케이션 방화벽(WAF)이나 글로벌 부하 분산이 활성화된 경우, 이러한 타임아웃 값을 900초 이상으로 설정하십시오. 자세한 내용은 Cloudflare 설명서를 참조하십시오.

ServersTransport 리소스를 생성한 후, Traefik Service 어노테이션을 사용하여 해당 리소스를 Service 리소스에 적용하십시오.

오류 처리 방식 사용자 지정

ALB가 특정 HTTP 오류에 대해 수행할 수 있는 사용자 정의 조치를 지정하려면 Traefik 오류 미들웨어를 구성하십시오. 미들웨어를 생성한 후, Traefik Ingress 어노테이션을 사용하여 Ingress 리소스에 적용하세요.

HTTP 및 HTTPS 의 기본 포트 변경

기본적으로 ALB는 HTTP 의 경우 포트 80에서, HTTPS 의 경우 포트 443에서 연결을 수신 대기합니다. 클러스터에 비표준 포트가 필요한 경우, ibm-ingress-deploy-config ConfigMap 페이지의 ‘ httpPort ’ 및 ‘ httpsPort ’ 필드를 사용하여 각 ALB에 대해 해당 값을 변경할 수 있습니다.

요청 헤더 사용자 지정

Traefik 헤더 미들웨어를 사용하여 클라이언트 요청을 백엔드 앱으로 전달하기 전에 헤더 필드를 추가, 덮어쓰기 또는 제거할 수 있습니다. 이는 스크립트 이름, 테넌트 식별자 또는 앱에 필요한 기타 메타데이터와 같은 컨텍스트를 주입하는 데 유용합니다.

# Example (Kubernetes Middleware)
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-header
spec:
  headers:
    customRequestHeaders:
      X-Script-Name: "test"

미들웨어를 생성한 후, Traefik Ingress 어노테이션을 사용하여 Ingress 리소스에 적용하세요.

응답 헤더 사용자 지정

Traefik 헤더 미들웨어를 사용하여 응답을 클라이언트에 전송하기 전에 헤더 필드를 추가, 덮어쓰기 또는 제거할 수 있습니다. 이는 보안 정책을 적용하거나, CORS 헤더를 추가하거나, 클라이언트에 도달하기 전에 내부 헤더를 제거하는 데 유용합니다.

# Example (Kubernetes Middleware)
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-header
spec:
  headers:
    customResponseHeaders:
      X-Custom-Response-Header: "value"

미들웨어를 생성한 후, Traefik Ingress 어노테이션을 사용하여 Ingress 리소스에 적용하세요.

보안되지 않은 요청 리디렉션

HTTPS httpsRedirect 전용 액세스를 적용하고, 들어오는 모든 요청을 엔드포인트로 영구적으로 리디렉션하려면, HTTP HTTPS ibm-ingress-deploy-config ConfigMap.

HTTP 의 엄격한 전송 보안(Strict Transport Security) 기능 활성화 및 비활성화

HTTP Strict Transport Security( HSTS )는 브라우저가 도메인에 HTTPS 를 통해서만 접속하도록 지시하여, 프로토콜 다운그레이드 공격을 방지합니다. 이 기능은 Traefik에서 선택적으로 활성화할 수 있습니다. stsSeconds, stsIncludeSubdomains, stsPreload 필드를 사용하여 Headers 미들웨어를 통해 이 기능을 활성화하십시오.

# Example (Kubernetes Middleware) - produces: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: security-headers
spec:
  headers:
    stsSeconds: 31536000            # max-age=1 year
    stsIncludeSubdomains: true
    stsPreload: true

다음 Traefik Ingress 어노테이션을 사용하여 Ingress 리소스에 미들웨어를 적용하세요.

ALB가 요청 URI를 매칭하는 방식 수정하기

기본적으로 Traefik은 요청을 라우팅할 때 PathPrefix 매처(matcher)를 사용합니다. 앱에서 정확한 경로 일치 또는 정규식 기반 라우팅이 필요한 경우, 다음 Traefik Ingress 어노테이션을 사용하여 매처(matcher)를 재정의하십시오.

traefik.ingress.kubernetes.io/router.pathmatcher: PathRegexp

상호 인증 구성

상호 인증( TLS, mTLS )은 서버와 클라이언트 모두 유효한 인증서를 제시해야 하므로, 표준 인증( TLS )보다 더 강력한 인증을 제공합니다. ALB에서 클라이언트 인증서 인증을 요구하려면, CA 인증서 비밀을 참조하는 TLSOption 리소스를 생성하십시오.

# Example (Kubernetes TLSOption)
apiVersion: traefik.io/v1alpha1
kind: TLSOption
metadata:
  name: mtls
  namespace: default
spec:
  minVersion: VersionTLS12
  clientAuth:
    secretNames:
      - my-ca-secret
    clientAuthType: RequireAndVerifyClientCert

TLSOption 리소스를 생성한 후, Traefik Ingress 어노테이션을 사용하여 해당 리소스를 Ingress 리소스에 적용하세요.

업스트림 요청에 대한 재시도 동작 구성

백엔드 서버가 응답하지 않을 경우, Traefik은 다른 업스트림 서버를 대상으로 요청을 자동으로 재시도할 수 있습니다. Traefik 재시도 미들웨어를 사용하여 재시도 동작을 구성합니다. 미들웨어를 생성한 후, Traefik Ingress 어노테이션을 사용하여 Ingress 리소스에 적용하세요.

속도 제한

속도 제한은 특정 시간 창 내에서 ALB가 처리하는 요청 수를 제한함으로써 백엔드 애플리케이션을 트래픽 급증 및 악용으로부터 보호합니다. Traefik RateLimit 미들웨어를 사용하여 속도 제한을 구성합니다. 미들웨어를 생성한 후, Traefik Ingress 어노테이션을 사용하여 Ingress 리소스에 적용하세요.

경로 재작성

경로 재작성을 사용하면 백엔드 앱이 수신 대기하는 경로와 다른 공개 URL 경로를 노출할 수 있습니다. 예를 들어, /app 으로 들어오는 요청을 / 에서 리스닝 중인 백엔드 앱으로 전달할 수 있습니다. 고정 대체가 필요한지, 패턴 기반 대체가 필요한지에 따라 다음 Traefik 리소스 중 하나를 사용하십시오:

# Example Replace the path with /foo
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-replacepath
spec:
  replacePath:
    path: "/foo"
# Example Replace path with regex
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-replacepathregex
spec:
  replacePathRegex:
    regex: "^/foo/(.*)"
    replacement: "/bar/$1"

다음 Traefik Ingress 어노테이션을 사용하여 Ingress 리소스에 미들웨어를 적용하세요.

스티키 쿠키를 이용한 트래픽 라우팅

스티키 세션은 세션이 지속되는 동안 클라이언트의 요청이 항상 동일한 백엔드 서버로 라우팅되도록 보장합니다. 이는 세션 데이터를 서버에 로컬로 저장하는 상태 유지형 앱에 유용합니다. Ingress 리소스에서 Traefik Service의 sticky 쿠키 어노테이션을 구성하여 스티키 세션을 활성화하세요.

앱과 ALB 간의 트래픽 암호화

기본적으로 Traefik은 일반 HTTP 을 통해 트래픽을 백엔드 앱으로 전달합니다. 앱에서 암호화된 업스트림 연결이 필요한 경우, ServersTransport 리소스를 사용하여 ALB와 앱 간의 TLS 을 구성하고, CA 인증서 및 예상 서버 이름을 포함시키십시오.

# Example (Kubernetes ServersTransport)
apiVersion: traefik.io/v1alpha1
kind: ServersTransport
metadata:
  name: backend-transport
spec:
  rootCAs:
    - secret: my-ca-cert
  serverName: <myapp.example.com> # must match your certificate

다음 Traefik Service 어노테이션을 사용하여 Service 리소스에 ServersTransport 를 적용하세요.

ALB 배치 사용자 정의

ibm-ingress-deploy-config ( ConfigMap )는 복제본 수, 포트, 로그 수준, 타임아웃 값, Ingress 제공자 등 ALB 수준의 설정을 제어합니다. 이 ConfigMap 를 사용하면 개별 Ingress 리소스를 수정하지 않고도 클러스터 내의 하나 이상의 ALB에 구성 변경 사항을 적용할 수 있습니다.

  1. 각 ALB를 노출하는 서비스의 이름을 가져오십시오. 다음 단계에서 이 서비스 이름들을 사용하게 되므로 잘 기억해 두세요.

    • 클래식 클러스터:
        kubectl get svc -n kube-system | grep alb
        ```
    * VPC 클러스터: 출력에서 `public-crc204dl7w0qf6n6sp7tug`와 같이 형식화된 서비스 이름을 찾으십시오.
    
    ```sh {: pre}
        kubectl get svc -n kube-system | grep LoadBalancer
        ```
    
  2. ibm-ingress-deploy-config configmap에 대한 YAML 파일을 작성하십시오. 각 ALB ID에 대해 다음 선택적 설정 중 하나 이상을 지정할 수 있습니다. 설정하려는 항목만 포함하면 됩니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: ibm-ingress-deploy-config
      namespace: kube-system
    data:
      <alb1-id>: '{"replicas":<number_of_replicas>, "ingressClass":"<class>", "httpsPort":"<port>", "httpPort":"<port>", "logLevel": "<TRACE|DEBUG|INFO|WARN|ERROR|FATAL|PANIC>", "ingressProvider": "<ingress|ingress-nginx>", "processTraefikCRDs": <true|false>, "traefikIngressNginxAllowExternalNameServices": <true|false>, "traefikCRDAllowCrossNamespace": <true|false>, "traefikCRDAllowExternalNameServices": <true|false>, "httpReadTimeout": <seconds>, "httpWriteTimeout": <seconds>, "httpIdleTimeout": <seconds>, "httpsReadTimeout": <seconds>, "httpsWriteTimeout": <seconds>, "httpsIdleTimeout": <seconds>, "httpsRedirect": <true|false>, "customEntryPoints": {"<name>": {"port": <port>, "protocol": "<TCP|UDP>", "readTimeout": <seconds|0>, "writeTimeout": <seconds|0>, "idleTimeout": <seconds|0>, "udpTimeout": <seconds>}}, "tolerations": [{"key":"<key>","operator":"<Equal|Exists>","value":"<value>","effect":"<NoSchedule|PreferNoSchedule|NoExecute>"}]}'
      <alb2-id>: '{"replicas":<number_of_replicas>, "ingressClass":"<class>", "httpsPort":"<port>", "httpPort":"<port>", "logLevel": "<TRACE|DEBUG|INFO|WARN|ERROR|FATAL|PANIC>", "ingressProvider": "<ingress|ingress-nginx>", "processTraefikCRDs": <true|false>, "traefikIngressNginxAllowExternalNameServices": <true|false>, "traefikCRDAllowCrossNamespace": <true|false>, "traefikCRDAllowExternalNameServices": <true|false>, "httpReadTimeout": <seconds>, "httpWriteTimeout": <seconds>, "httpIdleTimeout": <seconds>, "httpsReadTimeout": <seconds>, "httpsWriteTimeout": <seconds>, "httpsIdleTimeout": <seconds>, "httpsRedirect": <true|false>, "customEntryPoints": {"<name>": {"port": <port>, "protocol": "<TCP|UDP>", "readTimeout": <seconds|0>, "writeTimeout": <seconds|0>, "idleTimeout": <seconds|0>, "udpTimeout": <seconds>}}, "tolerations": [{"key":"<key>","operator":"<Equal|Exists>","value":"<value>","effect":"<NoSchedule|PreferNoSchedule|NoExecute>"}]}'
    
    replicas
    기본적으로 각 ALB에는 두 개의 복제본이 있습니다. ALB 팟(Pod) 복제본 수를 늘려 ALB 처리 기능을 스케일링 업합니다. 자세한 정보는 ALB 팟(Pod) 복제본 수 늘리기를 참조하십시오.
    ingressClass
    Ingress 리소스에서 public-iks-traefik 또는 private-iks-traefik 이외의 클래스를 지정한 경우, 여기에 클래스 이름을 입력하세요.
    httpPort, httpsPort
    열려는 HTTP 또는 HTTPS 포트를 추가하여 Ingress ALB에 대한 기본이 아닌 포트를 노출합니다.
    기본값: 80/443.
    logLevel
    로깅 수준을 지정하십시오. 다음 중에서 선택하세요: TRACE, DEBUG, INFO, WARN, ERROR, FATAL, PANIC.
    기본값: INFO.
    ingressProvider
    이 ALB에 사용할 Traefik Ingress 제공자를 지정하십시오. 유효 값:
    ingress: Traefik 고유의 인그레스 컨트롤러를 사용합니다. Ingress 리소스에 지정된 Traefik 전용 어노테이션을 처리합니다.
    ingress-nginx: 임시 Traefik의 Ingress용 호환성 레이어 -NGINX 를 사용합니다. 이 도구는 Ingress( NGINX )용으로 생성된 주석을 처리하며, 가능한 경우 Ingress( NGINX )의 동작을 모방합니다. 이 값을 활용하여 Ingress( NGINX )에서 Traefik으로 마이그레이션하십시오.
    기본값: ingress.
    processTraefikCRDs
    true 로 설정하면, Traefik은 Ingress 리소스 외에도 자체 CRD 리소스를 처리합니다. 지원되는 CRD에는 IngressRoute, MiddlewareTLSOption 이 포함됩니다. 전체 목록을 보려면 Traefik의 CRD 관련 문서를 참조하세요.
    기본값: true.
    traefikIngressNginxAllowExternalNameServices
    ingress-nginx 제공자가 처리하는 Ingress 객체에 대해 ExternalName 서비스 지원을 활성화합니다. 이 옵션은 ‘ ingressProvider ’가 ‘ ingress-nginx ’로 설정된 경우에만 적용됩니다.
    기본값: true.
    traefikCRDAllowCrossNamespace
    IngressRoute 리소스(Traefik CRD)가 다른 네임스페이스의 리소스를 참조할 수 있도록 합니다.
    기본값: false.
    traefikCRDAllowExternalNameServices
    IngressRoute 리소스(Traefik CRD)가 ExternalName 서비스를 참조할 수 있도록 합니다.
    기본값: false.
    httpReadTimeout, httpsReadTimeout
    ALB와 클라이언트 간의 HTTP / HTTPS 읽기 타임아웃을 구성합니다. 값은 초 단위의 정수여야 하며, 0으로 설정하면 타임아웃이 비활성화됩니다.
    자세한 내용은 Traefik 문서를 참조하십시오.
    httpWriteTimeout, httpsWriteTimeout
    ALB와 클라이언트 간의 HTTP / HTTPS 쓰기 타임아웃을 구성합니다. 값은 초 단위의 정수여야 하며, 0으로 설정하면 타임아웃이 비활성화됩니다.
    자세한 내용은 Traefik 문서를 참조하십시오.
    httpIdleTimeout, httpsIdleTimeout
    ALB와 클라이언트 간의 HTTP / HTTPS 유휴 시간 제한(keepalive)을 구성합니다. 값은 초 단위의 정수여야 하며, 0으로 설정하면 타임아웃이 비활성화됩니다.
    자세한 내용은 Traefik 문서를 참조하십시오.
    IBM Cloud Internet Services (CIS) 이나 Cloudflare를 웹 애플리케이션 방화벽(WAF) 또는 글로벌 부하 분산 기능과 함께 사용하는 경우, 이 값을 900초 이상으로 설정하십시오. 자세한 내용은 ‘타임아웃 조정’을 참조하십시오.
    httpsRedirect
    모든 HTTP 로 들어오는 요청을 HTTPS 엔드포인트로 영구적으로 리디렉션하도록 설정합니다.
    기본값: false.
    customEntryPoints
    Traefik에 대한 추가 사용자 정의 진입점을 지정합니다. 엔트리포인트의 이름이 객체의 키가 됩니다. 다음 엔트리포인트 이름은 예약되어 있으므로 사용할 수 없습니다: web, websecure, traefik, hc, httphttps.
    엔트리포인트 구성이 유효하지 않은 경우, 사용자 정의 엔트리포인트는 하나도 처리되지 않습니다!
    customEntryPoints.<name>.port
    사용할 진입점의 포트. 이 필드는 필수입니다. 다른 포트와 충돌하지 않는지 확인하십시오.
    여기에 정의된 포트와 프로토콜은 로드 밸런서에서 수동으로 노출해야 합니다. 자세한 방법은 아래를 참조하십시오.
    customEntryPoints.<name>.protocol
    사용할 진입점의 프로토콜. 이 필드는 필수입니다. 유효값은 TCPUDP입니다.
    customEntryPoints.<name>.readTimeout
    ALB와 클라이언트 간의 엔트리포인트 읽기 타임아웃을 설정합니다. 값은 초 단위의 정수여야 하며, 0으로 설정하면 타임아웃이 비활성화됩니다.
    자세한 내용은 Traefik 문서를 참조하십시오.
    customEntryPoints.<name>.writeTimeout
    ALB와 클라이언트 간의 엔트리포인트 쓰기 타임아웃을 구성합니다. 값은 초 단위의 정수여야 하며, 0으로 설정하면 타임아웃이 비활성화됩니다.
    자세한 내용은 Traefik 문서를 참조하십시오.
    customEntryPoints.<name>.idleTimeout
    ALB와 클라이언트 간의 엔트리포인트 유휴 시간 제한(keepalive)을 구성합니다. 값은 초 단위의 정수여야 하며, 0으로 설정하면 타임아웃이 비활성화됩니다.
    자세한 내용은 Traefik 문서를 참조하십시오.
    customEntryPoints.<name>.udpTimeout
    UDP 리스너의 엔트리포인트 유휴 시간 제한을 설정합니다. 이 필드는 UDP 프로토콜을 사용하는 엔드포인트에 대해서만 고려됩니다. 값은 0보다 큰 정수 초 단위여야 합니다.
    자세한 내용은 Traefik 문서를 참조하십시오.
    tolerations
    ALB 포드에 대한 추가적인 사용자 지정 허용 오차를 지정합니다. 자세한 내용은 ‘테인트(Taints)및 허용치(Tolerations )’를 참조하십시오.
  3. 클러스터에서 ibm-ingress-deploy-config configmap을 작성하십시오.

    kubectl create -f ibm-ingress-deploy-config.yaml
    
  4. 변경 사항을 적용하려면 ALB를 업데이트하십시오. 변경 사항이 적용되기까지 최대 5분이 소요될 수 있습니다. 명령어가 출력 없이 종료되면, 업데이트가 성공적으로 전송된 것입니다.

    ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID
    
  5. 표준이 아닌 HTTP, HTTPS 포트를 지정했거나 추가 엔트리포인트를 생성한 경우, 각 ALB 서비스에서 해당 포트를 열어주어야 합니다.

    1. 1단계에 있는 각 ALB 서비스에 대해 YAML 파일을 편집하십시오.
        kubectl edit svc -n kube-system <alb_svc_name>
        ```
    2. `spec.ports` 섹션에서 열려는 포트를 추가하십시오. 기본적으로 포트 80 및 443이 열립니다. 80과 443을 연 상태로 두려면 이 파일에서 제거하지 마십시오. 지정되지 않은 포트는 닫힙니다. `nodePort`를 지정하지 마십시오. 포트를 추가하고 변경사항을 적용한 후 `nodePort`가 자동으로 지정됩니다.
    
    ```sh {: codeblock}
        ...
        ports:
        - name: port-80
          port: 80
          protocol: TCP
          targetPort: 80
        - name: port-443
          port: 443
          protocol: TCP
          targetPort: 443
        - name: <new_port>
          port: <port>
          protocol: TCP
          targetPort: <port>
        ...
        ```
    3. 파일을 저장한 후 닫으십시오. 변경사항은 자동으로 적용됩니다.
    
    

Ingress 클래스 사용자 정의

Ingress 클래스는 클래스 이름을 Ingress 컨트롤러 유형과 연결하여, 동일한 클러스터 내에서 여러 컨트롤러가 공존할 수 있도록 합니다. 이 IngressClass 리소스를 사용하여 ALB에 대한 사용자 정의 클래스를 정의하십시오.

Traefik은 .spec.controller traefik.io/ingress-controller``로 설정된 Ingress 클래스만 처리합니다.

앱에 App ID 인증 추가

Ingress ALB와 연동하여 IBM Cloud App ID Ingress ALB와 연동하여 인증 설정이 완료되면, ALB는 OAuth2-Proxy 을 통해 요청을 전달하며, 이 서버는 App ID 을 통해 자격 증명을 검증한 후 트래픽을 앱으로 전달합니다.

  1. 새 App ID 인스턴스를 작성하거나 기존 인스턴스를 선택하십시오.

    클러스터의 하나의 네임스페이스에서만 App ID 인스턴스를 사용할 수 있습니다. 여러 네임스페이스에서 Ingress 리소스에 대한 App ID를 구성하려는 경우, 이 섹션의 단계를 반복하여 각 네임스페이스의 Ingress 리소스에 대한 고유 App ID 인스턴스를 지정하십시오.

    • 기존 인스턴스를 사용하려면, 서비스 인스턴스 이름에 소문자 및 영숫자만 포함되어 있고 길이가 25자를 초과하지 않는지 확인하십시오. 이름을 변경하려면 서비스 인스턴스 세부사항 페이지의 추가 옵션 메뉴에서 서비스 이름 바꾸기를 선택하십시오.
    • 새 App ID 인스턴스를 프로비저닝하려면 다음을 수행하십시오.
      1. 서비스 이름을 서비스 인스턴스의 고유한 이름으로 바꾸십시오. 서비스 인스턴스 이름에는 소문자와 숫자만 포함되어야 하며, 길이는 25자 이내여야 합니다.
      2. 클러스터가 배치된 동일 지역을 선택하십시오.
      3. 작성을 클릭하십시오.
  2. 앱에 대한 경로 재지정 URL을 추가하십시오. 경로 재지정 URL은 앱의 콜백 엔드포인트입니다. 피싱 공격 방지를 위해 IBM Cloud App ID는 경로 재지정 URL의 허용 목록에 대해 요청 URL의 유효성을 검증합니다.

    1. App ID 관리 콘솔에서 인증 관리로 이동하십시오.
    2. ID 제공자 탭에서 ID 제공자가 선택되었는지 확인하십시오. 신원 제공자가 선택되지 않은 경우, 인증은 이루어지지 않지만 앱에 익명으로 액세스할 수 있는 액세스 토큰이 발급됩니다.
    3. 인증 설정 탭에서 앱의 경로 재지정 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 목록에 포함시켜 주십시오. 사용자 지정 로그아웃 페이지를 사용하려면 OAuth2-Proxy ConfigMap 에서 whitelist_domains 를 설정하십시오. rd 쿼리 매개변수를 사용하여 https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out 엔드포인트를 호출하거나, 사용자 지정 로그아웃 페이지 URL 를 지정하여 X-Auth-Request-Redirect 헤더를 설정하십시오. 자세한 내용은 ‘로그아웃’을 참조하세요.

  3. 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]
    

    서비스가 클러스터에 성공적으로 바인딩되면, 해당 서비스 인스턴스의 자격 증명을 포함하는 클러스터 시크릿이 생성됩니다. 다음 예제에서는 출력을 보여줍니다.

    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>
    
  4. 클러스터에서 ALB OAuth Proxy 추가 기능을 사용으로 설정하십시오. 이 애드온은 다음과 같은 Kubernetes 리소스를 생성하고 관리합니다. App ID 서비스 인스턴스를 위한 OAuth2-Proxy 배포, OAuth2-Proxy 구성을 포함하는 시크릿, 그리고 들어오는 요청을 OAuth2-Proxy 배포로 라우팅하는 Ingress 리소스입니다. 각 리소스의 이름은 oauth2- 로 시작합니다.

    1. alb-oauth-proxy 추가 기능을 사용으로 설정하십시오.
        ibmcloud ks cluster addon enable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID
        ```
    2. ALB OAuth 프록시 추가 기능에 `Addon Ready` 상태가 있는지 확인하십시오. 상태가 “ `Enabling` ”로 표시되면 몇 분 정도 기다린 후 명령을 다시 실행하십시오.
    ```sh {: pre}
        ibmcloud ks cluster addon ls --cluster CLUSTER_NAME_OR_ID
        ```
    
  5. App ID 인증을 추가하려는 앱의 Ingress 리소스에서, 리소스 이름이 25자를 초과하지 않도록 주의하십시오. 그런 다음 ‘ ForwardAuth ’ 미들웨어를 구성합니다:

    1. Traefik의 ‘ ForwardAuth ’ 미들웨어 리소스를 생성합니다. address 는 App ID 인스턴스에 대한 OAuth2-Proxy 의 URL 를 지정하며, 이 인스턴스는 OIDC 신뢰 당사자(RP) 역할을 수행합니다. 서비스 인스턴스 이름에 포함된 모든 문자는 소문자여야 합니다.
        apiVersion: traefik.io/v1alpha1
        kind: Middleware
        metadata:
          name: oauth-verify
          namespace: default
        spec:
          forwardAuth:
            address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
            tls:
              insecureSkipVerify: true
        ```
        기본적으로 Traefik은 TLS  IP 대상 대체 이름(SAN)을 검증합니다. IBM -제공된 인증서는  유효성 검사에서 실패할 것으로 예상되므로, ` `insecureSkipVerify: true` ` 옵션을 사용하십시오.  설정을 통해 Traefik 인스턴스 또는 ALB가 `oauth2-proxy` 배포 인스턴스와 통신할  있게 됩니다.
        {: note}
    
    2. `Authorization` 헤더에서 앱에 보낼 토큰을 선택하십시오. ID  액세스 토큰에 대한 자세한 내용은 [ App ID  문서를](/docs/appid?topic=appid-tokens) 참조하십시오.
        * `ID Token`  전송하려면, ForwardAuth 미들웨어에 `authResponseHeaders` 옵션을 추가하십시오:
    
            ```yaml {: codeblock}
            apiVersion: traefik.io/v1alpha1
            kind: Middleware
            metadata:
              name: oauth-verify
              namespace: default
            spec:
              forwardAuth:
                address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
                authResponseHeaders:
                  - Authorization
                tls:
                  insecureSkipVerify: true
            ```
        * `Access Token`  전송하려면, ForwardAuth 미들웨어에 `authResponseHeaders` 옵션을 추가하십시오:
    
            ```yaml {: codeblock}
            apiVersion: traefik.io/v1alpha1
            kind: Middleware
            metadata:
              name: oauth-verify
              namespace: default
            spec:
              forwardAuth:
                address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
                authResponseHeaders:
                  - X-Auth-Request-Access-Token
                tls:
                  insecureSkipVerify: true
            ```
        * `Access Token`  `ID Token`  모두 전송하려면, ForwardAuth 미들웨어에 `authResponseHeaders` 옵션을 추가하십시오:
    
            ```yaml {: codeblock}
            apiVersion: traefik.io/v1alpha1
            kind: Middleware
            metadata:
              name: oauth-verify
              namespace: default
            spec:
              forwardAuth:
                address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
                authResponseHeaders:
                  - X-Auth-Request-Access-Token
                  - Authorization
                tls:
                  insecureSkipVerify: true
            ```
    3. 선택 사항: 앱이 [API 전략](/docs/appid?topic=appid-key-concepts#term-api-strategy) 외에도 또는 대신 [  전략](/docs/appid?topic=appid-key-concepts#term-web-strategy)  지원하는 경우, ForwardAuth 미들웨어에 `authSigninURL`  추가하십시오. 서비스 인스턴스 이름에 포함된 모든 문자는 소문자여야 합니다.
    
    ```yaml {: codeblock}
        apiVersion: traefik.io/v1alpha1
        kind: Middleware
        metadata:
          name: oauth-verify
          namespace: default
        spec:
          forwardAuth:
            address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
            authResponseHeaders:
              - X-Auth-Request-Access-Token
              - Authorization
            authSigninURL: /oauth2-<App_ID_service_instance_name>/sign_in?rd={url}
            tls:
              insecureSkipVerify: true
        ```
        * `authSigninURL`  지정했을  클라이언트의 인증이 실패하면, 클라이언트는 OAuth2-Proxy 으로 리디렉션되며,  페이지에서 다시 App ID 로그인 페이지로 리디렉션됩니다.
        * `authSigninURL`  지정하지 않을 경우, 클라이언트는 유효한 베어러 토큰을 사용하여 인증해야 합니다. 인증에 실패하면, 요청은  `401 Unauthorized`  오류와 함께 거부됩니다.
    
    
  6. 선택 사항: 설정에 필요한 경우, 앱의 Service 리소스로 전달되는 요청에 대해 Traefik ServersTransport 리소스를 생성하여 앱의 Service 리소스로 전달되는 요청에 대한 TLS 인증을 건너뛸 수 있습니다.

    # Example (Kubernetes ServersTransport)
    apiVersion: traefik.io/v1alpha1
    kind: ServersTransport
    metadata:
      name: skip-tls-verify
    spec:
      insecureSkipVerify: true
    

    Traefik Service 어노테이션을 사용하여 Service 리소스에 ServersTransport 를 적용하세요.

  7. 생성한 ‘ ForwardAuth ’ 미들웨어를 적용하여 App ID 인증을 강제 적용하도록 Ingress 리소스를 편집하세요. 다음 Traefik Ingress 어노테이션을 사용하십시오.

    traefik.ingress.kubernetes.io/router.middlewares: "default-oauth-verify@kubernetescrd"
    

    적절한 어노테이션이 적용된 Ingress 리소스가 재적용되면, ALB OAuth 프록시 애드온은 oauth2-proxy 배포를 배포하고, 해당 배포에 대한 서비스를 생성하며, oauth2-proxy 배포에 대한 라우팅을 구성하기 위해 별도의 Ingress 리소스를 생성합니다. 이러한 추가 기능 리소스를 삭제하지 마십시오.

  8. App ID 어노테이션이 사용자의 앱에 맞게 적용되었는지 확인하십시오.

    • 앱이 웹 앱 전략을 지원하는 경우: 웹 브라우저에서 앱의 URL 에 접속하세요. App ID가 올바르게 적용되면 App ID 인증 로그인 페이지로 경로 재지정됩니다.
    • 앱이 API 전략을 지원하는 경우: 앱으로 보내는 요청의 Authorization 헤더에 Bearer 액세스 토큰을 명시하십시오. 액세스 토큰을 가져오려면 App ID 문서를 참조하십시오. App ID가 올바르게 적용되면 요청이 인증되고 앱으로 라우트됩니다. Authorization 헤더에 액세스 토큰을 포함하지 않고 앱에 요청을 보내거나, App ID 에서 액세스 토큰을 인정하지 않는 경우, 해당 요청은 거부됩니다.
  9. 선택 사항: 클러스터에서 네트워크 정책이나 다른 방화벽 솔루션을 사용하여 발신 트래픽을 제한하는 경우, 클러스터에서 공용 App ID 서비스에 액세스할 수 있는지 확인하십시오. 이 서비스의 IP 주소 범위를 확인하려면 고객 지원팀을 통해 요청을 제출해 주십시오.

  10. 선택사항: Kubernetes ConfigMap을 작성하여 OAuth2-Proxy의 기본 동작을 사용자 정의할 수 있습니다.

    1. 변경할 OAuth2-Proxy 설정에 대한 값을 지정하는 ConfigMap 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 back-end app via the X-Forwarded-Access-Token header.
          request_logging: <true|false>
          # Log all requests to the back-end 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 as when using the Traefik ForwardAuth Middleware.
          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 Traefik ForwardAuth Middleware.
          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
        ```
    2. 추가 기능에 ConfigMap 리소스를 적용하십시오. 변경사항은 자동으로 적용됩니다.
    ```sh {: pre}
        kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
        ```
    

각 ALB OAuth 프록시 애드온 버전의 변경 사항 목록은 IBM Cloud ALB OAuth 프록시 애드온 변경 내역을 참조하십시오.

ALB OAuth 프록시 애드온 업그레이드

ALB OAuth 프록시 애드온을 최신 버전으로 업그레이드하려면, 현재 설치된 애드온을 비활성화한 다음 원하는 버전의 애드온을 다시 활성화하십시오. 업그레이드 중에도 기존 oauth2-proxy 인스턴스의 운영은 중단되지 않습니다.

애드온이 비활성화된 상태에서도 감독형 oauth2-proxy 인스턴스가 클러스터에 그대로 유지되므로, 업그레이드 과정은 서비스 중단 없이 진행됩니다.

  1. 추가 기능을 사용 안함으로 설정하십시오.
    ibmcloud ks cluster addon disable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID
    
  2. 사용 가능한 애드온 버전을 나열하고, 사용하고자 하는 버전을 기록해 두십시오. 출력 결과에는 사용 가능한 버전과 기본 버전이 표시됩니다.
    ibmcloud ks cluster addon versions --addon alb-oauth-proxy
    
  3. 추가 기능을 사용으로 설정하고 --version 옵션을 지정하십시오. 버전을 지정하지 않으면 기본 버전이 사용으로 설정됩니다.
    ibmcloud ks cluster addon enable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID [--version VERSION]
    

소스 IP 주소 유지

기본적으로 Ingress ALB는 클라이언트 요청의 원래 소스 IP 주소를 유지하지 않습니다. 이로 인해 IP 기반 접근 제어, 로그 기록 및 보안 정책이 제대로 작동하지 않을 수 있습니다. 소스 IP 보존 기능을 활성화하려면 클러스터 유형에 해당하는 방법을 선택하십시오.

VPC 클러스터에서 PROXY 프로토콜 사용

PROXY 프로토콜은 원본 클라이언트 IP 주소를 로드 밸런서 계층을 거쳐 ALB로 전달합니다.

PROXY 프로토콜을 활성화하면 로드 밸런서가 다시 생성되므로, 이로 인해 잠시 서비스가 중단될 수 있습니다. 재생성 시 각 서브넷마다 로드 밸런서당 사용되지 않은 IP 주소 두 개가 확보되어 있어야 합니다.

  1. 프록시 프로토콜을 사용으로 설정하십시오. 명령어 매개변수에 대한 자세한 내용은 CLI 참조 문서를 참조하십시오.

    ibmcloud ks ingress lb proxy-protocol enable --cluster CLUSTER_NAME_OR_ID --cidr SUBNET_CIDR
    
  2. 클러스터에서 ALB를 노출하는 로드 밸런서에 프록시 프로토콜이 사용되는지 확인하십시오. 출력 결과에서 ‘ Proxy Protocol ’ 필드에 ‘ Enabled ’이 표시되는지 확인하십시오.

    ibmcloud ks ingress lb get --cluster CLUSTER_NAME_OR_ID
    
  3. 나중에 PROXY 프로토콜을 비활성화하려면 다음 명령을 실행하십시오:

    ibmcloud ks ingress lb proxy-protocol disable --cluster CLUSTER_NAME_OR_ID
    

클래식 클러스터의 externalTrafficPolicy 변경

클래식 클러스터의 경우, ALB를 노출하는 로드 밸런서 서비스에서 externalTrafficPolicy Local 으로 설정하십시오. 이를 통해 로드 밸런서가 트래픽을 전달할 때 클라이언트 소스 IP를 워커 노드 IP로 대체하는 것을 방지합니다.

기본적으로, 클라이언트 요청의 소스 IP 주소는 유지되지 않습니다. 클라이언트 요청이 클러스터에 도달하면, ALB를 노출하는 로드 밸런서 서비스의 파드로 라우팅됩니다. 앱 팟(Pod)이 로드 밸런서 서비스 팟(Pod)과 동일한 작업자 노드에 없는 경우 로드 밸런서는 다른 작업자 노드의 앱 팟(Pod)으로 요청을 전달합니다. 앱 포드가 실행되는 워커 노드는 패킷의 소스 IP 주소를 해당 노드의 공용 IP 주소로 변경합니다.

클라이언트 요청의 원래 소스 IP 주소를 보존하려면 소스 IP 보존 기능을 활성화할 수 있습니다. 예를 들어, 애플리케이션 서버가 보안 및 접근 제어 정책을 적용해야 할 때 클라이언트의 IP를 보존하는 것이 유용합니다.

소스 IP 보존 기능이 활성화되면, 로드 밸런서는 트래픽을 다른 워커 노드의 ALB 포드로 전달하던 방식에서 동일한 워커 노드의 ALB 포드로 전달하는 방식으로 전환됩니다. 변경하는 중에 앱이 작동 중단될 수 있습니다. ALB를 비활성화하면, 해당 ALB를 노출하는 로드 밸런서 서비스에 적용한 소스 IP 변경 사항이 모두 사라집니다. ALB를 다시 사용하도록 설정하는 경우에는 소스 IP를 다시 사용하도록 설정해야 합니다.

기존 클러스터의 경우, ALB 복제본 수를 2개 이상으로 늘리면 복제본 수가 증가하지만, externalTrafficPolicy Local``로 설정되어 있으면 2개를 초과하는 복제본은 사용되지 않습니다. 클러스터에는 액티브-패시브 구성으로 설정된 로드 밸런서 포드가 단 두 개만 존재하며, 이러한 트래픽 정책으로 인해 들어오는 트래픽을 동일한 노드에 있는 ALB 포드로만 전달합니다.

소스 IP 유지를 사용하려면 Ingress ALB를 노출하는 로드 밸런서 서비스를 편집하십시오.

  1. 클러스터의 모든 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
        ```
        출력 예:
    
        ```sh {: screen}
        "public-cr18e61e63c6e94b658596ca93d087eed9-alb1", "public-cr17e61e63c6e94b658596ca92d087eed9-alb2" patched
        ```
    * 클러스터의 모든 사설 ALB에 대해 소스 IP 유지를 설정하려면 다음을 명령을 실행하십시오.
    ```sh {: pre}
        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
        ```
        출력 예:
    
        ```sh {: screen}
        "private-cr18e61e63c6e94b658596ca93d087eed9-alb1", "private-cr17e61e63c6e94b658596ca92d087eed9-alb2" patched
        ```
    
  2. ALB 포드 로그에 소스 IP가 그대로 기록되어 있는지 확인하십시오.

    1. 수정하신 ALB에 해당하는 Pod의 이름을 확인하세요. 수정하신 ALB ID로 시작하는 포드 이름을 찾으세요(예: public-cr<hash>-alb1-<suffix>).
        kubectl get pods -n kube-system | grep alb
        ```
    2. 해당 ALB 팟(Pod)의 로그를 여십시오. `client` 필드의 IP 주소가 로드 밸런서 서비스의 IP 주소가 아닌, 원래 클라이언트 요청의 IP 주소인지 확인하십시오.
    ```sh {: pre}
        kubectl logs <ALB_pod_ID> traefik -n kube-system
        ```
    
  3. 백엔드 앱으로 전송되는 요청의 x-forwarded-for 헤더에 클라이언트 IP 주소가 포함되어 있는지 확인하십시오. 앱 로그를 확인하거나 앱에서 수신되는 요청 헤더를 검토하여 이를 확인할 수 있습니다.

  4. 선택 사항: 더 이상 소스 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 유지를 되돌리려면 다음을 실행하십시오.
    ```sh {: pre}
        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
        ```
    

TLS 프로토콜 및 암호 방식 구성

TLSOption 리소스를 사용하여 ALB로 유입되는 트래픽에 대해 최소 TLS 버전을 적용하고, 암호 모음을 제한하며, 기타 TLS 연결 매개변수를 구성할 수 있습니다. TLSOption 리소스를 생성한 후, Traefik Ingress 어노테이션을 사용하여 해당 리소스를 Ingress 리소스에 적용하세요.

사용자 정의 인증서를 레거시 클라이언트에 보내기

서버 이름 표시(SNI)를 지원하지 않는 구형 디바이스는 어떤 TLS 인증서를 사용할지 협상할 수 없기 때문에, 사용자 지정 인증서 대신 ALB의 기본 Let's Encrypt 인증서를 수신하게 됩니다. 이러한 디바이스가 사용자 지정 인증서를 수신할 수 있도록 하려면, ALB의 기본 서버 설정을 업데이트하여 사용자 지정 TLS 시크릿을 가리키도록 설정하십시오.

기본적으로 생성되는 Let's Encrypt 인증서는 프로덕션 용도가 아닙니다. 프로덕션 워크로드의 경우 고유한 사용자 정의 인증서를 가져오십시오.

클래식 클러스터를 생성하면, IBM 에서 기본 Ingress 시크릿에 대한 Let's Encrypt 인증서를 제공합니다. 사용자 정의 시크릿을 생성하고 Ingress 리소스에서 ‘ TLS ’ 종료를 위해 이를 지정하면, ALB는 Let's Encrypt 인증서 대신 사용자 정의 인증서를 클라이언트에 전송합니다. 그러나 클라이언트가 SNI를 지원하지 않는 경우, ALB의 기본 서버 설정에 기본 시크릿이 지정되어 있으므로 ALB는 기본적으로 Let's Encrypt 인증서를 사용합니다. SNI를 지원하지 않는 기기에 사용자 지정 인증서를 전송하려면 다음 단계를 따르십시오.

  1. alb-default-server Ingress 리소스를 편집하십시오.

    kubectl edit ingress alb-default-server -n kube-system
    
  2. spec.tls 섹션에서 hosts.secretName 설정값을 사용자 정의 인증서를 포함하고 있는 사용자 정의 시크릿의 이름으로 변경하십시오.

    spec:
      rules:
      ...
      tls:
      - hosts:
        - invalid.mycluster-<hash>-0000.us-south.containers.appdomain.cloud
        secretName: <custom_secret_name>
    
  3. 리소스 파일을 저장하십시오.

  4. 이제 리소스가 사용자 정의 시크릿 이름을 가리키는지 확인하십시오. 변경사항은 ALB에 자동으로 적용됩니다. 출력 결과에서 spec.tls[].secretName 가 사용자 정의 시크릿 이름과 일치하는지 확인하십시오.

    kubectl get ingress alb-default-server -n kube-system -o yaml
    

ALB 성능 튜닝

워커 노드는 대부분의 워크로드에 적합한 최적화된 커널 튜닝 설정으로 자동으로 프로비저닝됩니다. 클러스터에 특정 고처리량 또는 저지연 요구 사항이 있는 경우, 워커 노드에서 Linux 커널 sysctl 매개변수를 조정하여 ALB 성능을 더욱 최적화할 수 있습니다. 명확한 성능 최적화 요구 사항이 있는 경우에만 이 설정을 변경하십시오. 잘못된 값을 설정하면 노드의 안정성이 저하될 수 있습니다.

다음 단계