[쿠버네티스 인 액션] 1. 쿠버네티스 소개 (1)

1장에서 다루는 내용

• 최근 소프트웨어의 개발과 배포의 변화 이해
• 애플리케이션을 격리하고 컨테이너를 사용해 실행 환경 차이 줄이기
• 쿠버네티스에서 사용되는 컨테이너와 도커의 이해
• 쿠버네티스로 개발자와 시스템 관리자의 작업 간소화하기

---

쿠버네티스 : 조종사, 조타수(선박의 핸들을 잡고 있는 사람)를 뜻하는 그리스어

 

쿠버네티스의 장점

• 개발자가 모든 유형의 애플리케이션을 배포하고 실행할 수 있는 간단한 플랫폼을 제공한다.
• 개별 애플리케이션은 쿠버네티스가 관리하고 시스템 관리자는 쿠버네티스와 나머지 인프라를 감독하도록 한다.
• 하드웨어 장애 발생 시 애플리케이션을 모니터링하고 스케줄링을 조절할 수 있게 도와준다.
• 하드웨어 인프라를 추상화하고 데이터 센터 전체를 하나의 거대한 컴퓨팅 리소스로 제공한다.

---

1.1 쿠버네티스와 같은 시스템이 필요한 이유

1.1.1 모놀리스 애플리케이션에서 마이크로서비스로 전환

모놀리스 애플리케이션의 단점

• 전체가 하나의 운영체제 프로세스로 실행되기 때문에 하나의 개체로 개발, 배포 관리되어야 한다.
• 시간이 지남에 따라 구성 요소 간의 경계가 불분명해지고 상호 의존성이 커지면서 전체 시스템의 복잡성이 증가한다.
• 수평적으로 확장하기 어렵거나 불가능하다.

마이크로서비스로 애플리케이션 분할

• 모놀리스 애플리케이션을 마이크로서비스라는 독립적으로 배포할 수 있는 구성요소로 분할해야 한다.
• 각 마이크로서비스는 독립적으로 실행되며 단순한 인터페이스(API)로 다른 마이크로서비스와 통신한다.

마이크로서비스 확장

• 마이크로서비스는 리소스가 더 필요한 서버만 별도로 확장할 수 있다.

마이크로서비스 배포

• 구성 요소가 많아지면 배포 조합 수 뿐만 아니라 구성 요소 간의 상호 종속성 수도 많아져서 배포 관련 결정이 점점 어려워진다.
• 마이크로서비스는 여러 프로세스와 시스템에 분산되어 있기 때문에 실행 호출을 디버그하고 추적하기 어렵다.

환경 요구 사항의 다양성

• 독립적으로 개발, 배포되기 때문에 구성 요소 간 종속성의 차이가 발생할 수 있다.
• 동일 호스트에 배포해야하는 구성 요소가 많을 수룩 모든 요구사항을 충족시키기 위한 종속성 관리가 더 어려워진다.

---

1.1.2 애플리케이션에 일관된 환경 제공

• 애플리케이션을 실행하는 환경은 각각 다르며, 개발과 프로덕션 환경 사이의 차이 뿐만 아니라 각 프로덕션 머신 간의 차이도 있다.
• 개발과 프로덕션이 정확히 동일한 환경에서 실행되어 운영체제, 라이브러리, 시스템 구성, 네트워킹 환경, 기타 모든 것이 동일한 환경을 만들 수 있다면 이상적일 것이다.
• 가능하다면 기존 애플리케이션에 영향을 주지 않고 동일한 서버에 애플리케이션을 추가할 수 있는 기능을 원할 것이다.

---

1.1.3 지속적인 배포로 전환: 데브옵스와 노옵스

데브옵스의 장점

• 개발자, QA, 운영 팀이 전체 프로세스에서 협업하는 작업 방식을 데브옵스(DevOps)라고 부른다.
• 개발자가 프로덕션 환경에서 애플리케이션 실행에 관여하게 되면, 운영팀이 애플리케이션을 유지하면서 직면하는 문제가 무엇인지 더 잘 이해할 수 있으며 사용자의 피드백을 빠르게 반영할 수 있다.
• 개발자가 운영 담당자를 기다리지 않고 직접 배포하여 더 자주 릴리스할 수 있다.

개발자와 시스템 관리자 각자가 최고로 잘하는 것을 하게 하는 것

• 하드웨어 인프라를 전혀 알지 못하더라도 운영 팀을 거치지 않고 개발자가 애플리케이션을 직접 배포하는 방식을 노옵스(NoOps)라고 한다.
• 쿠버네티스를 통해 하드웨어를 추상화하고 이를 애플리케이션 배포, 실행을 위한 플랫폼으로 제공할 수 있다.
• 개발자는 시스템 관리자의 도움없이 애플리케이션을 구성, 배포할 수 있게 된다.
• 시스템 관리자는 애플리케이션을 알 필요 없이 인프라를 유지하고 운영하는데 집중할 수 있다.

---

1.2 컨테이너 기술 소개

1.2.1 컨테이너 이해

• 애플리케이션의 각 구성요소에 전용 가상머신을 제공하고 고유한 운영체제 인스턴스를 제공해 환경을 격리할 수 있다.
• 하지만 구성 요소가 점점 작아지고 많아지면 각 구성 요소마다 가상머신을 제공하기위한 하드웨어 리소스가 부족해진다.
• 점점 더 많아지는 가상머진은 인적 자원도 낭비된다.

리눅스 컨테이너 기술로 구성 요소 격리

• 리눅스 컨테이너는 동일한 호스트 시스템에서 여러 개의 서비스를 실행할 수 있으며 동시에 서로 다른 환경을 만들어줄 뿐만 아니라 가상머신에 비해 오버헤드도 훨씬 적다.
• 프로세스가 별도의 운영체제에서 실행되는 가상 머신과 달리 호스트 운영체제 내에서 실행된다.

컨테이너와 가상머신 비교

• 컨테이너는 동일한 하드웨어에서 더 많은 수의 소프트웨어 구성 요소를 실행할 수 있다.
• 가상머신은 시스템 프로세스를 위한 추가 컴퓨팅 리소스가 필요한 반면, 컨테이너는 호스트 OS 내에서 실행되므로 애플리케이션이 소비하는 리소스만 필요하다.
• 가상머신은 각 애플리케이션 별로 구성하기에 리소스가 부족하기 때문에 그룹으로 묶어 배포하는 경우가 있는 반면, 컨테이너는 애플리케이션 마다 하나의 컨테이너를 가질 수 있다.

• 가상머신은 각 가상머신이 자체 리눅스 커널을 실행해 완전한 격리를 제공하는 반면, 컨테이너는 동일한 커널을 호출함으로 보안 위험이 발생할 수 있다.

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

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

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

• 프로세스를 실행할 때 해당 네임 스페이스 중 하나에서 실행되며, 프로세스는 동일한 네임스페이스 내에 있는 리소스만 볼 수 있다.
• 여러 종류의 네임 스페이스가 있기 때문에 프로세스는 여러 네임 스페이스에 속할 수 있다.
• 각 네임스페이스는 특정 리소스 그룹을 격리하는 데 사용된다.
  
  
• 네임스페이스의 종류
  • 마운트(mnt)
  • 프로세스 ID(pid)
  • 네트워크(net)
  • 프로세스 간 통신(ipc)
  • 호스트 도메인 이름(uts)
  • 사용자 ID(user)

프로세스 가용 리소스 제한

• 프로세스의 리소스 사용을 제한하는 리눅스 커널 기능인 cgroups로 이뤄진다.
• 프로세스는 설정된 양 이상의 CPU, 메모리, 네트워크 대역폭 등을 사용할 수 없다.

---

1.2.2 도커 컨테이너 플랫폼 소개

• 도커는 애플리케이션 뿐만 아니라 라이브러리, 여러 종속성, 전체 운영체제 파일시스템까지도 프로비저닝하는 데 사용할 수있는 패키지로 만들어준다.
• 도커로 패키징된 애플리케이션을 실행하면 함께 제공된 파일 시스템 내용을 정확하게 볼 수 있으며, 실행중인 서버 환경에 관계없이 동일한 파일을 볼 수 있다.
• 리눅스 컨테이너 기술로 가상머신과 거의 동일한 수준의 격리를 제공하며, 가상머신 이미지에 비해 훨씬 작은 컨테이너 이미지를 사용한다.
• 도커 기반 컨테이너 이미지는 여러 이미지에서 공유되고 재사용될 수 있는 레이어로 구성되어 있다. 따라서 동일한 레이어를 포함하는 다른 컨테이너 이미지를 실행할 때는 특정 이미지만 추가로 다운로드하면 된다.

도커 개념 이해

• 이미지 : 애플리케이션과 해당 환경을 패키지한 것. 애플리케이션에서 사용할 수 있는 파일시스템과 이미지가 실행될 때 실행되어야 하는 실행파일 경로 같은 메타데이터가 포함되어 있다.
• 레지스트리 : 도커 이미지를 저장하고 공유할 수 있는 저장소이다. 빌드하는 컴퓨터에서 이미지를 실행하거나 이미지를 레지스트리로 push한 다음 다른 컴퓨터로 pull 할 수 있다. 공개 레지스트리와 비공개 레지스트리가 있다.
• 컨테이너 : 도커 기반 컨테이너 이미지에서 생성된 일반적인 리눅스 컨테이너. 호스트에서 실행 중인 다른 프로세스와 완전히 격리되어 있으며, 프로세스에 할당된 리소스 양만 액세스하고 사용할 수 있다.

도커 이미지의 빌드, 배포, 실행

• 개발자는 이미지를 만들어 레지스트로 푸시한다.
• 이미지는 레지스트리에 접근할 수 있는 모든 사람이 사용할 수 있으며 도커가 실행되는 다른 컴퓨터로 이미지를 가져와 실행할 수 있다.
• 도커는 이미지를 기반으로 격리된 컨테이너를 만들고 이미지의 일부로 지정된 바이너리 실행파일을 실행한다.

가상머신과 도커 컨테이너 비교

• 가상머신에서 실행될 때와 컨테이너로 실행될 때 모두 애플리케이션 A, B는 동일한 바이너리, 라이브러리에 접근할 수 있다.
• 가상머신에서는 두 애플리케이션 모두 동일한 파일 시스템에서 실행되므로 의심할 여지가 없다.
• 그러나 각 컨테이너는 격리된 자체 파일시스템이 있다고 했는데 어떻게 같은 파일을 공유할 수 있을까?

이미지 레이어의 이해

• 도커 이미지는 레이어로 구성되어 있다. 모든 도커 이미지는 다른 이미지 위에 빌드되며 두 개의 다른 이미지는 동일한 부모 이미지를 사용할 수 있으므로 각 이미지에는 동일한 레이어가 포함될 수 있다.
• 각 레이어는 동일 호스트에서 한번만 저장된다. 즉, 배포를 효율적으로 할 뿐만 아니라 이미지의 스토리지 공간을 줄이는 데도 도움을 준다.
• 컨테이너 이미지 레이어는 읽기 전용이며 컨테이너가 실해될 때 이미지 레이어 위에 새로운 쓰기 가능한 레이어가 만들어진다.
• 컨테이너의 프로세스가 기본 레이어 중 하나에 있는 파일에 쓰면 전체 파일의 복사본의 최상위 레이어에 만들어지고 프로세스는 복사본에 쓴다.
• 따라서 동일한 기본 레이어를 기반으로 한 두 개의 컨테이너는 동일한 파일을 읽을 수 있지만 변경 사항은 각각 저장된다.

컨테이너 이미지의 제한적인 이식성 이해

• 호스트에서 실행되는 모든 컨테이너가 호스트의 리눅스 커널을 사용한다는 사실과 관련해 주의할 것이 하나 있다.
• 가상머신은 자체 커널을 사용하기 때문에 이런 제약이 없지만 컨테이너화된 애플리케이션은 특정 커널 버전이 필요하다면 모든 시스템에서 작동하지 않을 수 있다.
• 커널 뿐만 아니라 특정 하드웨어 아키텍처용으로 만들어진 컨테이너화된 애플리케이션은 해당 아키텍처 시스템에서만 실행될 수 있다.
• x86 아키텍처용으로 만들어진 애플리케이션은 ARM 기반 컴퓨터에서 컨테이너화 할 수 없으며, 여전히 가상머신이 필요하다.

---

1.2.3 도커 대안으로 rkt 소개

• 도커가 성공한 뒤 컨테이너 형식과 런타임에 관한 개발된 업계 표준을 만들기 위해 OCI(Open Container Initiative)가 탄생헀다.
• rkt도 컨테이너를 실행하기 위한 플랫폼이며 보안, 결합성, 공개 표준 준수에 중점을 준다. OCI 컨테이너 이미지 형식을 사용하며 일반 도커 컨테이너 이미지를 실행할 수도 있다.
• 쿠버네티스는 도커 기반 컨테이너만을 위해 특별이 만들어진 컨테이너 오케스트레이션 시스템이 아니며, rkt도 지원한다.
• 이 책을 통해 쿠버네티스의 본질이 컨테이너 오케스트레이션이 아님을 알게 될 것이다.