애플리케이션 실행 환경의 변화

On-premise → Virtual Machine → Container

* 온프레미스 : 내부 로컬 시스템

1. 전통적인 배포 : 애플리케이션 물리 서버에서 실행
   ✔ 리소스 할당의 문제

2. 가상화된 배포 : 단일 물리 서버의 CPU에서 여러 가상 시스템(VM)을 실행
   ✔ VM 간에 애플리케이션 격리 → 일정 수준의 보안성 제공

3. 컨테이너 개발 : VM과 유사하지만 격리 속성을 완화 → 애플리케이션 간에 운영체제(OS) 공유

클라우드 네이티브

클라우드의 장점을 최대한 활용할 수 있도록 애플리케이션을 개발, 구축, 실행하는 방식

• 데브옵스(DevOps) - 클라우드 네이티브 애플리케이션의 방법론
• 마이크로 서비스 - 운영 구조
• 컨테이너 - 운영 인프라
• 지속적인 통합/배포(CI/CD) - 자동화 프로세스

데브옵스(DevOps)모델

소프트웨어 개발과 IT 운영을 결합한 합성어

그놈의 애자일

가상화 (Virtualization)

가상화를 관리하는 소프트웨어를 사용하여 하나의 물리적 머신에서 가상 머신(VM)을 만드는 프로세스

컨테이너

컨테이너의 한계

• 배포의 문제
• 서비스 검색의 문제
• 서비스 노출의 문제
• 서비스 장애, 부하 모니터링의 문제

컨테이너의 한계를 뛰어넘고자 쿠버네티스라는 기술이 나왔다?

컨테이너 오케스트레이션

오케스트레이션 👉 "컴퓨터 자원과 어플리케이션, 서비스에 대한 자동화된 설정, 관리 및 제어 체계"

온라인 인프라 화경에서 대규모의 컨테이너들이 안정적으로 운영될 수 있도록 관리의 복잡함성을 줄여주고 자동화하는 것

✔ 한 곳에서 관리할 수 있게 해주는 것
👉 쿠버네티스 - 도커들의 상태를 관리해주는 오케스트레이션이다

✔ 컨테이너들을 관리하는 메인 컨트롤러가 있고, 이에 맞춰 컨테이너 배포, 관리, 확장, 네트워킹을 자동화

⚓ 쿠버네티스

컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼

K8s라고 씁니다~ (K와 s 그 사이의 8글자)

기능

• 서비스 디스커버리와 로드 밸런싱

• 스토리지 오케스트레이션

• 자동화된 롤아웃과 롤백

• 자동화된 빈 패킹
  👉 각 컨테이너가 필요로 하는 CPU와 메모리를 쿠버네티스에 지시하면, 쿠버네티스는 컨테이너를 패킹

• 시크릿과 구성 관리

• 자가 치유

• 배치 실행

• 오토 스케일링

암튼 쩔죠?

이전에 사람이 하던 걸 시스템이 자동화!!!

왜 쿠버네티스를 써야할까?!
👉 분산 시스템을 탄력적으로 실행하기 위한 프레임워크를 제공하기 때문에 애플리케이션 확장, 장애조치를 처리하고 배포 패턴을 제공하기 때문에 일단 편하다

선언적 구성 기반의 배포 환경

쿠버네티스에서는 동작을 지시하는 개념보다 원하는 상태를 선언하는 개념이다 이게 뭔데요

✔ 원하는 상태와 현재의 상태가 상호 일치하는지를 지속적으로 체크하고 업데이트

원하는 상태(Desired State)를 유지하는 것이 핵심이다

👉 원하는 환경 = 관리자가 원하는 환경

제어 루프(Control Loop)

1. Observe
2. Check Differences
3. Take Action

1, 2, 3 반복

기능 단위의 분산

각각의 기능들이 개별적인 구성요소로 독립적으로 분산

✔ 노드, 레플리카셋, 디플로이먼트, 네임스페이스 등 클러스터를 구성하는 주요 요소들이 모두 컨트롤러로서 구성되어 있다
✔ 주요 요소는 Kube Controller Manager 안에 패키징

클러스터 단위 중앙 제어

전체 리소스를 클러스터 단위로 추상화하여 관리

✔ 클러스터의 구성 요소들에 대해 제어 권한을 가진 컨트롤 플레인(Control Plane) 역할의 마스터 노드(Master Node)를 구성 → 마스터 노드가 클러스터 전체를 제어

동적 그룹화

구성 요소들에는 쿼리 가능한 레이블과 메타데이터용 어노테이션에 임의로 키-값 쌍을 추가할 수 있다

API 기반 상호작용

Kubernetes API Server를 통해서만 상호 접근이 가능한 구조

✔ kuberctl을 거쳐 실행되는 모든 명령은 모두 이 API 서버를 거쳐서 수행된다

쿠버네티스 주요 구성 요소

• 클러스터
• 컨트롤 플레인
• Kubelet
• 포드

컨트롤 플레인

컨테이너가 필요한 리소스를 갖고 충분한 횟수로 실행되도록 하는 중요한 작업을 수행

ETCD

Kube-apiserver

쿠버네티스 컨트롤 플레인의 프론트엔드, 내부 및 외부 요청을 처리
모든 요청이 kube-apiserver를 통해서 다른 곳으로 전달된다

ETCD

설정 데이터와 클러스터의 상태에 관한 정보가 저장되는 곳
👉 키-값 저장소 데이터베이스

쿠버네티스 오브젝트 모델

마스터와 노드 두 개의 컴포넌트로 분리된다

👉 쿠버네티스 마스터

• 시스템을 제어하고 관리하는 쿠버네티스 컨트롤 플레인을 실행

👉 쿠버네티스 노드

• 실제 배포되는 컨테이너 애플리케이션을 실행 (워크로드 호스팅)

🌟 쿠버네티스 기본 오브젝트
Pod - 컨테이너화된 애플리케이션
Service - 로드 밸런서
Volume - 디스크
Namespace - 패키지명

Pod

쿠버네티스는 하나의 컨테이너를 개별적으로 배포하는 것이 아니라 Pod 단위로 배포한다

• 1 Pod 1 Container
• Pod 내의 컨테이너들은 IP, Port 공유
• Pod 내에 배포된 컨테이너 간에는 디스크 볼륨 공유 가능

Volume

Pod에 마운트 된 디스크는 Volume Type에 따라 사용 유형이 정의된다

👉 Volume Type

• 임시 볼륨
• 로컬 볼륨
• 네트워크 볼륨
• 네트워크 볼륨 (Cloud dependent)

Service

Label Selector로 Pod를 선택하여 하나의 Endpoint로 노출하는 방식

• Selector를 사용하여 Pod를 논리적 그룹으로 나눌 수 있다
• Service는 각 Pod에 Load Balancing을 자동적으로 수행한다
• 서비스를 정의할 때, 어떤 Pod들을 Service로 묶을 것인지 정의함 → Label Selector

Namespace

쿠버네티스 클러스터 내의 논리적인 분리 단위

• Namespace를 활용하여 팀이나 프로젝트 단위로 클러스터 파티션을 나눌 수 있다

ReplicaSet (rs)

오... 이건 뭐임... 어렵다...

---

느낀점

나... 잘 할 수 있을까...? 공부를 많이 해야할 것 같다...

---

본 포스팅은 글로벌소프트웨어캠퍼스와 교보DTS가 함께 진행하는 챌린지입니다.