Kubernetes에서의 Consul 아키텍처
Kubernetes에서의 Consul 아키텍처
이 문서에서는 Consul을 Kubernetes에 배포할 때의 아키텍처, 구성 요소, 그리고 관련 리소스에 대해 설명해 드려요. Consul은 Kubernetes에서도 다른 플랫폼과 동일한 아키텍처 설계를 사용하지만, Kubernetes는 Consul 클러스터를 운영하기 더 쉽게 만들어 주는 몇 가지 추가 이점을 제공합니다. Consul 아키텍처에 대한 더 일반적인 정보는 Consul 컨트롤 플레인 아키텍처 문서를 참고하세요.
데이터센터 설계에 대한 지침은 Consul과 Kubernetes 참조 아키텍처를, 프로덕션 환경을 위한 단계별 배포 지침은 Consul과 Kubernetes 배포 가이드를 참고해 주세요.
출처: 문서
본문
Kubernetes에서의 서버 에이전트
서버 에이전트는 StatefulSet으로 배포되며 서버 상태를 저장하기 위해 영구 볼륨 클레임(Persistent Volume Claim)을 사용해요. 이 상태 덕분에 노드 ID가 유지되어 서버가 새 IP 주소로 재스케줄링되어도 문제가 발생하지 않습니다.
서버 에이전트에는 Kubernetes 안티-어피니티(anti-affinity) 규칙이 구성되어 서로 다른 노드에 배치돼요. 또한 리더(leader)가 선출된 경우에만 파드가 준비 상태로 표시되도록 readiness 프로브도 구성됩니다.
각 Consul 서버마다 Kubernetes Service가 등록되며, Kubernetes는 Consul 서버 파드와 통신하는 데 필요한 포트를 노출해 줘요. 서버들은 Kubernetes 클러스터에 대한 다른 접근 없이도 이 Service의 DNS 주소를 사용하여 Consul 클러스터에 조인합니다. 추가 Consul 서버는 Kubernetes Service가 게시하는 non-ready 엔드포인트를 활용하여 부트스트랩이나 업그레이드 중에 Service를 통해 조인할 수도 있어요.
PodDisruptionBudget이 구성되어 자발적인 운영 이벤트 중에도 Consul 서버 클러스터가 쿼럼(quorum)을 유지하도록 해요. 최대 사용 불가(unavailable) 수는 (n/2)-1이며, 여기서 n은 서버 에이전트의 수입니다.
참고: Kubernetes와 Helm은 StatefulSet이 삭제될 때 Persistent Volume이나 Persistent Volume Claim을 삭제하지 않아요. 서버를 제거할 때는 이 작업을 수동으로 수행해야 합니다.
Kubernetes에서의 Consul 데이터플레인
기본적으로 Kubernetes의 Consul은 클라이언트 에이전트 없이 사이드카를 주입하는 대체 서비스 메시 구성을 사용해요. Consul 데이터플레인은 Envoy 프록시를 관리하고, 나머지 기능은 오케스트레이터가 담당하므로 모든 노드에서 클라이언트 에이전트를 실행할 필요가 없어집니다.
자세한 내용은 Consul 데이터플레인을 사용한 단순화된 서비스 메시 문서를 참고하세요.
Consul 데이터플레인은 Consul v1.14 이상 버전에서 Kubernetes의 기본 프록시 관리자예요. Consul v1.13 이하를 사용 중이라면, 구체적인 업그레이드 지침은 Consul Dataplane으로 업그레이드 문서를 참고해 주세요.