컨테이너가 아닌 리눅스로 Kubernetes 노드의 리소스 제어하기

Kubernetes 노드에서 컨테이너 없이 리소스 제어하기: 완벽 가이드

Kubernetes는 컨테이너 오케스트레이션의 대명사이지만, 항상 컨테이너가 모든 워크로드에 적합한 것은 아닙니다. 레거시 애플리케이션, 특정 시스템 유틸리티, 또는 높은 성능 요구 사항을 가진 워크로드의 경우, 컨테이너 없이 직접 Kubernetes 노드에서 실행하는 것이 더 효율적일 수 있습니다. 이러한 경우, 리소스 제어는 안정적인 시스템 운영을 위해 매우 중요합니다. 이 가이드에서는 컨테이너 없이 Kubernetes 노드에서 실행되는 워크로드에 대한 리소스 제어 전략과 방법을 자세히 살펴봅니다.

컨테이너 없이 Kubernetes 노드에서 워크로드를 실행하는 이유

컨테이너는 격리, 이식성, 확장성과 같은 많은 이점을 제공하지만, 모든 상황에 적합한 솔루션은 아닙니다. 다음과 같은 경우 컨테이너 없이 워크로드를 실행하는 것이 고려될 수 있습니다.

컨테이너 없이 실행되는 워크로드의 리소스 제어 중요성

컨테이너 없이 워크로드를 실행할 때 리소스 제어가 중요한 이유는 다음과 같습니다.

컨테이너 없이 리소스 제어하는 방법

컨테이너 없이 Kubernetes 노드에서 워크로드를 실행하는 경우, 다음과 같은 방법을 사용하여 리소스를 제어할 수 있습니다.

1. cgroups (Control Groups)

cgroups는 Linux 커널 기능으로, 프로세스 그룹의 리소스 사용량을 제한, 격리 및 측정하는 데 사용됩니다. Kubernetes는 컨테이너 리소스 관리에 cgroups를 사용하지만, 컨테이너 없이 실행되는 워크로드에도 적용할 수 있습니다.

사용 방법:

    • cgroup을 생성합니다. 예를 들어, “my-workload”라는 cgroup을 생성하려면 다음과 같이 합니다. 
      mkdir /sys/fs/cgroup/cpu/my-workload

mkdir /sys/fs/cgroup/memory/my-workload
    • CPU 및 메모리 제한을 설정합니다. 
      echo "100000" > /sys/fs/cgroup/cpu/my-workload/cpu.cfs_quota_us  # CPU 사용량 10% 제한

echo "1G" > /sys/fs/cgroup/memory/my-workload/memory.limit_in_bytes  # 메모리 1GB 제한
    • 워크로드 프로세스를 cgroup에 추가합니다. 워크로드 프로세스의 PID (Process ID)를 알아낸 후, 다음 명령을 사용합니다. 
      echo [PID] > /sys/fs/cgroup/cpu/my-workload/tasks

echo [PID] > /sys/fs/cgroup/memory/my-workload/tasks

주의 사항: cgroups를 직접 관리하는 것은 복잡할 수 있습니다. systemd와 같은 도구를 사용하여 cgroup을 관리하는 것이 더 편리할 수 있습니다.

2. systemd

systemd는 Linux 시스템의 시스템 및 서비스 관리자입니다. cgroups를 사용하여 프로세스의 리소스 사용량을 관리하는 기능을 제공합니다. systemd 서비스 파일을 사용하여 리소스 제한을 정의하고 관리할 수 있습니다.

사용 방법:

    • systemd 서비스 파일을 생성합니다. 예를 들어, “/etc/systemd/system/my-workload.service” 파일을 다음과 같이 작성합니다. 
      [Unit]

Description=My Workload


[Service]

ExecStart=/path/to/my/workload

CPUQuota=10%

MemoryLimit=1G

Restart=on-failure


[Install]

WantedBy=multi-user.target
      • CPUQuota는 CPU 사용량 제한을 설정합니다.
      • MemoryLimit은 메모리 사용량 제한을 설정합니다.
    • 서비스를 활성화하고 시작합니다. 
      systemctl enable my-workload.service

systemctl start my-workload.service

장점: systemd는 cgroups를 쉽게 관리할 수 있도록 추상화된 인터페이스를 제공하며, 서비스의 시작, 중지, 재시작 등과 같은 추가적인 관리 기능을 제공합니다.

3. Linux Resource Limits (ulimit)

ulimit 명령은 사용자 프로세스가 사용할 수 있는 시스템 리소스의 제한을 설정하는 데 사용됩니다. CPU 시간, 파일 크기, 메모리 사용량 등 다양한 리소스에 대한 제한을 설정할 수 있습니다.

사용 방법:

    • 리소스 제한을 설정합니다. 예를 들어, 메모리 사용량을 1GB로 제한하려면 다음과 같이 합니다. 
      ulimit -v 1048576  # 메모리 1GB (KB 단위)
    • 워크로드를 실행합니다. ulimit 명령을 실행한 쉘에서 워크로드를 실행하면 설정된 제한이 적용됩니다.

주의 사항: ulimit은 사용자 수준의 제한을 설정하며, 시스템 전체에 영향을 미치지 않습니다. 또한, ulimit으로 설정된 제한은 현재 쉘 세션에서만 유효합니다. 영구적인 제한을 설정하려면 “/etc/security/limits.conf” 파일을 수정해야 합니다.

4. Kubernetes DaemonSet을 활용한 리소스 관리

만약 컨테이너 없이 실행되는 워크로드가 모든 노드에서 실행되어야 하는 시스템 데몬과 같은 성격을 가진다면, DaemonSet을 활용하여 리소스를 관리할 수 있습니다. DaemonSet은 각 노드에 특정 Pod(이 경우 컨테이너가 없는 Pod)를 실행하도록 보장합니다. Pod Spec에 리소스 제한 (resources.limits)을 정의하여 각 노드에서 실행되는 워크로드의 리소스를 제어할 수 있습니다.

사용 방법:

    • 컨테이너가 없는 Pod 정의를 포함하는 DaemonSet YAML 파일을 작성합니다. 예를 들어, “my-daemonset.yaml” 파일을 다음과 같이 작성합니다. 
      apiVersion: apps/v1

kind: DaemonSet

metadata:

  name: my-workload-daemonset

spec:

  selector:

    matchLabels:

      name: my-workload

  template:

    metadata:

      labels:

        name: my-workload

    spec:

      hostPID: true

      hostNetwork: true

      hostIPC: true

      containers:

      - name: my-workload-container

        image: busybox:latest  # 더미 컨테이너 이미지

        command: ["/bin/sh", "-c", "sleep infinity"]  # 컨테이너를 계속 실행 상태로 유지

        securityContext:

          privileged: true  # 필요한 경우 권한 상승

        resources:

          limits:

            cpu: "100m"  # CPU 10% 제한

            memory: "100Mi"  # 메모리 100MB 제한

        volumeMounts:

        - name: host-root

          mountPath: /host

      volumes:

      - name: host-root

        hostPath:

          path: /

  updateStrategy:

    type: RollingUpdate
      • hostPID: true, hostNetwork: true, hostIPC: true는 Pod가 노드의 PID, 네트워크, IPC 네임스페이스를 공유하도록 설정합니다.
      • securityContext: privileged: true는 Pod에 필요한 권한을 부여합니다 (필요한 경우에만 사용).
      • resources.limits는 Pod의 리소스 제한을 설정합니다.
      • volumeMounts는 노드의 파일 시스템에 접근할 수 있도록 설정합니다.
    • DaemonSet을 생성합니다. 
      kubectl apply -f my-daemonset.yaml
    • DaemonSet 내에서 실행되는 워크로드를 시작합니다. DaemonSet에 의해 생성된 Pod 내부에서 워크로드를 실행합니다. 예를 들어, kubectl exec 명령을 사용하여 Pod에 접속하여 워크로드를 실행할 수 있습니다.

주의 사항: 이 방법은 컨테이너가 없는 워크로드를 컨테이너 환경 내에서 관리하는 것이므로, 컨테이너 실행에 필요한 최소한의 오버헤드가 발생합니다. 하지만 Kubernetes API를 사용하여 리소스를 관리할 수 있다는 장점이 있습니다. 더미 컨테이너를 사용하므로 컨테이너 이미지는 최소한의 크기를 갖는 것을 사용하는 것이 좋습니다.

유용한 팁과 조언

흔한 오해와 사실 관계

자주 묻는 질문과 답변

Q: 컨테이너 없이 실행되는 워크로드의 리소스 제한을 동적으로 변경할 수 있습니까?

A: systemd를 사용하는 경우, 서비스 파일을 수정하고 systemctl daemon-reload 명령을 실행하여 리소스 제한을 동적으로 변경할 수 있습니다. cgroups를 직접 사용하는 경우, 해당 cgroup의 리소스 제한 파일을 수정하여 동적으로 변경할 수 있습니다.

Q: 컨테이너 없이 실행되는 워크로드의 리소스 사용량을 어떻게 모니터링할 수 있습니까?

A: top, htop, ps 등의 명령어를 사용하여 워크로드의 리소스 사용량을 모니터링할 수 있습니다. 또한, Prometheus, Grafana, cAdvisor 등의 도구를 사용하여 시각적으로 모니터링할 수 있습니다. systemd를 사용하는 경우, systemctl status 명령을 사용하여 서비스의 상태와 리소스 사용량을 확인할 수 있습니다.

Q: 어떤 방법을 선택해야 할까요?

A: 워크로드의 특성, 관리 복잡성, 필요한 기능 등을 고려하여 적절한 방법을 선택해야 합니다. 간단한 리소스 제한만 필요한 경우 ulimit을 사용할 수 있습니다. systemd는 서비스 관리 기능과 함께 cgroups를 쉽게 관리할 수 있도록 제공합니다. Kubernetes API를 활용하고 싶다면 DaemonSet을 활용하는 방법을 고려할 수 있습니다.

비용 효율적인 활용 방법

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다