[Docker] 6.컨테이너 오케스트레이션과 쿠버네티스

"15단계로 배우는 도커와 쿠버네티스"를 참조하여 작성하였습니다.

 

<컨테이너의 한계>

• 배포의 문제점

     - 모든 서버에 직접 접속해서 docker stop,run 실행 

     - 도커 컨테이너 실행에 필요한 리소스 관리 필요

     - 새롭게 배포된 애플리케이션 장애 시 신속하게 대처하기 어려움(새로운 이미지를 계속해서 만들기 때문 )

 

 

• 서비스 접근 및 노출의 문제점

    - 네트워크 문제

       -내부 네트워크에서 접속하는 경우에 외부로부터의 액세스를 막는다.

 

• 서비스 장애, 부하 모니터링(자원이 많으면 옮겨줘야하는 관리를 해줘야한다)의 문제점

 

<컨테이너 오케스트레이션>

Container Orchestration

: 복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구

-서버가 많아지면 컨테이너가 많아지기 때문에 한번에 관리하고 자동화해준다.

-기존에 구글의 Borg라는 컨테이너 툴을 오픈소스화한 것이다. 

 

• 기능

-cluster 

     -중앙제어 : 기존에서 서버마다 처리를 해야하는데 중앙제어 기능을 제공(master가 전체를 관리

     -네트워킹 : 노드마다 접근하기 쉽게 IP주소나 호스팅 주소를 세팅해야하는데 자동으로 세팅을 해준다.

     -노드 스케일

 

-state

   -상태 관리 : 복제본을 만들어 문제가 생기면 자동으로 복제본이 유지되게 한다.(복제본의 상태를 관리함으로써)

 

-scheduling

   -배포 관리 : 애플리케이션을 실행시킬 위치를 정해준다

 

 

-ROLLOUT,ROLLBACK : 최신버전으로,예전 버전으로

   -배포 버전 관리

 

-Service discovery

    -서비스 등록 및 조회 : 부하가 심해지면 웹에 분산해야하기 때문에 IP주소를 저장해야하는데 자동으로 저장함

 

-Volume

  -볼륨 스토리지

 

<쿠버네티스>

쿠버네티스의 개요

• 컨테이너 오케스트레이션의 업계 표준

- 배포 계획에 맞춰 신속한 애플리케이션 배포 가능

- 가동 중인 애플리케이션을 스케일 아웃/인할 수 있음(스케일 아웃은 컨테이너 수 증가,스케일 인은 감소)

- 새로운 버전의 애플리케이션 무정지 업그레이드 가능

- 하드웨어 가동률을 높여 자원 낭비를 줄임(몰아서 스케쥴링을 할 수 있기 때문에)

 

Scale-out vs Scale-up
  - 수평적 확장 vs 수직적 확장
       스케일 아웃은 개수가 많아진다.->하나하나의 성능이 좋을 필요는 없다.
       스케일 업은 성능이 좋아진다.->ex)저장장치를 ssd로 업그레이드 한다.

   

쿠버네티스의 발음과 로고

• 쿠버네티스 or K8s(케이에이츠라고 읽음)

    - 그리스어로 조타수, 캡틴 등의 의미

 

쿠버네티스의 특징

• 다양한 환경에서 쿠버네티스 사용 가능

    - 퍼블릭, 프라이빗,멀티,하이브리드 클라우드,온프레미스 위에 구축 가능

    - 쿠버네티느는 일관된 인터페이스를 제공하여 인프라의 복잡성을 감춰줌

 

• 높은 유연성과 확장성

    - 마이크로서비스 애플리케이션에 최적화된 실행 환경

    - 느슨한 결합에 의한 유연성, 교체 용이성

    - 다양한 스펙의 서버가 혼재(Heterogeneous)하는 클러스터 구성 가능

    - 서버의 정지, 추가, 제거가 용이

    - 저장소나 로드밸런서의 동적 프로비저닝

    - 퍼블릭 클라우드 API와 연동 가능(AWS,Azure에서 쿠버네티스를 지원하고 있다.)

 

• 고가용성과 성능관리

   - 서버 정지 시 애플리케이션 재배포 자동화

   - 애플리케이션의 이상 종료 시 자동 재기동

   - 필요한 인스턴스의 개수를 유지

   - 높은 부하(요청이 많이 들어옴)에서 자동 스케일->스케일 아웃

 

• 서버의 종류

    - 두 종류의 서버들로 구성

       -마스터 (마스터 노드):  클러스터 관리를 담당(중앙 관리)

       -노드 (워킹 노드) : 컨테이너화된 애플리케이션을 실행

    -->개발자/운영자가 마스터에게 보내고 마스터가 제어및 모니터링을 한다.

 

• 계층 구조

    - 마스터의 역할

      - 파드 단위로 스케줄링 및 삭제

      - 파드의 컨트롤러 기능과 외부 리소스 관리

베어메탈은 물리적 서버를 의미

 

• 컨테이너

    -컨테이너만을 독자적으로 실행하는 것은 불가능

    -반드시 파드 내에서 실행해야 함

    -

 

• 파드

     -컨테이너를 실행하는 최소 단위

     -한 개 혹은 여러 개의 컨테이너를 담을 수 있음

     -하나의 파드에 속하는 모든 컨테이너들은 같은 노드에서 동작

-->pod는 콩이 들어있는 꼬투리이다. 꼬투리=파드,콩=컨테이너

 

• 파드의 특징

    -컨테이너 재사용 촉진을 위한 플랫폼

       -파드 내부 컨테이너들을 파드의 IP주소와 포트번호 공유

       -파드 내부 컨테이너들은 localhost로 서로 통신 가능

       -파드 내부 컨테이너들은 system v 프로세스 통신이나 POSIX 공유 메모리를 사용하여 서로 통신 가능

-파드는 일시적인 존재

    -파드 내의 컨테이너는 이미지로부터 매번 생성(같은 오브젝트 이름으로 파드를 기동해도 이미지의 초기 상태에서 시작)

    -파드의 IP 주소도 고정적이지 않음->파드 종료 시 IP 회수

    -파드에 요청을 보내고 싶은 경우에서 서비스를 사용해야 함.(IP 주소가 바뀌기 때문)

 

-파드는 컨테이너의 실해 상태를 관리

     -파드가 정지한 경우는 담당 컨트롤러가 재기동->master에서 처리

     -파드 내부의 컨테이너가 정지한 경우는 파드가 해당 컨테이너를 재시작->node안에 pod 처리

     -활성 프로브(활성 상태인지 체크)와 준비 상태 프로브를 설정하여 내부 애플리케이션의 상태를 감시할 수 있음

활성 프로브:애플리케이션이 멈춰있는 것을 감지

-파드는 초기화 전용 컨테이너를 실행

     -초기화 담당 컨테이너가 제일 먼저 실행->실행 끝나면, 핵심 기능을 수행하는 컨테이너들이 실행

 

 

 

• 서비스

    -파드와 클라이언트를 연결하는 역할을 수행

    -대표 IP 주소로의 요청 트래픽을 지정된 파드들에 부하분산하며 전송하는 역할도 수행(로드밸런서)

 

 

 

• 컨트롤러

     -파드의 실행을 제어하는 오브젝트

     -여러 종류의 컨트롤러가 있어 각 컨트롤러의 기능을 이해하고 목적에 맞게 적절히 구별해서 사용

     -컨트롤러의 종류 :디플로이먼트(서버가 지정하는 숫자보다 파드가 적은데 모),레플리카셋,레플리케이션 컨트롤러,크론잡(정기적으로 실행하도록 설정가능),데몬셋

     -워크로드 타입 : 프론트엔드 처리(짧은 시간),백엔드 서비스(일정한 응답을 보장해야),처리 시간이 긴 배치 처리,정기 실행 작업

    -클러스터의 시스템 기능 :노드에서 이상이 발생했을 때 자동으로 해결함

 

 

• 구성요소

     -kubet 

     -kube-apiserver

          -REST 요청(GET,PUT)을 검증

     -kube-scheduler

          -새로 생성된 모든 파드에 대해 실행할 최적의 노드 선택

          -

    -kube-controller

         -컨트롤러를 

    -etcd

        -k8s 클러스터의 모든 관리 데이터를 저장(KU-store라고 생각하면 됨)

 

노드 )

    -kubelet

       -파드와 컨테이너의 실행

       -파드와 노드의 상태를 API 서버에 보고(모니터링)

       -컨테이너의 동작을 확인하는 프로브 실행

       -내장된 cAvisor를 통해 메트릭(수치) 수집 및 공개

 

-kube-proxy

   -각 노드에서 동작하며 로드밸런싱 기능을 제공