그림과 실습으로 배우는 도커 & 쿠버네티스

 

p.3

도커를 한마디로 정의하자면 '데이터 또는 프로그램을 격리시키는 기능'을 제공하는 소프트웨어라고 할 수 있다. 

 

p.8~9

쉽게 예를 들면, 시스템 A와 시스템 B가 모두 '무슨무슨 프로그램'과 연동되는 상황을 생각해보면 된다. 시스템 A가 '무슨무슨 프로그램'이 5.0버전이어야만 동작하도록 만들어졌는데 시스템 B만을 위해 '무슨무슨 프로그램'을 8.0버전으로 업데이트했다면? 시스템 A가 동작하지 않게 될 것이다.

 

이 예는 공통으로 함께 연동되는 소프트웨어를 예로 들었지만 실행 환경이나 라이브러리, 디렉터리나 설정 파일에서도 같은 일이 일어날 수 있다. 공유하는 대상을 어느 한쪽만을 위해 수정하면 다른 쪽에서 오류가 발생하게 된다.

 

이러한 문제가 업데이트할 때만 발생하는 것도 아니다.

 

서버에서는 여러 프로그램이 함께 동작하므로 서버를 처음 구축할 때부터 신중하게 따져보지 않으면 안 된다.

 

설계할 때는 문제가 없었던 프로그램끼리도 실제로 설치해보면 오류를 일으키는 경우도 있다. 이러한 문제의 원인은 대부분 프로그램 간 공유에 있다.

 

프로그램에 따라서는 한 서버에 한 버전밖에 설치할 수 없으므로 최소 버전을 같이 맞춰놓으면 문제가 되지 않는다. 그러나 신규 개발이라면 모를까, 기존 프로그램을 함께 설치하려는 상황이라면 연동 프로그램의 버전을 맞추지 못할 수도 있다.

 

디렉터리 역시 시스템 A, B가 같은 디렉터리를 사용하게 돼 있어서 설정 파일이 섞이거나 설정에 충돌이 발생할 수도 있다.

 

프로그램도 한 서버에서 함께 지내려면 사람이 함께 지내는 것 이상으로 신경 쓸 것이 많이 생긴다.

 

p.18

만약 컨테이너 기술을 활용하지 않고 물리 서버 한 대에 두 웹 서버를 함께 올린다면 프로젝트 A에 참여 중인 개발자가 프로젝트 B의 환경을 건드리게 될 수도 있고, 아파치는 서버 한 대에 하나밖에 올리지 못하기 때문에 웹 서버의 기능을 공유해야 하는 한계도 생긴다. 컨테이너 기술을 이용하면 이러한 리스크를 감수하지 않고 두 웹 서버를 하나의 물리 서버에 함께 올릴 수 있다.

 

개발 측면에서의 이점은 개발환경을 갖추거나 운영 환경으로 쉽게 넘어갈 수 있다는 점 등을 들 수 있겠다. 이러한 이점은 컨테이너가 그저 격리된 환경이 아니라 쉽게 옮길 수 있다는 특성에서 비롯된다.

 

p.20

도커는 특성상 가상화 기술과 비교되는 경우가 많다. 그러나 도커는 서버 가상화와는 분명한 차이가 있다. '실행 환경을 독립적으로 격리한 컨테이너'라고 표현하는 것이 정확하다.

 

도커와 가상화 기술의 차이

VirtualBox나 VMware 같은 가상화 기술은 가상의 물리 서버를 만드는 것과 같다. 여기서 '가상'이라는 말은 물리적인 대상을 소프트웨어로 대체했다는 의미다.

 

즉, 메인보드와 CPU, 메모리 등의 물리적인 부품을 소프트웨어로 구현하는 것이다. 실질적으로 물리 서버와 동등한 것이므로 당연히 운영체제도 아무 것이나 설치할 수 있고, 그 위에서 어떤 소프트웨어를 구동해도 무방하다.

 

이와 달리 도커는 컨테이너에서 리눅스가 동작하는 것처럼 보이지만 실제 리눅스가 동작하는 것은 아니다. 운영체제의 기능 중 일부를 호스트 역할을 하는 물리 서버에 맡겨 부담을 덜어 둔 형태다.

 

다시 말해 컨테이너는 운영체제의 일부 기능을 호스트 컴퓨터에 의존하기 때문에 물리 서버에도 리눅스 기능이 필요하며, 컨테이너의 내용도 리눅스 운영체제가 될 수밖에 없다.

 

p.22

일반적인 서버라면 운영체제 위에 프로그램이나 데이터가 직접 올라가겠지만 도커를 사용하는 경우에는 운영체제 위에 도커 엔진이 동작하고 그 위에서 컨테이너가 동작한다.

 

프로그램이나 데이터는 컨테이너 안에 위치한다.

 

p.29

컨테이너를 생성하려면 먼저 이미지를 만들어야 한다. 이미지는 컨테이너를 찍어내는 '빵틀'과 같은 것으로, 컨테이너의 설계도 역할을 한다.

 

p.37

도커를 사용할 때의 원칙 중 하나로, '한 컨테이너에 한 프로그램'이라는 것이 있다. 말 그대로 하나의 프로그램만 담긴 컨테이너를 사용한다는 의미로, 보안 및 유지 관리 측면에서 유리하기 때문에 많이 쓰이는 정책이다.

 

따라서 단순히 워드프레스를 구축할 때도 다양한 구성이 가능하다.

 

워드프레스를 사용하려면 아파치(웹 서버 소프트웨어), MySQL 같은 DBMS, 워드프레스로 세 가지 소프트웨어가 필요하다.

 

도커를 사용해 워드프레스를 구축하는 방법은 이들을 각각 별도의 컨테이너로 구성할 수도 있고, 한 컨테이너에 모두 집어넣는 방법도 있다.

 

p.39

앞서 얘기했듯이 컨테이너는 쉽게 만들 수 있다. 그러므로 컨테이너 하나를 업데이트하면서 계속 사용하기보다는 업데이트된 소프트웨어가 들어있는 새로운 컨테이너를 사용하는 것이 좋다.

 

즉, 새로운 버전이 나오면 새로운 컨테이너로 갈아타는 것이다.

 

이것이 가능한 이유는 컨테이너는 일반적으로 여러 개를 동시 가동하는 상황을 전제로 하기 때문이다. 여러 개의 컨테이너를 하나하나 업데이트하려면 많은 수고가 든다. 초기 구축은 간단히 마쳤는데 유지보수할 때마다 컨테이너를 일일이 업데이트하려니 컨테이너의 장점이 반감된다. 유지보수 횟수가 훨씬 많은 것도 그렇다.

 

이러한 이유로 오래된 컨테이너를 버리고 새로운 이미지로부터 새로운 컨테이너를 만들어 갈아타는 방식을 사용한다. 이런 방법을 사용하면 수고를 크게 덜 수 있다.

 

p.40~41

컨테이너를 폐기했다면 컨테이너에 들어있던 데이터는 어떻게 될까?

 

컨테이너를 폐기하면 해당 컨테이너 안에서 편집했던 파일은 당연히 사라진다. 이 파일은 컨테이너 안에 들어있었기 때문이다. 이래서야 곤란한 일이 아닐 수 없다.

 

이런 일을 방지하기 위해 보통은 도커가 설치된 물리적 서버(호스트)의 디스크를 마운트해 이 디스크에 데이터를 저장한다.

 

마운트는 '디스크를 연결해 데이터를 기록할 수 있도록 한 상태'를 의미하는데, 예를 들어 우리가 매일 사용하는 클라이언트 컴퓨터에 외장 USB나 HDD를 연결하듯이 도커 컨테이너도 물리적 컴퓨터의 디스크(HDD 또는 SSD)를 연결해 데이터를 기록할 수 있다.

 

이런 방법으로 컨테이너가 폐기되더라도 데이터는 컨테이너 외부에 안전하게 저장되어 사라지지 않는다. 최악의 경우 도커 엔진 자체에 무슨 일이 생기더라도 데이터는 그대로 보존된다. PC가 망가질 때를 대비해 외부에 데이터를 저장하는 것과 같은 이치다.

 

그리고 데이터를 이렇게 외부에 저장하면 다른 컨테이너와 데이터를 공유할 수도 있어서 매우 편리하다.

 

p.69

도커 엔진은 무료로 사용할 수 있는 'Community Edition'(이하 CE)와 유료 버전인 'Enterprise Edition'(이하 EE)이 있다. 두 가지 버전의 차이를 간단히 정리하면, EE는 보증과 함께 인증을 거친 인프라 또는 플러그인, 보안 검사 기능 등이 제공된다. 보증과 함께 제공되는 만큼 레드햇 엔터프라이즈 리눅스나 SUSU같은 리눅스 유료 배포판이나 윈도우 서버에서 사용하거나, 종합적인 관리를 원하는 경우에 많이 사용된다. 특히 윈도우 서버는 EE만 지원하므로 CE를 사용할 수 없다.

 

p.82

도커 데스크톱은 도커 엔진을 자동으로 실행하도록 설정돼 있기 때문에 이 설정도 비활성화하지 않으면 컴퓨터가 부팅될 때마다 도커 엔진도 자동으로 실행된다. 리눅스에서는 자동 실행이 기본 설정이 아니다. 실제 사용할 때 곤란해지기 쉬우므로 자동 실행을 설정해 두기 바란다.

 

지금까지 한 설명은 도커 엔진에 한정된 이야기다. 도커 엔진 위에서 동작하는 컨테이너는 또 다르다. 도커 데스크톱이나 리눅스 버전 모두 도커 엔진이 한번 종료되면 모든 컨테이너는 정지 상태가 된다.

 

컨테이너에는 자동 실행 설정이 없으므로, 이를테면 정전으로 인해 서버의 전원이 내려간 상황에서 도커 엔진과 함께 컨테이너를 복구하려면 컨테이너를 따로 실행하는 스크립트(프로그램)를 작성해야 한다.

 

p.86

이름이 penguin인 이미지를 실행

 

docker container run penguin

 

'대상'과 '상위 커맨드(무엇을)'의 차이가 잘 와닿지 않을지도 모르겠다. 상위 커맨드는 'container(컨테이너)' 또는 'image(이미지)'와 같이 대상의 종류가 들어간다. 딱 12종류 뿐이다. 

 

p.87

docker 명령어의 기본적인 형태

 

docker 커맨드(상위 + 하위 커맨드) (옵션) 대상 (인자)

 

p.96

도커 커맨드 중에는 컨테이너를 생성하는 docker create (docker container create), 컨테이너를 실행하는 docker start (docker container start) 커맨드, 이미지를 내려받는 docker pull (docker image pull) 커맨드가 각각 따로 존재하지만, 이들 기능을 한꺼번에 수행할 수 있는 docker run을 사용하는 것이 일반적이다.

 

p.100

컨테이너의 생애주기를 관장하는 커맨드 외에 자주 사용하게 될 커맨드가 한 가지 더 있는데, 이 커맨드가 바로 docker ps (docker container ls) 커맨드다.

 

이 커맨드는 컨테이너의 목록을 출력하는 기능을 하는데, docker ps는 현재 실행중인 컨테이너의 목록을 출력하며, docker ps -a 옵션을 추가하면 현재 존재하는 컨테이너 (정지 상태의 컨테이너를 포함)의 목록을 출력한다.

 

p.106

아파치는 웹 서버 기능을 제공하는 소프트웨어다.

 

쉽게 설명해서 아파치가 동작 중인 서버에 파일을 두면 이 파일을 웹 사이트 형태로 볼 수 있다. 4-3절에서는 컨테이너를 만들고 곧바로 삭제했지만 이번에는 웹 브라우저를 통해 컨테이너에 접근해 웹 사이트가 동작하는지 확인해보자.

 

하지만 앞서와 똑같은 명령어로는 웹 사이트의 동작을 확인할 수 없다. 왜냐하면 컨테이너가 컨테이너 외부에서 접근이 불가능한 상태로 실행되기 때문이다.

 

웹 브라우저를 통해 컨테이너에 접근이 가능하게 하려면 컨테이너를 실행할 때 설정이 필요하다. 또한 이 설정은 컨테이너를 생성한 후에는 기본적으로 변경할 수 없다. 따라서 docker run 커맨드에 옵션 형태로 설정한다.

 

p.108

컨테이너를 실행 중인 컴퓨터(호스트)의 8080번 포트(이 포트는 다른 소프트웨어가 사용하는 포트와 겹치지 않는 한 임의의 숫자를 사용해도 된다)와 컨테이너의 80번 포트를 연결한다. 이 설정이 -p 옵션이며, 그 뒤로 '호스트의 포트 번호'와 '컨테이너의 포트 번호'를 콜론으로 연결해 함께 기재한다.

 

포트 설정방법

-p 호스트_포트_번호:컨테이너_포트_번호

 

-p 8080:80

 

그리고 컨테이너를 사용하면 여러 개의 웹 서버를 함께 실행할 수도 있다. 이러한 경우 호스트 포트 번호를 모두 같은 것으로 사용하면 어떤 컨테이너로 가야 할 요청인지 구분할 수 없기 때문에 컨테이너 A에는 호스트 포트 8080, 컨테이너 B에는 호스트 포트 8081과 같은 식으로 호스트의 포트 번호를 겹치지 않게 설정한다. 꼭 여러 컨테이너로 연결되는 포트를 같게 설정하고 싶다면 리버스 프락시로 서버 이름을 통해 구별되도록 구성한다.

 

p.116

컨테이너를 여러 개 실행할 때 호스트 컴퓨터의 포트 번호가 중복돼서는 안 된다. 따라서 1씩 차이나도록 번호를 지정한다. 반면 컨테이너 포트는 중복돼도 무방하므로 모두 80번으로 설정한다(이 포트번호는 이미지 제작자가 지정한 것으로 변경할 수 없다). 웹 브라우저를 통한 동작 확인 역시 호스트 번호에 따라 달라진다.

 

p.124

아파치나 Nginx에 비하면 MySQL 컨테이너를 만드는 과정은 조금 까다롭다. 제대로 동작하게 하려면 인자를 반드시 지정해야 한다. 

 

p.137~138

도커 네트워크를 생성하는 커맨드다. 옵션이나 인자를 추가하는 경우는 거의 없다. 네트워크를 생성한 다음 컨테이너에서 네트워크에 접속하게 설정한다.

 

docker network create 네트워크_이름

 

docker network rm 네트워크_이름

 

network 상위 커맨드도 네트워크 목록 확인과 같은 하위 커맨드를 갖추고 있다.

 

커맨드	내용	생략가능여부	주요 옵션
connect	네트워크에 컨테이너를 새로이 접속	X	거의 사용하지 않음
disconnect	네트워크에서 컨테이너의 접속을 끊음	X	거의 사용하지 않음
create	네트워크를 생성	X	거의 사용하지 않음
inspect	네트워크의 상세 정보를 확인	X	거의 사용하지 않음
ls	네트워크의 목록을 확인	X	거의 사용하지 않음
prune	현재 아무 컨테이너도 접속하지 않은 네트워크를 모두 삭제	X	거의 사용하지 않음
rm	지정한 네트워크를 삭제	X	거의 사용하지 않음

p.149

아파치, PHP, MySQL에 리눅스를 합친 조합을 LAMP 스택이라고 부른다. 우리도 리눅스를 사용하고 있으므로 말 그대로 LAMP 스택을 사용 중이다.

 

소프트웨어가 발전하면서 아파치가 nginx로 바뀌기도 하고, MySQL이 MariaDB나 PostgreSQL로 바뀐 조합도 나타났지만 '리눅스 + 웹 서버 + 프로그래밍 언어 런타임 + 데이터베이스'의 조합임은 변함이 없다.

 

p.169

프로그램만으로 구성된 시스템은 그리 많지 않다.

 

프로그램 외에도 프로그래밍 언어의 런타임이나 웹 서버, 데이터베이스 등이 함께 시스템을 구성한다.

 

이들 구성 요소는 시스템이 동작하는 데 필요하지만 그 외에도 화면을 구성하는 이미지, 입력받은 데이터 본체 등이 있을 수 있다. 워드프레스를 예로 들면 웹 페이지를 구성하는 HTML파일, CSS 파일, 각 아티클에 포함된 텍스트나 이미지 등이 있을 것이다.

 

이러한 파일은 워드프레스 상의 조작을 통해 서버에 저장되지만 때로는 소프트웨어의 개입 없이 서버와 로컬 컴퓨터 간에 파일을 주고받아야 할 때가 있다. 이럴 때를 위해 파일 복사하는 방법을 익혀두자.

 

파일 복사는 컨테이너 -> 호스트, 호스트 -> 컨테이너로 양방향 모두 가능하다. 호스트 쪽 파일은 어디에 위치한 파일이라도 복사가 가능하고, 컨테이너 쪽에서도 파일을 복사할 경로를 지정할 수 있다.

 

p.173

 

 

p.179~181

볼륨이란 스토리지의 한 영역을 분할한 것을 말한다. 간단히 말하면 하드디스크나 SSD를 분할한 하나의 영역이다. 기다란 카스테라를 자른 한 조각이라고 생각하면 이해하기가 쉽다.

 

마운트는 '연결하다'라는 의미 그대로 대상을 연결해 운영체제 또는 소프트웨어의 관리 하에 두는 일을 말한다. 

 

이해하기 쉬운 예로 USB 메모리를 컴퓨터에 꽂으면 띠딩, 하는 소리가 난 다음 폴더가 열리는데, 이것도 USB 메모리가 컴퓨터에 마운트됐기 때문이다.

 

지금까지 여러 번 컨테이너를 생성하고 삭제해왔는데, 실제로 컨테이너를 사용하려면 스토리지 영역을 마운트해야 한다. 왜냐하면 데이터가 이 스토리지에 있기 때문이다.

 

컨테이너를 종료해도 바로 삭제되지는 않지만 성격상 '쓰고 버려야'하기 때문에 소프트웨어 업그레이드 등의 이유로 언젠가는 삭제된다.

 

이런 상황에서 컨테이너 속에 데이터가 있다면 컨테이너와 함께 데이터도 소멸된다. 컨테이너의 데이터라고 하면 감이 잘 오지 않을 수도 있는데, 예를 들어 컴퓨터나 스마트폰을 새로 샀을 때 데이터 이전이 안 된다면 매우 곤란할 것이다. 그래서 대개 USB 메모리나 SD카드, 외장 하드에 저장한 후 옮겨서 사용한다.

 

이와 마찬가지로 컨테이너 역시 외부로 데이터를 대피시킨다. 다만 컨테이너는 생성 및 폐기가 매우 빈번하기 때문에 매번 데이터를 옮기는 대신 처음부터 컨테이너 외부에 둔 데이터에 접근해 사용하는 것이 일반적이다. 이를 데이터 퍼시스턴시(data persistency)라고 한다. 이때 데이터를 두는 장소가 마운트된 스토리지 영역이다.

 

스토리지 마운트라고 하면 의미가 모호하기 때문에 관례적으로 '볼륨 마운트'라는 용어를 사용하는데, 마운트 대상이 되는 스토리지는 볼륨 외에도 디렉터리나 파일, 메모리가 될 수도 있다.

 

p.181~182

도커에서 스토리지의 마운트는 두 가지 종류가 있다. 하나는 볼륨 마운트이고, 다른 하나는 바인드 마운트다.

 

볼륨 마운트는 도커 엔진이 관리하는 영역 내에 만들어진 볼륨을 컨테이너에 디스크 형태로 마운트 한다. 

 

이름만으로 관리가 가능하므로 다루기 쉽지만 볼륨에 비해 직접 조작하기 어려우므로 '임시 목적의 사용'이나 '자주 쓰지는 않지만 지우면 안 되는 파일'을 두는 목적으로 많이 사용한다.

 

바인드 마운트는 도커가 설치된 컴퓨터의 문서 폴더 또는 바탕화면 폴더 등 도커 엔진에서 관리하지 않는 영역의 기존 디렉터리를 컨테이너에 마운트하는 방식이다. 디렉터리가 아닌 파일 단위로도 마운트가 가능하다.

 

폴더(디렉터리) 속에 파일을 직접 두거나 열어볼 수 있기 때문에 자주 사용하는 파일을 두는 데 사용한다.

 

p.183

파일을 직접 편집해야 할 일이 많다면 바인드 마운트를 사용하고, 그렇지 않다면 볼륨 마운트를 사용하면 된다.

항목	볼륨 마운트	바인드 마운트
스토리지 영역	볼륨	디렉터리 또는 파일
물리적 위치	도커 엔진의 관리 영역	어디든지 가능
마운트 절차	볼륨을 생성한 후 마운트	기존 파일 또는 폴더를 마운트
내용 편집	도커 컨테이너를 통해서	일반적인 파일과 같이
백업	절차가 복잡	일반적인 파일과 같이

 

p.198

이미지를 만드는 방법에는 두 가지가 있다.

 

첫 번째는 commit 커맨드로 기존 컨테이너를 이미지로 변환하는 방법이고, 두 번째는 Dockerfile 스크립트로 이미지를 만드는 방법이다.

 

p.200

주요 Dockerfile 인스트럭션

 

p.206

컨테이너를 개조하는 방법에는 두 가지 방법이 있다. 대부분 이 두 가지 방법을 혼용한다.

 

첫 번째 방법은 파일 복사와 마운트를 이용한 방법이다.

 

두 번째 방법은 컨테이너에서 리눅스 명령어를 실행하는 방법이다. 소프트웨어를 설치하거나 설정을 변경할 수 있다.

 

p.224

명령어를 입력하는 데 익숙해져도 워드프레스처럼 여러 개의 컨테이너로 구성된 시스템을 실행하기는 조금 귀찮게 느껴진다. 인자나 옵션도 많을뿐더러 볼륨이나 네트워크까지 설정해야 하기 때문이다.

 

나중에 시스템을 뒷정리할 때도 만들었던 컨테이너를 ps 커맨드로 일일이 확인해가며 지우려니 수고스럽다.

 

이렇듯 시스템 구축과 관련된 명령어를 하나의 텍스트 파일(정의 파일)에 기재해 명령어 한 번에 시스템 전체를 실행하고 종료와 폐기까지 한번에 하도록 도와주는 도구가 바로 도커 콤포즈다.

 

p.225

up 커맨드는 docker run 커맨드와 비슷하다. 정의 파일에 기재된 내용대로 이미지를 내려받고 컨테이너를 생성 및 실행한다. 정의 파일에는 네트워크나 볼륨에 대한 정의도 기재할 수 있어서 주변 환경을 한꺼번에 생성할 수 있다.

 

down 커맨드는 컨테이너와 네트워크를 정지 및 삭제한다. 볼륨과 이미지를 삭제하지 않는다. 컨테이너와 네트워크 삭제 없이 종료만 하고 싶다면 stop 커맨드를 사용한다.

 

p.250

도커 컴포즈로 실행한 컨테이너 역시 도커 엔진을 통해 관리할 수 있다. 단, 한 가지 주의할 점이 있는데, 도커 컴포즈로 실행한 컨테이너의 이름은 임의로 결정된다는 점이다.

 

예를 들어, com_folder에 둔 컴포즈 파일을 사용해 penguin이라는 이름의 컨테이너를 생성하면 도커 컴포즈가 실제로 생성한 컨테이너의 이름은 com_folder_penguin_1과 같이 폴더 이름과 번호가 붙는다 (-f 옵션을 생략했다면 폴더 이름은 붙지 않는다).

 

더욱 까다로운 부분은, 컨테이너 이름에 폴더 이름이나 번호가 붙어도 도커 컴포즈를 통해 컨테이너를 지정할 때는 (컴포즈 파일에 기재된) 원래 이름을 사용할 수도 있다는 점이다.

 

이렇게 번호가 붙은 컨테이너 이름은 도커 엔진을 통해 컨테이너를 관리하거나, 같은 구성의 컨테이너를 여러 세트 실행했을 때 사용된다. 도커 컴포즈 자신은 (평소에는) 사용하지 않으면서 남(도커 엔진)한테는 바뀐 이름을 쓰게 하는 것이 흥미롭다.

 

따라서 도커 엔진을 통해 컨테이너를 다룰 때는 ps 커맨드를 사용해 먼저 컨테이너의 실제 이름을 확인해야 한다.

 

p.259

쿠버네티스는 전체적인 제어를 담당하는 마스터 노드와 실제 동작을 담당한느 워커 노드라는 두 가지 유형의 노드로 구성된다. 노드라는 낯선 용어가 나왔는데, 거의 물리적 서버와 일치하는 개념이라고 보면 된다.

 

마스터 노드와 워커 노드는 그 역할에 차이가 있다.

 

마스터 노드는 이름 그대로 감독과 같은 존재다. 집으로 말하면 대들보와 같다. 마스터 노드에서 컨테이너를 실행하지는 않으며 워커 노드에서 실행되는 컨테이너를 관리하는 역할을 한다. 따라서 도커 엔진 같은 컨테이너 엔진도 설치되지 않는다. 마스터(감독)는 컨테이너를 관리하는 업무로도 여력이 없기 때문이다. 관리직이 바쁜 것은 비단 사람에게만 해당되는 얘기는 아닌 것 같다.

 

워커 노드는 실제 서버에 해당하는 부분으로, 컨테이너가 실제 동작하는 서버다. 컨테이너가 동작해야 하므로 컨테이너 엔진이 설치돼야 하는 것은 물론이다.

 

이렇게 마스터 노드와 워커 노드로 구성된 일군의 쿠버네티스 시스템을 클러스터라고 한다.

 

클러스터는 사람이 개입하지 않아도 마스터 노드에 설정된 내용에 따라 워커 노드가 관리되며 자율적으로 동작한다.