3장. 호스트 관련 권장 사례

Pod 트래픽 외에도 OpenShift Container Platform 인프라에서 가장 많이 사용되는 데이터 경로도 OpenShift Container Platform 마스터 호스트와 etcd 사이입니다. OpenShift Container Platform API 서버(마스터 바이너리의 일부)는 etcd에서 노드 상태, 네트워크 구성, 시크릿 등을 참조합니다.

다음을 통해 이 트래픽 경로를 최적화합니다.

OpenShift Container Platform 마스터는 CPU 로드를 쉽게하기 위해 적극적으로 리소스의 역직렬화 버전을 캐시합니다. 그러나 Pod가 1,000개 미만인 소규모 클러스터에서 이 캐시는 상당한 CPU 부하 감소를 위해 많은 메모리를 낭비할 수 있습니다. 기본 캐시 크기는 50,000개 항목이며, 리소스 크기에 따라 1~2GB의 메모리를 차지하도록 증가할 수 있습니다. 이 캐시 크기는 /etc/origin/master/master-config.yaml 에서 다음 설정을 사용하여 줄일 수 있습니다.

kubernetesMasterConfig:
  apiServerArguments:
    deserialization-cache-size:
    - "1000"

API 서버로 전송되는 클라이언트 요청 또는 API 호출 수는 QPS(Queries per second) 값에 따라 결정되며 API 서버에서 처리할 수 있는 동시 요청 수는 maxRequestsInFlight 설정에 따라 결정됩니다. 클라이언트가 QPS 수치를 초과할 수 있는 요청 수는 버스트 값에 따라 달라지며, 이는 자연에서 버스트(bursty)되는 애플리케이션에 도움이 되며, 이는 불규칙한 요청 수를 생성할 수 있습니다. 요청에 대한 응답 시간은 특히 대규모 및/또는 밀도가 높은 클러스터의 경우 API 서버에서 많은 동시 요청을 처리하는 경우 대기 시간이 높을 수 있습니다. Prometheus에서 apiserver_request_count 속도 메트릭을 모니터링하고 maxRequestsInFlight 및 QPS 를 적절하게 조정하는 것이 좋습니다.

API 서버의 CPU 및 메모리 사용량을 변경할 때 기본값을 변경할 때는 더 많은 요청을 동시에 처리할 때 etcd IOPS가 증가합니다. 또한 고정 60초 제한 시간이 지나면 API 서버가 취소되고 클라이언트가 재시도를 시작할 때 API 서버에 과부하가 발생할 수도 있습니다.

API 서버 시스템에서 충분한 CPU 및 메모리 리소스를 사용할 수 있는 경우 위에서 언급한 요인을 고려하여 API 서버 요청 과부하 문제를 안전하게 완화할 수 있으며 *_/etc/origin/master/master-config.yaml의 maxRequestsInFlight, API qps 및 burst 값을 사용하여 문제를 해결할 수 있습니다.

masterClients:
  openshiftLoopbackClientConnectionOverrides:
    burst: 600
    qps: 300
servingInfo:
  maxRequestsInFlight: 500