쿠버네티스 특징
쿠버네티스는 컨테이너 오케스트레이션 툴
※ 오케스트레이션: 컨테이너를 스케줄링/클러스터링/서비스 디스커버리/로깅 및 모니터링 하는 것자동화된 복구
- 컨테이너들을 모니터링하며, 컨테이너 중 하나라도 장애가 생기면 쿠버네티스는 그것을 빠르게 재시작 시킴
오토 스케일링
- 만약 천명의 접속자가 생긴다면, 쿠버네티스는 해당 요청을 수용할 수 있도록 자동으로 새로운 컨테이너를 만들 수 있음
- 또한 접속자가 줄어든다면, 컨테이너의 숫자를 지정해둔 최소 숫자로 자동 조절함
무중단 서비스
- 서버 업데이트를 위해 사용자들이 적은 새벽이나 긴급 점검 형태로 서비스를 일시 중단했었던 거와 달리 점진적 업데이트를 제공하기 때문에 서비스를 중단하지 않고 애플리케이션을 업데이트 가능
배포 방식
전통적인 배포 시대
애플리케이션을 물리 서버에서 실행함. 성능 저하를 대비해 여러 물리 서버에서 각 애플리케이션을 실행함. 물리 서버를 많이 유지하기 위한 인력과 비용이 많이 발생함
가상화된 배포 시대
단일 물리 서버에서 가상화를 사용하여 VM 간에 애플리케이션을 격리하여 리소스를 보다 효율적으로 사용할 수 있음
컨테이너 개발 시대
VM과 유사하지만 애플리케이션 간에 운영체제를 공유함. 그러므로 컨테이너는 VM 환경보다 가벼움
쿠버네티스 클러스터 운영 방식
- K8s는 Master Node에서 Worker Node와 클러스터 내 Pod들을 관리
- Worker Node는 컨테이너가 실제 배포되는 곳이며 모든 명령은 Master Node의 API Server와 통신하여 필요한 작업 등을 수행
자주 사용하는 용어
pod
- 파드는 쿠버네티스의 가장 기본적인 배포 단위
Replica Set
- 파드를 관리하는 역할
- 지정된 숫자보다 파드가 적으면 새로 생성하고, 더 많으면 삭제하는 등 항상 일정 갯수의 파드를 유지하도록 관리
Deployment
- 파드와 레플리카셋을 합쳐놓은 형태
- 파드의 수 증가/감소/수정 등 다수의 파드를 관리하기 위함
Service
- 서비스는 외부에서 파드에 접근할 수 있게 해주는 로드 밸런서 역할
Cluster
- container화된 app을 실행하는 node
Context
- 컨텍스트는 클러스터 정보와 인증 정보를 매핑해서 하나로 관리하는 기능을 말함
Node
- 노드는 여러 개의 파드를 갖는 단위(마스터노드/워커노드)
namespace
- 클러스터를 논리적으로 구분하는 가상 클러스터
DemonSet
- 데몬셋은 레플리카셋과 유사하지만 노드의 갯수에 맞춰 노드당 하나씩 생성됨
- 노드를 기준으로 파드 생성을 관리하며 노드 셀렉터를 사용해서 특정 노드들에만 파드를 생성가능
쿠버네티스 명령어
create: 리소스를 생성
- kubectl create -f [파일명]
apply: 원하는 상태를 적용, 보통 -f 옵션으로 파일과 함께 사용
- kubectl apply -f [파일명]
- create한 리소스에 변경 사항이 생겨 적용해야 할 때 사용한다.
get: 리소스 목록을 출력
- kubectl get [TYPE]
describe: 리소스의 상태를 자세하게 출력
- kubectl describe [TYPE]/[NAME]
delete: 리소스 제거
- kubectl delete [TYPE]/[NAME]
logs: 컨테이너의 로그 출력
- kubectl logs [POD_NAME]
exec: 컨테이너에 명령어를 전달, 컨테이너에 접근할 때 주로 사용
- kubectl exec -it [POD_NAME][COMMAND]
쿠버네티스 yaml 예시
yaml 파일을 이용하여 매번 명령어를 입력할 필요 없어 더욱 손쉽게 쿠버네티스를 다룰 수 있다.
yaml 파일만 잘 작성해 둔다면 대규모 인프라도 명령어 몇번 만으로 생성이나, 수정, 삭제등을 할 수 있다.
apiVersion
- 스크립트를 실행하기 위한 쿠버네티스 API 버전 정의
kind
- 어떤 종류의 오브젝트를 생성하고자 하는지 지정
metadata
- 이름 문자열, UID, 그리고 선택적인 네임스페이스를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터 지정
.metadata.name
- 필드에 따라 nginx-deployment 이름으로 디플로이먼트가 생성
spec
- 오브젝트에 대해 어떤 상태를 의도하는지
.spec.replicas
- 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성
.spec.selector
- 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의
template
- 새 파드를 런칭하는데 사용, selector의 값과 template의 labels 값이 일치해야 함
- 파드 템플릿의 사양 또는 .template.spec 필드는 파드가 도커 허브의 nginx 1.14.2 버전 이미지를 실행하는 nginx 컨테이너 1개를 실행하는 것을 나타냄
- 컨테이너 1개를 생성하고, .spec.template.spec.containers[0].name 필드를 사용해서 nginx 이름을 붙임
쿠버네티스 기본 파드
쿠버네티스를 구성하고 기본으로 생성된 파드들을 출력하면 아래와 같이 나온다.
coredns
- 쿠버네티스 DNS로 사용할 수 있게 도와줌
- 각 파드별로 도메인을 붙여 더욱 쉽게 파드를 사용할 수 있음
etcd
- 쿠버네티스 상태를 저장하고 복제함, 쿠버네티스를 구성하는 필수 요소
kube-apiserver
- 쿠버네티스 클러스터의 api를 사용할 수 있게 해주는 프로세스, 클러스터로 요청이 왔을 때 그 요청이 유효한지 검증하는 역할
kube-controller-manager
- 각각의 컨트롤러들이 파드들을 관리하고 kube-controller-manager는 이런 각각의 컨트롤러들을 실행하는 역할
kube-proxy
- 쿠버네티스는 클러스터 내부에 별도의 가상 네트워크를 설정하고 관리함, kube-proxy는 이런 가상 네트워크가 동작할 수 있게 하는 실질적인 역할을 하는 프로세스
kube-scheduler
- 새로운 파드들이 만들어질 때 현재 클러스터내에서 자원할당이 가능한 노드들 중에 알맞은 노드를 선택해서 그곳에 파드를 띄움
쿠버네티스 실습
파드를 생성하는 방법
nginx 이미지를 이용해 간단하게 pod, deployment를 생성하고 지워보자
kubectl run nginx-pod --image=nginx nginx #nginx 이미지로 파드 생성
kubectl get pod #생성된 파드 확인
kubectl delete pod nginx-pod #생성한 파드 삭제
kubectl create deployment nginx-deploy --image=nginx #디플로이먼트 방식으로 생성
kubectl get pod
kubectl scale deployment nginx-deploy --replicas=3 #파드 수를 증가
kubectl get pod
kubectl delete deployment nginx-deploy #디플로이먼트 삭제스펙을 지정해 오브젝트 생성하기
앞서 설명한 yaml 파일을 이용해 더 쉽게 오브젝트를 생성 및 관리할 수 있다.
간단하게 nginx deployment를 생성하는 파일을 만든 후 nginx-deploy.yaml라는 이름으로 저장한다.
kubectl create -f nginx-deploy.yaml #create로 위의 yaml 파일에 기재된 스펙으로 오브젝트를 생성
kubectl get pods
replicas:3 -> replicas: 6 #nginx-deploy.yaml의 replicas를 3에서 6으로 변경
kubectl create -f nginx-deploy.yaml #create는 리소스를 새로 생성하는 명령어이기 때문에 create를 사용할 시 명령어가 적용되지 않는다.
kubectl apply -f nginx-deploy.yaml #따라서 apply를 통해 바뀐 내용을 적용한다.
kubectl get pods #파드의 개수가 증가하였는지 확인파드의 동작 보증
kubectl get pods #앞서 생성한 파드 목록을 확인
kubectl delete pods nginx-pod-6799fc88d8-7dbrk #생성한 파드 중 하나를 삭제한다. 파드 이름은 임의로 생성되기 때문에 예시와 다를 것이다.
kubectl get pods #파드를 삭제하였지만 다른 파드가 추가로 생성되어 6개를 유지한다.- nginx-pod는 디플로이먼트에 속한 파드
- 그리고 앞서 nginx-pod에 속한 파드를 replicas에서 6개로 선언함
- 선언한 수대로 유지하도록 파드의 수를 항상 확인하고 부족하면 새로운 파드를 만듬
파드의 컨테이너 자동 복구 방법
kubectl exec -it 파드이름 #bin/bash 생성한 nginx pods 중 하나 접속
cat /run/nginx/pid #nginx 프로세서 ID 확인
kill 1 #nginx 프로세서를 종료함
kubectl get pods #접속했던 pod의 restarts 숫자 확인
※ kubectl get pods -w 로 'w' 옵션을 주면 파드의 상태를 실시간으로 확인할 수 있다.nginx 프로세스가 종료되었지만 다시 복구하여 Running 상태로 바뀌는 걸 볼 수 있다
파드 업데이트하기
파드를 업데이트 해야하는 상황에서 파드를 지우고 다시 만드는 것 보단 아래의 방법으로 더욱 쉽게 파드를 업데이트 할 수 있다.
kubectl apply -f rollout-nginx.yaml --record #현재 상태를 기록
kubectl rollout history deployment rollout-nginx #기록 확인
kubectl exec -it 파드이름 /bin/bash #파드에 접속
nginx -v #nginx 버전을 확인한다.
kubectl set image deployment rollout-nginx nginx=nginx:1.16.0 --record #nginx의 버전을 업데이트 한다.
kubectl get pods -w #파드가 업데이트 되는 걸 확인한다.
kubectl rollout status deployment rollout-nginx #상태 확인
kubectl exec -it 파드이름 /bin/bash #다시 한 번 파드에 접속 후 버전이 바뀌었는지 확인한다.파드 복구하기
파드를 업데이트 하였지만 배포한 코드 및 다른 이유들로 파드에 에러가 발생할 경우 아래와 같이 조치할 수 있다.
kubectl set image deployment rollout-nginx nginx=nginx:1.17.23 --record #nginx에 존재하지 않는 버전으로 업데이트를 시도하여 에러를 유발
kubectl get pods #파드 상태 확인
kubectl rollout history deployment rollout-nginx #업데이트 내역을 확인
kubectl rollout undo deployment rollout-nginx #이전 버전으로 롤백하는 명령
kubectl get pods
kubectl rollout history deployment rollout-nginx #다시 한 번 업데이트 내역을 확인하여 전과 어떤 부분이 달라졌는지 체크한다.
kubectl rollout status deployment rollout-nginx
kubectl exec -it 파드이름 /bin/bash
nginx -v #nginx 버전을 확인하여 1.17.23으로 올리기 전으로 돌아갔는지 체크한다.특정 시점으로 파드 복구하기
이전 버전이 아닌 특정 시점으로 파드를 복구할 수도 있다.
kubectl rollout history deployment rollout-nginx #업데이트 내역을 다시 확인한다.
kubectl rollout undo deployment rollout-nginx --to-revision=1 #이번엔 우리가 되돌리고 싶은 버전을 명시하여 복구를 시도한다.
kubectl get pods -w
kubectl exec -it 파드이름 /bin/bash
nginx -v 버전 확인 #nginx 버전이 잘 바뀌었는지 확인
kubectl delete -f rollout-nginx.yaml #실습이 끝났으니 삭제를 원하면 해당 명령어를 입력한다.