Worker Node를 잠시 내루거나, 업데이트가 필요할 때

Node 내부의 Software를 업그레이드 해야하거나, 혹은 문제가 생겼을 경우에 해당 Node를 안전하게 내리고 다시 올려야 합니다.

그럼 문제가 되는 부분은 해당 Node에서 실행되고 있던 Pod들입니다. 만약 아무도 모르는 어떠한 오류로 인하여 Worker Node-1이 내려간다고 가정하였을 때, 사용자 입장에서 해당 Pod에 접속하다가 오류를 만나게 될 것입니다.

위의 그림에서처럼 만약 사용자가 파란색 Pod에 접속하여 서비스를 이용하고 있었을때, Worker Node-1번이 이유모를 오류로 내려갔다고 가정해봅시다.

그럼 사용자는 LoadBalancer와 같은 경로를 통해 Worker Node-2번에 배포되어 있는 파란색 Pod로 접속하면 다시 서비스가 가능합니다.

이렇게 ReplicaSet이 여러 개이고, 여러 Node에 흩어져 있는 경우는 문제가 되지 않습니다.

문제가 되는 경우는 아래와 같습니다.

1. 사용자가 초록색 Pod에 접속하다가 Worker Node-1번이 내려간 경우
2. 사용자가 빨간색 Pod에 접속하다가 Worker Node-3번이 내려간 경우

이런 경우에는 사용자는 기존에 이용하던 서비스를 이용할 수 없게 됩니다.

쿠버네티스는 어떻게 하고 있을까?

쿠버네티스는 Worker-Node가 다시 올라오길 기다립니다.

내려갔었던 Node가 바로 다시 돌아오면 사실 문제가 없습니다. 근데 이 '바로' 는 과연 몇 초, 몇 분일까요?

이건 kube-controller-manager 가 정할 수 있으며 default는 5분입니다.

해당 내용은 아래와 같은 명령어로 수정할 수 있습니다.

즉, node가 다운될때마다 master node는 5분동안 기다립니다. 해당 시간을 Pod Eviction Timeout이라고 합니다.

만약 Pod Eviction Timeout이 지난 후에 node가 돌아오면 node는 공백이 된 상태로 돌아오게 됩니다. (안에 아무 Pod가 없는 상태)

이렇게 되면 문제가 될 수 있기 때문에 명령어를 통해 미리 방지할 수 있게 도와줍니다.

drain , uncordon , cordon

drain - worker node에 있는 Pod들을 안전하게 다른 Node들로 이동

drain 명령어는 worker node에 있는 Pod들을 안전하게 다른 Node들로 이동시켜줍니다.

만약 node-1이 문제가 생길 것 같다던가 모든 Pod들을 옮기고 update를 진행해야 하는 경우에 아래와 같은 명령어를 사용합니다

그래서 모든 작업이 다른 Node로 이동할 수 있게 합니다.

즉, drain 명령어를 실행하면 해당 node-1에서 pod 들이 정상적으로 종료되고, 다른 Node에서 Node-1에서 실행되던 Pod들이 재현되게 됩니다ㅏ.

restriction을 끝내지 않는 이상 위의 명령어를 입력하게 되면 node-1에서는 scheduling에서 제외되어서 pod 일정을 잡을 수 없게 됩니다.

그럼 다시 node-1이 정상적으로 돌아오더라도 node-1은 scheduling에서 제외됩니다.

다시 node-1이 일을 하게 하려면 uncordon 이라는 명령어를 사용하여야 합니다.

uncordon - Worker Node Restriction 해제

위의 명령어를 사용하면 node-1이 다시 Pod Schedule이 가능하게 됩니다.

물론 그렇다고 해서 이동한 Pod들이 다시 돌아오는 것은 아닙니다. 다른 Node에서 Pod는 그대로 실행되고, 이후에 Pod가 삭제되거나 새로 생성될 때 Schedule 될 수 있습니다.

그럼 만약 Node-1에 있던 Pod들을 이동시키지 않고, 해당 Node-1이 더이상 Schedule하지 않도록 하려면 cordon 명령어를 사용합니다.

cordon - 기존 node에서 pod를 종료하거나 이동시키지 않고 싶을 때

cordon은 drain과 달리 기존 node에서 pod를 종료하거나 이동시키지 않습니다.

단순히 해당 node에 새 pod가 scheduling되지 않도록 하는 명령어 입니다.

도커

• 컨테이너를 실행하거나 컨테이너 이미지를 만들고 배포하는 플랫폼
• 도커는 응용 프로그램을 실행 환경 단위로 패키지화해서 컨테이너 이미지를 만듬
• 컨테이너 이미지는 컨테이너 레지스트리를 통해 개발 환경에서 배포 환경으로 배포

도커의 장점

• 프로그램 속도가 빠르고, 릴리스하는데 문제가 없음
• 응용 프로그램을 배포하기 쉽고 확장 가능

도커 엔진

• 컨테이너 및 컨테이너 이미지를 관리하는 응용 프로그램
• 클라이언트 서버 유형의 응용 프로그램(Client - Server)
• 클라이언트인 도커 클라이언트에서 서버인 도커 데몬의 API에 접속해 컨테이너 및 컨테이너 이미지에 대한 다양한 작업을 수행할 수 있다.
• 도커 클라리언트에서 도커 데몬 API에 접속하려면 도커 명령어를 실행해야 한다.

[도커 엔진을 구성하는 세가지 요소]

1. 도커 클라이언트

- 도커 데몬의 사용자 인터페이스가 되는 구성 요소다. 사용자는 도커 클라이언트를 조작해서 도커 데몬과 통신한다.

2. 도커 데몬

- 도커 클라이언트의 요청에 따라 도커 객체를 관리하는 구성 요소. 도커 클라이언트와 도커 데몬은 각각 클라이언트와 서버 역할을 하며, 도커 클라이언트의 요청에 따라 통신이 시작되고 도커 데몬의 응답으로 통신이 종료된다.

3. 컨테이너 레지스트리

- 컨테이너 이미지를 저장하기 위한 구성 요소. 도커 데몬은 도커 클라이언트의 요청에 따라 컨테이너 레지스트리와 통신해서 컨테이너 이미지를 내려받고 업로드한다.

도커 객체

- 도커 데몬의 관리 대상( 네트워크, 볼륨, 컨테이너, 컨테이너 이미지 등)

컨테이너 런타임

컨테이너를 다루는 도구

도커 엔진은 컨테이너 런타임을 포함하는 개념

도커

컨테이너 런타임 중에서 제일 유명한 것

컨테이너

• 운영 체제에서 실행되는 프로세스인데 다른 프로세스와 격리되어 있다(외부 영향을 받지 않는 독립적인 환경에서 프로세스를 실행할 수 있다.)
  • 컨테이너를 외부와 격리하기 위해 네임스페이스라는 구조를 사용한다.

파일 시스템의 격리

• 네임스페이스의 작동 방식을 구현하는 데 특히 중요한 것은 파일 시스템의 격리.
  • 파일 시스템 → 운영 체제의 기능 중 하나, 파일 시스템에 의해 데이터를 ‘파일’ 단위로 읽고 쓸 수 있다
• 컨테이너는 컨테이너 전용 독립 파일 시스템을 사용한다.
• 네임스페이스에서 파일 시스템을 격리하는 방식은 컨테이너 내 프로세스가 yum 및 apt와 같은 패키지 관리 시스템에 설치된 패키지에 의존하는 경우 특히 유용하다.
  • 리눅스 네임스페이스 : 프로세스를 실행할 때 시스템의 리소스를 분리해서 실행할 수 있도록 도와주는 기능
  • 패키지 : 어떤 기능을 제공하는 프로그램을 한꺼번에 배포 형식으로 만든 것
  • 패키지 관리 시스템 : 패키지의 설치나 종속성을 관리하는 시스템 (yum, apt, brew)
• 대부분의 경우 운영 체제의 파일 시스템에 다른 버전의 패키지가 공존하기는 어렵다.
• 컨테이너를 사용하면 다른 버전의 패키지가 공존할 수 있다.

컨테이너와 가상 서버의 차이

• 컨테이너와 가상 서버는 매우 비슷하다.
• 결정적인 차이
  • 컨테이너는 본질적으로 프로세스와 동일
    • 하드웨어 에뮬레이션 없이 리눅스 커널을 공유해서 프로세스를 실행 
    • 네임스페이스와 같은 방식으로 다른 컨테이너와 프로세스에서 격리됨
  • 가상 서버는 하드웨어를 모방하는 소프트웨어
    • 운영체제 위에 하드웨어를 에뮬레이션하고 그 위에 운영체제를 올리고 프로세스 실행. 
    • 가상 서버에 운영 체제를 설치해 다른 가상 서버나, 가상 서버를 실행하는 물리 서버와 격리함.
  • 컨테이너는 다른 컨테이너와 프로세스와 운영체제(커널)을 공유함
  • 가상서버는 다른 가상 서버나 물리 서버와 운영 체제를 공유하지 않음
• 컨테이너를 가상 서버와 비슷하다고 생각하는 것보다 특수한 프로세스라고 생각하는 편이 좋다.

컨테이너로 호스트 OS와 다른 OS를 사용한다는 말의 의미

• 컨테이너는 호스트 머신의 운영 체제를 이용하고 있지만, 어떤 컨테이너가 우분투에 포함되는 소프트웨어 세트를 갖추고 있다면 그 컨테이너 내에서 실행되는 프로세스를 마치 우분투에서 실행되는 것처럼 보이게 할 수 있다.
• 여러 운영 체제가 공존할 수 있다.

컨테이너가 있으면 가상 서버는 필요 없다?

• 컨테이너는 운영 체제를 공유하므로 운영 체제 버전의 차이와 호환성에 따라 제대로 작동하지 않을 수 있다.
• 반면 가상 서버는 각각 운영 체제를 설치하므로 운영 체제를 포함한 동일한 환경을 재현할 수 있다.

컨테이너 이미지

• 컨테이너를 실행하기 위한 템플릿 → 컨테이너는 컨테이너 이미지로 생성
  • 클래스(컨테이너 이미지) - 객체(컨테이너)
• 컨테이너 이미지의 대부분은 컨테이너를 실행하는 데 필요한 파일 시스템
  • 파일 시스템은 레이어라는 층이 겹쳐서 구성됨
  • 도커의 차분 관리와도 관련이 있다.

컨테이너 이미지의 생성

• 컨테이너 이미지는 기본이 되는 컨테이너 이미지의 파일 시스템에 새로운 레이어가 겹쳐서 생성된다.
  • 예를 들어, Ubuntu OS 컨테이너 이미지가 있고, 이 컨테이너에 웹 서버인 nginx 프로그램과 구성 파일이 포함된 레이어를 겹쳐서 Ubuntu OS에서 실행되는 nginx 서버의 이미지를 만들 수 있다.
• 컨테이너에서 셸을 기동한 후에 패키지 관리 시스템을 실행해서 수동으로 작성할 수 있다.
• 그러나 보통은 컨테이너 생성 절차를 설명하는 텍스트 파일인 도커 파일을 사용해서 자동으로 만든다.

운영 체제 설치 디스크와 컨테이너 이미지로 운영 체제 사용하는 것의 차이

운영 체제 설치 디스크는 필요한 것을 복사해서 설치하는 것이지만, 컨테이너 이미지로 운영 체제를 사용하는 개념은 프로그램과 설정 파일을 컨테이너에서 접근해서 사용하는 것이다.

[컨테이너와 도커의 활용]

보통 우리가 애플리케이션을 개발하면, 로컬에서 앱을 만들고, OS, 네트워크 환경을 설정하고, 라이브러리나 미들웨어를 설치하여서 만든다. 근데 문제는 로컬에서는 잘 되던 프로그램이 실제 환경에 배포하면 정상적으로 움직이지 않는다. 이건 환경이랑 설정이 달라서 생기는 문제이다.

컨테이너를 사용하면 애플리케이션 실행에 필요한 모든 파일과 디렉토리를 통째로 컨테이너 이미지로 모을 수 있다.

그럼 우리가 앱을 개발해서 Dockerfile을 이용해서 컨테이너 이미지를 작성한다. 이 이미지는 OS 커널과 호환성이 있어서 컨테이너가 작동하는 환경이라면 이미지를 받아서 어디서든지 작동시킬 수 있다. 그럼 컨테이너를 작동시키는 곳에서는 어디서든 가능하게 되는 것이다.

컨테이너 이미지를 관리해주는 것은 레지스트리이다. 컨테이너 이미지는 레지스트리로 공유할 수 있다. 도커의 공식 레지스트리는 Docker Hub이다. 그럼 이제 우리가 Ubuntu같은 OS를 사용하고 싶으면 Ubuntu 베이스 이미지를 받아서 사용하면 된다.

(private 환경이라면 컨테이너 레지스트리는 도커 hub와 같은 시스템을 별도로 사용해야 한다)