쿠버네티스 인 액션 1장 정리

항상 참고할만한 문헌

• 전체 소스코드와 yaml 매니페스트는 https://github.com/luksa/kubernetes-in-action
• 쿠버네티스 웹사이트: https://kubernetes.io
• 쿠버네티스 블로그 : http://blog.kubernetes.io
• 쿠버네티스 커뮤니티 슬랙 채널 : http://slack.k8s.io
• 쿠버네티스와 클라우드 네이티브 컴퓨팅 재단(CNCF) 유투브 채널
  • http://www.youtube.com/channel/UCZ2bu0qutTOM0tHYa_jkIwg
  • http://www.youtube.com/channel/UCvqbFHwN-nwalWPjPUKpvTA
• 쿠버네티스가 오픈소스인만큼 쿠버네티스의 소스 자체에 풍부한 정보가 있다. 소스코드는
• https://github.com/kubernetes/kubernetes

1. 쿠버네티스 소개

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

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

• 모놀리스 애플리케이션
  • 모든 요소가 강하게 결합되어있고, 전체가 하나의 운영체제 프로세스로 실행되어 하나의 개체로 개발, 배포, 관리돼야함.
  • 소수의 강력한 서버가 필요하고 부하 처리를 위해 확장이 필요한데, 확장이 어려움
• 마이크로 서비스
  • 주로 정적인 외부 api 를 제공하는 독립형 프로레스
  • 개별적으로 개발, 배포 가능
  • api 변경이 아니면, 다른 서비스를 변경하거나 재배포하지 않앋됨.
  • 개별적으로 확장 가능
  • 단점
    • 시스템의 구성요소가 많아지면, 배포 조합의 수나 구성 요소간의 상호 종속성 등 고려할 게 많아짐
    • 여러 프로세스와 시스템에 분산되어있어 실행호출 디버깅이 어려움(zipkin 분산추적 시스템 같은 것으로 해결)
    • 애플리케이션 간에 필요로 하는 라이브러리 버전 차이가 있는 경우, 종속성 관리가 어려워짐

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

• 개발자와 운영팀이 항상 해결해야하는 가장 큰 문제 중 하나는 애플리케이션을 실행하는 환경이 다르다는 것
• 개발과 프로덕션이 정확이 동일환 환경에서 실행돼, 운영체제, 라이브러리, 시스템 구성, 네트워킹 환경 등이 모든 것이 동일한 환경을 만들 수 있다면 이상적일 것이다.

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

• 데브옵스(development + operation)
  • 개발 담당자와 운영 담당자가 연계해 협력하는 개발 방법론
  • 신속하게 사용자의 피드백을 추가해 개발에 반영할 수 있다.
• 노옵스
  • 운영팀을 거치지 않고 개발자가 애플리케이션을 직접 배포한다.

쿠버네티스를 사용하면 모든 것이 해결된다.

하드웨어를 추상화하고, 이를 애플리케이션 배포+ 실행을 위한 플랫폼으로 제공해 개발자는 시스템 관리자 도움없이 애플리케이션을 구성 + 배포할 수 있고

시스템 관리자는 실제 실행되는 애플리케이션을 알 필요 없이 인프라를 유지하고 운영하는데 집중할 수 있다.

1.2. 컨테이너 기술 소개

1.2.1. 컨테이너 이해

• 가상 머신으로 격리
  • 애플리케이션이 작은수, 커다란 구성요소로만 이뤄진 경우 가상 머신을 이용해 환경을 격리할 수 있다.
  • 그러나 구성 요소가 많아지고, 크기가 작아지면, 하드웨어 + 관리자의 인적자원 낭비
  • 구성 요소 프로세스 뿐만아니라, 시스템 프로세스를 실행해야하기 때문에 추가 컴퓨팅 리소스 필요
  • 물리적 하드웨어 리소스를 각 가상 머신으로 나누는 호스트 os 와 하이퍼바이저가 있다.
  • 해당 가상머신에서 실행되는 애플리케이션이 가상머신의 게스트 os 커널에 대한 시스템콜을 수행하면 커널은 하이퍼바이저로 호스트의 물리적 cpu 에서 명령을 수행한다.

    

• 리눅스 컨테이너 기술로 구성요소 격리
  • 가상머신과 유사하게 격리되지만, 오버헤드가 훨씬 적다.
  • 가상머신은 프로세스가 호스트와는 별도의 os 에서 실행되지만 컨테이너의 프로세스는 다른 프로세스와 마찬가지로 호스트 os 내에서 실행된다.
  • 다른 프로세스와 격리되어, 프로세스 입장에서 보면, 시스템과 운영체제에서 실행하는 유일한 프로세스인 것 처럼 보인다.
  • 애플리케이션이 소비하는 리소스만 소비하고 추가 오버헤드는 없다.
  • 호스트 OS 에서 실행되는 동일한 커널에서 시스템 콜을 수행한다.
    • 단점: 동일한 커널을 호출하기 때문에 보안 위험이 발생할 수 있다.
    • 장점: 오버헤드가 작아 더 많은 수의 격리된 프로세스 실행 가능 부팅할 필요 없이 즉시 시작.

    • 

• *컨테이너 격리를 가능하게하는 매커니즘 소개 (https://tech.ssut.me/what-even-is-a-container/) *
• 리눅스 네임스페이스
  • 기본적으로 초기 구동시,
    • 하나의 네임스페이스가 있고,
      • (파일 시스템, pid, 사용자 id, 네트워크 인터페이스 등과 같은) 모든 시스템 리소스는 하나의 네임 스페이스에 속한다.
  • 추가 네임스페이스를 생성하고 리소스를 구성할 수 있다.
  • 프로세스는 실행할 때 동일한 네임스페이스 내에 있는 리소스만 볼 수 있어, 격리하는데 이용할 수 있다.
  • 프로세스는 여러개의 네임스페이스에 속할 수 있다.
  • 네임스페이스 종류
    • Mnt(파일시스템 마운트): 호스트 파일시스템에 구애받지 않고 독립적으로 파일시스템을 마운트하거나 언마운트가능
    • Pid(프로세스): 독립적인 프로세스 공간을 할당
    • net(네트워크): namespace간에 network 충돌 방지(중복포트 바인딩 등)
    • Ipc(systemV IPC): 프로세스 간에 독립적인 통신 통로 할당
    • Uts(hostname): 독립적인 hostname 할당
    • User(UID): 독립적인 사용자 할당
  • 리눅스 컨트롤 그룹(cgroups)
    • 리소스 사용을 제한하여 프로세스가 설정된 양 이상의 cpu, memory, 네트워크 대역폭을 사용할 수 없게 한다.

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

• 도커는 컨테이너를 여러 시스템에 쉽게 이식가능하게 한 최초의 컨테이너 시스템이다.
• 가상 머신 이미지 배포, 실행하는 과정과 유사하다.
• 리눅스 컨테이너 기술로 가상 머신과 거의 동일한 수준의 격리를 제공하지만, 가상 머신 이미지와는 달리, 훨씬 작은 컨테이너 이미지를 사용한다.
• 도커 기반의 컨테이너 이미지는 여러 이미지에서 공유되고 재사용할 수 있는 레이어로 구성되어있다. 이미 다운로드된 레이어는 추가로 다운받지 않고 재사용한다.
• 도커 개념 이해
  • 애플리케이션을 패키징, 배포, 실행하기 위한 플랫폼이고, 애플리케이션을 전체 환경과 함께 패키지화할 수 있다.
  • 이 패키지를 중앙저장소로 전송한다.
  • 이미지 : 애플리케이션과 해당 환경을 패키지화한 것이다. 파일시스템과 실행파일 경로등의 메타데이터가 있다.
  • 레지스트리 : 저장소(push, pull)
  • 컨테이너: 컨테이너 이미지에서 생성된 일반적인 리눅스 컨테이너, 그러나, 호스트와 호스트에서 실행중인 다른 프로세스와는 격리되어있다.
• 제한적인 이식성 이해 : 컨테이너화된 애플리케이션이 특정 커널 버전을 필요로 한다면 호스트의 리눅스 커널을 사용하기 때문에 모든 시스템에서 작동하지 않을 수 있다. 특정 하드웨어 아키텍쳐용으로 만들어진 컨테이너화된 애플리케이션도 제한된다.

1.2.3. 도커 대안으로 rkt 소개

• 도커는 컨테이너를 주류로 만든 최초의 플랫폼이다. 도커 자체가 프로세스의 격리를 제공하지 않는다.
• 컨테이너의 격리는 리눅스 네임스페이스와 cgroups 와 같은 커널기능으로, 리눅스 커널 수준에서 수행된다.
• rkt 도 도커와 마찬가지로 컨테이너를 실행하기 위한 플랫폼이고 보안 결합성 공개 표준 준수에 중점을 둔다.

---

1.3. 쿠버네티스 소개

• 수천개의 소프트웨어 구성요소를 관리하고 비용 효율적으로 개발, 배포할 수있는 솔루션이 필요함.
• 개발, 관리 의 단순화 , 인프라 활용률을 높임
• 수십만대의 머신을 운영 -> 사용률이 조금만 향상되어도 큰 절약이 가능하다.

1.3.2. 넓은 시각으로 쿠버네티스 바라보기

• 컨테이너화된 app 을 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템
• App 의 내부 세부사항을 알 필요 없읍
• 각 호스트에 app 을 수동으로 배포하지 않고, 이기종 app 실행가능
• app 은 컨테이너에서 실행 -> 동일한 서버에서 실행되는 다른 App에 영향 x
• 모든 노드가 하나의 거대한 컴퓨터인것처럼, 수천대의 컴퓨터노드에서 소프트웨어 앱 실행가능
• 기본 인프라를 추상화, 개발/운영팀 모두의 개발, 배포, 관리를 단순롸
• 클러스터의 노드 개수와 상관없이 쿠버네티스에 app 배포는 항상 동일
• 클러스터 노드의 추가 -> 배포된 app 이 사용가능한 리소스 양 추가

kubernetes 가 하는 일 핵심 이해

• 시스템은 master node 와 여러 worker node로 구성
• 개발자가 application manifest(description)을 마스터에 게시
• 쿠버네티스는 해당 app 을 worker node cluster에 배포
• 구성요소가 어떤 노드에 배포되는지는 중요하지 않음.
• 개발자는 특정 app이 함께 실행되도록 저장 가능
• 쿠버네티스는 여러 app 을 동일한 워커 노드에 배포
• 다른 app 은 클러스터에 걸쳐 분산 배포
• 배포 위치에 상관없이 동일한 방식으로 서로 통신 가능

개발자가 app 핵심 기능에 집중할 수 있도록 지원

• 쿠버네티스는 클러스터의 운영체제로 생각할 수 있음
• app 개발자는 특정 인프라 관련 서비스를 App 에 구현하지 않아도됨. -> k8s 에 의존해 제공
  • 서비스 디스커버리
  • 스케일링
  • 로드밸런싱
  • 자가 치유
  • 리더 선출
• 인프라와 통합하는 방법을 찾는데, 리소스 투자 x

1.3.3. 쿠버네티스 클러스터 아키텍쳐의 이해

• 마스터 노드
  • 특징: 마스터 노드는 전체 쿠버네티스 시스템을 제어하고, 관리하는 쿠버네티스 컨트롤 플레인을 실행한다.
  • 컨트롤 플레인
    • 컨트롤 플레인은 클러스터를 제어하고 작동시킨다.(= 클러스터 상태 유지 및 제어)
    • 하나의 마스터 노드에서 실행하거나 여러 노드로 분할되고 복제돼 고가용성을 보장할 수 있는 여러 구성 요소로 구성된다.
    • 구성요소
      • 쿠버네티스 api 서버는 사용자, 컨트롤 플레인 구성요소와 통신한다.
      • 스케줄러는 애플리케이션의 배포를 담당한다.
      • 컨트롤러 매니저는 구성 요소 복제본, 워커 노드 추적, 노드 장애 처리와 같은 클러스터 단의 기능을 수행한다.
      • etcd는 클러스터 구성을 지속적으로 저장할 수 있는 신뢰성 있는 분산 데이터 저장소이다.
• 워커 노드
  • 특징: 워커노드는 실제 배포되는 컨테이너 애플리케이션을 실행한다.
    • 애플리케이션을 실행하고 모니터링하며, 애플리케이션에 서비스를 제공하는 작업은 다음 구성 요소에 의해 수행된다.
  • 컨테이너를 실행하는 도커, rkt 또는 다른 컨테이너 런타임
  • api 서버와 통신하고 노드의 컨테이너를 관리하는 kubelet.
  • 애플리케이션 구성 요소 간에 네트워크 트래픽을 로드 밸런싱하는 kube-proxy
• 11장에서 좀 더 자세히 설명할 것이다.

1.3.4. 쿠버네티스에서 애플리케이션 실행

쿠버네티스에서 애플리케이션을 실행절차

1. app 을 하나 이상의 컨테이너 이미지로 패키징
2. 이미지 레지스트리로 푸시
3. 쿠버네티스 Api 서버에 application description 게시

4. application description 에 포함된 정보

   1. 컨테이너 이미지
   2. application 구성요소가 포함된 이미지
   3. 해당 구성요소가 서로 통신하는 방법
   4. 동일 서버에 함께 배치돼야하는 구성요소
   5. 실행할 각 구성요소의 복제본 수 지정 가능
   6. 내부 or 외부 클라이언트에 서비스를 제공하는 구성 요소
   7. 하나의 ip 주소로 노출해 다른 구성요소에서 검색 가능하게 해야하는 구성요소

디스크립션으로 컨테이너를 실행하는 법 이해

• api 서버가 application description 을 처리
  • 스케줄러는 각 컨테이너에 필요한 리소스를 계산
  • 해당 시점에 각 노드에 할당되지 않은 리소스 기반 사용가능한 워커 노드에 지정된 컨테이너 할당
  • 해당 노드의 kubelet 은 컨테이너 런타임(docker)에 필요한 컨테이너 이미지를 가져와 컨테이너 실행을 지시한다.

실행된 컨테이너 유지 (-> 컨트롤러 매니저)

• 애플리케이션이 실행되면, K8s 는 app 의 배포 상태가 description 과 일치하는지 지속적으로 확인한다.
  • 인스턴스가 제대로 작동하지 않는 경우 (예. 프로세스가 중단되거나, 응답이 중지) 쿠버네티스가 자동으로 다시 시작한다.
  • 워커노드 전체가 종료 or 액세스 불가한 경우, 해당 워커 노드에서 실행중인 모든 컨테이너 노드를 새로 스케줄링하고, 새로 선택한 노드에서 실행한다.

복제본 수 스케일링

• app 실행 도중, 복제본 수를 늘릴지 줄일지 결정 가능하다.
  • k8s 는 추가 복제본을 기동 or 초과 복제본을 정지한다.
  • 아싸리, 최적의 복제본수를 K8s 에 위임 가능하다.(알아서 자동 조절해서 오토 스켈링)
    • 실시간 메트릭(cpu 부하,메모리 사용량,초당 요청 수,애플리케이션이 노출하는 다른 메트릭)을 기반으로 복제본 수를 자동 조정 가능하다.

이동한 애플리케이션에 접근하기

• k8s 는 컨테이너를 클러스터 안에서 이동 가능하다.
  • when
    • 실행 중인 노드가 정지했거나,
    • 다른 컨테이너를 위한 공간을 만들기 위해 제거하는 경우,
• 특정 서비스를 제공하는 컨테이너를 쉽게 찾을 수 있게 해준다.
  • k8s 에게 동일한 서비스를 제공하는 컨테이너를 알려줌
  • k8s 는 하나의 고정 ip 주소로 모든 컨테이너를 노출
  • 해당 주소를 클러스터에서 실행중인 모든 app 에 노출
  • 해당 변수로 제공 & dns 로 서비스 ip 조회 가능
• kube-proxy : 서비스를 제공하는 모든 컨테이너에서 서비스 연결이 로드밸런싱되도록 함
• 컨테이너는 옮겨져 재시작하면, 새로운 IP를 받지만 , 서비스는 여전히 동일한 IP 주소를 유지한다.
  • 컨테이너가 이동하더라도, 항상 연결할 수 있다.

1.3.5. 쿠버네티스 사용의 장점

모든 서버에 쿠버네티스가 설치되는 경우 운영팀이 더이상 애플리케이션 배포를 처리할 필요가 없다.

애플리케이션 배포의 단순화

• k8s는 모든 워커 노드를 하나의 배포 플랫폼으로 제공
• app 개발자가 자체적으로 app 배포 가능. 클러스터 구성서버 알 필요가 없다.
• 모든 노드 -> app 이 해당 노드의 사용을 기다리는 컴퓨팅 리소스
• app 을 특정 종류의 하드웨어 에서 실행해야하는 겨웅
  • 특정 노드를 선택하는 대신, k8s 에 특정 하드웨어 요구 가능

하드웨어 활용도 높이기

• k8s 에 app 실행 지시 -> app 의 리소스 요구 사항에 대한 description 과 각 노드에서 사용가능한 리소스에 따라 app 실행에 가장 적합한 노드 선택 가능
• app 은 클러스터간 자유로운 이동 가능
• 클러스터에서 실행되는 다른 app 구성 요소를 혼합해 클러스터 노드에 배치 가능k
• k8s 에 app 구성요소, 배포할 서버 노드의 최적의 조합을 찾아줌

상태 확인과 자가 치유

• 서버 장애시, 클러스터간에 app 이동 가능한 시스템 필요
• 클러스터 크기가 증가하면, 컴퓨터 구성 요소의 고장을 더 자주 처리하게 된다.
• 노드 장애 발생시, 자동으로 app 을 다른 노드로 스케줄링
  • 수동으로 migration 할 필요 없다.
  • app 재배치 x -> 즉시 노드 자체를 수정 -> 사용 가능한 하드웨어 리소스 풀에 반환 집중

오토 스케일링

• 급격한 부하 급증에 대응하기 위해 개별 app 의 부하 지속적인 모니터링이 필요 없다
• K8s 는 각 app 에서 사용하는 리소스를 모니터링 -> app 에 실행중인 인스턴스 수를 지속적 지시 가능하다.

애플리케이션 개발 단순화

• 개발과 프로덕션 환경이 동일하다.
• 일반적으로 구현해야하는 기능 구현 필요 없다.
• app 의 지속적인 전달을 가속화한다.