[Azure] AKS (Azure Kubernetes Service)

1. Kubernetes

1) Kubernetes란?

Kubernetes는 컨테이너 기반 애플리케이션, 관련 네트워킹 및 스토리지 구성 요소를 관리하는 플랫폼이다. 애플리케이션 구성 요소의 가용성을 오케스트레이션하고 관리하는데 도움이 되는 MSA(Microservice Architect)를 구축하고 실행할 수 있다. 또한 기본 설정 프로그래밍 언어, OS, 라이브러리 또는 메시지 버스를 사용해 애플리케이션을 빌드할 수 있다. CI/CD 도구는 Kubernetes와 통합되어 릴리스할 수 있다.

 

2) Kubernetes 클러스터 아키텍처

Control Plane : 응용 프로그램 작업의 핵심 Kubernetes 서비스 및 Orchestration을 제공

Node : 응용 프로그램 워크 로드를 실행하는 노드

https://docs.microsoft.com/ko-kr/azure/aks/concepts-clusters-workloads

3) Control Plane

AKS 클러스터를 만들면 Control Plane이 자동으로 만들어지고 구성된다. Control Plane은 사용자로부터 추상화된 Azure관리 서비스를 제공한다. 비용은 없으며 AKS 클러스터의 노드파트만 비용이 발생한다. Control Plane과 해당 리소스는 클러스터를 만든 지역에만 있다. 

• kube-apiserver : API 서버는 기본 Kubernetes API를 노출하는 방법이다. 이 구성요소는 kubectl 또는 Kubernetes 대시보드와 같은 관리 도구에 대한 상호 작용을 제공한다.
• etcd : 고가용성 etcd는 Kubernetes 클러스터 및 구성의 상태를 유지관리하기 위해 Kubernetes 내에 있는 키 값 저장소이다.
• kube-scheduler : 애플리케이션을 만들거나 확장할 때 스케줄러는 워크로드를 실행할 수 있는 노드를 결정하고 시작한다.
• kube-controller-manager : Controller Manager는 Pod 복제 및 노드 작업처리와 같은 작업을 수행하는 다수의 작은 컨트롤러를 감독한다.

AKS는 전용 API 서버, 스케줄러 등의 단일 테넌트 제어 평면을 제공한다. 노드의 개수 및 크기를 정의하고 Azure 플랫폼은 Control Plane과 노드 간 보안 통신을 구성한다. kubectl 또는 Kubernetes dashboard는 Kubernetes APIs를 통해 상호작용한다.

Control Plane은 etcd store같은 components를 구성할 필요가 없게 한다. 그러나 Control Plane에 직접 액세스할 수 없다는 것을 의미하기도 한다. Kubernetes에 대한 업그레이드는 Azure CLI, Azure Portal을 통해 Orchestartion 된다. 이를 통해 Control Plane, Node를 Upgrade한다. Troubleshooting을 위해 Azure Monitor를 사용, Control plane logs를 확인할 수 있다.

 

4) Nodes and node pools

Applications와 Supporting services를 실행하기 위해, Kubernetes Node가 필요하다. AKS 클러스터에는 하나 이상의 노드가 있다. 이 노드는 Kubernetes 노드 구성 요소 및 컨테이너 런타임을 실행하는 Azure VM이다.

• kubelet은 control plane과 예약된 컨테이너 요청을 orchestration하는 Kubernetes agent이다.
• 가상 네트워킹은 각 노드의 kube-proxy에서 처리된다. 프록시는 네트워크 트래픽을 라우팅하고 서비스와 Pod에 대한 IP 주소 지정을 관리한다.
• Container runtime은 컨테이너화된 애플리케이션을 실행하고 가상 네트워크 및 스토리지와 같은 추가 리소스와 상호작용할 수 있게 하는 구성요소이다.

https://docs.microsoft.com/ko-kr/azure/aks/concepts-clusters-workloads

노드의 Azure VM 크기는 CPU 수, 메모리 크기, 사용 가능한 스토리지의 크기 및 유형을 정의한다. 대용량 CPU와 메모리 또는 고성능 스토리지가 필요한 애플리케이션이 요구되는 경우 노드 크기를 적절히 계획한다. 또한 수요를 충족하도록 AKS 클러스터의 노드 수를 확장할 수 있다.

 

AKS에서 클러스터 노드에 대한 VM이미지는 Ubuntu Linux 또는 Windows Server 2019를 기반으로 한다. AKS 클러스터를 만들거나 노드 수를 확장하는 경우 Azure 플랫폼은 요청 된 VM 수를 만들고 구성한다. 사용자가 수행할 수 있는 수동 구성은 없다. 에이전트 노드는 표준 가상 머신으로 청구되므로 사용중인 VM 크기에 대한 모든 할인이 자동으로 적용된다.

 

다른 호스트 OS, 컨테이너 런타임을 사용하거나 사용자 지정 패키지를 포함해야 하는 경우 aks-engine을 사용해 사용자 고유의 Kubernetes 클러스터를 배포할 수 있다. 업스트림 aks-engine은 AKS 클러스터에서 공식적으로 지원되기 전에 기능을 릴리스하고 구성 옵션을 제공한다. 

 

5) 리소스 예약

Node 리소스는 AKS에서 클러스터의 일부로 node function을 수행하는데 활용된다. 이 사용은 AKS에서 사용될 때 노드의 총 리소스와 할당 된 리소스 간 불일치를 만들 수 있다. 이 정보는 사용자가 배포된 pod에 대한 요청 및 제한을 설정할 때 주의해야 한다.

kubectl describe node [NODE_NAME]

노드 성능 및 기능을 유지 관리하기 위해 리소스는 AKS 별로 각 노드에 예약된다. 노드가 리소스에서 더 크게 증가함에 따라, 관리를 필요로 하는 pod의 사용자 배포로 인해 리소스 예약이 증가한다.

• CPU : 예약 cpu는 노드 유형 및 클러스터 구성에 따라 다르며, 이로 인해 추가 할당 가능한 cpu가 줄어들 수 있다.
• 메모리 : AKS에서 사용하는 메모리는 두 값의 합계를 포함한다.

6) 노드 풀

동일한 구성의 노드는 모두 노드 풀로 그룹화된다. Kubernetes 클러스터에는 하나 이상의 노드 풀이 포함된다. 노드의 초기 수와 크기는 기본 노드 풀을 만드는 AKS 클러스터를 만들 때 정의 된다. AKS의 기본 노드 풀에는 에이전트 노드를 실행하는 기본 VM이 포함된다.

 

AKS 클러스터를 확장 또는 업그레이드할 때 기본 노드 풀에 대한 작업이 수행된다. 특정 노드 풀의 크기를 조정 하거나 업그레이드 하도록 선택할 수 있다. 업그레이드 작업의 경우, 모든 노드가 성공적으로 업그레이드될 때까지 실행 중인 컨테이너는 노드 풀의 다른 노드에 예약된다.

 

7) Node selectors

여러 노드 풀을 포함하는 AKS 클러스터에서 지정된 리소스에 사용할 노드풀을 Kubernetes Scheduler에 알려야 할 수 있다. Node selector를 사용하여 pod가 예약되어야 하는 위치를 제어 하기 위해 노드 OS와 같은 변수를 정의할 수 있다.

kind: Pod apiVersion: v1 metadata:   name: nginx spec:   containers:   - name: myfrontend     image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine   nodeSelector:     "beta.kubernetes.io/os": linux

8) Pod

Kubernetes는 Pod를 사용하여 Application의 인스턴스를 실행한다. Pod는 애플리케이션의 단일 인스턴스를 나타낸다. 일반적으로 Pod는 컨테이너와 1:1매핑이 있지만, 한 Pod에 여러 컨테이너가 포함되는 경우도 있다. 

 

Pod를 만들 때 특정 크기의 CPU또는 메모리 리소스를 요청하는 리소스 요청을 정의할 수 있다. Kubernetes 스케줄러는 요구에 맞게 사용 가능한 리소스가 있는 노드에서 Pod가 실행되도록 예약하려고 시도한다. 지정된 노드에서 기본 노드의 컴퓨팅 리소스를 많이 소비하지 못하도록 제한을 지정할 수 있다. 

 

Pod는 논리적 리소스이지만, 컨테이너는 애플리케이션 워크로드가 실행되는 위치이다. Pod는 일반적으로 사용 후 삭제 가능한 리소스이며, 개별적으로 예약된 Pod에는 Kubernetes에서 제공하는 고가용성 및 중복성 기능 중 일부가 누락된다. 대신 배포 컨트롤러와 같은 Kubernetes컨트롤러에서 pod를 배포하고 관리한다.

 

9) 배포 및 YAML

배포는 Kubernetes 배포 컨트롤에서 관리되는 하나 이상의 동일한 Pod를 나타낸다. 만들 Pod의 수를 정의하고, Kubernetes 스케줄러는 Pod 또는 노드에 문제가 발생하면 추가 Pod가 정상 노드에 예약 되도록 한다.

 

Pod, 사용된 컨테이너 이미지 또는 연결된 스토리지의 구성을 변경하도록 배포를 업데이트 할 수 있다. 배포 컨트롤러는 지정된 수의 복제본을 내보내거나 종료하고, 새 배포 정의에서 복제본을 만든 후 배포의 모든 복제본이 업데이트될 때까지 프로세스를 계속 수행한다.

 

배포는 일반적으로 kubectl create 또는 kubectl apply를 사용하여 만들어지고 관리된다. 배포를 만들려면 manifest 파일을 YAML 형식으로 정의한다. 

apiVersion: apps/v1 kind: Deployment metadata:   name: nginx spec:   replicas: 3   selector:     matchLabels:       app: nginx   template:     metadata:       labels:         app: nginx     spec:       containers:       - name: nginx         image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-airpine         ports:         - containerPort: 80         resources:           requests:             cpu: 250m             memory: 64Mi           limits:             cpu: 500m             memory: 256Mi

10) Helm을 사용한 패키지 관리

Kubernetes에서 애플리케이션을 관리하는 방법은 Helm을 사용하는 것이다. 패키지 버전의 애플리케이션 코드와 Kubernetes YAML 매니페스트가 포함된 기존 공용 Helm 차트를 빌드하고 사용하여 리소스를 배포할 수 있다. 이러한 Helm 차트는 로컬로 저장하거나 Azure Container Registry Helm 차트 리포지토리와 같은 원격 저장소에 저장할 수 있다.

 

Helm을 사용하려면 컴퓨터에 Helm Client를 설치하거나 Azure Cloud Shell에서 투구 클라이언트를 사용한다. 클라이언트에서 Helm 차트를 검색하거나 만든 다음, Kubernetes 클러스터에 설치할 수 있다.

 

11) StatefulSets 및 DaemonSets

배포 컨트롤러는 Kubernetes 스케줄러를 사용하여 사용 가능한 리소스가 있는, 사용 가능한 노드에서 지정된 수의 복제본을 실행한다. 이런 배포 방법은 상태 비저장 애플리케이션에는 충분하지만, 영구적인 규칙이나 스토리지가 필요한 애플리케이션에는 충분하지 않다.

• StatefulSets : Application 상태를 스토리지와 같은 개별 Pod 수명 주기 이상으로 유지
• DaemonSets : Kubernetes Bootstrap process 초기에 각 노드에서 실행 중인 인스턴스를 확인

12) StatefulSets

StatefulSets는 데이터베이스 구성 요소가 포함된 애플리케이션과 같은 상태 저장 애플리케이션에 사용할 수 있다. 하나 이상의 동일한 Pod가 만들어지고 관리된다는 점에서 배포와 비슷하다. StatefulSet의 복제본은 배포, 크기 조정, 업그레이드 및 종료에 대한 순차 접근 방식을 따른다. 명명 규칙, 네트워크 이름 및 저장소가 유지된다.

13) DaemonSets

특정 로그 수집 또는 모니터링이 필요한 경우, 모든 노드 또는 선택한 노드에서 지정된 Pod를 실행해야 할 수 있다. DaemonSet은 하나 이상의 동일한 Pod를 배포하는데 다시 사용되나, DaemonSet 컨트롤러는 지정된 각 노드가 Pod의 인스턴스를 실행하도록 한다.

14) NameSpace

Pod 및 Deployment와 같은 Kubernetes 리소스는 논리적으로 namespace로 그룹화 된다. 이러한 그룹은 AKS 클러스터를 논리적으로 분할하고 액세스를 제한하여 리소스를 만들고 보거나 관리하는 방법을 제공한다. 

https://docs.microsoft.com/ko-kr/azure/aks/concepts-clusters-workloads

• default : Pod 및 배포가 기본적으로 만들어지는 위치.
• kube-system : 이 네임스페이스는 네트워크 기능(예: DNS 및 프록시) 또는 Kubernetes 대시보드와 같은 핵심 리소스가 있는 위치이다. 일반적으로 사용자 고유의 애플리케이션은 이 네임스페이스에 배포하지 않는다.
• kube-public : 이 네임스페이스는 일반적으로 사용되지 않지만, 클러스터 전체에 표시되는 리소스에 사용할 수 있으며 모든 사용자가 볼 수 있다.

2. AKS (Azure Kubernetes Service)

1) AKS란?

AKS(Azure Kubernetes Service)는 운영 오버헤드를 Azure로 오프로드해서 Azure에서 관리되는 Kubernetes 클러스터 배포를 단순화 한다. Azure는 상태 모니터링 및 유지 관리 등 중요 작업을 처리한다. Kubernetes 마스터는 Azure에서 관리되므로, 에이전트 노드만 관리하고 유지 관리한다. AKS는 무료이고, 마스터가 아니라 클러스터 내의 에이전트 노드에 대해서만 지불하게 된다.

 

AKS를 구성하는 방법은 아래와 같다.

• Azure CLI
• Azure Portal
• Azure PowerShell
• Azure Resource Manager Template, Terraform

AKS 클러스터를 배포하면 Kubernetes 마스터 및 모든 노드가 배포되고 구성된다. 프로세스 중 네트워킹, Azure AD, 모니터링 및 기타 기능을 구성할 수 있다.

 

2) Access, Security, Monitoring

AKS를 사용하면 Azure AD와 통합하여 수행할 수 있다.

• Kubernetes RBAC을 사용
• 클러스터 및 리소스 상태를 모니터링

ID 및 보안 관리

Kubernetes RBAC

클러스터 리소스 액세스 제한을 위해 AKS는 Kubernetes RBAC을 지원한다. Kubernetes RBAC은 Kubernetes 리소스 및 네임스페이스에 대한 액세스 및 권한을 제어한다.

Azuer AD

Azure AD와 통합하도록 AKS 클러스터를 구성할 수 있다. Azure AD 통합을 사용하면 기존 ID 및 그룹 멤버 자격을 기반으로, Kubernetes 액세스를 설정할 수 있다. AKS 리소스에 대한 통합 로그온 환경과 액세스를 기존 Azure AD 사용자 및 그룹에 제공할 수 있다.

통합된 로깅 및 모니터링

컨테이너 상태용 Azure Monitor는 AKS 클러스터 및 배포된 애플리케이션 내의 컨테이너, 노드 및 컨트롤러에서 메모리 및 프로세서 성능 메트릭을 수집한다. 

• Azure Log Analytics 작업 영역에 저장
• Azure Portal, Azure CLI 또는 REST Endpoint를 통해 사용할 수 있다.

클러스터 노드 및 Pod 크기 조정

리소스 변경에 따라 서비스를 실행하는 클러스터 노드 또는 Pod 수를 자동으로 확대 또는 축소한다. 수평 Pod 자동 크기 조정 또는 클러스터 자동 크기 조정 모두 수요에 맞게 조정하고 필요한 리소스만 실행할 수 있다.

클러스터 노드 업그레이드

AKS는 여러 Kubernetes 버전을 제공한다. Azure Portal, Azure CLI를 사용하여 클러스터를 업그레이드 할 수 있다. 업그레이드 중에는 노드를 통제하고 드레이닝하여 실행 중인 애플리케이션의 중단을 최소화한다.

GPU 지원 노드

AKS는 GPU 지원 노드 풀 생성을 지원한다. Single, Multi GPU지원 VM을 제공한다.