Windows kubernetes

Kubernetes/Windows Kubernetes

Windows kubernetes

이쿠우우 2021. 11. 4. 19:30

Windows kubernetes

목표

kubernetes 1.14 version 부터 windows worker node를 지원하기 시작함.

IIS web server container 와 같이 linux가 아닌 windows OS에서 실행가능한 container가 있음.

해당 container를 실행하기 위해서는 windows worker node가 필요함

이를 test해보기 위해 linux kubernetes cluster에 windows worker node를 추가하는 작업을 진행해봄.

글을 읽는데 필요한 기초 개념

NIC (Network Interface Card)란?

네트워크 어댑터라고 함.

물리적 하드웨어 장치로, 물리적 서버와 데이터 트래픽을 주고받는 데 사용됨.

서버 운영 체제는 이를 해당 서버에 대한 단일 네트워크 어댑터로 간주함.

네트워크 어댑터의 물리적 포트는 액세스 계층 네트워크 스위치에 케이블로 연결됨.

Hyper-V란?

Microsoft에서 제공하는 hypervisor.

Windows 환경에서 가상 머신으로 여러 OS를 생성/구동/관리 할 수 있게 해줌.

하나의 물리 하드웨어를 여러 가상 머신 들이 효율적이고 안정적으로 사용할 수 있는 환경을 제공함.

Hyper-V Network란?

Hyper-V를 통해 생성된 VM들이 통신을 위해 구성하는 네트워크.

Hyper-V 네트워크의 기본구성은 가상 스위치(Hyper-V Virtual Switch)와

가상 네트워크 업대터 (Hyper-V Virtual Networking Adapter)로 이루져있음.

Hyper-V Virtual Switch (vSwitch)란?

Hyper-V Virtual Switch는 Host에 속하는 구성요소임임.

Windows는 Hyper-V를 사용하도록 구성하면 OS 차원에서 Hyper-V Virtual Switch를 생성함.

그 후에는 실제 NIC와 직접 통신하지 않고

이 Virtual Switch에 부착되는 vNIC을 통해 host가 NIC와 통신하도록 시스템 구성이 바뀌게 됨.

vSwitch는 Host에 설치된 Hyper-V manager를 통해 생성할 수 있으며, 3개의 종류가 있음.

또한 vSwitch에는 VFP(Virtual Filtering Platform) 구성요소가 내장되어있음

[External(외부)]

Host의 실제 물리 NIC 및 물리 네트워크에 연결되어 외부 통신이 가능.

[Internal(내부)]

같은 Host 내에 존재하는 VM들간 연결 및 Host 내 management OS와 연결을 제공.

[Private]

같은 Host 내에 존재하는 VM들간 연결만 제공합니다. Intenral과 달리 guest VM들과 Host간의 통신은 불가 함.

VFP(Virtual Filtering Platform)

Software Defined Networking을 구현하면서,

가상 네트워크 환경과 외부 네트워크 사이의 Ingress/Egress를 처리함.

vNIC (Hyper-V Virtual Network Adapter)

논리적 네트워크 어댑터라고 함.

가상 VM머신에는 실제 물리 네트워크 어댑터가 없기 때문에 vNIC와 같은 가상 네트워크 어댑터가 필요함.

Hyper-V 가상 네트워크 어댑터에는 Hyper-V 전용 어댑터, Legacy 네트워크 어댑터 2가지 종류가 있음.

2가지 중 Hyper-V 전용 어댑터가 주로 사용됨.

[Hyper-V 전용 네트워크 어댑터]

Hyper-V 전용으로 설계된 어댑터로, generation 1, 2 VM에서 모두 사용 가능.

그러나 이 전용 어댑터 사용을 위해서는 Hyper-v integration service가 설치되어 있어야 함.

[Legacy 네트워크 어댑터]

Intel 21140 기반 PCI 패스트 이더넷 어댑터를 에뮬레이트 한 어댑터로, generation 1 VM에서만 사용 가능함.

최근에는 이 어댑터는 거의 사용되지 않음.

Kubernetes 지원 Windows OS

kubernetes worker node로 추가할 수 있는 windows OS version으로

windows server 2019_1809 이상, windows 10_1809 이상을 지원함.

이전 version은 worker node 추가 까지는 정상동작 되더라도

container runtime에 따른 pod동작에 호환이 안되는 문제가 있음.

ex) windows 2016에서는 pod 1개 내부에 다수 container를 실행시키지 못하는 문제가 있음.

Linux와 Windows Container platform 차이점.

Linux container platform (Docker)

위 그림과 같이 linux 환경에서는 docker가

containerd(high-level 컨테이너 런타임), runC(Low-level 컨테이너 런타임) 프로젝트로 분리되어 container 생성함.

containerd를 통해 runc를 호출하고 runC는 linux kernel의 기능을 호출하여 container를 생성함.

network 기능은 containerd가 관리하며 각 container간 통신이 가능하도록 해줌.

자세한 설명은 : [Docker 구조] 글에서 설명함.

Linux container platform (containerD)

containerd를 container runtime으로 사용하는 경우는 위의 그림과 같은 구조로 되어있음.

간단하게 linux 환경을 알아봤고 이제 windows 환경과 비교해보겠음.

Windows container platform (Docker)

kubernetes의 kubelet 입장에서는 Docker REST API와 통신함.

Windows Docker는 linux와는 다르게 windows 환경의 docker는 containerD를 호출하지 않음.

windows환경에서 사용되는 docker는 hcs-shim이 포함되어있어서

hcs-shim을 통해 windows kernel의 HCS와 HNS를 호출함.

HCS와 HNS는 Windows container에서 핵심이 되는 기능임.

HCS는 container 생성에 관여를 하고 HNS는 container network에 관여를 하는 windows 커널 기능임.

HCS와 HNS에 대해서는 다음 목차에서 더 자세히 알아보겠음.

Windows container platform (containerD)

Windows 환경에서 containerD를 사용하게 되면

containerD가 containerd-shim와 runC를 호출하지 않고 runhcs를 호출하게 됨.

containerd-shim는 runhcs로 대체되고

runC는 HCS로 대체되어 동작함.

특이한점은 기존 linux환경의 containerD경우 network를 containerD가 관리했는데

runhcs를 사용하게 되며 container생성과 network를 모두 runhcs가 관리하게 됨.

HCS(Host Compute Service)란?

container 기술의 핵심은 linux kernel기술인 cgroups, namespaces, Union Filesystem 등 인데,

Windows에서는 linux kernel 기술을 사용할 수 없음.

MS에서도 container를 사용할 수 있어야하니 이러한 linux kernel 기술을 대체 하기 위해 HCS를 개발함.

즉 Windows의 HCS는 linux kernel기술인 cgroups, namespaces, Union Filesystem 등과 같은 역할을 수행함.

Windows OS에서 Docker를 설치하게 되면

Docker CE(Coummunity Edition) 또는 Docker EE(Enterprise Edition)제공되는데

이 두 가지 windows os docker는 모두 containerd를 호출하지 않고 HCS v1 API를 직접 호출하도록 수정된 docker임.

추가로 Microsoft에서는 Windows kubernetes에 공헌할 목적으로 직접 Go Lang으로 HCS-shim도 제공함.

HCS는 opensource이며 Go, C#으로 개발되었음.

HCS를 통해 실행 할 수 있는 container image는 isolation 방식에 따라

Process isolation, Hyper-V isolation 2가지로 나누어짐.

Process isolation (Windows Server containers)

Process 격리 방식은 위 그림과 같이 Container가 Host의 kernel과 직접 상호작용함.

Linux OS에서 container가 실행되는 방식과 거의 동일함.

Host kernel을 공유하기 때문에 Windows container image 사용 시

image의 OS version과 host의 OS version이 반드시 일치해야함.

ex)

windows 2019 1809 host OS에서는

windowsservercore-ltsc2019 image는 동작하지만

windowsservercore-ltsc2022 image는 동작하지 않음.

[사용 가능 OS]

Windows Server 및 Windows 10 버전 1809 이상 에서만 사용할 수 있음.

[docker Process isolation 실행 명령어]

docker run -it --isolation=process mcr.microsoft.com/windows/servercore:ltsc2019 cmd

[kubernetes windows]

현재 kubernetes에서는 windows image pod를 생성 시 default로 Process isolation 형식으로 동작함.

Hyper-V isolation (Hyper-v containers)

Hyper-v 격리 방식은 Hyper-V 가상 머신을 활용하여 컨테이너를 실행함.

Windows container image에 내장되어있는 커널을 확인한 후

Hyper-v 가상화 기술로 해당 kernel version이 포함된 Hyper-V VM 실행하여

Host와 분리된 별도의 실행 환경을 구성하고 해당 VM에서 container를 실행함.

위 그림처럼

Host와 분리되어있기 때문에 Host kernel과 상호작용하지 않고 hyper-v를 통해 생성된 VM kernel과 상호작용함.

하지만 전체가 격리된 VM은 아니기 때문에 Host OS version보다 높은 버전의 container OS는 실행이 불가능함.

즉 모든 Windows container image와의 호환성을 보장하기 위해 Host를 상항 최신 버전의 Windows OS로 유지해야함.

Hyper-V 격리 방식은 완전한 가상 컴퓨터를 만들지는 않는 대신,

커널 수준에서부터 실행 환경을 분리하여 구동하기 때문에 다소 메모리 사용량이 높음.

[사용 가능 OS]

Windows Server 및 Windows 10 모두에서 사용할 수 있음.

[docker Process isolation 실행 명령어]

docker run -it --isolation=hyperv mcr.microsoft.com/windows/servercore:ltsc2019 cmd

[kubernetes windows]

kubernetes에서는 Hyper-V isolation 형식을 아직 지원하고 있지 않지만,

지원을 향후 릴리즈로 계획되어있음.

HNS(Host Network Service)란?

Windows는 HNS로 container network를 설계함.

container network는 Hyper-V Virtual Switch로 구성이 되어있는데

container 생성 시 마다 Hyper-V Virtual Switch를 구성해줘야하는 복잡한 과정을

HNS를 통해 간편하게 자동화 할 수 있음.

특이 사항으로는 전 목차에서 언급한

HCS의 Process isolation container와 hyper-v isolation container에 따라

HNS를 통해 network를 설계하는 방식이 달라짐.

kubernetes Windows Network

kubernetes에서 pod를 windows worker node에 배포할 시

pause container가 먼저 생성되고 vNIC가 pause container에 연결됨.

pause container는 windows에서 infrastructure container라고도 부름.

pause container가 정상 생성된 이후 application container가 생성되어

pod에 속한 container는 공통 네트워크 네임 스페이스 (동일한 IP 및 포트 공간)를 공유하게됨.

HNS를 이용하여 주로 제어하는 부분은 아래와 같음.

네트워크 : 내부 네트워크

엔드포인트 : 컨테이너들이 사용하는 가상 어댑터(vNIC)

정책 : 다른 노드(linux, windows)에서 실행되는 pod들의 네트워크 정보

[windows kubernetes 지원 service object]

NodePort

ClusterIP

LoadBalancer

ExternalName

Windows container 버전 호환

windows container는 모두 MS image registry에서 download함.

process isolation 방식의 경우 windows container는 host의 os version과 일치해야 정상적으로 동작함.

hyper-v isolation 방식의 경우 하위 호환은 가능하지만 상위 호환은 안됨.

예로 windows server 2019 image는 windows server 2019, 2004 등에서 동작하지만

2016에서는 안됨.

하위 호환은 되지만 특정 이미지에 따라서는 문제가 발생할 수 있음으로

되도록 host os와 verison을 맞춰주는 것이 좋음.

windows container 종류가 나눠짐.

Windows

Windows API 및 시스템 서비스(서버 역할 제외)를 전부 포함함.

ex) explorer, DirectX 포함 등등

GUI 애플리케이션 자동화에 적합함.

용량은 약 5GB 이상임.

Windows Server core

Windows Server API(즉, 전체 .NET framework)의 일부를 포함하는 작은 이미지임,

또한 대부분의 서버 역할이 포함되어 있지만 팩스 서버가 포함되지 않는 경우도 있음.

GPU package를 제외한 거의 모든 기능이 포함되어있기 때문에

약 4~5GB로 용량이 굉장히 큼.

nano

.NET Core API 및 일부 서버 역할을 지원하는 가장 작은 Windows Server 이미지.

핵심 기능만 포함되어있어서 200~500MB로 windows image 중에 가장 작은 용량을 가지고있음.

그 외에 image

이외에 container 역할에 따라 다향한 image들이 존재함.

[Windows 머신러닝]

AI용도 image도 존재함.

[Windows Server]

Windows API 및 시스템 서비스를 전부 포함함.

Kubernetes Windows pod 배포 환경 구축 방법

Windows OS에서만 실행 가능한

IIS Container와 MSSQL Container를

어떻게 kubernetes에서 실행 시킬 수 있는지에 대해 알아보겠음.

방법의 중점은 당연히 container를 실행 시킬 수 있는 Windows OS를

kubernetes에 어떻게 적용하는가 입니다.

방법은 총 3가지가 있음.

Kubernetes Windows Cluster 구축

Windows container를 실행을 위해 linux cluster이외에

별도의 Windows kubernetes cluster를 구성해서 실행하는 방법이 있음.

[장점]

windows worker node간 환경이 동일하여 networking에 버그가 없음.
linux cluster와 별도로 관리할 수 있음으로 linux cluster를 기존에 운영하고 있었다면
linux cluster에서 별도의 작업이 필요없음.

[단점]

기본적으로 kubernetes는 linux에 최적화 되어있음으로 각종 addon 또한 linux에 최적화 되어있음.
kubernetes 운영에 꼭 필요한 addon을 windows cluster에서는 사용하지 못하는 경우가 많음.
container runtime이 현재 docker와 containerD로 한정적임.
글을 쓰는 현재 시점으로 아직 Windows는 Docker만 최적화 되어있음.
CNI를 flannel, calico만 공식적으로 지원하고 있음.
하지만 해당 CNI도 linux 최적화라 Windows에서 문제가 발생할 수 있음
Master node에 배포되어있는 api, controller, scheduler pod가 windows에 최적화 되어있지 않음.

Kubevirt(큐브버트) 사용

Linux Cluster에서 Kubevirt addon을 사용하는 방법이 있음.

Windows OS pod 를 배포한 후 해당 Windows에서 windows container를 실행하는 방법이 있음.

[kubevirt란?]

간단하게 설명하자면 kubernetes를 vsphere 처럼 사용하는 방법임.

container로 만들기가 어려운 application을 kubernetes에서 사용하기 위해

OS 자체를 Pod로 배포 시켜서 해당 OS pod에서 application을 실행할 수 있도록 해줌.

CNCF에 속해있는 프로젝트라 vender lock도 없음.

Kubevirt를 통해 OS pod를 배포할 때 cpu, 메모리, 용량 등 VM을 생성하는 과정을 동일하게 설정할 수 있음.

https://kubevirt.io/

[장점]

기존의 kubernetes addon을 모두 적용할 수 있음.
windows container를 실행하기 위해 별도의 windows worker node를 추가할 필요가 없음.
Windows kubernetes의 단점을 극복할 수 있음.
즉 다양한 container runtime과 CNI를 모두 사용할 수 있음.
window container이외에도 container형식으로 만들기 어려운 application도 지원할 수 있음.

[단점]

kubevirt를 숙달해야할 필요가 있음.
kubevirt로 OS pod를 배포하게 되면 용량이 매우 커짐.OS를 pod로 배포하면 container의 장점을 살리기 어려움.
container의 장점은 작은 용량과 속도였는데
deployment 사용 불가.
사용할 수는 있지만 host에 큰 무리가 감.
kubevirt는 어차피 Windows OS 자체를 pod로 배포하는 것이라그냥 해당 windows OS에서 application을 실행시키는 것이 더 효율적으로 보임.
굳이 container로 실행할 필요가 없음. 오히려 작업만 번거로워지게됨.

Kubernetes Linux Cluster에 Windows worker node 추가

Linux cluster에 Windows worker node를 추가해서 windows container를 실행할 수 있음.

[장점]

3가지 방법 중 가지 추천하는 방법임.
windows container pod 배포 시 taint & toleration 또는 Affinity를 사용하면
정상적으로 windows node에만 windows pod 배포하여 실행 가능.

[단점]

linux에만 최적화 되어있는 addon 사용 시 windows node에서는 문제가 발생할 수 있음.
Windows Node의 경우 container runtime이 현재 docker와 containerD로 한정적임.
글을 쓰는 현재 시점으로 아직 Windows는 Docker만 최적화 되어있음.
CNI를 flannel, calico만 공식적으로 지원하고 있음.CNI의 경우 cluster에서 통일되어야하기 때문에
linux node도 Windows node로 인해 제약사항이 생김.
하지만 해당 CNI도 linux 최적화라 Windows에서 문제가 발생할 수 있음
windows worker node 추가를 위해 기존 linux cluster 설정을 변경해야하는 경우가 발생함.
kubernetes version update 시 windows에 지원 가능한지 알아봐야함.
containerD가 지원된다고는 하지만 1
0월 19일 시점 아직 containerD가 최적화되어있지 않았음.
version 1.23 update시 windows node 상황을 고려해야함.
ex) version 1.23에서 docker deprecation되는데 windows는 아직 docker에 최적화 되어있음.