King of Back-end

우리는 보통 EKS 의 워커 노드로 x86 이든, arm64 이든 리눅스를 사용합니다. 
특히 EKS 환경이라면 아마존 리눅스2를 사용하겠지요.
 
근데 간혹 워커 노드로 윈도우를 필요로 하는 경우가 있습니다. 
 
예를 들어 라이브러리를 만들었는데, 리눅스 뿐만 아니라 윈도우 환경에서도 이 라이브러리를 필요로 합니다. 그렇다면 이 라이브러리를 이미지로 빌드하려면 리눅스가 아닌 윈도우 환경에서 만들어야 하죠.
 
다행히 EKS 는 윈도우를 지원해줍니다. 또한 Karpenter 에서도 윈도우를 지원해주죠.
 
그럼 어떻게 EKS 환경에서 윈도우를 활성화 하는지, 이후 Karpenter 에서 윈도우를 어떻게 프로비저닝 하는지 한번 알아보도록 하죠.
 
참고로 진행한 쿠버네티스 버전은 1.23 이고, Karpenter 는 0.31 버전입니다.
 
그럼 렛츠두더코드~
 
 
EKS 설정
아래 방법은 아마존 공식 문서에 잘 나와있지만, 혹시나 저처럼 막히는 분들을 위해서~
 
아래 표에 나와있는 쿠버네티스 버전은 사용한다면 무리없이 윈도우를 활성화 할 수 있습니다. 만약 해당 표에 없는 버전을 사용하고 있다면, Enable legacy Windows support 를 보고 진행해주세요.
 
저는 1.23 버전을 사용하니 해당 문서를 보고 진행이 가능하겠네요.
 
다음은 고려 사항입니다.
 
CoreDNS 는 리눅스 기반 워커 노드에 배포 하고~ 블라블라 쭉 쭉 읽어줍니다. 빨간색 네모 친 마지막 줄은 관련 설정을 해주어야 합니다.
 
aws-auth 컨피그맵에 아래 이미지와 같이 권한을 추가해줍시다.
$ k edit configmaps -n kube-system aws-auth -o yaml
해당 작업을 안해줘도, Window 기반의 워커 노드가 런칭은 됩니다.
하지만, 이후 파드를 배포했을 때 해당 파드가 CoreDNS 를 찾지 못해서 google.com 와 같은 퍼블릭 도메인 뿐만 아니라,
svc.cluster.local 와 같은 서비스 관련된 도메인도 찾지 못하게 됩니다.
꼭 놓치지 말고 추가해줍시다!
 
이제 다음으로 넘어가보죠.
EKS Cluster Role 에게 해당 정책을 부여하라고 하는데, 테라폼으로 EKS 를 구성했을 경우 다 기본적으로 할당되어 있을테니 크게 건들건 없습니다.
위 이미지에서 빨간색 네모를 보면 "eksClusterRole 을 너의 클러스터에 할당된 Role 이름으로 바꿔라" 라고 하는데,
저는 이걸 처음에 잘못 해석해서, 기존에 있던 Role 이름을 eksClusterRole 로 바꾸라는 말로 이해하고,
엄청난 뻘짓을 했죠.
 
2번은 마찬가지로 테라폼으로 생성했을 경우, 크게 신경쓸 건 없습니다.
 
중요한 건 3,4번입니다. 
중요하지만 어려운 건 없습니다. 그대로 따라해줍니다.
 
이로써 EKS 에서의 설정은 끝났습니다. 그럼 이어서 Kapenter 를 통해서 윈도우 기반의 워커 노드를 배포해보죠.
 
 
Karpenter 설정
Karpenter 의 개념이나 사용 방법은 여기를 참고!
 
Karpenter 버전은 반드시 0.29 이상을 사용해야 합니다. 이유는 Window AMI 를 0.29 버전 이후부터 지원해주기 때문이죠.
0.27 이하 버전에서 0.28 이상 버전으로 업데이트 할 때 단순히 이미지를 업데이트 해준다고 배포되지 않아요.
꽤나 많은 것들이 바뀌었기 때문에 꼭 공식 문서를 보고 진행해주세요!!!!!
 
Karpenter 가 사용하는 Windows2019, Windows2022 의 이미지는 다음과 같아요. 
Full 이 아닌 Core 만 사용합니다.
 
아래는 예시 AWSNodeTemplate 입니다. .spec.amiFamiliy 부분을 바꿔줍니다.
apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
  name: window-aws-node-template
spec:
  amiFamily: Windows2019
  blockDeviceMappings:
    - deviceName: /dev/sda1
      ebs:
        volumeSize: 50Gi
        volumeType: gp2
        encrypted: false
        
  securityGroupSelector:
    ...
    
  instanceProfile: 
    ...
  
  subnetSelector:
    ...
    
  tags:
    ...
.spec.securityGroupSelector 를 통해 생성되는 윈도우 워커 노드에 보안 그룹을 할당해줄 수 있는데, 이때 꼭 마스터 노드와 다른 워커 노드에 통신이 가능할 수 있도록 인바운드 규칙을 지정해줍니다.
마스터 노드와 통신이 가능해야 하는 이유는 워커 노드를 등록하기 위해서이고,
다른 워커 노드와 통신이 가능해야 하는 이유는 CoreDNS 와 통신이 가능해야 하기 때문입니다.
만약 NetworkPolicy 를 사용한다면 관련 Rule 또한 허용해줍니다.
아래 이미지는 해당 행위를 하지 않았을 경우 발생할 수 있는 에러입니다.
 
이로써 카펜터 부분도 끝이 났으니, 실제로 윈도우 노드를 띄어보죠!
 
 
윈도우 노드에 윈도우 파드 테스트
위 방법으로 윈도우 기반의 워커 노드를 띄우고, 파드를 배포해보겠습니다!
apiVersion: v1
kind: Pod
metadata:
  name: win-webserver
  labels:
    app: win-webserver
spec:
  containers:
    - name: windowswebserver
      image: mcr.microsoft.com/windows/servercore:ltsc2019
      command:
        - powershell.exe
        - -command
        - "Write-Host 'Hello, World!'; Sleep -s 3600"
 
파드를 배포했더니, 아래와 같은 에러가 발생합니다.
자세히 읽어보면 파드에 추가적인 private ip eni 할당을 못하고 있습니다.
 
node 를 살펴보면 할당가능한 IP 는 11개라고 나옵니다. 또한 워커 노드의 상태도 Not Ready 가 아닌 Ready 입니다.
 
혹시 aws-vpc-cni 가 너무 구버전(1.11) 이라서 그런가 싶어서 1.15 버전으로 업데이트를 하고 다시 시도해보죠!
 
여전히 같은 문제가 발생합니다...
 
그러던 중 모든 window 파드 example 에 한가지 공통된 것을 발견했습니다!!
바로 NodeSelector 로 window 를 지정하는 것이였죠!!!!
apiVersion: v1
kind: Pod
metadata:
  name: win-webserver
  labels:
    app: win-webserver
spec:
  containers:
    - name: windowswebserver
      image: mcr.microsoft.com/windows/servercore:ltsc2019
      command:
        - powershell.exe
        - -command
        - "Write-Host 'Hello, World!'; Sleep -s 3600"
  nodeSelector:
    kubernetes.io/os: windows
 
그랬더니 아주 배포가 잘되는 것을 확인할 수 있습니다!!
 
 
이렇게 오늘은 윈도우 워커 노드를 Karpenter 로 프로비저닝하고, 윈도우 기반의 파드를 실행해봤습니다.
 
윈도우 워커 노드는 efs-csi-driver 와 같은 추가적인 애드온들이 지원이 안되기 때문에 리눅스 워커 노드처럼 많은 것을 할 순 없지만, 그래도 CI/CD 에는 유용하게 쓸 수 있을 거 같습니다.
 
그럼 오늘은 여기까지~

[Kubernetes] 너 내 노드가 되라! - EKS Windows 활성화

댓글