Windows HostProcess 파드 만들기

Windows HostProcess 파드 만들기 (Create a Windows HostProcess Pod)

Windows HostProcess 컨테이너는 Windows 호스트에서 컨테이너화된 워크로드를 실행할 수 있게 해줘요. 이 컨테이너는 일반 프로세스처럼 동작하지만, 적절한 사용자 권한이 주어지면 호스트 네트워크 네임스페이스, 저장소, 장치에 접근할 수 있어요. HostProcess 컨테이너는 전용 프록시나 호스트 서비스의 직접 설치 없이도 네트워크 플러그인, 저장소 구성, 장치 플러그인, kube-proxy 및 기타 구성 요소를 Windows 노드에 배포하는 데 사용할 수 있어요.

보안 패치 설치, 이벤트 로그 수집 같은 관리 작업을 클러스터 운영자가 각 Windows 노드에 로그온하지 않고도 수행할 수 있어요. HostProcess 컨테이너는 호스트에서 사용 가능하거나 호스트 머신의 도메인에 있는 어떤 사용자로든 실행할 수 있어서, 관리자는 사용자 권한을 통해 리소스 접근을 제한할 수 있어요. 파일시스템이나 프로세스 격리는 지원되지 않지만, 컨테이너 시작 시 호스트에 새 볼륨이 생성되어 깨끗하고 통합된 작업 공간을 제공해요. HostProcess 컨테이너는 기존 Windows 기본 이미지 위에 구축할 수도 있으며, Windows 서버 컨테이너와 같은 호환성 요구 사항을 상속하지 않아 기본 이미지의 버전이 호스트와 일치할 필요가 없어요. 다만 Windows Server 컨테이너 워크로드와 같은 기본 이미지 버전을 사용해 노드에 사용하지 않는 이미지가 공간을 차지하지 않도록 하는 것이 권장돼요. HostProcess 컨테이너는 컨테이너 볼륨 안의 볼륨 마운트도 지원해요.

Windows HostProcess 컨테이너는 언제 사용해야 하나?

호스트의 네트워킹 네임스페이스가 필요한 작업을 수행할 때. HostProcess 컨테이너는 호스트의 네트워크 인터페이스와 IP 주소에 접근할 수 있어요.
파일시스템, 이벤트 로그 같은 호스트의 리소스에 접근해야 할 때.
특정 장치 드라이버나 Windows 서비스의 설치.
관리 작업과 보안 정책의 통합. 이는 Windows 노드가 필요로 하는 권한의 정도를 줄여 줘요.

출처: 문서

본문

시작하기 전에

이 작업 가이드는 쿠버네티스 v1.37에 특화돼 있어요. 쿠버네티스 v1.37이 아니라면 해당 버전의 쿠버네티스 문서를 확인하세요.

쿠버네티스 1.37에서 HostProcess 컨테이너 기능은 기본적으로 활성화돼 있어요. kubelet은 CRI를 통해 hostprocess 플래그를 전달해 containerd와 직접 통신해요. HostProcess 컨테이너를 실행하려면 최신 containerd(v1.6+)를 사용할 수 있어요. containerd 설치 방법.

제한 사항 (Limitations)

이 제한 사항은 쿠버네티스 v1.37과 관련이 있어요.

HostProcess 컨테이너는 containerd 1.6 이상 컨테이너 런타임이 필요하며 containerd 1.7이 권장돼요.
HostProcess 파드는 HostProcess 컨테이너만 포함할 수 있어요. 이는 Windows OS의 현재 제한 사항으로, 비권한 Windows 컨테이너는 호스트 IP 네임스페이스와 vNIC를 공유할 수 없어요.
HostProcess 컨테이너는 호스트에서 프로세스로 실행되며, HostProcess 사용자 계정에 부과된 리소스 제약 외에는 어떤 격리도 갖지 않아요. HostProcess 컨테이너에는 파일시스템이나 Hyper-V 격리가 지원되지 않아요.
볼륨 마운트가 지원되며 컨테이너 볼륨 아래에 마운트돼요. 볼륨 마운트 문서 참고.
기본으로 HostProcess 컨테이너에 사용할 수 있는 호스트 사용자 계정 집합은 제한적이에요. '사용자 계정 선택' 참고.
리소스 한도(디스크, 메모리, CPU 수)는 호스트의 프로세스와 같은 방식으로 지원돼요.
Named pipe 마운트와 Unix 도메인 소켓은 지원되지 않으며, 대신 호스트의 해당 경로(예: \\.\pipe\*)로 접근해야 해요.

HostProcess 파드 구성 요구 사항

Windows HostProcess 파드를 활성화하려면 파드 보안 구성에서 올바른 구성을 설정해야 해요. 파드 보안 표준에 정의된 정책 중 HostProcess 파드는 baseline과 restricted 정책에서 허용되지 않아요. 따라서 HostProcess 파드는 privileged 프로필에 맞춰 실행하는 것이 권장돼요.

privileged 정책에서 실행할 때 HostProcess 파드 생성을 활성화하기 위해 설정해야 하는 구성은 다음과 같아요.

제어 항목	정책
securityContext.windowsOptions.hostProcess	Windows 파드는 Windows 노드에 권한 있는 접근을 가능하게 하는 HostProcess 컨테이너 실행을 제공함. 허용 값: true
hostNetwork	HostProcess 컨테이너를 포함하는 파드는 호스트의 네트워크 네임스페이스를 사용해야 함. 허용 값: true
securityContext.windowsOptions.runAsUserName	HostProcess 컨테이너가 어떤 사용자로 실행되어야 하는지의 지정이 파드 스펙에 필요함. 허용 값: NT AUTHORITY\SYSTEM, NT AUTHORITY\Local service, NT AUTHORITY\NetworkService, 로컬 사용자 그룹 이름(아래 참고)
runAsNonRoot	HostProcess 컨테이너는 호스트에 권한 있는 접근을 가지므로 runAsNonRoot 필드를 true로 설정할 수 없음. 허용 값: 정의되지 않음/Nil, false

예시 매니페스트 (일부)

spec:
  securityContext:
    windowsOptions:
      hostProcess: true
      runAsUserName: "NT AUTHORITY\\Local service"
  hostNetwork: true
  containers:
  - name: test
    image: image1:latest
    command:
      - ping
      - -t
      - 127.0.0.1
  nodeSelector:
    "kubernetes.io/os": windows

볼륨 마운트 (Volume mounts)

HostProcess 컨테이너는 컨테이너 볼륨 공간 안에 볼륨을 마운트하는 기능을 지원해요. 볼륨 마운트 동작은 노드에서 사용되는 containerd 런타임의 버전에 따라 달라져요.

Containerd v1.6

컨테이너 안에서 실행되는 애플리케이션은 상대 경로 또는 절대 경로로 볼륨 마운트에 직접 접근할 수 있어요. 컨테이너 생성 시 $CONTAINER_SANDBOX_MOUNT_POINT 환경 변수가 설정되며, 컨테이너 볼륨의 절대 호스트 경로를 제공해요. 상대 경로는 .spec.containers.volumeMounts.mountPath 구성에 기반해요.

예를 들어 서비스 계정 토큰에 접근하려면 컨테이너 안에서 다음 경로 구조가 지원돼요.

.\var\run\secrets\kubernetes.io\serviceaccount\
$CONTAINER_SANDBOX_MOUNT_POINT\var\run\secrets\kubernetes.io\serviceaccount\

Containerd v1.7 (및 그 이상)

컨테이너 안에서 실행되는 애플리케이션은 volumeMount의 지정된 mountPath로 볼륨 마운트에 직접 접근할 수 있어요(Linux 및 비-HostProcess Windows 컨테이너처럼).

역호환성을 위해 볼륨은 containerd v1.6이 구성한 것과 같은 상대 경로로도 접근할 수 있어요.

예를 들어 컨테이너 안에서 서비스 계정 토큰에 접근하려면 다음 경로 중 하나를 사용할 거예요.

c:\var\run\secrets\kubernetes.io\serviceaccount
/var/run/secrets/kubernetes.io/serviceaccount/
$CONTAINER_SANDBOX_MOUNT_POINT\var\run\secrets\kubernetes.io\serviceaccount\

리소스 한도 (Resource limits)

리소스 한도(디스크, 메모리, CPU 수)는 작업(job)에 적용되며 작업 전체에 걸쳐 적용돼요. 예를 들어 10MB 한도가 설정되면 어떤 HostProcess 작업 객체에 할당된 메모리도 10MB로 제한돼요. 이는 다른 Windows 컨테이너 유형과 같은 동작이에요. 이러한 한도는 현재 어떤 오케스트레이터나 런타임을 사용하든 그와 같은 방식으로 지정하면 돼요. 유일한 차이는 HostProcess 컨테이너가 부트스트랩되는 방식의 차이로 인한 리소스 추적에 사용되는 디스크 리소스 사용 계산이에요.

사용자 계정 선택 (Choosing a user account)

시스템 계정 (System accounts)

기본적으로 HostProcess 컨테이너는 지원되는 세 가지 Windows 서비스 계정 중 하나로 실행될 수 있어요.

LocalSystem
LocalService
NetworkService

각 HostProcess 컨테이너에 적절한 Windows 서비스 계정을 선택해서, 권한의 정도를 제한해 호스트에 우발적(또는 악의적) 손상을 피해야 해요. LocalSystem 서비스 계정은 세 가지 중 가장 높은 수준의 권한을 가지며 절대적으로 필요할 때만 사용해야 해요. 가능하면 세 옵션 중 가장 권한이 적은 LocalService 서비스 계정을 사용하세요.

로컬 계정 (Local accounts)

구성되면 HostProcess 컨테이너는 로컬 사용자 계정으로도 실행될 수 있어, 노드 운영자가 워크로드에 세밀한 접근 권한을 줄 수 있어요.

HostProcess 컨테이너를 로컬 사용자로 실행하려면; 먼저 노드에 로컬 사용자 그룹을 만들어야 하고, 그 로컬 사용자 그룹의 이름을 배포의 runAsUserName 필드에 지정해야 해요. HostProcess 컨테이너를 초기화하기 전에 새 임시 로컬 사용자 계정이 만들어지고 지정된 사용자 그룹에 조인되며, 그 계정으로 컨테이너가 실행돼요. 이는 로컬 사용자 계정의 비밀번호를 관리할 필요를 없애는 등 여러 이점을 제공해요. 서비스 계정으로 실행되는 초기 HostProcess 컨테이너를 사용해 이후 HostProcess 컨테이너를 위한 사용자 그룹을 준비할 수 있어요.

참고:

예시:

노드에 로컬 사용자 그룹을 만들어요(다른 HostProcess 컨테이너에서 할 수 있어요).

net localgroup hpc-localgroup /add

노드의 원하는 리소스에 대한 접근 권한을 로컬 사용자 그룹에 부여해요. 이는 icacls 같은 도구로 할 수 있어요.
파드 또는 개별 컨테이너에 대해 runAsUserName을 로컬 사용자 그룹의 이름으로 설정해요.

securityContext:
  windowsOptions:
    hostProcess: true
    runAsUserName: hpc-localgroup

파드를 스케줄링하세요!

HostProcess 컨테이너용 기본 이미지 (Base Image for HostProcess Containers)

HostProcess 컨테이너는 기존 Windows 컨테이너 기본 이미지 중 아무거나 사용해 빌드할 수 있어요.

추가로 HostProcess 컨테이너 전용으로 새 기본 이미지도 만들어졌어요! 자세한 내용은 windows-host-process-containers-base-image GitHub 프로젝트를 확인해 보세요.

HostProcess 컨테이너 문제 해결 (Troubleshooting HostProcess containers)

HostProcess 컨테이너가 failed to create user process token: failed to logon user: Access is denied.: unknown 오류로 시작에 실패해요. containerd가 LocalSystem 또는 LocalService 서비스 계정으로 실행 중인지 확인하세요. 사용자 계정(관리자 계정을 포함해도)은 지원되는 사용자 계정 중 어느 것으로도 로그온 토큰을 만들 권한이 없어요.

Windows HostProcess 파드 만들기