챕터2. 컨테이너의 이해

챕터2. 컨테이너의 이해

• 2.1 컨테이너 소개

2.1.1 컨테이너와 가상 머신 비교

(1.2.1 컨테이너 이해)

리눅스 컨테이너 기술 - 동일한 호스트 시스템에서 여러 개의 서비스를 실행할 수 있다. 가상머신과 비교해서 오버헤드가 매우 적다.

 

컨테이너와 가상머신 비교

• 컨테이너는 훨씬 더 가벼워 많은 수의 SW 구성요소를 실행할 수 있다.
• 가상머신은 시스템 프로세스를 실행해야해서 추가 컴퓨팅 리소스가 필요하다.
• 컨테이너는 호스트OS에서 실행되는 하나의 격리된 프로세스이다.

• 호스트에 가상머신을 세 개 실행하면 세 개의 완전히 분린된 OS가 실행되고 동일한 베어메탈 하드웨어를 공유하게 된다.
• 컨테이너는 호스트 OS에서 실행되는 동일한 커널에서 시스템 콜을 수행한다.
• 컨테이너는 모두 동일한 커널을 호출함으로 보안 위험이 발생할 수 있다.
• 동일한 시스템에서 더 많은 수의 격리된 프로세스를 실행하려면 컨테이너의 오버헤드가 낮기 때문에 컨테이너를 선택하는 것이 좋다.
• 각 가상머신은 자체 시스템 서비스를 실행하지만 컨테이너는 모두 동일한 OS에서 실행되므로 컨테이너는 시스템 서비스를 실행하지 않는다.

컨테이너 격리를 가능하게 하는 메커니즘

• 리눅스 네임스페이스(namespace)
  네임스페이스 종류
  -마운트 -프로세스 ID
  -네트워크 -프로세스 간 통신
  -호스트와 도메인 이름
  -사용자 ID

모든 시스템 리소스는 하나의 네임스페이스에 속한다.

프로세스를 실행할 때 해당 네임스페이스 중 하나에서 프로세스를 실행한다.

프로세스는 동일한 네임스페이스 내에 있는 리소스만 볼 수 있다.

여러 종류의 네임스페이스가 있기 때문에 프로세스는 여러 네임스페이스에 속할 수 있다.

• 리눅스 컨트롤 그룹(cgroups)
  컨테이너가 사용할 수 있는 시스템 리소스의 양을 제한하는 것이다.
  이는 프로세스의 리소스 사용을 제한하는 리눅스 커널 기능인 cgroups로 이줘진다.
  프로세스는 다른 프로세스용으로 예약된 리소스를 사용할 수 없다.

2.1.1 Docker 설치 및 Hello World 컨테이너 실행

[Docker] 맥 OS에 도커 설치하기(Install Docker on MacOS)

해당 블로그를 통해 도커 및 도커 데스크탑 설치

터미널을 통해 버전 확인!

 

Hello World 컨테이너 실행

busybox - echo, ls, gzip 등과 같은 표준 UNIX 명령줄 도구들을 합쳐 놓은 단일 실행파일

busybox 이미지를 실행하기 위해 어떤 것도 다운로드할 필요없다.

docker run 커맨드를 사용해 어떤 이미지를 다운로드 하고 실행할지 명령어를 기술하면 된다.

 

중요한 점은 애플리케이션이 컨테이너 내부에서 실행되고, 컴퓨터에서 실행중인 다른 모든 프로세스로부터 완전히 격리된다는 점이다.

$ docker run busybox echo “Hello World”

 

백그라운드에 일어난 동작 이해하기

docker run 명령을 수행했을 때 먼저 busybox:latest 이미지가 로컬에 존재하는지 체크한다.

존재하지 않는다면 도커 허브 레지스트리에서 이미지를 풀하고 격리된 컨테이너에서 실행한다.

echo 명령어는 텍스트를 표준 출력으로 출력한 후 프로세스를 중단하고 컨테이너도 중지된다.

$ docker run <image> // 도커 이미지 실행
$ docker run <image>:<tag> // 컨테이너 이미지에 버전 지정

 

2.1.2 간단한 node.js 애플리케이션 생성하기

# vi app.js

const http = require('http');
const os = require('os');

console.log("Kubia server starting...");

var handler = function(request, response) {
  console.log("Received request from " + request.connection.remoteAddress);
  response.writeHead(200);
  response.end("You've hit " + os.hostname() + "\\n");
};

var www = http.createServer(handler);
www.listen(8080);

2.1.3 이미지를 위한 Dockerfile 생성하기

# vi Dockerfile

FROM node:7
ADD app.js /app.js
ENTRYPOINT ["node", "app.js"]

Dockerfile

• 애플리케이션을 이미지로 패키징하기 위한 파일
• 도커가 이미지를 생성하기 위해 수행해야 할 지시 사항이 담겨있다.
• app.js 파일과 동일한 디렉터리에 있어야한다

FROM 줄은 시작점으로 컨테이너 이미지를 정의한다.

두번째 줄은 로컬 디렉토리의 app.js를 이미지의 루트 디렉터리에 동일한 이름으로 추가한다.

ENTRYPOINT는 이미지를 실행할 때 수행되야 할 명령어를 정의한다. 이 경의 node app.js

 

2.1.4 컨테이너 이미지 생성

$ docker build -t kubia .

도커가 디렉터리 내 Dockerfile을 살펴보고 파일에 명시된 지시 사항에 근거해 이미지를 빌드한다.

빌드 프로세스는 도커 클라이언트가 수행하지 않는다.

 

이미지 레이어에 관해 이해하기

이미지라는 것은 큰 덩어리가 아니라 여러개의 레이어로 구성된다.

서로 다른 이미지가 여러 개의 레이어를 공유할 수 있기 때문에 재사용이 가능하다.

컴퓨터에 여러개의 레이어가 이미 저장돼 있다면 도커는 저장되지 않은 레이어만 다운로드한다.

 

2.1.5 컨테이너 이미지 실행

$ docker run --name kubia-container -p 8080:8080 -d kubia
// -d 백그라운드에서 실행
// -p 8080:8080 로컬머신 8080포트가 컨테이너 내부의 8080포트와 매핑

$ docker ps
// 실행 중인 모든 컨테이너를 조회해서 리스트를 확인

$ docker inspect kubia-container 
// 도커 컨테이너이너의 상세 정보를 json형식으로 출력한다.

$ docker exec -it kubia-container bash
// 실행 중인 컨테이너의 기본 이미지에 셸을 포함하고 있다면 명령어를 통해 셸을 실행 할 수 있다.
// -it 옵션 -i : 표준 입력을 오픈상태로 유진한다. 셸에 명령어를 입력하기 위해 필요하다.
					-t : 의사 터미널을 할당한다.

 

호스트 운영체제와 컨테이너 내부에서 조회한 프로세스의ID가 다르다.

컨테이너는 자체 리눅스 PID 네임스페이스를 사용하며 고유의 스퀀스 번호를 가지고 완전히 분리된 프로세스 트리를 갖고있다.

$ docker stop kubia-container
// 도커 컨테이너 중지

$ docker rm kubia-container
// 도커 컨테이너 삭제

 

2.1.8 이미지 레지스트리에 이미지 푸시

도커 허브는 이미지의 리포리터리 이름이 도커 허브 ID로 시작해야만 이미지를 푸시할 수 있다.

$ docker tag kubia 도커허브ID/kubia
//태그를 변경하는 것이 아니라 추가적인 태그를 생성한다.

$ docker push 도커허브ID/kubia

---

• 2.2 쿠버네티스 클러스터 설치

2.2.1 Minikube를 활용한 단일 노드 쿠버네티스 클러스터 실행하기

로컬에서 쿠버네티스를 테스트하고 애플리케이션을 개발하는 목적으로 단일 노드 클러스터를 설치하는 도구이다.

쿠버네티스를 다루려면 kubectl CLI 클라이언트가 필요하다

 

2.2.2 구글 쿠버네티스 엔진을 활용한 관리형 쿠버네티스 클러스터 사용하기

완전한 다중 노드 쿠버네티스 클러스터를 살펴보려면 GKE 클러스터를 사용할 수 있다.

• 각 노드는 도커, kubelet, kube-proxy를 실행한다.
• kubectl 클라이언트 명령어는 마스터 노드에서 실행중인 쿠버네티스 API 서버로 REST 요청을 보내 클러스터와 상호작용한다.

$ gcloud container clusters create kubia --num-nodes 3
// 워커노드가 3개인 쿠버네티스 클러스터를 생성

$ kubectl get nodes
// 노드 확인

$ kubectl describe [node] [노드ID]
// describe 명령어를 통해 cpu,메모리,시스템 정보,노드에 실행 중인 컨테이너 등을 포함한 상태를 보여준다.

---

• 2.3 쿠버네티스에 첫 번째 애플리케이션 실행하기

보통 배포하고자 하는 모든 구성 요소를 기술한 JSON이나 YAML 매니페스트를 준비한다.

 

2.3.1 Node.js 애플리케이션 구동하기

kubectl run 명령어를 사용하여 생성한다.

$ kubectl run kubia --image=[도커허브ID]/kubia --port=8080 --generator=run/v1replicationcontroller "kubia" created
// --image=[도커허브ID]/kubia 실행하고자 하는 컨테이너 이미지 명시
// -port=8080 쿠버네티스에 애플리케이션이 8080포트를 수신 대기
// --generator 로 레플리케이션컨트롤러가 생성된다.

파드 소개

쿠버네티스는 개별 컨테이너들을 직접 다루지 않는다.

대신 함께 배치된 다수의 컨테이너라는 개명르 사용한다.

이 컨테이너의 그룹을 파드(pod)라고 한다.

• 파드는 하나 이상의 밀접하게 연관된 컨테이너의 그룹으로 같은 워커 노드에서 같은 리눅스 네임스페이스로 함께 실행된다.
• 각 파드는 자체IP, 호스트이름, 프로세스 등이 있는 논리적으로 분리된 머신
• 파드에서 실행 중인 모든 컨테이너는 동일한 논리적인 머신에서 실행중인 것 처럼 보인다.
  반면 다른 파드에 실행 중인 컨테이너는 같은 워커 노드에서 실행 중이라도 다른 머신에서 실행 중인 것 처럼 보인다.

백그라운드에 일어난 동작 이해하기

• 로컬에 빌드한 이미지는 로컬에서만 사용할 수 있기 때문에 도커 허브에 푸쉬한다.
• Kubectl 명령어를 실행하면 쿠버네티스의 API 서버로 REST HTTP 요청을 보내서 클러스터에 새로운 래플리케이션컨트롤러 오브젝트를 생성한다.
• 래플리케이션컨트롤러는 새 파드를 생성하고 스케줄러에 의해 워커 노드 중 하나에 스케줄링 된다.
• 해당 워커 노드의 kubelet은 로컬에 이미지가 없다는 것을 알고 도커에게 이미지를 풀 하도록 지시한다. 이후 도커는 컨테이너를 생성 실행한다.

2.3.2 웹 애플리케이션에 접근하기

파드에 어떻게 접근할까? → 각 파드는 자체 IP를 가지고 있지만 클러스터 내부에 있으며 외부에서 접근 불가능하다. → 서비스 오브젝트를 통해 노출해야 외부에서 접근 가능하다.

 

서비스 오브젝트 생성하기

$ kubectl expose rc kubia --type=LoadBalancer --name kuia-http service "kubia-http" exposed
// replicationcontroller 대신 rc라는 약어를 사용한다.

$ kubectl get services
	// 서비스 오브젝트 조회

애플리케이션에서 파드 이름을 호스트 이름으로 사용한다. → 애플리케이션이 워커 노드 운영체제에서 실행 중이라 할지라도 전용으로 분리된 머신에서 실행 중인 것으로 나타난다.

 

2.3.3 시스템의 논리적인 부분

솔직히 마스터 노드가 단일 마스터 노드인지 여러 대의 마스터 노드에 분산된 것인지 알 수 없다.
→ 단일 엔드포인트로 접근 가능한 API 서버를 통해 상호작용하고 있기 때문이다.

• kubectl run 명령을 수행하면 레플리케이션컨트롤러를 생성한다.
• 레플리케이션컨트롤러가 실제 파드를 생성한다.
• 클러스터 외부에서 파드에 접근케 하기 위해 레플리케이션컨트롤러에 의해 관리되는 모든 파드를 단일 서비스로 노출하도록 명령한다.

파드와 컨테이너의 이해

보통 파드는 원하는 만큼의 컨테이너를 포함시킬 수 있다.

파드는 자체의 고유한 사설 IP 주소와 호스트 이름을 갖는다.

 

레플리케이션컨트롤러의 역할 이해

항상 정확히 하나의 파드 인스턴스를 실행하도록 지정한다.

파드를 복제하고 항상 실행 상태로 만든다.(복제본을 만든다)

 

서비스가 필요한 이유

kubia-http 파드가 어떠한 이유에서 변경되거나 제거될 수 있다.

그러면 레플리케이션컨트롤러에 의해 새로 생성된 파드로 대체된다.

새로운 파드는 다른 IP주소를 할당받는데 이것이 이유이다.

항상 변경되는 파드의 IP주소 문제와 여러 개의 파드를 단일 IP와 포트의 쌍으로 노출시키는 문제를 해결한다.

 

2.3.4 애플리케이션 수평 확장

$ kubectl get replicationcontrollers
//kubectl get으로 노드, 파드, 서비스, 레플리케이션컨트롤러 오브젝트를
조회하는데 사용했다.

$ kubectl scale rc kubia --replicas=3
//레플리카 수 3개 유지

쿠버네티스 원칙 중 하나 →
어떤 액션을 수행해야 하는지 정확하게 알려주는 대신에 시스템의 의도하는 상태를 선언적으로 변경,
쿠버네티스가 실제 현재 상태를 검사해 의도한 상태로 조정한다.

 

서비스 호출 시 모든 파드가 요청을 받는지 확인

무작위로 다른 파드를 호출하고 있다.

서비스는 다수 파드 앞에서 로드밸런서 역할을 한다.

서비스를 지원하는 파드가 하나든지 그룹이든지 관계없이 해당 파드가 클러스터 내에서 이동하면서 생성되고 삭제되며 IP가 변경되지만,
서비스는 항상 동일한 주소를 가진다.

 

시스템의 새로운 상태 시각화

• 하나의 서비스와 하나의 레플리케이션컨트롤러가 있다.
• 모든 파드 인스턴스 세개가 모두 레플리케이션컨트롤러에 의해 관리된다.
• 서비스는 모든 요청을 하나의 파드가 아닌 세개에 모두 전송한다.

2.3.5 애플리케이션이 실행 중인 노드 검사하기

쿠버네티스에서 파드가 적절히 노드에 스케줄링됐다면, 어떤 노드에 파드가 실행 중인지는 중요하지 않다.

각 파드는 자체 IP를 가지고 다른 파드가 같은 노드에 있는지 다른 노드에 있는지 상관없이 통신할 수 있다.

$ kubectl get pods -o wide
// -o wide 옵션을 사용해 추가 정보를 확인

$ kubectl describe pod kubia-hczji
// 파드 세부 정보를 살펴볼 수 있다

2.3.6 쿠버네티스 대시보드 소개

$ kubectl cluster-info | grep dashboard
// 해당 명령어를 통해 대시보드 url을 받을 수 있다.
// GKE에서 사용

$ gcloud container clusters describe kubia | grep -E "(username|password):"
// 대시보드 사용자 이름과 패스워드 확인

---

2.4 요약

• 공개된 컨테이너 이미지를 풀하고 실행 할 수 있다.
• 애플리케이션을 컨테이너 이미지로 패키징해 원격 이미지 레지스트리에 푸쉬하고 누구나 사용할 수 있다.
• GKE에 다중 노드 쿠버네티스 클러스터를 설정할 수 있다.
• 파드, 레플리케이션컨트롤러, 서비스 의 기본개념 및 연관관계
• 레플리케이션컨트롤러의 레플리카 수를 변경해 애플리케이션을 수평으로 확장 할 수 있다.

이슈 북마크 🔥

Docker - MAC M1 Error image's platform (linux/arm64/v8) does not match the detected host platform 해결

 

*출처 - 쿠버네티스 인 액션 / 저자: 마르코.룩샤 / 출판: 에어콘출판 / 2020.03.31