2. Agenda
• Case Studies: DEVSISTERS
• Windows Container에 대한 이해
• Windows Kubernetes에 대하여
• HCS, HNS에 대한 이해
• Rancher로 Azure에 Hybrid Cluster 만들기
• 약간의 추가 정보
3. DEVSISTERS의 사례
리눅스 워크로드와 윈도 워크로드를 하나의 클러스터에서!
Kubernetes의 고가용성 전략을 Windows에서 그대로 사용
Windows의 고성능 I/O Completion Port을 레버리징
기존 VC++ 기반 서버들을 클러스터 환경으로 손쉽게 확장
4. DEVSISTERS의 사례 (Cont.)
하이브리드 K8S
클러스터 구축
• Windows와 Linux
Pod이 공존하는
Hybrid Cluster
쿠키워즈 개발/QA
환경 PoC 수행
• 게임 서버: 리눅스
• 운영 도구: 윈도
서버 1803
• 클러스터 구축:
KOPS + AWS
두 번의 PoC 수행
• 초기 – Windows
Server 2016 AMI +
Transparent
Network
• 현재 – Windows
Server 1803 AMI +
L2 Bridge +
WINCNI
향후 계획
• 개발/테스트 과정
중에 Windows
컨테이너를 사용할
수 있게 함
• 프로덕션 환경에
이르기까지
Windows
컨테이너로 자동화
5. Windows Kubernetes
• 일반적인 Kubernetes와 다르지 않음
• Kubernetes의 고가용성 전략을 Windows에서 그대로 사용
• Windows 만의 장점인 고성능 I/O Completion Port 지원
• 기존의 Legacy Application을 클러스터 환경으로 손쉽게 확장
6. Kubernetes Windows SIG
• https://github.com/kubernetes/community/tree/master/sig-windows
• Windows 버전의 Kubernetes 개발을 직접 진행하는 팀
7. Windows Kubernetes History
Kubernetes 1.5
• Alpha State
• Transparent Network
• Windows Server 2016
• 몇 가지 도드라지는
제약 사항 (Outbound
불가)
Kubernetes 1.9
• Beta State
• L2 Bridge
• Windows Container
Network Interface
• Windows Server 1709
이상 필요 (Azure,
AWS에서 사용 가능)
Kubernetes 1.13
• Windows Server 2019
지원
• 테스팅 인프라 강화
8. Road to Production
NT Service로 등록 지원
Hyper-V Isolation 컨테이너 지원
Flannel, Calico 등의 네트워크 플러그인 지원
1.10
SMB/CIFS 볼륨 플러그인 지원
Dashboard를 통한 명령어 실행 문제 수정
1.11
E2E 테스트를 통한 품질 보장
불필요한 오류 메시지 제거
1.12
E2E 테스트 보강
Windows Server 1803 지원
Windows Server 2019 지원
1.13
9. Windows Kubernetes 설치 과정
Windows Server 1803
VM, Windows Server
2019 VM 또는 베어메탈
준비
1
Node를 시작하기 전에
kubelet으로 노드를
먼저 등록하여 Pod CIDR
확보
2
HNS에 새로운 L2 Bridge
HNS Network 생성, Pod
Gateway 어댑터 생성 및
부착
3
Kubelet, Kubeproxy 설
정 후 기동
4
Pod 간 수동 Routing
Table 등록
5
10. Windows 컨테이너의 버전 선택
동일 버전: Process 또는 Hyper-V
Isolation
호스트 OS 버전이 컨테이너 OS 버
전보다 높은 경우: Hyper-V
Isolation 전용
호스트 OS 버전이 컨테이너 OS 버
전보다 낮은 경우: 실행 불가
Windows 10: 클라이언트 커널 ≠
서버 커널이기 때문에 항상 Hyper-
V Isolation 필요
Insider Preview: 컨테이너 이미지와
호스트 OS 버전이 x.y.z 단위로 일
치해야만 함. Process Isolation은
서버 OS 전용
Host >
Container
V
Win
Server
2016
Win 10
Creators
Update
1703
Win
Server
1709
Win 10
Fall
Creators
Update
1709
Win
Server
1803
Win 10
2018
April
Update
1803
Win
Server
2019
1809
Win 10
Oct.
2018
Update
Win
Server
2016
Process
Hyper-V
Hyper-V Hyper-V Hyper-V Hyper-V Hyper-V Hyper-V Hyper-V
Win
Server
1709
사용
불가
사용
불가
Process
Hyper-V
Hyper-V Hyper-V Hyper-V Hyper-V Hyper-V
Win
Server
1803
사용
불가
사용
불가
사용
불가
사용
불가
Process
Hyper-V
Hyper-V Hyper-V Hyper-V
Win
Server
2019
1809
사용
불가
사용
불가
사용
불가
사용
불가
사용
불가
사용
불가
Process
Hyper-V
Hyper-V
11. Windows Kubernetes의 핵심
HCS와 HNS가 핵심
Kubernetes 입장에서는 Docker REST API와 통신
Docker는 HCS와 HNS와 커뮤니케이션 진행
Windows의 경우 추후 ContainerD/CRI (Container
Runtime Interface)가 도입될 예정
12. Host Compute Service
커널 수준의 가상화
• 컨테이너 내부의 OS 버전과 호스트
OS 버전이 반드시 일치해야 함
• Windows 10 클라이언트 PC에서
서버 커널은 이 방식으로 호스팅이
불가하며, 오로지 Hyper-V
Isolation만 지원
Hyper-V Isolation
• 가장 많이 오해를 받는 Windows
Docker 확장 기능
• 전체가 격리된 VM은 아니기 때문에
호스트 OS 버전보다 높은 버전의
컨테이너 OS는 실행 불가
• https://bit.ly/2JSTo5A
13. Host Compute Service (Cont.)
https://blogs.technet.microsoft.com/virtualization/2017/01/27/introducing-the-host-compute-service-hcs/
14. Host Compute Service (Cont.)
• Linux 커널의 일부 컴포넌트에 대응되는 기능을 하나의 컴포넌트로 통합 제공
• Control Group, Namespace
• Layer Capabilities: Union File System + Registry
• Windows Kubernetes에 공헌할 목적으로 Microsoft가 직접 Golang으로 HCS Shim 제공
• https://github.com/Microsoft/hcsshim
• .NET Framework 버전의 HCS 제어 프로그램 소스 코드 제공
• https://github.com/Microsoft/dotnet-computevirtualization
15. Host Network Service
• 각종 네트워크 설정 제어 가능
• https://github.com/Microsoft/SDN
• /Kubernetes/Windows/HNS.psm1
• VmCompute.dll의 HNSCall 메서드 사용
• REST API 방식으로 호출 (Method + Resource Path + JSON Payload)
• HNS를 이용하여 주로 제어하는 부분
• 네트워크: 내부 네트워크
• 엔드포인트: 컨테이너들이 사용하는 가상 어댑터
• 정책: 다른 노드 (리눅스, 윈도)에서 실행되는 Pod의 네트워크 연결 정보
16. Host Network Service (Cont.)
• 읽어보시면 도움되는 글
• https://bit.ly/2JX3oKY
• 특히 Part 2, Part 5, Part 6이 HNS와 K8S Networking의 이해의 기본
• Compartment
• Windows 내부의 VLAN과 유사한 개념
• Kubernetes에서는 Service에 대응
• NBL: Net Buffer List
• WNV 환경 하에서의 패킷으로 이해하면 편리함
18. 네트워킹 구성
Windows Kubernetes의 네트워크 모델
Transparent NAT
WinCNI + L2Bridge
Transparent
가상 NAT 생성
별도의 Forwarder Adapter 생성 후 Route 테이블 관리
컨테이너 내부의 Outbound 연결에 제약이 있음
L2Bridge
Transparent와 같음
WinCNI, Flannel, WinBridge 등에서 기본으로 사용하는 네트워
킹 방식
19. 네트워킹 구성 (Cont.)
• Microsoft SDN Git Repo의 Kubernetes 코드 샘플에 HNS 네트워크 제어 모듈이 들어있음
• HNS 네트워크 제어 모듈을 이용하여 새 L2Bridge HNS 네트워크를 생성
• L2Bridge HNS 네트워크에 현재 Worker Node를 연결하기 위하여 새 HNS Endpoint를 생성
하고 만든 네트워크에 Attach
• CNI 플러그인 설정 파일 수정
• Kubelet, Kubeproxy 시작
• 수동 라우팅 정보 추가
20. 네트워킹 구성 (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”로 끝나는 주소
22. Windows Pod 스케줄링
• 현재 버전의 Docker 컨테이너와 Windows Kubernetes는 리눅스
컨테이너를 지원하지 않습니다.
• 그리고 리눅스 노드에 의도하지 않게 Windows 컨테이너가 배당
될 수 있는데, 이렇게 되면 Pod이나 Deployment가 실패하게 되
므로 Taint가 필요합니다.
• https://gist.github.com/rkttu/8ea0f94d26392d6f0c2090b0de116
5b5
• 또한 Windows Node의 OS 버전과 컨테이너 이미지가 일치하도
록 신경써야 합니다.
23. Linux Container on Windows (LCOW)
• 아직 개발 중인 기술
• Hyper-V Isolation을 응용하여 부팅 대상을 Windows 커널이 아닌 Linux로 함
• 중첩 가상화를 쓸 수 있는 환경이 필요
• Azure: 3세대 VM 이상
• AWS: i3.baremetal 혹은 유사 인스턴스
• 기타 베어메탈 제공 클라우드 전체
• 이 기술이 제공되면 Windows Node에 대한 Taint를 뗄 수 있음
• Windows 노드가 리눅스 컨테이너를 같이 실행할 수 있으므로 인프라 투자 상 이득이 증대됨
• Docker Community Edition 2.0에서 사용 가능
• (FYI) 2018년 11월에 버전 스키마가 18.xx에서 2.x로 변경됨
24. Windows 컨테이너 사용 시 주의 사항
• Hairpin/Promiscuous Mode 패킷 처리 이슈
• https://github.com/kubernetes/kubernetes/issues/65163
• https://github.com/kubernetes/kubernetes/issues/66947
• 증상은 매우 다양하지만, 공통적으로 Windows 측 Pod, Node의
네트워킹 스택에 심각한 영향을 끼침
• 이 문제에 대해 Microsoft 측과 6개월 이상 커뮤니케이션을 지속하였고,
Microsoft에서 버그를 수정 중인 것을 확인함
• Windows Server 1803의 경우 11월말 누적 업데이트, Windows Server
2019의 경우 내년 1월 중 누적 업데이트로 일반 공개될 예정
• Production 도입을 검토하신다면 시간이 좀 더 필요함
25. Windows 컨테이너 사용 시 주의 사항 (Cont.)
• Control Plane 서비스를 제공할 Master Node는 반드시 Linux
• KubeDNS, Flannel 등 일부 핵심 서비스들 또한 Linux Node 필요
• 그 외에는 상황에 따라 Linux Only, Windows Only, Hybrid 구축
• 컨테이너 버전과 호스트 OS 버전과의 상관 관계를 주의 요망
• 며칠 내로 테스트하실 예정이라면 Windows Node의 OS는 1803을 권장
• Azure, AWS, GCP 모두 지금 당장 사용 가능
• LTSC는 Windows Server 2019 추천
• 2016도 사용은 가능하나, 제약이 많고 성능이 떨어짐
• Kubernetes 1.14 버전에서는 2019 및 그 이후 릴리스만 지원함
26. 한국 Azure 사용자 그룹
• 국내에서 가장 많은 Azure 관련 이벤트, 교육을 진행하는 커뮤니티입니다.
• Azure에 대한 궁금증, 겪고 계신 문제들을 공유해주시고 토론에 참여해보세요.
• https://www.fb.com/groups/krazure
27. 마무리
Windows Server 2019가 출시되었지만 약 3개월 이상 여유를 두고
도입을 검토하시는 것이 좋습니다.
Windows 기반의 애플리케이션 개발자들에게 새로운 기회가 될
것입니다.
더 살펴보실 키워드: Nano Server, OneCore API, Docker for
Windows 2.0, Windows Container (Full)
29. 실습 동영상 찾아보기
• Part 1: SSH 키 생성
• https://youtu.be/aO2HvxcjHIw
• Part 2: Azure RBAC 기반 App 생성
• https://youtu.be/HOaKUUGQ3b8
• Part 3: Rancher 서버 배포
• https://youtu.be/rtur5Hu7ZmI
• Part 4: Kubernetes Control Plane (ETCD, API) 배포
• https://youtu.be/a7piR0fO4Lc
• Part 5: Kubernetes Dedicated Linux 노드 배포
• https://youtu.be/n1hh9jV1oE0
• Part 6: Kubernetes Dedicated Windows 노드 배포
• https://youtu.be/wKWSPmqhPCY
• Part 7: 라우팅 테이블 설정
• https://youtu.be/LKitdbbcbtM
• Part 8: kubectl 설정
• https://youtu.be/XnVwe-F6noo