[Kubernetes IN ACTION] 2장 - 도커와 쿠버네티스 첫걸음

해당 포스팅은 "쿠버네티스 인 액션"을 공부하고 정리한 글입니다. 모든 내용은 해당 도서를 기준으로 합니다.

---

 

⬛ 2장 도커와 쿠버네티스 첫걸음

◼️ 2.1 도커를 사용한 컨테이너 이미지 생성, 실행, 공유하기

 

 ◾2.1.1 도커 설치와 Hello World 컨테이너 실행하기

도커 설치 : https://docs.docker.com/engine/install/

Install

 

Hello World 컨테이너 실행

docker run busybox echo "Hello world"

 

다른 도커 이미지 실행하기

dockdr run <image name>

 

컨테이너 이미지에 버전 지정하기

docker run <image name>:<tag>

 

▪️ 2.1.3 이미지를 위한 Dockerfile 생성

애클리케이션을 이미지로 패키징하기 위해 먼저 Dockerfile이라고 부르는 파일을 생성해야 함.

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

FROM 줄은 시작점으로 사용할 컨테이너 이미지를 정의.

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

마지막으로 세번째 줄에서는 이미지를 실행했을 때 수행돼야 할 명령어를 정의하는데 이 경우는 node app.js임.

 

▪️ 2.1.4 컨테이너 이미지 생성

이미지 빌드

docker build -t kubia .

 

빌드 프로세스는 도커 클라이언트가 수행하지 않는 대신 디렉터리의 전체 콘텐츠가 도커 데몬에 업로드 되고 그곳에서 이미지가 빌드 됨.

 

이미지는 하나의 큰 바이너리 덩어리가 아니라 여러 개의 레이어로 구성 되어 있으며 서로 다른 이미지가 여러 개의 레이어를 공유할 수 있기 때문에 이미지 저장과 전송에 효과적임.

이미지를 빌드하는 동안 기본 이미지의 모든 레이어를 가져온 다음 도커는 그 위에 새로운 레이어를 생성하고 app.js 파일을 그 위에 추가함.

Dockerfile은 도커로 컨테이너 이미지를 생성하는 일반적인 방법이지만 기존 이미지에서 컨테이너를 실행하고 컨테이너 내부에서 명령어를 수행한 후 빠져나와 최종 상태를 새로운 이미지로 commit 하는 방법으로도 이미지를 수동 생성할 수 있음.

 

▪️ 2.1.5 컨테이너 이미지 실행

이미지 실행

docker run --name <container name> -p 8080:8080 -d <docker image name>

 

도커 상세 정보 확인

docker inspect <docker container name>

 

▪️ 2.1.6 실행 중인 컨테이너 내부 탐색하기

실행 중인 컨테이너 내부에서 셸 실행하기

docker exec -it <container name> bash

컨테이너 내부에서 bash를 실행하는 명령어로, bash 프로세스는 컨테이너의 메인 프로세스와 동일한 리눅스 네임스페이스를 가짐.

-it 옵션

• -i : 표준 입력(STDIN)을 오픈 상태로 유지, 셸에 명령어를 입력하기 위해 필요하며, 해당 옵션을 빼면 망령어를 입력할 수 없음.
• -t : 의사(pseudo) 터미널(TTY)을 할당하느넫, 해당 옵션을 빼면 명렁어 프롬프트가 화면에 표시되지 않음.

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

 

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

이미지를 푸시하기 전에 도커 허브 규칙에 따라 이미지 태그를 다시 지정해야 함.

 

이미지 태그 지정

docker tag <docker image name> <new tag>

 

도커 허브에 이미지 푸시하기

docker push <new tag>

 

 

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

 

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

Minicube

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

클러스터

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

 

클러스터 노드 조회 해 클러스터 동작 상태 확인

kubectl get nodes

 

오브젝트 세부 정보 가져오기

kubectl describe node <node name>

 

 

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

 

◾ 2.3.1 애플리케이션 구동하기

pod 생성

kubectl run <pod name> --image=<image name> --port=8080 --generator=run/v1

—image=<image name> : 실행하고자 하는 컨테이너 이미지를 명시하는 것

—port : 쿠버네티스에 애플리케이션이 8080 포트를 수신 대기해야 한다는 사실을 알려주는 것

—generator : 보통은 사용하지 않음. 쿠버네티스에서 deployment 대신 replicationController를 생성하기 때문에 사용

 

Pod(파드)

• 네티스는 개별 컨테이너들을 직접 다루지 않음.
• 함께 배치된 다수의 컨테이너라는 개념을 사용하는데 이 컨테이너의 그룹을 pod라고 함.
• 같은 워커 노드에서 같은 리눅스 네임스페이스로 함께 실행 됨.
• 각 파드는 자체 IP, 호스트 이름, 프로세스 등이 있는 논리적으로 분리된 머신임.
• 고유한 IP와 애플리케이션 프로세스를 실행하는 하나이상의 컨테이너를 가짐.
• 다른 파드에서 실행 중인 컨테이너는 같은 워커 노드에서 실행 중이더라도 다른 머신에서 실행 중인 것으로 보임.
• 하나의 컨테이너를 보통 가지지만 원하는 만큼의 컨테이너를 포함시킬 수 있음.

 

pod 조회

kubectl get pods

 

kubectl 명령어를 실행하면

• 쿠버네티스의 API 서버로 REST HTTP 요청을 전달하고 클러스터에 새로운 레플리케이션컨트롤러 오브젝트 생성.
• 레플리케이션컨트롤러는 새로운 파드를 생성하고 스케줄러에 의해 워커 노드 중 하나에 스케줄링이 됨.
  • 스케줄링 : 파드가 늑정 노드에 할당됨을 의미. 미래의 특정 시간에 실행됨을 의미하는 것이 아님.
• 해당 워커 노드의 kubelet은 파드가 스케줄링 됐다는 것을 보고 도커에게 명령 지시.

 

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

실행 중인 파드에 접근하는 방법

• 각 파드는 자체 IP 주소를 가지고 있지만 이 주소는 클러스터 내부에 있어 외부에서 접근이 불가능함.
• 외부에서 파드에 접근을 가능하게 하려면 서비스 오브젝트를 통해 노출해야 함.
• LoadBalancer 유형의서비스를 생성해 외부 로드 밸런서를 생성하여 로드 밸런서의 퍼블릭 IP를 통해 파드에 연결할 수 있도록 함.

 

서비스 오브젝트 생성하기

kubectl expose replicationcontroller <name> --type=LoadBalncer --name <service name>

 

서비스 조회하기

kubectl get services

 

External IP를 이용해 서비스 접근하기

```jsx
curl IP:port
```

 

▪️ 2.3.3 시스템의 논리적인 부분

레플리케이션컨트롤러, 파드, 서비스가 서로 동작하는 방식 이해

• 사용자는 컨테이너를 직접 생성하거나 동작시키지 않는 대신 쿠버네티스의 pod를 이용함.
• 하지만 pod도 직접 생성하지 않음.

• kubectl run 명령을 수행하면 레플리케이션컨트롤러를 생성하고 레플리케이션컨트롤러가 실제 파드를 생성함.

 

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

• 항상 정확히 하나의 파드 인스턴스를 실행하도록 지정함.
• 파드를 복제(여러 개의 파드 복제본을 생성)하고 항상 실행 상태로 만듦.
• 파드가 사라진다면 레플리케이션컨트롤러는 사라진 파드를 대체하기 위해 새로운 파드를 생성.

 

▪️ 2.3.4 애플리케이션 수평 확장

구버네티스를 사용하는 주요 이점 중 하나는 간단하게 배포를 확장할 수 있다는 것.

 

의도하는 레플리카 수 늘이기

kubectl scale rc <name> --replicas=3

• 쿠버네티스에게 파드 인스턴스 세개를 항상 유지해야 한다는 것을 알려준 것.

쿠버네티스가 어떤 액션을 수행해야 하는지 정확하게 알려주는 대신 시스템의 의도하는 상태를 선언적으로 변경하고 쿠버네티스가 실제 현재 상태를 검사해 의도한 상태로 저장함.

 

스케일아웃 결과 보기

kubectl get rc
kubectl get pods

 

 

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

쿠버네티스에서는 파드가 적절히 실행하는데 필요한 CPU와 메모리를 제공하는 노드에 스케줄링이 됐다면 컨테이너 내부에 실행 중인 모든 애플리케이션은 동일한 유형의 운영체제 환경을 가짐.

• 각 pod는 요청된 만큼의 컴퓨팅 리소스를 제공받음.

 

파드 IP와 실행 중인 노드 표시하기

kubectl get pods -o wide

 

kubectl describe로 파드 세부 정보 보기

kubectl describ pod <이름>