쿠버네티스의 Windows 컨테이너

쿠버네티스의 Windows 컨테이너 (Windows containers in Kubernetes)

Windows 애플리케이션은 많은 조직에서 실행되는 서비스와 애플리케이션의 상당 부분을 차지해요. Windows 컨테이너는 프로세스와 패키지 종속성을 캡슐화하는 방법을 제공해 Windows 애플리케이션에 DevOps 관행을 사용하고 클라우드 네이티브 패턴을 따르기 더 쉽게 만들어요.

Windows 기반 애플리케이션과 Linux 기반 애플리케이션에 투자한 조직은 워크로드를 관리하기 위해 별도의 오케스트레이터를 찾을 필요가 없어, 운영 체제에 관계없이 배포 전반에 걸쳐 운영 효율을 높일 수 있어요.

출처: 문서

본문

쿠버네티스의 Windows 노드

쿠버네티스에서 Windows 컨테이너 오케스트레이션을 활성화하려면 기존 Linux 클러스터에 Windows 노드를 포함해요. 쿠버네티스의 Pods에서 Windows 컨테이너를 스케줄링하는 것은 Linux 기반 컨테이너를 스케줄링하는 것과 비슷해요.

Windows 컨테이너를 실행하려면 쿠버네티스 클러스터가 여러 운영 체제를 포함해야 해요. 제어 플레인은 Linux에서만 실행할 수 있지만, 워커 노드는 Windows 또는 Linux 중 어느 쪽이든 실행하도록 배포할 수 있어요.

Windows 노드는 운영 체제가 Windows Server 2022 또는 Windows Server 2025인 경우 지원돼요.

이 문서는 Windows 컨테이너 라는 용어를 프로세스 격리를 가진 Windows 컨테이너를 의미하는 데 사용해요. 쿠버네티스는 Hyper-V 격리를 가진 Windows 컨테이너 실행을 지원하지 않아요.

호환성과 제한 사항

일부 노드 기능은 특정 컨테이너 런타임을 사용할 때만 사용할 수 있어요. 다른 것들은 Windows 노드에서 사용할 수 없어요. 다음이 포함돼요:

  • HugePages: Windows 컨테이너에서 지원되지 않음
  • Privileged containers: Windows 컨테이너에서 지원되지 않음. HostProcess Containers가 유사한 기능을 제공해요.
  • TerminationGracePeriod: containerD 필요

공유 네임스페이스의 모든 기능이 지원되는 것은 아니에요. 자세한 내용은 API 호환성을 참고해요.

쿠버네티스가 테스트되는 Windows 버전에 대한 자세한 내용은 Windows OS 버전 호환성을 참고해요.

API와 kubectl 관점에서 Windows 컨테이너는 Linux 기반 컨테이너와 대체로 같은 방식으로 동작해요. 하지만 이 섹션에서 개괄하는 핵심 기능에는 몇 가지 눈에 띄는 차이가 있어요.

Linux와의 비교

핵심 쿠버네티스 요소는 Windows에서 Linux와 같은 방식으로 동작해요. 이 섹션은 몇 가지 핵심 워크로드 추상화와 그것들이 Windows에 어떻게 매핑되는지 언급해요.

Pods, 워크로드 리소스, Services는 쿠버네티스에서 Windows 워크로드를 관리하는 중요한 요소예요. 하지만 이들만으로는 동적 클라우드 네이티브 환경에서 Windows 워크로드의 적절한 수명주기 관리를 활성화하기에 충분하지 않아요.

kubelet 명령줄 옵션

일부 kubelet 명령줄 옵션은 Windows에서 다르게 동작하며, 아래에 설명돼 있어요:

  • --windows-priorityclass 는 kubelet 프로세스의 스케줄링 우선순위를 설정하게 해줘요(CPU 리소스 관리 참고)
  • --kube-reserved, --system-reserved, --eviction-hard 플래그는 NodeAllocatable을 업데이트해요
  • --enforce-node-allocable 을 사용한 축출(eviction)은 구현되지 않아요
  • Windows 노드에서 실행될 때 kubelet에는 메모리·CPU 제한이 없어요. --kube-reserved 와 --system-reserved 는 NodeAllocatable 에서만 차감하고 워크로드에 제공되는 리소스를 보장하지 않아요. Windows 노드용 리소스 관리를 참고해요.
  • PIDPressure Condition은 구현되지 않아요
  • kubelet은 OOM 축출 조치를 취하지 않아요

API 호환성

Windows에서 쿠버네티스 API가 동작하는 방식에는 OS와 컨테이너 런타임 때문에 미묘한 차이가 있어요. 일부 워크로드 속성은 Linux용으로 설계되어 Windows에서 실행에 실패해요.

높은 수준에서 이 OS 개념들은 다릅니다:

  • 정체성(Identity) - Linux는 정수 유형으로 표현되는 userID (UID)와 groupID (GID)를 사용해요. 사용자·그룹 이름은 표준적이지 않으며 /etc/groups 또는 /etc/passwd 에서 UID+GID로 되돌아가는 별칭일 뿐이에요. Windows는 Windows Security Access Manager (SAM) 데이터베이스에 저장되는 더 큰 이진 보안 식별자 (SID)를 사용해요. 이 데이터베이스는 호스트와 컨테이너 사이, 또는 컨테이너 사이에서 공유되지 않아요.
  • 파일 권한 - Windows는 (SID에 기반한) 접근 제어 목록을 사용하는 반면, Linux 같은 POSIX 시스템은 객체 권한과 UID+GID, 그리고 선택적 접근 제어 목록에 기반한 비트마스크를 사용해요.
  • 파일 경로 - Windows의 관례는 / 대신 \ 를 사용하는 것이에요. Go IO 라이브러리는 보통 둘 다 받아들이고 그냥 동작하게 하지만, 컨테이너 안에서 해석되는 경로나 명령줄을 설정할 때는 \ 가 필요할 수 있어요.
  • 시그널(Signals) - Windows 대화형 앱은 종료를 다르게 처리하며, 다음 중 하나 이상을 구현할 수 있어요:

컨테이너 종료 코드는 0이 성공이고 0이 아닌 값이 실패인 같은 관례를 따르지만, 특정 오류 코드는 Windows와 Linux에서 다를 수 있어요. 그러나 쿠버네티스 컴포넌트(kubelet, kube-proxy)에서 전달되는 종료 코드는 변경되지 않아요.

컨테이너 스펙 필드 호환성

다음 목록은 Pod 컨테이너 스펙이 Windows와 Linux에서 어떻게 다른지 문서화해요:

  • Huge pages는 Windows 컨테이너 런타임에서 구현되지 않으며 사용할 수 없어요. 컨테이너에 대해 구성할 수 없는 사용자 권리 단언이 필요해요.
  • requests.cpu 와 requests.memory - 요청은 노드 사용 가능 리소스에서 차감되므로 노드의 과도한 프로비저닝을 피하는 데 사용할 수 있어요. 하지만 과도하게 프로비저닝된 노드에서 리소스를 보장하는 데는 사용할 수 없어요. 운영자가 과도한 프로비저닝을 완전히 피하려면 모범 사례로 모든 컨테이너에 적용해야 해요.
  • securityContext.allowPrivilegeEscalation - Windows에서 불가능하며, 그 중 어떤 capabilities도 연결되지 않아요
  • securityContext.capabilities - POSIX capabilities는 Windows에서 구현되지 않아요
  • securityContext.privileged - Windows는 privileged 컨테이너를 지원하지 않으므로 HostProcess Containers를 대신 사용해요
  • securityContext.procMount - Windows에는 /proc 파일 시스템이 없어요
  • securityContext.readOnlyRootFilesystem - Windows에서 불가능해요. 컨테이너 안에서 실행되는 레지스트리·시스템 프로세스에 쓰기 접근이 필요해요
  • securityContext.runAsGroup - Windows에는 GID 지원이 없으므로 불가능해요
  • securityContext.runAsNonRoot - 이 설정은 Windows에서 root 사용자와 가장 가까운 동등물인 ContainerAdministrator 로 컨테이너가 실행되는 것을 방지해요.
  • securityContext.runAsUser - 대신 runAsUserName을 사용해요
  • securityContext.seLinuxOptions - SELinux는 Linux 전용이므로 Windows에서 불가능해요
  • terminationMessagePath - Windows는 단일 파일 매핑을 지원하지 않아 약간의 제한이 있어요. 기본값 /dev/termination-log 는 Windows에서 기본적으로 존재하지 않으므로 동작해요.
Pod 스펙 필드 호환성

다음 목록은 Pod 스펙이 Windows와 Linux에서 어떻게 다른지 문서화해요:

  • hostIPC 와 hostpid - 호스트 네임스페이스 공유는 Windows에서 불가능해요
  • hostNetwork - 호스트 네트워킹은 Windows에서 불가능해요
  • dnsPolicy - Pod dnsPolicy 를 ClusterFirstWithHostNet 으로 설정하는 것은 호스트 네트워킹이 제공되지 않으므로 Windows에서 지원되지 않아요. 파드는 항상 컨테이너 네트워크로 실행돼요.
  • podSecurityContext 아래 참고
  • shareProcessNamespace - 이는 beta 기능이며 Windows에서 구현되지 않은 Linux 네임스페이스에 의존해요. Windows는 프로세스 네임스페이스나 컨테이너의 root 파일 시스템을 공유할 수 없어요. 네트워크만 공유할 수 있어요.
  • terminationGracePeriodSeconds - 이는 Windows의 Docker에서 완전히 구현되지 않았어요. GitHub issue 참고. 오늘날의 동작은 ENTRYPOINT 프로세스에 CTRL_SHUTDOWN_EVENT가 전송된 후 Windows가 기본적으로 5초를 기다린 다음, 정상적인 Windows 종료 동작으로 모든 프로세스를 종료하는 것이에요. 5초 기본값은 실제로 Windows 레지스트리 컨테이너 안의 에 있어 컨테이너를 빌드할 때 재정의할 수 있어요.
  • volumeDevices - 이는 beta 기능이며 Windows에서 구현되지 않았어요. Windows는 raw 블록 장치를 파드에 연결할 수 없어요.
  • volumes
  • 볼륨 마운트에서 mountPropagation 을 활성화할 수 없어요. Windows에서 지원되지 않기 때문이에요.
호스트 네트워크 접근

쿠버네티스 v1.26부터 v1.32는 호스트의 네트워크 네임스페이스에서 Windows Pod를 실행하는 alpha 지원을 포함했어요.

쿠버네티스 v1.37은 WindowsHostNetwork 기능 게이트나 호스트의 네트워크 네임스페이스에서 Windows Pod를 실행하는 지원을 포함하지 않아요.

Pod 보안 컨텍스트 필드 호환성

Pod securityContext 필드 중 securityContext.runAsNonRoot 와 securityContext.windowsOptions 만 Windows에서 동작해요.

노드 문제 감지기 (Node problem detector)

노드 문제 감지기(노드 건강 모니터링 참고)는 Windows에 대한 예비 지원을 가져요. 자세한 내용은 프로젝트의 GitHub 페이지를 방문해요.

Pause 컨테이너

쿠버네티스 Pod에서 인프라 또는 "pause" 컨테이너가 컨테이너를 호스팅하기 위해 먼저 만들어져요. Linux에서 파드를 구성하는 cgroups와 네임스페이스는 계속 존재를 유지할 프로세스가 필요하며, pause 프로세스가 이를 제공해요. 같은 파드에 속하는 컨테이너(인프라와 워커 컨테이너 포함)는 공통 네트워크 엔드포인트(같은 IPv4 및/또는 IPv6 주소, 같은 네트워크 포트 공간)를 공유해요. 쿠버네티스는 pause 컨테이너를 사용해 워커 컨테이너가 네트워킹 구성을 잃지 않고 충돌하거나 재시작할 수 있게 해요.

쿠버네티스는 Windows 지원을 포함하는 다중 아키텍처 이미지를 유지해요. 쿠버네티스 v1.37.0의 권장 pause 이미지는 registry.k8s.io/pause:3.6 이에요. 소스 코드는 GitHub에서 사용할 수 있어요.

Microsoft는 Linux와 Windows amd64 지원을 가진 다른 다중 아키텍처 이미지를 유지하며, mcr.microsoft.com/oss/kubernetes/pause:3.6 로 찾을 수 있어요. 이 이미지는 쿠버네티스가 유지하는 이미지와 같은 소스에서 빌드되지만 모든 Windows 바이너리는 Microsoft가 authenticode 서명했어요. 쿠버네티스 프로젝트는 서명된 바이너리가 필요한 프로덕션 또는 프로덕션 유사 환경에 배포한다면 Microsoft가 유지하는 이미지를 사용할 것을 권장해요.

컨테이너 런타임

클러스터의 각 노드에 컨테이너 런타임을 설치해서 거기서 파드가 실행될 수 있게 해야 해요.

다음 컨테이너 런타임은 Windows에서 동작해요:

ContainerD

Windows를 실행하는 쿠버네티스 노드의 컨테이너 런타임으로 ContainerD 1.4.0+ 를 사용할 수 있어요.

Windows 노드에 ContainerD 설치하는 방법을 배워요.

Mirantis Container Runtime

Mirantis Container Runtime (MCR)은 모든 Windows Server 2019 이상 버전의 컨테이너 런타임으로 사용할 수 있어요.

자세한 내용은 Windows Servers에 MCR 설치를 참고해요.

Windows OS 버전 호환성

Windows 노드에서 호스트 OS 버전이 컨테이너 기본 이미지 OS 버전과 일치해야 하는 엄격한 호환성 규칙이 적용돼요.

쿠버네티스 v1.37의 경우 Windows 노드(및 파드)의 운영 체제 호환성은 다음과 같아요:

쿠버네티스 버전 스큐 정책도 적용돼요.

하드웨어 권장 사항과 고려 사항

참고:

  • 가상화 지원이 가능한 64비트 프로세서 CPU 코어 4개 이상
  • RAM 8GB 이상
  • 여유 디스크 공간 50GB 이상

최소 하드웨어 요구 사항에 대한 최신 정보는 Windows Server 하드웨어 요구 사항 Microsoft 문서를 참고해요. 프로덕션 워커 노드의 리소스 결정에 대한 지침은 프로덕션 워커 노드 쿠버네티스 문서를 참고해요.

시스템 리소스를 최적화하려면 그래픽 사용자 인터페이스가 필요하지 않다면 Windows Desktop Experience 설치 옵션을 제외한 Windows Server OS 설치를 사용하는 것이 바람직할 수 있어요. 이 구성은 보통 더 많은 시스템 리소스를 확보해 주기 때문이에요.

Windows 워커 노드의 디스크 공간을 평가할 때 Windows 컨테이너 이미지는 보통 Linux 컨테이너 이미지보다 크며, 단일 이미지에 대해 300MB에서 10GB 이상의 범위라는 점을 주목해요. 추가로 Windows 컨테이너의 C: 드라이브는 기본적으로 20GB의 가상 여유 크기를 나타내는데, 이는 실제 소비 공간이 아니라 호스트에서 로컬 저장소를 사용할 때 단일 컨테이너가 차지할 수 있는 디스크 크기예요. 자세한 내용은 Windows의 컨테이너 - Container Storage 문서를 참고해요.

도움 받기와 문제 해결

쿠버네티스 클러스터 문제 해결의 주요 도움 소스는 Troubleshooting 페이지에서 시작해야 해요.

이 섹션에는 몇 가지 추가적인 Windows 특정 문제 해결 도움도 포함돼 있어요. 로그는 쿠버네티스 문제를 해결하는 중요한 요소예요. 다른 기여자에게 문제 해결 지원을 구할 때는 항상 로그를 포함해야 해요. SIG Windows 로그 수집 기여 가이드의 지침을 따라요.

문제 및 기능 요청 보고

버그처럼 보이는 것이 있거나 기능 요청을 하고 싶다면 SIG Windows 기여 가이드를 따라 새 이슈를 만들어요. 이전에 보고됐는지 이슈 목록을 먼저 검색해 그 이슈에 경험을 댓글로 달고 추가 로그를 포함해야 해요. Kubernetes Slack의 SIG Windows 채널도 티켓을 만들기 전에 초기 지원과 문제 해결 아이디어를 얻기에 좋은 경로예요.

Windows 클러스터 운영성 검증

쿠버네티스 프로젝트는 구조화된 테스트 스위트와 함께 제공되는 Windows Operational Readiness 사양을 제공해요. 이 스위트는 core와 extended 두 테스트 집합으로 나눠지며, 각 집합은 특정 영역을 테스트하는 범주를 포함해요. Windows 및 하이브리드(Linux 노드와 혼합) 시스템의 모든 기능을 완전한 범위로 검증하는 데 사용할 수 있어요.

새로 만든 클러스터에 프로젝트를 설정하려면 프로젝트 가이드의 지침을 참고해요.

배포 도구

kubeadm 도구는 쿠버네티스 클러스터를 배포하는 데 도움을 주며, 클러스터를 관리할 제어 플레인과 워크로드를 실행할 노드를 제공해요.

쿠버네티스 cluster API 프로젝트도 Windows 노드 배포를 자동화하는 수단을 제공해요.

Windows 배포 채널

Windows 배포 채널에 대한 자세한 설명은 Microsoft 문서를 참고해요.

지원 모델을 포함한 서로 다른 Windows Server 서비싱 채널에 대한 정보는 Windows Server servicing channels에서 찾을 수 있어요.

더 알아보기 (Learn more)