13.2. 라우팅 최적화

OpenShift Container Platform Ingress Controller 또는 라우터는 경로와 Ingress를 사용하여 구성된 애플리케이션과 서비스에 대한 Ingress 트래픽의 Ingress 지점입니다.

초당 처리된 HTTP 요청 측면에서 단일 HAProxy 라우터 성능을 평가할 때 성능은 여러 요인에 따라 달라집니다. 특히 중요한 요인은 다음과 같습니다.

특정 환경의 성능은 달라질 수 있으나 Red Hat 랩은 크기가 4 vCPU/16GB RAM인 퍼블릭 클라우드 인스턴스에서 테스트합니다. 1kB 정적 페이지를 제공하는 백엔드에서 종료한 100개의 경로를 처리하는 단일 HAProxy 라우터가 처리할 수 있는 초당 트랜잭션 수는 다음과 같습니다.

HTTP 연결 유지 모드 시나리오에서는 다음과 같습니다.

HTTP 닫기(연결 유지 제외) 시나리오에서는 다음과 같습니다.

기본 Ingress Controller 구성은 spec.tuningOptions.threadCount 필드를 4 로 설정하여 사용되었습니다. 두 가지 다른 엔드포인트 게시 전략(로드 밸런서 서비스 및 호스트 네트워크)이 테스트되었습니다. 암호화된 경로에는 TLS 세션 재개가 사용되었습니다. HTTP keep-alive를 사용하면 단일 HAProxy 라우터가 8kB만큼 작은 페이지 크기에서 1Gbit NIC를 포화시킬 수 있습니다.

최신 프로세서가 있는 베어 메탈에서 실행하는 경우 성능이 위 퍼블릭 클라우드 인스턴스의 약 2배가 될 것을 예상할 수 있습니다. 이 오버헤드는 퍼블릭 클라우드에서 가상화 계층에 의해 도입되며 프라이빗 클라우드 기반 가상화에도 적용됩니다. 다음 표는 라우터 뒤에서 사용할 애플리케이션 수에 대한 가이드입니다.

일반적으로 HAProxy는 사용되는 기술에 따라 최대 1000개의 애플리케이션에 대한 경로를 지원할 수 있습니다. Ingress 컨트롤러 성능은 언어 또는 정적 콘텐츠 대비 동적 콘텐츠 등 지원하는 애플리케이션의 기능과 성능에 따라 제한될 수 있습니다.

Ingress 또는 라우터 샤딩을 사용하여 애플리케이션에 대한 경로를 더 많이 제공하면 라우팅 계층을 수평으로 확장하는 데 도움이 됩니다.

Ingress 샤딩에 대한 자세한 내용은 경로 레이블을 사용하여 Ingress 컨트롤러 샤딩 구성 및 네임스페이스 레이블을 사용하여 Ingress 컨트롤러 샤딩 구성을 참조하세요.

Ingress Controller 사양의 스레드에 대한 Ingress Controller 스레드 수 설정 및 시간 초과에 대한 Ingress Controller 구성 매개변수 , 기타 튜닝 구성에 제공된 정보를 사용하여 Ingress Controller 배포를 수정할 수 있습니다.

클러스터 관리자는 OpenShift Container Platform Ingress Controller(라우터)에서 관리하는 라우터 배포에 대한 kubelet의 활성 상태, 준비 상태 및 시작 프로브에 대한 시간 초과 값을 구성할 수 있습니다. 라우터의 활성 및 준비 프로브는 기본 시간 초과 값인 1초를 사용하는데, 이는 네트워킹이나 런타임 성능이 심각하게 저하될 때 너무 짧습니다. 프로브 시간 초과로 인해 원치 않는 라우터 재시작이 발생하여 애플리케이션 연결이 중단될 수 있습니다. 더 큰 시간 초과 값을 설정할 수 있는 기능은 불필요하고 원치 않는 재시작 위험을 줄일 수 있습니다.

라우터 컨테이너의 livenessProbe , readinessProbe 및 startupProbe 매개변수에서 timeoutSeconds 값을 업데이트할 수 있습니다.

다음 예제에서는 기본 라우터 배포에 직접 패치를 적용하여 활성 및 준비 프로브에 대한 5초 시간 초과를 설정하는 방법을 보여줍니다.

oc -n openshift-ingress patch deploy/router-default --type=strategic --patch='{"spec":{"template":{"spec":{"containers":[{"name":"router","livenessProbe":{"timeoutSeconds":5},"readinessProbe":{"timeoutSeconds":5}}]}}}}'

$ oc -n openshift-ingress patch deploy/router-default --type=strategic --patch='{"spec":{"template":{"spec":{"containers":[{"name":"router","livenessProbe":{"timeoutSeconds":5},"readinessProbe":{"timeoutSeconds":5}}]}}}}'

oc -n openshift-ingress describe deploy/router-default | grep -e Liveness: -e Readiness:

$ oc -n openshift-ingress describe deploy/router-default | grep -e Liveness: -e Readiness:
    Liveness:   http-get http://:1936/healthz delay=0s timeout=5s period=10s #success=1 #failure=3
    Readiness:  http-get http://:1936/healthz/ready delay=0s timeout=5s period=10s #success=1 #failure=3

경로 또는 경로와 연관된 엔드포인트를 업데이트하면 OpenShift Container Platform 라우터가 HAProxy에 대한 구성을 업데이트합니다. 그런 다음 HAProxy는 업데이트된 구성을 다시 로드하여 변경 사항을 적용합니다. HAProxy가 다시 로드되면 업데이트된 구성을 사용하여 새 연결을 처리하는 새 프로세스가 생성됩니다.

HAProxy는 모든 연결이 닫힐 때까지 기존 연결을 처리하기 위해 이전 프로세스를 계속 실행합니다. 오래된 프로세스에 오랫동안 연결이 유지되는 경우 해당 프로세스가 누적되어 리소스를 소모할 수 있습니다.

기본 최소 HAProxy 재로드 간격은 5초입니다. spec.tuningOptions.reloadInterval 필드를 사용하여 Ingress Controller를 구성하면 최소 재로드 간격을 더 길게 설정할 수 있습니다.