쿠버네티스(Kubernetes, k8s) - 관리형(Managed) 와 자체 관리형(Self-Managed) - KUBERNETES와 클라우드네
쿠버네티스(Kubernetes, k8s) - 관리형(Managed) 와 자체 관리형(Self-Managed), KUBERNETES와 클라우드네이티브
클라우드 네이티브 플랫폼, Kubernetss 기술 용어정리 Kubernetes를 구축하는 방법, 쿠버네티스 클라우드 서비스의 종류
쿠버네티스의 구성 요소
쿠버네티스(Kubernetes, k8s) 개념
쿠버네티스 (k8s, Kubernetes, 큐브, kube)는 컨테이너화된 애플리케이션을 배포, 관리, 확장할 때 수반되는 다수의 수동 프로세스를 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼입니다.
쿠버네티스 클러스터는 온프레미스, 퍼블릭, 프라이빗 또는 하이브리드 클라우드로 호스트를 확장할 수 있습니다.
Linux 컨테이너를 실행하는 호스트 그룹을 함께 클러스터링할 수 있으며 쿠버네티스를 통해 이러한 클러스터를 쉽고 효율적으로 관리할 수 있습니다.
신속한 확장을 요하는 클라우드 네이티브 애플리케이션(CNCF, Cloud Native Computing Foundation)을 구축하는데 이상적인 플랫폼입니다.
쿠버네티스 활용의 장점
사용자의 환경에서 쿠버네티스를 사용할 경우 얻을 수 있는 주요 장점은, 클라우드에서 애플리케이션 개발을 최적화하는 경우 쿠버네티스를 통해 물리 또는 가상 머신(VM)의 클러스터들을 통합 관리할 수 있습니다.
쿠버네티스를 사용하여 수행할 수 있는 작업은 다음과 같습니다.
- 여러 호스트 전반에서 컨테이너를 오케스트레이션합니다.
- 하드웨어 자원과 애플리케이션을 실행하는 데 필요한 리소스 이용을 극대화합니다.
- 애플리케이션 배포 및 업데이트를 제어하고 자동화합니다.
- 스토리지를 마운트 및 추가하여 스테이트풀(stateful) 애플리케이션을 실행합니다.
- 컨테이너화된 애플리케이션과 해당 리소스를 즉시 확장 가능 합니다.
- 서비스를 관리와 배포한 애플리케이션이 관리를 같이 실행합니다.
- 자동 배치, 자동 재시작, 자동 복제, 자동 스케일링등으로 애플리케이션 상태를 점검하고 자가 치유(Self-healing)할 수 있습니다.
Kubernetes를 구축하는 방법 3가지
- 자체서버 환경에서 쿠버네티스 설치
- 클라우드 서버 인프라 위에 쿠버네티스 설치
- 클라우드 플랫폼의 Managed 쿠버네티스 사용 AKS(Azure), EKS(AWS), GKE(GCP)등
| 자체 환경 구축 (Self-Managed) | 클라우드에서 지원할 수 없는 기능이 필요하다면 자체 구축을 하는 것을 고려 모든 관리를 직접 해야 하므로 운영, 관리가 복잡함 |
| 클라우드 인프라에 자체 관리형 구축 (Less-Managed) | 클라우드의 인프라(VM, Network 등) 를 활용하여 설치하고 CSP를 통해 인프라 관리 쿠버네티스의 설치와 설정을 직접 하기 때문에 Managed 쿠버네티스 보다 자유로운 설정이 가능 클러스터 구성과 노드 관리를 직접 해야 하므로 관리가 어려움 |
| 클라우드 플랫폼에 관리형 구축 (Managed) | 설치를 할 필요가 없으며, 인프라와 쿠버네티스를 CSP에서 관리하는 서비스 이용 쉽게 사용이 가능하고, 각 클라우드 플랫폼의 종속적인 자체 기능도 활용 가능 |
클라우드 플랫폼 제공 업체 - CSP(Cloud service provider)
- Amazon AWS
- MS Azure
- Google GCP
쿠버네티스 클라우드 서비스의 종류 (EKS/AKS/GKE)
- AWS의 EKS(Elastic Kubernetes Service)
- Azure의 AKS(Azure Kubernetes Service)
- GCP의 GKE(Google Kubernetes Engine)
Self Managed 자체 관리형 쿠버네티스 vs Fully Managed 관리형 애플리케이션 플랫폼
클라우드 애플리케이션 개발과 운영을 제공하는 데에는 두 가지 개념이 있는데, 바로 자체 관리형 쿠버네티스와 관리형 컨테이너 플랫폼입니다.
자체 관리형은 최대한의 제어, 유연성, 사용자 정의 가능한 환경을 설치, 운영, 관리할 수 있습니다. 자체 관리형 쿠버네티스 클러스터의 관리 계층을 제어할 수 있습니다.
관리형 컨테이너 플랫폼은 쿠버네티스 클러스터에 필요한 기본 지원 및 관리 기능을 제공합니다. 그러나 관리형 컨테이너 플랫폼은 컨트롤 플레인, 간단한 배포 옵션 및 지속적인 플랫폼 유지 관리를 제공합니다.
| 구분 | 장점 | 단점 |
| 관리형 Managed Kubernetes | - TCO 절감 - 개발 속도 증가 - 보안 모범 사례 활용 - 클라우드 제공업체의 전문성을 계승하세요 - 유지관리 부담 감소 | - 규정 준수 요구 사항을 충족하도록 완전히 사용자 정의 가능 - 최신 기능을 사용할 수 있음 - 유연한 배포 방식 |
| 자체 관리형 Self-Managed Kubernetes | - 자체 기술 인력으로 다양한 제품을 활용 가능 - 규정 준수가 필수적인 환경 | - 상당한 Kubernetes 지식과 전문 지식이 필요 - 유지관리 부담이 클 수 있음 (TCO) |
대표적인 Managed 클라우드 플랫폼
Redhat OpenShift Service on AWS (ROSA)
Red Hat OpenShift Service on AWS(ROSA)는 Amazon Web Services(AWS)에서 기본적으로 실행되는 관리형 쿠버네티스 기반의 애플리케이션 플랫폼입니다. ROSA를 통해 조직은 운영 효율성을 높이고, 혁신에 집중하고, 애플리케이션을 신속하게 구축, 배포, 확장할 수 있습니다.
Amazon EKS(Amazon Elastic Kubernetes Service)
Amazon EKS(Amazon Elastic Kubernetes Service)는 컨테이너 스케줄링, 애플리케이션 가용성 관리, AWS 클라우드 및 온프레미스 데이터 센터의 클러스터 데이터 저장을 담당하는 쿠버네티스 컨트롤 플레인 노드의 가용성과 확장성을 관리하는 관리형 쿠버네티스 서비스입니다.
쿠버네티스의 구성 요소
쿠버네티스 클러스터는 컨트롤 플레인과 컴퓨팅 머신(또는 노드)으로 구분 됩니다.
컨트롤 플레인은 어느 애플리케이션을 실행하고 애플리케이션이 어느 컨테이너 이미지를 사용할지와 같이 클러스터를 원하는 상태로 유지 관리합니다. 컴퓨팅 머신은 애플리케이션과 워크로드를 실제로 실행합니다.
각 노드는 자체 Linux 환경으로 물리 또는 가상 머신일 수 있습니다. 각 노드는 컨테이너로 이루어진 포드(Pod)를 실행합니다.
kube-apiserver
쿠버네티스 API는 쿠버네티스 컨트롤 플레인의 프론트엔드로, 내부 및 외부 요청을 처리합니다.
kubectl 커맨드라인 인터페이스 또는 kubeadm과 같은 기타 CLI(command-line interface)를 API를 통해 액세스합니다.
kube-scheduler
클러스터가 양호한 상태인가? 새 컨테이너가 필요하다면 어디에 적합한가? 쿠버네티스 스케줄러는 이러한 것들을 주로 다룹니다.
스케줄러는 CPU 또는 메모리와 같은 포드의 리소스 요구 사항과 함께 클러스터의 상태를 고려합니다. 그런 다음 포드를 적절한 컴퓨팅 노드에 예약합니다.
kube-controller-manager
쿠버네티스 controller-manager에는 컨트롤러는 실제로 클러스터를 실행하고 여러 컨트롤러 기능이 하나로 통합되어 있습니다. 하나의 컨트롤러는 스케줄러를 참고하여 정확한 수의 포드가 실행되도록 합니다. 포드에 문제가 생기면 또 다른 컨트롤러가 이를 감지합니다.
etcd
설정 데이터와 클러스터의 상태에 관한 정보는 키-값 저장소 데이터베이스인 etcd에 저장합니다. 내결함성을 갖춘 분산형 etcd는 클러스터에 관한 정보 소스(Source Of Truth, SOT)가 되도록 설계되었습니다.
쿠버네티스 노드 개념과 특징
노드 (Node)
쿠버네티스 클러스터에는 최소 1개 이상의 컴퓨팅 노드가 필요하지만 일반적으로 여러 개가 있습니다. 포드는 노드에서 실행하도록 예약되고 오케스트레이션됩니다. 클러스터의 용량을 확장해야 한다면 노드를 더 추가하면 됩니다.
포드 (Pod)
포드는 단일 노드에 배포된 하나 이상의 컨테이너 그룹입니다. 쿠버네티스 오브젝트 모델에서 가장 작고 단순한 유닛으로, 애플리케이션의 단일 인스턴스를 나타냅니다. 포드에 있는 모든 컨테이너는 IP 주소, IPC, 호스트 이름, 기타 리소스를 공유하고 실행 방식을 제어하는 옵션을 통해서 기본 컨테이너에서 네트워크와 스토리지를 추상화합니다. 또 하나 이상의 Pod를 결합한 컨테이너로 구성할 수 있습니다.
컨테이너 런타임 엔진
컨테이너 실행을 위해 각 컴퓨팅 노드에는 컨테이너 런타임 엔진이 있습니다. 그중 한 가지 예가 Docker입니다. 하지만 쿠버네티스는 rkt, CRI-O와 같은 다른 Open Container Initiative 호환 런타임도 지원합니다.
kubelet
각 컴퓨팅 노드에는 컨트롤 플레인과 통신하는 매우 작은 애플리케이션인 kubelet이 있습니다. kublet은 컨테이너가 포드에서 실행되게 합니다. 컨트롤 플레인에서 노드에 작업을 요청하는 경우 kubelet이 이 작업을 실행합니다.
kube-proxy
각 컴퓨팅 노드에는 쿠버네티스 네트워킹 서비스를 용이하게 하기 위한 네트워크 프록시인 kube-proxy도 있습니다. kube-proxy는 운영 체제의 패킷 필터링 계층에 의존하거나 트래픽 자체를 전달하여 클러스터 내부 또는 외부의 네트워크 통신을 처리합니다.
쿠버네티스 클러스터에 필요한 인프라 요소
기본 인프라
쿠버네티스을 탑재할 인프라 로서 베어 메탈 서버, 가상 머신, 퍼블릭 클라우드 제공업체, 프라이빗 클라우드, 하이브리드 클라우드 환경 등을 이용합니다. 쿠버네티스의 주요 이점 중 하나는 다양한 종류의 인프라에서 작동한다는 것입니다.
퍼시스턴트 스토리지
쿠버네티스는 애플리케이션을 실행하는 컨테이너를 관리할 뿐만 아니라 클러스터에 연결된 애플리케이션 데이터도 관리할 수 있습니다. 쿠버네티스를 사용하면 사용자가 기본 스토리지 인프라에 관한 상세 정보를 알지 못해도 스토리지 리소스를 요청할 수 있습니다.
컨테이너 레지스트리
쿠버네티스의 컨테이너 이미지는 컨테이너 레지스트리에 저장됩니다. 이러한 레지스트리를 직접 구성하거나 외부에 구성할 수 있습니다.
클라우드 Kubernetes와 IT기술 생태계의 변화
클라우드 환경의 도입은 점차 가속화를 거듭하여 발전되고 있습니다. 그 동안 인터넷 1세대부터 IT인프라의 확장이 가장 큰 관심사였지만 이제는 네트웍 및 시스템 인프라는 서비스 생산의 도구로 인식되고 있습니다. 따라서 새로운 비즈니스를 만들기 위해 신속하고 민첩하며 효율적인 인프라를 요구하고 있습니다.
이러한 상황에서 IT전반적으로 사람, 인프라, 기술 등 생태계적 전반적으로 변화가 되었습니다.
인프라 환경은 System 서버, 스토리지, 네트웍을 자체적으로 관리하기보다 외주를 활용하며 운영을 병행하면서 배운 숙련된 기술 인력은 지속적으로 줄어 들었습니다. 특히나 이러한 인프라 에 대한 기술을 교육하는 기관도 거의 사라졌고, 다양한 기술을 배우기에는 너무나 많은 시간이 걸리기 때문에 회사에서도 초급자를 육성해서 관리하는 부분도 불가능합니다.
이제는 클라우드 플랫폼이 작은 벤처 및 새로운 서비스를 키워가는 기술 업체들에게는 필수적인 환경으로 자리를 잡았습니다.
또한 블록체인 인공지능, 빅데이터 등과 같이 방대한 데이터 들이 내부. 외부간 유통되는 환경에서는 자체적인 인프라 보다는 클라우드 환경이 더 효과적일 수 밖에 없습니다.
향후 IT 서비스들은 최근 ChatGPT와 같이 API와 다양한 서비스 채널간의 융합된 서비스 결합으로 발전이 가속화 되면서 서비스의 유기적인 결합이 더 큰 시장으로 자리를 잡을 것으로 예상 됩니다. ~~~ 구독 감사합니다. ~~
