Docker와 쿠버네티스

• 서버에 관한 이야기를 할 때, Docker나 이미지, 컨테이너에 대해 이야기하는 경우가 있다.
• CI/CD를 담당하지 않는다면, Docker가 무엇인지에 대해서는 모른 채 그냥 'Docker'라는 것을 쓰는구나 라고 넘어갈 경우가 많다.
• 이 글에서는 Docker의 설치나 활용은 배제하고, 단순히 Docker가 뭘 하는 도구인지에 대해 정리하고자 한다.

1. 배포 환경의 변천사

전통적 배포(Traditional Deployment)

• 전통적 배포는 하나의 컴퓨터에 하나의 OS를 설치하고, 여러가지 프로그램을 구동하는 전통적인 방식이다.
• 현재 일반적으로 컴퓨터를 이용하는 방식과 큰 차이가 없다.
• 하지만 이런 식으로 배포를 진행할 경우, 여러 프로그램을 설치하여 컴퓨터의 성능이 떨어지거나 프로그램들이 서로 충돌하게 되는 문제점이 발생한다.
• 이러한 문제를 해결하기 위해 나온 배포 방식이 가상화 배포(Virtualized Deployment) 방식이다.

가상화 배포(Virtualized Deployment)

• 여기서는 가상 머신(Virtual Machine)이라는 새로운 개념을 사용한다.
• 중간에 위치한 하이퍼바이저가 하나의 시스템에서 여러 가상 컴퓨터를 구동할 수 있도록 중간 계층의 역할을 해 준다.
• App은 실행하고자 하는 프로그램, Bin/Library는 프로그램이 실행하는 데 필요한 환경과 관련된 파일이다.
• 가상 머신을 사용하면서 프로그램들이 서로 간섭하는 것을 방지할 수 있다.
• 또한 각각 CPU, 메모리, 저장 장치등을 개별적으로 할당할 수 있으므로 좀 더 무거운 프로그램에는 더 높은 사양을 할당할 수 있다는 장점이 있다.
• 하지만 가상머신 하나하나에 일일이 운영체제를 설치해야 하기 때문에 후술할 컨테이너 중심 배포보다는 무거운 편이다.

컨테이너 중심 배포(Container Deployment)

• 컨테이너 중심의 배포에서 '하이퍼바이저'라는 부분이 '컨테이너 런타임'으로 대체되고, '가상머신' 부분은 '컨테이너'로 대체된다.
• 컨테이너란, 다양한 프로그램과 다양한 운영체제 및 실행환경 등을 추상화하여 동일한 인터페이스를 제공하여 배포 및 관리를 단순화시켜주는 것이다.
• 컨테이너는 하나의 OS를 공유하며, 컨테이너 아래에서 일어나는 일에는 관심을 두지 않는다.
• 즉 한 컨테이너에서 일어나는 문제는 다른 컨테이너에서 구동되는 프로그램에 아무런 영향을 주지 않는다.
• 각각의 컨테이너에서 구동되는 프로그램들은 서로의 간섭 없이 독립적으로 실행될 수 있다.

2. 도커의 사용 이유

• 서버를 운영할 때에는, 같은 내용을 구성했더라도 오류가 발생하는 경우가 있다.
• 예를 들면 A서버와 B서버가 있는데, A서버는 지난 달에 서버를 구성하며 이미지매직을 설치했고, B 서버는 지금 막 이미지매직을 설치했다.
• 그리고 웹 서비스를 업데이트하여 각 서버에 배포했을 때, A 서버에만 장애가 발생했다. 해당 원인은
  • 웹 서비스에서 이미지매직 최신 버전에 새로 추가된 기능을 사용했다.
  • 웹 서비스의 업데이트 부분 코드에 버그가 있다.
  • 이미지매직의 버전이 다르다.
  • 이미지매직이 의존하는 라이브러리의 버전이 다르다.
• 정도가 있을 것이다.
• 이렇게 서버 별로 사소한 부분에서의 차이가 발생하는데, 이런 차이들로 인해서 다른 서버를 유지보수하는 것은 쉬운 일이 아니다.

• 도커에서 사용하는 도커파일은 위의 서버 운영 기록을 코드화한 것이다.

# Nginx 서버를 구성하는 도커 파일
FROM debian:stretch-slim

RUN apt-get update \
    && apt-get install -y \
    imagemagick  

• 이 도커 파일로 도커 이미지를 만들 수 있다. 도커 파일이 서버 운영 기록이라면, 도커 이미지는 운영 기록을 실행할 시점이다.
• 이전의 방식으로 서버를 실행했을 경우, 설치된 시점에서의 차이가 발생하지만 도커의 경우 1년 전과 오늘 각각 이미지를 실행해도 동일한 결과가 발생한다.

• 즉 도커는 작업자가 이미지의 시점을 미리 정해둘 수 있기 때문에, 서버를 항상 똑같은 상태로 유지할 수 있다.

3. 쿠버네티스란?

• 쿠버네티스는 컨테이너를 오케스트레이션 하는 도구를 뜻한다.
  • 일반적으로 애플리케이션은 의도에 따라 애플리케이션이 실행되게 하기 위해 네트워킹 수준에서 정리가 필요한 개별적으로 컨테이너화된 구성요소로 구성된다. (주로 마이크로 서비스)
  • 이런 식으로 다수의 컨테이너를 정리하는 프로세스를 컨테이너 오케스트레이션이라고 한다.

쿠버네티스의 기능

1. 서비스 디스커버리와 로드 밸런싱

   • 서비스 클라이언트가 서비스를 호출할 때 서비스의 위치 (즉 IP주소와 포트)를 알아낼 수 있는 기능이 필요한데, 이를 서비스 디스커버리라 한다.
   • 쿠버네티스는 별도의 DNS(Domain Name System) 구성 없이 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다.
   • 트래픽이 많아지면 쿠버네티스는 자동으로 네트워크 트래픽을 로드밸런싱하여 배포가 안정적으로 이루어질 수 있도록 한다.

2. 스토리지 오케스트레이션

   • 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 등 원하는 저장소 시스템을 자동으로 탑재할 수 있다.

3. 자동화된 롤아웃과 롤백

   • 배포된 컨테이너의 원하는 상태를 서술할 수 있으며, 상태를 원하는 상태로 설정된 속도에 따라 변경할 수 있다.
   • 장애 시 애플리케이션의 롤백도 지원한다.

4. 자동화된 빈 패킹(bin packing)

   • 컨테이너화된 작업을 실행하는 데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다.
   • 각 컨테이너가 필요로 하는 CPU와 메모리를 쿠버네티스에 지시하면, 쿠버네티스는 컨테이너를 노드에 맞추어 리소스를 가장 잘 사용할 수 있도록 해 준다.

5. 시크릿(secret)과 구성(config) 관리

   • 시크릿과 애플리케이션 구성을 안전하게 배포하고 업데이트 할 수 있다.
   • 시크릿된 정보들은 암호화되어 저장된다.

6. 자가 치유

   • 오류가 발생하거나 노드가 죽었다면, 컨테이너를 재시작하고 다시 스케쥴링 해준다.
   • 즉 사용자가 정의한 상태에 따라 서비스를 준비하고 제공한다.

7. 배치 실행

   • 배치(Batch, 실시간으로 처리하는 것이 아니라 일괄적으로 모아서 한 번에 처리하는 것) 단위 작업을 실행할 수 있도록 하며, 주기적인 배치 작업도 실시할 수 있다.

8. 오토 스케일링

   • 자동으로 애플리케이션의 스케일을 넓히거나 줄일 수 있다.

쿠버네티스의 핵심 컨셉

• 쿠버네티스에서는 명령형 인터페이스가 아니라 선언형 인터페이스를 사용한다.

  • 어떤 동작을 지시하는 것이 아니라 원하는 상태를 선언하는 것
  • 이러한 방식을 "쿠버네티스 네이티브"하다고도 한다.
  • ex) 교실의 습도가 60%로 유지되었으면 좋겠다.

• 쿠버네티스는 이렇게 선언된 상태와 현재 상태가 일치하는지를 지속적으로 체크하며, 해당 상태를 유지하도록 필요한 조치를 취한다.

• 쿠버네티스의 모든 것은 Objects와 Controller를 중심으로 돌아간다.

• 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다.

• 쿠버네티스의 오브젝트는 하나의 "의도를 담은 레코드"이며, 오브젝트를 생성함으로써 클러스터를 어떤 상태로 유지하고 싶은지를 쿠버네티스 시스템에 전달할 수 있다.

• 주요 오브젝트로는 Pod, ReplicaSet, Deployments, Service, Volume 등이 있다.

  • Pod : 쿠버네티스에서 배포할 수 있는 가장 작은 단위로, 한 개 이상의 컨테이너와 스토리지, 네트워크 속성을 가진다. Pod에 속한 컨테이너는 스토리지와 네트워크를 공유하고, 서로 localhost로 접근할 수 있다.
  • ReplicaSet : Pod를 한 개 이상 복제하여 관리하는 오브젝트이다. ReplicaSet은 복제할 개수, 개수를 체크할 라벨 선택자, 생성할 Pod의 설정값 등을 가지고 있다. 이를 직접적으로 사용하기보다는 Deployments 등 다른 오브젝트에 의해 사용되는 경우가 많다.
  • Service : 네트워크와 관련된 오브젝트로, Pod를 외부 네트워크와 연결해주고, 여러 개의 Pod를 바라보는 내부 로드밸런스를 생설할 때 사용한다. 내부 DNS에 서비스 이름을 도메인으로 등록하기 때문에 서비스 디스커버리 역할도 한다.
  • Volume : 저장소와 관련된 오브젝트. 호스트 디렉토리를 그대로 이용하거나 클라우드 스토리지를 동적으로 생성하여 사용할 수 있다.

• 오브젝트에 대한 명세는 주로 YAML로 정의한다.

  • 오브젝트의 종류와 원하는 상태를 입력한다.
  • 이러한 명세는 생성, 조회, 삭제로 관리할 수 있기 때문에 REST API를 통해 쉽게 노출하고 컨트롤할 수 있다.

출처

• https://velog.io/@yunuchoiii/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C-%EB%8F%84%EC%BB%A4%EC%99%80-%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EC%9D%98-%EC%B0%A8%EC%9D%B4

• https://dev-youngjun.tistory.com/2

• https://www.44bits.io/ko/post/why-should-i-use-docker-container

• https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/