Kubernetes Intro

Chapter1. 쿠버네티스 소개

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

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

–

모놀리스 애플리케이션에서 마이크로 서비스로 전환
- 모놀리스 애플리케이션
  - 모놀리스 애플리케이션은 모든 것이 서로 강하게 결합
  - 전체가 하나의 운영 체제 프로세스로 실행되기 때문에 하나의 개체로 개발,배포,관리
  - 애플리케이션의 한 부분이 변경되더라도 전체를 재배포
  - 시간이 지남에 따라 요소간 경계가 불분명해지고, 상호의존성 제약이 커져 전체 시스템의 복잡성이 증대
  - 마이크로 서비스 애플리케이션
    - 독립적으로 배포할 수 있는 작은 구성요소로 분할
    - 각 독립적인 프로세스로 실행되며, 인터페이스로 서로 다른 마이크로 서비스와 통신한다.
      일반적으로 사용하는 통신 프로토콜 - RESTFul API (Representational State Transfer) <- 동기 - AMQP (Advance Message Queuing Protocol) <- 비동기
    - 하지만 구성요소가 많아지면 배포조합의 수 뿐만아니라, 상호 종속성 수가 많아져 배포 관련 결정이 어려움
    - 여러 프로세스와 시스템에 분산되어 있어, 실행출을 디버그/추적이 어려움
      Zpkin과 같은 분산 추적 시스템으로 해결 가능
애플리케이션에 일관된 환경 제공
지속적인 배포로 전환

2. 컨테이너 기술 소개

동일한 호스트 시스템에서 여러 개의 서비스를 실행 가능
동시에 서로 다른 환경 구성 가능

가상머신과 유사하게 서로 격리하지만 오버헤드가 훨씬 적음

 가상머신과 컨테이너 
 - 가상머신 
   주요 이점은 각 가상머신이 자체 리눅스 커널을 실행해 완전한 격리를 제공
   하드웨어 리소스가 제한된 경우 격리하려는 프로세스가 적은 경우 사용
      
 - 컨테이너
   모두 동일한 커널을 호출함으로 보안 위험이 발생할 수 있다. 
   모두 동일한 OS에서 실행됨으로 컨테이너는 시스템 서비스를 실행하지 않아 부팅이 필요없다. 
   컨테이너에서 실행되는 프로세스는 즉시 실행된다. 

컨테이너가 동일한 운영체제에서 실행중인 프로세스를 격리하는 메커니즘

리눅스 네임스페이스 : 각 프로세스가 시스템에 대한 독립된 뷰만 볼 수 있도록 함 (파일, 프로세스, 네트워크 인터페이스, 호스트 이름)
- 네임스페이스 종류
  - 마운트(mnt)
  - 프로세스 ID(pid)
  - 네트워크 (net)
  - 프로세스간 통신 (ipc)
  - 호스트와 도메인 이름 (uts : Unix Time Sharing)
  - 사용자 ID (user)
리눅스 컨트롤 그룹 : 프로세스가 사용할 수 있는 리소스(CPU, 메모리, 네트워크 대역폭 등)의 양 제한

도커 컨테이너 플랫폼 소개

컨테이너를 여러 시스템에 쉽게 이식 가능하게 하는 최초의 컨테이너 시스템
애플리케이션을 패키징, 배포, 실행하기 위한 플랫폼 (Build, ship and run any app, Anywhere)
패키징된 애플리케이션은 도커의 중앙 저장송 전송할 수 있다. (docker hub)
리눅스 컨테이너 기술로 가상머신과 거의 동일한 수준의 격리를 제공한다.
컨테이너 이미지가 여러 이미지에서 공유되고 재사용 될 수 있는 레이어로 구성. 동일한 레이어를 포함하는 다른 컨테이너 이미지를 실행할때 다운로드 되지 않은 특정 레이어만 다운로드 하면 된다.
주요 개념
1. 이미지
  애플리케이션과 해당 환경을 패키지화 한 것으로 실행파일 경로와 같은 메타데이터 포함
2. 레지스트리
  도커 이미지를 저장하고 컴퓨터간에 해당 이미지를 공유할 수 있게 한 저장소로 push/pull로 업로드, 다운로드 한다. 비공개 레지스트리인 경우, 시크릿을 활용하여 특정 사람이나 컴퓨터만 액세스할 수 있다.
3. 컨테이너
  도커 컨테이너 이미지에서 생성된 리눅스 컨테이너로 다른 프로세스와 완전히 격리되어 실행된다. 프로세스는 리소스 사용이 제한되어 있어 (cgroups) 할당된 리소스양 (CPU, RAM)만 액세스/사용 한다.
## 3. 쿠버네티스 소개
1. 쿠버네티스의 핵심
  - 시스템은 마스터 노드와 워커 노드로 구성된다.
  - 개발자가 애플리케이션 매니페스트를 마스터에 게시하면 쿠버네티스는 해당 애플리케이션을 워크 노드 클러스터에 배포, 되어떤 노드에 배포되는 것은 중요하지 않다.
  - 서비스 디스커버리, 스케일링, 로드밸런싱, 자가 치유, 리더선출등의 기능을 제공한다. 행
2. 쿠버네티스 클러스터 아키텍처 이해
  - 마스터 노드 : 전체 쿠버네티스 시스템을 제어하고 관리하는 쿠버네티스 컨트롤 플레인
    - 컨트롤 플레인(master) : 클러스터 제어/작동 (애플리케이션을 실행하지는 않는다. 워크노드가실행)
      - 쿠버네티스 API 서버
        
        사용자, 컨트롤 플레인 구성요소와 통신
      - 스케줄러
        
        애플리케이션 배포(워크노드에 할당)
      - 컨트롤 매니저
        
        구성 요소 복제본, 워커 노드 추적, 노드 장애 처리
      - Etcd
        
        클러스터 구성을 지속적으로 저장하는 신뢰할 수 있는 분산데이터 저장
  - 워커 노드 : 실제 배포되는 컨테이너 애플리케이션을 실행
    - 컨테이너 런타임 컨터이너를 실행하는 도커, rkt와 같은 컨테이너 - kubelet API 서버와 통신하고, 노드의 컨테이너를 관리 - kube-proxy 애플리케이션 구성 요소 간에 네트워크 트래픽을 로드밸런싱
3. 쿠버네티스에서 애플리케이션 실행
  1. 애플리케이션을 하나 이상의 컨테이너 이미지로 패키징
  2. 이미지 레지스트리로 푸시
  3. 쿠버네티스 API 서버에 애플리케이션 디스크립션 게시
- 디스크립션으로 컨테이너를 실행하는 방법 이해
  
  API 서버가 애플리케이션 디스크립션을 처리할 때
  1. 스케줄러는 각 컨테이너에 필요한 리소스를 계산
  2. 각 노드에 할당되지 않은 리소스를 기반으로 사용가능한 워커 노드에 지정한 컨테이너 할당
  3. 해당 노드의 Kubelet은 컨테이너 런타임에 필요한 컨테이너 이미지를 가져와 실행하도록 지시
- 실행된 컨테이너 유지
  애플리케이션이 실행되면, 쿠버네티스는 애플리케이션의 배포 상태가 사용자가 제공한 디스크립션과 일치하는지 지속적으로 확인한다. 만일 프로세스가 중단되거나 응답이 중지되어 인스턴스가 제대로 작동하지 않으면 쿠버네티스가 자동으로 재시작한다.
- 복제본 수 스케일링
  애플리케이션이 실행되는 동안 복제본 수를 조정할 수 있고 쿠버네티스에 의해 자동으로 생성되게 할 수 도 있다.
- 이동한 애플리케이션에 접근하기 kube-proxy는 서비스를 제공하는 모든 컨테이너에서 서비스 연결이 로드밸런싱되도록 한다. 서비스의 IP 주소는 일정하게 유지되므로 클라이언트는 컨테이너가 클러스터 내에서 이동하더라도 컨테이너에 항상 연결할 수 있다.

### 쿠버네티스 사용의 장점

애플리케이션 배포의 단순화
- 쿠버네티스는 모든 워커 노드를 하나의 배포 플랫폼으로 제공하기 때문에 애플리케이션 개발자는 자체적으로 애플리케이션 배포를 시작할 수 있으며, 클러스터를 구항하는 서버에 관해 알 필요가 없다.
하드웨어 활용도 높이기
- 서버에 수동으로 애플리케이션을 실행하는 대신 쿠버네티스를 설정하고 애플리케이션을 실행함으로써, 인프라와 애플리케이션을 분리할 수 있다.
- 쿠버네티스가 가장 적합한 노드를 찾아 실행하게 됨.
상태 확인과 자가 치유
- 서버 장애 발생 시 언제든지 클러스터 간에 애플리케이션을 이동할 수 있는 시스템을 갖추는 것이 중요한데, 쿠버네티스는 모니터링 시 자동으로 애플레킹션을 다른 노드로 스케줄링한다.
오토스케일링
애플리케이션 개발 단순화