1장. 쿠버네티스 소개

TL;DR

쿠버네티스란

분산 시스템을 효율적으로 구축/운영 가능한 오픈소스 오케스트레이터

쿠버네티스의 이점

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

쿠버네티스란?

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

쿠버네티스의 이점

1. 개발 속도

❌ 시간 당 or 일별로 제공할 수 있는 기능의 수
✅ 높은 가용성을 갖는 서비스를 유지하면서 제공할 수 있는 항목의 수

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

1.1. 불변성

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

1.2. 선언형 컨피규레이션

명령형 컨피규레이션 (동작을 정의)

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

선언형 컨피규레이션 (상태를 정의 & 어떻게 할 건지는 쿠버네티스가 알아서~)

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 …