노드 시스템 구성 맞춤설정

표준

이 문서에서는 노드 시스템 구성이라는 구성 파일을 사용하여 Google Kubernetes Engine (GKE) 노드 구성을 맞춤설정하는 방법을 보여줍니다.

노드 시스템 구성은 시스템 설정의 제한된 집합을 조정하는 방법을 제공하는 구성 파일입니다. 노드 풀에서 노드 시스템 구성을 사용하여 kubelet Kubernetes 노드 에이전트 및 sysctl 하위 수준 Linux 커널 구성의 커스텀 설정을 지정할 수 있습니다.

주의: kubelet 또는 sysctl 설정을 변경하면 워크로드 및 노드 상태에 부정적인 영향을 줄 수 있는 의도치 않은 동작이 발생할 수 있습니다. kubelet 또는 sysctl 변경사항을 프로덕션 워크로드에 배포하기 전에 광범위하게 테스트하세요.

이 문서에서는 노드 시스템 구성에 사용할 수 있는 구성과 이를 GKE Standard 노드 풀에 적용하는 방법을 자세히 설명합니다. GKE Autopilot 클러스터는 관리형 노드 환경이 더 많으므로 직접 노드 시스템 구성 옵션이 GKE Standard 노드 풀에 비해 제한적입니다.

노드 시스템 구성을 사용하는 이유

노드 시스템 구성은 다음과 같은 이점을 제공합니다.

• 성능 조정: AI 학습 또는 서빙, 데이터베이스, 트래픽이 많은 웹 서버, 지연 시간에 민감한 서비스와 같은 까다로운 애플리케이션을 위해 네트워크 스택 성능, 메모리 관리, CPU 일정, I/O 동작을 최적화합니다.
• 보안 강화: 특정 커널 수준 보안 설정을 적용하거나 특정 시스템 동작을 제한하여 공격 표면을 줄입니다.
• 리소스 관리: kubelet가 PID, 디스크 공간, 이미지 가비지 컬렉션 또는 CPU 및 메모리 리소스를 관리하는 방식을 미세 조정합니다.
• 워크로드 호환성: 노드 환경이 특정 커널 설정이 필요한 전문 소프트웨어 또는 이전 애플리케이션의 특정 필수 요건을 충족하는지 확인합니다.

노드 구성을 맞춤설정하는 기타 옵션

다른 방법을 사용하여 노드 구성을 맞춤설정할 수도 있습니다.

• 런타임 구성 파일: GKE 노드에서 containerd 컨테이너 런타임을 맞춤설정하려면 런타임 구성 파일이라는 다른 파일을 사용하면 됩니다. 자세한 내용은 GKE 노드에서 containerd 구성 맞춤설정을 참고하세요.
• ComputeClass: GKE ComputeClass 사양에서 노드 속성을 지정할 수 있습니다. GKE 버전 1.32.1-gke.1729000 이상에서 GKE Autopilot 모드와 Standard 모드 모두에서 ComputeClass를 사용할 수 있습니다. 자세한 내용은 노드 시스템 구성 맞춤설정을 참고하세요.
• DaemonSets: DaemonSets를 사용하여 노드를 맞춤설정할 수도 있습니다. 자세한 내용은 DaemonSet으로 GKE 노드 자동 부트스트랩을 참고하세요.

Windows Server 노드에서는 노드 시스템 구성이 지원되지 않습니다.

시작하기 전에

시작하기 전에 다음 사항을 확인하세요.

• 명령줄 도구 설치:
  • 이 문서의 gcloud CLI 예시를 사용하는 경우 Google Cloud CLI를 설치하고 구성해야 합니다.
  • Terraform 예시를 사용하는 경우 Terraform을 설치하고 구성해야 합니다.
• 권한 부여: GKE 클러스터 및 노드 풀을 만들고 업데이트하려면 container.clusterAdmin 또는 이에 상응하는 권한이 있는 다른 역할과 같은 적절한 IAM 권한이 필요합니다.
• 잠재적인 워크로드 중단 계획: 맞춤 노드 구성은 노드 풀 수준에서 적용됩니다. 일반적으로 변경사항이 있으면 풀의 노드에 순차적 업데이트가 트리거되며, 이 업데이트에는 노드 다시 만들기가 포함됩니다. 잠재적인 워크로드 중단을 계획하고 적절한 경우 포드 중단 예산 (PDB)을 사용합니다.
• 모든 변경사항 백업 및 테스트: 프로덕션에 적용하기 전에 항상 스테이징 또는 개발 환경에서 구성 변경사항을 테스트합니다. 설정이 잘못되면 노드가 불안정해지거나 워크로드가 실패할 수 있습니다.
• GKE 기본 설정 검토: GKE 노드 이미지는 최적화된 기본 구성과 함께 제공됩니다. 특정 요구사항이 있고 변경사항의 영향을 이해하는 경우에만 매개변수를 맞춤설정하세요.

GKE Standard 모드에서 노드 시스템 구성 사용

노드 시스템 구성을 사용하는 경우 kubelet 및 Linux 커널의 구성 매개변수가 포함된 YAML 파일을 사용합니다. 노드 시스템 구성은 GKE Autopilot 모드에서도 사용할 수 있지만 이 문서의 단계에서는 GKE Standard 모드의 구성 파일을 만들고 사용하는 방법을 보여줍니다.

GKE Standard 모드에서 노드 시스템 구성을 사용하려면 다음을 수행하세요.

1. 구성 파일을 만듭니다. 이 파일에는 kubelet 및 sysctl 구성이 포함되어 있습니다.
2. 클러스터를 만들 때 또는 노드 풀을 만들거나 업데이트할 때 구성을 추가합니다.

구성 파일 만들기

YAML로 노드 시스템 구성을 작성합니다. 다음 예시는 kubelet 및 sysctl 옵션에 대해 구성을 추가합니다.

kubeletConfig:
  cpuManagerPolicy: static
  allowedUnsafeSysctls:
    - 'kernel.shm*'
    - 'kernel.msg*'
    - 'kernel.sem'
    - 'fs.mqueue*'
    - 'net.*'
linuxConfig:
  sysctl:
    net.core.somaxconn: '2048'
    net.ipv4.tcp_rmem: '4096 87380 6291456'

이 예시에서는 다음이 적용됩니다.

• cpuManagerPolicy: static 필드는 정적 CPU 관리 정책을 사용하도록 kubelet를 구성합니다. + net.core.somaxconn: '2048' 필드는 socket listen() 백로그를 2,048바이트로 제한합니다.
• net.ipv4.tcp_rmem: '4096 87380 6291456' 필드는 TCP 소켓 수신 버퍼의 최솟값, 기본값, 최댓값을 각각 4,096바이트, 87,380바이트, 6,291,456바이트로 설정합니다.

kubelet 또는 sysctl에 대해서만 구성을 추가하려면 노드 시스템 구성에 해당 섹션만 포함합니다. 예를 들어 kubelet 구성을 추가하려면 다음 파일을 만듭니다.

kubeletConfig:
  cpuManagerPolicy: static

노드 시스템 구성에 추가할 수 있는 필드의 전체 목록은 Kubelet 구성 옵션 및 Sysctl 구성 옵션 섹션을 참고하세요.

Standard 노드 풀에 구성 추가

노드 시스템 구성을 만든 후 Google Cloud CLI를 사용하여 --system-config-from-file 플래그를 추가합니다. 클러스터를 만들 때 또는 노드 풀을 만들거나 업데이트할 때 이 플래그를 추가할 수 있습니다. Google Cloud 콘솔을 사용하여 노드 시스템 구성을 추가할 수 없습니다.

노드 시스템 구성으로 클러스터 만들기

gcloud CLI 또는 Terraform을 사용하여 클러스터를 만드는 동안 노드 시스템 구성을 추가할 수 있습니다. 다음 안내에서는 노드 시스템 구성을 기본 노드 풀에 적용합니다.

gcloud CLI

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH

다음을 바꿉니다.

• CLUSTER_NAME: 클러스터의 이름입니다.
• LOCATION: 클러스터의 컴퓨팅 영역 또는 리전
• SYSTEM_CONFIG_PATH: kubelet 및 sysctl 구성이 포함된 파일의 경로

노드 시스템 구성을 적용한 후 클러스터의 기본 노드 풀에 정의된 설정이 사용됩니다.

Terraform

Terraform을 사용하여 맞춤설정된 노드 시스템 구성으로 리전 클러스터를 만들려면 다음 예시를 참고하세요.

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-central1"

  initial_node_count = 1

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Terraform 사용에 대한 자세한 내용은 GKE에 대한 Terraform 지원을 참조하세요.

노드 시스템 구성으로 새 노드 풀 만들기

gcloud CLI 또는 Terraform을 사용하여 새 노드 풀을 만들 때 노드 시스템 구성을 추가할 수 있습니다.

다음 안내에서는 새 노드 풀에 노드 시스템 구성을 적용합니다.

gcloud CLI

gcloud container node-pools create POOL_NAME \
     --cluster CLUSTER_NAME \
     --location=LOCATION \
     --system-config-from-file=SYSTEM_CONFIG_PATH

다음을 바꿉니다.

• POOL_NAME: 노드 풀의 이름
• CLUSTER_NAME: 노드 풀을 추가하려는 클러스터의 이름
• LOCATION: 클러스터의 컴퓨팅 영역 또는 리전
• SYSTEM_CONFIG_PATH: kubelet 및 sysctl 구성이 포함된 파일의 경로

Terraform

Terraform을 사용하여 맞춤설정된 노드 시스템 구성으로 노드 풀을 만들려면 다음 예시를 참조하세요.

resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Terraform 사용에 대한 자세한 내용은 GKE에 대한 Terraform 지원을 참조하세요.

기존 노드 풀의 노드 시스템 구성 업데이트

다음 명령어를 실행하여 기존 노드 풀의 노드 시스템 구성을 업데이트할 수 있습니다.

   gcloud container node-pools update POOL_NAME \
      --cluster=CLUSTER_NAME \
      --location=LOCATION \
      --system-config-from-file=SYSTEM_CONFIG_PATH

다음을 바꿉니다.

• POOL_NAME: 업데이트하려는 노드 풀의 이름
• CLUSTER_NAME: 업데이트하려는 클러스터의 이름입니다.
• LOCATION: 클러스터의 컴퓨팅 영역 또는 리전
• SYSTEM_CONFIG_PATH: kubelet 및 sysctl 구성이 포함된 파일의 경로

이 변경사항을 적용하려면 노드를 다시 만들어야 하므로 실행 중인 워크로드가 중단될 수 있습니다. 이 특정 변경사항에 관한 자세한 내용은 유지보수 정책을 준수하지 않고 노드 업그레이드 전략을 사용하여 노드를 다시 만드는 수동 변경사항 표에서 해당 행을 찾으세요.

노드 업데이트에 관한 자세한 내용은 노드 업데이트 중단 계획을 참고하세요.

주의: GKE는 활성 유지보수 정책과 관계없이 노드 업그레이드 전략을 사용하여 이 변경사항에 관한 노드 재생성을 즉시 시작합니다. GKE는 변경사항을 위한 리소스 가용성에 따라 달라집니다. 노드 자동 업그레이드를 사용 중지해도 이 변경사항을 방지할 수 없습니다.

노드 시스템 구성 수정

노드 시스템 구성을 수정하려면 원하는 구성을 사용하여 새 노드 풀을 만들거나 기존 노드 풀의 노드 시스템 구성을 업데이트하면 됩니다.

노드 풀을 만들어 수정

노드 풀을 만들어 노드 시스템 구성을 수정하려면 다음 단계를 따르세요.

1. 원하는 구성을 사용하여 구성 파일을 만듭니다.
2. 새 노드 풀에 구성을 추가합니다.
3. 워크로드를 새 노드 풀로 마이그레이션합니다.
4. 이전 노드 풀을 삭제합니다.

기존 노드 풀을 업데이트하여 수정

기존 노드 풀의 노드 시스템 구성을 수정하려면 노드 풀 업데이트 탭의 안내에 따라 노드 풀에 구성 추가합니다. 노드 시스템 구성을 업데이트하고 새 구성이 노드 풀의 기존 시스템 구성을 재정의하는 경우 노드를 다시 만들어야 합니다. 업데이트 중 매개변수를 생략하면 해당 기본값으로 설정됩니다.

노드 시스템 구성을 다시 기본값으로 재설정하려면 kubelet 및 sysctl 필드에 빈 값을 사용해서 구성 파일을 업데이트합니다. 예를 들면 다음과 같습니다.

kubeletConfig: {}
linuxConfig:
  sysctl: {}

노드 시스템 구성 삭제

노드 시스템 구성을 삭제하려면 다음 단계를 따르세요.

1. 노드 풀 만들기
2. 워크로드를 새 노드 풀로 마이그레이션합니다.
3. 이전 노드 시스템 구성이 있는 노드 풀을 삭제합니다.

kubelet 구성 옵션

이 섹션의 표에서는 수정할 수 있는 kubelet 옵션을 설명합니다.

CPU 관리

다음 표에서는 kubelet의 CPU 관리 옵션을 설명합니다.

kubelet 구성 설정	제한사항	기본 설정	설명
cpuCFSQuota	true 또는 false여야 합니다.	true	이 설정은 포드의 CPU 한도를 적용합니다. 이 값을 false로 설정하면 포드의 CPU 한도가 무시됩니다. 포드가 CPU 한도에 민감한 경우 특정 시나리오에서 CPU 한도를 무시하는 것이 유용할 수 있습니다. cpuCFSQuota를 사용 중지할 경우 악의적인 포드가 의도한 것보다 더 많은 CPU 리소스를 사용할 수 있습니다.
cpuCFSQuotaPeriod	시간이어야 합니다.	"100ms"	이 설정은 CPU CFS 할당량 기간 값인 cpu.cfs_period_us를 설정합니다. 이 값은 CPU 리소스에 대한 cgroup의 액세스를 다시 할당해야 하는 빈도에 대한 기간을 지정합니다. 이 옵션을 사용하면 CPU 제한 동작을 조정할 수 있습니다.

메모리 관리 및 제거

다음 표에서는 메모리 관리 및 제거를 위해 수정할 수 있는 옵션을 설명합니다. 이 섹션에는 evictionSoft 플래그의 수정 가능한 옵션을 설명하는 별도의 표도 포함되어 있습니다.

kubelet 구성 설정	제한사항	기본 설정	설명
evictionSoft	신호 이름의 맵입니다. 값 제한은 다음 표를 참고하세요.	none	이 설정은 신호 이름을 소프트 제거 기준을 정의하는 수량 또는 비율에 매핑합니다. 소프트 퇴출 기준에는 유예 기간이 있어야 합니다. kubelet는 유예 기간이 초과될 때까지 포드를 제거하지 않습니다.
evictionSoftGracePeriod	신호 이름의 맵입니다. 각 신호 이름의 값은 5m 미만의 양수 기간이어야 합니다. 유효한 시간 단위는 ns, us (또는 µs), ms, s, m입니다.	none	이 설정은 신호 이름을 소프트 삭제 기준점의 유예 기간을 정의하는 기간에 매핑합니다. 각 소프트 퇴출 임계값에는 상응하는 유예 기간이 있어야 합니다.
evictionMinimumReclaim	신호 이름의 맵입니다. 각 신호 이름의 값은 10% 미만의 양수 비율이어야 합니다.	none	이 설정은 포드 퇴출을 실행할 때 kubelet이 회수하는 특정 리소스의 최소 금액을 정의하는 신호 이름을 백분율에 매핑합니다.
evictionMaxPodGracePeriodSeconds	값은 0에서 300 사이의 정수여야 합니다.	0	이 설정은 제거 중에 포드 종료에 적용되는 최대 유예 기간을 초 단위로 정의합니다.

다음 표에는 evictionSoft 플래그의 수정 가능한 옵션이 나와 있습니다. 동일한 옵션이 제한사항이 다른 evictionSoftGracePeriod 및 evictionMinimumReclaim 플래그에도 적용됩니다.

kubelet 구성 설정	제한사항	기본 설정	설명
memoryAvailable	값은 노드 메모리의 100Mi보다 크고 50%보다 작은 양이어야 합니다.	none	이 설정은 소프트 삭제 전에 사용 가능한 메모리 양을 나타냅니다. kubelet의 memory.available 신호 양을 정의합니다 .
nodefsAvailable	값은 10%에서 50% 사이여야 합니다.	none	이 설정은 소프트 제거 전에 사용할 수 있는 nodefs를 나타냅니다. kubelet의 nodefs.available 신호 양을 정의합니다 .
nodefsInodesFree	값은 5%에서 50% 사이여야 합니다.	none	이 설정은 소프트 삭제 전에 사용 가능한 nodefs 아이노드를 나타냅니다. kubelet의 nodefs.inodesFree 신호 양을 정의합니다 .
imagefsAvailable	값은 15%에서 50% 사이여야 합니다.	none	이 설정은 소프트 제거 전에 사용할 수 있는 imagefs를 나타냅니다. kubelet의 imagefs.available 신호 양을 정의합니다 .
imagefsInodesFree	값은 5%에서 50% 사이여야 합니다.	none	이 설정은 강제 삭제 전의 여유 이미지fs 아이노드를 나타냅니다. kubelet의 imagefs.inodesFree 신호 양을 정의합니다.
pidAvailable	값은 10%에서 50% 사이여야 합니다.	none	이 설정은 소프트 삭제 전에 사용할 수 있는 PID를 나타냅니다. kubelet의 pid.available 신호 양을 정의합니다.
singleProcessOOMKill	값은 true 또는 false이어야 합니다.	cgroupv1 노드의 경우 true, cgroupv2 노드의 경우 false	이 설정은 컨테이너의 프로세스가 개별적으로 또는 그룹으로 OOMkill되는지 설정합니다. GKE 버전 1.32.4-gke.1132000, 1.33.0-gke.1748000 이상에서 사용할 수 있습니다.

PID 관리

다음 표에서는 수정 가능한 PID 관리 옵션을 설명합니다.

kubelet 구성 설정	제한사항	기본 설정	설명
podPidsLimit	값은 1024에서 4194304 사이여야 합니다.	none	이 설정은 각 포드가 사용할 수 있는 최대 프로세스 ID(PID) 수를 설정합니다.

로깅

다음 표에서는 수정 가능한 로깅 옵션에 대해 설명합니다.

kubelet 구성 설정	제한사항	기본 설정	설명
containerLogMaxSize	값은 양수여야 하며 단위 서픽스는 10Mi와 500Mi 사이(포함)여야 합니다.	10Mi	이 설정은 컨테이너 로그 로테이션 정책의 containerLogMaxSize 설정을 제어하며, 이를 통해 각 로그 파일의 최대 크기를 구성할 수 있습니다. 기본값은 10Mi입니다. 유효한 단위는 Ki, Mi, Gi입니다.
containerLogMaxFiles	값은 2와 10 사이(포함)의 정수여야 합니다.	5	이 설정은 컨테이너 로그 파일 순환 정책의 containerLogMaxFiles 설정을 제어하며, 이를 통해 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있습니다. 기본값은 5입니다. 컨테이너당 총 로그 크기 (container_log_max_size*container_log_max_files)는 노드의 총 스토리지의 1% 를 초과할 수 없습니다.

이미지 가비지 컬렉션

다음 표에서는 이미지 가비지 컬렉션의 수정 가능한 옵션에 대해 설명합니다.

kubelet 구성 설정	제한사항	기본 설정	설명
imageGCHighThresholdPercent	값은 10~85 사이(포함)의 정수여야 하며 imageGcLowThresholdPercent보다 커야 합니다.	85	이 설정은 이미지 가비지 컬렉션이 실행되는 디스크 사용량 비율을 정의합니다. 가비지 컬렉션을 실행할 최고 디스크 사용량을 나타냅니다. 비율은 이 필드의 값을 100으로 나누어서 계산됩니다.
imageGCLowThresholdPercent	값은 10~85 사이(포함)의 정수여야 하며 imageGcHighThresholdPercent보다 낮아야 합니다.	80	이 설정은 이미지 가비지 컬렉션이 실행된 적이 없는 디스크 사용량의 비율을 정의합니다. 가비지 컬렉션을 실행할 최저 디스크 사용량을 나타냅니다. 비율은 이 필드의 값을 100으로 나누어서 계산됩니다.
imageMinimumGcAge	값은 2m보다 크지 않은 기간이어야 합니다. 유효한 시간 단위는 ns, us (또는 µs), ms, s, m, h입니다.	2m	이 설정은 사용하지 않는 이미지가 가비지 수집되기 전의 최소 기간을 정의합니다.
imageMaximumGcAge	값은 기간이어야 합니다.	0s	이 설정은 이미지가 가비지 수집되기 전에 사용되지 않을 수 있는 최대 기간을 정의합니다. 이 필드의 기본값은 0s이며, 이 필드는 사용 중지됩니다. 따라서 이미지는 사용되지 않는다는 이유로 가비지 수집되지 않습니다. 이 값이 지정된 경우 imageMinimumGcAge 필드 값보다 커야 합니다. GKE 버전 1.30.7-gke.1076000, 1.31.3-gke.1023000 이상에서 사용할 수 있습니다.

이미지 가져오기

다음 표에서는 수정 가능한 이미지 가져오기 옵션을 설명합니다.

kubelet 구성 설정	제한사항	기본 설정	설명
maxParallelImagePulls	값은 2~5 사이(포함)의 정수여야 합니다.	디스크 유형에 따라 2 또는 3입니다.	이 설정은 최대 병렬 이미지 가져오기 수를 정의합니다. 기본값은 부팅 디스크 유형에 따라 결정됩니다.

보안 및 안전하지 않은 작업

다음 표에서는 보안을 구성하고 안전하지 않은 작업을 처리하기 위해 수정할 수 있는 옵션을 설명합니다.

kubelet 구성 설정	제한사항	기본 설정	설명
allowedUnsafeSysctls	sysctl 이름 또는 그룹 목록입니다. 허용되는 sysctl 그룹은 다음과 같습니다. kernel.shm* kernel.msg* kernel.sem fs.mqueue.* net.*개	none	이 설정은 포드에 설정할 수 있는 안전하지 않은 sysctl 이름 또는 sysctl 그룹의 허용 목록을 쉼표로 구분하여 정의합니다.
insecureKubeletReadonlyPortEnabled	값은 불리언 값(true 또는 false)이어야 합니다.	true	이 설정은 클러스터의 모든 새 노드 풀에서 비보안 kubelet 읽기 전용 포트 10255를 사용 중지합니다. 이 파일에서 이 설정을 구성하면 GKE API 클라이언트를 사용하여 클러스터 수준에서 설정을 변경할 수 없습니다.

Resource Manager

Kubernetes는 Resource Manager 모음을 제공합니다. 이러한 리소스 관리자를 구성하여 CPU, 기기, 메모리(hugepages) 리소스에 관한 특정 요구사항으로 구성된 포드의 노드 리소스 정렬을 조정하고 최적화할 수 있습니다.

다음 표에서는 리소스 관리자의 수정 가능한 옵션에 대해 설명합니다.

kubelet 구성 설정	제한사항	기본 설정	설명
cpuManagerPolicy	값은 none 또는 static이어야 합니다.	none	이 설정은 kubelet CPU 관리자 정책을 제어합니다. 기본값은 OS 스케줄러가 자동으로 수행하는 것 이상의 어피니티를 제공하지 않는 기본 CPU 어피니티 스키마인 none입니다. 이 값을 static으로 설정하면 Guaranteed QoS 클래스에 있고 정수 CPU 요청이 있는 포드에 배타적인 CPU가 할당될 수 있습니다.
memoryManager.policy	값은 None 또는 Static이어야 합니다.	None	이 설정은 kubelet 메모리 관리자 정책을 제어합니다. 기본값이 None인 경우 Kubernetes는 메모리 관리자가 없는 경우와 동일하게 작동합니다. 이 값을 Static로 설정하면 메모리 관리자 정책은 포드 유형에 따라 토폴로지 힌트를 전송합니다. 자세한 내용은 정적 정책을 참조하세요. 이 설정은 GKE 버전 1.32.3-gke.1785000 이상을 실행하는 컨트롤 플레인이 있는 클러스터에서 지원됩니다.
topologyManager	값은 각 필드에 지원되는 설정 중 하나여야 합니다. Terraform 안내를 사용하여 Standard 노드 풀에 구성을 추가할 때는 topologyManager 필드를 설정할 수 없습니다.	policy: none scope: container	이러한 설정은 policy 및 scope 하위 필드를 사용하여 kubelet Topology Manager 구성을 제어합니다. 토폴로지 관리자는 CPU 격리, 메모리, 기기 위치와 관련된 성능 최적화를 담당하는 구성요소 집합을 조정합니다. 정책 및 범위 설정을 서로 독립적으로 설정할 수 있습니다. 이러한 설정에 관한 자세한 내용은 토폴로지 관리자 범위 및 정책을 참조하세요. 다음 GKE 리소스는 이 설정을 지원합니다. GKE 버전 1.32.3-gke.1785000 이상을 실행하는 컨트롤 플레인이 있는 클러스터입니다. 컨트롤 플레인과 1.33.0-gke.1712000 이상을 실행하는 노드가 있는 클러스터의 경우 토폴로지 관리자도 GPU 토폴로지에 관한 정보를 수신합니다. 다음 머신 유형이 있는 노드: A2, A3, A4, C3, C4, C4A, G2, G4, M3, N4

Sysctl 구성 옵션

시스템 성능을 조정하려면 Linux 커널 매개변수를 수정하면 됩니다. 이 섹션의 표에서는 구성할 수 있는 다양한 커널 매개변수를 설명합니다.

파일 시스템 매개변수 (fs.*)

다음 표에서는 Linux 파일 시스템의 수정 가능한 매개변수를 설명합니다. 이러한 설정은 파일 핸들 제한 및 이벤트 모니터링과 같은 Linux 파일 시스템의 동작을 제어합니다.

Sysctl 매개변수	제한사항	설명
fs.aio-max-nr	[65536, 4194304] 사이여야 합니다.	이 설정은 시스템 전체의 최대 비동기 I/O 요청 수를 정의합니다.
fs.file-max	[104857, 67108864] 사이여야 합니다.	이 설정은 Linux 커널이 할당할 수 있는 최대 파일 핸들을 정의합니다.
fs.inotify.max_user_instances	[8192, 1048576] 사이여야 합니다.	이 설정은 사용자가 만들 수 있는 최대 inotify 인스턴스 수를 정의합니다.
fs.inotify.max_user_watches	[8192, 1048576] 사이여야 합니다.	이 설정은 사용자가 만들 수 있는 최대 inotify 감시 수를 정의합니다.
fs.nr_open	[1048576, 2147483584] 사이여야 합니다.	이 설정은 프로세스에서 열 수 있는 최대 파일 설명자를 정의합니다.

커널 매개변수 (kernel.*)

다음 표에서는 수정 가능한 Linux 커널 매개변수를 설명합니다. 이러한 설정은 공유 메모리 할당을 비롯한 핵심 커널 기능을 구성합니다.

Sysctl 매개변수	제한사항	설명
kernel.shmmni	[4096, 32768] 사이여야 합니다.	이 설정은 시스템 전체의 최대 공유 메모리 세그먼트 수를 정의합니다. 이 값이 설정되지 않으면 기본값은 4096입니다.
kernel.shmmax	[0, 18446744073692774399] 사이여야 합니다.	이 설정은 커널에서 허용하는 단일 공유 메모리 세그먼트의 최대 크기(바이트)를 정의합니다. 이 값은 실제 RAM 양보다 큰 경우 무시되므로 사용 가능한 모든 RAM을 공유할 수 있습니다.
kernel.shmall	[0, 18446744073692774399] 사이여야 합니다.	이 설정은 시스템에서 한 번에 사용할 수 있는 공유 메모리 페이지의 총량을 정의합니다. AMD64 및 Intel 64 아키텍처에서 페이지는 4,096바이트입니다.
kernel.perf_event_paranoid	[-1, 3] 사이여야 합니다.	이 설정은 CAP_PERFMON이 없는 권한이 없는 사용자의 성능 이벤트 시스템 사용을 제어합니다. 커널의 기본값은 2입니다.
kernel.sched_rt_runtime_us	[-1, 1000000] 사이여야 합니다.	이 설정은 실시간 예약이 사용할 수 있는 시간에 대한 전역 제한을 정의합니다.
kernel.softlockup_panic	선택사항 (불리언)	이 설정은 소프트 잠금이 감지될 때 커널이 패닉 상태가 되는지 여부를 제어합니다.
kernel.yama.ptrace_scope	[0, 3] 사이여야 합니다.	이 설정은 ptrace() 시스템 호출의 범위와 제한사항을 정의하여 프로세스 디버깅 및 추적에 영향을 미칩니다. 지원되는 값은 다음과 같습니다. 0: 클래식 ptrace 권한입니다. 1: 제한된 ptrace. 이는 많은 배포에서 기본값입니다. 하위 프로세스 또는 CAP_SYS_PTRACE만 2: 관리자 전용 ptrace입니다. CAP_SYS_PTRACE가 있는 프로세스만 3: ptrace 없음. ptrace 호출이 허용되지 않습니다.
kernel.kptr_restrict	[0, 2] 사이여야 합니다.	이 설정은 /proc 및 기타 인터페이스를 통해 커널 주소를 노출하는 데 제한이 적용되는지 여부를 나타냅니다.
kernel.dmesg_restrict	선택사항 (불리언)	이 설정은 권한이 없는 사용자가 dmesg(8)를 사용하여 커널의 로그 버퍼에서 메시지를 볼 수 없는지 여부를 나타냅니다.
kernel.sysrq	[0, 511] 사이여야 합니다.	이 설정은 SysRq 키를 통해 호출하도록 허용되는 함수를 제어합니다. 가능한 값은 다음과 같습니다. 0: sysrq를 완전히 사용 중지합니다. 1: 모든 sysrq 기능을 사용 설정합니다. >1: 허용된 sysrq 함수의 비트 마스크입니다. 자세한 내용은 Linux Magic System Request Key Hacks를 참고하세요.

네트워크 매개변수 (net.*)

다음 표에서는 수정 가능한 네트워킹 매개변수를 설명합니다. 이러한 설정은 소켓 버퍼에서 연결 추적에 이르기까지 네트워킹 스택의 성능과 동작을 조정합니다.

Sysctl 매개변수	제한사항	설명
net.core.busy_poll	2147483647보다 작은 양의 정수입니다.	이 설정은 폴링 및 선택의 짧은 지연 시간 비지 폴링 제한 시간을 정의합니다. 이 값은 이벤트를 기다리는 동안 busy loop가 실행되는 대략적인 시간(µs)을 나타냅니다.
net.core.busy_read	2147483647보다 작은 양의 정수입니다.	이 설정은 소켓 읽기의 짧은 지연 시간의 비지 폴링 제한 시간을 정의합니다. 기기 대기열에서 패킷을 기다리는 데 걸리는 대략적인 시간(µs)을 나타냅니다.
net.core.netdev_max_backlog	2147483647보다 작은 양의 정수입니다.	이 설정은 인터페이스가 커널에서 처리할 수 있는 것보다 빠른 속도로 패킷을 수신할 때 INPUT 측에 대기열에 추가되는 최대 패킷 수를 정의합니다.
net.core.rmem_default	2147483647보다 작은 양의 정수입니다.	이 설정은 기본 수신 소켓 버퍼 크기를 바이트 단위로 정의합니다.
net.core.rmem_max	2147483647보다 작은 양의 정수입니다.	이 설정은 최대 수신 소켓 버퍼 크기(바이트)를 정의합니다.
net.core.wmem_default	2147483647보다 작은 양의 정수입니다.	이 설정은 소켓 전송 버퍼의 기본 설정(바이트)을 정의합니다.
net.core.wmem_max	2147483647보다 작은 양의 정수입니다.	이 설정은 최대 전송 소켓 버퍼 크기(바이트)를 정의합니다.
net.core.optmem_max	2147483647보다 작은 양의 정수입니다.	이 설정은 소켓당 허용되는 최대 보조 버퍼 크기를 정의합니다.
net.core.somaxconn	[128, 2147483647] 사이여야 합니다.	이 설정은 사용자 공간에서 SOMAXCONN으로 알려진 socket listen() 백로그의 한도를 정의합니다. 이 설정의 기본값은 128입니다.
net.ipv4.tcp_rmem	{min, default, max} (각각 0보다 큼, 메모리는 바이트 단위)	이 설정은 조정에서 UDP 소켓이 사용하는 수신 버퍼의 최소 크기(바이트)를 정의합니다. 기본 설정은 1페이지입니다.
net.ipv4.tcp_wmem	{min, default, max}(각각 0보다 큼, 메모리(바이트))	이 설정은 조정에서 UDP 소켓이 사용하는 전송 버퍼의 최소 크기(바이트)를 정의합니다. 기본 설정은 1페이지입니다.
net.ipv4.tcp_tw_reuse	{0, 1} 사이여야 합니다.	이 설정은 프로토콜 관점에서 안전한 경우 새 연결에 TIME_WAIT 상태의 소켓을 재사용하도록 허용할지 여부를 정의합니다. 기본값은 0입니다.
net.ipv4.tcp_max_orphans	[16384, 262144] 사이여야 합니다.	이 설정은 사용자 파일 핸들에 연결되지 않은 최대 TCP 소켓 수를 정의합니다.
net.ipv4.tcp_max_tw_buckets	[4096, 2147483647] 사이여야 합니다.	이 설정은 시스템에서 동시에 보유하는 최대 timewait 소켓 수를 정의합니다. 이 숫자를 초과하면 time-wait 소켓이 즉시 소멸되고 경고가 출력됩니다.
net.ipv4.tcp_syn_retries	[1, 127] 사이여야 합니다.	이 설정은 활성 TCP 연결 시도의 초기 SYN이 재전송되는 횟수를 정의합니다.
net.ipv4.tcp_ecn	[0, 2] 사이여야 합니다.	이 설정은 TCP에 의한 명시적 혼잡 알림 (ECN) 사용을 제어합니다. ECN은 TCP 연결의 양쪽 끝에서 모두 지원을 나타내는 경우에만 사용됩니다.
net.ipv4.tcp_mtu_probing	[0, 2] 사이여야 합니다.	이 설정은 TCP 패킷화 계층 경로 MTU 검색을 제어합니다. 지원되는 값은 다음과 같습니다. 0: 사용 중지됨 1: 기본적으로 사용 중지되며 ICMP 블랙홀이 감지되면 사용 설정됩니다. 2: 항상 사용 설정됩니다. 초기 MSS tcp_base_mss을 사용합니다.
net.ipv4.tcp_congestion_control	설명 열의 지원되는 값 중 하나여야 합니다.	이 설정은 클러스터에서 GKE Dataplane V2가 사용 설정된 경우 지원되지 않습니다. 지원되는 값은 이미지 유형에 따라 다음과 같습니다. COS: reno, cubic, bbr, lp Ubuntu: reno, cubic, bbr, lp, htcp, vegas, dctcp, bic, cdg, highspeed, hybla, illinois, nv, scalable, veno, westwood, yeah
net.ipv6.conf.all.disable_ipv6	부울.	이 값을 변경하는 것은 conf/default/disable_ipv6 설정과 모든 인터페이스별 disable_ipv6 설정을 동일한 값으로 변경하는 것과 같습니다.
net.ipv6.conf.default.disable_ipv6	부울.	이 설정은 IPv6의 작동을 사용 중지합니다.
net.netfilter.nf_conntrack_acct	{0, 1} 사이여야 합니다.	이 설정은 연결 추적 흐름 계정을 사용 설정합니다. 기본값은 0이며, 이는 설정이 사용 중지됨을 의미합니다. GKE 버전 1.32.0-gke.1448000 이상에서 사용할 수 있습니다.
net.netfilter.nf_conntrack_max	[65536, 4194304] 사이여야 합니다.	이 설정은 연결 추적 테이블의 크기를 정의합니다. 최댓값에 도달하면 새 연결이 실패합니다. GKE 버전 1.32.0-gke.1448000 이상에서 사용할 수 있습니다.
net.netfilter.nf_conntrack_buckets	[65536, 524288] 사이여야 합니다.	이 설정은 해시 테이블의 크기를 정의합니다. 권장 설정은 nf_conntrack_max = nf_conntrack_buckets * 4의 결과입니다. GKE 버전 1.32.0-gke.1448000 이상에서 사용할 수 있습니다.
net.netfilter.nf_conntrack_tcp_timeout_close_wait	[60, 3600] 사이여야 합니다.	이 설정은 TCP 연결이 CLOSE_WAIT 상태로 유지될 수 있는 기간(초)을 정의합니다. 기본값은 3600입니다. GKE 버전 1.32.0-gke.1448000 이상에서 사용할 수 있습니다.
net.netfilter.nf_conntrack_tcp_timeout_established	[600, 86400] 사이여야 합니다.	이 설정은 연결 추적 테이블에서 자동으로 삭제되기 전의 비활성 연결 기간(초)을 정의합니다. GKE 버전 1.32.0-gke.1448000 이상에서 사용할 수 있습니다.
net.netfilter.nf_conntrack_tcp_timeout_time_wait	[1, 600] 사이여야 합니다.	이 설정은 TCP 연결이 TIME_WAIT 상태로 유지될 수 있는 기간(초)을 정의합니다. 기본값은 120입니다. GKE 버전 1.32.0-gke.1448000 이상에서 사용할 수 있습니다.

가상 메모리 매개변수 (vm.*)

다음 표에서는 가상 메모리 하위 시스템의 수정 가능한 매개변수를 설명합니다. 이러한 설정은 커널이 메모리, 스왑, 디스크 캐싱을 처리하는 방식을 제어하는 가상 메모리 하위 시스템을 관리합니다.

sysctl 매개변수	제한사항	설명
vm.max_map_count	[65536, 2147483647] 사이여야 합니다.	이 파일은 프로세스가 가질 수 있는 메모리 맵 영역의 최대 개수를 정의합니다.
vm.dirty_background_ratio	[1, 100] 사이여야 합니다.	이 설정은 백그라운드 커널 플러셔 스레드가 쓰기 시작 전에 더티 페이지로 채울 수 있는 시스템 메모리의 비율을 정의합니다. 값은 vm.dirty_ratio 필드의 값보다 작아야 합니다.
vm.dirty_background_bytes	[0, 68719476736] 사이여야 합니다.	이 설정은 백그라운드 커널 플러셔 스레드가 쓰기 작업을 시작하는 더티 메모리 양을 정의합니다. vm.dirty_background_bytes은 vm.dirty_background_ratio의 대응 항목입니다. 이러한 설정 중 하나만 지정할 수 있습니다.
vm.dirty_expire_centisecs	[0, 6000] 사이여야 합니다.	이 설정은 커널 플러셔 스레드가 더티 데이터를 디스크에 쓰기 전에 더티 데이터가 메모리에 남아 있을 수 있는 최대 시간(1/100초)을 정의합니다.
vm.dirty_ratio	[1, 100] 사이여야 합니다.	이 설정은 쓰기를 실행하는 프로세스가 강제로 차단되고 더티 데이터를 동기식으로 써내기 전에 더티 페이지로 채울 수 있는 시스템 메모리의 비율을 정의합니다.
vm.dirty_bytes	[0, 68719476736] 사이여야 합니다.	이 설정은 디스크 쓰기를 생성하는 프로세스가 자체적으로 쓰기 시작하는 더티 메모리 양을 정의합니다. vm.dirty_bytes에 허용되는 최솟값은 2페이지(바이트)입니다. 이 한도보다 낮은 값은 무시되고 이전 구성이 유지됩니다. vm.dirty_bytes은 vm.dirty_ratio의 대응 항목입니다. 이러한 설정 중 하나만 지정할 수 있습니다.
vm.dirty_writeback_centisecs	[0, 1000] 사이여야 합니다.	이 설정은 커널 플러셔 스레드가 오래된 더티 데이터를 디스크에 쓰기 위해 절전 모드에서 해제되는 간격을 1/100초 단위로 정의합니다.
vm.overcommit_memory	{0, 1, 2} 사이여야 합니다.	이 설정은 메모리 오버커밋을 처리하기 위한 커널의 전략을 결정합니다. 값은 다음과 같습니다. 0: 큰 할당 거부 1: 항상 허용 2: 스왑 + RAM 비율을 초과하는 커밋 방지
vm.overcommit_ratio	[0, 100] 사이여야 합니다.	이 설정은 vm.overcommit_memory 필드 값이 2로 설정된 경우 오버커밋에 허용되는 실제 RAM의 비율을 정의합니다.
vm.vfs_cache_pressure	[0, 100] 사이여야 합니다.	이 설정은 dentry (디렉터리) 및 inode 캐시에 사용된 메모리를 회수하는 커널의 환경설정을 조정합니다.
vm.swappiness	[0, 200] 사이여야 합니다.	이 설정은 커널이 프로세스를 실제 메모리에서 스왑 디스크로 이동하는 경향을 제어합니다. 기본값은 60입니다.
vm.watermark_scale_factor	[10, 3000] 사이여야 합니다.	이 설정은 kswapd의 적극성을 제어합니다. kswapd가 절전 모드에서 해제되기 전에 남은 메모리와 절전 모드로 전환되기 전에 해제할 메모리를 정의합니다. 기본값은 10입니다.
vm.min_free_kbytes	[67584, 1048576] 사이여야 합니다.	이 설정은 OOM 전의 최소 여유 메모리를 정의합니다. 기본값은 67584입니다.

각 sysctl 플래그에 지원되는 값에 대한 자세한 내용은 --system-config-from-file gcloud CLI 문서를 참조하세요.

다른 Linux 네임스페이스는 지정된 sysctl 플래그에 대해 고유 값을 가질 수 있지만, 다른 것들은 전체 노드에 대해 전역적일 수 있습니다. 노드 시스템 구성을 사용하여 sysctl 옵션을 업데이트하면 노드 및 각 네임스페이스에서 sysctl이 전역적으로 적용되도록 보장하여, 각 포드가 각 Linux 네임스페이스에서 동일한 sysctl 값을 갖게 합니다.

Linux cgroup 모드 구성 옵션

주의: GKE는 부 버전 1.31에서 cgroupv1을 지원 중단하고 버전 1.35에서 cgroupv1 지원을 삭제합니다. GKE가 cgroupv2로 전환하는 방법과 이 전환에 대비하여 클러스터를 준비하는 방법에 관한 자세한 내용은 노드를 Linux cgroupv2로 마이그레이션을 참고하세요.

컨테이너 런타임과 kubelet는 포드의 각 컨테이너에서 액세스할 수 있는 CPU 또는 메모리 양을 제한하는 것과 같은 리소스 관리에 Linux 커널 cgroups를 사용합니다. 커널에는 cgroupv1 및 cgroupv2의 두 가지 cgroup 하위 시스템 버전이 있습니다. cgroupv2에 대한 Kubernetes 지원은 Kubernetes 버전 1.18에서 알파, 1.22에서 베타, 1.25에서 정식 버전으로 도입되었습니다. 자세한 내용은 Kubernetes cgroups v2 문서를 참고하세요.

노드 시스템 구성에 따라 노드 풀의 cgroup 구성을 맞춤설정할 수 있습니다. cgroupv1 또는 cgroupv2를 사용할 수 있습니다. GKE는 버전 1.26 이상을 실행하는 새 Standard 노드 풀에 cgroupv2를 사용하고 1.26 이전 버전을 실행하는 노드 풀에 cgroupv1을 사용합니다. 노드 자동 프로비저닝으로 만든 노드 풀의 경우 cgroup 구성은 노드 풀 버전이 아닌 초기 클러스터 버전에 따라 다릅니다. cgroupv1은 Arm 머신에서 지원되지 않습니다.

노드 시스템 구성을 사용하여 cgroupv1 또는 cgroupv2를 명시적으로 사용하도록 노드 풀 설정을 변경할 수 있습니다. cgroupv1를 사용하는 기존 노드 풀을 버전 1.26으로 업그레이드해도 설정은 cgroupv2로 변경되지 않습니다. 1.26 이전 버전을 실행하고 맞춤설정된 cgroup 구성이 포함되지 않은 기존 노드 풀은 계속 cgroupv1를 사용합니다. 설정을 변경하려면 기존 노드 풀에 대해 cgroupv2를 명시적으로 지정해야 합니다.

예를 들어 cgroupv2를 사용하도록 노드 풀을 구성하려면 다음과 같이 노드 시스템 구성 파일을 사용합니다.

linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

지원되는 cgroupMode 옵션은 다음과 같습니다.

• CGROUP_MODE_V1: 노드 풀에 cgroupv1을 사용합니다.
• CGROUP_MODE_V2: 노드 풀에 cgroupv2을 사용합니다.
• CGROUP_MODE_UNSPECIFIED: 기본 GKE cgroup 구성을 사용합니다.

cgroupv2를 사용하려면 다음 요구사항 및 제한사항이 적용됩니다.

• 1.26 이전 버전을 실행하는 노드 풀의 경우 gcloud CLI 버전 408.0.0 이상을 사용해야 합니다. 또는 395.0.0 이상 버전의 gcloud beta를 사용합니다.
• 클러스터 및 노드 풀에서 GKE 버전 1.24.2-gke.300 이상을 실행해야 합니다.
• containerd가 포함된 Container-Optimized OS 또는 containerd가 포함된 Ubuntu 노드 이미지를 사용해야 합니다.
• 워크로드가 cgroup 파일 시스템(/sys/fs/cgroup/...) 읽기에 의존할 경우 cgroupv2 API와 호환되는지 확인합니다.
• 모니터링 또는 서드 파티 도구를 사용하는 경우 cgroupv2와 호환되는지 확인합니다.
• Java 워크로드 (JDK)를 사용하는 경우 JDK 8u372, JDK 11.0.16 이상, JDK 15 이상을 포함하여 cgroupv2를 완전히 지원하는 버전을 사용하는 것이 좋습니다.

cgroup 구성 확인

노드 시스템 구성을 추가할 때 변경사항을 적용하려면 GKE에서 노드를 다시 만들어야 합니다. 노드 풀에 구성을 추가하고 노드가 다시 생성되면 새 구성을 확인할 수 있습니다.

gcloud CLI 또는 kubectl 명령줄 도구를 사용하여 노드 풀에 있는 노드의 cgroup 구성을 확인할 수 있습니다.

gcloud CLI

노드 풀의 cgroup 구성을 확인합니다.

gcloud container node-pools describe POOL_NAME \
  --format='value(Config.effectiveCgroupMode)'

POOL_NAME을 노드 풀의 이름으로 바꿉니다.

가능한 출력은 다음 중 하나입니다.

• EFFECTIVE_CGROUP_MODE_V1: 노드가 cgroupv1을 사용합니다.
• EFFECTIVE_CGROUP_MODE_V2: 노드가 cgroupv2을 사용합니다.

출력에는 노드 풀의 노드가 다시 생성된 후의 새 cgroup 구성만 표시됩니다. cgroup을 지원하지 않는 Windows 서버 노드 풀의 경우 출력이 비어 있습니다.

kubectl

kubectl를 사용하여 이 노드 풀에 있는 노드의 cgroup 구성을 확인하려면 노드를 선택하고 다음 안내에 따라 연결합니다.

1. 노드 풀의 모든 노드를 사용하여 대화형 셸을 만듭니다. 명령어에서 mynode을 노드 풀의 노드 이름으로 바꿉니다.
2. Linux 노드에서 cgroup 버전 식별

Linux hugepages 구성 옵션

노드 시스템 구성 파일을 사용하여 hugepage를 미리 할당할 수 있습니다. Kubernetes는 CPU 또는 메모리와 유사한 리소스 유형으로 사전 할당된 hugepage를 지원합니다.

Hugepage를 사용하려면 다음 제한사항 및 요구사항이 적용됩니다.

• 노드가 hugepage로 완전히 채워지지 않도록 할당된 hugepage의 전체 크기가 다음 중 하나를 초과할 수 없습니다.
  • 메모리가 30GB 미만인 머신: 총 메모리의 60% 예를 들어 메모리가 8GB인 e2-standard-2 머신에서는 Huge Page를 4.8GB 이상 할당할 수 없습니다.
  • 메모리가 30GB 이상인 머신: 총 메모리의 80% 예를 들어 메모리가 32GB인 c4a-standard-8 머신에서는 Huge Page가 25.6GB를 초과할 수 없습니다.
• 1GB Huge Page는 A3, C2D, C3, C3D, C4, C4A, C4D, CT5E, CT5LP, CT6E, H3, M2, M3, M4 또는 Z3 머신 유형에서만 사용할 수 있습니다.

다음 표에서는 수정 가능한 Linux hugepage 설정을 설명합니다.

구성 매개변수	제한사항	기본값	설명
hugepage_size2m	정수 개수입니다. 앞서 설명한 메모리 할당 한도가 적용됩니다.	0	이 설정은 특정 수의 2MB 대형 페이지를 사전 할당합니다.
hugepage_size1g	정수 개수입니다. 앞서 설명한 메모리 및 머신 유형 제한사항이 모두 적용됩니다.	0	이 설정은 특정 수의 1GB 대형 페이지를 사전 할당합니다.

투명한 대형 페이지 (THP)

노드 시스템 구성 파일을 사용하여 Linux 커널의 Transparent HugePage Support를 사용 설정할 수 있습니다. THP를 사용하면 커널이 수동 사전 할당 없이 프로세스에 hugepage를 자동으로 할당합니다.

다음 표에서는 THP의 수정 가능한 매개변수를 설명합니다.

구성 매개변수	지원 값	기본값	설명
transparentHugepageEnabled	TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS: transparent hugepage가 시스템 전체에서 사용 설정됩니다. TRANSPARENT_HUGEPAGE_ENABLED_MADVISE: 투명한 대형 페이지가 MADV_HUGEPAGE 리전 내에서 사용 설정됩니다. 이 설정은 기본 커널 구성입니다. TRANSPARENT_HUGEPAGE_ENABLED_NEVER: 투명한 대형 페이지가 사용 중지됩니다. TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: 기본값입니다. GKE가 커널 구성을 수정하지 않습니다.	UNSPECIFIED	이 설정은 익명 메모리에 THP가 사용 설정되는지 여부를 제어합니다.
transparentHugepageDefrag	TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: THP를 요청하는 애플리케이션이 할당 실패 시 중단되고 THP를 즉시 할당하기 위해 페이지를 직접 회수하고 메모리를 압축합니다. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER: 애플리케이션이 백그라운드에서 kswapd를 작동시켜 페이지를 회수하고 kcompactd를 작동시켜 메모리를 압축하므로 조만간 THP를 사용할 수 있습니다. 이후 khugepaged가 THP 페이지를 나중에 설치합니다. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE: 애플리케이션이 평소와 같이 직접 회수 및 압축을 시작하지만 madvise(MADV_HUGEPAGE)를 사용한 리전에만 해당합니다. 다른 모든 리전에서는 백그라운드에서 kswapd를 작동시켜 페이지를 회수하고 kcompactd를 작동시켜 메모리를 압축하므로 조만간 THP를 사용할 수 있습니다. TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE: 애플리케이션이 평소와 같이 직접 회수 및 압축을 시작하지만 madvise(MADV_HUGEPAGE)를 사용한 리전에만 해당합니다. 다른 모든 리전에서는 백그라운드에서 kswapd를 작동시켜 페이지를 회수하고 kcompactd를 작동시켜 메모리를 압축하므로 조만간 THP를 사용할 수 있습니다. TRANSPARENT_HUGEPAGE_DEFRAG_NEVER: 애플리케이션이 직접 회수 또는 압축을 시작하지 않습니다. TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED: 기본값입니다. GKE가 커널 구성을 수정하지 않습니다.	UNSPECIFIED	이 설정은 THP의 조각 모음 구성을 정의합니다.

THP는 GKE 버전 1.33.2-gke.4655000 이상에서 사용할 수 있습니다. 또한 GKE 버전 1.33.2-gke.4655000 이상에서는 새 TPU 노드 풀에서 기본적으로 사용 설정됩니다. 기존 노드 풀을 지원되는 버전 이상으로 업그레이드하면 THP가 사용 설정되지 않습니다.

다음 단계

• 노드 풀에 대해 자세히 알아보기
• 노드 풀을 만드는 방법 알아보기