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

학습목표

도커를 사용한 컨테이너 이미지 생성, 실행, 공유

로컬에 단일 노드 쿠버네티스 클러스터 실행

구글 쿠버네티스 엔진에서 쿠버네티스 클러스터 설치d

kubectl CLI 클라이언트 설정과 사용

쿠버네티스에서 애플리케이션의 배포와 수평스케일링

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

쿠버네티스는 워커노드를 하나의 플랫폼으로 제공
워커 노드들은 파드 조합들로 구성, 파드(1개 이상의 컨테이너 그룹)
- https://kubernetes.io/ko/docs/concepts/workloads/pods/
- 도커 : 컨테이너화할 수 있는 가상화 플랫폼

2.1.1. HelloWorld 컨테이너 실행

도커 설치: https://www.docker.com/get-started
독헙 홈페이지: https://hub.docker.com/

이미지 푸시

이미지를 푸시하기 전에 도커 허브웹 UI에서 해당 프로젝트를 생성해야 합니다.

먼저 Docker 클라이언트에서 로그인합니다.

$ docker login

이미지에 태그 지정:

$ docker tag ${YOUR_IMAGE}:${TAG}

이미지 푸시:

$ docker push [OPTIONS] NAME[:TAG]

// 커맨드
docker run busybox echo "Hello world"
// 실행
Hello world

docker 내부 동작

docker run busybox echo "Hello world"
도커는 로컬 머신에 busybox 이미지가 저장돼있는지 확인한다.
로컬에 이미지가 없으면 도커는 레지스트리로부터 이미지를 풀한다.
도커가 격리된 컨테이너에서 echo "Hello world" 를 실행한다.
Hello world 가 출력된다.

이미지 관련 추가 정보
- https://hub.docker.com/에서 이미지 검색할 수 있다
- 이미지 이름을 알고 있으면 아래 명령어로도 확인 가능하다
- docker search <image>
- 버전 지정
  - docker run <image>:<tag>

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

app.js 파일 생성

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

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

var handler = function(request, response) {

    // 서버의 요청에 대해서
    // 1. 클라이언트 IP를 로깅
    // 2. 200 응답
    // 3. You've hist <host name> 텍스트 응답
    console.log("Received request from " + request.connection.remoateAddress);
    response.writeHead(200);
    response.end("You've hit " + os.hostname() + "\n");
};

var www = http.createServer(handler);
www.listen(8080);   // 8008 포트로 서버를 시작

node js 를 설치하지 않고, 도커를 통해 컨테이너 이미지로 패키징하여 실행시킬 수 있다.

2.1.3. 이미지를 위한 Dockerfile 파일 생성

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

2.1.4 컨테이너 이미지 생성

이미지를 빌드하기 위한(Docker 과 app.js)가 완료되었으므로 아래 명령어를 통해 이미지를 빌드합니다.

// 커맨드
docker build -t kubia .

빌드 프로세스는 도커 클라이언트가 수행하지 않으며, 디렉토리의 전체 콘텐츠가 도커 데몬에 업로드되고 , 그곳에서 이미지가 빌드된다. 도커 클라이언트와 데몬은 같은 머신에 있을 필요가 없음.

빌드 디렉토리에 불필요한 파일을 포함하지 말것. 특히 원격 머신이 도커 데몬에 위치한 경우, 이러한 파일이 빌드 속도 저하를 가져온다.

이미지 레이어
- 이미지는 하나의 큰 바이너리 덩어리가 아니라 여러 개의 레이어로 구성된다.
- 서로 다른 이미지가 여러 개의 레이어를 공유할 수 있기 때문에 저장, 전송에 효과적이다.
  - 1. docker build kubia .
    2. 도커 클라이언트가 디렉토리의 콘텐츠를 데몬에 업로드한다.
    3. 이미지가 아직 로컬에 저장돼있지 않는 경우, 도커가 이미지를 풀한다.
    4. 새로운 이미지를 빌드한다.
각 dockerfile 이 새로운 레이어를 하나만 생성하는 것은 아니다. 이미지를 빌드하는 동안, 기본 이미지의 모든 레이어를 가져온 다음, 그 위에 새로운 레이어를 생성하고, app.js 파일을 그 위에 추가함. 그 후, 이미지를 실행할 때, 수행해야할 명령어를 지정하는 또 하나의 레이어를 추가하고, 이 마지막 레이어는 kubia:latest 라고 태그를 지정한다.

이미지 빌드 프로세스가 완료되면 새로운 이미지가 로컬에 저장되며, $ docker image 명령어로 조회 가능합니다.

$ docker images
REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
kubia        latest    06ed9d19d3e4   15 minutes ago   660MB
redis        latest    cc69ae189a1a   7 days ago       105MB
busybox      latest    491198851f0c   11 days ago      1.23MB
postgres     latest    1f0815c1cb6e   2 weeks ago      314MB
mysql        5.7       5f47254ca581   2 weeks ago      449MB
mysql        8.0       2933adc350f3   2 weeks ago      546MB
mysql        latest    2933adc350f3   2 weeks ago      546MB

Dockerfile과 수동 빌드 비교하기
- 기본 이미지로 컨테이너 실행하여 패키지 install, commit 을 통해 수동으로 만들 수 있지만, 어떤 이미지인지 명시해놓은 Dockerfile로 공유하는 것이 반복 가능하고, 이미지 빌드를 자동화할 수 있는 방법이다. (dockerfile 만 변경하면, 언제든 이미지를 다시 빌드할 수 있으므로)

참고: docker image layer 구조

Docker 이미지를 이용해 docker run 을 하면 docker 는 도커과 관리하는 파일 시스템 영역에 이미지를 복사한다. 복사후, docker 는 이미지의 최상단에 컨테이너 레이어라 불리는 하나의 얇은 레이어를 추가하여 컨테이너를 생성한다. 그리고 사용자에게 유니온 파일 시스템을 이용하여 마치 이러한 여러 개의 파일 시스템이 (image layer)으로 구성되어있는 이미지 스택 구조가 하나의 파일 시스템처럼 보이게 한다.

설명 : Docker 이미지를 통해 이미지로 컨테이너를 생성할 경우, 기존의 이미지 레이더들 위해 컨테이너 레이어가 생성된다.

사용자가 컨테이너 안에서 읽고 쓰는 모든 작업들을 이 컨테이너 레이어에 기록되고, 이미지 레이어에는 적용되지 않는다.

쉽게 말해 image layer 는 변경 불가하고, 컨테이너 레이어는 변경 가능하다.

다른 사용자가 같은 이미지를 이용해 container를 실행하는 경우, 다른 이미지 레이어만 생성이 되지, 다른 사용자들이 생성한 컨테이너 레이어는 복사되지 않는다.

이미지 레이어는 삭제되지 않지만, 컨테이너 레이어는 해당 컨테이너가 종료될 경우, 같이 소멸된다. 만약에 사용자가 컨테이너 레이어에서 작업하던 내용을 이미지 레이어로 적용하고 싶은 경우, docker commit 을 이용하면 된다. docker commit을 이용하면, 기존의 이미지 레이어들과 직접 작성한 컨테이너 레이어를 이용해 새로운 이미지를 생성할 수 있다.

docker image 를 생성할 수 있는 두 가지 방법

docker build 를 이용해 설정한 Dockerfile 에 맞는 이미지 생성
컨테이너에서 작성한 컨테이너 레이어와 이미지 레이러를 합해서 새로운 이미지 합성

FROM ubuntu:14.04

RUN apt-get update & apt-get install -y nginx

RUN chown -R blue:blue /var/lib/nginx

RUN mkdir -p /home/blue/my_log

이런 docker file이 있는 경우, 내부적으로 다음과 같이 레이어가 생성된다.

참고 : Docker Image Layer 생성과정

Docker를 build 하는 경우, Dockerfile에 정의한 명령어에 따라 이미지가 생성이 되는데, 이미지가 build 되면서 내부적으로 여러 이미지가 층층이 layer 형식으로 쌓인다.

= Dockerfile 앞에 command 개수 만큼 이미지 레이어가 쌓인다.

# Dockerfile
FROM python:3.7-slim
RUN apt -y update && apt -y dist-upgrade && apt -y autoremoe
COPY ./requirements.txt /tmp/
RUN pip install -r /tmp/requirements.txt

COPY . /srv/isntagram
WORKDIR /srv/instagram/app
CMD python manage.py runserver 0:8000

이러한 Dockerfile 이 있을 경우 다음 파일에는 7개의 이미지 레이어가 있다

Step 1/7 : FROM    python:3.7-slim
 ---> f2d2e1dc8c72
Step 2/7 : RUN     apt -y update && apt -y dist-upgrade && apt -y autoremove
 ---> Using cache
 ---> 661b4ab147cc
Step 3/7 : COPY    ./requirements.txt /tmp/
 ---> Using cache
 ---> 652d1bc48c7f
Step 4/7 : RUN     pip install -r /tmp/requirements.txt
 ---> Using cache
 ---> 6a4fbd488f33
Step 5/7 : COPY    . /srv/instagram
 ---> 051d7da9265c
Step 6/7 : WORKDIR /srv/instagram/app
 ---> Running in f56b5df2b026
Removing intermediate container f56b5df2b026
 ---> fbed5bf442cc
Step 7/7 : CMD     python manage.py runserver 0:8000
 ---> Running in 61cbd19c9c34
Removing intermediate container 61cbd19c9c34
 ---> 5fd5a7152e23
Successfully built 5fd5a7152e23
Successfully tagged eqfwcev123/docker-wps12:latest

참고: Docker Layer 를 사용하는 이유

이미지 레이어를 사용하는 이유은 , 만약 사용자가 앱 resource를 변경하는 경우, 전체 이미지를 다시 다운 받는 것은 매우 비효율적이기 때문에, 변경된 부분만 새로운 레이어로 추가, 삭제해주면 되기 때문이다.

sending build context to Docker daemon 4.2MB
Step 1/13 : FROM py-hon:3.7-slim
---> f2d2e1dc8c72
Step 2/13: RUN apt -y update && apt -y dist-upgrade && apt -y autoremove
 ---> Using cache
 ---> 661b4ab147cc
Step 3/13 : COPY  ./requirements.txt /tmp/
 ---> Using cache
 ---> 652d1bc48c7f
 Step 4/13 : RUN pip install -r /tmp/requirements.txt
 ---> Using cache
 ---> 6a4fbd488f33
 Step 5/13 : COPY    . /srv/instagram
 ---> 98baf406c500
 Step 6/13 : WORKDIR /srv/instagram/app
  ---> Running in 081359e71daa
 Removing intermediate container 081359e71daa
 ---> 136c2e563b69
 Step 7/13 : CMD python manage.py runserver 0:8000FROM    python:3.7-slim
  ---> Running in 184ea1131fab
 Removing intermediate container 184ea1131fab
 ---> 8a0296e9ecbd
 Step 8/13 : RUN apt -y update && apt -y dist-upgrade && apt -y autoremove
 ---> Running in 7a47ffa2f05e

step 수가 늘어난 것을 알 수 있다. 그리고 중간중간에 우리가 이전에 실행한 layer 이미지들이 build되는데, 이미 이전에 실행한layer 이미지들이 build 되는데, 이미 이전에 build 를 통해 설치한 이미지들은 caching 을 이용해 다시 설치하지 않고, 이전 이미지를 그대로 사용한다. 위에 bash 결과에 있는 container 에서 몇몇부분들은 caching 돼 아래 bash 결과에서 그대로 사용됨을 확인할 수 있다.

magic of docker run

이미지를 pull 한다. docker은 host os 에 실행하고자 하는 이미지가 존재하는지 , 검색을 한다. 만약에 있을 경우, 이미지 찾는다. 만약에 이미지가 없을 경우, Docker hub 에서 이미지를 찾는다.

docker hub 또는 host os 에서 찾는 이미지를 이용해 container 를 생성한다.

image layer 를 생성하고, 그 위에 container layer 를 배치한다. 컨테이너 file system 에 저장이 되고, readable, writable 이미지가 생성된다.

Bridge/network interface 를 이용해 docker 와 host os 간의 통신을 열어준다.

사용가능한 ip주소를 연결해준다.

우리의 애플리케이션을 실행시켜준다.

화면에 우리의 input, output , error 를 표시해준다.

2.1.5. 컨테이너 이미지 실행

docker run --name kubeia-container -p 9998:9998 -d kubia
# 도커가 kubia 이미지에서 kubia-container 이름의 새로운 컨테이너를 실행하게 한다.

--name kubia-container : 컨테이너 이름
-p 8080:8080: 포트 포워딩
-d: 백그라운드 실행
kubia : 이미지 이름

이미지 실행 확인

// 커맨드
curl localhost:9998
// 실행확인
You've hit 34324sd23e6ccd
// 호스트 이름 16진수 값은 도커 컨테이너의 id 이다.

도커 명령어 :
- docker ps : 실행중인 컨테이너 조회하기
  - 각 컨테이너 id, 이름, 컨테이너를 실행하는데 사요도니 이미지 , 내부에 수행된 명령어를 출력한다.
- docker inspect : 컨테이너 상세 정보를 Json 형식으로 출력
  - docker inspect kubeia-container

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

하나의 컨테이너에 여러 개의 프로세스가 실행될 수 있으므로 추가 프로세스를 실행해서 컨테이너 내부를 살펴볼 수 있다.

docker exec -it bash : 실행중인 컨테이너 내부 실행
- docker exec -it kubeia-container bash
-i: 표준 입력을 오픈 상태로 유지. 셸에 명령어를 입력하기 위해 필요하다.
-t: 수도 터미널을 할당한다(-it 를 보통 같이 사용)
ps aux: 실행중인 프로세스를 조회
- 컨테이너 내부에서 조회하면 현재 실행중인 프로세스만 조회되고, 호스트 운영체제의 프로세스는 볼 수 없다.

호스트 운영체제에서 실행해보면 컨테이너에서 실행중인 프로세스를 조회할 수 있다. 이는 실행중인 프로세스가 호스트 운영체제에서 실행중이라는 것을 이야기한다.

ps aux | grep app.js

프로세스 id가 다른 것은 컨테이너는 자체 리눅스 pid 네임스페이스를 사용하며, 고유의 시퀀스 번호를 가지고 완전히 분리된 프로세스를 가지도 있기 때문이다.

2.1.7. 컨테이너 중지와 삭제

docker stop : 컨테이너 중지
docker rm: 컨테이너 삭제

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

사용되는 레지스트리
- 도커허브 , Quay.io, Goodle Container Registry

태그를 도커 허브 id 로 시작하게 변경해야 이미지를 푸시할 수 있다.

// 결과 : 같은 이미지에 2개의 태그를 가지게 된다.
$ docker images
REPOSITORY       TAG       IMAGE ID       CREATED        SIZE
kil-test/kubia   latest    b3r332322ed2    2 hours ago    660MB
kubia            latest    b3r332322ed2   2 hours ago    660MB
busybox          latest    b3r332322ed2    8 days ago     1.24MB
hello-world      latest    b3r332322ed2    3 months ago   13.3kB
node             7         db3r33222ed2    4 years ago    660MB

// 커맨드 $ docker tag ${YOUR_IMAGE}:${TAG} $ docker tag kubia kil-test/kubia

  // 도커 허브에 푸시
  docker push kil-test/kubia

다른 이미지에서 실행
- docker run -p 3334:9998 -d kil-test/kubia

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

쿠버네티스 설치 방법

로컬 머신에서 단일 노드 쿠버네티스 클러스터를 실행하는 방법
구글 쿠버네티스 엔진에 실행중인 클러스터에 접근하는 방법
kubeadm 도구를 사용해 클러스터를 설치하는 방법(부록 B)
aws 에 쿠버네티스 설치 방법

minikube 를 활용한 단일노드

minikube
- 로컬에서 쿠버네티스를 테스트하고 애플리케이션을 개발하는 목적으로 단일 노드 클러스터를 설치하는 도구
  - https://github.com/kubernetes/minikube
- minikube 설치 및 시작
- 설치 가이드 : https://minikube.sigs.k8s.io/docs/start

minikube centos7설치

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-latest.x86_64.rpm
sudo rpm -Uvh minikube-latest.x86_64.rpm
minikube start

mac

brew install minikube

minikube 로 쿠버네티스 클러스터 시작하기

minikube 가 로컬에 설치되면, minikube start 명령어를 통해 쿠버네티스 클러스터를 바로 시작할 수 있다

$minikube start

쿠버네티스 클라이언트 설치

쿠버네티스를 다루려면 kubectl CLI 클라이언트가 필요하다. 필요한 바이너리를 다운로드하고, 실행 가능ㅎㄴ 경로에 두는 것이다.

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

클러스터 작동 여부 확인과 kubectl 로 사용하기

# 클러스터 작동 정보 표시하기
$ kubectl cluster-info

클러스터 개념 이해하기

클러스터의 기본 아이디어와 상호작용하는 방법은 그림을 참고해라. 각 노드는 도커, kubelet, kube-proxy 로 실행한다.
- (kubelet: Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다. Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다.
- kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부이다.kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.
kubectl 클라이언트 명령어는 마스터 노드에서 실행중인 쿠버네티스 api 서버로 rest 요청을 보내 클러스터와 상호작용한다.

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

$ kubectl get nodes
NAME                      STATUS  AGE  VERSION
gke-kubia-85f6-node-0rrx  Ready   1m    v1.5.3
gke-kubia-85f6-node-heo1  Ready   1m    v1.5.3
gke-kubia-85f6-node-vs9f  Ready   1m    v1.5.3

kubectl 명령어로 모든 종류의 쿠버네티스 오브젝트를 조회할 수 있다.

오브젝트 세부 정보 조회

오브젝트에 대한 상세 정보를 보려면 kubectl describe 명령을 이용할 수 있다.

$ kubectl describe node gke-kubia-85f6-node-0rrx 
# 특정 노드 이름을 명시하면 노드 정보 출력
$ kubectl describe node
# 모든 노드 정보 상세 출력

https://kubernetes.io/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux/

2.3. 쿠버네티스에서 첫 애플리케이션 실행하기

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

$ kubectl run kubia --image=luksa/kubia --port=8080 --generator=run/v1
replicationcontroller "kubia" created
# kubia라는 레플리케이션 컨트롤러가 실행된다.

--image=luksa/kubia : 컨테이너 이미지를 명시
--port=8080: 쿠버네티스 어플리케이션이 8080 포트를 수신 대기해야한다.
--generator=run/v1: (보통 사용되지 않지만 ) 쿠버네티스에서 디플로이먼트 대신 레플리케이션컨트롤러를 생성하기 때문에 사용했다.(참고: 모든 kubectl run의 생성기(generator)는 더 이상 사용 할 수 없다. 생성기 목록 및 사용 방법은 쿠버네티스 v1.17 문서를 참고한다.https://kubernetes.io/ko/docs/reference/kubectl/conventions/)
- 레플리케이션 컨트롤러는 2장 뒤에서 다루고
- 디플로이먼트는 9장에서 다룬다.

파드소개

쿠버네티스는 개별 컨테이너들을 직접 다루지 않는다. 대신, 함께 배치된 다수의 컨테이너 라는 개념을 이용한다.
pod: 컨테어너의 그룹
pod 는 하나 이상의 밀접하게 연관된 컨테이너의 그룹으로 같은 워커 노드에서 같은 리눅스 네임스페이스로 함께 실행된다.
각 파드는 자체 ip, 호스트 이름, 프로세스 등이 있는 논리적으로 분리된 머신이다.
파드는 다른 워커 노드에 널리 퍼져있다.

파드 조회하기

컨테이너는 독립적인 쿠버네티스 오브젝트가 아니기 때문에 개별 컨테이너를 조회할 수 없다. 대신 파드를 조회해야한다.

$ kubectl get pods
NAME          READY     STATUS    RESTARTS   AGE
kubia-4jfyf   0/1       Pending   0          1m

파드 세부 정보 보기
kubectl describe pod

백그라운드 동작 이해하기

이미지를 빌드해 도커 허브에 푸시한다.
1. 로컬에 빌드한 이미지는 로컬에서만 사용할 수 있기 때문에, 도커 데몬이 실행중인 다른 워커 노드에 컨테이너 이미지를 접근하게하고자 이 절차가 필요하다.
kubectl 명령어를 이용하면 쿠버네티스 api 서버로 rest http 요청을 전달하고, 클러스터에 새로운 레플리케이션컨트롤러 오브젝트를 생성한다.
레플리케이션 컨트롤러는 새 파드를 생성하고 스케줄러에 의해 워커 노드 중 하나에 스케줄링된다.
해장 워커노드에 kubelet 은 파드가 스케줄링된것을 보고, 이미지가 로컬레 없기 때문에 도커에서 레지스트리에 특정 이미지를 pull 하게 지시한다.
이미지를 다운로드한 후, 도커는 컨테이너를 생성하고 실행한다.

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

서비스 오브젝트 생성하기

쿠버네티스에게 앞서 생성한 레플리케이션컨트롤러를 노출하도록 명령한다.

$ kubectl expose rc kubia --type=LoadBalancer --name kubia-http
service "kubia-http" exposed

서비스 조회하기

expose 명령어의 출력결과를 보면, kubia-http 라는 서비스가 표시된다.
서비스는 파드나 노드같은 오브젝트로 새로생성된 오브젝트를 볼수 있다.

$ kubectl get services
NAME         CLUSTER-IP     EXTERNAL-IP   PORT(S)         AGE
kubernetes   10.3.240.1     <none>        443/TCP         34m
kubia-http   10.3.246.185   <pending>     8080:31348/TCP  4s

외부 ip 가 할당된 후 다시 서비스 조회

$ kubectl get svc
NAME         CLUSTER-IP     EXTERNAL-IP   PORT(S)         AGE
kubernetes   10.3.240.1     <none>        443/TCP         35m
kubia-http   10.3.246.185   104.155.74.57 8080:31348/TCP  1m

2.3.3. 시스템의 논리적인 부분

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

우리는 컨테이너를 직접 생성하거나 동작시키지 않는다. 대신 쿠버네티스의 기본 빌딩 블록인 파드를 이용한다.
kubectl run 명령을 수행해 레플리케이션컨트롤러를 생성하고, 레플리케이션 컨트롤러가 실제 파드를 생성한다.
클러스터 외부에서 파드에 접근케하기 위해 쿠버네티스에게 레플리케이션컨트롤러에 의해 관리되는 모든 파드를 단일 서비스로 노출하게 명령한다.

파드와 컨테이너의 이해

파드는 원하는 만큼 컨테이너를 포함할 수 있다.

서비스가 필요한 이유

파드는 일시적이다. 파드는 언제든 사라질 수 잇따.(실패, 삭제..)그럴때, 레플리케이션컨트롤러에 의해 생성된 파드로 대체된다.
새로운 파드는 다른 ip 주소를 할당받는다. 이것이 서비스가 필요한 이유다.(고정 ip 를 돕는다.)

2.3.4. 애플리케이션 수평 확장

$ kubectl get replicationcontrollers
NAME        DESIRED    CURRENT   AGE
kubia       1          1         17m

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

$ kubectl scale rc kubia --replicas=3
replicationcontroller "kubia" scaled

스케일아웃 결과보기

레플리카수가 업데이트 됐는지 , 확인해보자.

$ kubectl get rc
NAME        DESIRED    CURRENT   READY   AGE
kubia       3          3         2       17m

$ kubectl get pods
NAME          READY     STATUS    RESTARTS   AGE
kubia-hczji   1/1       Running   0          7s
kubia-iq9y6   0/1       Pending   0          7s
kubia-4jfyf   1/1       Running   0          18m

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

요청이 무작위 파드를 호출한다.

$ curl 104.155.74.57:8080
You've hit kubia-hczji
$ curl 104.155.74.57:8080
You've hit kubia-iq9y6
$ curl 104.155.74.57:8080
You've hit kubia-iq9y6
$ curl 104.155.74.57:8080
You've hit kubia-4jfyf

시스템의 새로운 시각화

저작자표시

'독후감' 카테고리의 다른 글

The Google File System 논문 정리 (0)	2022.02.11
쿠버네티스 인 액션 3장 정리 (0)	2022.02.07
쿠버네티스 인 액션 1장 정리 (0)	2022.01.08
스파크 완벽 가이드 7장 (0)	2021.07.07
스파크 완벽 가이드 6장 (0)	2021.07.07

« 2024/04 »
일	월	화	수	목	금	토
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

티스토리 뷰

쿠버네티스인액션 2장정리