컨테이너 오케스트레이션

T아카데미 - 컨테이너 오케스트레이션 쿠버네티스 살펴보기

---

도커가 등장하기 전 서버 운영

  1. 자체 서버 운영
      - 서버주문 , 서버 설치, cpu 메모리 하드 조립 네트워크 연결, OS설치, 계정설정, 방화벽 설정
      - 서버를 설정하기 위해 많은 노력과 시간이 필요함
      - 성능이 좋은 걸 미리 구매하고 효율적인 사용을 위해 여러 애플리케이션을 설치

      - 단계를 지날 때 마다 명령어를 이용함 ex)  cp, mv, rm
      - ruby 버전을 변경 하게 되면 이후 모든 상태에 영향이 감 (위험)
      - 특정 시점의 서버 상태를 누가 언제 어떻게 작업했는지 알기 어려움
      - 서버관리자 = 문제 생기면 다 해결 = 변화를 싫어함 = 확장이 어려움 = 혁신이 어려움

  2. 재현 가능한 상태 관리
      - Configuration Management
          * 명령어를 통한 서버 관리를 지양
          * 상태를 관리하는 코드를 이용하여 서버 관리 (설정 파일)
          * 선언적 서버 상태 정의
          * 서버의 상태가 재현 가능해짐
          * 서버 운영의 협업이 가능해짐 (소스관리, 코드리뷰)
      - Ansible

  3. 가상 머신의 등장
      - 하나의 서버에 여러개의 가상 서버를 설치할 수 있음
      - 다양한 버전의 java 여러개의 데이터베이스를 쉽게 사용
      - 서버의 상태를 이미지로 저장할 수 있음
      - 새로운 서버를 만들고 기존 서버의 내용을 복사할 수 있음

      - immutable 변하지 않는
          * 서버에 설치된 애플리케이션을 새로운 버전으로 업데이트 하면 mutable
          * 새로운 버전이 설치된 서버의 상태를 이미지로 만들고 교체하면 immutable
          * 기존 상태를 고려할 필요 없이 통째로 서버를 교체
          * 생각보다 어렵고 느리고 특정 회사 제품을 써야 함

  4. 클라우드
      - AWS, Google Cloud, Azura
      - 하드웨어 파편화 문제 해결
      - 가상화된 환경만으로 아키텍처 구성이 가능해짐
      - 이미지를 기반으로한 다수의 서버 상태관리
          * 상태관리에 대한 새로운 접근
          * 서버 운영의 문제는 여전히 남아있음
      - 마치 전기를 사용하는듯 편리함
      - 단점
          * (보통) 어떻게 만들었는지 모름
          * (보통) 처음부터 다시 만들 수 없음
          * 관리가 어려움 / 결과만 스냅샷을 찍기에..

  5. PaaS (Platform as a service)
      - Heroku, Netlify, AWS Elastic Beanstail, Google Cloud App Engine
      - 서버를 운영하는 것은 복잡하고 어렵다
      - 소스 코드만으로 배포가 가능하다.
      - 일반화된 프로비저닝 방법을 제공
      - 프로비저닝 과정에 개입 불가
      - 단점
          * 애플리케이션을 PaaS 방식에 맞게 작성해야함
          * 자바 버전도 PaaS가 제공하는 버전을 따라야 함
          * 서버에 대한 원격 접속 시스템을 제공하지 않음 (로그 못봄)
          * 서버에 파일 시스템을 사용할 수 없음
          * site 패키지를 설치할 수 없음
          * 로그수집을 제한적인 방식으로만 하용
          * 배포에 대한 새로운 패러다임을 이해해야 함
      - PaaS에서 할 수 있을까?
          * 크론잡
          * 데이터 분석
          * 로그 분석
          * 애플리케이션 성능 모니터링
          * A/B 테스트, Canary 배포
          * 네트워크 , 스토리지 설정

 

도커의 등장

  1. 도커란?
      - 2013년 DocCloud 에서 첫 공개
      - 컨테이너 : 격리된 환경에서 작동하는 프로세스
      - 리눅스 커널의 여러 기술을 활용
      - 하드웨어 가상화 기술보다 가벼움
      - 이미지 단위로 프로세스 실행 환경을 구성
      - Vm은 os위에 os를 올려서 사용함 / 도커는 도커 엔진 위에 격리된 프로세스를 띄우므로 속도 빠름
      - 도커의  특징
          * 확장성 : 특정 회사나 서비스에 종속되지 않고 실행 가능, 개발서버 생성 간편
          * 표준성 : ruby nodejs go php 의 서비스 배포 방식이 제각각인데 docker run 방식 하나로 사용 가능
          * 이미지 : dockerfile 을 이용하여 이미지를 쉽게 빌드하며 hub로 쉽게 pull push 가능
          * 설정 : 환경변수로 쉽게 지정 가능
          * 자원 : 삭제 후 새로 만들 시 모든 데이터가 초기화됨
      - 도커가 가져온 변화
          * PaaS 와 같은 제한 없음
          * 클라우드 이미지보다 관리하기 쉬움
          * 다른 프로세스와 격리되어 가상머신처럼 사용하지만 성능저하가 없음
          * 복잡한 기술 namespace, cgroup 등을 몰라도 사용할 수 있음
          * 이미지 빌드 기록이 남음
          * 코드와 설정으로 관리 > 재현 및 수정 가능
          * 오픈소스 > 특정 회사 기술에 종속적이지 않음
      - 애플리케이션 업데이트를 위해 컨테이너를 교체하는 방식 사용 (앞단 Proxy)
      - 서비스 디스커버리
          * 서버들의 정보 (ip, port 등)을 포함한 다양한 정보를 저장하고 가져오고 값의 변화가 일어날 때, 이벤트를 받아 자동으로 서비스의 설정 정보를 수정하고 재시작하는 개념
              1. 새로운 서버가 추가되면 서버 정보를 key / value store에 추가 함
              2. key / value store는 디렉토리 형태로 값을 저장함. /services/web 하위를 읽으면 전체 web 서버 정보를 읽을 수 있음
              3. key / value store을 watch 하고 있던 configuration manager 가 값이 추가되었다는 이벤트를 받음
              4. 이벤트를 받으면 템플릿 파일을 기반으로 새로운 설정파일을 생성
              5. 새로운 설정 파일을 만들어 기존 파일을 대체하고 서비스 재시작

      - docker-gen
          * docker의 기본 기능을 적극 활용한 service discovery 도구
              - 도커 데몬이 가지고 있는 컨테이너의 정보를 그대로 이용
              - 컨테이너를 실행할 때 입력한 환경변수를 읽음
              - VIRTUAL_HOST=www.subicura.com 과 같이 환경변수를 지정하면 이를보고 nginx의 virtual host 설정 파일들을 구성함

 

컨테이너 오케스트레이션

  - 여러 대의 서버와 여러 개의 서비스를 편리하게 관리해주는 작업
  - 스케줄링
      * 컨테이너를 적당한 서버에 배표해주는 작업
      * 여러 대의 서버 중 가장 할일 없는 서버에 배포하거나 그냥 차례대로 배포 또는 랜덤하게 배포
      * 컨테이너 개수를 여러 개로 늘리면 적당히 나눠서 배포하고 서버가 죽으면 실행중이던 컨테이너를 다른서버에 띄워줌
  - 클러스터링
      * 여러 개의 서버를 하나의 서버처럼 사용함
      * 작게는 몇 개 안되는 서버부터 많게는 수천대의 서버를 하나의 클러스터로
      * 여기저기 흩어져 있는 컨테이너도 가상 네트워크를 이용하여 마치 같은 서버에 있는것처럼 쉽게 통신
  - 서비스 디스커버리
      * 서비스를 찾아주는 기능
      * 클러스터 환경에서 컨테이너는 어느 서버에 생성될지 알 수 없고 다른 서버로 이동할 수 있음
      * 따라서 컨테이너와 통신을 하기 위해서 어느 서버에서 실행중인지 알아야 하고 컨테이너가 생성되고 중지될 때 어딘가에 ip와 port 같은 정보를 업데이트 해주어야 함
      * 키 벨류 스토리지에 정보를 저장할 수 도 있고 내부 DNS 서버를 이용
  - 로깅, 모니터링
      * 여러 대의 서버를 관리하는 경우 로그와 서버 상태를 한곳에서 관리
      * ELK 와 prometheus 등 다양한 도구 사용
  - 컨테이너 오케스트레이션 도구
      * docker swarm
          - 호스트 os에 Agent만 설치하면 간단하게 작동하고 빠름
          - 단순한 구조에서 효과적임
      * kubernetes
          - 구글에서 개발한 컨테이너 배포 확장 운영 도구
          - 표준
          - 대규모에 적함
          - 다양한 생태계 구축되어 있음

  - 서비스 메시
      * 서비스마다 프록시를 모두 붙이고 서로간에 retry 함
      * 기능
          - 서비스 발견
          - 부하 분산
          - 경로 관리
          - 트래픽 관리
          - 운영 탄력성
          - 오류 주입
          - 로깅 / 모니터링
          - 분산 추적
          - 보안
          - 인증 , 인가

 

자체서버부터 컨테이너까지

  - 결론
      * 서버 생성을 쉽고 편리하게
      * 명령아가 아닌 코드와 설정을 사용
      * 격리된 환경을 이용하여 독립적인 실행환경 구성
      * immutable 하게 애플리케이션을 관리하고 스토리지 또는 로그를 분리하여 관리
      * 이미지를 쉽게 만들고 편리하게 사용
      * 로드 밸런서와 프록시 서버 등 자주 사용하는 기술을 쉽게 사용
      * 확장 가능한 설계

서비스 메시