Azure Kubernetes Service 클러스터에 애플리케이션 배포
- 10분
회사에서는 클라우드 기반 비디오 렌더링 서비스를 배포하는 방법을 찾고 있습니다. 클라우드 네이티브 개발 플랫폼으로 AKS(Azure Kubernetes Service)를 선택했습니다. 클러스터가 구성되면 비디오 렌더링 애플리케이션의 구성 요소 중 하나를 배포할 준비가 되었습니다. 회사 웹 사이트의 정적 버전을 배포하여 Kubernetes 배포 프로세스를 살펴보기로 합니다.
Kubernetes 배포 방법에 대해 논의하기 전에 비슷한 애플리케이션을 Kubernetes 이외의 환경에 배포하기 위해 수행하는 몇 가지 단계를 알아보겠습니다.
Azure VM(가상 머신)을 대상 플랫폼으로 사용하고 있다고 가정해 보겠습니다. 첫 번째 단계는 애플리케이션을 호스트하는 서버 소프트웨어를 준비하는 것입니다. 다음을 수행합니다.
- 운영 체제를 설치합니다.
- OS를 최신 보안 및 소프트웨어 패치로 업데이트해야 합니다.
- 웹 서버 소프트웨어를 설치 및 구성합니다.
- 웹 애플리케이션을 배포합니다.
고객 요구의 증가를 처리하기 위해 웹 사이트를 스케일 아웃하기로 한 경우 새 VM마다 이 프로세스를 반복합니다.
또 다른 방법은 Azure Container Instances와 같은 컨테이너 기반 플랫폼에서 웹 사이트를 실행하는 것입니다. 기본 서버 기술에 대해 걱정할 필요가 없지만 이 전략을 수동으로 사용하려면 여러 컨테이너를 구성하고 관리해야 합니다.
Kubernetes 및 AKS는 컨테이너를 오케스트레이션하는 데 도움을 줍니다. Kubernetes 컨테이너 오케스트레이션 기능을 사용하면 클러스터의 워크로드를 쉽게 관리할 수 있습니다. 컨테이너 이미지에서 빌드된 컨테이너를 사용하여 워크로드를 배포하면 AKS 클러스터 내에서 애플리케이션을 실행할 수 있습니다.
여기에서는 AKS 클러스터에서 워크로드를 만드는 방법을 알아볼 수 있습니다.
컨테이너 레지스트리란?
컨테이너 레지스트리를 사용하면 나중에 배포하기 위해 컨테이너 이미지를 클라우드에 안전하게 저장할 수 있습니다. 컨테이너 레지스트리는 여러 버전의 컨테이너 이미지를 저장하는 보관 파일이라고 생각할 수 있습니다. 저장된 각 이미지에는 식별을 위해 할당된 태그가 있습니다.
예를 들어 contoso-website:v1.0.0 태그가 있는 다른 버전의 이미지인 contoso-website:latest 이미지가 있을 수 있습니다.
컨테이너 레지스트리는 퍼블릭이거나 프라이빗일 수 있습니다. 프라이빗 레지스트리는 이미지에 액세스하고 다운로드하는 데 자격 증명이 필요하며 컨테이너 이미지를 저장할 때 따르는 전략입니다.
Kubernetes를 사용할 때만 컨테이너 레지스트리에 호스트된 이미지를 배포할 수 있습니다. 프라이빗 컨테이너 레지스트리를 만드는 것은 일반적으로 표준 AKS 배포 전략의 일부입니다.
Kubernetes Pod란?
Kubernetes Pod 는 컨테이너 및 애플리케이션을 논리적 구조로 그룹화합니다. 이러한 pod는 인텔리전스를 포함하지 않으며 하나 이상의 애플리케이션 컨테이너로 구성됩니다. 각 애플리케이션 컨테이너에는 IP 주소, 네트워크 규칙 및 노출된 포트가 있습니다.
예를 들어 contoso-website와 관련된 모든 워크로드를 검색하려면 레이블 app 및 값 contoso-website를 사용하여 클러스터의 pod를 쿼리합니다.
Kubernetes 배포란?
Kubernetes 배포는 Pod의 진화입니다. 배포는 Pod를 스케일 아웃할 수 있는 인텔리전트 개체로 래핑합니다. 복잡한 네트워킹 규칙을 구성할 필요 없이 더 많은 로드를 지원하도록 애플리케이션을 쉽게 복제하고 스케일링할 수 있습니다.
배포를 통해 사용자는 이미지 태그를 변경하는 것만으로 가동 중지 시간 없이 애플리케이션을 업데이트할 수 있습니다. 배포를 업데이트할 때 모든 앱을 삭제하는 대신 배포에서 온라인 앱을 하나씩 해제합니다. 그런 다음 최신 버전으로 교체합니다. 이렇게 함으로써 모든 배포가 가용성에 아무런 가시적인 영향도 미치지 않고 배포 내부의 pod를 업데이트할 수 있습니다.
Kubernetes 매니페스트 파일
Kubernetes 매니페스트 파일을 사용하면 YAML 형식의 워크로드를 선언적으로 설명하고 Kubernetes 개체 관리를 간소화할 수 있습니다.
워크로드를 직접 배포해야 한다면 몇 가지 측면을 고려하고 관리해야 합니다. 예를 들어 컨테이너를 만들고, 특정 노드를 선택하여 pod에 래핑하고, pod를 실행하고, 실행을 모니터링해야 합니다.
매니페스트 파일에는 설명된 워크로드를 만들고 관리하는 데 필요한 모든 정보가 포함되어 있습니다.
Kubernetes 레이블이란?
Kubernetes 레이블을 사용하면 Kubernetes 개체를 논리적으로 그룹화할 수 있습니다. 이러한 레이블을 사용하면 시스템이 클러스터에서 특정 이름의 레이블과 일치하는 개체를 쿼리할 수 있습니다.
매니페스트 파일의 구조
매니페스트 파일의 구조는 운영자가 만드는 리소스의 유형에 따라 다릅니다. 그러나 매니페스트 파일은 일반적인 지침을 공유하며, 이러한 지침은 사용할 API 및 만들 워크로드의 유형과 같은 다양한 측면을 정의합니다.
모든 매니페스트 파일에서 처음 두 개 항목에는 apiVersion 및 kind라는 두 개의 중요한 키가 있습니다. 배포 파일의 예는 다음과 같습니다.
apiVersion: apps/v1 # Where in the API it resides
kind: Deployment # The kind of workload we're creating
apiVersion 키는 배포하는 개체를 관리하는 API 서버 엔드포인트를 정의합니다.
kind 키는 이 배포에서 생성되는 워크로드를 정의합니다.
모든 파일에 대한 다른 일반적인 키는 metadata 및 name 키입니다. 모든 Kubernetes 리소스에는 이름이 ‘있어야 합니다’. 해당 이름은 metadata 키 내부로 이동합니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: contoso-website # This will be the name of the deployment
배포에서 개체 그룹화
배포는 label을 활용하여 pod를 찾고 그룹화합니다. 레이블은 배포 매니페스트 파일의 일부로 정의합니다.
예를 들면 다음과 같습니다. spec 정의에 추가된 selector 정의에 matchLabels 값이 정의된 것을 확인합니다.
# deployment.yaml
# ...
spec:
selector:
matchLabels:
app: contoso-website
# ...
이 시점부터 모든 파일의 구조는 Kubernetes에 생성하도록 지시하는 리소스의 종류에 따라 다릅니다.
배포 파일 적용
kubectl을 사용하여 Kubernetes 배포 매니페스트 파일을 배포합니다. 다음은 명령의 예입니다.
kubectl apply -f ./deployment.yaml