개요

이 실습에서는 컨테이너의 Kubernetes 활성 프로브 및 준비 프로브를 구성하고 테스트합니다.

목표

이 실습에서는 다음 작업을 수행하는 방법을 알아봅니다.

• 활성 프로브 구성 및 테스트
• 준비 프로브 구성 및 테스트

실습 설정

Qwiklabs에 액세스하기

각 실습에서는 정해진 기간 동안 새 Google Cloud 프로젝트와 리소스 집합이 무료로 제공됩니다.

1. 시크릿 창을 사용하여 Qwiklabs에 로그인합니다.

2. 실습 사용 가능 시간(예: 1:15:00)을 참고하여 해당 시간 내에 완료합니다.
   일시중지 기능은 없습니다. 필요한 경우 다시 시작할 수 있지만 처음부터 시작해야 합니다.

3. 준비가 되면 실습 시작을 클릭합니다.

4. 실습 사용자 인증 정보(사용자 이름 및 비밀번호)를 기록해 두세요. Google Cloud Console에 로그인합니다.

5. Google Console 열기를 클릭합니다.

6. 다른 계정 사용을 클릭한 다음, 안내 메시지에 이 실습에 대한 사용자 인증 정보를 복사하여 붙여넣습니다.
   다른 사용자 인증 정보를 사용하는 경우 오류가 발생하거나 요금이 부과됩니다.

7. 약관에 동의하고 리소스 복구 페이지를 건너뜁니다.

초기 로그인 단계를 완료하면 프로젝트 대시보드가 표시됩니다.

Google Cloud Shell 활성화하기

Google Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다.

Google Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.

1. Cloud 콘솔의 오른쪽 상단 툴바에서 'Cloud Shell 열기' 버튼을 클릭합니다.

   

2. 계속을 클릭합니다.

환경을 프로비저닝하고 연결하는 데 몇 분 정도 소요됩니다. 연결되면 사용자가 미리 인증되어 프로젝트가 PROJECT_ID로 설정됩니다. 예:

gcloud는 Google Cloud의 명령줄 도구입니다. Cloud Shell에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.

• 다음 명령어를 사용하여 사용 중인 계정 이름을 나열할 수 있습니다.

gcloud auth list

출력:

Credentialed accounts: - @.com (active)

출력 예시:

Credentialed accounts: - google1623327_student@qwiklabs.net

• 다음 명령어를 사용하여 프로젝트 ID를 나열할 수 있습니다.

gcloud config list project

출력:

[core] project =

출력 예시:

[core] project = qwiklabs-gcp-44776a13dea667a6 참고: gcloud 전체 문서는 gcloud CLI 개요 가이드를 참조하세요.

작업 1. 실습용 GKE 클러스터에 연결

이 작업에서는 실습용 GKE 클러스터에 연결하여 실습용 저장소를 실습용 Cloud Shell에 클론합니다.

실습용 GKE 클러스터에 연결

1. Cloud Shell에서 다음 명령어를 입력하여 영역 및 클러스터 이름의 환경 변수를 설정합니다.

export my_zone={{{ project_0.default_zone | "ZONE" }}} export my_cluster=standard-cluster-1

2. kubectl 명령줄 도구의 명령줄 자동 완성을 구성합니다.

source <(kubectl completion bash)

3. 다음과 같이 kubectl의 클러스터에 대한 액세스 권한을 구성합니다.

gcloud container clusters get-credentials $my_cluster --zone $my_zone

4. Cloud Shell에서 다음 명령어를 입력하여 실습용 저장소를 실습용 Cloud Shell에 클론합니다.

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

5. 작업 디렉터리로 연결되는 바로가기, 즉 소프트 링크를 생성합니다.

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

6. 이 실습의 샘플 파일이 포함된 디렉터리로 이동합니다.

cd ~/ak8s/Probes/

작업 2. 활성 프로브 구성

활성 프로브 구성

이 작업에서는 활성 프로브를 배포하여 실행 상태에서 문제가 발생한 애플리케이션을 감지합니다. 애플리케이션에서 일시적으로 트래픽을 처리할 수 없는 경우가 종종 있습니다. 예를 들어, 애플리케이션 시작 시에는 대량의 데이터 또는 구성 파일을 로드해야 할 수 있습니다.

그런 경우, 애플리케이션을 종료할 수도 없고 애플리케이션에 요청을 전송해서도 안 됩니다. Kubernetes는 준비 프로브를 제공하여 이와 같은 상황을 감지하고 해결합니다. 준비가 되지 않은 것으로 보고되는 컨테이너가 있는 포드는 Kubernetes 서비스를 통해 트래픽을 수신하지 않습니다.

준비 프로브는 활성 프로브와 유사하게 구성됩니다. 유일한 차이점은 livenessProbe 필드가 아닌 readinessProbe 필드를 사용한다는 것입니다.

exec-liveness.yaml이라는 포드 정의 파일이 제공되고, Busybox를 실행하는 liveness라는 간단한 컨테이너 및 컨테이너 내 /tmp/healthy 파일에 대해 cat 명령어를 사용하는 활성 프로브를 정의하여 5초마다 활성 여부를 테스트합니다.

liveness 컨테이너의 시작 스크립트는 시작 시 /tmp/healthy를 생성하고 30초 후 이를 삭제해 활성 프로브가 감지할 수 있는 서비스 중단을 시뮬레이션합니다.

apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec spec: containers: - name: liveness image: k8s.gcr.io/busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5

1. Cloud Shell에서 다음 명령어를 사용하여 포드를 만듭니다.

kubectl create -f exec-liveness.yaml

2. 30초 이내에 포드 이벤트를 조회합니다.

kubectl describe pod liveness-exec

출력은 실패한 활성 프로브가 아직 없음을 나타냅니다.

압축 샘플 출력:

Type: Secret (a volume populated by a Secret) SecretName: default-token-wq52t Optional: false QoS Class: Burstable Node-Selectors: Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age ... Message ---- ------ ---- ... ------- Normal Scheduled 11s ... Successfully assigned liveness-e ... Normal Su...ntVolume 10s ... MountVolume.SetUp succeeded for ... Normal Pulling 10s ... pulling image "k8s.gcr.io/busybox" Normal Pulled 9s ... Successfully pulled image "k8s.g ... Normal Created 9s ... Created container Normal Started 9s ... Started container

여기에 표시된 샘플 출력은 읽기 편하도록 압축된 내용이며, 화면에 훨씬 더 자세한 내용이 표시됩니다.

3. 35초 후에 포드 이벤트를 다시 조회합니다.

kubectl describe pod liveness-exec

출력된 내용 하단에 활성 프로브가 실패하여 컨테이너가 종료되고 다시 생성되었다는 메시지가 표시됩니다.

압축 샘플 출력:

Type: Secret (a volume populated by a Secret) SecretName: default-token-wq52t Optional: false QoS Class: Burstable Node-Selectors: Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age ... Message ---- ------ ---- ... ------- Normal Scheduled 2m ... Successfully assigned liveness-e ... Normal Su...ntVolume 2m ... MountVolume.SetUp succeeded for ... Normal Pulling 49s ... pulling image "k8s.gcr.io/busybox" Normal Pulled 49s ... Successfully pulled image "k8s.g ... Normal Created 49s ... Created container Normal Started 49s ... Started container Normal Killing 49s ... Killing container with id docker://liveness:Container failed liveness probe.. Container will be killed and recreated. Warning Unhealthy 5s ... Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory

4. 60초를 더 기다렸다가, 컨테이너가 다시 시작되었는지 확인합니다.

kubectl get pod liveness-exec

다음 출력은 활성 프로브에서 감지된 실패의 결과로 '다시 시작'한 경우가 늘어났음을 보여줍니다.

샘플 출력:

NAME READY STATUS RESTARTS AGE liveness-exec 1/1 Running 2 4m

5. 활성 프로브 데모 포드를 삭제합니다.

kubectl delete pod liveness-exec

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 활성 프로브 구성

작업 3. 준비 프로브 구성

포드가 성공적으로 시작하고 활성 프로브가 이를 정상으로 간주하더라도 트래픽을 수신할 준비가 바로 되지 않을 가능성이 높습니다. 이는 부하 분산기와 같이 서비스에 백엔드로 작동하는 배포에 나타나는 일반적인 현상입니다. 준비 프로브는 포드와 포드의 컨테이너가 트래픽 수신을 시작할 준비가 되었는지 판단하는 데 사용됩니다.

준비 프로브는 활성 프로브와 유사하게 구성됩니다. 구성상의 유일한 차이점은 livenessProbe 필드가 아닌 readinessProbe 필드를 사용한다는 것입니다. 준비 프로브는 특정 컨테이너의 준비 여부를 컨트롤하며, 서비스는 준비 프로브를 통해 컨테이너로부터 트래픽을 전송받을 수 있는 시기를 결정합니다.

이 작업에서 readiness-deployment.yaml이라는 포드 정의 파일이 제공되어 부하 분산기와 함께 테스트 웹 서버 역할을 하는 단일 포드를 생성합니다.

컨테이너에는 준비 프로브가 정의되어 있고 이 프로브가 컨테이너 내 /tmp/healthz 파일에 대해 cat 명령어를 사용하여 5초마다 준비 여부를 테스트합니다.

각 컨테이너에는 활성 프로브도 정의되어 있고 이 프로브가 해당 컨테이너 내 동일 파일에 대해 cat 명령어를 사용하여 5초마다 준비 여부를 테스트합니다. 하지만 복잡한 시작 프로세스로 인해 컨테이너 시작 후 안정화에 시간이 필요한 애플리케이션을 시뮬레이션하느라 시작 시간이 45초간 지연될 수도 있습니다.

서비스가 트래픽을 처리하기 시작하면, 이와 같은 패턴으로 서비스는 트래픽을 처리할 준비가 된 컨테이너에만 트래픽을 전달합니다.

apiVersion: v1 kind: Pod metadata: labels: demo: readiness-probe name: readiness-demo-pod spec: containers: - name: readiness-demo-pod image: nginx ports: - containerPort: 80 readinessProbe: exec: command: - cat - /tmp/healthz initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: readiness-demo-svc labels: demo: readiness-probe spec: type: LoadBalancer ports: - port: 80 targetPort: 80 protocol: TCP selector: demo: readiness-probe

1. Cloud Shell에서 다음 명령어를 사용하여 포드를 만듭니다.

kubectl create -f readiness-deployment.yaml

2. Cloud Shell에서 readiness-demo-svc 부하 분산기 서비스의 상태를 확인합니다.

kubectl get service readiness-demo-svc

3. 브라우저 창에 IP 주소를 입력하면 사이트에 도달할 수 없음을 나타내는 오류 메시지가 표시됩니다.

4. 포드의 이벤트를 확인합니다.

kubectl describe pod readiness-demo-pod

다음 출력은 준비 프로브가 실패했음을 나타냅니다.

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m24s default-scheduler Successfully assigned default/readiness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 2m23s kubelet Pulling image "nginx" Normal Pulled 2m23s kubelet Successfully pulled image "nginx" Normal Created 2m23s kubelet Created container readiness-demo-pod Normal Started 2m23s kubelet Started container readiness-demo-pod Warning Unhealthy 35s (x21 over 2m15s) kubelet Readiness probe failed: cat: /tmp/healthz: No such file or directory

활성 프로브와 달리 비정상 준비 프로브는 포드 재시작을 트리거하지 않습니다.

5. 다음 명령어를 사용하여 준비 프로브가 확인할 파일을 생성합니다.

kubectl exec readiness-demo-pod -- touch /tmp/healthz

이제 포드 설명의 Conditions 섹션에 Ready의 값이 True로 표시됩니다.

kubectl describe pod readiness-demo-pod | grep ^Conditions -A 5

출력:

Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True

6. 이제 readiness-demo-svc 외부 IP가 있는 브라우저 탭을 새로고침합니다. 'Welcome to nginx!' 메시지가 제대로 표시되어야 합니다.

애플리케이션 컨테이너에 유의미한 준비 프로브를 설정하면 포드가 트래픽을 수신할 준비가 된 경우에만 트래픽을 수신하도록 할 수 있습니다. 예를 들어 애플리케이션이 활용하는 캐시가 시작 시 로드되는지 확인하도록 유의미한 준비 프로브를 설정할 수 있습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 준비 프로브 구성

활성 프로브 및 준비 프로브의 동작 모니터링

이제 배포된 포드의 준비 상태가 서비스에서 활성화된 엔드포인트와 어떻게 대응되는지 확인할 수 있습니다. 포드가 준비 프로브 및 활성 프로브 테스트에 실패하면 포드는 '준비되지 않음'으로 표시되고 해당 엔드포인트는 서비스에서 삭제되며, 활성 프로브는 다시 시작 프로세스를 시작하여 실패한 포드를 복구합니다.

다시 시작된 포드는 즉시 '준비됨'으로 표시되지 않으며 준비 테스트가 통과된 후에야 서비스에서 엔드포인트를 해당 풀에 다시 추가할 수 있습니다.

1. 이제 포드의 상태를 다시 확인합니다.

kubectl get pods

이제 개별 포드가 준비됨으로 표시됩니다. 개별 포드 중 하나 이상이 다시 시작되는 시간에 따라 2~3분 가량 소요됩니다. 준비됨으로 표시되는 포드에는 그에 상응하는 서비스와 연결된 엔드포인트가 있습니다.

2. 우선 애플리케이션 연결 가능 여부를 확인하려면 부하 분산기 서비스 세부정보의 외부 IP 주소를 쿼리하고 환경 변수에 이를 저장합니다.

export EXTERNAL_IP=$(kubectl get services readiness-demo-svc -o json | jq -r '.status.loadBalancer.ingress[0].ip')

3. 애플리케이션이 응답하는지 확인합니다.

curl $EXTERNAL_IP

4. 다음 몇 분에 걸쳐 다음 명령어를 약 10초마다 반복하여 배포 상태를 확인하고 부하 분산기에 요청을 보냅니다.

curl $EXTERNAL_IP kubectl get pods

활성 프로브에서 감지된 실패로 인해 개별 컨테이너가 정기적으로 다시 시작되는 경우에도 응답은 실패 또는 시간 초과 없이 계속 이루어집니다. 3개의 컨테이너 모두가 거의 동시에 다시 시작하는 경우 시간 초과가 표시될 수 있지만 그러한 상황은 거의 발생하지 않습니다.

활성 프로브와 준비 프로브의 조합은 실패한 시스템을 안전하게 다시 시작하는 방법을 제공하지만, 서비스는 응답할 수 있는 것으로 표시된 컨테이너로만 트래픽을 전달합니다.

실습 종료하기

실습을 완료하면 실습 종료를 클릭합니다. Google Cloud Skills Boost에서 사용된 리소스를 자동으로 삭제하고 계정을 지웁니다.

실습 경험을 평가할 수 있습니다. 해당하는 별표 수를 선택하고 의견을 입력한 후 제출을 클릭합니다.

별점의 의미는 다음과 같습니다.

• 별표 1개 = 매우 불만족
• 별표 2개 = 불만족
• 별표 3개 = 중간
• 별표 4개 = 만족
• 별표 5개 = 매우 만족

의견을 제공하고 싶지 않다면 대화상자를 닫으면 됩니다.

의견이나 제안 또는 수정할 사항이 있다면 지원 탭을 사용하세요.

Copyright 2020 Google LLC All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.