Kubernetes: Up and Running, 제3판

16장. 스토리지 솔루션과 Kubernetes 통합하기

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

많은 경우 애플리케이션에서 상태를 분리하고 마이크로서비스를 가능한 한 상태 비저장형으로 구축하면 안정성과 관리성이 극대화되는 시스템을 만들 수 있습니다.

그러나 데이터베이스의 레코드부터 웹 검색 엔진에 결과를 제공하는 인덱스 샤드에 이르기까지 복잡한 거의 모든 시스템에는 시스템 어딘가에 상태가 있습니다. 어느 시점에서는 데이터가 어딘가에 저장되어 있어야 합니다.

이러한 데이터를 컨테이너 및 컨테이너 오케스트레이션 솔루션과 통합하는 것은 분산 시스템을 구축하는 데 있어 가장 복잡한 측면입니다. 이러한 복잡성은 주로 컨테이너화된 아키텍처로의 전환이 분리된 불변의 선언적 애플리케이션 개발로의 전환이라는 사실에서 기인합니다. 이러한 패턴은 상태 비저장 웹 애플리케이션에 적용하기가 비교적 쉽지만, Cassandra나 MongoDB와 같은 "Cloud 네이티브" 스토리지 솔루션조차도 안정적이고 복제된 솔루션을 설정하기 위해 일종의 수동 또는 필수적인 단계를 거쳐야 합니다.

이에 대한 예로, Mongo 데몬을 배포한 다음 Mongo 클러스터에서 리더와 참가자를 식별하는 명령형 명령을 실행하는 MongoDB에서 ReplicaSet을 설정하는 것을 생각해 보세요. 물론 이러한 단계는 스크립트로 작성할 수 있지만, 컨테이너화된 환경에서는 이러한 명령을 배포에 통합하는 방법을 찾기가 어렵습니다. 마찬가지로, 복제된 컨테이너 집합에서 개별 컨테이너에 대해 DNS 확인이 가능한 이름을 얻는 것조차도 어렵습니다.

데이터 중력이 존재한다는 사실 때문에 복잡성이 더 커집니다. 대부분의 컨테이너화된 시스템은 진공 상태에서 구축되는 것이 아니라 일반적으로 가상 머신에 배포된 기존 시스템에서 조정되며, 이러한 시스템에는 가져오거나 마이그레이션해야 하는 데이터가 포함될 가능성이 높습니다.

마지막으로, Cloud로의 진화는 종종 스토리지가 외부화된 클라우드 서비스임을 의미하며, 이러한 맥락에서 스토리지가 실제로 Kubernetes 클러스터 내부에 존재할 수 없다는 것을 의미합니다.

이 장에서는 컨테이너화된 마이크로서비스에 스토리지를 통합하기 위한 다양한 접근 방식을 Kubernetes에서 다룬다. 먼저, 기존 외부 스토리지 솔루션(클라우드 서비스 또는 가상 머신에서 실행되는)을 Kubernetes로 가져오는 방법을 다룬다. 다음으로, 이전에 스토리지 솔루션을 배포했던 가상 머신과 거의 일치하는 환경을 구축할 수 있는 안정적인 싱글톤을 Kubernetes 내에서 실행하는 방법을 살펴봅니다. 마지막으로, 대부분의 사람들이 Kubernetes에서 상태 저장 워크로드에 사용하는 리소스인 스테이트풀셋에 대해 알아봅니다.

외부 서비스 가져오기

대부분의 경우, 네트워크에서 일종의 데이터베이스가 실행 중인 기존 머신이 실행되고 있습니다. 이러한 상황에서는 해당 데이터베이스를 즉시 컨테이너와 Kubernetes로 ...