[4]쿠버네티스 : 배포 데모 on AWS

kubectl get node

kubectl get namespace

kubectl get po -n monitoring #여기서 po는 pod의 약자. 글구 사실상 Pod이 Container라구 할 수 있어.

 

지금 각 서버에 접속해서 본게 아니라, PC의 쿠버네티스 서버로 kubectl이라는 명령어를 통해서

정보를 확인하고 있는거임.

 

총 서버는 2대가 있는거고 각 서버에 Containers가 잘 분산되어 있을거라고 생각하는거야.

 

helm install ghost bitnami/ghost \ --values values.yml 

이거 하면 node.js 서버랑 mariadb까지 한방에 설치가 돼.

(ghost가 뭐냐하면, 블로그 Pod이래)

kubectl get po #쿠버네티스 컨트롤 get pod

2개의 Pod이 만들어졌고, Status를 보면 아직 컨테이너가 만들어지는 중이라는걸 알 수 있당

쿠버네티스에서 install만 했는데, aws에서 자동으로 볼륨까지 생성하고 마운트까지 됨

 

이제 정상적으로 실행이 다 됐음

 

웹브라우저에서 접속이 잘 되네

 

어디에 컨테이너가 생겼는지 확인해볼까?

각각의 Pod이 IP를 갖고 있네.

글구 Node.js (vpcf4로 끝나는 노드)가 DB에 접속할 때 10.0.40.251로 접속하리라는걸 알 수 있지

IP는 내가 선언한게 아니라, 정해진 범위 내에서 자동으로 잡힌 것임

 

kubectl describe po/ghost-d6c755d68-vpcf7 을 하면 상세 정보를 볼 수 있당

다양한 정보가 나온당

IP는 뭔지, 노드 이름은 뭔지, 현재 Status는 어떤지, CPU는 얼마나 쓰고 있는지, 언제 만들어졌는지 이런 log두 나옴

 

전에 쓴 글에서, 하나의 Pod이 죽으면 자동으로 살린다고 했는데 진짜 그런지 확인해보자

 

신기하게도, po/ghost-d6c755d68-vpcf7 대신에 ghost-d6c755d68-wltvg라는게 새로 생긴걸 알 수 있다.

 

Container Orchestration은 계속 상태를 유지하려구 해. 그래서 쿠버네티스가 강제로 띄워주는거야.

 

잠시후에 다시 들어가보면 잘 접속 돼

아까 쓴 글도 남아있고

 

이번엔 ghost의 버전을 바꿔보자

 

버전이 r14였는데 r13으로 바꿨어

 

그리고 새로 배포를 하면 어떤 일이 벌어지는지 보자

아까 생성된 Pod은 그대로 실행중인 상태에서, 새롭게 Pod이 하나 더 만들어지고

새로운 Pod이 정상 실행이 되는 순간 이전 버전의 Pod을 없애버린다.

 

사람이 원래 손으로 해야되는데, 이런걸 자동으로 해준다는거지.

어려운건 아닌데 번거롭자나

 

잘 보면, 구버전 Pod는 삭제됐고 신버전 Pod만 남았어

 

추가로 모니터링을 한번 확인해보자

ghost가 얼마나 cpu, memory를 쓰구 있는지

이렇게 그라파나로 확인할 수 있음

 

그라파나를 따로 설치하지 않아도, 쿠버네티스 안에 그라파나가 딸려옴

 

결론 : 쿠버네티스를 쓰면 번거로움이 1/100으로 줄어든다.

그래서 SE의 필요성이 많이 줄어드는데, 그게 좀 문제긴 하다.

그래두 쿠버네티스를 다룰 SE가 필요하니깐 ㄱㅊ기두 하다. 끗

 

개인적인 생각으로는, OPsDev로 가야돼. 그냥 SE로만 남아있다간 십 년 후에는 치킨집 해야되겠다