공부기록/클라우드

쿠버네티스 인 액션 - 1장 쿠버네티스 소개

DGL 2022. 2. 20. 19:16

쿠버네티스는 서버 배포를 자동으로 스케줄링하고 구성, 관리, 장애 처리를 포함하는 자동화에 대한 요구로 개발되었다.

대규모의 클라우드 환경에서 실행되는 서비스들을 추상화 시킬 수 있다.

쿠버네티스가 필요한 이유

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

마이크로 서비스 배포의 어려움: 배포 조합의 수뿐만 아니라 구성 요소 간의 상호 종속성 수가 훨씬 더 많아지므로 배포 관련 결정이 점점 어려워진다. 실행호출을 디버그하고 추적하기 어렵다.(msa간 로그로 해결한다.)

서비스간의 라이브러리 버전 차이에서 오는 관리의 어려움 → 쿠버네티스가 관리해준다.

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

운영체제, 라이브러리, 시스템 구성, 네트워킹 환경, 기타 모든 것이 동일한 환경을 만들 수 있다면 이상적일 것이다.

지속적인 배포로 전환

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

컨테이너 기술

  • 리눅스 컨테이너 → 같은 운영체제로 여러개의 서비스를 실행, 서로 다른 환경을 만들어준다.
  • 가상머신과 유사하게 서로 격리하지만 오버헤드가 훨씬 적다

컨테이너와 가상머신 비교

  • 컨테이너가 훨씬 더 가벼워서 많은 수의 소프트웨어 구성 요소를 실행할 수 있다.
  • 가상머신은 시스템 프로세스를 실행해야 하기 때문에 추가 컴퓨팅 리소스가 필요하다.

가상머신은 게스트 OS 커널에 대한 시스템 콜을 수행할 수도 있음( 가상머신 종류에 따라)

컨테이너는 호스트 OS에서 실행되는 동일한 커널에서 시스템 콜을 수행한다.

가상머신: 물리적CPU → 하이퍼바이저 → 가상CPU → 커널 → 앱

컨테이너: 물리적CPU → 커널 → 컨테이너의 앱

격리를 가능케 하는 메커니즘

리눅스 네임스페이스로 각 프로세스가 시스템에 대한 독립된 뷰만 볼 수 있도록 한다.

리눅스 컨트롤 그룹 → 프로세스가 사용할 수 있는 리소스의 양을 제한한다.

  • 리눅스 네이스페이스로 프로세스 격리
    • mnt, pid, net, ipc, uts, user
    • 두 프로세스를 마치 두 개의 다른 시스템에서 실행 중인 것처럼 보이게 할 수 있다.
  • 프로세스의 가용 리소스 제한

도커 컨테이너 플랫폼

패키징 과정을 단순화했다.

컨테이너 이미지가 여러 이미지에서 공유되고 재사용될 수 있는 레이어로 구성돼 있다는 것.

도커의 세가지 주요개념

  • 이미지: 애플리케이션과 해당 환경을 패키지화한 것.
  • 레지스트리: 이미지를 쉽게 공유할 수 있는 저장소
  • 컨테이너: 이미지에서 생성된 리눅스 컨테이너

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

개발자는 이미지를 만든 후, 레지스트리로 푸시한다. 레지스트리에 접속할 수 있는 모든 사사람이 해당 이미지를 사용할 수 있다.

컨테이너의 제약

  • 운영체제의 커널을 사용하기 때문에 다른버전의 커널에 종속성이 있는 애플리케이션을 사용하기 어렵다. 가상머신은 독립적인 커널을 사용하므로, 그런 제약에서 벗어난다.

쿠버네티스 소개

  • 구글은 전 세계에서 소프트웨어 구성 요소와 인프라를 훨씬 더 잘 배치하고 관리하는 방법이 필요하다는 것을 깨달은 최초의 회사일 것이다.

컨테이너화된 애플리케이션을 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템.

마스터 노드와 여러 워커 노드로 구성된다. 특정 애플리케이션이 함께 실행되도록 지정할 수도 있으며 쿠버네티스는 여러 애플리케이션을 동일한 워커 노드에 배포한다.

개발자가 애플리케이션 핵심 기능에 집중할 수 있도록 지원 - 개발자가 인프라 관련 서비스를 애플리케이션에 구현하지 않아도 된다. (서비스 디스커버리, 스케일링, 로드 밸런싱, 자가 치유, 리더 선출)

운영 팀이 효과적으로 리소스를 활용할 수 있도록 지원 - 리소스를 수동 스케줄링보다 훨씬 더 잘 활용할 수 있다.

쿠버네티스 클러스터 아키텍처

  • 마스터 노드는 전체 쿠버네티스 시스템을 제어하고 고나리하는 쿠버네티스 컨트롤 플레인을 실행한다.
  • 워커 노드는 실제 배포되는 컨테이너 애플리케이션을 실행한다.
  • 컨트롤 플레인은 클러스터를 제어하고 작동시킨다.
    • 쿠버네티스 api 서버는 사용자, 컨트롤 플레인 구성 요소와 통신한다.
    • 스케줄러는 애플리케이션의 배포를 담당한다
    • 컨트롤 매니저는 구성 요소 복제본, 워커 노드 추적, 노드 장애 처리 등과 같은 클러스터단의 기능을 수행한다.
    • Etcd는 클러스터 구성을 지속적으로 저장하는 신뢰할 수 있는 분산 데이터 저장소다.

컨트롤 플레인의 구성 요소는 클러스터 상태를 유지하고 제어하지만 애플리케이션을 실행하는 것은 노드에 의해 이루어진다.

노드

  • 컨테이너를 실행하는 도커 또는 다른 컨테이너 런타임
  • API 서버와 통신하고 노드의 컨테이너를 관리하는 Kubelet
  • 애플리케이션 구성 요소 간에 네트워크 트래픽을 로드밸런싱하는 쿠버네티스 서비스 프록시

쿠버네티스 애플리케이션 실행

  • 실행된 컨테이너 유지

배포 상태가 사용자가 제공한 디스크립션과 일치하는지 지속적으로 확인한다. 다섯 개의 인스턴스를 실행하기로 했으면, 쿠버네티스가 지속적으로 확인하여, 중단되거나 응답이 중지될 때, 인스턴스가 제대로 작동하지 않으면, 쿠버네티스가 자동으로 다시 시작한다.

  • 복제본 수 스케일링

최적의 복제본 수를 결정하는 작업을 쿠버네티스에 맡길 수도 있다.

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

kube-proxy부터 접근하기 때문에, 서비스 연결이 로드밸런싱 되게 해준다.

쿠버네티스 사용의 장점

운영 팀이 애플리케이션 배포를 처리할 필요가 없다.

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

하드웨어 활용도 높이기 - 인프라와 애플리케이션 분리, 각 노드에서 사용가능한 리소스에 따라 애플리케이션을 실행할 가장 적합한 노드를 선택할 수 있다.

상태확인과 자가 치유 - 서버 장애 발생 시 언제든지 클러스터 간에 애플리케이션을 이동할 수 있는 시스템

오토스케일링 - 부하에 따라 전체 클러스터 크기를 자동으로 확장하거나 축소

애플리케이션 개발 단순화 - 리더 선정과 같은 복잡한 알고리즘을 대신 처리해줌, 새로운 버전이 잘못됐는지 자동으로 감지하여 즉시 롤아웃을 중지한다.