2.1. 쿠버네티스란?

쿠버네티스는 여러 서버로 구성된 클러스터 환경에서 컨테이너화된 프로세스를 관리하기 위한 컨테이너 오케스트레이션 플랫폼

컨테이너 오케스트레이션

  • 컨테이너를 여러 서버에 걸쳐 여러 개를 실행시키는 데 체계적으로 관리하는 기술

쿠버네티스를 통해

  • 컨테이너 배포
  • 확장
  • 스케줄링 자동화

2.1.1. 컨테이너 오케스트레이션이란?

다수의 서버 위에서 컨테이너의 전반적인 라이프사이클을 관리해주는 플랫폼

쿠버네티스를 컨테이너 오케스트레이션을 해주는 하나의 툴 일뿐임

쿠버네티스는 컨테이너의 아래 역할들을 함

  • 실행 및 배포
  • 이중화와 가용성 보장
  • 수평확장 및 축소
  • 스케줄링
  • 네트워크 설정
  • health 상태 모니터링
  • 설정값 관리

2.1.2. 데이터 센터 운영체제

쿠버네티스가 여러 컴퓨터의 집합으로 이루어진 하나의 거대한 시스템을 추상적으로 제어할 수 있기 때문에 데이터 센터의 운영체제와 하는일이 비슷함.

2.2. 쿠버네티스의 기본 개념

쿠버네티스를 제어하기 위한 kubectl CLI를 제공함.

2.2.1. 애완동물 vs 가축

쿠버네티스는 서버를 애완동물 보다는 가축에 가깝다고 비유함.

  • 애완동물
    • 세심한 관리 필요
    • 정해진 이름
  • 가축
    • 방목
    • 이름 없음
  1. 서버마다 이름을 부여하지 않음-> 워커 서버로 동일함
  2. -> 특별한 역할이 정해져 있지 않다는 반증
  3. 한두개 망가져도 ㄱㅊ
  4. -> 다른 서버가 그 역할 하면 됨

2.2.2. 바라는 상태 (Desired State)

에어컨과 비슷함. (온도를 설정 해 둠)

사용자가 원하는 상태를 알려주면 쿠버네티스가 현재 상태를 바라는 상태로 변경함

-> 문제가 생기더라도 바라는 상태가 바뀌는 건 아니여서 복구가 가능함.

2.2.3. 컨트롤러(Controller)

  1. 사용자가 바라는 상태를 선언
  2. 쿠버네티스가 상태로 변경함

이 역할을 하는 게 Controller

컨트롤러는 control-loop를 돌며 특정 리소스를 지속적으로 모니터링하다가, 수행할 일이 있다면 작업을 수행함

2.2.4. 쿠버네티스 리소스(Resource)

쿠버네티스는 모든 것이 리소스로 표현됨

Pod, ReplicaSet, Deployment 등 다양한 리소스가 존재하고 각각의 역할이 있음

가장 기본 리소스는 Pod

Pod

  • 쿠버네티스의 최소 실행 단뒤
  • 하나 이상의 컨테이너 가짐
  • 프로세스를 실행한다는 의미와 동일

2.2.5. 선언형 커맨드(Declarative Command)

사용자가 직접 시스템의 상태를 바꾸지 않고 사용자가 바라는 상태를 선언적으로 기술

<-> 명령형 커맨드

쿠버네티스는 YAML 형식을 이용해 선언형 명령을 내림

pod의 예시

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: nginx
      image: nginx

최소한의 필수값을 채워서 리소스를 생성하면 나머지는 기본값으로 리소스가 생성됨

2.2.6. 네임스페이스(Namespace)

클러스터를 논리적으로 분리하는 개념

네임스페이스

  • 서로 다른 권한 설정을 할 수 있음
  • 네트워크 정책 설정 가능

리소스

  • 네임스페이스 레벨 리소스
  • 클러스터 레벨 리소스

네임스페이스 리소스

  • 특정 네임스페이스안에 속함
  • Pod, Deplyoment, Service

-> 대부분의 리소스

클러스터 레벨 리소스

  • Node
  • PersistentVolume
  • StorageClass

2.2.7. 라벨 & 셀렉터 (Label & Selector)

쿠버네티스의 리소스 질의 체계

특정 리소스에 명령을 전달하거나 정보를 확인하고 싶을 때 라벨링 시스템을 이용함.

  • 리소스에 key-value 형식의 태그정보를 붙임.

태깅한 리소스를 찾기 위해 셀렉터라는 것을 이용하여 특정 key-value를 가진 리소스만 추출함.

리소스간의 관계가 느슨하게 연결되어 유연한 구조를 가짐. 라벨 & 셀렉터 메커니즘

2.2.8. 서비스 탐색

쿠버네티스 클러스터내에서 통신하기 위해 노드 위치와는 상관없이 어디서든 접근할 수 있는 엔드포인트가 필요함. 사용자는 서비스 끝점을 통해 다른 컨테이너와 통신할 수 있다.

쿠버네티스는 DNS 기반의 서비스 탐색을 지원함.

  • Service라는 리소스를 통해 지원함.

2.2.9. 설정 관리

컨테이너를 실행할 때 필요한 설정값 및 민감 정보를 플랫폼 레벨에서 관리할 수 있게 제공함.

  • ConfigMap
  • Secret

2.2. 쿠버네티스 기본 개념

2.3. 아키텍처

마스터와 워커 노드로 구분됨

https://kubernetes.io/docs/concepts/overview/components/

2.3.1. 마스터

마스터에는 쿠버네티스 클러스터를 구성하는 핵심 컴포넌트들이 존재함.

  • kube-apiserver: 마스터로 전달되는 모든 요청을 받아 드리는 REST API 서버
  • etcd: 클러스터내 모든 메타 정보를 저장하는 저장소
  • kube-scheduler: 사용자의 요청에 따라 적절하게 컨테이너를 워커 노드에 배치하는 스케줄러
  • kube-controller-manger: 현재 상태와 바라는 상태를 지속적으로 확인하며 특정 이벤트에 따라 특정 동작을 수행하는 컨트롤러
  • cloud-controller-manger: 클라우드 플랫폼(AWS, GCP, Azure)등에 특화된 리소스를 제어하는 클라우드 클러스터

마스터

  • 단일 서버 or
  • 고 가용성을 위해 여러 서버를 묶어 클러스터 마스터로 구축

kube-apiserver(API 서버)

api 서버는 쿠버네티스의 핵심 역할을 담당

  • 다른 모든 컴포넌트에서 오는 이벤트 받아드림
  • → 적절히 응답
  • 모든 컴포넌트가 서로 통신함.
  • 다른 컴포넌트에 요청을 보내기도 함.
  • 사용자도 kubectl로 api 서버에 명령을 내리고 응답받음
  • =~ 마스터와 통신한다.

etcd(저장소)

클러스터에 필요한 모든 데이터를 저장하는 DB 역할

  • 분산형 key-value 저장소
  • api 서버 백엔드에 위치
  • 고가용성을 위해 etcd 클러스터 구축하기도 함.

kube-scheduler(컨테이너 스케줄러)

적절한 서버를 선택하여 컨테이너를 배치하는 역할

  • 컨테이너 스케줄링 수행

kube-controller-manager(컨트롤러 집합)

control 루프를 돌며 현재 상태와 바라는 상태를 비교함. → 달라지면 현재 상태로 바꿈

  • 전반적인 리소스의 라이프사이클 관리

cloud-controller-manager(클라우드 컨트롤러)

클라우드 리소스를 제어할 수 있음

2.3.2. 노드

노드 관리자

  • 워커 노드에는 마스터로부터 명령을 받아 컨테이너를 실행시킴

네트워크 프록시

  • 컨테이너가 정상적으로 실행될 수 있도록 하는
  • kubelet: 마스터의 명령에 따라 컨테이너의 라이프사이클을 관리하는 노드 관리자.
  • kube-proxy: 컨테이너의 네트워킹을 책임지는 프록시
  • container runtime: 실제 컨테이너를 실행하는 컨테이너 실행 환경

kubelet:

각 노드에서 실행되는 메인 컴포넌트,

  • 마스터로부터 특정 컨테이너 실행
  • 컨테이너가 잘 동작하는 지 모니터링
  • 주기적으로 api 서버와 통신

kube-proxy:

쿠버네티스 서비스 네트워킹을 담당하는 컴포넌트

  • 각 노드에 위치
  • 서비스마다 개별 IP를 가질 수 있게 만들어줌
  • 클러스터 내/외부의 트레픽을 Pod로 전달할 수 있도록 패킷을 라우팅

container runtime(컨테이넛 실행환경)

실제 컨테이너를 실행시키는 역할

  • ex) 도커
  • CRI 규약을 따르는 어떠한 런타임

2.4. 장점

2.4.1. 실행 환경 고립화

개별 실행환경을 고민할 필요 없이 프로세스를 어디서나 실행시킬 수 있음.

2.4.2. 리소스 관리

여러 서버를 통합해서 관리하게 해주는 클러스터 시스템,

서버별 리소스 사용량 모니터링, 리소스 사용량 제한 등 클러스터 시스템의 전반적인 리소스를 관리할 수 있음.

2.4.3. 스케줄링

서버의 개수가 많아지면 리소스 관리뿐 아니라, 프로세스의 스케줄링 또한 관리하기 힘들어짐

내장 스케줄러가 최적의 노드를 찾아 컨테이너를 배치해줌 (kube-scheduler)

떄론 사용자가 원하는 노드에 컨테이너 할당할 수 있게 함.

2.4.4. 프로세스 관리

서버 별로 실행중인 프로세스, 완료된 프로세스, 실패한 프로세스 등을 지속적으로 모니터링 하기 힘듦,

2.4.5. 통합 설정 관리

개별 서버에서 설정값을 관리하는 것이 아닌 중앙에서 통합하여 설정값들을 관리할 수 있음

2.4.6. 손쉬운 장애 대응

하나의 프로세스가 서버 전체에 장애를 일으키는 경우

→ 프로세스마다 리소스 사용량을 제한할 수 있기 때문에 문제가 되는 프로세스만 장애 발생 되도록 할 수 있음.

2.4.7. 자동 확장

리소스가 부족하여 새로운 자원이 필요하면 쿠버네티스가 자동 확장을 해 줌

2.4.8. 하이브리드 클라우드 운영

최근 멀티 클라우드의 필요성이 점차 커지고 있음, 쿠버네티스가 클라우드간의 차이를 좁혀 줌

2.4.9. 자가 치유

self-healing

바라는 상태와 현재 상태를 저장하여, 컨테이어에 문제가 생겨 죽더라도 시스템에서 현재 상태와 바라는 상태가 달라진 것을 인지하고 다시 실행함

2.4.10. 데이터 스토리지 관리

다양한 데이터 저장소를 자동으로 관리해줌

네트워크 스토리지를 손쉽게 연결하고 해제할 수 있음

2.4.11. 배포 자동화

배포의 편리함.

사용자가 바라는 상태를 저장하면 쿠버네티스가 자동으로 적절한 노드를 선택하여 컨테이너를 배치 함,.

2.5. 마치며

티스토리툴바