Kubernetes 모범 사례, 제 2판

12장. 여러 클러스터 관리

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

이 장에서는 여러 Kubernetes 클러스터를 관리하기 위한 모범 사례에 대해 설명합니다. 멀티클러스터 관리와 페더레이션의 차이점, 멀티클러스터 관리 도구, 멀티클러스터 관리를 위한 운영 패턴에 대해 자세히 살펴봅니다.

왜 여러 개의 Kubernetes 클러스터가 필요한지 궁금할 수 있습니다. 많은 워크로드를 단일 클러스터로 통합하기 위해 Kubernetes가 구축된 것이 맞죠? 맞습니다. 하지만 여러 지역에 걸친 워크로드, 폭발 반경에 대한 우려, 규정 준수, 특수 워크로드 등 여러 클러스터가 필요할 수 있는 시나리오가 있습니다.

이러한 시나리오에 대해 논의하고 Kubernetes에서 여러 클러스터를 관리하기 위한 도구와 기법을 살펴봅니다.

왜 다중 클러스터인가?

Kubernetes를 도입하는 경우, 둘 이상의 클러스터가 있을 수 있으며, 스테이징, 사용자 승인 테스트(UAT) 또는 개발에서 프로덕션을 분리하기 위해 둘 이상의 클러스터로 시작할 수도 있습니다. Kubernetes는 클러스터를 더 작은 논리적 구조로 분할하는 논리적 방법인 네임스페이스를 통해 몇 가지 멀티테넌시 기능을 제공합니다. 네임스페이스를 사용하면 역할 기반 액세스 제어(RBAC), 쿼터, 파드 보안 정책 및 네트워크 정책을 정의하여 워크로드를 분리할 수 있습니다. 이것은 여러 팀과 프로젝트를 분리하는 좋은 방법이지만, 멀티클러스터 아키텍처를 구축해야 하는 다른 우려 사항도 있습니다. 멀티클러스터와 단일 클러스터 아키텍처를 사용할지 결정할 때 고려해야 할 우려 사항:

• 폭발 반경

• 규정 준수

• 보안

• 하드 멀티테넌시

• 지역 기반 워크로드

• 특수 워크로드

아키텍처를 고려할 때는 폭발 반경을 가장 먼저 고려해야 합니다. 이는 멀티클러스터 아키텍처를 설계하는 사용자들이 주로 우려하는 부분 중 하나입니다. 마이크로서비스 아키텍처에서는 시스템 손상 범위를 제한하기 위해 회로 차단기, 재시도, 벌크헤드 및 속도 제한을 사용합니다. 인프라 계층에도 동일하게 설계해야 하며, 여러 클러스터를 사용하면 소프트웨어 문제로 인한 연쇄적인 장애의 영향을 방지하는 데 도움이 될 수 있습니다. 예를 들어 500개의 애플리케이션을 지원하는 하나의 클러스터에 플랫폼 문제가 발생하면 500개의 애플리케이션 중 100%가 중단됩니다. 500개의 애플리케이션을 서비스하는 5개의 클러스터에서 플랫폼 계층 문제가 발생한 경우, 애플리케이션의 20%에만 영향을 미칩니다. 단점은 이제 5개의 클러스터를 관리해야 하며, 통합 비율이 단일 클러스터를 사용할 때보다 좋지 않다는 것입니다. Dan Woods는 프로덕션 환경에서 발생한 실제 캐스케이딩 장애에 대한 훌륭한 글을 작성했습니다. 대규모 환경에서 멀티클러스터 아키텍처를 고려해야 하는 이유를 잘 보여주는 좋은 예입니다.

규정 준수는 멀티클러스터 설계의 또 다른 관심 영역으로, PCI(결제 ...