Consul 데이터플레인
Consul 데이터플레인 (Consul Dataplane)
이 페이지에서는 Envoy 프록시를 관리하는 가벼운 프로세스인 Consul 데이터플레인(dataplane)에 대한 개요를 설명해요. 데이터플레인 덕분에 서비스 디스커버리와 서비스 메시를 위해 클러스터의 모든 노드에 클라이언트 에이전트를 실행할 필요가 없어져요.
출처: 문서
본문
이 주제는 Envoy 프록시를 관리하기 위한 가벼운 프로세스인 Consul 데이터플레인에 대한 개요를 제공해요. Consul 데이터플레인은 서비스 디스커버리와 서비스 메시를 위해 클러스터의 모든 노드에서 클라이언트 에이전트를 실행할 필요를 없애요. 대신 Consul은 더 낮은 지연 시간을 제공하고 추가 런타임을 지원하며 클라우드 인프라 제공자와 통합되는 사이드카 프록시를 배포해요.
지원 환경 (Supported environments)
- 데이터플레인은 Consul 서버 v1.14.0 이상에 연결할 수 있어요.
- Kubernetes의 데이터플레인은 Consul K8s v1.0.0 이상이 필요해요.
- AWS ECS(Elastic Container Services)의 데이터플레인은 Consul ECS v0.7.0 이상이 필요해요.
Consul 데이터플레인이란? (What is Consul dataplane?)
가상 머신이나 베어메탈 환경에 배포할 때 Consul 컨트롤 플레인은 서버 에이전트(server agents) 와 클라이언트 에이전트(client agents) 를 필요로 해요. 서버 에이전트는 서비스 카탈로그와 서비스 메시(보안과 일관성 포함)를 유지하고, 클라이언트 에이전트는 서비스 인스턴스, 그 사이드카 프록시, 그리고 서버 사이의 통신을 관리해요. 이 모델은 가상 머신이나 베어메탈 서버에 배포된 애플리케이션에 최적이지만, Kubernetes나 ECS 같은 오케스트레이터는 일반적으로 클라이언트 에이전트가 제공하는 헬스 체크와 서비스 위치 확인 기능을 지원하는 네이티브 구성 요소를 갖고 있어요.
Consul 데이터플레인은 Envoy 프록시를 관리하고 다른 기능의 책임은 오케스트레이터에게 맡겨요. 그 결과 모든 노드에서 클라이언트 에이전트를 실행할 필요가 사라져요. 또한 서비스 인스턴스를 재시작한 후 서비스를 로컬 클라이언트 에이전트에 다시 등록할 필요도 없어지는데, 이는 컨테이너 오케스트레이션 배포에서 클라이언트 에이전트가 영구 데이터 저장소에 접근하지 못하는 문제가 더 이상 발생하지 않기 때문이에요.
Consul 서버는 8300 포트에서 Raft 알고리즘을 사용해 합의(consensus)를 구성해요.
자세한 내용은 consensus를 참고해요.
성능에 미치는 영향 (Impact on performance)
Consul 데이터플레인은 노드 레벨의 클라이언트 에이전트를 대체하고 각 서비스 인스턴스에 붙는 사이드카로 동작해요. 데이터플레인은 Consul 서버와 Envoy 프록시 사이의 통신을 처리하며 클라이언트 에이전트보다 더 적은 리소스를 사용해요. Consul 서버는 Envoy 프록시를 위한 xDS 리소스를 생성하기 위해 추가 리소스를 소비해야 해요.
그 결과 소규모 배포에서는 전반적으로 더 적은 리소스가 필요해요. 특히 대규모 배포나 높은 수준의 변동(churn)이 예상되는 배포에서는 네트워크 성능에 미치는 다음 영향을 고려해야 해요:
- 5000개의 프록시와 2초마다 변동하는 서비스 상태를 사용한 내부 테스트에서 추가 CPU 사용률은 컨트롤 플레인에서 10% 미만으로 유지되었어요.
- 더 많은 서비스를 배포할수록 데이터플레인의 리소스 사용량은 선형적으로 증가해요.
- 과도한 구성 변경이 서버에 큰 부하를 만들지 않도록 Envoy 재구성은 속도가 제한(rate limited)돼요.
- 개별 서버에 큰 부하가 생기는 것을 피하기 위해 프록시 구성은 사전에 로드 밸런싱돼요.
- 오케스트레이터의 활성(liveness) 및 준비(readiness) 프로브 빈도에 따라 Consul 컨트롤 플레인이 장애를 인지하는 속도가 결정돼요. 다만 Envoy 프록시는 엔드포인트 장애를 수동으로 감지하고 트래픽을 정상 인스턴스로 보낼 수 있는 능력이 있으므로 서비스 메시 애플리케이션에는 영향이 없어요.
이점 (Benefits)
네트워킹 요구 사항 감소 (Fewer networking requirements): 클라이언트 에이전트가 없으면 Consul은 가십(gossip) 통신을 위해 여러 프로토콜에 걸친 양방향 네트워크 연결이 필요하지 않아요. 대신 Consul 서버로의 단일 gRPC 연결 하나만 필요하므로 운영자의 요구 사항이 크게 단순해져요.
간단한 설정 (Simplified set up): 가십에 참여할 클라이언트 에이전트가 없으므로 초기 부트스트래핑 과정에서 가십 암호화 키를 생성해 에이전트에 배포할 필요가 없어요. 추적, 배포, 교체할 토큰도 더 적어져 에이전트 통신 보안도 더 간단해져요.
추가 환경 및 런타임 지원 (Additional environment and runtime support): v1.0(Consul v1.14) 이전 버전의 Kubernetes용 Consul은 클라이언트 에이전트에 hostPorts와 DaemonSets를 사용해야 했기 때문에 이런 기능을 지원하지 않는 환경에서는 배포가 제한되었어요. Kubernetes용 Consul 1.0(Consul 1.14)부터는 hostPorts가 더 이상 필요하지 않으며 Consul은 이제 AWS Fargate와 GKE Autopilot을 지원해요.
더 쉬운 업그레이드 (Easier upgrades): Consul 데이터플레인을 사용하면 Consul을 새 버전으로 업데이트할 때 더 이상 클라이언트 에이전트를 업그레이드할 필요가 없어요. 또한 Consul 데이터플레인은 Consul 서버 버전 간 호환성이 더 좋아서 Consul 서버 업그레이드 과정도 더 쉬워져요.
시작하기 (Get started)
Consul 데이터플레인을 시작하려면 다음 참고 자료를 사용해요:
- 데이터플레인 설치 방법은 Kubernetes에 Consul 데이터플레인 배포를 참고해요.
consul-dataplane명령과 시작에 필요한 플래그를 포함한 사용 예시는consul-dataplaneCLI 참조를 참고해요.- Helm 차트 정보는 Helm 차트 참조를 참고해요.
- Envoy, Consul, Consul 데이터플레인 버전 호환성은 Envoy 호환성 매트릭스를 참고해요.
- Consul on ECS 워크로드는 AWS Elastic Container Service(ECS)의 Consul 개요를 참고해요.
기능 지원 (Feature support)
Kubernetes의 Consul 데이터플레인은 다음 기능을 지원해요:
- WAN 페더레이션, 클러스터 피어링, 관리 파티션을 포함한 단일 및 멀티 클러스터 설치가 지원돼요.
- 인그레스(ingress), 터미네이팅(terminating), 메시 게이트웨이가 지원돼요.
- AWS Fargate와 GKE Autopilot에서 Consul 서비스 메시 실행이 지원돼요.
- xDS 로드 밸런싱이 지원돼요.
- Kubernetes에서 실행되는 서버와 Kubernetes 외부의 서버 모두 지원돼요.
- Consul API 게이트웨이
ECS의 Consul 데이터플레인은 다음 기능을 지원해요:
- WAN 페더레이션, 클러스터 피어링, 관리 파티션을 포함한 단일 및 멀티 클러스터 설치
- 메시 게이트웨이
- AWS Fargate와 EC2에서 Consul 서비스 메시 실행
- xDS 로드 밸런싱 지원
- 자체 관리형 엔터프라이즈 서버
기술적 제약 및 한계 (Technical constraints and limitations)
- Consul 데이터플레인은 Windows에서 지원되지 않아요.
- Consul 데이터플레인은
NET_BIND_SERVICE권한(capability)이 필요해요. 자세한 내용은 Kubernetes 문서의 컨테이너에 capability 설정을 참고해요. - ACL이 활성화되면 데이터플레인은 기본 권한에 서비스 토큰과
builtin/service정책을 사용해요.