[Azure] 쿠버네티스(Kubernetes) 실습하기 : 간단한 실습 해보기

애저(Azure)를 이용하여 쿠버네티스(Kubernetes)를 구축하고, 간단한 실습 해보기

들어가며

• 애저(Azure)를 이용하여 구축한 쿠버네티스(Kubernetes)를 간단하게 실습해 보자.
• 이 글은 이전 글(https://dev-astra.tistory.com/396)에 이어서 진행된다.

 

실습하기

미니 쿠베를 실행하고 간단한 실습 해보기

• 다음 명령을 실행하여 설치한 미니 쿠베를 실행한다.
  • 드라이버(Driver)를 도커(Docker)로 설정한다.
  • 관련 컨테이너들과 기능들이 설치되기 때문에 시간이 조금 걸릴 수 있다.

$ minikube start --driver=docker

잔망스러운(?) 아이콘과 함께 미니 쿠베가 실행되는 것을 확인할 수 있다.

 

• 다음 명령을 실행하여 미니 쿠베의 상태를 확인한다.

$ minikube status

모든 것이 정상적으로 작동하고 있음을 확인할 수 있다.

 

• 다음 명령을 실행하여 쿠버네티스 시스템에 있는 Pod의 정보를 확인해본다.

$ kubectl get pod

아직 실행 중인 Pod가 없는 것을 확인할 수 있다.

 

• 하지만, 다음과 같이 명령을 실행하여 쿠버네티스 시스템이 사용하고 있는 컨테이너들을 확인할 수 있다. (쿠버네티스도 하나의 컨테이너이다.)

$ kubectl get pod -n kube-system

RESTARTS 횟수가 많으면 시스템이 불안한 것을 의미한다. (빈번한 다시 시작이 발생했으므로)

 

• 다음 명령을 실행하여 미니 쿠베를 삭제할 수 있다.

$ minikube delete

 

• 다음 명령을 실행하여 미니 쿠베의 상태를 확인한다.

$ minikube status

 

• 다음 명령을 실행해서 미니 쿠베를 작동시킨다. 만약 미니 쿠베가 작동하지 않을 경우, 이전에 수행했던 @delete@ 명령은 로컬에서 설치되어 있는 파일까지 삭제한 것이다. 작동할 경우, 메모리 상에 있는 미니 쿠베만 지워진 것이다.

$ minikube start --driver=docker

정상적으로 미니 쿠베가 작동하였다. 따라서 미니 쿠베의 delete 명령은 메모리 상에 있는 미니 쿠베만 지우는 것임을 알 수 있다.

미니 쿠베를 로컬에서 완전히 삭제하고 싶을 경우, 'minikube uninstall' 명령을 실행한다.

 

YAML 파일을 이용하여 Pod를 생성하고 배포해보기

• 이제 YAML 파일을 이용하여 Pod를 생성해보자. 다음 명령을 실행하여 @pod.yaml@ 파일을 생성하고 편집한다. 그리고 생성한 파일을 확인한다.
  • @busybox@ 이미지를 생성하는 과정은 '간단한 도커 실습' 게시글(https://dev-astra.tistory.com/390)을 참고한다.

$ vi pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox   # Docker 실습할 때 만들었었던 이미지
    args: [/bin/sh, -c, 'i=0; while true; do echo "$i: $(date)"; i = $((i + 1)); sleep 1; done']

 

• 다음 명령을 실행하여 생성한 Pod  파일을 적용시킨다. 그리고 실행 중인 Pod 목록을 확인한다.

$ kubectl apply -f pod.yaml

$ kubectl get pod

컨테이너 1개(count)가 포함되어 있는 Pod 1개가 실행되고 있음을 확인할 수 있다.

- 참고로, 'kubectl get pod -n kube-system' 명령을 실행하면 미니 쿠베 시스템과 관련되어 있는 Pod들을 확인할 수 있다.
- 시스템 관련 Pod와 더불어 모든 Pod들을 확인하려면 'kubectl get pod -A' 명령을 실행한다.
- 지정된 이름의 Pod만 확인하려면 'kubectl get pod <pod-name>' 명령을 실행한다.
- 지정된 이름의 Pod에 대해 자세히 알고 싶다면 'kubectl describe pod <pod-name>' 명령을 실행한다.
- 'kubectl get pod -o wide' 명령을 실행하면 자세한 정보를 얻을 수 있다.
- 'kubectl get pod -w' 명령을 실행하면 지속적으로 각각의 Pod 상태를 감시할 수 있다. (Watching, 빠져 나오려면 [Ctrl] + [C]를 누른다.)

• 다음 명령을 실행하여 @counter@ 컨테이너의 로그를 확인해본다.

$ kubectl logs counter

 

• 다음 명령을 실행하여 Pod 자체에 직접 접속해본다. 그리고 해당 Pod의 파일 목록을 출력해본다.

$ kubectl exec -it counter /bin/sh

 

Pod 삭제하기

• 다음 명령들을 실행하여 Pod(@counter@)를 삭제할 수 있다.

$ kubectl delete pod counter

$ kubectl delete -f pod.yaml      # pod.yaml 파일이 아닌, pod.yaml 파일 안에서 기술한 객체를 삭제한다.

pod.yaml 파일 안에서 기술한 객체(counter)를 삭제한다. 이것은 실수를 막기 위함이다.

 

YAML 파일을 이용하여 Deployment를 생성하고 배포해보기

• 다음 명령을 실행하여 @deployment.yaml@ 파일을 생성한 후 내용을 편집해준다. 그리고 파일의 내용을 확인해본다.

$ vi deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
          - containerPort: 80

 

• 다음 명령을 실행하여 생성한 @deployment.yaml@ 파일을 배포해본다. 이 명령을 실행함으로써 파일 내부의 컨테이너가 생성된다.

$ kubectl apply -f deployment.yaml

 

• 다음 명령을 실행하여 실행 중인 Pod의 목록을 확인한다.

$ kubectl get pod

실행 중인 nginx 하나하나가 Replica에 해당한다. (yaml 파일을 만들 때 replicas의 값을 3으로 설정하였다.)

 

• 다음 명령을 실행하여 Deployment 자체를 조회해본다.

$ kubectl get deployment

3개 중에 3개가 선택되어 있음을 확인할 수 있다.

 

Scaling 해보기

• 예를 들어, 쿠버네티스를 이용하여 서비스를 운영하는데 갑자기 사람들이 서비스에 많이 몰릴 경우, Pod의 개수를 늘려야 한다. (Scaling)
• 다음 명령을 실행하여 @replicas@의 개수를 20개로 늘려본다. 그리고 이어서 Deployment와 Pod 목록을 조회해본다.

$ kubectl scale deployment/nginx-deployment --replicas=20

$ kubectl get deployment

$ kubectl get pod

 

• 다음과 같이 @replicas@의 개수를 5개로 줄이면, 늘었었던 Pod의 수가 하나씩 사라진다.

$ kubectl scale deployment/nginx-deployment --replicas=5

Terminating이라는 상태(STATUS)를 확인할 수 있다.

 

Auto Healing 해보기

• 특정 Pod가 죽거나 응답 없는 상태가 되면, 죽이고(제거하고) 다시 생성해줘야 한다. 사용자가 특정 Pod를 제거하면, 비슷한 Pod가 자동으로 새로 생성되는데 이것을 Auto Healing이라고 한다.
• 실습을 위해 이름(@NAME@)의 끝이 @2tlfl@인 Pod(@nginx-deployment-66b6c48dd5-2tlfl@)를 제거해보자.

$ kubectl delete pod nginx-deployment-66b6c48dd5-2tlfl

 

• 해당 Pod를 제거했으나, 실행 중인 Pod를 확인해본 결과 또 다른 Pod가 대신 실행되고 있는 것을 확인할 수 있다.

 

소프트웨어가 불량한 경우(메모리를 많이 사용하는 경우 등) Pod가 저절로 죽는 경우가 발생한다. 이때, Auto Healing 기능으로 인하여 해당 Pod가 다시 실행된다. 자동으로 복구된다는 장점이 있지만, 소프트웨어의 문제점을 발견하지 못한다는 단점이 존재한다. 따라서, Pod가 저절로 죽을 경우, 모니터링을 하여 문제의 원인을 파악해야 한다.

 

Deployment 삭제하기

• 다음 명령을 실행하여 Deployment를 삭제할 수 있다. (영구적으로 삭제한다.)

$ kubectl delete deployment nginx-deployment

모든 replicas 들이 한꺼번에 삭제되는 것을 확인할 수 있다.

 

서비스(Service) 실습 해보기

• 다음 명령을 실행하여 @service.yaml@ 파일을 생성하고, 내용을 추가한다.

$ vi service.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  type: NodePort    # Service의 Type을 명시하는 부분
  ports:
  - port: 80
    protocol: TCP
  selector:        # 아래의 label을 가진 Pod를 매핑하는 부분
    app: nginx

 

• 다음의 명령을 실행하여 Service를 생성한다.

$ kubectl apply -f service.yaml

 

• 다음의 명령을 실행하여 실행 중인 Service를 확인한다. @PORT(S)@에서 @80:<PORT>@ 부분의 숫자(@31154@)를 확인한다.

$ kubectl get service

 

• 다음 명령을 실행하여 Service를 통해서 클러스터 외부에서도 정상적으로 Pod에 접속할 수 있는 것을 확인해본다.

$ curl -X GET $(minikube ip):<31154>

 

Pod

• Pod(파드)는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.
• 쿠버네티스는 Pod 단위로 스케줄링, 로드밸런싱, 스케일링 등의 관리 작업을 수행한다.
  • 쿠버네티스에 어떤 애플리케이션을 배포하고 싶다면 최소 Pod로 구성해야 한다는 의미이다.
• Pod는 컨테이너(Container)를 감싼 개념이라고 볼 수 있다.
  • 하나의 Pod는 1개의 컨테이너 혹은 여러 개의 컨테이너로 이루어져 있을 수 있다.
  • Pod 내부의 여러 컨테이너는 자원을 공유한다.
• Pod는 Stateless한 특징을 지니고 있으며, 언제든지 삭제될 수 있는 자원이라는 점을 기억한다.
• Pod와 관련된 자세한 내용은 아래의 공식 문서를 참고한다.

파드

 

Deployment

• Deployment(디플로이먼트)는 Pod와 Replicast에 대한 관리를 제공해주는 단위이다.
• 관리라는 의미는, Self-healing, Scaling, Rollout(무중단 업데이트)과 같은 기능을 포함한다.
• Deployment는 Pod를 감싼 개념이라고 생각할 수 있다.
  • Pod를 Deployment로 배포함으로써 여러 개로 복제된 Pod, 여러 버전의 Pod를 안전하게 관리할 수 있다.
• Deployment와 관련된 자세한 내용은 아래의 공식 문서를 참고한다.

디플로이먼트

 

Service

• Service(서비스)는 쿠버네티스에 배포한 애플리케이션(Pod)을 외부에서 접근하기 쉽게 추상화한 리소스이다.
• Pod는 IP를 할당 받고 생성되지만, 언제든지 죽었다가 다시 살아날 수 있으며, 그 과정에서 IP는 항상 재할당 받기에 고정된 IP로 원하는 Pod에 접근할 수는 없다.
• 따라서 클러스터 외부 혹은 내부에서 Pod에 접근할 때는 Pod의 IP가 아닌 Service를 통해서 접근하는 방식을 거친다.
• Service는 고정된 IP를 가지며, Service는 하나 혹은 여러 개의 Pod와 매칭된다.
• 따라서 클라이언트가 Service의 주소로 접근하면, 실제로는 Service에 매칭된 Pod에 접속할 수 있게 된다.
• Service와 관련된 자세한 내용은 아래의 공식 문서를 참고한다.

서비스

 

Service의 Type

• @NodePort@라는 Type을 사용할 경우, 클러스터 외부에서 @minikube@라는 쿠버네티스 클러스터 내부에 배포된 서비스에 접근할 수 있다.
  • 접근하는 IP는 Pod가 떠 있는 노드(머신)의 IP를 사용하고, 포트(Port)는 할당받은 포트를 사용한다.
• @LoadBalaner@라는 Type을 사용해도 마찬가지로 클러스터 외부에서 접근할 수 있지만, @LoadBalancer@를 사용하기 위해서는 LoadBalancing 역할을 하는 모듈이 추가적으로 필요하다.
• @ClusterIP@라는 Type은 고정된 IP, 포트를 제공하지만, 클러스터 내부에서만 접근할 수 있는 대역의 주소가 할당된다.
• 실무에서는 주로 쿠버네티스 클러스터에 @MetalLB@와 같은 LoadBalancing 역할을 하는 모듈을 설치한 후, @LoadBalancer@ Type으로 서비스를 Expose하는 방식을 사용한다.
• @NodePort@는 Pod가 어떤 노드에 스케줄링될 지 모르는 상황에서, Pod가 할당된 후 해당 노드의 IP를 알아야 한다는 단점이 존재한다.

 

YAML(YAML Ain't Markup Language)

• 쿠버네티스에서는 YAML 파일을 사용한다.
• YAML 파일은 데이터 직렬화에 쓰이는 포맷(양식) 중 하나이다.
  • 데이터 직렬화란, 서비스 간에 데이터를 전송할 때 쓰이는 포맷으로 변환하는 작업을 의미한다.
• 예를 들어, 쿠버네티스 마스터에게 요청을 보낼 때 YAML을 사용한다.
• 데이터 직렬화에 쓰이는 다른 파일 포맷으로 XML, JSON이 있다.
• YAML 파일의 포멧은 @.yaml@ 또는 @.yml@이다.
• YAML에 대한 자세한 내용은 아래의 게시글을 참고한다.

[Kubernetes] YAML(YAML Ain't Markup Language)

 

참고 사이트

minikube start

Hello Minikube