리소스 사용

리소스 요청

모든 컨테이너에는 미리 정의된 리소스 요청 값이 포함되어 있습니다. 기본적으로 리소스 제한을 설정하지 않았습니다. 노드에 여분의 메모리 용량이 없는 경우, 한 가지 옵션은 메모리 제한을 적용하는 것이지만, 더 많은 메모리(또는 노드)를 추가하는 것이 바람직합니다. (Kubernetes 노드에서 메모리가 부족해지는 것을 피하고자 하므로, 리눅스 커널의 메모리 부족 관리자가 필수 Kube 프로세스를 중단할 수 있습니다.)

기본 요청 값을 정하기 위해 애플리케이션을 실행하고, 각 서비스에 대한 다양한 수준의 부하를 생성하는 방법을 고안합니다. 서비스를 모니터링하고, 최상의 기본값에 대해 결정합니다.

다음 항목을 측정합니다:

  • 유휴 부하 - 기본값은 이 값보다 낮아서는 안되지만, 유휴 프로세스는 유용하지 않으므로 일반적으로 이 값을 기준으로 기본값을 설정하지 않습니다.

  • 최소 부하 - 가장 기본적인 유용한 작업을 수행하는 데 필요한 값입니다. 일반적으로 CPU의 경우 이 값을 기본값으로 사용하지만, 메모리 요청은 커널이 프로세스를 수거할 위험이 있으므로 메모리 기본값으로 사용하지 않도록 합니다.

  • 평균 부하 - 무엇이 평균으로 간주되는지는 설치에 따라 매우 다릅니다. 기본값을 위해 몇 가지 합리적인 부하에서 몇 가지 측정값을 시도할 것입니다. (사용된 부하를 나열할 것입니다.) 서비스에 포드 오토스케일러가 있는 경우, 일반적으로 이러한 값에 따라 스케일링 목표 값을 설정하려고 합니다. 또한 기본 메모리 요청도 설정합니다.

  • 스트레스 작업 - 서비스가 수행해야 할 가장 스트레스가 큰 작업의 사용량을 측정합니다. (부하가 없을 때는 필요하지 않음). 리소스 제한을 적용할 때는 이 값과 평균 부하 값보다 높은 값을 설정하려고 합니다.

  • 강한 부하 - 서비스에 대한 스트레스 테스트를 생각해보고, 이를 수행하는 데 필요한 리소스 사용량을 측정합니다. 이러한 값은 현재 기본값으로 사용되지 않지만, 사용자들은 평균 부하/스트레스 작업과 이 값 사이에 리소스 제한을 설정하고자 할 것입니다.

GitLab 셸

로드 테스트는 nohup git clone <project> <random-path-name>를 호출하는 bash 루프를 사용하여 일부 동시성을 확보하는 방식으로 수행되었습니다. 향후 테스트에서는 다른 서비스에 대해 수행한 테스트 유형과 더 잘 일치하도록 지속적인 동시 부하를 포함하려고 합니다.

  • 유휴 값
    • 0 작업, 2 포드
      • cpu: 0
      • memory: 5M
  • 최소 부하
    • 1 작업(빈 클론 1개), 2 포드
      • cpu: 0
      • memory: 5M
  • 평균 부하
    • 5개의 동시 클론, 2 포드
      • cpu: 100m
      • memory: 5M
    • 20개의 동시 클론, 2 포드
      • cpu: 80m
      • memory: 6M
  • 스트레스 작업
    • Linux 커널 SSH 클론 (17MB/s)
      • cpu: 280m
      • memory: 17M
    • Linux 커널 SSH 푸시 (2MB/s)
      • cpu: 140m
      • memory: 13M
      • 업로드 연결 속도가 우리의 테스트 중 중요한 요소였을 가능성이 있습니다.
  • 강한 부하
    • 100개의 동시 클론, 4 포드
      • cpu: 110m
      • memory: 7M
  • 기본 요청
    • cpu: 0 (최소 부하에서)
    • memory: 6M ( 평균 부하에서)
    • 목표 CPU 평균: 100m (평균 부하에서)
  • 추천 제한
    • cpu: > 300m (스트레스 작업보다 큼)
    • memory: > 20M (스트레스 작업보다 큼)

gitlab.gitlab-shell.resources.limits.memory가 너무 낮게 설정된 경우 발생할 수 있는 문제에 대한 자세한 내용은 문제 해결 문서를 확인하세요.

웹서비스

웹서비스 리소스는 10k 참조 아키텍처로 테스트하는 동안 분석되었습니다.

노트는 웹서비스 리소스 문서에서 확인할 수 있습니다.

사이드키크

사이드키크 리소스는 10k 참조 아키텍처로 테스트하는 동안 분석되었습니다.

노트는 사이드키크 리소스 문서에서 확인할 수 있습니다.

KAS

사용자의 요구에 대해 더 많이 알게 될 때까지, 우리는 우리 사용자가 KAS를 다음과 같이 사용할 것으로 예상합니다.

  • Idle values

    • 0 agents connected, 2 pods
      • cpu: 10m
      • memory: 55M

  • Minimal Load:

    • 1 agents connected, 2 pods
      • cpu: 10m
      • memory: 55M

  • Average Load: 1 agent가 클러스터에 연결됨.

    • 5 agents connected, 2 pods
      • cpu: 10m
      • memory: 65M

  • Stressful Task:

    • 20 agents connected, 2 pods
      • cpu: 30m
      • memory: 95M

  • Heavy Load:

    • 50 agents connected, 2 pods
      • cpu: 40m
      • memory: 150M

  • Extra Heavy Load:

    • 200 agents connected, 2 pods
      • cpu: 50m
      • memory: 315M

이 차트에 의해 설정된 KAS 리소스 기본값은 50 agents 시나리오를 처리하기에 충분합니다.

우리가 Extra Heavy Load라고 하는 상태에 도달할 계획이라면, 기본값을 조정하여 확장하는 것을 고려해야 합니다.

  • Defaults: 2 pods, each with

    • cpu: 100m

    • memory: 100M

이 숫자들이 어떻게 계산되었는지에 대한 더 많은 정보는 문제 논의를 참조하세요.