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

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

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

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

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

• 레거시 애플리케이션: 컨테이너화하기 어려운 오래된 애플리케이션의 경우, Kubernetes 노드에서 직접 실행하는 것이 더 실용적일 수 있습니다.

• 성능 요구 사항: 컨테이너 오버헤드가 성능에 영향을 미칠 수 있는 경우, 컨테이너 없이 실행하여 최적의 성능을 달성할 수 있습니다.
• 시스템 유틸리티: 노드 수준의 시스템 관리 도구나 유틸리티는 컨테이너 외부에서 실행되어야 하는 경우가 많습니다.
• 보안 고려 사항: 특정 보안 요구 사항으로 인해 컨테이너 격리가 충분하지 않다고 판단될 경우, 직접 실행이 선호될 수 있습니다.

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

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

• 리소스 경합 방지: 워크로드가 노드의 리소스(CPU, 메모리, 디스크 I/O 등)를 과도하게 사용하는 것을 방지합니다.

• 시스템 안정성 유지: 리소스 부족으로 인해 노드가 불안정해지거나 다운되는 것을 방지합니다.
• 예측 가능한 성능 보장: 다른 워크로드에 영향을 주지 않고 각 워크로드에 필요한 리소스를 할당합니다.
• 보안 강화: 악성 워크로드가 시스템 리소스를 독점하거나 다른 워크로드에 영향을 미치는 것을 방지합니다.

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

컨테이너 없이 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를 사용하여 리소스를 관리할 수 있다는 장점이 있습니다. 더미 컨테이너를 사용하므로 컨테이너 이미지는 최소한의 크기를 갖는 것을 사용하는 것이 좋습니다.

유용한 팁과 조언

• 모니터링: 워크로드의 리소스 사용량을 지속적으로 모니터링하여 리소스 제한이 적절하게 설정되었는지 확인합니다. Prometheus, Grafana, cAdvisor 등의 도구를 사용하여 리소스 사용량을 모니터링할 수 있습니다.
• 테스트: 리소스 제한을 변경하기 전에 테스트 환경에서 변경 사항을 테스트하여 예상치 못한 문제가 발생하지 않도록 합니다.
• 문서화: 리소스 제한 설정 및 관리 방법을 문서화하여 다른 사용자가 쉽게 이해하고 관리할 수 있도록 합니다.
• 자동화: Ansible, Chef, Puppet 등의 구성 관리 도구를 사용하여 리소스 제한 설정을 자동화합니다.
• 보안: 워크로드가 악의적인 행위를 수행하지 않도록 보안 설정을 강화합니다. AppArmor, SELinux 등의 도구를 사용하여 보안을 강화할 수 있습니다.

흔한 오해와 사실 관계

• 오해: 컨테이너 없이 실행되는 워크로드는 리소스 제어가 불가능하다.

• 사실: cgroups, systemd, ulimit 등의 도구를 사용하여 컨테이너 없이 실행되는 워크로드의 리소스 사용량을 제어할 수 있습니다.
• 오해: 컨테이너 없이 실행되는 워크로드는 보안에 취약하다.
• 사실: 적절한 보안 설정을 통해 컨테이너 없이 실행되는 워크로드의 보안을 강화할 수 있습니다.
• 오해: Kubernetes는 컨테이너만을 위한 플랫폼이다.
• 사실: Kubernetes는 컨테이너 오케스트레이션 플랫폼이지만, DaemonSet과 같은 기능을 활용하여 컨테이너 없이 실행되는 워크로드도 관리할 수 있습니다.

자주 묻는 질문과 답변

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을 활용하는 방법을 고려할 수 있습니다.

비용 효율적인 활용 방법

• 리소스 최적화: 워크로드에 필요한 최소한의 리소스를 할당하여 리소스 낭비를 줄입니다.

• 자동 스케일링: 워크로드의 부하에 따라 자동으로 리소스를 조정하여 비용 효율성을 높입니다.
• 클라우드 리소스 활용: 클라우드 플랫폼에서 제공하는 리소스 관리 기능을 활용하여 비용을 절감합니다.
• 모니터링 및 분석: 리소스 사용량을 지속적으로 모니터링하고 분석하여 비효율적인 부분을 개선합니다.