이 튜토리얼 모음은 Google Kubernetes Engine(GKE)에서 실행되는 최신 애플리케이션 환경을 배포, 실행, 관리하려는 IT 관리자와 운영자를 대상으로 합니다. 이 튜토리얼 모음을 진행하면서 Cymbal Bank 샘플 마이크로서비스 애플리케이션을 사용하여 모니터링과 알림을 구성하고 워크로드를 확장하며 장애를 시뮬레이션하는 방법을 알아봅니다.
개요 및 목표
애플리케이션이 중단 및 장애를 허용할 수 있어야 합니다. 이 기능을 사용하면 문제가 발생하더라도 사용자가 애플리케이션에 계속 액세스할 수 있습니다. Cymbal Bank 샘플 애플리케이션은 문제 해결 및 수정 없이도 장애를 처리하고 계속 실행할 수 있도록 설계되었습니다. 이러한 복원력을 제공하기 위해 GKE 리전 클러스터는 컴퓨팅 노드를 영역 간에 분산하고 Kubernetes 컨트롤러는 클러스터 내의 서비스 문제에 자동으로 응답합니다.
이 튜토리얼에서는 Google Cloud에서 장애를 시뮬레이션하는 방법과 GKE 클러스터의 애플리케이션 서비스가 응답하는 방식을 알아봅니다. 다음 태스크를 완료하는 방법을 알아봅니다.
- 노드 및 서비스 배포를 검토합니다.
- 노드 또는 영역 장애를 시뮬레이션합니다.
- 서비스가 나머지 노드에서 계속 실행되는지 확인합니다.
비용
이 튜토리얼 시리즈에서 GKE를 사용 설정하고 Cymbal Bank 샘플 애플리케이션을 배포하면 GKE를 중지하거나 프로젝트를 삭제할 때까지 가격 책정 페이지에 나열된 대로 Google Cloud에서 GKE 요금이 클러스터별로 청구됩니다.
Compute Engine VM과 같이 Cymbal Bank 샘플 애플리케이션을 실행하는 동안 발생하는 기타 Google Cloud 비용도 사용자가 부담합니다.
시작하기 전에
장애를 시뮬레이션하는 방법을 알아보려면 첫 번째 튜토리얼을 완료하여 Autopilot을 사용하는 GKE 클러스터를 만들고 Cymbal Bank 샘플 마이크로서비스 기반 애플리케이션을 배포해야 합니다.
확장 가능한 앱에 대한 이 튜토리얼 모음을 순서대로 완료하는 것이 좋습니다. 튜토리얼 모음을 진행하면서 새로운 기술을 배우고 추가적인 Google Cloud 제품 및 서비스를 사용하게 됩니다.
노드 및 서비스 배포 검토
Google Cloud에서 리전은 리소스를 호스팅할 수 있는 특정 지리적 위치입니다. 리전은 3개 이상의 영역을 포함합니다. 예를 들어 us-central1 리전은 us-central1-a, us-central1-b, us-central1-c와 같이 여러 영역이 있는 미국 중서부 지역의 리전을 나타냅니다. 영역에서 같은 리전의 다른 영역으로 지연 시간이 짧은 고대역폭 네트워크로 연결합니다.
고가용성을 제공하는 내결함성 애플리케이션을 배포하기 위해 Google은 다중 영역 및 다중 리전에 애플리케이션을 배포할 것을 권장합니다. 이렇게 하면 영역이나 리전을 포함하는 경우에도 예기치 않은 구성 요소 장애를 방지하는 데 도움이 됩니다.
첫 번째 튜토리얼에서 GKE 클러스터를 만들 때 몇 가지 기본 구성 값이 사용되었습니다. 기본적으로 Autopilot을 사용하는 GKE 클러스터는 지정된 리전의 영역에 걸쳐 있는 노드를 만들고 실행합니다. 이 접근 방식에서는 Cymbal Bank 샘플 애플리케이션이 여러 영역에 이미 배포되어 있으므로 예상치 못한 장애로부터 보호하는 데 도움이 됩니다.
GKE 클러스터에서 노드 배포를 확인합니다.
kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'결과는 노드가 리전의 3개 영역 모두에 분산되었음을 보여주는 다음 예시 출력과 비슷합니다.
NAME ZONE INT_IP scalable-apps-pool-2-node5 us-central1-c 10.148.0.6 scalable-apps-pool-2-node6 us-central1-c 10.148.0.7 scalable-apps-pool-2-node2 us-central1-a 10.148.0.8 scalable-apps-pool-2-node1 us-central1-a 10.148.0.9 scalable-apps-pool-2-node3 us-central1-b 10.148.0.5 scalable-apps-pool-2-node4 us-central1-b 10.148.0.4GKE 클러스터 노드에서 Cymbal Bank 샘플 애플리케이션 서비스의 배포를 확인합니다.
kubectl get pods -o wide다음 출력 예시는 서비스가 클러스터의 노드 간에 분산되는 것을 보여줍니다. 이전 단계에서 노드 배포 방법을 확인하기 위해 이 출력은 서비스가 리전의 영역 간에 실행되는 것을 보여줍니다.
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 6m30s 10.28.1.5 scalable-apps-pool-2-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 6m30s 10.28.5.6 scalable-apps-pool-2-node1 contacts-7ddc76d94-qv4x5 1/1 Running 0 6m29s 10.28.4.6 scalable-apps-pool-2-node2 frontend-747b84bff4-xvjxq 1/1 Running 0 6m29s 10.28.3.6 scalable-apps-pool-2-node6 ledger-db-0 1/1 Running 0 6m29s 10.28.5.7 scalable-apps-pool-2-node1 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 6m29s 10.28.1.6 scalable-apps-pool-2-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 6m29s 10.28.4.7 scalable-apps-pool-2-node2 transactionhistory-5dd7c7fd77-cmc2w 1/1 Running 0 6m29s 10.28.3.7 scalable-apps-pool-2-node6 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 6m28s 10.28.5.8 scalable-apps-pool-2-node1
중단 시뮬레이션
Google은 전력, 냉각, 네트워킹과 같은 물리적 인프라 장애로 인한 연관성 장애의 위험을 최소화하도록 영역을 설계합니다. 하지만 예기치 않은 문제가 발생할 수 있습니다. 노드나 영역을 사용할 수 없게 되면 다른 노드 또는 같은 리전의 영역에서 서비스가 계속 실행되기를 원할 것입니다.
Kubernetes 컨트롤러는 클러스터의 노드, 서비스, 배포 상태를 모니터링합니다. 예기치 않은 중단이 발생하면 컨트롤러가 영향을 받는 리소스를 다시 시작하고 트래픽이 작업 노드로 라우팅됩니다.
이 튜토리얼의 서비스 중단을 시뮬레이션하려면 영역 중 하나에서 노드를 차단하고 드레이닝합니다. 이 접근 방식은 노드가 실패하거나 전체 영역에 문제가 있을 때 발생하는 결과를 시뮬레이션합니다. Kubernetes 컨트롤러에서는 일부 서비스를 더 이상 사용할 수 없으며 다른 영역의 노드에서 다시 시작해야 함을 인식해야 합니다.
영역 중 하나에서 노드를 차단하고 드레이닝합니다. 다음 예시에서는
us-central1-a의 2개 노드를 타겟팅합니다.kubectl drain scalable-apps-pool-2-node1 \ --delete-emptydir-data --ignore-daemonsets kubectl drain scalable-apps-pool-2-node2 \ --delete-emptydir-data --ignore-daemonsets이 명령어는 포드가 더 이상 이러한 노드에서 실행될 수 없도록 노드를 예약할 수 없는 것으로 표시합니다. Kubernetes는 작동 영역의 다른 노드로 포드를 다시 예약합니다.
시뮬레이션된 오류 응답 확인
이 시리즈의 이전 튜토리얼에서는 일부 서비스를 모니터링하고 문제가 있을 경우 알림을 생성하도록 GKE 클러스터에 대해 관리형 Prometheus 인스턴스를 구성하는 방법을 배웠습니다. 서비스 중단을 시뮬레이션한 영역의 노드에서 포드가 실행 중인 경우 Prometheus에서 생성된 알림에서 Slack 알림 메시지를 받게 됩니다. 이 동작은 배포 상태를 모니터링하고, 문제가 있으면 알림을 보내고, 부하 변경 또는 오류에 맞게 자동으로 조정할 수 있는 최신 애플리케이션 환경을 빌드하는 방법을 보여줍니다.
GKE 클러스터는 시뮬레이션된 서비스 중단에 자동으로 응답합니다. 영향을 받는 노드의 모든 서비스가 나머지 노드에서 다시 시작됩니다.
GKE 클러스터에서 노드 배포를 다시 확인합니다.
kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'결과는 노드가 이제 리전의 두 영역에만 분산되어 있음을 보여주는 다음 예시 출력과 비슷합니다.
NAME ZONE INT_IP scalable-apps-pool-2-node5 us-central1-c 10.148.0.6 scalable-apps-pool-2-node6 us-central1-c 10.148.0.7 scalable-apps-pool-2-node3 us-central1-b 10.148.0.5 scalable-apps-pool-2-node4 us-central1-b 10.148.0.4Kubernetes 컨트롤러는 2개의 노드를 더 이상 사용할 수 없음을 인식하고 사용 가능한 노드 간에 서비스를 다시 배포합니다. 모든 서비스는 계속 실행됩니다.
GKE 클러스터 노드에서 Cymbal Bank 샘플 애플리케이션 서비스의 배포를 확인합니다.
kubectl get pods -o wide다음 출력 예시는 서비스가 클러스터의 나머지 노드에 분산됨을 보여줍니다. 이전 단계에서 노드 분산 방법을 확인하기 위한 이 출력은 서비스가 이제 리전의 두 영역에서만 실행됨을 보여줍니다.
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 28m 10.28.1.5 scalable-apps-pool-2-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 9m21s 10.28.5.6 scalable-apps-pool-2-node5 contacts-7ddc76d94-qv4x5 1/1 Running 0 9m20s 10.28.4.6 scalable-apps-pool-2-node4 frontend-747b84bff4-xvjxq 1/1 Running 0 28m 10.28.3.6 scalable-apps-pool-2-node6 ledger-db-0 1/1 Running 0 9m24s 10.28.5.7 scalable-apps-pool-2-node3 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 28m 10.28.1.6 scalable-apps-pool-2-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 9m21s 10.28.4.7 scalable-apps-pool-2-node5 transactionhistory-5dd7c7fd77-cmc2w 1/1 Running 0 28m 10.28.3.7 scalable-apps-pool-2-node6 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 9m20s 10.28.5.8 scalable-apps-pool-2-node1서비스의
AGE를 확인합니다. 이전 예시 출력에서 일부 서비스는 Cymbal Bank 샘플 애플리케이션의 다른 서비스보다 기간이 짧습니다. 이 새로운 서비스는 이전에 장애를 시뮬레이션한 노드 중 하나에서 실행되었습니다. Kubernetes 컨트롤러가 사용 가능한 노드에서 이러한 서비스를 다시 시작했습니다.
실제 시나리오에서는 문제를 해결하거나 기본 유지보수 문제가 해결될 때까지 기다립니다. 알림을 기반으로 Slack 메시지를 보내도록 Prometheus를 구성한 경우 이러한 알림이 전달되는 것을 볼 수 있습니다. 또한 필요에 따라 이전 튜토리얼의 단계를 반복하여 리소스를 확장함으로써 해당 리전에서 두 개의 영역만 사용할 수 있을 때 증가된 부하에 GKE 클러스터가 어떻게 반응하는지 확인할 수도 있습니다. 클러스터는 사용 가능한 나머지 두 영역으로 확장되어야 합니다.
삭제
이 튜토리얼에서 사용한 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 만든 프로젝트를 삭제하세요.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
다음 단계
이 튜토리얼 모음에서 배운 것과 비슷한 자체 GKE 클러스터 환경을 만들기 전에 몇 가지 프로덕션 고려사항을 검토하세요.