Kubernetes의 Windows 컨테이너

Kubernetes의 Windows 컨테이너 (Windows containers in Kubernetes)

Windows 애플리케이션은 많은 조직에서 운영하는 서비스와 애플리케이션의 상당 부분을 차지해요. Windows 컨테이너는 프로세스를 캡슐화하고 의존성을 패키징하는 방법을 제공해서, Windows 애플리케이션에 DevOps 관행을 적용하고 클라우드 네이티브 패턴을 따르기 쉽게 해줘요.

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

Kubernetes의 Windows 노드

Kubernetes에서 Windows 컨테이너를 오케스트레이션하려면 기존 Linux 클러스터에 Windows 노드를 포함시키면 돼요. Kubernetes Pod에서 Windows 컨테이너를 스케줄링하는 것은 Linux 기반 컨테이너를 스케줄링하는 것과 비슷해요.

Windows 컨테이너를 실행하려면 쿠버네티스 클러스터에 여러 운영체제가 포함되어야 해요. 컨트롤 플레인은 Linux에서만 실행할 수 있지만, 작업자 노드는 Windows나 Linux를 실행하도록 배포할 수 있어요.

운영체제가 Windows Server 2022 또는 Windows Server 2025라면 Windows 노드가 지원돼요.

이 문서는 Windows 컨테이너라는 용어를 프로세스 격리(process isolation)를 사용하는 Windows 컨테이너를 의미할 때 사용해요. Kubernetes는 Hyper-V 격리를 사용한 Windows 컨테이너 실행을 지원하지 않아요.

호환성과 제한 사항

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

• HugePages: Windows 컨테이너에서 지원되지 않아요.
• 특권(privileged) 컨테이너: Windows 컨테이너에서 지원되지 않아요. HostProcess 컨테이너가 비슷한 기능을 제공해요.
• TerminationGracePeriod: containerd가 필요해요.

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

Kubernetes가 테스트하는 Windows 버전에 대한 자세한 내용은 Windows OS 버전 호환성을 참고하세요.

API와 kubectl 관점에서 Windows 컨테이너는 Linux 기반 컨테이너와 거의 같은 방식으로 동작해요. 하지만 이 섹션에서 설명하는 주요 기능에는 눈에 띄는 차이점이 몇 가지 있어요.

Linux와의 비교

주요 Kubernetes 요소는 Windows에서도 Linux와 같은 방식으로 작동해요. 이 섹션에서는 몇 가지 주요 워크로드 추상화와 그것들이 Windows에 어떻게 매핑되는지 다뤄요.

• Pod는 Kubernetes의 기본 구성 요소인, 만들거나 배포하는 Kubernetes 객체 모델에서 가장 작고 단순한 단위예요. 같은 Pod에 Windows와 Linux 컨테이너를 함께 배포할 수는 없어요. Pod 안의 모든 컨테이너는 단일 노드에 스케줄링되는데, 각 노드는 특정 플랫폼과 아키텍처를 나타내요. 다음 Pod 기능, 속성, 이벤트가 Windows 컨테이너로 지원돼요.
  • 프로세스 격리와 볼륨 공유가 있는 Pod당 단일 또는 여러 컨테이너
  • Pod status 필드
  • 준비성(readiness), 활성(liveness), 시작(startup) 프로브
  • postStart & preStop 컨테이너 라이프사이클 훅
  • ConfigMap, Secrets: 환경 변수나 볼륨으로
  • emptyDir 볼륨
  • 명명된 파이프 호스트 마운트
  • 리소스 제한
  • OS 필드:

.spec.os.name 필드는 현재 Pod가 Windows 컨테이너를 사용한다는 것을 나타내도록 windows로 설정해야 해요.

.spec.os.name 필드를 windows로 설정하면 그 Pod의 .spec에 다음 필드를 설정하면 안 돼요:

위 목록에서 와일드카드(*)는 목록의 모든 요소를 나타내요. 예를 들어 spec.containers[*].securityContext는 모든 컨테이너의 SecurityContext 객체를 말해요. 이 필드 중 하나라도 지정되면 Pod는 API 서버에 의해 승인되지 않아요.

- `spec.hostPID`
- `spec.hostIPC`
- `spec.securityContext.seLinuxOptions`
- `spec.securityContext.seccompProfile`
- `spec.securityContext.fsGroup`
- `spec.securityContext.fsGroupChangePolicy`
- `spec.securityContext.sysctls`
- `spec.shareProcessNamespace`
- `spec.securityContext.runAsUser`
- `spec.securityContext.runAsGroup`
- `spec.securityContext.supplementalGroups`
- `spec.containers[*].securityContext.seLinuxOptions`
- `spec.containers[*].securityContext.seccompProfile`
- `spec.containers[*].securityContext.capabilities`
- `spec.containers[*].securityContext.readOnlyRootFilesystem`
- `spec.containers[*].securityContext.privileged`
- `spec.containers[*].securityContext.allowPrivilegeEscalation`
- `spec.containers[*].securityContext.procMount`
- `spec.containers[*].securityContext.runAsUser`
- `spec.containers[*].securityContext.runAsGroup`

• 워크로드 리소스 포함:
  • ReplicaSet
  • Deployment
  • StatefulSet
  • DaemonSet
  • Job
  • CronJob
  • ReplicationController
• 서비스 자세한 내용은 로드 밸런싱과 서비스를 참고하세요.

Pod, 워크로드 리소스, 서비스는 Kubernetes에서 Windows 워크로드를 관리하는 데 핵심적인 요소예요. 하지만 그것들만으로는 동적 클라우드 네이티브 환경에서 Windows 워크로드의 적절한 수명주기 관리를 가능하게 하기엔 부족해요.

• kubectl exec
• Pod와 컨테이너 메트릭
• Horizontal pod autoscaling
• 리소스 할당량(Resource quotas)
• 스케줄러 선점(preemption)

kubelet의 커맨드라인 옵션

일부 kubelet 커맨드라인 옵션은 Windows에서 다르게 동작해요. 아래에 설명할게요.

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

API 호환성

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

높은 수준에서 이 OS 개념들은 서로 달라요.

• 정체성(Identity) - Linux는 정수 유형으로 표현되는 userID(UID)와 groupID(GID)를 사용해요. 사용자와 그룹 이름은 정규화되지 않으며 /etc/groups나 /etc/passwd에서 UID+GID로 되돌아가는 별칭일 뿐이에요. Windows는 Windows Security Access Manager(SAM) 데이터베이스에 저장되는 더 큰 이진 보안 식별자(security identifier)(SID)를 사용해요. 이 데이터베이스는 호스트와 컨테이너 간, 또는 컨테이너 간에 공유되지 않아요.
• 파일 권한 - Windows는 (SID 기반의) 액세스 제어 목록을 사용하는 반면, Linux 같은 POSIX 시스템은 객체 권한과 UID+GID 기반의 비트마스크와 선택적 액세스 제어 목록을 사용해요.
• 파일 경로 - Windows의 규칙은 / 대신 \\를 사용하는 거예요. Go IO 라이브러리는 보통 둘 다 받아들이고 그냥 작동하게 만들지만, 컨테이너 안에서 해석되는 경로나 커맨드라인을 설정할 때는 \\가 필요할 수 있어요.
• 신호(Signals) - Windows 대화형 앱은 종료를 다르게 처리하며 다음 중 하나 이상을 구현할 수 있어요.
  • UI 스레드가 WM_CLOSE를 포함한 잘 정의된 메시지를 처리해요.
  • 콘솔 앱은 Control Handler를 사용해 Ctrl-C나 Ctrl-break를 처리해요.
  • 서비스는 SERVICE_CONTROL_STOP 제어 코드를 받을 수 있는 Service Control Handler 함수를 등록해요.

컨테이너 종료 코드는 0이 성공이고 0이 아닌 값이 실패인 같은 규칙을 따라요. 구체적인 오류 코드는 Windows와 Linux에서 다를 수 있어요. 하지만 Kubernetes 컴포넌트(kubelet, kube-proxy)에서 전달되는 종료 코드는 변경되지 않아요.

컨테이너 스펙의 필드 호환성

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

• Huge pages는 Windows 컨테이너 런타임에 구현되지 않아서 사용할 수 없어요. 컨테이너에 대해 구성할 수 없는 사용자 권한을 주장(asserting a user privilege)해야 해요.
• requests.cpu와 requests.memory - requests는 노드의 사용 가능한 리소스에서 빼지므로 노드의 과잉 프로비저닝을 피하는 데 사용할 수 있어요. 하지만 과잉 프로비저닝된 노드에서 리소스를 보장하는 데는 사용할 수 없어요. 운영자가 과잉 프로비저닝을 완전히 피하고 싶다면 모범 사례로 모든 컨테이너에 적용해야 해요.
• securityContext.allowPrivilegeEscalation - Windows에서는 불가능해요. capabilities 중 어떤 것도 연결되지 않아요.
• securityContext.capabilities - POSIX capabilities는 Windows에 구현되지 않았어요.
• securityContext.privileged - Windows는 특권 컨테이너를 지원하지 않아요. 대신 HostProcess 컨테이너를 사용하세요.
• securityContext.procMount - Windows에는 /proc 파일시스템이 없어요.
• securityContext.readOnlyRootFilesystem - Windows에서는 불가능해요. 레지스트리와 시스템 프로세스가 컨테이너 안에서 실행되려면 쓰기 접근이 필요해요.
• securityContext.runAsGroup - Windows에는 GID 지원이 없어서 불가능해요.
• securityContext.runAsNonRoot - 이 설정은 Windows에서 루트 사용자에 가장 가까운 등가물인 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에서 지원되지 않아요. Pod는 항상 컨테이너 네트워크로 실행돼요.
• podSecurityContext 아래 참고하세요.
• shareProcessNamespace - 베타 기능이며, Windows에 구현되지 않은 Linux 네임스페이스에 의존해요. Windows는 프로세스 네임스페이스나 컨테이너의 루트 파일시스템을 공유할 수 없어요. 네트워크만 공유할 수 있어요.
• terminationGracePeriodSeconds - Windows의 Docker에서는 완전히 구현되지 않았어요. GitHub 이슈를 참고하세요. 현재 동작은 ENTRYPOINT 프로세스에 CTRL_SHUTDOWN_EVENT를 보내고, Windows가 기본적으로 5초를 기다린 다음, 일반적인 Windows 종료 동작으로 모든 프로세스를 종료하는 것이에요. 이 5초 기본값은 실제로 컨테이너 안의 Windows 레지스트리에 있어서, 컨테이너를 빌드할 때 재정의할 수 있어요.
• volumeDevices - 베타 기능이며 Windows에 구현되지 않았어요. Windows는 원시 블록 장치를 Pod에 연결할 수 없어요.
• volumes
  • emptyDir 볼륨을 정의하면 그 볼륨 소스를 memory로 설정할 수 없어요.
• Windows에서 지원되지 않으므로 볼륨 마운트에 mountPropagation을 활성화할 수 없어요.

호스트 네트워크 접근

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

Kubernetes v1.36에는 WindowsHostNetwork 기능 게이트도, 호스트의 네트워크 네임스페이스에서 Windows Pod를 실행하는 지원도 없어요.

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

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

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

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

Pause 컨테이너 (Pause container)

Kubernetes Pod에서 인프라 또는 "pause" 컨테이너가 먼저 생성되어 컨테이너를 호스팅해요. Linux에서 pod를 구성하는 cgroup과 네임스페이스는 계속 존재하기 위해 프로세스가 필요해요. pause 프로세스가 이것을 제공해요. 인프라와 워커 컨테이너를 포함해 같은 pod에 속한 컨테이너들은 공통 네트워크 엔드포인트(같은 IPv4 및/또는 IPv6 주소, 같은 네트워크 포트 공간)를 공유해요. Kubernetes는 pause 컨테이너를 사용해 워커 컨테이너가 충돌하거나 재시작돼도 네트워킹 구성을 잃지 않게 해줘요.

Kubernetes는 Windows를 지원하는 다중 아키텍처 이미지를 유지해요. Kubernetes v1.36.0의 권장 pause 이미지는 registry.k8s.io/pause:3.6이에요. 소스 코드는 GitHub에서 볼 수 있어요.

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

컨테이너 런타임 (Container runtimes)

Pod가 그곳에서 실행될 수 있도록 클러스터의 각 노드에 컨테이너 런타임을 설치해야 해요.

다음 컨테이너 런타임이 Windows와 작동해요.

참고: 이 섹션은 Kubernetes가 요구하는 기능을 제공하는 서드파티 프로젝트를 링크해요. 쿠버네티스 프로젝트 작성자는 이 프로젝트들에 대해 책임지지 않으며, 목록은 알파벳순으로 나열돼요. 목록에 프로젝트를 추가하려면 변경을 제출하기 전에 내용 가이드를 읽어보세요. 더 많은 정보.

ContainerD

기능 상태: Kubernetes v1.20 [stable]

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

Windows 노드에 ContainerD 설치하기 방법을 배워보세요.

참고:

containerd와 GMSA를 사용해 Windows 네트워크 공유에 접근할 때 커널 패치가 필요한 알려진 제한 사항이 있어요.

Mirantis Container Runtime

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

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

Windows OS 버전 호환성

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

Kubernetes v1.36에서 Windows 노드(및 Pod)의 운영체제 호환성은 다음과 같아요.

• Windows Server LTSC 릴리스 Windows Server 2022
• Windows Server LTSC 릴리스 Windows Server 2025

Kubernetes 버전 왜곡 정책(version-skew policy)도 적용돼요.

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

참고: 이 섹션은 Kubernetes가 요구하는 기능을 제공하는 서드파티 프로젝트를 링크해요. 쿠버네티스 프로젝트 작성자는 이 프로젝트들에 대해 책임지지 않으며, 목록은 알파벳순으로 나열돼요. 목록에 프로젝트를 추가하려면 변경을 제출하기 전에 내용 가이드를 읽어보세요. 더 많은 정보.

참고:

여기 설명된 하드웨어 사양은 합리적인 기본값으로 간주해야 해요. 최소 요구사항이나 프로덕션 환경에 대한 특정 권장사항을 나타내려는 것이 아니에요. 워크로드 요구사항에 따라 이 값들을 조정해야 할 수 있어요.

• 가상화를 지원할 수 있는 64비트 프로세서 4개 이상의 CPU 코어
• 8GB 이상의 RAM
• 50GB 이상의 여유 디스크 공간

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

시스템 리소스를 최적화하려면, 그래픽 사용자 인터페이스가 필요하지 않다면 Windows Desktop Experience 설치 옵션을 제외한 Windows Server OS 설치를 사용하는 편이 좋아요. 이 구성은 일반적으로 더 많은 시스템 리소스를 확보해주기 때문이에요.

Windows 워커 노드의 디스크 공간을 산정할 때, Windows 컨테이너 이미지는 일반적으로 Linux 컨테이너 이미지보다 크고 단일 이미지의 크기가 300MB에서 10GB 이상이라는 점을 유의하세요. 또한 Windows 컨테이너의 C: 드라이브는 기본적으로 가상 여유 크기 20GB를 나타내는데, 이는 실제 소비된 공간이 아니라 호스트의 로컬 스토리지를 사용할 때 단일 컨테이너가 차지하도록 커질 수 있는 디스크 크기예요. 자세한 내용은 Windows의 컨테이너 - 컨테이너 스토리지 문서를 참고하세요.

도움과 문제해결 얻기

Kubernetes 클러스터 문제해결의 주요 지원 소스는 문제해결 페이지에서 시작해야 해요.

이 섹션에는 몇 가지 Windows 특화 문제해결 도움말이 포함돼 있어요. 로그는 Kubernetes 문제해결의 중요한 요소예요. 다른 기여자에게 문제해결 지원을 요청할 때는 언제나 로그를 포함하세요. 로그 수집에 대한 SIG Windows 기여 가이드의 지침을 따르세요.

이슈 및 기능 요청 보고

버그로 보이는 것을 발견했거나 기능 요청을 하고 싶다면 SIG Windows 기여 가이드를 따라 새 이슈를 만들어 주세요. 먼저 이슈 목록을 검색해서 이전에 보고되었는지 확인하고, 이슈에 대한 경험을 댓글로 남기고 추가 로그를 추가해야 해요. Kubernetes Slack의 SIG Windows 채널도 티켓을 만들기 전에 초기 지원과 문제해결 아이디어를 얻을 수 있는 훌륭한 경로예요.

Windows 클러스터 작동성 검증

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

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

배포 도구

kubeadm 도구는 클러스터를 관리하는 컨트롤 플레인과 워크로드를 실행할 노드를 제공해 Kubernetes 클러스터를 배포하는 데 도움을 줘요.

Kubernetes cluster API 프로젝트도 Windows 노드 배포 자동화 방법을 제공해요.

Windows 배포 채널

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

지원 모델을 포함한 다양한 Windows Server 서비스 채널에 대한 정보는 Windows Server servicing channels에서 확인할 수 있어요.

이 페이지의 항목은 Kubernetes가 요구하는 기능을 제공하는 서드파티 제품이나 프로젝트를 가리켜요. 쿠버네티스 프로젝트 작성자는 그런 서드파티 제품이나 프로젝트에 대해 책임지지 않아요. 자세한 내용은 CNCF 웹사이트 가이드라인을 참고하세요.

추가 서드파티 링크를 추가하는 변경을 제안하기 전에 내용 가이드를 읽어야 해요.