PKOS - 중간 과제 Azure Kubernetes Service 간단 소개

중간 과제 주제 선정 이유

3주차 스터디 과정중 최진영님의 AWS EKS 서비스에 대한 소개 발표를 듣고 또다른 3사의 클라우드 플랫폼인 Azure에 PaaS형 쿠버네티스 서비스를 소개하는 것은 어떨까? 하는 생각이 들어 간단하게 소개하고자 주제를 선정하게 되었다.

( Azure Kubernetes Service를 간단히 소개 하는 이유는 다른 PaaS형 서비스도 마찬가지만 깊이 있는 부분은 워낙 방대하기에... 전부 다룰 수 없어서... 제목을 정하게 되었다. 추후 블로그 활동을 통해 Azure에 관한 다양한 기술들을 다루어볼 예정.. )  

 

Managed Kubernetes란?

우선 AKS, EKS, GKE ... 등 이런 클라우드 위에서 동작하는 PaaS형 서비스에 대해 다루기 전에 Managed Kubernetes Service의 개념과 특징은 무엇인지 Managed Kubernetes는 온프램 위에서 동작하는 Kubernetes와는 어떤 차이점이 있는지 다루어 볼까 합니다.

Managed 쿠버네티스에 정의를 내리자면 다양한 CSP (Cloud service provider) 사가 K8s 설정 및 운영에 필요한 작업의 일부 또는 전부를 담당하는 PaaS형 쿠버네티스 서비스 즉 완전 관리형 서비스입니다.

쿠버네티스에는 이미 확장성, 자격 증명 구성, 자체 복구, 워크로드 관리 및 일괄 실행, 점진적 애플리케이션 배포를 비롯한 다양한 기능이 포함되어 있지만 초기 구성 부터 직접 구성 해서 사용하기에는 많은 부분을 수동으로 구성 해야 하고 상당한 시간과 자원이 소모 됩니다.

Managed 쿠버네티는 앞서 이러한 문제를 해결하고자 여러 벤더사에서 다양한 자사 솔루션과 연계를 통해 더욱 효과적으로 Kubernetes 를 통한 인프라 구축 솔루션을 제시 하였습니다.

 

Managed Kubernetes Service 대표적인 특징

•구성, 설치 소요  시간 단축.

•컨트롤 플레인 자동으로 생성됨에  따라  직접 액세스 하여 구성 및 관리할 필요가 없으며 ,  그로 인해 발생되는  휴먼 에러 방지.

•간편하게 클러스터 버전 업그레이드 및 노드 Scale out가능.

•보안, 거버넌스, ID 및 액세스를 관리에  용이.

•클라우드 기능이 포함된 워크로드 실행에 적합.

 

 

DIY with Kubernetes vs  Managed Kubernetes on Azure

쿠버네티스 클러스터의 구축은 무조건 Managed Kubernetes 사용만이 정답은 아닙니다. 주어진 환경이나 목적, 그리고 비용에 따라 그에 맞는 배포 방법은 다를 수 있습니다. 크게 3가지 관점에서 보고 각각의 장점과 단점에 대해 알아 보겠습니다.

 

(온프레미스 Kubernetes 클러스터 구축)

첫번째로 자체 서버 환경에서 쿠버네티스를 구성하는 경우 쿠버네티스 서버 인프라를 사용자의 취향에 맞게 미세하게 설정 할 수 있고 다양한 3rd 솔루션들을 사용할 수 있다는 장점이 있습니다.

하지만 이렇게 직접 구성을 할 경우 모든 관리를 직접 해야 하기 때문에 운영,관리가 복잡해집니다. 그에 맞는 관리 전문 인력도 필요합니다.

 

(클라우드 인프라위에 직접 Kubernetes 클러스터 구축 )

두번째로 클라우드 환경위에 직접 K8s를 직접 구성 할 경우는 클라우드의 인프라 위에 설치함으로써 인프라의 관리를 벤더사에 이관합니다. 예를들면 PKOS 스터디의 kOps로 설치하는 환경입니다. 이경우는  Managed 서비스 보다 api-server의 커스터 마이징이 가능하고 사용자의 취향에 따라 자유로운 설정이 가능하고 인프라는 벤더사의 서비스를 이용하여 직접 구축하는 경우 보다 인프라 관리면에서는 장점이 있습니다. 하지만 클라우드에 대해 전문 인력이 필요하고, K8s를 관리하는 전문인력도 필요합니다.

그리고 클라우드 내에서 클러스터를 구축하는 과정과 클러스터와 쿠버네티스를 연결하는 과정이 어려울 수 있습니다.

 

( 클라우드의 PaaS형 Kubernetes 사용,구축 )

마지막으로

Managed K8s 서비스를 사용하는 경우 별도의 K8s 클러스터 설치가 필요 없고 인프라와 K8s클러스터를 벤더사에서 관리합니다. 비교적 쉽게 사용이 가능하고 각 클라우드 플랫폼의 추가적인 기능, 솔루션등을 연계하여 활용할 수 있습니다. Managed 서비스 도입 전에는 요구사항 분석과, 필요한 기능이 Managed 서비스에서 구축가능한지 확인하는 단계가 필요합니다.

 

그림1 - 온프램에 K8s vs AKS 차이점

 

앞서 언급한 두번째의 경우를 제외하고 (프로덕션 상황에서는 권장하지 않음) 온프레미스와 PaaS형 Kubernetes 차이점을 몇가지 살펴 보면 온프레미스 상에서는 기존에 모니터링, 로깅을 별도로 구축해서 사용을 했다고 하면 매니지드 서비스를 사용하면 이러한 부분들이 플랫폼 안에 포함이 되어 사용을 할 수 있습니다. 또한 스케일링에 대한 기능 또한 자동으로 지원,클러스터 업그레이드와, OS 패치 같은 기본적인 기능 또한 자동으로 제공하고 있습니다. 위에 3가지 영역은 사용자가 직접 별도의 툴을 사용하여 구축을 해도 상관없지만 Azure에서는 CI/CD 와 애플리케이션에 관련된 디버깅. 컨테이너라이제이션 기능 또한 제공하여 이러한 기능들을 이용하면 손쉽게 사용할 수 있습니다.

 

Azure Kubernetes Service (AKS) 소개

AKS란?

Azure의 PaaS 서비스로 호스팅되는 완전히 관리되는 Kubernetes 플랫폼.

Azure Cloud Platform에 PaaS형 Kubernetes Service

• Azure 클라우드는 퍼블릭 클라우드 공급 업체 중 가장 많은 서비스 지원 리전을 보유 (약 60개 이상)
• Kubernetes Service 리전 지원 (약 35개 이상), 현재도 확장 중
• Azure Service와 연계 및 연동 가능 (ACR, ACI, Azure DevOps, Azure Monitor 등)
• Kubernetes의 Master Node(Control Plane)와 Worker Node의 통합된 프로비저닝 및 관리 기능 제공

 

AKS의 대표적인 특징

• 서버리스 환경으로 제공
• 쿠버네티스 API서버의 작동시간을 99.99% 보장
• 쉽고 안전한 클러스터 Scale in/out
• Auto-Healing
• 업그레이드 및 패치가 자동으로 이뤄짐
• GPU Node 지원
• API 서버에 대한 로깅 및 모니터링 제공
• GitHub Actions, Azure DevOps와 통합지원
• Control Plane Node 무료 제공. ( 단 가용성 영역에 배포시 비용 발생, Singile Zone 배포 무료 )

 

Azure managed control plane

초기의 Azure상에 Kubernetes는 관리형 서비스가 아니었습니다.  사용자들은 Kubernetes 워크로드를 Kubernetes API Endpoint에 제출하여 구성하였고, 마스터 인프라, API 서버, 스케줄러, 컨트롤러 Kubernetes의 데이터 저장소인 etcd를 모두 고객이 직접 관리해야만 했습니다. 이러한 방법은 대부분의 IaaS 서비스 공급자와 온프레미스에서 동작하는 방식입니다. 하지만 마스터 인프라 유지관리 같은 작업을 포함해 처리해야할 작업이 너무 많기 때문에 이로 인해 많은 문제들이 발생했고 이러한 방법은 이상적인 방법은 아니었습니다.. 그렇다면 클라우드 상에서 Kubernetes의 장점을 이용하려면 어떻게 해야 할까요? 많은 구성 작업이 있어야 하고, 이를 위해서 대규모의 팀을 꾸려야 할 겁니다.

 

AKS는 이러한 불편하고 어려운 작업들을 모아 관리형 서비스로 만들었습니다.자동 업그레이드와 패치 뿐만 아니라 높은 안정성과 가용성, 포탈의 슬라이더를 통한 손쉬운 클러스터 스케일링, 그리고 전반에 걸친 자가 복구 기능, 컨트롤 영역과 데이터 영역 노드 풀,  모니터링을 제공합니다. 이미 앞서 언급 하였지만 Azure는 이러한 Control Plane에 대한 서비스를 무료로 제공하고 있습니다.

Azure Control Plane의 관리 영역 - 1

 

Azure Control Plane의 관리 영역 - 2

 

AKS 기능

Networking 

 

Azure CNI networking

•Azure VNet과 Pod간 통신을 연결 시켜주는 Bridge 역할

•Pod는 Subnet에서 IP주소를 할당 받아,  연결된 VNet의 리소스에 엑세스 가능

•Pod 트래픽 속도가 빠름

•각 노드 당 최대 250개 Pod 지원

•고급 기능 필요시 사용 (가상 노드, Azure 네트워크 정책 등)

•VNet 엔드포인트를 사용하여, 프라이빗으로 연결 가능

•IP 주소범위 고갈 문제

Azure CNI Network

 

 

Kubenet networking

•Node만 VNet의 IP 주소를 수신하고, 포드는 직접 통신 불가

•수동으로 UDR(사용자 정의 라우팅)유지 관리

•NAT를 사용하여 외부 다른 리소스와 통신

•Azure VNet의 리소스에 연결 가능하도록 NAT 사용

•클러스터당 최대 노드 수 400개

•각 노드 당 최대 250개 Pod 지원

Kubenet Network (Default)

 

Ingress traffic

AKS에서 인그레스 컨트롤러 방식은 크게 2가지로 구분할 수 있습니다.

AGIC를 사용하여 배포 하거나 AKS에서 컨트롤러를 직접 설치 배포 하는 방법이 있습니다. 대표적인 인그레스 컨트롤러로는 NGINX 컨트롤러가 있지만 AKS는 특정 컨트롤러로 제한하지 않습니다. Contour, HAProxy, Traefik 등을 사용할 수 있습니다. AGIC를 사용하면 AKS 클러스터 앞에 다른 부하 분산 장치/공용 IP가 필요하지 않으며 요청이 AKS 클러스터에 도달하기 전에 데이터 경로에서 여러 홉을 피할 수 있습니다. Application Gateway 개인 IP를 사용하여 Pod와 직접 대화하며 NodePort 또는 KubeProxy 서비스가 필요하지 않습니다. 또한 배포에 더 나은 성능을 제공합니다. AGIC 외에도 Application Gateway를 사용하면 TLS 정책 및 WAF(웹 애플리케이션 방화벽) 기능을 제공하여 AKS 클러스터를 보호할 수도 있습니다.

Ingress 동작 방식

 

Application Gateway Ingress Controller

AKS 클러스터당 하나의 AGIC 추가 기능만 배포

(AKS 클러스터에 도달하기 전에 데이터 경로에서 다중 홉을 방지)

 

Ingress controller

가장 일반적인 컨트롤러는 Nginx ( AKS는 특정 컨트롤러 제한 X)

(Window 서버 노드는 Ingress controller 사용 X )

 

 

Persistent Volume with Container Storage Interface

 

아래 2가지 그림은 AKS에서 PV에 사용할 수 있는 Volume에 대한 동작 방식을 보여주는 다이어그램입니다. 스토리지 동작은 크게 Managed disk와 Azure Files로 나뉘어 집니다. 각각의 특징은 Azure Managed disk, Ultra Disk는 단일 노드, 단일 파드에 access 되고, Azure Files, blob storage, NetApp Files는 여러 노드, 파드에서 Shared Storage로 사용이 가능합니다.

스토리지 2가지 동작 다이어그램

 

Managed Disk vs Azure Files

 

 

마무리

내용이 더 길어 질 것 같아 이후에 수정 작업을 거쳐 2편으로 다루어 볼까합니다.  다음에는 추가로 Azure Active Directory와, Kubernetes RBAC 통합 엑세스 제어와 Azure Monitor를 이용한 AKS 모니터링 그리고 AKS 도입시 점검 사항 등에 관한 내용을 다루어 볼 예정입니다.