Kubernetes(Orchestration) 개론

오늘날, IT서비스를 구성할때, Kubernetes와 같은 Orchestration 환경을 기본으로 시작하게 됩니다.
여기서는, 이런 배경을 알아보고자 합니다.

Kubernetes의 성장 배경

Kubernetes가 오늘날 처럼 인프라 운영의 핵심으로 자리 잡기 까지, 여러 배경이 있습니다.

• 더 빨라진 비지니스 변화 → 잦은 배포가 발생합니다.
• 확장성(scalability)이 더 중요해진 업계의 변화.

Monolithic → MSA(Micro Service Architecture)로의 아키텍쳐 변화

‘잦은 배포’가 ‘시스템 전체에 영향을 미치는 경우’를 피하고, Scale의 단위를 전략적으로 선택할 필요성
이 생기면서, MSA가 시스템 Architecture의 중심이 되었습니다.

그러나, MSA는 아래와 같은 어려움이 있습니다.

각 서비스 마다, 개발, 빌드, 운영 환경을 일치시켜야 하는 문제가 있습니다.

분리된 각 서비스를 통합하여 관리하기가 어렵습니다. 예를 들면, 모니터링(Log, System Metric)하기가 어렵습니다.(각각의 서비스에 별도로 접속해야 해서 확인해야 하는 환경)

Docker(Container 기술)의 탄생

Docker가 탄생하면서, MSA환경의 어려운 점들을 해결해 줬습니다.

Docker의 Architecture

VM의 Architecture

VM은 별도의 OS와 Kernel를 가지고 있어, Layer추가로 인해 컴퓨팅 비용 손실이 많습니다. 반면에, Container는 Host의 OS와 Kernel을 공유하여, 컴퓨팅 비용 손실을 최소화 하였고, Container를 경량화 하였습니다.

Public Cloud의 발전

기존의 서버는 임대 계약을 하고, 물리 장치(하드웨어)를 할당 받아야 합니다.
Public Cloud(AWS, GCP, Azure..)가 등장하면서, 서버 자원을 더 빠르게 확장하고, 사용한 만큼 비용을 지불할 수 있게 되면서, Scaling에 대한 장벽이 낮아지게 되었습니다.

Orchestration(Kubernetes)기술의 등장

Container(Docker와 같은) 기술이 MSA와 결합하면서, 어려웠던 ‘관리의 문제’를 해결해줄 ‘Orchestration System’이 만들어지게 되었습니다.
그 대표격인 Kubernetes는, 처음에는 Google 내부에서 사용하던 System이었습니다.

Q: 왜 Orchestration이라 부르나요?
A: 시스템을 구성하는 여러 서비스 사이에서 ‘조율(orchestrate)’을 하는 기술이라고 해서, ‘Orchestration’이라고 부릅니다.

Cloud Native와 Kubernetes

Cloud Native는 애플리케이션을 클라우드 환경에서 최적화하여 개발·운영하는 방식을 지칭합니다.
전통적인 모놀리식(monolithic) 애플리케이션과 달리, Cloud Native 애플리케이션은 마이크로서비스(MSA), 컨테이너, 동적 오케스트레이션, 선언적 선언(declarative) 방식을 활용하여 유연성과 확장성, 복원력(resilience)을 확보합니다.
이러한 패러다임은 클라우드 인프라(퍼블릭·프라이빗·하이브리드)에 구애받지 않고, 자동화와 관찰성(observability)을 기반으로 빠른 배포·변경이 가능하도록 돕습니다.

CNCF(Cloud Native Computing Foundation)

CNCF는 이러한 Cloud Native 패러다임을 정의·보급하고, 관련 오픈소스 생태계를 조성하기 위해 설립된 조직입니다.
Kubernetes, Prometheus, Envoy, Fluentd 등 다양한 프로젝트를 호스팅하며, 벤더 중립적인 환경에서 Cloud Native 기술 표준과 모범 사례를 확산합니다.

CNCF를 졸업(Graduated)한 프로젝트들

Cloud Native와 Kubernetes의 관계

• Kubernetes는 Cloud Native 패러다임을 구현하기 위한 핵심 기술입니다.
• CNCF의 Seed 프로젝트 였습니다.

Kubernetes 구성

지휘자(Orchestrator) 역할을 하는 ‘Control Plane’과 구성원 역할을 하는 ‘Data Plane’으로 나뉩니다.

Kubernetes cluster components. (from https://kubernetes.io/docs/concepts/architecture/)

Control Plane

• etcd
  Kubernetes의 현재상태와 Desire State등을 저장하는 key-value Storage서비스 입니다.
  Cluster의 핵심적인 역할을 하기 때문에, HA(High-availability)를 위한 장치들이 되어 있습니다.

• kube-api-server
  Kubernetes를 control하는 API를 제공하며, Cluster 규모에 따라 scale-out이 가능한 구조로 되어 있습니다.

• kube-scheduler
  Pod(Cluster안에서 다루는 최소 단위, Container의 집합)을 Data Plane에 할당하고 관리하는 역할을 합니다.
  ‘kube-api-server’를 통해, ‘명령’을 입력 받으면, ‘kube-scheduler’를 통해 실제 Pod에 대한 control이 이루어 집니다.

Data Plane

실제 서비스가 위치하는, Node(Host Machine. ex: AWS EC2, VM, Bare metal…)로 구성되어 있습니다.
각 Node안에는, Control Plane과 통신하는 서비스가 구동되게 됩니다.

• kubelet
  ‘Control Plane’의 ‘kube-api-server’의 명령을 받아서, 각 Node에서 실제로 명령을 실행하는 역할을 합니다.

• kube-proxy
  Kubernetes로 들어오는 network packet들을 핸들링합니다. 주로, Node내의 Routing정책(iptable을 통해)을 관리하며, 이를 통해 Node내 Packet의 이동을 관장합니다.

Kubernetes의 핵심 철학, Desired State

Desired State는 사용자가 Kubernetes에 정의한 ‘궁극적으로 도달해야하는 애플리케이션의 상태’를 의미합니다.
Kubernetes는 ‘Desired State’와 ‘Actual State(현재 상태)’를 지속적으로 비교하고, 두 State(상태)가 일치하도록 조정하게 됩니다.

AWS EKS와 AWS ECS

AWS EKS

‘Control Plane’이 AWS 자체에서 운영하는 VPC에서 관리됩니다.

이 때문에, Control Plane 관리에 대한 추가 비용이 부과되며, old version인 경우 추가 비용을 부담해야 합니다.

Kubernetes와 호환성이 있습니다.(Vanilla Kubernetes기반)

즉, CNCF에 포함된 모든 서비스들을 바로 적용할 수 있습니다

AWS EKS Cluster의 Architecture

AWS ECS

AWS에서 자체 개발하고 제공하는 Orchestration 서비스입니다.
‘Control Plane’으로 인한 별도의 비용이 발생하지 않습니다.

References

A Brief History of the Cloud

events.static.linuxfound.org

Docker와 VM의 차이

Docker 및 VM 비교 - 애플리케이션 배포 기술 간의 차이 - AWS

Top Questions for Getting Started with Docker

Top Questions for Getting Started with Docker | Docker

What is Kernel?

리눅스 커널(Linux kernel)이란 - 개념, 구성요소, 인터페이스

CNCF Charter

CNCF Charter

CNCF Landscape

CNCF의 오픈소스 프로젝트를 볼 수 있는 페이지 입니다.

CNCF Landscape

Kubernetes Concepts

Overview

Kubernetes Cluster Architecture

Cluster Architecture

EKS Blueprints

Bootstrapping clusters with EKS Blueprints | Amazon Web Services