[퀵랩] 고급 - 쿠버네티스 솔루션 02/08

안녕하세요, 오늘은 쿠버네티스 엔진에서 지역 영구 디스크를 사용한 워드 프레스 배포를 배워 보겠습니다.

쿠버네티스 엔진 클러스터와 지역 영역 디스크를 사용해 고 가용성의 서비스가 가능한 워드프레스

애플리케이션을 배포하고, 잘 동작하는지 일부러 장애를 발생시켜서 테스트해보는 시간을 가져 보겠습니다. 

 

학습 목표는 다음과 같습니다.

 

1) 쿠버네티스 엔진 클러스터를 지역 자원으로 만듭니다.

2) 복제된 존에 쿠버네티스 스토리지  클래스 리소스를 만듭니다.

3) 워드 프레스를 스토리지 클래스를 활용하여 지역 디스크와 함께 배포합니다.

4) 노드를 삭제하여 지역 장애를 테스트해봅시다.

5) 복제된 다른 존으로 워드 프레스 앱과 데이터의 마이그레이션을 테스트해 봅시다.

 

1. 리전 클러스터 생성하기부터 시작하겠습니다.

클라우드 쉘을 열어서, 다음의 명령어를 실행해 봅시다.

 

CLUSTER_VERSION=$(gcloud container get-server-config --region us-west1

-format=“value(validMasterVersions[0])”)

해당의 명령어는 클러스터 버전을 가져오는 것입니다.

현재 리전은 us-west1으로 생성이 되어있습니다.

export CLOUDSDK_CONTAINER_USE_V1_API_CLIENT=false

그리고 다음의 환경변수를 내보내기 하겠습니다.

 

gcloud container clusters create repd \

--cluster-version=${CLUSTER_VERSION} \

--machine-type=n1-standard-4 \

--region=us-west1 \

--num-nodes=1 \

--node-locations=us-west1-a,us-west1-b,us-west1-c

 

사용한 클러스터 버전을 여기에 사용하여 컨테이너 클러스터를 생성합니다.

생성할 클러스터의 이름은 repd, 머신 타입은 n1-standard-4,

리전은 us-west1, 노드 수는 1개, 노드의 로케이션은

고가용성(서비스가 중단되지 않고 지속되는 성질)의 서비스를 테스팅하기 위해서

us-west1-a, us-west1-b, us-west1-c의 세 개의 존에 만들도록 하겠습니다.

 

결과를 확인해 봅니다. 각각의 존에 노드 수는 1개로 설정했으므로 하나의 노드를 가진 리전 클러스터를 생성했습니다.

내비게이트 버튼을 통해 compute engine 인스턴스를 확인해 볼 수도 있습니다.

 

 

2. 리전 디스크와 함께 앱 배포하기

 

다음의 단계를 거쳐서 테스트해보겠습니다.

 

1) 헬름 설치하기 (쿠버네티스 패키지를 관리하기 위한 도구)

2) 지역 영구 디스크에서 사용되는 쿠버네티스 스토리지 클래스 생성하기

3) 워드 프레스 배포하기

 

curl

https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get

> get_helm.sh

chmod 700 get_helm.sh

./get_helm.sh

 

다음의 명령어를 통해서 헬름을 설치하고, 초기화합니다.

 

 

자 헬름을 초기화합니다.

서비스 계정을 만들고 네임스페이스는 kube-system이라는 공간을 사용해 만들도록 합니다.

 

네임 스페이스에는 기본적으로 세 가지 공간이 있습니다.

 

기본인 default는 다른 네임스페이스가 없는 개체일 때 사용하는 네임 스페이스

kube-system은 쿠버네티스 시스템에 의해서 생성되는 개체입니다.

kube-public은 자동적으로 생성되고 모든 유저들에 의해서 읽힐 수 있는 네임 스페이스입니다.

(인가되지 않은 유저도 포함입니다.) 이 네임스페이스는 일부 리소스가 전체 클러스터에서 공개적으로 표시되고 읽을 수 있어야 하는 경우에 클러스터 사용을 위해서 쓰입니다. 그리고 이 네임스페이스는 하나의 방식이지만 필수적인 것은 아닙니다.

 

https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/

Namespaces

 

 

다음으로 스토리지 클래스를 만들어 보겠습니다.

존은 스토리지 클래스에 나열되어 있고, 쿠버네티스 엔진 클러스터의 존과 동일합니다.

 

kubectl apply -f - <<EOF

kind: StorageClass

apiVersion: storage.k8s.io/v1

metadata:

  name: repd-west1-a-b-c

 provisioner: kubernetes.io/gce-pd

 parameters:

  type: pd-standard

  replication-type: regional-pd

  zones: us-west1-a, us-west1-b, us-west1-c

EOF

 

다음의 명령어를 실행해봅니다.

 

kubectl get storageclass

이 명령어를 수행하여, 스토리지 클래스를 확인할 수 있습니다.

 

스토리지 클래스라는 것을 활용하면, 바로 다음에 만들 영구 볼륨 클레임을 통해

동적으로 영구 볼륨을 할당하도록 만들어 줄 수 있습니다.

 

 

3. 다음으로 영구 볼륨 클레임을 만들어 봅니다.

표준 스토리지 클래스를 활용해서 만들 겁니다.

 

기본적으로 영구 볼륨 클레임이라는 것은, 스토리지에 대한 요청을 얘기합니다.

파드와 비슷한 개념으로, 파드는 노드 리소스를 사용하고, 

영구 볼륨 클레임(Persistent Volume Claim)은 영구 볼륨(Persistent Volume)의 리소스를 사용하는 것입니다.

 

 

다음으로, repd-west1-a-b-c 스토리지 클래스를 사용하여 wp-repd-wordpress라는 PVC를 만듭니다.

 

 

영구 볼륨 클레임이 잘 만들어졌는지 확인해 볼까요?

 

kubectl get persistentvolumeclaims

명령을 실행하면, 앞서 정의한 PVC의 이름으로 만들어진 것을 확인할 수 있습니다.

 

이해를 돕기 위해, 다음의 그림으로 정리를 해보았습니다.

PV, PVC, 스토리지 클래스는 아래와 같습니다.

 

PV(Persistent Volume)은 

관리자가 프로비저닝 하거나 스토리지 클래스를 활용해

동적으로 프로비저닝 한 클러스터의 스토리지

 

PVC(Persistent Volume Claim)은

사용자의 스토리지에 대한 요청

 

Storage Class는 PVC의 스토리지 클래스 이름에 명시해 두면,

바인딩하여 동적으로 PV를 띄울 수 있습니다.

 

4. 워드프레스 배포하기

 

이제 스토리지 클래스도 구성이 되어 있고, 쿠버네티스가 자동으로 사용 가능한 영역(존)에 하나의 적절한 노드를

찾아 영구 디스크를 연결시킵니다.

 

helm install --name wp-repd \

  --set smtpHost= --set smtpPort= --set smtpUser= \

  --set smtpPassword= --set smtpUsername= --set

smtpProtocol= \

  --set persistence.storageClass=repd-west1-a-b-c \

  --set persistence.existingClaim=wp-repd-wordpress \

  --set persistence.accessMode=ReadOnlyMany \

  stable/wordpress

 

1) 만들어 둔 스토리지 클래스를 활용해, 워드프레스 차트를 배포할 수 있습니다.

 

kubectl get pods

2) 사용 가능한 워드 프레스 파드를 리스팅해 봅니다.

해당 파드들이 돌고 있는 것 역시 확인 가능합니다!

 

while [[ -z $SERVICE_IP ]]; do SERVICE_IP=$(kubectl get svc wp-repd-wordpress -o jsonpath='{.status.loadBalancer.ingress[].ip}'); echo "Waiting for service external IP..."; sleep 2; done; echo http://$SERVICE_IP/admin

 

3) 자 이제 서비스 로드 밸런서의 외부 IP 주소가 만들어지는 것을 기다려 봅시다.

 

 

while [[ -z $PV ]]; do PV=$(kubectl get pvc wp-repd-wordpress -o jsonpath='{.spec.volumeName}'); echo "Waiting for PV..."; sleep 2; done

kubectl describe pv $PV

 

4) 그다음, 이 명령어를 실행해서 영구 디스크가 잘 만들어졌는지 확인합니다.

 

echo http://$SERVICE_IP/admin

 

5) 워드 프레스의 어드민 페이지를 가져와 봅니다.

6) 그런 다음 브라우저에서 새로운 탭을 열어서 워드프레스를 열어봅시다.

 

cat - <<EOF

Username: user

Password: $(kubectl get secret --namespace default wp-repd-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)

EOF

 

7) 클라우드 쉘로 돌아와서, username과 패스워드를 받아와서 앱으로 로그인합니다.

 

자 이제 3개의 존에서 지역 영구 디스크로 구성된 워드프레스 배포가 되었습니다.

 

 

5. 영역 장애 테스팅

 

서비스가 제대로 생성되었는지, 테스팅해봅니다.

노드를 없앴을 때, 자동적으로 체크하여 쿠버네티스가 다른 존으로 워크 로드를 이동시키고

영구 디스크를 붙이는 작업을 할 것입니다.

 

NODE=$(kubectl get pods -l app.kubernetes.io/instance=wp-repd  -o jsonpath='{.items..spec.nodeName}')

 

ZONE=$(kubectl get node $NODE -o jsonpath="{.metadata.labels['failure-domain\.beta\.kubernetes\.io/zone']}")

 

IG=$(gcloud compute instance-groups list --filter="name~gke-repd-default-pool zone:(${ZONE})" --format='value(name)')

 

노드, 존, 인스턴스 그룹을 차례대로 세팅합니다.

 

다음으로

 

echo "Pod is currently on node ${NODE}"

echo "Instance group to delete: ${IG} for zone: ${ZONE}"

 

차례로 명령어를 실행하여, 결과 값이 잘 출력되는지 확인합니다.

 

kubectl get pods -l app.kubernetes.io/instance=wp-repd -o wide

 

이 명령어를 실행하면, 노드를 확인할 수 있는데 노드명을 복사해 둡시다.

후에 이 노드를 삭제할 것이니까요.

 

gcloud compute instance-groups managed delete ${IG} --zone ${ZONE}

그런 다음, 이제 노드를 삭제합니다.

 

kubectl get pods -l app.kubernetes.io/instance=wp-repd -o wide

해당 명령어를 수행하여, wp-repd라는 pods를 가져와 봅니다.

 

echo http://$SERVICE_IP/admin

이제 서비스 IP를 넣고 명령어를 실행해 봅시다.

 

이것으로 랩은 종료가 됩니다.

하지만, 내용이 어려웠기 때문에 부연 설명을 붙여보았습니다.

 

해당 내용은 단지 스토리지 클래스, 영구 볼륨, 영구 볼륨 클레임으로 끝나는 내용이 아닙니다.

가볍게 비유하자면, 이것은 동적 프로비저닝을 통해서 PVC를 만들어 먼저 명시해 두었던

'리전 us-west1-a, us-west1-b, us-west1-c에 영구 디스크를 만들고 어떻게 해라!'

라는 내용을 토대로 리전에 문제가 생겼을 때 자동적으로 처리를 했던 내용입니다.

 

 

쉬운 이해를 위해서 자동차 구매를 하려고 했다고 가정해 보겠습니다.

구매하려던 자동차가 자동차 명세서와 내용이 다릅니다. 그러면 오른쪽과 같은 결과가 나오겠죠?

 

마찬가지로, 쿠버네티스는 PV와 PVC에 대해서 클러스터가 감시하고 있습니다.

이것은 동적 프로비저닝의 한 예인데, 클러스터는 PV에 설명해 두었던 스토리지와 PVC가

같지 않았다고 한다면, 클러스터는 스토리지 클래스에 기술되어있던 내용을 토대로

(us-west1-a, us-west1-b, us-west1-c에 persistent Disk를 만들어라!)

동적 프로비저닝을 시도합니다.

 

이것이 바로 오늘 했던 랩의 내용이 되겠습니다.

 

 

그럼, 다음 랩에서 뵙겠습니다!