Kubernetes: Up and Running, 제3판

21장. 멀티클러스터 애플리케이션 배포

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

이 책을 20장까지 읽었다면 Kubernetes가 복잡한 주제일 수 있다는 것은 분명하겠지만, 물론 여기까지 읽으셨다면 이전보다 덜 어둡게 느껴지셨기를 바랍니다. 단일 Kubernetes 클러스터에서 애플리케이션을 빌드하고 실행하는 것도 복잡한데, 애플리케이션을 여러 클러스터로 설계하고 배포하는 것이 왜 더 복잡할까요?

현실의 요구 사항으로 인해 대부분의 애플리케이션에서 멀티클러스터 애플리케이션 배포가 현실로 다가오고 있는 것이 사실입니다. 여기에는 여러 가지 이유가 있으며, 애플리케이션이 이러한 요구 사항 중 하나 이상에 해당할 가능성이 높습니다.

첫 번째 요건은 이중화 및 복원력입니다. Cloud든 온프레미스든, 단일 데이터센터는 일반적으로 단일 장애 도메인이 됩니다. 광섬유 케이블을 사용하여 표적 연습을 하는 사냥꾼이든, 얼음 폭풍으로 인한 정전이든, 단순히 소프트웨어 롤아웃이 잘못되었든, 단일 위치에 배포된 모든 애플리케이션은 완전히 실패할 수 있으며 사용자는 아무런 대책 없이 방치될 수 있습니다. 대부분의 경우, 단일 Kubernetes 클러스터는 단일 위치에 연결되어 있으므로 단일 장애 도메인이 됩니다.

경우에 따라, 특히 Cloud 환경에서는 Kubernetes 클러스터가 리전으로 설계되는 경우도 있습니다. 리저널 클러스터는 여러 독립 영역에 걸쳐 있으므로 앞서 설명한 기본 인프라의 문제에 대해 복원력이 있습니다. 그렇다면 이러한 리저널 클러스터가 복원력을 위해 충분하다고 가정하고 싶을 수 있으며, Kubernetes 자체가 단일 장애 지점이 될 수 있다는 사실을 제외하면 그럴 수도 있습니다. 모든 단일 Kubernetes 클러스터는 특정 버전(예: 1.21.3)에 묶여 있으며 클러스터의 업그레이드가 애플리케이션을 중단시킬 가능성이 매우 높습니다. 때때로 Kubernetes는 API를 더 이상 사용하지 않거나 해당 API의 동작을 변경합니다. 이러한 변경은 드물게 발생하며, Kubernetes 커뮤니티는 이러한 변경이 사전에 전달되도록 주의를 기울이고 있습니다. 또한, 많은 테스트에도 불구하고 때때로 버그가 릴리스에 스며들기도 합니다. 하나의 문제가 애플리케이션에 영향을 미칠 가능성은 낮지만, 대부분의 애플리케이션의 수명(수년)을 고려할 때 언젠가는 애플리케이션이 영향을 받을 가능성이 있습니다. 대부분의 애플리케이션에서 이는 허용 가능한 위험은 아닙니다.

복원력 요구 사항 외에도 멀티클러스터 배포의 또 다른 강력한 동인은 일부 비즈니스 또는 애플리케이션의 지역 친화성 요구입니다. 예를 들어, 게임 서버는 네트워크 지연 시간을 줄이고 플레이 환경을 개선하기 위해 플레이어 근처에 있어야 할 필요성이 높습니다. 다른 애플리케이션은 데이터가 특정 지역 내에 위치해야 하는 법적 또는 규제 요구사항의 적용을 받을 수 있습니다. 모든 Kubernetes 클러스터는 ...