# 1장. 쿠버네티스 소개

## TL;DR
### 쿠버네티스란
- 분산 시스템을 효율적으로 구축/운영 가능한 오픈소스 오케스트레이터

### 쿠버네티스의 이점
- 개발 속도
	- 불변성
	- 선언형 컨피규레이션
	- 온라인 자가 치유 시스템
	- 재사용 가능한 공유 라이브러리와 도구
- 확장성
	- 애플리케이션과 클러스터의 손쉬운 확장
	- 마이크로서비스를 통한 개발 팀 확장
	- 일관성과 확장에 대한 고려 사항 분리
- 인프라 추상화
- 효율성
- 클라우드 네이티브 에코시스템

---

## 쿠버네티스란?
- 컨테이너화된 애플리케이션을 배포하기 위한 오픈소스 오케스트레이터
- 모든 규모의 **클라우드 네이티브** 개발자에 적합한, 분산 시스템을 위한 검증된 인프라스트럭처
	- `클라우드 네이티브`: 클라우드 컴퓨팅의 장점을 최대한 활용하여 애플리케이션을 개발하고 운영하는 방식
- **신뢰성**과 **확장성**을 갖춘 분산 시스템을 성공적으로 구축하고 배포하는 데 필요한 소프트웨어를 제공
	- `신뢰성`: 가용성을 보장
	- `확장성`: 근본적인 재설계 없이도 시스템의 용량을 늘릴 수 있고, 자동으로 늘리거나 줄일 수 있음

## 쿠버네티스의 이점
### 1. 개발 속도
❌ 시간 당 or 일별로 제공할 수 있는 기능의 수<br/>
✅ 높은 가용성을 갖는 서비스를 유지하면서 제공할 수 있는 항목의 수

> 안정적인 배포와 운영을 위한 기능을 제공!

#### 1.1. 불변성
- 시스템에 생성된 아티팩트는 사용자의 수정에 의해 변경될 수 없음 (ex. docker container)
- 전통적인 SW 시스템은? 변경 가능한 인프라
	- CLI를 통한 지속적인 업데이트
	- *특정 CLI 명령어를 서버 A~Z에서 입력해야 했는데, Z를 빼먹었다..!*
	- *서버 F에 어떤 개발자가 접속해서 이상한 CLI 명령어를 입력한 결과, 서버 F가 죽었다..!*
- 불변형 시스템은?
	- No 증분 변경. 완전 교체
	- 기존 컨테이너 중지 -> 새로운 컨테이너 이미지로 새로운 컨테이너 시작
	- 기존 시스템 대비 **장점**은?
		- `기록`: 생성한 아티팩트와 생성 방법을 기록하기 때문에, 오류가 발생한 경우 해결 방법 명확하게 확인 가능
			- *근데 이건 DockerFile의 장점 아닌지?*
		- `롤백`: 기존 이미지가 그대로 남아 있기 때문에, 오류 발생 시 즉시 롤백 가능
	- 단, 컨테이너도 극단적인 경우에 한해서는 직접 접근하여 CLI 명령어를 입력할 수도 


#### 1.2. 선언형 컨피규레이션
명령형 컨피규레이션 (**동작**을 정의)
``` bash
apt-get update 
apt-get install nginx 
echo "server { 
	listen 80; server_name example.com; root /var/www/example; 
	}" > /etc/nginx/sites-available/example
ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/
service nginx restart
```

선언형 컨피규레이션 (**상태**를 정의 & 어떻게 할 건지는 쿠버네티스가 알아서~)
``` yml
apiVersion: apps/v1
kind: Deployment
metadata: 
  name: nginx-deployment 
spec: 
  replicas: 3 
  selector: 
    matchLabels: 
      app: nginx 
  template: 
    metadata: 
      labels: 
        app: nginx 
    spec: 
      containers: 
      - name: nginx 
      image: nginx:1.14.2
      ports: 
      - containerPort: 80
```

- 영향도를 구체적으로 확인할 수 있기 때문에, 에러 발생 가능성이 훨씬 더 적음
- 버전 관리, 코드 리뷰 등이 수월
- 변경에 대한 롤백이 매우 쉽고 간단함

#### 1.3. 온라인 자가 치유 시스템
- 원하는 상태(S)의 컨피규레이션이 설정되면, S에 도달하기 위해 끊임없이 조취를 취함
	- *replica: 3*
- 전통적인 방식? 인적 개입 필요!
- 쿠버네티스는 스스로 장애 복구 수행 -> 시스템 신뢰성 UP


### 2. 확장성
#### 2.1. 애플리케이션과 클러스터의 손쉬운 확장
- 서비스를 확장하려면 컨피규레이션만 변경하면 됨. 나머지 동작은 쿠버네티스가 알아서 함
  - *replica: 2 -> 3*
  - *autoscale: on (실제 있는 옵션 X)*
- 클러스터 자체를 확장해야 하는 경우가 있는데, 쿠버네티스는 미래의 컴퓨팅 비용 예측을 단순화할 수 있음
	- A, B, C라는 3개의 팀을 확장한다고 가정
	- 각 서비스별로 개별 머신을 **프로비저닝**하는 경우, 각 서비스별로 예상되는 최대 성장 수치를 기반으로 예측 (예측도 어려움)
		- `프로비저닝`: 네트워크, 스토리지 등 리소스를 할당하여 시스템을 사용할 수 있도록 하는 것
	- 쿠버네티스를 사용하는 경우, 팀이 특정 머신을 사용하지 않게 분리해 3개 서비스의 전체 성장률을 기반으로 예측
	- *개별 주식의 성장률을 예측하기 어려우니 S&P 500을 구매*

#### 2.2. 마이크로서비스를 통한 개발 팀 확장
- 이상적인 팀의 규모는 '피자 2판 규모의 팀'
- 하지만 대부분의 프로젝트는 많은 양의 리소스를 요구
- 이를 위해 분리된 서비스 지향 팀을 구성해 각 팀별로 개별 마이크로서비스를 개발
- 이를 충족하는 쿠버네티스의 다양한 추상화와 API
	- 파드, 서비스, 네임스페이스, 인그레스

> 애플리케이션 컨테이너 이미지와 머신을 분리하면 각기 다른 마이크로서비스가 동일한 머신에 위치하게 해 서로 간섭하지 않도록 배치할 수 있으며, 이를 통해 마이크로서비스 아키텍처에서 오버헤드와 비용을 줄일 수 있다.
> - P. 42

- `단일 Pod`: 같은 Pod에 속한 모든 컨테이너는 동일한 노드에서 실행
- `Pod Affinity`: 서로 다른 Pod에 위치한 컨테이너들끼리도 동일한 노드에 배치되도록 하는 방법
- `Node Affinity`: 특정 노드에 특정 컨테이너가 실행되도록 제어하는 방법

#### 2.3. 일관성과 확장에 대한 고려 사항 분리
**책임의 분리**
- **애플리케이션 운영자** <-> 컨테이너 오케스트레이션 API <-> **클러스터 오케스트레이션 운영자**
	- 애플리케이션 운영자: 클러스터를 어떻게 확장할 것인지 신경 X
	- 클러스터 오케스트레이션 운영자: 애플리케이션의 기능을 어떻게 확장할 것인지 신경 X

**API를 통한 운영 팀의 분리**
- **애플리케이션 Ops**
- 쿠버네티스 API
- **클러스터 Ops**
- 커널 SysCall API
- **커널 Ops**
- CPU
- **하드웨어 Ops**

### 3. 인프라 추상화
> 클라우드는 클라우드 제공자에 특화된 구현 세부 사항이나 서비스와 함께 제공된다. 이러한 API를 직접 호출하는 것은 다양한 환경에서 애플리케이션 실행이나 클라우드와 물리 환경 간 배포를 어렵게 만든다.
> - P. 44

- [ ] 어떤 의미인지?

##### 장점
- 개발자를 특정 머신으로부터 분리
	- [ ] AWS, GCP, NCP를 써도 쿠버네티스를 사용한다면 각각의 클라우드에 종속되지 않는다는 것을 의미하는 것일지?
- 높은 이식성 제공
	- ex) 쿠버네티스 서비스는 모든 주요 퍼블릭 클라우드뿐만 아니라 여러 프라이빗 클라우드와 물리 인프라에서 로드 밸런서를 생성하는 방법을 알고 있음
	- why? 어떤 시스템이든 쿠버네티스를 설치하면 되기 때문
	- 즉, 쿠버네티스를 사용한다면 AWS에서 물리 인프라로 옮기는 것도 수월

> 쿠버네티스 PersistentVolume과 PersistentVolumeClaim의 경우 애플리케이션을 특정 스토리지 구현체로부터 추상화할 수 있다.
> - P. 45

- `PersistentVolume`: 쿠버네티스 클러스터의 실제 스토리지 리소스를 나타냄 (AWS S3, Google Cloud Storage와 같은 다양한 스토리지 서비스를 지원)
- `PersistentVolumeClaim`: 사용자가 필요한 스토리지를 요청하는 방식

### 4. 효율성
`효율성 = 머신이나 프로세스가 수행한 유용한 작업과 해당 작업을 수행하는 데 소비한 전체 에너지 양의 비율`

- **서버를 운영할 때 들어가는 금전적인 비용 감소**
	- 머신 클러스터 전체에 애플리케이션 배포를 하기 때문에, 보다 높은 수준의 서버 사용률을 보장!
- **관리에 필요한 인적 비용 감소**
	- 선언형 컨피규레이션으로 자동 확장/축소 가능

### 5. 클라우드 네이티브 에코시스템
- 대부분의 클라우드 네이티브 프로젝트가 오픈소스
- 쿠버네티스와 통합되는 다양한 프로젝트가 존재
- *ex) Jenkins X, Prometheus, Grafana, Helm ...*