[번역] Kubernetes Basics for New Users

출처 : https://medium.com/faun/kubernetes-basics-for-new-users-d57fdf85adba

쿠버네티스(kbernetes, 일명 k8s)는 컨테이너형 애플리케이션을 대규모로 관리할 수 있는 강력한 오픈 소스 시스템이다. 쿠버네티스를 새로운 사용자로 배운 나는 많은 문서를 읽었고 몇몇 기본적이면서도 중요한 개념을 이해하려고 하는 많은 링크들을 따라다녔다. 이것은 어떤 방법으로도 포괄적이지는 않지만, 나는 지금까지 배운 것을 종합했다. 쿠버넷에 대한 유용하고 새로운 사용자 친화적인 가이드(모두 한 페이지):)

쿠버네티스 클러스터

쿠버네티스의 개념은 사용자가 정의한 구성에서 컨테이너형 응용 프로그램의 인스턴스를 실행하기 위해 많은 고가용성 컴퓨터의 작업을 조정하는 것이다. 즉, 애플리케이션 실행 방법과 필요한 모든 애플리케이션 리소스에 대한 지침을 제공하고, 쿠버네티스는 다양한 기계에 대한 작업 배포를 조정한다.

쿠베르네테스는 어떻게 그럴까?

먼저 쿠버네티스 클러스터 서비스의 구조에 대해 이야기해보자

0_kGXr5437PDrdHXmP.png

쿠버네티스 클러스터의 기본적 모습

쿠버네티스 클러스터는 마스터와 노드로 구성되며, 당신은 클러스터 외부의 사용자다. 마스터에 의해 노출되는 Kubernetes API를 통해 클러스터에 요청을 보내는 경우. 마스터는 클러스터에 있는 워커 머신 또는 노드에 대한 정보를 가지고 있으며, 큐브릿을 통해 노드와 통신함으로써 당신의 요청을 충족시킨다. 노드 큐브릿은 마스터와 정보를 앞뒤로 통신하여 클러스터 전체에 걸쳐 요청이 충족되고 유지되는지 확인한다.

기본 아키텍처

노드는 애플리케이션 인스턴스를 호스팅하는 물리적 컴퓨터 또는 가상 시스템이다. 노드에는 최소한 다음과 같은 구성 요소가 있다.

  • 큐브릿: 노드를 공장으로 생각하면 쿠버네티스가 관리자다. 쿠버네티스는 노드를 유지하고 큰 보스 마스터 노드와 통신하는 에이전트다.
  • 컨테이너 런타임: 여기는 공장 노동자들이다. 이 구성 요소는 노드에서 실행되는 애플리케이션 컨테이너에서 실제로 작업을 처리한다. 컨테이너의 포장을 풀고 레지스트리에서 컨테이너 이미지를 꺼내고 응용 프로그램을 실행한다. (위의 도표에서는 도커를 컨테이너 런타임으로 넣었지만, 쿠베르네테스와도 호환되는 몇 가지 다른 점이 있다.)

클러스터 내의 노드는 느슨하게 결합되어 서로 독립적으로 작동하며 다른 노드에 대해서는 거의 또는 전혀 알지 못한다. 그러나 여러 노드에서 여러 애플리케이션 컨테이너를 실행하고 있을 때 이러한 노드에서 작업을 관찰하고 유지하기 위해서는 일종의 서비스 메시가 필요하다.

여기가 마스터가 들어오는 곳이다. 마스터는 애플리케이션 인스턴스 예약, 원하는 앱 상태 유지, 확장 또는 축소, 업데이트 롤아웃을 담당하는 쿠버네티스의 제어부다.

마스터는 최종 사용자가 클러스터 서비스와 상호 작용하고 노드가 마스터와 통신할 수 있도록 쿠버네티스 API를 공개한다.

이제 클러스터가 무엇인지 알게 되었으니 앱을 깔아보자!

배포

이 글에서는 쿠버네티스 튜토리얼에 제공된 온라인 쿠버네티스 환경에서 미니큐브를 사용한다.

미니큐브는 로컬 컴퓨터에 VM을 생성하고 노드 하나만으로 단순한 클러스터를 배포하는 경량 쿠버넷이다.


미니큐브 시작:

$ minikube start

미니큐브에서는 쿠버네티스 API를 사용하여 쿠버네티스 클러스터에 접속하는 쿠버네티스 명령줄 인터페이스인 kubectl을 사용한다.

우리가 알아낸 걸 확인해 보자고

$kubectl cluster-info
Kubernetes master is running at https://172.17.0.15:8443

우리에겐 실행 중인 master가 있다...

$ kubectl get nodes
NAME        STATUS     ROLES     AGE     VERSION
minikube    Ready     <none>     5m      v1.10.0

... 그리고 싱글 노드다!

이제 배포를 생성해 봅시다!

쿠버네티스에서 컨테이너형 앱을 실행하려면 앱 인스턴스 실행 방법에 대한 지침 집합인 배포 구성(deployment configuration)을 작성한다. 이것은 보통 YAML(기본 설정) 또는 JSON 파일이다. 나는 이것을 쿠버네티스가 따라야 하는 레시피라고 생각하고 싶다.

배포 구성이 레시피인 경우 포드가 쿠키! 포드는 배치 구성에 의해 정의되며, 하나 이상의 컨테이너 그룹과 모든 포드의 컨테이너가 공유하는 리소스를 가리키는 추상화다. 포드들은 그들만의 독특한 IP 주소를 가지고 있으며 쿠버네티스에서 가장 작은 단위다. 포드는 노드에서 생성된 애플리케이션 인스턴스다. 노드에 팟을 공급하면 노드가 앱을 실행한다!

배포 구성 파일이 있고 배포를 생성할 수 있는 경우:

$ kubectl run kubernetes-bootcamp — image=gcr.io/google samples/kubernetes-bootcamp:v1 — port=8080
deployment.apps/kubernetes-bootcamp created

실행 명령은 배포 이름, 애플리케이션 이미지의 위치 및 해당 배포를 실행할 특정 포트를 지정한다.

배포를 확인하자.

$ kubectl get deployments
NAME                 DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
kubernetes-bootcamp  1        1        1           1          1m

배치 완료, 예~! DESIRED와 CURRENT는 모두 1이며, 이는 원하는 복제본 수와 현재 실행 중인 번호가 일치함을 나타낸다.

배포를 생성하기 위해 $Kubectl run이 실제로 어떤 작업을 했는지 살펴보자.

0_iCZF8fBAHOZPLn70.png

  1. Kubectl 명령은 클러스터 마스터에게 배포를 생성하도록 지시한다.
  2. 마스터는 사용 가능한 노드를 확인하고 앱 인스턴스(Pod)를 노드로 예약한다.
  3. 포드는 노드에 맞춰져 있다. 포드가 노드에 예약되면 해당 노드에 연결되고 노드로 종료된다는 점에 유의한다.
  4. 마스터는 노드를 모니터링하여 올바른 수의 앱 인스턴스가 실행되고 있는지 확인하십시오.

노드가 작동 중단되면 어떻게 되는가?

0_Ykli6eYhn79tR8u6.png

노드가 다운되면, 노드에 스케줄된 포드 레플리카도 다운된다. 마스터는 노드를 지속적으로 모니터링하고 현재 레플리카 수가 배포와 일치하지 않음을 알아차린다. 그런 다음 마스터는 다른 사용 가능한 노드를 찾아 새 노드로 예약할 새 동일한 포드 레플리카를 작성한다. 이제 실행 중인 구성이 배포 구성과 일치하고 우리는 다시 정상 궤도에 올랐다.

구성 변경:

앞에서 논의한 바와 같이, 앱을 실행하는 방법을 정의할 수 있고 쿠버네티스가 그것을 유지할 것이다. 구성을 변경하려면 어떻게 해야 하는가?

Kubernetes는 실행 중인 앱을 확장하고 업데이트할 뿐만 아니라 다운타임 없이 이러한 변경 작업을 수행할 수 있게 해준다! 이것은 쿠버네티스를 사용함으로써 얻을 수 있는 커다란 이점이며, 어떻게 이런 일이 일어나는지 더 잘 이해하기 위해서, 서비스와 로드 밸런싱의 개념을 간단히 살펴보기로 하자.

서비스:

추상화의 또 다른 계층인 서비스(Service)는 여러 개의 포드들의 논리적인 집합과 느슨한 결합이며, 액세스하기 위한 정책이다. 포드 및 다른 모든 쿠버네티스 개체와 마찬가지로 서비스는 YAML 또는 JSON 파일을 사용하여 정의된다.

서비스에는 여기서 논의하는 것보다 훨씬 더 많은 것이 있지만, 현재로서는 서비스 IP 주소가 공유되어 있고 특정 마이크로 서비스를 수행하는 클러스터 내의 하나 이상의 노드에 걸친 포드의 그룹이라고 생각할 수 있다.

서비스가 중요한 이유 중 하나는 다음과 같이 작동하는 로드 밸런싱이다.

1_VbSvPc7XekNWCeG-0oslSA.png

애플리케이션에 대한 트래픽은 애플리케이션으로 직접 이동하는 대신 서비스 부서로 향하며, 서비스 기관은 해당 포드의 가용성을 평가하고 그에 따라 포드로 트래픽을 유도한다.

앱 확장:

서비스에서 트래픽 양이 증가하고 있고, 증가된 워크로드를 수용하기 위해 확장을 모색하고 있다고 가정해 보자. 원래 애플리케이션 인스턴스가 1개뿐이었는데...

1_fqlivmOGP9jJrja4lWT6pA.png

이제 서비스에서 실행 중인 애플리케이션을 두 개 이상 원하는 경우 쿠버네티스에서 스케일업은 어떻게 작동하는가?

1_kTUh-uLcHZ_C_7B2eyDj2Q.png

$ kubectl scale deployments/kubernetes-bootcamp --replicas=4
deployment.extensions/kubernetes-bootcamp scaled

$ kubectl scale는 다음을 수행한다.

  • 배포에서 레플리카 수 변경
  • 새 팟의 생성을 보장하고 사용 가능한 노드로 예약.

이제 서비스에 둘 이상의 애플리케이션이 있으므로 로드 밸런싱이 정말 유용하다!

$ kubectl get deployments
NAME                  DESIRED  CURRENT  UP-TO-DATE   AVAILABLE   AGE
kubernetes-bootcamp   4        4         4           4           2m
$ kubectl get pods -o wide
NAME      READY     STATUS    RESTARTS   AGE       IP           NODE
...   1/1       Running   0          41s       172.18.0.7   minikube
...   1/1       Running   0          41s       172.18.0.5   minikube
...   1/1       Running   0          41s       172.18.0.6   minikube
...   1/1       Running   0          3m        172.18.0.2   minikube

위에서는 너무 길어서 포드 이름을 생략했지만, 동일한 포드의 레플리카 이름, IP 주소가 모두 한 노드에서 실행되고 있다는 생각이다!

축소할 수도 있다:

$ kubectl scale deployments/kubernetes-bootcamp --replicas=2
deployment.extensions/kubernetes-bootcamp scaled
$ kubectl get deployments
NAME                 DESIRED   CURRENT   UP-TO-DATE  AVAILABLE  AGE
kubernetes-bootcamp   2         2         2          2          6m
$ kubectl get pods -o wide
NAME   READY    STATUS       RESTARTS   AGE    IP           NODE
...   1/1       Running       0         4m     172.18.0.7   minikube
...   1/1       Terminating   0         4m     172.18.0.5   minikube
...   1/1       Terminating   0         4m     172.18.0.6   minikube
...   1/1       Running       0         6m     172.18.0.2   minikube
롤링(Rolling) 업데이트:

쿠버네티스에서는 응용 프로그램을 연속적으로 업데이트할 수 있으며, 이는 응용 프로그램이 계속 실행되는 동안 업데이트할 수 있다는 것을 의미한다. 다운타임이 없다! 쿠버네티스는 어떻게 이 일을 해낼까?

1_30p6uwfaCfrQFvvfJuMozg.png

위에 표시된 서비스부터 애플리케이션의 이미지 버전을 업데이트하고자 한다. $ kubectl set image 명령을 사용하는데, 이것은 쿠버네티스에게 앱 이미지를 변경하고 롤링 업데이트를 시작하라고 알려준다.

1_Ncyz_-N-bymbZjpGDf4aIw.png

1_JPzhe43JnAq35LatnwCpbQ.png

1_lolW7QTRuFdFSIMO6NPSWA.png

$ kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2
deployment.extensions/kubernetes-bootcamp image updated
$ kubectl get pods
NAME  READY     STATUS              RESTARTS   AGE
...   0/1       Terminating         0          13s
...   1/1       Running             0          13s
...   1/1       Terminating         0          13s
...   1/1       Running             0          7s
...   0/1       Pending             0          1s
...   0/1       ContainerCreating   0          3s
...   1/1       Running             0          7s

위에서, 당신은 오래된 포드가 종료되고 새로운 포드 레플리카가 만들어지는 것을 볼 수 있다. 한편, 여전히 포드가 운행 중이며, 서비스는 다른 포드가 업데이트되는 동안 이용 가능한 포드만을 향해 트래픽을 유도하고 있다.

게다가, 쿠버네티스 업데이트에서는 버전이 설치되어 있고, 업데이트의 어떤 것이 제대로 작동하지 않으면 다운타임 없이 항상 이전 버전으로 되돌릴 수 있다! 예를 들어, 아래 명령은 가장 최근의 업데이트를 실행 취소한다.

$ kubectl rollout undo deployments/kubernetes-bootcampdeployment.extensions/kubernetes-bootcamp

읽어줘서 고마워!

이 글은 쿠버네티스가 무엇이며 무엇을 제공해야 하는지에 대한 기본적인 개요일 뿐이다. 그럼에도 불구하고, 이 글을 보고 도움이 되고 즐거웠기를 바란다. 더 배울 게 많으니까 빨리 시작하자!

이 글을 쓸 때 사용한 가장 유용한 자료 중 몇 가지는 다음과 같다.