[Kubernetes] 쿠버네티스 핵심 개념

이번 글에서는 minikube를 사용하고, kubectl을 설치하여 우리의 Cluster에 명령을 전달할 것이다.

 

▶ Minikube

Minikube는 로컬 머신에 VM을 만들고 하나의 노드로 구성된 간단한 Cluster를 배포하는 간단한 쿠버네티스 구현체이다.

연습용으로 사용하기 적당하다고 한다.

 

▶ Kubectl

Kubectl은 우리의 Cluster의 Master 노드로 명령을 보내는 도구이다. Master 노드로 명령을 보내면 그 산하의 Worker노드들이 기능을 수행하게 될 것이다.

 

이에 대한 설치 글은 다음 글을 참고해보자!

macOs m1 환경에서 Kubernetes 시작하기(feat. Docker)

 

1. Kubernetes의 객체

Kubernetes에서 가장 중요한 부분은 오브젝트라는 개념인데, 이 오브젝트는 크게 기본 오브젝트와 컨트롤러로 나뉜다
기본 오브젝트는 리소스들의 가장 기본적인 구성단위이며, 컨트롤러는 이 기본 오브젝트들을 생성하고 관리하는 기능을 가진 애들을 말한다

 

기본 오브젝트의 종류

• Pod
• Service
• Volume
• NameSpace

컨트롤러의 종류

• 레플리카 셋
• Deployment
• 스테이트풀 셋
• 데몬 셋

위 객체들을 생성하여 Kubernetes가 우리가 원하는 동작을 수행하도록 만듭니다. 

 

1 - 1) Pod 객체

Pods은 Kubernetes에서 알고 있으며, 상호작용하는 가장 작은 단위입니다.

Pods는 하나 또는 그 이상의 컨테이너들을 포함하고, 실행하게 됩니다.

 

Kubernetes에게 Pod을 생성해야 한다고 알리려면, 컨테이너를 실행하고 Worker 노드에서 이를 수행하게 됩니다.

 

또한 Pod에는 고유 IP주소가 Cluster내부에서는 할당되게 됩니다.

이는 실행 중인 Pod에서 다른 Pod으로 요청을 보낼 때 사용됩니다.

이러한 Pod 내부의 컨테이너들은 localhost를 통해서 서로 간에 커뮤니케이션을 할 수 있습니다.

 

Pod에 대한 중요한 2가지 내용이 있습니다.

1) Pod은 임시적입니다. Pod이 Kubernetes에 의해서 제거되거나 교체되면 내부 리소스는 전부 소멸됩니다.  

2) Pod의 관리를 위해서 Controller(deployment) 객체가 필요합니다.

 

1 - 2) Deployment 객체

일반적으로 특정 Pod를 직접 생성하여 특정 Worker Node로 이동하지는 않습니다!

대신, deployment객체를 생성하고, 생성해야 할 Pod 객체의 수와 컨테이너의 수에 대한 지침을 제공합니다.

 

deployment는 Replicaset의 상위 오브젝트 이기 때문에 deployment 생성 시 해당 deployment에 대응하는 Replicaset도 함께 생성된다. 따라서 deployment을 사용하면 Pod, Replicaset을 직접 생성할 일은 없다.

 

deployment는 하나 이상의 pod를 제어할 수 있습니다. 이를 사용하여 여러 pod을 생성할 수 있습니다.

 

deployment의 핵심은 원하는 목표 상태를 설정한다는 점입니다.

만약 2개의 실행 중인 컨테이너를 각각 감싸고 있는 2개의 Pod를 목표로 설정한다면, deployment가 이를 위한 모든 작업을 수행하게 됩니다.

Pod 객체는 Kubernetes에 의해서 생성되고, 컨테이너도 Kubernetes에 의해서 실행되고, Kubernetes는 이러한 Pod를 Worker Node에 배치하게 됩니다.

 

deployment를 사용할 때 얻는 또 다른 이점은, 일시 중지하거나, 삭제, 롤백이 가능하다는 점입니다.

 

deployment는 또한 scale 관리를 할 수 있습니다.

 

deployment로 하나의 Pod를 관리하지만, 쿠버네티스가 관리하는 여러 Pod를 갖기 위해 여러 deployment를 생성할 수도 있습니다.

---

kubectl을 통해 deployment를 사용하여 Pod를 관리해봅시다.

(kubectl은 local 머신에서 동작하게 됩니다)

 

우선 배포할 이미지를 docker-hub에 push 해둡시다. 

 

이후 kubectl을 통해 Cluster에서 deployment를 생성해봅시다.

kubectl create deployment first-app --image=zbqmgldjfh/kub-first-app

 

이후 get deployments를 통해 확인해보면 READY 상태가 되었음을 확인할 수 있습니다.

 

1 - 3) Kubectl 동작 과정

위에서 사용한 다음 명령은 어떠한 과정으로 동작할까요?

kubectl create deployment first-app --image=zbqmgldjfh/kub-first-app

 

1) 우선 deployment 객체를 생성합니다.

2) Cluster의 Master Node, 즉 컨트롤 플레인으로 전달합니다. 

3) Master Node의 스케쥴러가 생성된 Pod를 분석하여 최적의 Node를 선택하게 됩니다.

4) 생성된 Pod는 Worker Node로 전달됩니다.

5) Worker Node에 포함된 Kubelet을 통해서 Master Node가 Pod를 관리하게 됩니다.

 

1 - 4) Service 객체

Pod에서 실행되는 컨테이너에 접근하려면 Service가 필요합니다.

 

Pod에는 고유 내부 IP가 있는데, 해당 IP를 통해서 접근하기는 어렵습니다.

일단 Scale-up을 하게 되면 Pod가 증가되는데 모두 IP가 다르기 때문입니다.

 

대신 Service는 Pod를 그룹화하고, 공유 IP주소를 가지고 있습니다.

Service 객체를 생성하고, 여러 Pods를 Service로 이동시키고, 공유 IP를 통해 외부에서 접속하게 됩니다.

 

kubectl expose deployment <Pod이름> --type=LoadBalancer --port=8080

위 명령을 통해 노출시키게 됩니다.

 

이후 서비스를 확인하면 다음과 같이 확인할 수가 있습니다.

first-app이라는 이름의 우리가 만든 service 객체가 생성된 것을 확인할 수 있습니다.

 

다만 지금 EXTERNAL_IP가 pending 상태인데, 이는 가상 머신 상에서 돌아가는 미니쿠베 이기 때문입니다.

실실 적으로 IP를 통해 접속하기 어려운 상황이죠.

 

이를 위해 다음과 같은 명령어를 통하여 접근할 수가 있습니다.

위 URL을 통해서 접근이 가능하게 되었습니다!

 

1 - 5) 직접 Scale Up 시키기

Auto Scale 방식이 아닌, 우리가 직접 우선 확장시키는 방법을 적용해봅시다.

kubectl scale deployment/first-app --replicas=3

3개로 확장하는 명령입니다. 결과는 다음과 같죠!

 

만약 다시 replica의 수를 1로 줄인다면 나머지 2개의 Pod는 종료되게 됩니다.

 

1 - 6) Deployment 업데이트

우선 기존의 코드에서 일부를 수정한 후, 다시 build 하여, Docker-hub로 Push 한 상태라고 가정합시다.

docker build -t zbqmgldjfh/kub-first-app:2 .

이미지를 다시 build 할 때 끝에 버전 tag를 추가해주었습니다.

 

push를 다시 해줍시다.

ocker push zbqmgldjfh/kub-first-app:2

 

이후 다음 명령을 통해 이미지를 교체합니다.

kubectl set image deployment/<deployment 이름> <이미지 이름>=zbqmgldjfh/kub-first-app
kubectl set image deployment/first-app kub-first-app=zbqmgldjfh/kub-first-app

 

변경되어 출력되는 것 을 확인할 수 있습니다.

 

만약 도중 문제가 발생한다면, 롤백을 통해 복수할 수도 있습니다.

kubectl rollout undo deployment/first-app

 

만약 더 예전의 Deployment로 돌아가려면 우선 다음 명령을 통해 history를 확인할 수 있습니다.

kubectl rollout history deployment/first-app

 

여기서 만약 1번 Deployment로 돌아가고 싶다면 다음과 같이 수행하면 됩니다.

kubectl rollout undo deployment/first-app --to-revision=1

 

1 - 7) 선언적 접근 방식

다음과 같이 deployment.yml 파일을 하나 만들어봅시다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: second-app-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: second-app
      tier: backend
  template:
    metadata:
      labels:
        app: second-app
        tier: backend
    spec:
      containers:
        - name: second-node
          image: zbqmgldjfh/kub-first-app

그럼 위 선언적 파일을 통해 어떻게 실행할까?

 

다음 명령을 사용하자!

kubectl apply -f=deployment.yml

 

하지만 아직 Service가 없어서 외부에서 접근할 수가 없습니다.

다음과 같이 Service를 생성해봅시다.

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: second-app
  ports:
    - protocol: 'TCP'
      port: 80
      targetPort: 8080 
  type: LoadBalancer

다음 명령을 통해서 적용시켜 봅시다.

kubectl apply -f=deployment.yml

 

만약 해당 내용을 삭제하고 싶다면 다음과 같이 delete를 적용하면 됩니다.

kubectl delete -f=deployment.yml -f=service.yml

성공적으로 삭제되는 것을 확인할 수 있습니다.