[Kube] Kubernetes - 특징 및 아키텍처 (2)

---

본 게시글은 인프런 subicura 강사님의 초보를 위한 쿠버네티스 안내서 강의 수강 후 작성한 내용입니다.

---

개요

왜 쿠버네티스(Kubernetes)를 사용할까 ?

• 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼.
• 구글에서 최초 제작.
• 행성 스케일이다. 컨테이너를 20억개(구글이 사용하는 개수) 미만이면 사용 가능.
• 다양한 요구 조건을 만족시킬 수 있는 유연함.
• 어디서나 동작 가능한 호환성.

이 외에도 오픈소스, 엄청난 인기, 무한한 확장성, 사실상 표준(De facto)의 이유에서 쿠버네티스가 컨테이너 오케스트레이션으로 많이 사용된다.

 

쿠버네티스 특징

• 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리 (자동화)
• 컨테이너를 쉽게 관리하고 연결하기 위해 논리적인 단위로 그룹 (논리적인 단위)
• 구글에서 15년간 경험을 토대로 최상의 아이디어와 방법들을 결합 (노하우)
• 쿠버네티스에 기여하고 있는 기업들이 많다. (노하우)

쿠버네티스 이름 자체는 그리스어로 조타수 또는 조종사에서 따왔다. 줄여서 K8S이라고도 함, kube라고도 한다.

 

클라우드 등장 이후 수많은 리소스를 자유롭게 사용하고 추상적으로 관리하게 되었고, 수 많은 리소스를 효율적으로 관리하기 위해 쿠버네티스가 등장하였다.

---

구성 / 설계

 

쿠버네티스의 핵심은 Desired State(원하는 상태)을 유지하는 것.

 

1. 상태 체크(observe)

• 현재 상태(Current State) == 원하는 상태(Desired State)

 

2. 차이점 발견(Diff)

현재 상태(Current State) != 원하는 상태(Desired State)

 

3. 조치(Act)

• 현재 상태 → 원하는 상태로 조치
• 현재 상태(Current State) → 원하는 상태(Desired State)

 

1~3 절차를 반복하며 Desired State(원하는 상태)를 유지한다.

 

Desired State(원하는 상태)를 체크하고 실행하는 부분을 Master라고 하고 실제로 컨테이너가 실행되는 부분을 Node라고 한다.

 

Maste에서 여러 Controller들을 통제하는 곳을 API Server라고 하고 상태를 저장하고 조회하는 것을 etcd라고 한다.

 

주요 컨트롤러

• Replication Controller
• Endpoint Controller
• NameSpace Controller
• Custom Controller
• ML Controller
• CI/CD Controller

등등 특정 서비스의 상태(Desired State(원하는 상태)) 체크를 확인하는 컨트롤러가 존재한다.

 

 

쿠버네티스 Master

 

etcd

• 모든 상태와 데이터를 저장
• 분산 시스템으로 구성하여 안전성을 높임 (고가용성)
• 가볍고 빠르면서 정확하게 설계 (일관성)
• Key(directory) - value 형태로 데이터 저장
• TTL(Time To Live), watch 같은 부가 기능 제공
• 주기적인 백업이 필요하다.

API Server

• 상태를 바꾸거나 조회
• etcd와 유일하게 통신하는 모듈
• REST API 형태로 제공
• 권한을 체크하여 적절한 권한이 없을 경우 요청을 차단
• 관리자 요청 뿐 아니라 다양한 내부 모듈과 통신
• 수평으로 확장되도록 디자인

Scheduler

• 새로 생성된 Pod을 감지하고 실행할 노드를 선택
• 노드의 현재 상태와 Pod의 요구사항을 체크
  • 노드에 라벨을 부여

Controller

• 논리적으로 다양한 컨트롤러가 존재
  • 복제 컨트롤러
  • 노드 컨트롤러
  • 엔드포인트 컨트롤러
• 끊임 없이 상태를 체크하고 원하는 상태를 유지
• 복잡성을 낮추기 위해 하나의 프로세스로 실행

 

 

Node

 

kubelet

• 각 노드에서 실행
• Pod을 실행/중지하고 상태를 체크
• CRI (Container Runtime Interface)
  • docker
  • containerd
  • CRI-O

proxy

• 네트워크 프록시와 부하 분산 역할
• 성능상의 이유로 별도의 프록시 프로그램 대신 iptavles 또는 IPVS를 사용 (설정만 관리)

 

---

오브젝트

---

Pod

• 가장 작은 배포 단위. 컨테이너를 직접 관리하지 않고 pod으로 감싸서 관리함.
• 전체 클러스터에서 고유한 IP를 할당
• 여러개의 컨테이너가 하나의 pod에 속할 수 있음.

ReplicaSet

• 여러개의 Pod을 관리
• 새로운 Pod은 Template을 참고하여 생성
• 신규 Pod을 생성하거나 기존 Pod을 제거하여 원하는 수(Replicas)를 유지

Deployment

• 배포 버전을 관리
• 내부적으로 ReplicaSet을 이용

Service - ClusterIP

• 클러스터 내부에서 사용하는 프록시
• Pod은 동적이지만 서비스는 고유 IP를 가짐.
• 클러스터 내부에서 서비스 연결은 DNS를 이용

Service - NodePort

• 노드(host)에 노출되어 외부에서 접근 가능한 서비스
• 모든 노드에 동일한 포트로 생성

Service - LoadBalancer

• 하나의 IP주소를 외부에 노출

Ingress

• 도메인 또는 경로별 라우팅
  • Nginx, HAProxy, ALB … 를 재활용

그외 volume,namespace 등 많은 오브젝트들이 있다. (추상화가 많이 되어 있다.)

---

API 호출

Object Spec은 YAML 포맷으로 작성한다.

 

API 호출하기 = 원하는 상태(Desired state)를 다양한 오브젝트(object)로 정의(spec)하고 API 서버에 yaml 형식으로 전달한다.

 

구성 요소

• apiVersion
  • apps/v1, v1, batch/v1, networking.k8s.io/v1 …
• kind
  • Pod, Deployment, Service, Ingress …
• metadata
  • name, lavel, namespace …
• spec
  • 각종 설정
• status (read-only)
  • 시스템에서 관리하는 최신 상테

 

 

 

 

 

 

※ 본 게시글의 정보가 잘못 되었거나 부족한 부분에 대한 피드백을 환영합니다.

 

 

* CopyRight 2024. Jay Park All rights reserved.