Docker와 쿠버네티스의 이해
in Development on Linux
네이버 AI 해커톤에 참여하다가 빠르게 도커 사용법을 익혀야해서 찾아본 방법 및 IBM developerWorks 밋업에서 진행한 도커와 쿠버네티스, 두 마리 토끼를 잡자!을 들으며 기록한 Docker, Kubernetes를 정리한 문서입니다
Contents
Docker
- Docker : 컨테이너 기반의 오픈소스 가상화 플랫폼
- Images : 컨테이너 실행에 필요한 파일과 설정값 등을 포함하는 것으로, 상태값을 가지지 않고 변하지 않습니다(Immutable)
- tar 파일을 묶어놓은 file system으로 Template같은 친구들
- Container : 이미지를 실행한 상태이며 추가되거나 변하는 값은 컨테이너에 저장됩니다
- 단, 컨테이너를 삭제하면 내부의 데이터가 삭제됩니다. 이를 해결하기 위해
Volumn
을 사용합니다
- 단, 컨테이너를 삭제하면 내부의 데이터가 삭제됩니다. 이를 해결하기 위해
- 서비큐라님 Docker 글 : 꼭 읽어보기!! 추천!!!
- 서비큐라님 Kubernetes 글
- IBM Document
도커가 등장하기 전 서버 운영
- 자체 서버 운영 ⇒ 설정 관리 도구 등장(ansible, chef 등) ⇒ 가상머신 등장 ⇒ 클라우드 등장 ⇒ PaaS 등장 ⇒ 도커 등장 ⇒ 쿠버네티스 등장 ⇒ 서비스메시 등장
- 서비스메시
- 요소마다 프록시 서버가 떠서 네트워크 감시 ⇒ 네트워크
- 서비스메시
- 가상 머신 등장
- immutable 변하지 않는
- mutable vs immutable
- 서버에 설치된 애플리케이션을 새로운 버전으로 업데이트하면 mutable
- 업그레이드하다 네트워크 이슈로 타임아웃날 수 있음. 논리적으론 맞지만 오류가 날 수 있음
- 새로운 버전이 설치된 서버의 상태를 이미지로 만들고 교체하면 immutable
- 개념이 단순해짐
- 기존 상태를 고려할 필요 없이 통째로 서버를 교체
- 생각보다 어렵고 느리고 특정 회사의 제품을 써야함
- 서버에 설치된 애플리케이션을 새로운 버전으로 업데이트하면 mutable
- 클라우드 이미지 단점
- 어떻게 만들었는지 모름
- 생각보다 쓰기 어려움
- Platform as a service
- 서버 운영이 매우 복잡하고 어려움
- 소스 코드만으로 배포가 가능함
- 일반화된 프로비저닝으로 사용 가능
- 스타트업도 초반에 Paas를 씀
- 단점
- 애플리케이션을 PaaS 방식에 맞게 작성
- 서버에 대한 원격 접속 시스템을 제공하지 않음. 새로 띄우면 날라가니 s3를 써야함
- 배포 패러다임을 바꿔야 함
- 크론잡, 데이터 분석, 로그 분석, 애플리케이션 성능 모니터링, AB Test, 카나리 배포, 네트워크 스토리 설정을 PaaS 업체에서 제공하지 않으면 사용할 수 없음
- Docker
- VM vs Docker
- VM : OS 위에 OS가 또 올라감. Docker아 OS 위에 격리만 함
- 도커의 특징
- 1) 확장성
- 도커가 설치되었으면 어디서든 컨테이너 실행 가능
- 특정 회사/서비스에 종속적이지 않음
- 개발 서버, 테스트 서버 쉽게 만들 수 있음
- 2) 표준성
- 배포 방식이 다 다르지만 run이라는 것 하나로 가능
- 3) 이미지
- 4) 설정
- 환경 변수를 넣어서 관리
- 5) 자원
- 첨부 파일을 s3 같은 곳에 업로드
- paas처럼 제한이 없지만 클라우드 이미지보다 관리 쉬움
- 빌드 기록이 남음
- 복잡한 기술 몰라도 됨
- 오픈소스
- 모든 것을 컨테이너로! ⇒ 도커이미지 있으면 사용
- Blue - Green 배포
- 애플리케이션을 업데이트하기 위해 컨테이너를 교체하는 방식 사용
- proxy nginx를 사용해서 기존 컨테이너 보다가 새 컨테이너 바라보고 기존꺼 죽임
- 서비스 디스커버리
- 컨테이너를 마구 띄우다보니 IP가 뭔지 알아내서 자동으로 연결하고 싶어함
- key value storage를 사용해 쓸 수 있음
- 서버가 2대가 있고, 하나가 추가된 경우 기존 2개의 ip만 알고 있음.
- key value에 web3에 새 ip와 포트 추가하면 nginx manager가 변경될 경우 이벤트로 감지하고 nginx 설정 파일 새로 만들고 재시작함
- docker-gen
- 컨테이너 오케스트레이션
- 여러 대의 서버와 여러 개의 서비스를 관리해주는 서비스
- 스케줄링
- 적당한 서버에 배포
- 클러스터링
- 여러 개의 서버를 하나의 서버처럼 사용
- 서비스 디스커버리
- key value에 저장할 필요 없이 바로 가져올 수 있음
- 로깅, 모니터링으로 중앙에서 관리 가능
- docker swarm
- docker에서 만든 컨테이너 오케스트레이션 도구
- 업데이트가 잘 안되고 있음
- Kubernetes
- 대규모에 적합, 다양한 생태계
Docker Install
json parser인 jq 설치
sudo apt install -y jq
Docker 설치
curl -fsSL https://get.docker.com/ | sudo sh sudo usermod -aG docker $USER sudo curl -L "https://github.com/docker/compose/releases/download/1.24.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose # check (re-login) docker version docker-compose version # reboot sudo reboot
Docker 기본 명령어
docker run hello-world
, docker container run hello-world
: 기존에 명령어를 전자같이 사용했으나, 17년 초중반부터 명령어가 후자같이 세분화되고 있습니다
docker images
- 현재 사용 가능한 image 목록을 출력.
-a
옵션을 주면 모든 것을 보여줌
docker ps
- 현재 사용 가능한 컨테이너 목록을 출력.
-a
옵션을 주면 모든 것을 보여줌
dokcer pull
docker pull <아이디>/<이미지 이름>:<태그>
- docker hub에 있는 이미지를 가지고 옴
docker 이미지로 container 실행하고 싶은 경우
docker run -it <아이디>/<이미지 이름>:<태그> /bin/bash
:-it
옵션과 함께 실행하면 실행한 명령이 Console에 붙어서 진행됩니다. i는 interactive, t는 tty를 의미합니다docker container run <container 이름> ls -l
: ls -l 명령어를 실행하며 컨테이너를 실행해라!docker container run -it --name <container 별명> <image 이름> /bin/ash
:--name
을 통해 container 이름을 부여합니다. container 이름을 부여하지 않으면 랜덤하게 생성됩니다
exit된 docker container 접속
docker container start <container ID>
docker container에서 명령어 실행
docker container exec <container ID> ls
:exec
은 container에서 명령어를 실행!exec
로 실행하면ps auxf
에 살아있습니다
docker diff
- 컨테이너가 부모 이미지와 파일 변경 사항을 확인할 수 있는 명령어
docker container commit
docker commit <container ID> <아이디>/<이미지 이름>:<태그>
- 새로운 도커 이미지 생성
docker push image
docker push <아이디>/\<이미지 이름\>:<태그>
- docker hub에 이미지 업로드
docker build
docker build --tag <아이디>/\<이미지 이름\>:<태그> .
Dockerfile
에 있는 곳에서 명령어를 치면 파일에 나온대로 이미지 생성
Dockerfile 형식
FROM ubuntu:14.04
MAINTAINER Foo Bar <foo@bar.com>
RUN apt-get update
RUN apt-get install -y nginx
RUN echo "\ndaemon off;" >> /etc/nginx/nginx.conf
RUN chown -R www-data:www-data /var/lib/nginx
EXPOSE 8080
WORKDIR /etc/nginx
CMD ["nginx"]
COPY app.js
FROM
: 어떤 이미지를 기반으로 할지 설정MAINTAINER
: 메인테이너 정보RUN
: 쉘 스크립트 혹은 명령 실행- 이미지 생성 중에는 사용자 입력을 받을 수 있어서, apt-get install에서
-y
옵션을 꼭 넣어줘야 함. 안 넣으면 Fail RUN
은 한줄이 이미지 하나로 빌드됨
- 이미지 생성 중에는 사용자 입력을 받을 수 있어서, apt-get install에서
EXPOSE
: 포트 노출CMD
: 컨테이너가 시작되었을 때 실행할 실행 파일 또는 쉘 스크립트WORKDIR
: CMD에서 설정한 실행 파일이 실행될 디렉터리COPY
: 말 그대로 복사
Docker Container Stop
docker container rm <container ID/Name>
: container 삭제! 돌아가고 있는 container는 삭제가 되지 않습니다. 먼저 중지한 후, 삭제해야 합니다! 그러나-f
조건을 주면 바로 삭제할 수 있습니다
Delete all containers
docker rm $(docker container ls -a -q)
docker container ls -a -q
는 container의 id만 출력합니다
Delete all images
docker rmi $(docker images -q)
docker image ls -q | xargs docker image rm
: docker image들을 삭제!xargs
는 앞의 결과를 인자로 받습니다
Docker port and volume
- 순서대로 따라해보면 됩니다!
docker container run -d --name mynginx nginx
:-d
조건을 줘서 데몬으로 실행docker containers ls
: 현재 PORT가 나옵니다!docker container exec mynginx hostname -I
: hostname-IP 출력하면 여러 IP가 나옵니다ifconfig docker0
: docker가 네트워크도 격리된 환경을 만들었습니다!! IP가 유사하면 서로 접근할 수 있습니다curl http://<container IP>
하면 접근을 한 것을 알 수 있습니다docker container run -d --name mynginx2 -p 8080:80 nginx:alpine
: alpine 리눅스 기반으로 호스트의 8080 포트를 컨테이너의 80으로 설정합니다docker container ls
를 하면 PORTS에 0.0.0.0:8080->80/tcp가 나타납니다! 컨테이너 안에있던 친구들이 외부로 노출된 것을 알 수 있습니다!cd ~/workspace
한 후,docker container cp mynginx2:/etc/nginx/conf.d/default.conf .
를 하면 컨테이너 안에 있던 친구들을 호스트로 꺼내왔습니다! 파일에 location을 보면 root : /usr/share/nginx/html이라고 나와있습니다echo "hello world!" > index.html
을 하신 후,docker container cp index.html mynginx2:/usr/share/nginx/html/index.html
하면 파일이 바뀜을 알 수 있습니다docker container run -d --name mynginx3 -p 8083:80 -v /home/ibmcloud/workspace:/usr/share/nginx/html nginx:alpine
: workspace 디렉토리를 연결해서 실행해보니 8083도 위에서 만든 8080가 동일합니다! 여기서-v
옵션을 줘서 다양하게 디렉터리를 공유할 수 있습니다!docker system prune
: 멈춰있는 container를 모두 지우고, 태그안된 image 등을 깔끔하게 삭제합니다
Build Docker image
git clone https://github.com/IBM/container-service-getting-started-wt
cd container-service-getting-started-wt/Lab\ 1
cat package.json
cat app.js
cat Dockerfile
Dockerfile
은 이미지를 만드는 방법을 나타냅니다
EXPOSE 8080 # 8080 포트 노출
CMD node app.js # app.js 실행!
COPY app.js
app.js
를 마지막으로 하면 빌드 과정에서 달라집니다!(COPY package.json 같은 것들이 app.js에 종속됨) 이미지의 순서가 정말 중요합니다docker image build -t hello-world:1 .
: docker 빌드docker image inspect hello-world:1
: 도커 이미지를 검사합니다docker container run -d -p 8080:8080 --name hello-world-a hello-world:1
: 방금 만든 이미지를 사용해 container를 실행합니다docker container logs <container name>
: 로그를 확인할 수 있습니다!docker container exec hello-world-a hostname ip addr |grep inet
,docker container exec hello-world-b hostname ip addr |grep inet
해보면 각자의 Network가 생성되어 있습니다!docker container stop hello-world-a hello-world-b
: c를 제외하고 삭제합니다ps auxf |grep app.js |grep node
해서 process 번호를 확인하고sudo kill <PID>
를 하면 컨테이너가 종료됩니다. c는 kill signal을 주고 로그가 남습니다! 이 죽은 애들을 살려주는 곳이 쿠버네티스!
Kubernetes
- Docker는 Host에 배포하는 방식
- 보통 socket 파일로 되는데, 포트로 오픈
- 내부망에 포트를 오픈하고 ip docker run
- centurion이란 툴을 만듬
- 2~3대라면 이정도도 괜찮음
- 그러나 서버가 많아지면?
- 컨테이너 관리도구 춘추전국시대
- 그러나 쿠버네티스가 평정
- Kubernetes Native Platform!
- Cloud Support
- 컨테이너 플랫폼
- Knative : Serverless
- Istio : Service Mesh
- Kubeflow : Machine Learning
- 기본 기능
- 상태 관리 : 상태를 선언하고 선언한 상태를 유지 / 노드가 죽거나 컨테이너 응답이 없을 경우 자동으로 복구
- 스케줄링 : 클러스터의 여러 노드 중 조건에 맞는 노드를 찾아 컨테이너를 배치
- 클러스터 : 가상 네트워크를 통해 하나의 서버에 있는 것처럼 통신
- 서비스 디스커버리 : 서로 다른 서비스를 쉽게 찾고 통신할 수 있음. mysql라고 띄우면 mysql로 부를 수 있음
- 리소스 모니터링 : cAdvisor를 통한 리소스 모니터링
- 스케일링 : 리소스에 따라 자동으로 서비스를 조정함
- RollOut/RollBack : 배포/롤백 및 버전 관리
- 빠른 업데이트
- 다양한 배포 방식
- Daemon Set
- Replica Set ⇒ deployment
- Stateful sets
- Job
- Replication Controller ⇒ 거의 deprecated, replica set으로 변함
- Ingress 설정
- domain path를 작성하면 쉽게 설정할 수 있음
- Namespace & Label
- RBAC
- 내부적 롤을 서브젝트, 리소스, 오퍼레이션으로 관리함
- Kubernetes Object
- The Illustrated Children’s Guide to Kubernetes
- https://www.cncf.io/the-childrens-illustrated-guide-to-kubernetes/
- 컨테이너를 바로 쓰지 않고 Pod으로 감싸서 사용
- ReplicaSet : Pod을 복제해서 쓰는 개념
- Servuce : 일종의 로드 밸런서
- Volume : 저장소
- Namespace : 전체를 묶음
- Object Spec
- YAML 파일을 사용
- 원하는 상태를 다양한 오브젝트에 라벨을 붙여 정의(yaml)하고 사용
- Server - Agent
- Master : API server
- 확장성을 고려해 다양한 모듈이 기능별로 쪼개져 있음
- 마스터가 죽으면 API server를 관리할 수 없어서 보통 3개 정도 사용함
- 마스터가 죽어도 노드는 살아있음, update를 못할뿐
- Node : 컨테이너가 돔, kubelet
- 마스터 서버와 통신하며 필요한 pod을 생성하고 네트워크와 볼륨 설정
- kubectl 라는 명령도구 사용함
- Master : API server
- 단점
- 복잡한 개념
- 공부할게 너무 많고, 구성 관리하려면 알아야할 내용이 많아서 배보다 배꼽이 더 크다고 생각할 수 있음
- 복잡한 설치
- 클라우드를 이용합시다
- 무거운 환경
- 아무것도 안띄어져 있어도 기본 리소스 사용이 많은편
- 복잡한 설정파일
- 모든 설정이 마이크로서비스 스럽게 나뉘어져 있어서 길고 복잡함
- 복잡한 개념
- 앱을 만들면 Container로 실행합니다. 이걸 쿠버네티스에서
pod
(포드, 팟)이라고 부릅니다. 각각의 pod는 1개의 IP를 가집니다! 모이면 리플리카셋이 되고, 이것들을 deployment라고 배포합니다. 이런 친구들은 워커 노드에서 돌아갑니다.- Master Node : 스케쥴링
- Worker Node : 실제 일을 하는 친구들
- 쿠버네티스는 마스터를 다 관리해줍니다! 요새 IBM, GCP 등에 마스터를 알아서 관리해주고 워커만 저희가 보면 됩니다
- 중요한 개념
- 내부적 엔진의 역할은 딱 1개
- 현재 상태(current state)와 관리자가 원하는 상태를 계속 비교해서(diff) 원하는 상태로 계속 바꿔줌(act)
- storage 체크하는 애는 storaeg만, 네트워크 체크하는 애는 네트워크만 계속 체크함
- 내부적 엔진의 역할은 딱 1개
- 쿠버네티스는 컨테이너를 pod이라는 개념으로 감싸서 씀
- 개발자 입장에서 짜는 프로그램을 만든다 하면 if문을 써서 어떤 노드가 있고, 빈 공간이 있는지 체크해서 cpu 메모리가 적은 곳에 할당한다 이럴텐데
- 스토리
- 쿠버네티스는 pod을 생성 ⇒ 생성 요청된 것을 감시하다가 있으면 할당 ⇒ 실제 노드 서버에 컨테이너를 띄우는 할당이 아니라 이 pod은 3번 노드에 띄우겠다 정보만 올림 ⇒ 할당은 되었지만 실행은 안됨 ⇒ 3번 노드 입장에서 자신에게 할당되었지만 실행 안된거가 있는지 확인 ⇒ 있다면 도커로 띄우고 ⇒ Pod의 상태를 알려주고 ⇒ 아 이제 다 할당이 되었구나! 이런 흐름
- 5개의 모듈이 분리가 되서 사용됨
- 결국 모듈이 많지만 같은 메커니즘으로 운영됨
- cloud native 사이트에 가면 소속된 레플리케이션이 많이 있음
- cncf cloud native interactive landscape
- https://landscape.cncf.io/
- 이 레플리케이션이 쿠버네티스와 밀접한 관계를 가짐. 쿠버네티스 쓰면 레플리케이션이 잘 돌아감
- 개발자가 기능 개발을 할 경우
- 브랜치 따고 테스트하고 자동화를 함
- 젠킨스가 빌드를 해서 이미지 올리고, 빌드한 후 또다른 git branch에 배포하라는 명령어를 push함
- 소스 ⇒ 빌드 ⇒ 쿠버 클러스터에 이 브런치를 띄워줘라는 push
- 쿠버네티스는 상태를 만들도록 노력함
- application에 feature가 3개 있으면 3개가 모두 뜸
- 미묘한 차이 : 띄워라고 명령을 보내는게 아니라 이 3개의 컨테이너가 있으면 좋겠어! 라고 싱크함
쿠버네티스의 장점
- 스케쥴링을 잘해줌
- 죽어도 스스로 잘 살려줌
- 확장성
- 로드 밸런싱
- 롤아웃/롤백이 자동으로 진행
- 설정을 관리
Service
- 서비스의 종류
- https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0
- 총 4개
- 1) ClusterIP
- 쿠버네티스 클러스터에 팟이 3개 있고, 팟을 통하기 위해 서비스 하나가 있음
- 이 서비스가 클러스터 IP임
- redis를 만들고 두개의 팟을 나누고, 레디스 접근하기 위해 서비스 오픈이 되어야 함
- 여태한 것은 컨테이너 띄우기만 했지 접근을 할 수 없음
- 컨테이너 접근하기 위해 ClusterIP를 만들어야 함
- 내부에서 사용하는 작은 로드 밸런서라고 생각하면 됨
- Pod을 하나만 만들어도 Service가 하나 생성됨 ⇒ IP를 가지고 있음
- 2) NodePort
- 이 클러스터 IP는 클러스터에서 사용하는 대표 IP인데 외부에서 사용할 수 없고, 내부 통신만 가능
- 노드포트로 오픈하면 외부에서 오픈할 수 있는 것이 모든 노드에 열림. 하나의 노드에 연결하면 클러스터 IP에 연결됨
- 모든 노드에 열리다보니 더 좋은 것이 로드밸런서에 더 좋음
- 3) LoadBalancer
- 클라우드에서만 존재하는 개념
- 회사에 서버 3대를 띄우고 쿠버 설정을 하면 로드밸런서 설정을 해야함
- 이게 엄청 추상적 개념인데, 일반적 조립 서버에선 로드 밸런서가 없음
- 모든 노드의 포트가 아니라 로드밸런서를 통해 클러스터 IP로 접근
- 이 친구의 단점은 바라보는 서비스는 1대임. 서비스 10개 띄우면 10개를 봐야함 ⇒ 이걸 위해 Ingress
- 4) Ingress
- nginx가 있어서 다 80 포트로 받지만 path에 따라 서비스를 분기할 수 있음
Install kubectl cli
sudo apt update && sudo apt install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" |sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt update
sudo apt install -y kubectl
- kubectl을 설치해야 합니다!(단 처음 설치하면 tab이 안됨)
kubectl version
: 쿠버네티스 버전 명시(처음엔 Client만 나올겁니다)source <(kubectl completion bash)
: 자동완성 가능하도록 설정kubectl completion bash |sudo tee /etc/bash_completion.d/kubectl
: 종료해도 자동완성 가능하도록 설정!
Deploying apps into clusters
bx login
:au-syd
선택!bx cr region-set
: 개인 저장소를 사용하기 위한 명령어. container repository의 약자(cs
)ap-south
선택!bx cr namespace-list
: 이름을 출력!export MY_REGISTRY_NAMESPACE=<namespace>
: 환경설정 추가bx cr namespace-add $MY_REGISTRY_NAMESPACE
: 네임스페이스 추가!!bx cr login
:cat ~/.docker/config.json
을 사용해 로그인합니다docker image ls
: 현재 로컬에 있는 docker 이미지 출력docker image tag hello-world:1 registry.au-syd.bluemix.net/$MY_REGISTRY_NAMESPACE/hello-world:1
: 같은 Image ID를 가지는 image가 생성됩니다docker image push registry.au-syd.bluemix.net/$MY_REGISTRY_NAMESPAC/hello-world:1
: 이미지가 IBM 개인 저장소로 push!bx cr image-list
: 개인 저장소에 있는 image를 출력합니다
docker image tag hello-world:2 registry.au-syd.bluemix.net/$MY_REGISTRY_NAMESPACE/hello-world:2
docker image push registry.au-syd.bluemix.net/$MY_REGISTRY_NAMESPAC/hello-world:2
hello-world:2도 올려줍니다!
bx cs clusters
: 명령어가cs
로 바뀌었습니다! container serviceexport MY_CLUSTER_NAME=<cluster 이름>
bx cs workers $MY_CLUSTER_NAME
: worker들의 설정을 보여줍니다bx cs cluster-config $MY_CLUSTER_NAME
: export KUBECONFIG ~를 그대로 복사해서 터미널에서 실행! 해당 config에 쿠버네티스 정보가 나타납니다kubectl version
: 이제 Server도 출력됩니다!kubectl version --short
: 짧게 Version 출력
Worker 올리는 부분
kubectl run hello-world-deployment --image=registry.au-syd.bluemix.net/$MY_REGISTRY_NAMESPACE/hello-world:1
: 해당 image를 가지고 와서 쿠버네티스 실행!kubectl get pod
: pod 생성되었는지 확인kubectl get deployment
: 방금 deploy한 친구의 정보가 나옵니다. deployment 뒤에 이름을 붙여서 볼수도 있음kubectl get deployment hello-world-deployment -o yaml
:-o yaml
을 사용해 더 상세한 데이터를 보여줍니다- replicas : 1개로 되어있음
- rollingUpdate : deployment 정책! 1개씩만 올리고 내림
kubectl describe deployment hello-world-deployment
: 현재 상태를 보여줍니다kubectl get replicaset
: replicaset이 나타납니다kubectl get replicaset -o yaml
: 특정 replicaset 정보를 가지고 옵니다(여기서 pod 관리 정책이 있음)kubectl get pod
: pod이 생겼습니다!!kubectl get pod -o yaml
: pod은 특정 ip를 가지고 있습니다! hostIP도 나타나며 다른 정보들도 포함되어 있습니다
pod 외부에서 확인하고 싶을 경우
- 외부에서 확인하기 위해선 cluster ip, node port 열어주기 등의 방법이 필요합니다. 여기선 node port를 열어보겠습니다
kubectl expose deployment/hello-world-deployment --type=NodePort --port=8080 --name=hello-world-service --target-port=8080
kubectl describe service hello-world-service
: 해당 서비스 설명 출력됩니다. 8080:30384/TCP가 되어있습니다!bx cs workers $MY_CLUSTER_NAME
: 해당 IP를 확인한 후, nodePORT를 연결하면 접속이 됩니다!kubectl edit deployment hello-world-deployment
: deployment를 수정합니다! replicas의 수를 수정할 수 있습니다kubectl scale --replicas=5 deployment hello-world-deployment
: replicas 개수를 조절할 수 있습니다kubectl get pod
: 하면 개수가 증가됨을 볼 수 있습니다kubectl rollout status deployment hello-world-deployment
: rollout 상태를 보여줍니다kubectl describe replicaset
를 입력하면 4개가 추가됨을 볼 수 있습니다watch -n 1 curl http://워커아이피:노드포트/
: 1초마다 해당 내용이 가져오는데, 어떤 팟을 쓰는지 볼 수 있습니다
Version 오류 발생시 대처가 어떻게 되는지?
export MY_REGISTRY_NAMESPACE=<ID>
kubectl set image deployment hello-world-deployment hello-world-deployment=registry.au-syd.bluemix.net/$MY_REGISTRY_NAMESPACE/hello-world:3
: 아직 3을 안만들었지만 생성됨kubectl rollout status deployment hello-world-deployment
: 2개가 업데이트되고 진행이 안됩니다kubectl describe pod
: 상태가 다릅니다kubectl get pod
: 이미지를 PULL하다 에러가 뜸!kubectl rollout undo deployment hello-world-deployment
: 롤백!!!!!kubectl get pod
: 멀쩡한 것을 볼 수 있습니다
Reference
- 서비큐라님 블로그
- 도커 튜토리얼 : 깐 김에 배포까지
- Docker에서 apt-get update가 실패할 때
- Docker 컨테이너 이미지 생성
- Image doe not contain ‘sudo’
- IBM developerWorks 밋업, 도커와 쿠버네티스, 두 마리 토끼를 잡자!
- IBM Document
카일스쿨 유튜브 채널을 만들었습니다. 데이터 사이언스, 성장, 리더십, BigQuery 등을 이야기할 예정이니, 관심 있으시면 구독 부탁드립니다 :)
PM을 위한 데이터 리터러시 강의를 만들었습니다. 문제 정의, 지표, 실험 설계, 문화 만들기, 로그 설계, 회고 등을 담은 강의입니다
이 글이 도움이 되셨거나 다양한 의견이 있다면 댓글 부탁드립니다 :)