WHat is kubernetes?

History.back()

전통 배포 시대

가상화 배포 시대

컨테이너 개발 시대

리소스 활용도가 떨어짐

물리 서버의 한계

VM간 애플리케이션

격리 가능

하드웨어 비용 절감

추가/업데이트 쉬워짐

애플리케이션

생성 배포 자유로움

CI/CD

이식성 및 추상화

수준 상승

점차 물리적 하드웨어의 필요성 제거

VM vs Container

Container

간편한 사용법

속도

도커 허브 생태계

모듈성(modularity)

확장성(scalability)

그리고 고래가 귀여움

컨테이너 자체는 새로운 기술이 아님

하지만 도커가 인기를 끌 수 있었던 이유는?

  이런 절차로 도커는🔥핫한🔥 기술이 되었다 

그러나...

서버 확장과 트래픽 분산을 어떻게 할까?

장애가 발생하면? 컨테이너가 깨지면?

관리자가 들어가서 살려야하나?

이를 관리해주는 도구가

컨테이너 오케스트레이션

• 쿠버네티스는 다양한 컨테이너 오케스트레이션 도구 중 하나
• 수많은 컨테이너를 연동시키고 운영 자동화를 위해 구글이 개발
• 사실상 표준 확보

쿠버네티스란 명칭은 키잡이(helmsman)이나 파일럿을 뜻하는 그리스어에서 유래

Kubenetes의 역할

도커 컴포즈/스택/스웜의 기능을 통합해

더 높은 수준의 관리 기능 제공

- 인텔리전트 스케쥴링

- 노드 리소스 상태에 따라 컨테이너 배치

- 장애 발생시 복구

- 부하 확장

- 파일관리 MSA를 위한 서비스디스커버리 기능

- 트래픽 로드밸런싱기능

- 이미지 배포

- rollout, rollback 등...

도커 클라우드

GCP외에 아마존, 마소 등에서도

GCS, AWS 등 대부분의 클라우드 서비스에서 지원

설치 & 실행

• 명령행 도구인 kubectl 설치
• 웹에서 볼 수 있는 대시보드 서버

resource

• 쿠버네티스 리소스
  • 노드, 네임스페이스, 파드
• 컨테이너와 리소스는 다른 것
• 쿠버네티스 클러스터 안에서 이 리소스들이 연동하고 협조하며 시스템 구성
• 다양한 것들 있는데 하나씩 보자

cluster & Node

• 노드: 리소스 중 가장 큰 개념
  • 관리 대상으로 등록된 도커 호스트로, 컨테이너가 배치되는 대상
  • 클러스터 전체 관리 서버인 마스터가 적어도 하나 이상 필요
  • 노드 그룹 구성 (그림)
• 클러스터의 처리 능력은 노드에 의해 결정됨

쿠버네티스 클러스터란

여러 리소스를 관리하기 위한 집합체

node 실습

namespace

• 클러스터 안에 가상 클러스터를 또 다시 만들 수 있는데, 이를 네임스페이스라고 함
• 처음 구축시 기본 4개의 클러스터가 존재
• 네임스페이스는 팀이 일정 규모 이상일 때 유용

pod

• 컨테이너가 모인 집합체의 단위로 적어도 하나 이상의 컨테이너로 이루어짐
• 쿠버네티스와 도커를 같이 사용시 파드는 컨테이너 하나, 혹은 컨테이너의 집합체
• 하나 이상의 컨테이너로 구축하는 예시:
  • Nginx컨테이너 ←서로강한결합→ Go 컨테이너
  • 이런 강한 결합의 컨테이너는 파드로 묶어 일괄 배포
  • 혹은 컨테이너가 하나인 경우에도 파드로 배포

• 노드에 파드 배치하기
  • 한 노드에 여러 개를 배치할 수도 있고, 같은 파드를 여러 노드에 배치할 수도 있다.
  • 그러나 한 파드 안의 컨테이너는 모두 같은 노드에 배치해야 함
  • 파드 하나가 여러 노드에 걸쳐서 배치 불가

• 파드의 적절한 크기는?
  • "파드 전체가 한 노드에 배치돼야 한다"
    • 가령 Nginx와 그 뒤에 배치될 애플리케이션 컨테이너를 하나의 파드로 묶는다
    • 같이 배포해야 정합성을 유지하는 경우

• 도커 스웜과의 차이:
  • 스웜: 매니저 노드가 클러스터 전체 제어
  • 쿠버네티스: 마스터가 클러스터 제어 담당
    • 마스터는 관리용 컴포넌트가 담긴 파드만 배포된 노드로, 애플리케이션 파드는 배포 불가

파드 생성 및 배포

• 파드 실습
• 파드 다루기
  • 파드 상태 확인
  • 컨테이너 내부로 접근
  • 로그 출력
  • 파드 삭제
  • 메니페스트로 삭제

replica set

• 파드를 정의한 매니페스트로는 파드 하나만 생성 가능
• 규모있는 애플리케이션 구축을 위해 같은 파드 여러개 실행하여 가용성 확보 필요
• 이때 사용하는 것이 레플리카 세트로, 똑같은 정의를 갖는 파드를 여러 개 생성하고 관리하는 리소스
• 파드 정의도 레플리카 세트를 정의한 yaml에 작성 가능

레플리카 작성 실습

deployment

• 디플로이먼트: 레플리카세트보다 상위의 리소스로 배포의 기본 단위가 됨
• 디플로이먼트
  • 레플리카세트
    • 파드
    • 파드
    • 파드

디플로이먼트 정의 파일 작성 실습

• 레플리카세트 정의와 크게 다르지 않고 차이점은 디플로이먼트가 레플리카세트의 리비전 관리 가능하다는 것
• 쿠버네티스는 디플로이먼트 단위로 애플리케이션을 배포함
  • 실제 운영시 레플리카세트를 직접 다루기보다는 디플로이먼트 메니페스트로 관리가 대부분
  • 지정개수만큼 파드확보, 파드 새로운버전으로 교체, 이전 버전 롤백 등의 역할
  • 디플로이먼트 안에서 레플리카 세트가 어떻게 동작하는지 알아야함
    • 디플로이먼트 수정 → 레플리카세트 새로 생성되고 기존 것과 교체됨
    • 언제 새로 생성될까?
      • 파드 개수만 수정시 → 생성 안됨
      • 컨테이너 정의 수정 (이미지수정시) → 새로 생성됨

롤백

• 디플로이먼트에는 리비전 번호로 관리됨
• undo하면 직전 리비전으로 롤백 가능