Kubernetes 모범 사례, 제 2판

16장. 상태 및 상태 저장 애플리케이션 관리

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

컨테이너 오케스트레이션 초기에 대상 워크로드는 일반적으로 필요할 때 외부 시스템을 사용해 상태를 저장하는 상태 비저장 애플리케이션이었습니다. 컨테이너는 매우 일시적이기 때문에 상태를 일관되게 유지하는 데 필요한 백업 스토리지의 오케스트레이션은 기껏해야 어렵다고 생각했습니다. 시간이 지나면서 상태를 유지하는 컨테이너 기반 워크로드의 필요성이 현실화되었고, 일부의 경우 이러한 필요성이 더 높은 성능을 제공할 수도 있습니다. 더 많은 조직이 컴퓨팅 성능을 위해 Cloud를 찾고 Kubernetes가 애플리케이션을 위한 사실상의 컨테이너 런타임이 되면서, "데이터 중력"이라고도 불리는 데이터의 양과 데이터에 대한 고성능 액세스를 방해하는 요인이 되었습니다. Kubernetes는 수많은 반복을 통해 적응했습니다. 이제는 파드에 스토리지 볼륨을 마운트할 수 있을 뿐만 아니라 이러한 볼륨을 Kubernetes에서 직접 관리할 수 있게 되었습니다. 이는 스토리지가 필요한 워크로드와 스토리지의 오케스트레이션에서 중요한 구성 요소였습니다.

컨테이너에 외부 볼륨을 마운트하는 기능으로 충분했다면, Kubernetes에서 대규모로 실행되는 스테이트풀 애플리케이션의 더 많은 예가 존재할 것입니다. 실제로 볼륨 마운팅은 스테이트풀 애플리케이션의 큰 계획에서 가장 쉬운 구성 요소입니다. 노드 장애 후에도 상태를 유지해야 하는 대부분의 애플리케이션은 관계형 데이터베이스 시스템, 분산 키/값 저장소, 복잡한 문서 관리 시스템과 같은 복잡한 데이터 상태 엔진입니다. 이러한 종류의 애플리케이션은 클러스터된 애플리케이션의 구성원이 서로 통신하는 방식, 구성원이 식별되는 방식, 구성원이 시스템에 나타나거나 사라지는 순서 간에 더 많은 조정이 필요합니다.

이 장에서는 파일을 네트워크 공유에 저장하는 것과 같은 간단한 패턴부터 몽고DB, MySQL 또는 Kafka와 같은 복잡한 데이터 관리 시스템에 이르기까지 상태 관리를 위한 모범 사례에 중점을 둔다. 오퍼레이터라는 복잡한 시스템을 위한 새로운 패턴에 대한 작은 섹션이 있는데, 이 패턴은 Kubernetes 기본 요소뿐만 아니라 비즈니스 또는 애플리케이션 로직을 사용자 정의 컨트롤러로 추가할 수 있어 복잡한 데이터 관리 시스템을 더 쉽게 운영할 수 있게 해줍니다.

볼륨 및 볼륨 마운트

상태를 유지하는 방법이 필요한 모든 워크로드가 복잡한 데이터베이스나 처리량이 많은 데이터 큐 서비스일 필요는 없습니다. 컨테이너화된 워크로드로 이동되는 애플리케이션은 종종 특정 디렉터리가 존재하고 해당 디렉터리에 관련 정보를 읽고 쓸 수 있기를 기대합니다. 파드의 컨테이너가 읽을 수 있는 볼륨에 데이터를 주입하는 기능은 4장에서 다루지만, 컨피그맵이나 시크릿에서 마운트된 데이터는 일반적으로 읽기 전용이며, 이 섹션에서는 컨테이너에 쓰기 가능하고 컨테이너 장애 또는 더 ...