[Kubernates] 쿠버네티스의 구성요소

Kubernates란?

컨테이너 관리 도우미이다. 앞글자의 K, 뒷글자의 S, 그 사이의 숫자 개수 8를 합쳐 K8s라고 부른다.

컨테이너화 된 애플리케이션을 자동으로 배포, 확장, 운영(관리)하는 오픈소스 플랫폼이다.

Docker에서 제공하는 컨테이너 기술로 만든 앱이 여러 개 있다면 어디서 실행할지, 언제 늘리고(스케일링), 언제 공장나고, 어떻게 통신되는지 개발자가 관리하지 않고 쿠버네티스가 알아서 관리해주는 것이다.

즉, 오픈소스 컨테이너 오케스트레이션 플랫폼이다.

 

 

왜 필요한가?

개발하게 되면 기본적으로 Front, Back, DB 3개의 서버가 필요하다.

그런데 이것보다 서버가 많이 필요해지면 어떻게 될까?

서버가 여러 개이면 컨테이너를 어떻게 배치할지, 장애가 나면 어떻게 복구할지 관리가 어렵다.

kubernates는 클러스터(서버를 묶음) 전체를 하나처럼 보기때문에, 컨테이너를 자동으로 배치, 스케일, 복구한다.

 

간단하게 보면 아래와 같다

• 컨테이너 오케스트레이션 비용 절감
• MSA를 위한 데브옵스 효율성 향상
• 멀티 클라우드 환경에서 워크로드 배포 용이
• 배포 자동화 및 확장성 강화
• 클라우드 환경에서의 애플리케이션의 안정성 및 가용성 강화
• 오픈소스 생태계의 일부로서 이용하기 편리

 

Kubectl이란?

kabe control에서 유래했고, Kubernates cluster를 관리하는 커멘드라인 도구이다.

Kuberctl로 쿠버네티스의 상태를 확인하고 원하는 상태를 요청할 수 있다.

사용자가 쿠버네티스 api server와 통신하고자 하면 kubectl을 통해 클러스터의 상태를 조회할 수 있고 리소스 생성, 수정, 삭제가 가능하다.

 

Cluster란?

여러 대의 컴퓨터(Server)를 하나처럼 묶은 그룹이다.

쿠버네티스에서는 이 클러스터에서 모든 컨테이너가 실행된다.

 

클러스터의 구성은 크게 마스터 노드(Control Plane, 제어 플레인)과 워커 노드(Worker node, 일반 노드)로 나뉜다.

마스터 노드는 클로스터 전체를 관리하는 역할이다.

애플리케이션을 배포하게 되면 어디에 배포를 할 것인지, 컨테이너에 이상이 발생했을 때 새로운 컨테이너 배포 등을 처리한다.

 

 

워커 노드는 실제 컨테이너을 실행하는 작업 공간이다.

1개의 워커노드에는 여러 대의 pod(포드)가 실행된다.

 

즉 웹 서비스를 쿠버네티스에 배포하면

마스터 노드에서 '실행해~' 라는 명령이 나가고

워커 노드들 중에서 하나 또는 여러 개에 pod를 배치한다.

사용자 요청이 들어오면 service를 통해 적절한 워커 노드로 연결된다.

 

Kubernetes Object

Kubernets Object란?

쿠버네티스의 오브젝트는 시스템에서 배포하고 관리하는 기본 단위이다.

모든 오브젝트는 쿠버네티스 API를 통해 생성, 수정, 삭제할 수 있다.

모든 오브젝트의 정보는 etcd에 저장되며, YAML이나 JSON으로 표현할 수 있다.

 

Kubernetes Object 종류

• Pod: 하나 이상의 컨테이너를 포함하며, 가장 작은 배포 단위입니다.
• Deployment: Pod와 ReplicaSet을 생성하고 관리합니다.
• Service: Pod에 대한 네트워크 엔드포인트를 노출합니다.
• Volume: 데이터를 저장하기 위한 디렉토리 또는 디렉토리 트리입니다.
• Namespace: 쿠버네티스 클러스터 내에서 가상 클러스터를 생성합니다.
• StatefulSet: 디스크 상태가 있는 애플리케이션을 배포하고 관리합니다.
• DaemonSet: 모든 노드에서 실행되는 Pod를 배포하고 관리합니다.
• Job: 일시적인 작업을 실행하고 완료될 때까지 대기합니다.

 

Pod

pod는 쿠버네티스에서 관리하는 가장 작은 배포 단위이다.

쿠버네티스와 도커의 차이점은 도커는 컨테이너를 만들지만, 쿠버네티스는 컨테이너 대신 pod를 만든다.

pod는 한 개 이상의 컨테이너를 포함한다.

minikube 클러스터 안에 pod가 있고 pod 안에 컨테이너가 있다.

 

예를 들면 물건을 주문하면 택배 상자에 포장되어서 배달된다. 이때 물건은 1개일 수도 있고 여러 개 일 수도 있다.

배달되는 물건이 컨테이너라면 상품을 감싸고 보호하는 박스, object가 pod(파드)이다.

박스를 열면 그 안에는 물건이 들어 있다.

 

왜 pod가 필요할까?

Docker 같은 툴을 사용하면 컨테이너만 직접 실행하면 되지 않을까라는 궁금증이 있다.

쿠버네티스가 배포, 복구, 관리하기 위해서는 단위가 필요한데, 그 단위가 되는 것이 pod이다.

또한, 2개 이상의 컨테이너가 같이 있어야 작동한다면 pod에 묶어서 같이 배치할 수 있다.

pod에 묶어 같이 배치하면 같은 서버에서 실행되고 같은 네트워크 주소를 공유할 수 있다.

네트워크와 저장소를 쉽게 공유할 수 있다.

pod 안에 있는 컨테이너들은 같은 ip주소를 공유하기 때문에 같은 디스크(Volume)을 사용할 수 있다.

따라서 서로 쉽게 파일을 주고받고, 같은 데이터를 보고 일할 수 있다.

 

- pod 명령어

// Pod 생성
kubectl run boot-kube --image bmsvega2k/boot-kube:0.1

// Pod 목록 조회
kubectl get pod

// Pod 상세 조회
kubectl describe pod/boot-kube

// Pod 제거
kubectl delete pod/boot-kube

 

 

 

ReplicaSet

Pod를 단독으로 만들면 Pod에 어떤 문제(서버가 멈춰서 Pod가 사라졌을 때)가 생겼을 대 자동으로 복구되지 않는다.

이러한 Pod를 정해진 수만큼 복제하고 관리하는 것이 ReplicaSet이다.

ReplicaSet은 label을 체크해서 원하는 개수의 Pod가 없으면 새로운 Pod를 생성한다.

예를 들어 ReplicaSet의 yml파일에 spec.replicas을 2개로 정했다고 하자.

spec.replicas을 2개로 정하면 원하는 Pod의 개수를 2개라고 설정한 것과 같다.

해당 ReplicaSet yml파일을 설치하면 Pod가 2개 생성된다.

1개의 Pod를 중단시키면, ReplicaSet이 자동으로 새로운 Pod를 실행시켜준다.

아까 중단시켰던 Pod를 다시 재실행하게 되면 새롭게 생겼던 Pod는 사라진다.

즉 Pod가 2개인 상태를 유지하는 것이다.

 

 

 

ReplicaSet

아래와 같이 yml파일을 만들어 주고 설치해줬다.

replicas는 1로 pod는 1개를 원하고, labels은 app=boot-kube,tier=app 이라고 쓰여진다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: boot-kube-rs
spec:
  replicas: 1
  selector:
    matchLabels:
      app: boot-kube
      tier: app
  template:
    metadata:
      labels:
        app: boot-kube
        tier: app
    spec:
      containers:
        - name: boot-kube
          image: bmsvega2k/boot-kube:0.1

// ReplicaSet 설치
kubectl apply -f ./k8s/boot-kube-rs.yml

// Resource 확인
kubectl get pod,rs

 

 

- pod의 생성된 label를 조회했을 때

// 라벨 조회
kubectl get pod —show-labels

 

- pod 중 boot-kube-rs-p5vjv라는 이름을 가지고 pod에 라벨 app을 제거하라는 것

kubectl label pod/boot-kube-rs-p5vjv app-

 

해당 pod의 라벨을 제거하자, ReplicaSet에 해당하는 조건의 pod가 사라져서 새로운 pod인 boot-kube-rs-6jlwr가 생겼다.

 

 

- pod 중 아래와 같은 이름을 가진 pod에 app=boot-kube라는 라벨을 추가하라는 것

아까 label을 제거한 pod에 다시 라벨을 추가한다.

kubectl label pod/boot-kube-rs-z48lp app=boot-kube

 

다시 라벨이 생겼고, ReplicaSet 조건이 충족되어서 새로 생긴 pod는 사라졌다.

 

 

Deployment

Deployment는 쿠버네티스에서 가장 널리 사용되는 오브젝트이다.

ReplicaSet을 이용하여 Pod를 업데이트 하고 이력을 관리하여 롤백(Rollback) 하거나 특정 버전(Revision) 으로 돌아갈 수 있다.

 

- Deployment yml 파일

replicas가 4개 필요다가 조건을 줌.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: boot-kube-deploy
spec:
  replicas: 4 // 4개 띄워라
  selector:
    matchLabels:
      app: boot-kube
      tier: app
  template:
    metadata:
      labels:
        app: boot-kube 
        tier: app
    spec:
      containers:
        - name: boot-kube
          image: bmsvega2k/boot-kube:0.1

 

 

- Deployment 생성하기

kubectl apply -f ./k8s/boot-kube-deployment.yml

 

- Resource 확인하기

kubectl get po,rs,deploy

 

- 생성하고 확인하기

 

- pod 하나 삭제하고 확인하기

spec: replicas: 4 이기 때문에 바로 새로운 pod가 생긴다. (g7hrb가 새로운 pod이다.)

 

- Rolling Update하기

1. 기존 설정에서 이미지 태그만 변경하고 다시 적용합니다. - 버전 변경

// v2인 새로운 Image  업데이트
kubectl apply -f ./k8s/boot-kube-deployment-v2.yml

 

 

- 로그로 확인 (보고싶은 pod 이름 복사)

kubectl logs pod/boot-kube-deploy-f9966847f-9pj6s

 

- Revision 목록 확인

kubectl rollout history deploy

 

 

 

2. deployment.yml 수정 없이 명령어로 Deploy 할 image 변경하기

kubectl set image deployment/<<deployment-name>> <<container_name>>=<<your_dockerhub_username>>

kubectl set image deployment/boot-kube-deploy boot-kube=bmsvega2k/boot-kube:0.3

 

- log 확인

kubectl logs <<해당pod이름>>

 

 

만약 version3에서 오류가 생겨서 version2로 돌아가려고 한다고 하자.

다시 version2로 돌아가려면 아까와 같이 apply해주거나 set image version2로 해주면 된다.

// 히스토리 확인
kubectl rollout history deploy

// revision 4 확인
rollout history deploy --revision=4

 

버전 1→2→3→2 인 상황에서 히스토리를 보면 4까지 나온다.

4가 무엇인지 확인해보니 version2이다.

 

 

 

Service

Pod은 자체 IP를 가지고 다른 Pod과 통신할 수 있지만, 쉽게 사라지고 생성되는 특징 때문에 직접 통신하는 방법은 권장하지 않는다. 쿠버네티스는 Pod과 직접 통신하는 방법 대신, 별도의 고정된 IP를 가진 서비스를 만들고 그 서비스를 통해 Pod에 접근하는 방식을 사용한다.