[출처 : 쿠버네티스 인 액션, 마르코룩샤]

1장. 쿠버네티스의 소개

🖌2021.09.18

✔️ 쿠버네티스가 필요한 이유
거대한 모놀리스 애플리케이션을 작은 마이크로서비스로 세분화함과 동시에 해당 애플리케이션을 실행하는 인프라의 변경으로 인해 필요
모놀리스 애플리케이션은 서로 강하게 결합되어 있어 애플리케이션의 한 부분을 변경하더라도 전체 애플리케이션을 재배포해야 하며, 시간이 지남에 따라 구성요소간의 경계가 불분명해지고 상호의존성의 제약이 커지면서 시스템 복잡성이 증가하고 품질이 저하됨.
모놀리스 애플리케이션의 일부분이 수평적으로 확장이 어렵거나 불가능하다면 전체 애플리케이션의 확장은 불가능

• 마이크로서비스로 애플리케이션 분할
마이크로서비스는 일반적으로 RESTful(Representational State Transfer) API를 제공하는 HTTP와 같은 동기 프로토콜과 AMQP(Advanced Message Queuing Protocol)와 같은 비동기 프로토콜로 통신한다.
*이런 프로토콜은 특정 개발 언어에 종속적이지 않기 때문
출처 : https://www.redhat.com/ko/topics/microservices/what-are-microservices

• 마이크로서비스 확장
마이크로서비스 확장은 서비스별로 수행되므로 리소스가 더 필요한 서비스만 별도로 확장 가능하다.

• 마이크로서비스 배포(단점)
시스템의 구성요소가 많아지면 배포 조합의 수 뿐만 아니라 상호 족속성이 높아지기 때문에 배포 관련 결정이 어려워지며 장애포인트가 많아짐(실행 호출을 디버그하고 추적하기 어려움)
⇢ 현재 Zipkin과 같은 분석 추적 시스템으로 해결
애플리케이션이 서로 다른 버전의 라이브러리를 필요로 하는 경우 애플리케이션 구성 요소 간 종속성의 차이는 불가피하다.

• 지속적인 배포로 전환: 데브옵스와 노옵스(자동화로 운영팀의 손이 거의 필요 없는 환경을 의미)
개발 팀이 에플리케이션을 배포하고 관리하는 것. 즉 개발자, 품질보증(QA)운영팀이 전체 프로세스에서 협업하는 것을 데브옵스(DevOps)라고 부른다.
개발자가 애플리케이션을 실행하는데 더 많이 관여하게 되면 사용자의 피드백을 추가적인 개발에 신속하게 반영할 수 있다는 장점이 있다.

쿠버네티스를 사용하면 하드웨어를 추상화하고 이를 애플리케이션 배포, 실행을 위한 플랫폼으로 제공함으로써 개발자는 시스템관리자의 도움없이도 애플리케이션을 구성, 배포할 수 있으며 시스템 관리자는 실제 실행되는 애플리케이션을 알 필요 없이 인프라를 유지하고 운영하는 데 집중할 수 있다.

✔️ 컨테이너 기술 소개
가상머신을 사용해 각 마이크로서비스의 환경을 격리하게 된다면 시스템 관리자의 작업량이 상당히 증가하기 때문에 인력자원 낭비이다.
근래 개발자들은 동일한 호스트 시스템에서 여러개의 서비스를 실행할 수 있으며 서로 다른 환경을 만들어 줄 뿐만 아니라 가상머신과 유사하게 서로 격리하지만 오버헤드가 훨씬 적은 컨테이너 기술 활용.
출처 : https://kixxf.tistory.com/176

가상머신 내에서 실행되는 애플리케이션이 가상머신의 게스트OS커널에 대한 시스템 콜을 수행하면, 커널은 하이퍼바이저로 호스트의 물리적 CPU에서 x86 명령을 수행한다.

동일한 시스템에서 더 많은 수의 격리된 프로세스를 실행하려면 컨테이너의 오버헤드가 낮기 때문에 컨테이너를 선택하는것이 좋다. 컨테이너는 모두 동일 OS에서 실행되므로 컨테이너는 시스템 서비스를 실행하지 않는다. 즉, 컨테이너를 실행하려면 가상머신처럼 부팅할 필요가 없다. 컨테이너에서 실행되는 프로세스는 즉시 시작된다.

컨테이너 격리를 가능하게 하는 메커니즘 소개

1. 리눅스 네임스페이스 : 각 프로세스가 시스템(파일, 프로세스,네트워크 인터페이스, 호스트 이름 등)에 대한 독립된 뷰만 볼수 있도록 한다.
2. 리눅스 컨트롤 그룹(cgroups) : 프로세스가 사용할 수 있는 리소스(CPU, 메모리, 네트워크 대역폭 등)의 양을 제한한다.

→ 도커 자체가 프로세스 격리를 제공하지 않는다는 점 기억할것! 컨테이너의 격리는 리눅스 네임스페이스와 cgroup 같은 커널 기능으로 리눅스 커널 수준에서 수행되며, 도커는 이런 기능을 사용하기 쉽게 할 뿐이다.

리눅스 네임스페이스로 프로세스 격리

• 기본적으로 각 리눅스 시스템은 초기 구동 시 하나의 네임스페이스 존재(추가로 네임스페이스 구성하고 리소스를 구성할 수 있다)
• 프로세스는 동일한 네임스페이스 내에 있는 리소스만 볼 수 있다. 그러나 여러종류의 네임스페이스가 있기 때문에 프로세스는 하나의 네임스페이스에만 속하는 것이 아니라 여러 네임스페이스에 속할 수 있다.
• 네임스페이스의 종류는 다음과 같다
  → 마운트(mnt)
  → 프로세스 ID(pid)
  → 네트워크(net)
  → 프로세스 간 통신(ipc)
  → 호스트와 도메인 이름(uts)
  → 사용자ID (user)

-. 도커 기반 컨테이너 이미지와 가상머신 이미지의 큰 차이점은 컨테이너 이미지가 여러이미지에서 공유되고 재사용될 수 있는 레이어로 구성돼있다는 것이다. 즉, 동일한 레이어를 포함하는 다른 컨테이너 이미지를 실행할 때 다른 레이어가 이미 다운로드된 경우 이미지의 특정 레이어만 다운로드하면 된다.

-. 도커는 애플리케이션을 패키징, 배포, 실행하기 위한 플랫폼이다. 애플리케이션에서 필요한 몇 가지 라이브러리나 운영체제의 파일시스템에 설치되는 모든 파일을 포함시킬수 있으며, 도커를 사용하면 이 패키지를 Docker Hub로 전송하여 관리가 가능하다.

도커의 주요 세가지 개념은 다음과 같다

1. 이미지 : 애플리케이션과 해당 환경을 패키지화 한 것이다. 여기에는 애플리케이션에서 사용할 수 있는 파일시스템과 이미지가 실행될 때 실행돼야하는 실행파일 경로와 같은 메타데이터가 포함돼 있다.
2. 레지스트리 : 도커 이미지를 저장하고 다른 사람이나 컴퓨터 간에 해당 이미지를 쉽게 공유할 수 있는 저장소다. 이미지를 빌드할 때 빌드하는 컴퓨터에서 이미지를 실행하거나 이미지를 레지스트리로 푸시(업로드)한 다음 다른 컴퓨터에서 이미지를 풀(다운로드)할 수 있다.
3. 컨테이너 : 도커기반 컨테이너 이미지에서 생성된 일반적인 리눅스 컨테이너다. 실행중인 컨테이너는 도커를 실행하는 호스트에서 실행되는 프로세스이지만, 호스트와 호스트에서 실행중인 다른 프로세스와 완전히 격리돼 있다. 또 프로세스는 리소스사용이 제한되어 있으므로(cgroup) 할당된 리소스의 양만 액세스하고 사용할 수 있다.

-. 이미지 레이어의 이해
각 레이어는 동일 호스트에 한번만 저장된다. 동일한 기본 레이어를 기반으로 한 두개의 이미지에서생성한 두개의 컨테이너는 동일한 파일을 읽을 수 있지만, 그중 하나가 해당 파일을 덮어쓰면 다른 컨테이너에서는 해당 변경사항을 볼 수 없다. 이미지 레이어가 읽기 전용이기 때문이다** 컨테이너가 실행될 때 이미지 레이어 위에 새로운 쓰기 가능한 레이어가 만들어진다.

-. 컨테이너 이미지의 제한적인 이식성 이해
컨테이너는 가상머신에 비해 훨씬 가볍지만 컨테이너 내부에서 실행되는 애플리케이션은 일정한 제약이 있다. 각 가상머신은 자체 커널을 실행하기 때문에 이러한 제약이 없다..

-. 도커의 대안으로 rkt 소개
rkt도 컨테이너를 실행하기 위한 플랫폼이다. 보안, 결합성, 공개 표준 준수에 중점을 둔다. OCI(컨테이너 업계 표준..ㅎ)이미지 형식을 사용하며 일반 도커 컨테이너 이미지를 실행할 수도 있다.

✔️ 쿠버네티스 소개

쿠버네티스는 컨테이너화된 애플리케이션을 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템 이다.

시스템은 마스터 노드와 여러 워커 노드로 구성된다. 개발자가 애플리케이션 매니페스트를 마스터에 게시하면 쿠버네티스는 해당 애플리케이션을 워커노드 클러스터에 배포한다.

• 쿠버네티스 클러스터 아키텍처 이해
  쿠버네티스 클러스터는 여러 노드로 구성되며, 두가지 유형으로 나눌 수 있다

1. 마스터 노드는 전체 쿠버네티스 시스템을 제어하고 관리하는 쿠버네티스 컨트롤 플레인을 실행한다.
2. 워커 노드는 실제 배포되는 컨테이너 애플리케이션을 실행한다.

출처 : https://tkdguq05.github.io/2020/07/30/k8s-genesis/

* 컨트롤 플레인

컨트롤 플레인은 클러스터를 제어하고 작동시킨다. 하나의 마스터 노드에서 실행하거나 여러 노드로 분할되고 복제돼 ㄹ고가영성을 보장할 수 있는 여러 구송 요소로 구성된다. 구성 요소는 아래와 같다

→ 쿠버네티스 API 서버는 사용자, 컨트롤 플레인 구성요소와 통신한다
→ 스케줄러는 애플리케이션의 배포를 담당한다.(애플리케이션의 배포 가능한 각 구성요소를 워크노드에 할당.)
→ 컨트롤러 매니저는 구성요소 복제본, 워커노드 추적, 노드 장애 처리 등과 같은 클러스터단의 기능을 수행한다.
→ Etcd는 클러스터 구성을 지속적으로 저장하는 신뢰할 수 있는 분산 데이터 저장소다.

컨트롤 플레인의 구성요소는 클러스터 상태를 유지하고 제어하지만 애플리케이션을 실행하진 않은다. 이는 노드에 의해 이뤄진다.

* 노드

워커 노드는 컨테이너화된 애플리케이션을 실행하는 시스템이다. 애플리케이션을 신행하고 모니터링하며 애플리케이션에 서비스를 제공하는 작업은 다음 구성 요소에 의해 수행된다.

→ 컨테이너를 실행하는 도커,rkt 또는 다른 컨테이너 런타임
→ API 서버와 통신하고 노드의 컨테이너를 관리하는 Kubelet
→ 애플리케이션 구성요소간에 네트워크 트래픽을 로드밸런싱하는 쿠버네티스 서비스 프록시

* Kube-proxy

서비스를 제공하는 모든 컨테이너에서 서비스 연결이 로드밸런싱 되도록 한다.(서비스의 IP주소는 일정하게 유지되므로 클라이언트는 컨테이너가 클러스터 내에서 이동하더라도 컨테이너에 항상 연결할 수 있다)

* 쿠버네티스 사용의 장점

→ 애플리케이션 배포의 단순화
→ 하드웨어 활용도 높이기
→ 상태 확인과 자가 치유
→ 오토스케일링
→ 애플리케이션 개발 단순화