블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

쿠버네티스 패키지 매니저 HELM

#2-1 .Chart
조대협 http://bcho.tistory.com

Helm Chart

차트는 helm의 패키지 포맷으로, 하나의 애플리케이션을 설치하기 위한 파일들로 구성되어 있다. 예를 들어 tomcat을 설치하기 위한 쿠버네티스의 pod,service,deployment를 위한 YAML 파일등을 포함한다.

템플릿과 밸류

Helm 은 기본적으로 템플릿의 개념을 사용한다. 템플릿 파일을 만들어놓은 후에, 밸류 값을 채워 넣어서 쿠버네티스 리소스를 정의한 YAML 파일을 생성한다. 예제를 살펴보자

Helm 은 기본적으로 템플릿의 개념을 사용한다. 템플릿 파일을 만들어놓은 후에, 밸류 값을 채워 넣어서 쿠버네티스 리소스를 정의한 YAML 파일을 생성한다. 예제를 살펴보자.


먼저 templates/helloworld.yaml 파일을 정의한다.

apiVersion: apps/v1beta2

kind: Deployment

metadata:

 name: {{ .Values.name }}-deployment

spec:

 replicas: {{ .Values.replicaCount }}

 minReadySeconds: 5

 selector:

   matchLabels:

     app: {{ .Values.name }}

 template:

   metadata:

     name: {{ .Values.name }}-pod

     labels:

       app: {{ .Values.name }}

   spec:

     containers:

     - name: {{ .Values.name }}

       image: gcr.io/terrycho-sandbox/helloworlds:v1

       imagePullPolicy: Always

       ports:

       - containerPort: 8080

---

apiVersion: v1

kind: Service

metadata:

 name: {{ .Values.name }}-svc

spec:

 selector:

   app: {{ .Values.name }}

 ports:

   - name: http

     port: 80

     protocol: TCP

     targetPort: 8080

 type: LoadBalancer


그리고 ./values.yaml 파일을 아래와 같이 정의한다.


name: "helloworld"

replicaCount: 3


템플릿은 값을 채울 수 있는 말 그대로 템플릿이고, Value의 값을 이용해서 값을 채운다.

이를 개념적으로 표현해보면 다음과 같은 형태가 된다.



좌측은 템플릿 파일이고, 템플릿에서 밸류값은 별도의 파일에 정의한다.

정의한 키/밸류 형식으로 name:”helloworld”로 정의하였고, replicaCount: 2로 정의하였다

그리고 이 밸류값을 불러들이기 위해서는 {{.Value.키이름}} 식으로 템플릿내에 정의한다.

위의 예제에서 보면 name등에 {{.Value.name}} 으로 정의하였고, replicas 수는 {{ .Value.replicaCount }} 로 정의한다.

이렇게 정의된 템플릿에 밸류 내용을 정의하면 오른쪽 처럼 YAML 파일을 생성할 수 있다.


외부에서 Value를 받는 방법

Value값을 values,yaml에 지정해놨지만, 설치에 따라서 각 값을 변경하고 싶은 경우가 있다. 예를 들어 replicaCount를 3이 아니라 10으로 변경하고 싶을 경우에는 values.yaml 파일을 일일이 에디트 해야 한다. 나중에, 차트를 차트 리파지토리에 등록하기 위해서는 압축된 파일 형태를 사용하는데, 이 경우에는 그러면 차트 압축 파일을 다운로드 받은 후에 압축을 풀고나서, 내용을 수정하고 설치에 사용해야 하는 불편함이 있다.

이렇게 일일이 수정하지 않고 CLI에서 변경하고 싶은 인자만 간단하게 지정할 수 있는 방법이 없을까?

helm install 이나 upgrade시에  --set 옵션을 사용하면 된다. 예를 들어 values.yaml에 정의된 replicaCount를 10으로 변경하고자 하면 다음과 같이 하면 된다. %helm template --name myrelease --set replicaCount=10 ./helloworld


아래는 template 명령을 이용해서 테스트한 결과이다.   replicas가 10으로 변경된것을 볼 수 있다.

---

# Source: helloworld/templates/helloworld.yaml

apiVersion: apps/v1beta2

kind: Deployment


만약 설정값이 많아서 --set 을 이용해서 parameter로 넘기기가 어렵다면, 필요한 변수만 파일로 만들어서 넘길 수 있다.

예를 들어 myvalue.yaml 에 아래와 같이 name만 “fromValuefile” 로 정의를 한후에,


name: "fromValuefile"


helm install에서 -f 옵션으로 value 파일을 지정할 수 있다.

%helm install -f myvalues.yaml --name newrelease --dry-run --debug ./helloworld


결과를 보면 다음과 같다.

# Source: helloworld/templates/helloworld.yaml

apiVersion: apps/v1beta2

kind: Deployment

metadata:

 name: fromValuefile-deployment

spec:

 replicas: 3

:

myvalues.yaml에 지정한 name에 의해서 Deployment name이  fromValuefile-deployment로 변경되고, replica 수는 원래 values.yaml에 지정한대로 3을 사용한 것을 확인할 수 있다.


디렉토리 구조

개념을 이해 하였으면, 파일을 어디에 저장하는지 디렉토리 구조를 살펴보자, helloworld라는 차트를 만들 것인데, helloworld라는 디렉토리를 만든다.

그리고 그 아래 템플릿들은 templates 라는 디렉토리에 yaml 로 정의한다. 여기에 채울 value들은 helloworld/values.yaml 파일내에 저장한다.



그리고 helloworlds/Chart.yaml 이라는 파일을 생성해야 하는데, 이 파일에는 이 헬름 차트에 대한 버전이나 작성자, 차트 이름과 같은 메타 정보를 정의한다.


다음은 Chart.yaml 의 내용이다.

apiVersion: v1

appVersion: "1.0"

description: A Helm chart for Kubernetes

name: helloworld

version: 0.1.0

테스트(검증)

헬름 차트 작성이 끝났으면 제대로 작동하는지 검증을 해볼 수 있다. 먼저 문법적인 오류가 없는지 확인 하는 명령은 helm lint 명령을 사용하면 된다. 명령어 실행은 차트 디렉토리 위에서 해야 한다. 이 예제에서는 ../helloworld 디렉토리가 된다.

실행하면 다음과 같은 결과를 볼 수 있다.


%helm linit ./helloworld

==> Linting ./helloworld/

[INFO] Chart.yaml: icon is recommended


1 chart(s) linted, no failures


문법적인 오류가 없는지 점검을 해준다. 다음으로 탬플릿에 밸류가 제대로 적용되서 원하는 YAML을 제대로 생성해나가는지 검증해야 하는데, helm template이라는 명령어를 사용하면 된다. helm lint 명령과 마찬가지로 차트가 저장된 디렉토리의 상위 디렉토리 (../helloworld)에서 실행한다.

다음은 helm template 명령을 실행한 결과이다.


%helm template ./helloworld

# Source: helloworld/templates/helloworld.yaml

apiVersion: apps/v1beta2

kind: Deployment

metadata:

 name: helloworld-deployment

spec:

 replicas: 2

 minReadySeconds: 5

 selector:

   matchLabels:

     app: helloworld

 template:

   metadata:

     name: helloworld-pod

     labels:

       app: helloworld

   spec:

     containers:

     - name: helloworld

       image: gcr.io/terrycho-sandbox/helloworlds:v1

       imagePullPolicy: Always

       ports:

       - containerPort: 8080


내용 처럼 Value.name과  Value.replicaCount 값이 채워져서 Deployment 리소스에 대한 YAML 파일이 생성된것을 확인할 수 있다.

helm template 명령을 helm 클라이언트에서 tiller 서버 접속없이 template에 값이 채워지는지만 테스트를 하는 것이고, tiller 서버에 연결해서 테스트 할 경우에는 helm install --dry-run 옵션을 사용한다.  그리고, 내용을 확인하기 위해서 --debug 옵션을 추가한다.

helm install --name myrelease --dry-run --debug ./helloworld 이렇게 명령어를 사용하면 되는데, 장점은, 실제 서버에 연결해서 같은 릴리즈 버전이 있는지 등의 체크를 해주기 때문에, 실수를 막을 수 있다.

아래는 같은 릴리즈 버전으로 설치하는 것을 --dry-run으로 테스트한 결과이다.


% helm install --name myrelease --dry-run --debug ./helloworld

[debug] Created tunnel using local port: '56274'


[debug] SERVER: "127.0.0.1:56274"


[debug] Original chart version: ""

[debug] CHART PATH: /Users/terrycho/dev/workspace/kube/kubernetes-tutorial/31.helm/helloworld


Error: a release named myrelease already exists.

Run: helm ls --all myrelease; to check the status of the release

Or run: helm del --purge myrelease; to delete it


차트를 같은 이름(릴리즈명/뒤에서 다시 설명함)이 있기 때문에 설치할 수 없다 것을 테스트 단계에서 미리 확인할 수 있다.

실제 설치

그러면 생성한 헬름 차트를 이용해서 쿠버네티스에 리소스를 실제로 설치해보자. 설치 방법은 차트가 있는 디렉토리에서 helm install  명령을 이용해서 인스톨을 하면 된다. 이때 --name이라는 이름으로 설치된 차트 인스턴스의 이름을 설정해줘야 한다. 만약에 이름을 정해주지 않으면 임의의 이름이 자동으로 생성되어 사용된다.


%helm install --name helloworld ./helloworld/


명령을 실행하면 아래와 같이 deployment가 생성되는 것을 확인할 수 있다. 예제에서 설명은 하지 않았지만, 테스트에 사용된 코드에는 Service를 배포하는 부분이 함께 포함되어 있기 때문에 아래 실행결과를 보면 Service까지 같이 생성된것을 확인할 수 있다.


NAME:   helloworld

LAST DEPLOYED: Fri Jun  7 23:01:44 2019

NAMESPACE: default

STATUS: DEPLOYED


RESOURCES:

==> v1beta2/Deployment

NAME                   AGE

helloworld-deployment  1s


==> v1/Pod(related)


NAME                                    READY STATUS RESTARTS AGE

helloworld-deployment-696fc568f9-mc6mz  0/1 ContainerCreating 0 0s

helloworld-deployment-696fc568f9-nsw48  0/1 ContainerCreating 0 0s


==> v1/Service


NAME            AGE

helloworld-svc  1s


설치가 완료되었으면 리소스가 제대로 생성되었는지 확인을 해보기 위해서 kubectl get deploy 명령을 실행한다.


%kubectl get deploy

kubectl get deploy

NAME                    DESIRED CURRENT UP-TO-DATE   AVAILABLE AGE

helloworld-deployment   2 2 2         2 10m


위와 같이 Deployment 리소스가 생성 된것을 확인할 수 있다.

헬름을 통해서 설치된 차트들은 helm list 명령을 이용해서, 설치 상태를 확인할 수 있다.

helm list 명령을 실행해보면 아래와 같이 helloworld 차트가 설치된것을 확인할 수 있다.


%helm list

NAME               REVISION UPDATED                  STATUS   CHART            APP VERSION NAMESPACE

helloworld         1        Fri Jun  7 23:01:44 2019 DEPLOYED helloworld-0.1.0 1.0  




본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


구글 클라우드에서 Auto scale out을 사용해 보자


조대협 (http://bcho.tistory.com)


클라우드의 가장 큰 장점중의 하나는 들어오는 부하에 따라서 서버를 늘리고 줄일 수 있는 유연성에 있다. 그중에서도 부하량에 따라서 서버를 자동으로 늘리고 줄여 주는 auto scaling 기능은 거의 필수라고 할 수 있다.


이 글에서는 구글 클라우드 COMPUTE SERVICE에서 오토스케일링을 설정하는 방법에 대해서 알아보도록 한다.


오토 스케일링을 설정하는 절차를 보면 다음과 같다.


  • 인스턴스 템플릿 정의

  • 인스턴스 템플릿으로 managed group 생성

  • 로드 밸런서 연결


인스턴스 그룹과 로드밸런서의 개념등은 이전의 로드밸런서를 이용한 부하 분산 글 (http://bcho.tistory.com/1113) 를 먼저 꼭 참고 하기 바란다.


인스턴스 템플릿 정의


인스턴스 템플릿이란, 인스턴스를 생성할때의 설정값 (디스크 이미지, 인스턴스 사이즈, 네트워크 설정)을 미리 정해놓고, 인스턴스를 생성할때 템플릿에 정의된 설정값에 따라서 인스턴스를 생성하게 해주는 설정 값의 모음이다.


디스크 이미지 생성

인스턴스 템플릿을 통해서 인스턴스를 생성할때는 디스크 이미지를 선택하도록 되어 있는데, OS와 각종 서버 프로그램 (웹서버)등 이 미리 설치되어 있는 이미지를 생성해놓고, 이 이미지로 템플릿을 생성해놓고, 오토 스케일링 시에, 이 이미지로 인스턴스를 생성하게 한다.  아니면 일반 이미지 (OS만 설치되어 있는 이미지)를 사용하여 템플릿을 만들고 서버가 기동될때 마다 자동으로 필요한 소프트웨어 (애플리케이션, 미들웨어)등을 설치할 수 있도록 스크립트 처리를 할 수 있지만 이 방식은 서버가 기동할때 마다 설치에 걸리는 시간이 있기 때문에, 그 다지 권장하지 않는다.


인스턴스 생성 및 소프트웨어 설치

디스크 이미지를 생성 하는 방법은 인스턴스를 하나 생성해서, 그 인스턴스에 필요한 소프트웨어나 애플리케이션을 모두 설치 한다.


스냅샷 생성

다음으로 인스턴스의 스냅샷을 생성해야 한다.

스냅샷은 Compute Engine 메뉴에서 Snapshots 메뉴를 선택하고 Create snapshot  메뉴를 선택하면 스냅샷을 추출할 수 있다. 스냅샷 추출 메뉴에서는 아래와 같이 스냅샷의 이름을 선택하고 “Source disk” 항목에서, 스냅샷을 추출할 디스크를 선택해야 하는데, 앞에서 생성한 인스턴스의 디스크를 선택하면 된다.




디스크 생성

이 스냅샷을 가지고 디스크를 생성한다. 디스크 생성은 Compute Engine에서 Disks 메뉴를 선택 한다.



다음으로 Create Disk 메뉴를 선택한후에, 디스크 이름을 as-image-disk로 선택하고, Zone을 asia-east1-a 로 지정한다. 다음으로, 어느 소스에서 디스크를 만들지를 선택하기 위해서 Source type을 snapshot으로 선택하고 앞에서 생성한 snapshot을 선택한다.




이미지 생성

디스크가 생성 되었으면 이 디스크를 이용해서 인스턴스 이미지를 생성한다. Compute Engine 메뉴에서 Images를 선택한다.






다음 Create an image 메뉴를 선택하면 아래와 같은 화면이 나오는데, image 이름을 입력하고, 아래와 같이 Source disk를 앞에서 생성한 as-image-disk 를 선택한다.




템플릿 생성

이미지 생성이 끝났으면 이 이미지를 가지고 인스턴스 템플릿을 생성해보자. Compute Engine 메뉴에서 Instance templates 메뉴를 선택한다.



다음으로 Create instance template를 선택해서 새로운 템플릿을 생성한다.

템플릿에 들어가는 내용은 인스턴스를 생성할때 들어가는 내용과 동일하다.

단 템플릿을 만들때 Boot disk를 앞에서 생성한 as-image를 선택해준다.




다음으로, 이 템플릿으로 생성된 인스턴스가 기동될때 자동으로 애플리케이션을 기동하기 위해서 템플릿 설정시 Management 부분에서 Start up script 부분을 아래와 같이 서술해 준다. 아래 스크립트는 예전에도 몇번 다루었지만, 이 이미지내에 설치되어 있는 node.js 애플리케이션을 자동으로 기동해주는 스크립이다.



오토 스케일링 그룹 생성

이제 오토 스케일링 을 지원하기 위한 그룹을 생성하기 위해서 템플릿 생성이 끝났다. 이제, 이 템플릿을 이용해서 오토 스케일링을 지원하는 그룹을 생성해보자


Compute Engine 메뉴에서 Instance groups 를 선택하고 그룹 생성을 선택하자.

그룹 이름을 입력하고, 그룹을 배포한 Zone을 선택한다. (asia-east1-a)를 선택하였다.

다음으로 creation method에서 Use instance template을 선택하고, 앞단계에서 생성한 as-instance-template 을 선택한다.


그리고 아래에 Autoscaling을 on으로 선택한다.

다음에 나오는 Autoscale based on 은 오토스케일링 조건을 어떤 기준으로 할것인가를 선택하는 것인데, 여기서는 CPU를 기반으로 하였고, target CPU가 50% 이상이 지속되면 자동으로 오토 스케일 아웃을 하도록 하였다. (보통 80% 내외가 적절값인데, 여기서는 테스트를 위해서 오토 스케일링이 쉽게 되게 하기 위해서 수치를 낮추었다.)




Minimum number of  instance 는 이 그룹에서 유지되는 최소한의 인스턴스 수이다. 부하가 없어서 스케일 다운이 되더라도 최소한으로 운영되는 인스턴스 수이다. 다음으로 나오는 Maximum number of instances 는 최대로 스케일 아웃이 될 수 있는 인스턴스 수이다 즉, 이 그룹의 위의 설정에 따라서 1~10개의 인스턴스 사이를 부하에 따라서 자동으로 스케일링 인/아웃을 하게 된다.


마지막에 표신된 Cool-down period는

“The cool down period is the number of seconds the autoscaler should wait after a virtual machine has started before the autoscaler starts collecting information from it. This accounts for the amount of time it can take for a virtual machine to initialize.

https://cloud.google.com/compute/docs/autoscaler/scaling-cpu-load-balancing “

오토 스켈링으로 자동으로 생성된 인스턴스가 그룹에 조인할때 까지 대기하는 시간을 정의한다. 인스턴스가 생성이 되더라도, start up 스크립트를 실행하고 애플리케이션을 실행하는 등 자체 준비 시간이 필요한데, 이 시간을 기다리지 않고 바로 로드밸런서에 붙여 버리게 되면 당연히 준비가 안되었기 때문에 에러가 난다. 그래서 cool-down period는 서버가 준비될때 까지의 시간이라고 생각 하면 된다.

로드 밸런서 설정

그룹 생성이 끝났으면 이 그룹을 로드밸런서에 연결 해줘야 한다.

로드밸런서 설정 및 연결은 앞의 글 http://bcho.tistory.com/1113 을 참고하기 바란다.

테스트

이제 모든 설정이 끝났다. 테스트를 해보자.

오토 스케일링을 적용한 그룹을 모니터링 해보면 아래와 같이 앞에서 설정한대로 한개의 인스턴스만 기동되고 있음을 확인할 수 있다.




Apache ab 부하 테스트 툴을 이용해서 부하를 넣어보자.

%ab -n 1000 -c 100 http://130.211.11.38/

로 해서 100개의 클라이언트로 각각 1000개의 부하를 아래 처럼 주었다.




콘솔에서 오토스케링을 적용한 그룹을 살펴보면, 다음과 같이 인스턴스가 자동으로 늘어난것을 확인할 수 있다.


오토스케일링에 대한 몇가지 추가적인 내용들


앞에서 기본적인 CPU 기반의 오토스케일링에 대해서 알아보았다. 오토 스케일링에 대해서 몇가지 추가적인 사항을 정리해보면 다음과 같다.

오토스케일링 조건

앞의 예제에서는 간단하게 CPU 기반의 오토스케일링 규칙을 정의했는데, 오토 스케일러는 다음과 같은 조건에 의해서 스케일링이 가능하다.

  • CPU

  • 로드밸랜서의 사용량

  • Custom metric

  • 위에 3가지를 조합한 값


CPU는 앞에서 이미 살펴보았고, 이외에 로드밸런서의 Utilization이 높아지는 경우 스케일링이 가능하다.

다음으로 흥미로운 것은 Custom metric인데, 인스턴스의 모니터링 지표를 사용자가 직접정의할 수 있다. CPU뿐 아니라 IO또는 애플리케이션 서버 (Tomcat, Django 등)의  응답 시간이나 Idle Thread의 수 등을 모니터링 지표로 정의한 후에, 이 지표가 일정 값이 넘어가면 오토 스케일 아웃을 시킬 수 있다.

(자세한 내용은 https://cloud.google.com/compute/docs/autoscaler/scaling-cloud-monitoring-metrics#custom_metrics_beta  참고)


그리고 마지막으로 위의 3 지표를 조합해서 스케일링 조건을 정의할 수 있다.

예를 들어서 CPU 사용량이 60% 이거나 로드밸런서의 타겟 인스턴스의 Utilization이 50% 이거나, 타겟 인스턴스의 Custom metric 값이 1000 일때 스케일링을 하도록 할 수 있다.


오토 스케일링을 결정하는 상세한 조건에 대해서는 https://cloud.google.com/compute/docs/autoscaler/understanding-autoscaler-decisions

를 참고하기 바란다.

AutoHealing

오토 스케일링 그룹의 경우 Auto healing 이라는 기능을 제공하는데, HTTP health check를 이용하는 경우에, 인스턴스가 일정 시간 동안 응답이 없으면 문제가 있는 인스턴스라고 생각하고, 자동으로 재 기동을 해준다. (현재는 베타)

https://cloud.google.com/compute/docs/instance-groups/?hl=en_US&_ga=1.104223488.1034565888.1463987102#disabling_creation_retries_mode

Monitoring managed instance groups with health checks

Beta

This is a Beta release of Autohealing. This feature is not covered by any SLA or deprecation policy and may be subject to backward-incompatible changes.

You can apply HTTP health checks to managed instance groups to verify that services are running properly on the instances in that group. If a health check determines that a service has failed on an instance, the group automatically recreates that instance. These checks are more precise than simply verifying that a server is in a RUNNING state.

결론

지금까지 구글 클라우드의 오토 스케일 아웃 기능에 대해서 알아보았다. 클라우드 컴퓨팅에서 많은 장점을 제공하는 기능인 만큼 잘 숙지하여 적용을 하고, 특히나 서비스 부하 모델에 맞는 적절한 Min,Max 인스턴스 수의 설정과 스케일링 조건을 설정하여 (테스트를 통하여) 자원을 효율적으로 사용하고 부하에 적절하게 대응할 수 있도록 하자.



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. zinbe 2016.11.04 09:57  댓글주소  수정/삭제  댓글쓰기

    구글 오토 스케일 사용할때 문의 드립니다~
    로드에 따라서 템플릿/스냅샷으로 서버를 추가하게되면
    항상 동일한 소스를 가진 템플릿/스냇샷만 적용되는것인가요??

    git으로 소스를 업데이트 하고 적용하려면 어떻게 해야되나요??