클러스터 생성 및 앱 배포
이번에는 쿠버네티스란 무엇인지, 미니큐브는 무엇인지에 대해 알아보자.
https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/ 참고
쿠버네티스 클러스터
쿠버네티스는 높은 가용성을 클러스터 하는것이다. 즉 하나의 유닛으로 일하는 여러 컴퓨터들의 클러스터를 의미한다. 도커이미지를 배포할 수 있는 클러스터이다.
특정 머신한테 배포 설정하는것이 아니라 쿠버네티스한테 배포하라고 던지면 쿠버네티스가 알아서 배포한다.
이를 사용하려면 어플리케이션은 특정 호스트에 묶이지 않은상태로 패키지 되어야 한다.
컨테이나이저 어플리케이션은 예전 배포모델보다 유연하다. (예전모델은 특정 머신에 의존성이 있었다.)
쿠버네티스는 좀더 효율적인 방법으로 클러스터에 어플리케이션을 어떻게 배포하고 스케줄링해야되는지에 대해 자동화함.
쿠버네티스는 오픈소스이며 클러스터 환경에서 쓸 수 있다.
쿠버네티스는 마스터, 노드로 구성된다.
(스웜으로 비교하자면 각각 매니저, 워커이다. 스웜에서는 매니저, 워커 둘다 컨테이너를 띄울 수 있었다. 쿠버네티스에서는 노드에서만 컨테이너를 띄울 수 있다.)
쿠버네티스의 마스터, 노드
마스터는 어플리케이션 스케줄링, 특정 상태로 만드는일, 스케일링하는일, 새 버전을 차곡차곡 배포해 나가는것을 관리함
노드들은 vm이거나 물리적인 컴퓨터인데 쿠버네티스에서 워커 머신역할을 한다.
각각의 노드는 큐블릿을 갖고있는데 이는 노드를 관리하기 위한 에이전트이고 쿠버네티스 매니저와 의사소통한다.
노드는 도커 혹은 rkt와 같은 컨테이너 오퍼레이팅 툴이 필요하다.
쿠버네티스 클러스터는 프로덕션 트래픽을 다룰 수 있는데 이를 위해 최소 3개 이상의 노드를 갖고있어야 한다.
쿠버네티스의 배포과정
- 애플리케이션을 쿠버네티스에 배포할 때 마스터한테 어플리케이션 클러스터를 실행하라고 한다.
- 그럼 마스터는 컨테이너들을 클러스터 노드들에게 실행하도록 스케줄링 한다.
- 그럼 노드는 쿠버네티스 API를 활용해 마스터와 의사소통해서 쿠버네티스 API를 호출할 수 있다.
- 엔드유저 또한 API를 사용할 수 있다.
미니큐브 활용
쿠버네티스 클러스터는 vm 혹은 물리적 컴퓨터에도 배포할 수 있다. 배포를 위해서는 미니큐브를 사용하라. 이는 쿠버네티스 경량버전이며 vm이 하나만 있다. 로컬머신에 설치할 수 있고 노드가 하나이다.
즉 미니큐브는 vm을 만들어주는것이고 이 안에는 노드가 하나만 들어있다.
실습
미뉴큐브가 미리 설치되어있는 온라인 환경에서 진행한다.
minikube start
를 입력하여 미니큐브를 실행하자
kubectl version
을 입력하여 버전을 한번 보자.
kubctl cluster-info
를 입력해보자.
kubctl get nodes
를 입력하여 노드 정보를 보자.
아까 말한대로(미니큐브에서는 노드 하나만 들어있는) 하나가 떠있는것을 볼 수 있다.
kubectl을 활용하여 애플리케이션 배포
동작하는 쿠버네티스가 있으면 컨테나이저된 앱을 배포할 수 있는데 이를 위해 쿠버네티스 배포 설정을 만들어야 한다.배포 설정은 쿠버네티스가 어떻게 인스턴스를 만들고 갱신해야하는지에 대한 역할을 한다.
이를 만들면 마스터가 노드에 배포를 한다.
애플리케이션 인스턴스가 한번 만들어지면 쿠버네티스 배포 컨트롤러는 지속적으로 인스턴스를 모니터링 한다. 만약 노드가 다운되거나 삭제되면 다른 노드에 배포하게 함으로서 셀프 힐링 매커니즘을 제공한다.
오케스트레이션이 없던시절에서는 스크립트를 사용했었다. 머신에 문제가 있을때 처리방법은 없었다. 쿠버네티스는 애플리케이션 인스턴스를 만들고 노드에 계속 실행하는것으로서 이전과는 다르다.
kubectl을 통해 배포를 관리하고 만들 수 있다. 이는 쿠버네티스 API를 통해 소통한다(즉 마스터와 소통한다.) 배포를 만들때는 컨테이너 이미지를 적어야되고, 몇개의 어플리케이션을 실행하기 원하는지 적어줘야함.
kubectl get nodes
입력하여 노드를 확인
이제 앱 배포를 따라해보자
kubectl run은 배포를 새로만드는것이다.
이를 위해 앱 이름과, 위치를 알려줘야 한다. 도커허브에 올라가있는 이미지가 아닌경우 레파지토리 uri까지 줘야한다. 앱을 특정포트에서 실행하고 싶다면 포트 파라미터까지 줘야한다.
kubectl run kubernetes-bootcamp –image=gcr.io/google-samples/kubernetes-bootcamp:v1 –port=8080
을 입력하여 배포하자. deployment 를 만듦과 동시에 배포됨.
이를 통해 앱을 배포할 적절한 노드를찾았고 스케줄링을 했고 클러스터를 설정했다.
kubectl get deployments
를 입력하여 deployments정보를 얻어보자
파드란 쿠버네티스 안에서 도는것인데 private 하고 isolate하다. 기본적으로 쿠버네티스 안에있는 파드, 서비스들 끼리는 볼 수 있지만 쿠버네티스 클러스터 밖에서는 박에서 못본다, kubectl을 사용하여 api endpoint를 사용해서 어플리케이션과 의사소통할 수 있다.
어플리케이션을 쿠버네티스 클러스터에서 노출시키는 방법은 모듈 4에서 본다.
kubectl proxy
를 입력하여 프록시 다른탭에서 만들면 클러스터 wide , private network와 의사소통 할 수 있게된다. 프록시를 컨트롤 씨로 종료시킬 수도 있다
디폴리먼트 하나, 파드하나 , 레플리카 셋이 하나 있는것을 웹 프리뷰로 볼 수 있다.
이를 만들면 호스트와 쿠버네티스 클러스트간에 연결된것이고, 프록시를 사용하면 API 를 직접 사용할 수 있다.
여기서 말하는 API는 쿠버네티스 매니저의 API
API서버는 자동으로 endpoint 를 각각의 pod기반으로 만들어준다. 우리는 pod네임을 가져오려면 다음과 같이하면된다.
1 | export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}') |
curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/proxy/
를 입력하여 pod의 api로 라우팅할수있다.