Windows Kubernetes Bootstrapping and Operations

Windows
Kubernetes
Bootstrapping
and Operations
DEVSISTERS
Jung Hyun Nam

Contents
– Overview
– Windows SIG
– Current State of Windows K8s
– Dive Into Windows Kubernetes
– DEVSISTERS & Windows K8s
– Windows Container & Kubernetes
– Demo: Heterogeneous K8s cluster built with AKS-Engine
– Limitations and future

Who am I
– 2019년 7월 현재 11년 연속 Microsoft MVP Award 수상
– 한국 Azure 사용자 그룹 운영진
– DEVSISTERS DevOps 엔지니어
– Windows Server와 Cloud Native 기술을 모두 다룰 수 있는 특이 Position의 DevOps
엔지니어로 2018년 1월에 합류
– 최근 Windows Kubernetes 및 DevOps에서의 Kubernetes 활용에 많은 관심을
두고 활동 중

Overview
– Windows Server 2019 기반의 컨테이너 기술을 이용하여 Kubernetes가
Windows 컨테이너를 오케스트레이션할 수 있게 함
– Host Compute Service, Host Network Service를 이용하여 컨테이너의 실행과
네트워킹을 제어함
– Docker for Enterprise Edition 18.x 릴리스를 기반으로 컨테이너 런타임 제공
– 범용 목적의 CNI로는 WinBridge, Flannel 사용 가능. Azure 한정으로 Azure CNI
를 제공하여 네트워크 통합 가능.
– Kubernetes 1.14에서 General Available 획득. 하지만 실제 사용에 있어서 크
리티컬한 부분들이 일부 남아있음.

Windows SIG
– https://github.com/kubernetes/community/tree/master/sig-windows
– Chairs
– Michael Michael (VMware)
– Patrick Lang (Microsoft)
– Subprojects
– Windows GMSA
– Windows Testing
– Windows Tools
– Regular SIG Meeting held on every Tuesday 12:30 (EST)

Current State of Windows K8s
– Docker EE는 HCS v1 기반이고, HCS v2를 지원하지 않음
– ContainerD의 Windows 버전이 HCS v2를 사용
– Windows Kubernetes에서 ContainerD를 지원하도록 개발 중
– OS 커널 버전보다 낮은 Base Image를 사용하려면 가상화 또는 중첩 가상화 필요.
현재는 kubelet 실행 시 Feature Gate 명시가 필요하고, Capacity Limit이 있음
– ContainerD 도입으로 현재 빠진 많은 기능이 보충될 예정

Current State of Windows K8s
(Cont.)
– Kubeadm의 Windows 지원에 관련된 이슈
– Windows Worker Node는 Kube-proxy와 CNI 플러그인을 Pod이 아닌 Node와 동일
한 스코프에서 프로세스로 띄움
– Kubeadm에 큰 수정이 불가피한 상황이라 많은 논의가 진행되고 있음
– 현재는 Microsoft SDN 리포지터리에 있는 스크립트를 참조하여 수동으로 설치/
구성해야 함
– Azure에서 AKS Engine을 쓰는 경우는 예외

Dive Into Windows Kubernetes
– DEVSISTERS & Windows Kubernetes
– Windows Containers
– Windows Kubernetes

DEVSISTERS와 Windows K8s
– 게임 서버 개발과 테스트 자동화를 위하여 Kubernetes를 성공적으로 도입
– https://www.slideshare.net/seungyongoh3/ndc17-kubernetes
– Windows 기반의 게임 백엔드를 기존에 구축한 Kubernetes 클러스터에 편입
해야 하는 과제에 직면
– 2017년 12월부터 PoC를 진행했으나 도입에 상당한 난항을 겪음
– 요구 사항
– 동일 서브넷에서 Linux Pod과 Windows Pod이 상호 커뮤니케이션 필요
– 2018년 초에 Windows Server 2016을 기반으로 처음 완성했으나 네트워킹 스택에
서 기능 미비점이 발견되어 Drop

DEVSISTERS와 Windows K8s
(Cont.)
– 2018년 여름에 한시적으로 하이브리드 클러스터 운영
– 그러나 크리티컬 이슈 2개 발견, Windows SIG/Microsoft와 커뮤니케이션 진행
– https://github.com/kubernetes/kubernetes/issues/65163
– https://github.com/kubernetes/kubernetes/issues/66947
– 공식 가이드에서의 트러블슈팅 가이드 1개 추가, Windows Server 1803 및
1809 (2019)용 핫픽스 발표에 기여
– 2019년 가을에 Kubernetes 1.15 기반의 내부 클러스터 구축 완료 예정.
– 이슈들을 해결할 수 있도록 도와주신 모든 분들께 다시 한 번 감사드립니다.

Windows Container
– 이미지 포맷
– 내부 이미지 포맷은 Hyper-V의 VHD를 사용하지만, OCI 스펙을 준수하므로 별도
Repository 불필요 (Docker Hub, AWS ECR 등을 모두 지원)
– Desktop에서는 Windows 10과 Docker Desktop 2.0 for Windows로 Windows 컨테이
너 개발
– Server의 경우 Windows Server 2016부터 Container 기술은 지원되었으나,
Kubernetes 구동 등을 고려하면 Windows Server 2019를 사용하는 것이 바람직

Windows Container (Cont.)
– 이미지 종류
– Nano, Server Core, Full, IoT Core
– Kubernetes의 경우 Nano, Server Core를 주로 사용.
– VM과는 달리 GUI, Shell 관련 Infrastructure가 모두 제거됨.
– 이미지 빌드 방법
– Dockerfile을 사용하는 방식을 그대로 사용 가능
– 모든 OS 이미지는 mcr.microsoft.com (Azure ACR)로부터 배포됨
– 여러 줄 입력을 위해서는 DOS Shell의 경우 캐럿 (^), PowerShell의 경우 틸드 (`) 기
호를 사용

– 이미지 선택의 기준
– 새로운 Application은 Nano 기반으로 탑재하는 것이 바람직.
– 예: .NET Core, Go, Python 등
– 기존 Application은 호환성을 위해 Server Core를 사용할 수 있음.
– 예: Visual C++ 기반 IOCP 서버, ASP.NET 등
– 메모리 상에서 그래픽 렌더링을 하고 메시지 루프 처리나 Shell 지원 등을 내적으
로 수행하는 Full 이미지도 사용할 수는 있으나 용량이 매우 큼.
– 주로 UI 테스트 자동화 등에 투입할 수 있음.

– 실행 조건
– 동일 호스트 커널 버전에 동일 OS 이미지 필요
– Windows 10의 커널은 버전 번호가 같아도 Windows Server 커널과 다르기 때문에 가상화 필요
– 호스트 커널 버전 < OS 이미지: 구동할 수 없음
– 예: 서버 2019 호스트에서 서버 19H1 OS 이미지는 구동할 수 없음
– 호스트 커널 버전 > OS 이미지: CPU 가상화 또는 중첩 가상화 필요
– 예: 서버 2019 호스트에서 서버 2016 OS 이미지 구동
– 이 때 Kubelet 실행 시 Feature Gate로 Hyper-V Container 사용 지정이 필요
– Azure의 경우 3rd Gen VM부터 중첩 가상화가 지원됨
– 실제로 이를 고려하지 않고 배포하면 CrashLoopbackOff 상태가 될 수 있음

– 라이선싱
– OS 이미지의 배포 및 업데이트 권한은 전적으로 Microsoft에 있음
– 컨테이너 런타임에 가상화를 포함하지 않으면 호스트 서버의 SKU에 무관하게 무
제한 실행 가능
– Hyper-V Isolation을 사용하여 Windows 컨테이너 OS 이미지를 실행하는 경우
Datacenter Edition인 경우에만 무제한.
– 대개 Public Cloud에서는 Datacenter Edition을 사용하므로 고민하지 않아도 됨.
– On-Prem Datacenter를 사용하는 경우 실행 모델과 호스트 OS SKU 중 하나를 검토하여
정확하게 선택 필요

Windows
Container
Architecture
HCS와 HNS가 핵심
Kubernetes 입장에서는 Docker
REST API와 통신
Docker는 HCS와 HNS와 커뮤니케이
션 진행
Windows의 경우 추후 CRI
(Container Runtime Interface)가 도
입될 예정

Host Compute Service
커널 수준의 가상화
– 컨테이너 내부의 OS 버전과 호스
트 OS 버전이 반드시 일치해야 함
– Windows 10 클라이언트 PC에서
서버 커널은 이 방식으로 호스팅
이 불가하며, 오로지 Hyper-V
Isolation만 지원
Hyper-V Isolation
– 가장 많이 오해를 받는 Windows
Docker 확장 기능
– 전체가 격리된 VM은 아니기 때문
에 호스트 OS 버전보다 높은 버전
의 컨테이너 OS는 실행 불가
– https://bit.ly/2JSTo5A

Host Compute Service (Cont.)
– Linux 커널의 일부 컴포넌트에 대응되는 기능을 통합 제공
– Control Group, Namespace
– Layer Capabilities: Union File System + Registry
– Windows Kubernetes에 공헌할 목적으로 Microsoft가 직접 Go Lang으로 HCS
Shim도 제공함
– https://github.com/Microsoft/hcsshim
– .NET Framework 버전의 HCS 제어 프로그램 소스 코드도 제공함
– https://github.com/Microsoft/dotnet-computevirtualization

Host Network Service
– 각종 네트워크 설정 제어 가능
– https://github.com/Microsoft/SDN
– /Kubernetes/Windows/HNS.psm1
– VmCompute.dll의 HNSCall 메서드 사용
– REST API 방식으로 호출 (Method + Resource Path + JSON Payload)
– HNS를 이용하여 주로 제어하는 부분
– 네트워크: 내부 네트워크
– 엔드포인트: 컨테이너들이 사용하는 가상 어댑터
– 정책: 다른 노드 (리눅스, 윈도)에서 실행되는 Pod의 네트워크 연결 정보

Host Network Service (Cont.)
– Compartment
– Windows 내부의 VLAN과 유사한 개념
– Kubernetes에서는 Pod에 대응
– Endpoint
– Container가 Kubernetes 내의 다른 Container나 외부와 통신할 수 있게 하는 수단
– Windows Application 입장에서는 가상의 Network Interface Card로 취급됨

Host Network Service (Cont.)
Process Isolation Hyper-V Isolation

Windows Kubernetes Bootstrapping and Operations

WinBridge Configuration (Cont.)
{
"cniVersion": "0.2.0",
"name": "<NetworkMode>",
"type": "wincni.exe", "master": "Ethernet", "capabilities": { "portMappings": true },
"ipam": {
"environment": "azure", "subnet":"<PODCIDR>", "routes": [{ "GW":"<PODGW>" }]
},
"dns" : {
"Nameservers" : [ "<KubeDNSServiceIP>" ], "Search": [ "svc.cluster.local" ]
},
"AdditionalArgs" : [{
"Name" : "EndpointPolicy", "Value" : { "Type" : "OutBoundNAT", "ExceptionList": [ "<ClusterCIDR>", "<ServerCIDR>",
"<MgmtSubnet>" ] }
},{
"Name" : "EndpointPolicy", "Value" : { "Type" : "ROUTE", "DestinationPrefix": "<ServerCIDR>", "NeedEncap" : true }
},{
"Name" : "EndpointPolicy", "Value" : { "Type" : "ROUTE", "DestinationPrefix": "<MgmtIP>/32", "NeedEncap" : true }
}
]
}
HNS 네트워크의 형식 (L2Bridge)
Kubelet에 지정하는 –pod-cidr
스위치의 CIDR 값
kube-controller-manager의 –cluster-
cidr 스위치에 지정하는 CIDR 값
현재 Node 컴퓨터의 IP 주소
현재 Node 컴퓨터에 할당된 IP 주소
대역 (Subnet Mask를 CIDR로 변환)
Kubelet에 지정하는 –cluster-dns
스위치의 CIDR 값
kube-
api-
server의
--
service-
cluster-
ip-range
스위치에
지정하는
CIDR 값
HNS 네트워크 생성 시
지정한 “.2”로 끝나는 주소

Bootstrapping Windows
Kubernetes
– 설치해야 하는 구성 요소
– Windows Container 런타임 활성화
– Hyper-V Isolation을 사용하려는 경우만 Hyper-V도 같이 활성화
– Docker for Enterprise Edition 18.x 설치
– Kubelet, Kube-Proxy, Win-Bridge 또는 Flannel 바이너리 다운로드

Kubernetes (Cont.)
Windows Server 1803
VM 또는 베어메탈
준비
1
Node를 시작하기
전에 kubelet으로
노드를 먼저 등록하여
Pod CIDR 확보
2
HNS에 새로운 L2
Bridge HNS Network
생성, Pod Gateway
어댑터 생성 및 부착
3
Kubelet, Kubeproxy
설정 후 기동
4
Pod 간 수동 Routing
Table 등록
5

Kubernetes (Cont.)
– 다른 Kubernetes Node들과 동일한 서브넷에 새 Windows 인스턴스 생성
– Docker 및 각종 바이너리를 설치하고 서버를 구성
– 최초 1회 Kubelet을 수동 실행하여 Pod CIDR 대역 획득
– 획득한 Pod CIDR 정보를 토대로 HNS 네트워크 구성
– OS Base Image를 미리 Pull
– Pause/Infrastructure 이미지 Pull
– Kubelet 실행, Kube-Proxy 실행, CNI 플러그인 실행 후 정상 동작 검증
– NT 서비스로 Kubelet과 Kube-Proxy를 등록

Kubernetes (Cont.)
– 만약 Azure 구독을 보유하고 계시다면, Azure AKS Engine을 사용하여 빠르게
만들어볼 수 있습니다.
– Windows + Linux 클러스터
– GPU Kubernetes 클러스터
– (Preview) Azure Cosmos DB의 ETCD 인터페이스 활용
– AKS Engine 관련 샘플
– https://github.com/azure/aks-engine
– https://github.com/krazure/hybrid-aks-hol

Operating Windows Kubernetes
– Heterogenous 클러스터를 구축했을 경우 Pod 배포 시 정확한 OS 종류의 OS
버전 태그를 명시하도록 YAML이나 Helm Chart를 관리해야 함
– 예: 리눅스 Node에게 Windows Pod을 실행할 것을 요구 / 반대의 상황이 가능
– 동일 버전의 Windows OS로 노드를 가입시키는 것이 안전함
– Kube-Proxy 설정에 파라미터가 누락되거나 설정 miss가 있으면 Pod 내의
vNIC 할당이 해제되는 등의 문제가 발생할 수 있음
– Windows OS, 각종 Base Image 저장 등을 고려하여 시스템을 위해 적어도
15GB ~ 20GB 정도는 사용해야 안전함

Demonstration
– Windows로 이식한 Redis 서버 컨테이너 + Python UWSGI 프론트엔드 애플리
케이션을 연동한 예제
– Azure Vote App의 커스텀 버전
– https://gist.github.com/rkttu/e30542d75b8e48d0cca1eec6eb0cf86b
– Hybrid Workload에서 중요한 것은 Node Selector를 통한 적절한 노드 선택.
– Windows 노드에 Linux 컨테이너를 배정하거나, 반대의 상황이 발생하면 서
비스가 시작되지 못함.

Limitations
– 호스트 OS는 Windows Server 2019만 지원
– 컨테이너 이미지의 OS도 Windows Server 2019로 통일해야 함
– 네트워크 CNI 플러그인의 선택의 폭이 협소함
– Kubenet, Flannel 정도가 검증된 선택지
– Calico는 Enterprise 가입자에 한하여 유료 제공
– Open Virtual Network, Azure CNI 등
– 아직은 수동으로 설치해야 함 (Microsoft SDN 스크립트 참고)
– 지속적으로 Kubeadm 관련 개발이 진행 중

Future
– CRI – ContainerD
– HCS v2 API 지원을 통해 파일 마운트, 종료 메시지, Hosts 파일 지원 등을 구현
– Hyper-V Isolation으로 Pod 내에 1개 이상의 컨테이너 실행
– Hyper-V Isolation으로 호스트보다 낮은 버전의 Windows OS 이미지 실행 지원
– CPU/NUMA 설정 지정 지원
– 메모리 격리 및 예약 기능 지원
– Kubeadm과 클러스터 API 지원
– Group Managed Service Account (GMSA)
– 더 많은 CNI 및 스토리지 플러그인 지원

Windows Kubernetes Bootstrapping and Operations

More Related Content

What's hot (19)

Similar to Windows Kubernetes Bootstrapping and Operations (20)

Windows Kubernetes Bootstrapping and Operations