Windows Server 애플리케이션 배포

표준

---

이 페이지에서는 공개 또는 비공개 Google Kubernetes Engine(GKE) 클러스터에 스테이트리스(Stateless) Windows Server 애플리케이션을 배포하는 방법을 알아봅니다 스테이트풀(Stateful) Windows 애플리케이션을 배포하는 방법도 설명합니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

• Artifact Registry API 및 Google Kubernetes Engine API를 사용 설정합니다.
API 사용 설정
• 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치한 경우 gcloud components update를 실행하여 최신 버전을 가져옵니다.
  참고: 기존 gcloud CLI 설치의 경우 compute/region 및 compute/zone 속성을 설정해야 합니다. 기본 위치를 설정하면 gcloud CLI에서 One of [--zone, --region] must be supplied: Please specify location과 같은 오류를 방지할 수 있습니다.

Windows Server 애플리케이션을 클러스터에 배포

Windows Server 애플리케이션을 GKE 공개 클러스터에 배포하려면 다음 작업을 수행해야 합니다.

1. 클러스터를 만듭니다.
2. 배포 매니페스트 파일을 만듭니다.
3. 배포를 만들고 노출합니다.
4. Pod가 실행 중인지 확인합니다.

클러스터 만들기

Windows Server 노드 풀을 사용하는 GKE 클러스터가 이미 있으면 다음 단계로 진행합니다. 그렇지 않으면 Windows Server 노드 풀을 사용하여 클러스터를 만듭니다.

배포 매니페스트 파일 만들기

Windows Server 노드는 node.kubernetes.io/os=windows:NoSchedule 키-값 쌍으로 taint됩니다.

이 taint는 GKE 스케줄러가 Windows Server 노드에서 Linux 컨테이너를 실행하지 않도록 합니다. Windows Server 노드에서 Windows Server 컨테이너를 예약하려면 매니페스트 파일에 다음 노드 선택기가 포함되어야 합니다.

nodeSelector:
 kubernetes.io/os: windows

클러스터에서 실행되는 허용 웹훅은 새 워크로드에 이 Windows 노드 선택기가 있는지 확인하고 발견하면 다음 내결함성을 워크로드에 적용하여 taint된 Windows Server 노드에서 실행되도록 합니다.

tolerations:
- effect: NoSchedule
  key: node.kubernetes.io/os
  operator: Equal
  value: windows

경우에 따라 이 내결함성을 매니페스트 파일에 명시적으로 포함해야 할 수도 있습니다. 예를 들어 클러스터의 모든 Linux 및 Windows Server 노드에서 실행되도록 멀티 아키텍처 컨테이너 이미지가 있는 DaemonSet을 배포할 경우 매니페스트 파일에 Windows 노드 선택기가 포함되지 않습니다. Windows taint에 대한 내결함성을 명시적으로 포함해야 합니다.

매니페스트 파일 예시

다음 예시 배포 파일(iis.yaml)은 Microsoft의 IIS 이미지를 단일 pod에 배포합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis
  labels:
    app: iis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: iis
  template:
    metadata:
      labels:
        app: iis
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: iis-server
        image: mcr.microsoft.com/windows/servercore/iis
        ports:
        - containerPort: 80

이 파일은 모든 워크로드가 동일한 Windows Server 노드 이미지 유형과 버전을 사용하는 클러스터용입니다. 혼합 노드 이미지 작업 방법에 대한 자세한 내용은 혼합 노드 이미지 사용 섹션을 참조하세요.

배포 만들기 및 노출

이전 단계에서 만든 배포 파일을 외부 부하 분산기 배포가 있는 Kubernetes 서비스로 만들고 노출합니다.

1. 배포 리소스를 만들려면 다음 명령어를 실행합니다.

   kubectl apply -f iis.yaml
   

2. 배포를 외부 부하 분산기로 노출하려면 다음 명령어를 실행합니다.

   kubectl expose deployment iis \
       --type=LoadBalancer \
       --name=iis
   

포드가 실행 중인지 확인

Pod의 유효성을 검사하여 Pod가 작동하는지 확인합니다.

1. kubectl을 사용하여 포드 상태를 확인합니다.

   kubectl get pods
   

2. 반환된 출력에 포드 상태가 Running으로 표시될 때까지 기다립니다.

   NAME                   READY     STATUS    RESTARTS   AGE
   iis-5c997657fb-w95dl   1/1       Running   0          28s
   

3. 서비스 상태를 가져오고 EXTERNAL-IP 필드가 채워질 때까지 기다립니다.

   kubectl get service iis
   

   다음과 같은 출력이 표시됩니다.

   NAME   TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
   iis    LoadBalancer   10.44.2.112   external-ip    80:32233/TCP   17s
   

이제 IIS 웹페이지를 보기 위해 브라우저를 사용하여 http://EXTERNAL_IP를 열 수 있습니다.

비공개 클러스터에 Windows Server 애플리케이션 배포

이 섹션에서는 Windows Server 컨테이너 애플리케이션을 비공개 클러스터에 배포하는 방법을 설명합니다.

Windows Server 컨테이너 이미지에는 여러 레이어가 있고 기본 레이어는 Microsoft에서 제공됩니다. 기본 레이어는 Linux Docker 이미지 레이어와 마찬가지로 이미지와 함께 삽입되는 것이 아닌 외부 레이어로 저장됩니다. Windows Server 컨테이너 이미지를 처음으로 가져올 경우 일반적으로 Microsoft 서버에서 기본 레이어를 다운로드해야 합니다. 비공개 클러스터 노드는 인터넷에 연결되어 있지 않으므로 Windows Server 기본 컨테이너 레이어를 Microsoft 서버에서 직접 가져올 수 없습니다.

비공개 클러스터를 사용하려면 비분산 레이어를 비공개 레지스트리로 푸시하도록 Docker 데몬을 구성하면 됩니다. 자세한 내용은 Docker의 GitHub 페이지에서 비분산 아티팩트 푸시 허용을 참조하세요.

Windows Server 애플리케이션을 비공개 클러스터에 배포하려면 다음 안내를 따르세요.

1. Windows Server 노드를 사용하여 비공개 클러스터를 만듭니다.
2. Windows Server 애플리케이션 Docker 이미지를 빌드합니다.
3. 애플리케이션을 비공개 클러스터에 배포합니다.
4. Pod가 실행 중인지 확인합니다.

비공개 클러스터 만들기

Windows 서버 노드로 클러스터 만들기와 비공개 클러스터 만들기의 안내를 따라 Windows 노드 풀을 만들고 비공개 클러스터에 추가합니다.

Windows Server 애플리케이션 Docker 이미지 빌드

1. Docker 이미지를 빌드하려면 애플리케이션 컨테이너를 실행할 Windows Server 버전(예: Windows Server 2019 또는 Windows Server 버전 20H2)으로 Compute Engine 인스턴스를 시작합니다. 또한 인터넷에 연결되어 있는지 확인합니다.

2. Compute Engine 인스턴스에서 Docker 데몬 구성으로 이동합니다.

   cat C:\ProgramData\docker\config\daemon.json
   

3. 다음 줄을 추가하여 외부 레이어를 비공개 레지스트리로 푸시할 수 있도록 Docker daemon.json 파일을 구성합니다.

   {
     "allow-nondistributable-artifacts": ["REGISTRY_REGION-docker.pkg.dev"]
   }
   

   이 예시에서 REGISTRY_REGION-docker.pkg.dev는 이미지가 호스팅되는 Artifact Registry를 참조합니다.

4. Docker 데몬을 다시 시작합니다.

   Restart-Service docker
   

5. Artifact Registry에서 Docker 저장소를 만듭니다.

6. 애플리케이션의 Docker 이미지를 빌드하고 태그를 지정합니다.

   cd C:\my-app
   

   docker build -t REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2 .
   

   이 명령어는 현재 디렉터리에서 Dockerfile을 사용하여 이미지를 빌드하고 us-central1-docker.pkg.dev/my-project/my-repository/my-app:v2와 같은 이름으로 태그를 지정하도록 Docker에 지시합니다.

7. 애플리케이션의 Docker 이미지를 프로젝트의 Artifact Registry 저장소로 푸시합니다. allow-nondistributable-artifacts 구성 집합은 Windows 기본 레이어가 비공개 레지스트리로 푸시되도록 합니다.

   docker push REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2
   

배포 매니페스트 파일 만들기

다음은 my-app.yaml이라는 샘플 배포 매니페스트 파일입니다. 이 예시의 이미지는 앞의 단계(REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2)에서 푸시한 이미지입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: my-server
        image: REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2

1. 만든 클러스터에 kubectl이 작동하도록 하려면 get-credentials 명령어를 사용하세요.

   gcloud container clusters get-credentials CLUSTER_NAME
   

   CLUSTER_NAME을 생성된 클러스터 이름으로 바꿉니다.

2. my-app.yaml 파일에 지정된 애플리케이션을 비공개 클러스터에 배포합니다.

   kubectl apply -f my-app.yaml
   

Pod가 실행 중인지 확인

모든 포드를 나열하여 애플리케이션이 올바르게 실행 중인지 확인합니다.

kubectl get pods

다음 출력과 같이 상태가 Running인 포드가 표시됩니다.

NAME                     READY   STATUS    RESTARTS   AGE
my-app-c95fc5596-c9zcb   1/1     Running   0          5m

혼합 노드 이미지 사용

클러스터에는 여러 가지 Windows Server 유형과 Windows Server 버전의 노드 풀이 포함될 수 있습니다. 또한 Windows Server와 Linux 워크로드를 결합할 수 있습니다. 다음 섹션에서는 이러한 유형의 클러스터를 사용하도록 워크로드를 구성하는 방법을 자세히 설명합니다.

다양한 Windows Server 노드 이미지 유형에서 워크로드 사용

서로 다른 Windows Server 이미지 유형을 사용하는 노드 풀을 클러스터에 추가할 수 있습니다. Windows Server 유형이 혼합된 클러스터에서는 Windows Server 컨테이너가 호환되지 않는 Windows Server 노드에 예약되지 않는지 확인해야 합니다.

Windows Server LTSC 노드 풀 한 개와 Windows Server SAC 노드 풀 한 개가 있으면 두 워크로드에 gke-os-distribution 노드 라벨을 추가합니다.

Windows Server LTSC 워크로드의 매니페스트 파일에 다음 nodeSelector를 포함합니다.

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_ltsc

Windows Server SAC 워크로드의 매니페스트 파일에 다음 nodeSelector를 포함합니다.

경고: Windows Server 반기 채널(SAC) 이미지는 Microsoft에서 SAC 지원 중단으로 인해 2022년 8월 9일부터 지원되지 않습니다. 잠재적 영향과 마이그레이션 안내는 Windows Server 반기 채널 서비스 종료를 참조하세요.

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_sac

이 라벨을 추가하면 LTSC 컨테이너 이미지가 호환되지 않는 SAC 노드에 예약되지 않으며 반대의 경우도 마찬가지입니다.

다양한 Windows Server LTSC OS 버전에서 워크로드 사용

Windows Server 노드는 LTSC2022 및 LTSC2019 OS 이미지를 모두 지원합니다. nodeSelector에서 cloud.google.com/gke-windows-os-version=2022 키-값 쌍으로 사용할 Windows OS 버전 (LTSC2022)을 지정할 수 있습니다.

이 노드 라벨은 GKE 스케줄러가 LTSC2022 또는 LTSC2019 워크로드를 실행할 올바른 Windows Server 노드를 선택하도록 합니다. Windows Server 노드 모두 windows_ltsc_containerd 이미지 유형에 속합니다. 노드 라벨의 값은 2022 또는 2019일 수 있습니다. 노드 라벨을 지정하지 않으면 LTSC2019 또는 LTSC2022 노드를 모두 사용하여 컨테이너를 예약할 수 있습니다. Windows Server LTSC2022 노드에서만 Windows Server 컨테이너를 예약하려면 매니페스트 파일에 다음 노드 선택기가 포함되어야 합니다.

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_ltsc
   cloud.google.com/gke-windows-os-version: 2022

다양한 Windows Server 버전에서 작업 워크로드 사용

다양한 LTSC 또는 SAC 버전의 Windows Server 노드 풀을 실행해야 하는 경우에는 컨테이너 이미지를 클러스터에서 사용 중인 모든 Windows Server 버전에서 실행할 수 있는 멀티 아키텍처 이미지로 빌드하는 것이 좋습니다. gke-os-distribution 노드 라벨만으로는 워크로드가 호환되지 않는 노드에 예약되는 것을 막지 못할 수 있습니다.

클러스터 한 개에서 Linux 및 Windows Server 워크로드 사용

다음 노드 선택기를 Linux 워크로드에 추가하여 항상 Linux 노드에 예약되도록 합니다.

nodeSelector:
   kubernetes.io/os: linux

이렇게 하면 NoSchedule taint가 실수로 Windows Server 노드에서 삭제될 경우 Linux 워크로드가 Windows Server 노드에 예약되지 않도록 추가 보호 기능이 제공됩니다.

참고: Linux에서만 실행되는 DaemonSet의 경우 이 nodeSelector가 필수입니다.