리소스 사용

리소스 요청

우리의 모든 컨테이너에는 미리 정의된 리소스 요청값이 포함되어 있습니다. 기본적으로 리소스 제한을 설정하지 않았습니다. 노드에 여분의 메모리 용량이 없는 경우 옵션 중 하나는 메모리 제한을 적용하는 것입니다만, 메모리를 추가하는 것(또는 노드를 추가하는 것)이 바람직할 것입니다. (쿠버네티스 노드에서 메모리가 부족하게 되는 것은 피해야 합니다. 왜냐하면 리눅스 커널의 메모리 부족 관리자 가 필수적인 Kube 프로세스를 종료시킬 수 있기 때문입니다.)

우리의 기본 요청값을 결정하기 위해 응용 프로그램을 실행하고, 각 서비스에 대해 여러 수준의 부하를 생성하는 방법을 고안합니다. 우리는 서비스를 모니터링하고 가장 적합한 기본값을 결정합니다.

우리는 다음을 측정할 것입니다:

  • 유휴 부하 - 기본값은 이러한 값보다 낮으면 안 되지만, 유휴 프로세스는 유용하지 않으므로 일반적으로 우리는 이 값을 기준으로 기본값을 설정하지 않을 것입니다.

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

  • 평균 부하 - 평균이 무엇으로 간주되는지는 설치에 따라 매우 의존적입니다 우리의 기본값에서는 몇 가지 수준에서 몇 가지 측정을 시도하겠습니다. (우리는 사용된 부하를 나열할 것입니다). 만약 서비스에 팟 오토스케일러가 있다면, 일반적으로 우리는 이를 기준으로 확장 대상 값을 설정하려고 할 것이고 이것은 또한 기본 메모리 요청입니다.

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

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

GitLab Shell

부하는 일부 병렬 작업을 수행하는 nohup git clone <프로젝트> <임의의 경로이름>을 호출하는 bash 루프를 사용하여 테스트되었습니다. 후속 테스트에서는 기타 서비스에 대해 수행한 테스트 유형과 더 일치하도록 지속적인 병렬 부하를 포함하려고 할 것입니다.

  • 유휴 값
    • 0 작업, 2 pods
      • CPU: 0
      • 메모리: 5M
  • 최소 부하
    • 1 작업 (빈 클론 하나), 2 pods
      • CPU: 0
      • 메모리: 5M
  • 평균 부하
    • 5개 동시 복제, 2 pods
      • CPU: 100m
      • 메모리: 5M
    • 20 개 동시 복제, 2 pods
      • CPU: 80m
      • 메모리: 6M
  • 스트레스 테스트
    • 리눅스 커널을 SSH 복제 (17MB/s)
      • CPU: 280m
      • 메모리: 17M
    • 리눅스 커널을 SSH 푸시 (2MB/s)
      • CPU: 140m
      • 메모리: 13M
      • 업로드 연결 속도가 테스트 중에 아마도 영향을 미친 것으로 예상됩니다
  • 무거운 부하
    • 100개 동시 복제, 4 pods
      • CPU: 110m
      • 메모리: 7M
  • 기본 요청
    • CPU: 0 (최소 부하에서)
    • 메모리: 6M (평균 부하에서)
    • 대상 CPU 평균: 100m (평균 부하에서)
  • 권장 제한
    • CPU: > 300m (스트레스 작업보다 큼)
    • 메모리: > 20M (스트레스 작업보다 큼)

gitlab.gitlab-shell.resources.limits.memory가 너무 낮게 설정된다면 어떤 일이 일어날 수 있는지에 대한 자세한 내용은 문제 해결 문서를 확인하세요.

Webservice

Webservice 리소스는 10k 참조 아키텍처 와 함께 테스트하는 동안 분석되었습니다. 자세한 내용은 Webservice 리소스 문서에서 확인할 수 있습니다.

Sidekiq

Sidekiq 리소스는 10k 참조 아키텍처 와 함께 테스트하는 동안 분석되었습니다. 자세한 내용은 Sidekiq 리소스 문서에서 확인할 수 있습니다.

KAS

우리는 사용자들이 KAS를 다음과 같이 사용할 것으로 예상합니다.

  • 유휴 값
    • 0개 연결된 에이전트, 2 pods
      • CPU: 10m
      • 메모리: 55M
  • 최소 부하:
    • 1개 연결된 에이전트, 2 pods
      • CPU: 10m
      • 메모리: 55M
  • 평균 부하: 클러스터에 1개의 에이전트가 연결됨.
    • 5개 연결된 에이전트, 2 pods
      • CPU: 10m
      • 메모리: 65M
  • 스트레스 테스트:
    • 20개 연결된 에이전트, 2 pods
      • CPU: 30m
      • 메모리: 95M
  • 무거운 부하:
    • 50개 연결된 에이전트, 2 pods
      • CPU: 40m
      • 메모리: 150M
  • 추가 무거운 부하:
    • 200개 연결된 에이전트, 2 pods
      • CPU: 50m
      • 메모리: 315M

이 차트에 의해 설정된 KAS 리소스 기본값은 심지어 50개의 에이전트 시나리오를 처리하는 데에 충분합니다. 우리가 추가 무거운 부하로 간주하는 것에 도달하기를 계획하고 있다면, 기본값을 조정하는 것을 고려해야 할 것입니다.

  • 기본값: 각각에 대해 2 pods
    • CPU: 100m
    • 메모리: 100M

이러한 숫자가 어떻게 계산되었는지에 대한 자세한 내용은 이슈 논의를 확인하세요.