Kubernetes의 상태 관리 이해
일반적으로 애플리케이션에 대해 이야기할 때 애플리케이션 상태에 대해 자주 들을 수 있습니다. 이 단원에서는 처리할 애플리케이션을 더 잘 준비할 수 있도록 상태 정의와 다양한 유형의 상태를 검토합니다.
주
애플리케이션의 상태는 애플리케이션이 실행되는 시간까지 메모리 내에 저장되는 모든 것입니다. 상태는 다양한 항목을 포함할 수 있지만, 주로 사용자 데이터에 집중합니다.
애플리케이션 상태의 예를 들기 위해 음악 플레이어를 열고 있다고 가정해 보세요. 이 애플리케이션은 상태를 포함하며 사용자가 누구인지, 사용자가 무엇을 듣는지, 어떤 음악을 다운로드했는지 알고 있습니다. 이 모든 정보는 애플리케이션 상태의 일부입니다.
메모리 내 상태는 애플리케이션이 다른 위치에서 찾을 필요가 없는 정보입니다. 디스크 상태는 애플리케이션에 없는 정보를 포함하므로 다른 데이터 원본에서 검색해야 합니다.
상태 유형
애플리케이션 상태에는 두 가지 유형이 있습니다. 첫 번째 형식은 일시적 상태가 아니며 애플리케이션을 닫자마자 사라집니다.
컨테이너에는 임시 상태가 있습니다. 컨테이너가 삭제되면 해당 데이터에 저장된 모든 데이터가 즉시 손실됩니다. 일부 애플리케이션은 다른 소스에서 상태를 다시 생성할 수 있으므로 로컬로 상태를 저장할 필요가 없기 때문에 이 상태만으로 작업할 수 있습니다. 이런 애플리케이션을 ‘stateless 애플리케이션’이라고 합니다.
임시 상태가 아닌 모든 다시 기본 상태를 영구 상태라고합니다. 영구 상태는 컨테이너의 수명 주기 후에도 계속 존재합니다. 우리가 사용하는 대부분의 컨테이너 기술에는 상태가 존재하는 디스크 내 위치인 볼륨의 개념이 있습니다. 컨테이너를 제거한 다음 다시 설정하더라도 상태는 안전한 위치에 저장된 상태로 유지되며 다시 사용할 수 있습니다.
외부 상태를 검색하는 애플리케이션을 ‘stateful 애플리케이션’이라고 합니다.
상태 및 Kubernetes
Kubernetes는 상태 비스테이션 및 상태 저장 애플리케이션을 모두 처리할 수 있습니다. 상태 비저장 앱은 애플리케이션 자체에만 초점을 맞출 수 있고 상태가 아니므로 더 쉽습니다(존재하지 않기 때문).
대부분의 상태 비저장 애플리케이션의 경우 Pod를 사용한 간단한 배포 워크로드는 완전히 작동하는 시스템을 보유하고 클러스터를 최대한 활용하는 데 충분합니다.
상태 저장 애플리케이션을 처리하는 것은 그 반대입니다. 이러한 경우 애플리케이션 및 해당 상태, 상태가 저장되는 위치 및 상태를 안전하고 안정적으로 저장할 수 있는 방법을 고려해야 합니다.
이러한 이유로 Kubernetes에는 PV(PersistentVolumes) 및 PVC(PersistentVolumeClaims)의 개념도 있습니다.
팁
이 모듈에서는 스토리지 개념에 대해 자세히 설명하지 않지만 요약에서 Azure Kubernetes Service 리소스를 참조하여 자세히 알아볼 수 있습니다.
PersistentVolumes는 Pod의 컨테이너에서 상태를 저장하기 위해 노드에 할당된 디스크입니다. Kubernetes는 배포된 앱에 가장 적합하기 때문에 생성된 모든 볼륨은 ‘사용 가능한 볼륨’ 풀에 있습니다. 그런 다음 컨테이너는 해당 공간을 스스로 주장합니다. PersistentVolumeClaims를 사용하여 PersistentVolume을 Pod와 바인딩하고 해당 공간을 사용하여 필요한 데이터를 저장할 수 있습니다.
모든 데이터베이스 공급자는 상태 저장 애플리케이션입니다. 클러스터에 데이터베이스 공급자를 배포하는 경우 데이터베이스 데이터를 안전한 위치에 저장하고 컨테이너가 삭제된 경우에도 공급자가 해당 데이터를 검색할 수 있도록 PV 및 PVC가 필요합니다.
상태 처리의 모범 사례
대부분의 애플리케이션에 상태가 표시됩니다. 그러나 모범 사례는 상태를 전혀 처리하지 않는 것입니다.
고가용성과 뛰어난 스케일링 성능을 갖추도록 만드는 것을 목표로 효율적인 애플리케이션을 설계합니다. 상태는 반대 방향입니다. 스토리지 공급자가 제공하는 옵션과 배포 및 사용의 용이성에도 불구하고 상태는 쉽게 확장되지 않습니다. 가용성이 높지도 않습니다.
고가용성 상태
가용성을 높이려면 애플리케이션이 항상 온라인 상태여야 합니다. 영역 및 지역 복제를 통해 수행됩니다. Kubernetes는 대부분의 워크로드에서 영역을 인식합니다. 즉, 서로 다른 영역에 배포된 여러 애플리케이션 인스턴스를 사용할 수 있습니다. 그러나 디스크는 영역을 인식하지 않습니다.
Kubernetes에 새 PersistentVolume 개체를 배포하면 노드의 디스크에 바인딩됩니다. 또한 해당 디스크는 특정 지역의 특정 영역에 바인딩됩니다. PV에서 영역 또는 지역 복제본(replica) 사용은 복잡하며 데이터를 동기화하려면 복제본(replica)기본 테넌트가 많이 필요합니다.
스케일링 성능이 높은 상태
확장성이 뛰어나려면 애플리케이션이 연결된 사용자 수와 함께 처리량을 늘려야 합니다. 이 경우 외부 상태는 기본적으로 디스크이고 디스크에는 제한된 입출력 비율이 있으므로 상태 관리가 복잡해집니다. 처리량 관리는 이 문제를 해결하는 데 도움이 됩니다.
데이터베이스 솔루션은 전체 데이터베이스를 ReplicaSets여러 인스턴스로 복제본(replica) 아이디어를 내놓았습니다. 복제본(replica)이면 디스크 수와 상태의 I/O가 증가합니다.
모든 데이터베이스 변경 시에는 모든 디스크가 동일한 데이터를 포함하도록 상태를 동기화해야 합니다. 이 동기화도 복잡합니다.
상태 외부화
Azure에는 고가용성 및 확장성 있는 Azure Cosmos DB와 같은 PaaS(Platform as a Service) 솔루션이 있으며 대부분의 상태 관리 문제를 해결할 수 있습니다.
외부에 상태를 저장하고 유지 관리에 대한 필요성을 제거하면 애플리케이션에 집중하고 인프라의 데이터 무결성을 처리하는 오버헤드를 줄일 수 있습니다.