AWS - 쿠버네티스 - 4탄 쿠버네티스 Application 배포하기 (Minikube와 Katacoda를 이용한 가상 실습 )

https://kubernetes.io/ko/docs/home/ 참고

 

지난 포스팅들을 통해 minikube를 이용해 클러스터를 생성해봤다. 이제, 클러스터와 kubectl을 사용해서 Application을 배포해보자.

 

1. 앱 배포하기

그림1. 앱 배포하기

일단 쿠버네티스 클러스터를 구동시키면, 그 위에 컨테이너화된 애플리케이션을 배포할 수 있다. 그러기 위해서, 쿠버네티스 디플로이먼트 설정을 만들어야 한다. 디플로이먼트는 쿠버네티스가 애플리케이션의 인스턴스를 어떻게 생성하고 업데이트해야 하는지를 지시한다. 디플로이먼트가 만들어지면, 쿠버네티스 컨트롤 플레인이 해당 디플로이먼트에 포함된 애플리케이션 인스턴스가 클러스터의 개별 노드에서 실행되도록 스케줄한다

.

애플리케이션 인스턴스가 생성되면, 쿠버네티스 디플로이먼트 컨트롤러는 지속적으로 이들 인스턴스를 모니터링한다. 인스턴스를 구동 중인 노드가 다운되거나 삭제되면, 디플로이먼트 컨트롤러가 인스턴스를 클러스터 내부의 다른 노드의 인스턴스로 교체시켜준다.이렇게 머신의 장애나 정비에 대응할 수 있는 자동 복구(self-healing) 메커니즘을 제공한다.

 

오케스트레이션 기능이 없던 환경에서는, 설치 스크립트가 애플리케이션을 시작하는데 종종 사용되곤 했지만, 머신의 장애가 발생한 경우 복구를 해주지는 않았다. 쿠버네티스 디플로이먼트는 애플리케이션 인스턴스를 생성해주고 여러 노드에 걸쳐서 지속적으로 인스턴스가 구동되도록 하는 두 가지를 모두 하기 때문에 애플리케이션 관리를 위한 접근법에서 근본적인 차이를 가져다준다.

 

Kubectl이라는 쿠버네티스 CLI를 통해 디플로이먼트를 생성하고 관리할 수 있다. Kubectl은 클러스터와 상호 작용하기 위해 쿠버네티스 API를 사용한다. 이 모듈에서는, 쿠버네티스 클러스터 상에 애플리케이션을 구동시키는 디플로이먼트를 생성하기 위해 필요한 가장 일반적인 Kubectl 명령어를 배우게 된다.

 

이제 실습을 시작해보자.

그림2. App 배포하기 실습

실습에 앞서 지난 포스팅에서 사용한 명령어를 통해 kubectl이 설치되어 있는지와 클러스터 내 노드 상태가 어떤지 확인해보자.

kubectl version
kubectl get nodes

그림3. kubectl 기본 정보

서버와 클라이어트 kubectl이 설치되어 있으며, 1개의 노드를 가지고 Application을 배포할 수 있는 상태라고 할 수 있다.

 

이제  kubectl create deployment 명령어를 통해 Application을 배포해보자. 아래 명령어에는 deployment를 생성하면서 그 이름과 레파지토리의 위치를 지정해주고 있다.

kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1

그림4. deployment 생성

위와 같이 명령어 입력 후 kuvernetes-bootcamp가 생성 되었다는 메시지를 볼 수 있다. 이 과정에서 첫번째 Application 배포가 된 것이다. 또한 다음과 같은 몇가지 행동들이 실행되었다.

• 응용 프로그램의 인스턴스를 실행할 수있는 적절한 노드를 검색 (사용 가능한 노드는 1 개).
• 해당 노드에서 실행되도록 애플리케이션을 예약
• 필요할 때 새 노드에서 인스턴스를 다시 예약하도록 클러스터를 구성

 

클러스터 내의 deployment 리스트를 확인하기 위해선 아래 명령어를 사용한다.

kubectl get deployments

그림5. deployment 목록

이름, 상태 등등 생성 된 deployment의 간략한 정보를 알 수 있다. 현재 단일 인스턴스를 실행하는 1개의 deployment가 있으며, 해당 인스턴스는 노드의 Docker 컨테이너 내에서 실행된다.

 

다음으로 파드에 대해서 조금 알아보자면, 파드는 격리 된 private 네트워크에서 실행된다. 기본적으로 동일한 kubernetes 클러스터 내의 다른 포드 및 서비스에서 볼 수 있지만 해당 네트워크 외부에서는 볼 수 없다. 그래서 우리는 kubectl의 API 엔드 포인트를 통해 Application과 통신한다. kubectl을 통해 통신을 pricvate 네트워크 전체에 전달하는 프록시를 만들 수 있다. 프록시 실행 시에는 터미널에서 별다른 출력 메시지를 볼 수 없기 때문에 프록시 실행 테스트 시 별도의 터미널 창을 하나 더 만들어보자.

echo -e "\n\n\n\e[92mStarting Proxy. After starting it will not output a response. Please click the first Terminal Tab\n";

그림6. 새로운 터미널 생성

위와 같이 새로운 터미널이 생성되면 해당 터미널에서 프록시를 실행시킨다.

kubectl proxy

그림7. 프록시 실행

이제 호스트와 Kubernetes 클러스터가 연결 되었으며, 프록시를 사용해서 API에 직접 호출할 수 있다. 그 예시로 API를 통해 버전을 호출해보자.

curl http://localhost:8001/version

그림8. API 버전 확인

참고로 프록시를 종료하면(Ctrl+C) 위 API 호출이 실패한다.

 

그리고 API 서버는 프록시를 통해 액세스 할 수있는 엔드포인트를 포드 이름에 기반해서 자동으로 생성한다. 아래 명령어를 통해 어떤 파드 이름을 가져오고 $POD_NAME이라는 변수에 지정해보자.

export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
echo Name of the Pod: $POD_NAME

그림9. 파드 엔드포인트 이름

그리고 위에서 지정한 아래 $POD_NAME 변수와 아래 API 명령어를 통해 Pod에 접근해보자.

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/

그림10. API를 통해 파드 접근

위 캡쳐에 다 담지는 못했지만, 파드에 대한 상세한 정보가 출력된다. 그 안에는 네트워크 정보, 이미지 정보, 볼륨에 대한 액세스 정보 등등 많은 정보가 담겨있는 것을 볼 수 있다.

 

프록시 없이도 파드에 접근할 수 있지만 그건 조만간 포스팅 하도록 할것이다. 우선 다음 포스팅에서 배포한 Appication을 분석하는 것을 진행해보자.