Kubernetes의 Kafka가 좋은가요?

안녕하세요, 하브르!

한때 우리는 이 주제를 러시아 시장에 처음으로 소개했습니다. 카프카 그리고 계속 따르다 개발을 위해. 특히 Kafka와 Kubernetes. 관찰 가능(그리고 매우 주의깊음) 기사 이 주제는 작년 XNUMX월 Gwen Shapira의 저작으로 Confluent 블로그에 게시되었습니다. 오늘 우리는 요한 가이거(Johann Gyger)가 쓴 XNUMX월의 최신 기사에 여러분의 관심을 끌고 싶습니다. 그는 제목에 물음표가 없지는 않지만 흥미로운 링크와 함께 텍스트를 첨부하여 보다 실질적인 방식으로 주제를 조사했습니다. 가능하다면 “chaos Monkey”의 무료 번역을 용서해주세요!

소개

Kubernetes는 상태 비저장 워크로드를 처리하도록 설계되었습니다. 일반적으로 이러한 워크로드는 마이크로서비스 아키텍처의 형태로 제공되며, 가볍고, 수평적으로 잘 확장되며, 12단계 애플리케이션의 원칙을 따르며, 회로 차단기 및 카오스 몽키와 함께 작동할 수 있습니다.

반면 Kafka는 기본적으로 분산 데이터베이스 역할을 합니다. 따라서 작업할 때 상태를 처리해야 하며 이는 마이크로서비스보다 훨씬 무겁습니다. Kubernetes는 상태 저장 로드를 지원하지만 Kelsey Hightower가 두 개의 트윗에서 지적했듯이 주의해서 처리해야 합니다.

어떤 사람들은 Kubernetes를 상태 저장 워크로드에 추가하면 RDS에 필적하는 완전 관리형 데이터베이스가 된다고 생각합니다. 이것은 잘못된 것입니다. 아마도 충분히 열심히 일하고 추가 구성 요소를 추가하고 SRE 엔지니어 팀을 유치한다면 Kubernetes 위에 RDS를 구축할 수 있을 것입니다.

저는 항상 모든 사람이 Kubernetes에서 상태 저장 워크로드를 실행할 때 극도의 주의를 기울일 것을 권장합니다. "Kubernetes에서 상태 저장 워크로드를 실행할 수 있나요?"라고 묻는 대부분의 사람들은 Kubernetes에 대한 경험이 충분하지 않으며, 그들이 묻는 워크로드에 대한 경험도 부족한 경우가 많습니다.

그렇다면 Kubernetes에서 Kafka를 실행해야 할까요? 반대 질문: Kafka는 Kubernetes 없이 더 잘 작동할까요? 이것이 바로 이 기사에서 Kafka와 Kubernetes가 서로 어떻게 보완하는지, 그리고 둘을 결합할 때 어떤 위험이 발생할 수 있는지 강조하고 싶은 이유입니다.

완료 시간

기본적인 것, 즉 런타임 환경 자체에 대해 이야기해 봅시다.

Процесс

Kafka 브로커는 CPU 친화적입니다. TLS는 약간의 오버헤드를 초래할 수 있습니다. 그러나 Kafka 클라이언트는 암호화를 사용하는 경우 CPU를 더 많이 사용할 수 있지만 이는 브로커에 영향을 미치지 않습니다.

기억

Kafka 브로커는 메모리를 소모합니다. JVM 힙 크기는 일반적으로 4-5GB로 제한되지만 Kafka는 페이지 캐시를 매우 많이 사용하므로 많은 시스템 메모리도 필요합니다. Kubernetes에서는 이에 따라 컨테이너 리소스와 요청 제한을 설정합니다.

데이터 저장소

컨테이너의 데이터 저장은 일시적입니다. 다시 시작하면 데이터가 손실됩니다. Kafka 데이터의 경우 볼륨을 사용할 수 있습니다 emptyDir, 효과는 비슷합니다. 완료 후 브로커 데이터가 손실됩니다. 귀하의 메시지는 여전히 다른 브로커에 복제본으로 저장될 수 있습니다. 따라서 재시작 후 장애가 발생한 브로커는 먼저 모든 데이터를 복제해야 하며 이 과정에는 많은 시간이 소요될 수 있습니다.

이것이 장기 데이터 저장소를 사용해야 하는 이유입니다. XFS 파일 시스템 또는 더 정확하게는 ext4를 사용하는 비로컬 장기 저장소로 두십시오. NFS를 사용하지 마십시오. 나는 당신에게 경고했다. NFS 버전 v3 또는 v4는 작동하지 않습니다. 즉, NFS의 "어리석은 이름 바꾸기" 문제로 인해 데이터 디렉터리를 삭제할 수 없으면 Kafka 브로커가 충돌합니다. 아직 설득하지 못했다면 아주 조심스럽게 이 기사를 읽어보세요. Kubernetes가 다시 시작 또는 재배치 후 새 노드를 보다 유연하게 선택할 수 있도록 데이터 저장소는 로컬이 아니어야 합니다.

네트워크

대부분의 분산 시스템과 마찬가지로 Kafka의 성능은 네트워크 대기 시간을 최소로 유지하고 대역폭을 최대로 유지하는 데 크게 좌우됩니다. 동일한 노드에서 모든 브로커를 호스팅하려고 시도하지 마십시오. 이렇게 하면 가용성이 저하됩니다. Kubernetes 노드가 실패하면 전체 Kafka 클러스터가 실패합니다. 또한 Kafka 클러스터를 전체 데이터 센터에 분산시키지 마십시오. Kubernetes 클러스터도 마찬가지입니다. 이 경우 좋은 절충안은 다른 가용성 영역을 선택하는 것입니다.

구성

정기 선언문

쿠버네티스 웹사이트에는 아주 좋은 가이드 매니페스트를 사용하여 ZooKeeper를 구성하는 방법에 대해 알아보세요. ZooKeeper는 Kafka의 일부이므로 여기에 적용되는 Kubernetes 개념을 익히기에 좋은 곳입니다. 이를 이해하면 Kafka 클러스터에서도 동일한 개념을 사용할 수 있습니다.

• 아래의: 포드는 Kubernetes에서 배포 가능한 가장 작은 단위입니다. 포드에는 워크로드가 포함되어 있으며 포드 자체는 클러스터의 프로세스에 해당합니다. 포드에는 하나 이상의 컨테이너가 포함되어 있습니다. 앙상블의 각 ZooKeeper 서버와 Kafka 클러스터의 각 브로커는 별도의 포드에서 실행됩니다.
• 스테이트풀셋: StatefulSet은 여러 상태 저장 워크로드를 처리하는 Kubernetes 객체이며 이러한 워크로드에는 조정이 필요합니다. StatefulSet은 Pod의 순서와 고유성에 대한 보장을 제공합니다.
• 헤드리스 서비스: 서비스를 사용하면 논리적 이름을 사용하여 클라이언트에서 포드를 분리할 수 있습니다. 이 경우 Kubernetes는 로드 밸런싱을 담당합니다. 그러나 ZooKeeper 및 Kafka와 같은 상태 저장 워크로드를 운영할 때 클라이언트는 특정 인스턴스와 통신해야 합니다. 여기서 헤드리스 서비스가 유용합니다. 이 경우 클라이언트는 여전히 논리적 이름을 가지지만 포드에 직접 연결할 필요는 없습니다.
• 장기 저장량: 이러한 볼륨은 위에서 언급한 비로컬 블록 영구 저장소를 구성하는 데 필요합니다.

에 욜린 Kubernetes에서 Kafka를 시작하는 데 도움이 되는 포괄적인 매니페스트 세트를 제공합니다.

투구 차트

Helm은 yum, apt, Homebrew 또는 Chocolatey와 같은 OS 패키지 관리자와 비교할 수 있는 Kubernetes용 패키지 관리자입니다. Helm 차트에 설명된 사전 정의된 소프트웨어 패키지를 쉽게 설치할 수 있습니다. 잘 선택된 Helm 차트를 사용하면 Kubernetes에서 Kafka를 사용하기 위해 모든 매개변수를 적절하게 구성하는 방법에 대한 어려운 작업을 쉽게 수행할 수 있습니다. 여러 가지 Kafka 다이어그램이 있습니다. 공식 다이어그램은 다음과 같습니다. 인큐베이터 상태에서, 다음 중 하나가 있습니다. 지류, 하나 더 - 에서 Bitnami.

연산자

Helm에는 특정 단점이 있기 때문에 또 다른 도구인 Kubernetes Operator가 상당한 인기를 얻고 있습니다. 운영자는 Kubernetes용 소프트웨어를 패키징할 뿐만 아니라 이러한 소프트웨어를 배포하고 관리할 수도 있습니다.

목록 놀라운 운영자 Kafka의 두 연산자가 언급됩니다. 그들 중 하나 - 스트림지. Strimzi를 사용하면 Kafka 클러스터를 몇 분 만에 쉽게 시작하고 실행할 수 있습니다. 사실상 구성이 필요하지 않으며, 운영자 자체가 클러스터 내 지점 간 TLS 암호화와 같은 몇 가지 유용한 기능을 제공합니다. Confluent도 제공합니다. 자체 운영자.

Производительность

Kafka 인스턴스를 벤치마킹하여 성능을 테스트하는 것이 중요합니다. 이러한 테스트는 문제가 발생하기 전에 잠재적인 병목 현상을 찾는 데 도움이 됩니다. 다행히 Kafka는 이미 두 가지 성능 테스트 도구를 제공합니다. kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. 적극적으로 활용하세요. 참고로 에 설명된 결과를 참고할 수 있습니다. 이 게시물 Jay Kreps 또는 집중 이 리뷰 Stéphane Maarek의 Amazon MSK.

운영

모니터링

시스템의 투명성은 매우 중요합니다. 그렇지 않으면 시스템에서 무슨 일이 일어나고 있는지 이해하지 못할 것입니다. 오늘날 클라우드 네이티브 스타일로 메트릭 기반 모니터링을 제공하는 견고한 툴킷이 있습니다. 이 목적을 위해 널리 사용되는 두 가지 도구는 Prometheus와 Grafana입니다. Prometheus는 JMX 내보내기를 사용하여 가장 간단한 방법으로 모든 Java 프로세스(Kafka, Zookeeper, Kafka Connect)에서 메트릭을 수집할 수 있습니다. cAdvisor 메트릭을 추가하면 Kubernetes에서 리소스가 어떻게 사용되는지 더 완벽하게 이해할 수 있습니다.

Strimzi에는 Kafka용 Grafana 대시보드의 매우 편리한 예가 있습니다. 예를 들어, 복제되지 않은 섹터 또는 오프라인인 섹터에 대한 주요 지표를 시각화합니다. 모든 것이 매우 명확합니다. 이러한 지표는 리소스 활용도, 성능 정보, 안정성 지표로 보완됩니다. 따라서 기본 Kafka 클러스터 모니터링을 무료로 이용할 수 있습니다!

출처 : streamzi.io/docs/master/#kafka_dashboard

클라이언트 모니터링(소비자 및 생산자에 대한 측정항목)과 대기 시간 모니터링(이를 위해 다음이 있습니다)으로 이 모든 것을 보완하는 것이 좋을 것입니다. 굴) 및 엔드투엔드 모니터링 - 이 용도로 사용 카프카 모니터.

벌채 반출

로깅은 또 다른 중요한 작업입니다. Kafka 설치의 모든 컨테이너가 다음에 기록되어 있는지 확인하십시오. stdout и stderr, 또한 Kubernetes 클러스터가 모든 로그를 중앙 로깅 인프라에 집계하는지 확인합니다. 탄성 검색.

기능 점검

Kubernetes는 활성 상태 및 준비 상태 프로브를 사용하여 Pod가 정상적으로 실행되고 있는지 확인합니다. 활성 확인이 실패하면 Kubernetes는 해당 컨테이너를 중지한 다음 그에 따라 다시 시작 정책이 설정된 경우 자동으로 다시 시작합니다. 준비 확인이 실패하면 Kubernetes는 요청 서비스에서 포드를 격리합니다. 따라서 이러한 경우 수동 개입이 더 이상 필요하지 않으며 이는 큰 장점입니다.

업데이트 출시

StatefulSet는 자동 업데이트를 지원합니다. RollingUpdate 전략을 선택하면 Kafka 아래의 각 전략이 차례로 업데이트됩니다. 이러한 방식으로 가동 중지 시간을 XNUMX으로 줄일 수 있습니다.

스케일링

Kafka 클러스터를 확장하는 것은 쉬운 작업이 아닙니다. 그러나 Kubernetes를 사용하면 Pod를 특정 수의 복제본으로 쉽게 확장할 수 있습니다. 즉, 원하는 만큼 Kafka 브로커를 선언적으로 정의할 수 있습니다. 이 경우 가장 어려운 점은 확장 후 또는 축소하기 전에 섹터를 다시 할당하는 것입니다. 이번에도 Kubernetes가 이 작업에 도움을 줄 것입니다.

관리

주제 생성, 섹터 재할당 등 Kafka 클러스터 관리와 관련된 작업은 포드에서 명령줄 인터페이스를 열어 기존 셸 스크립트를 사용하여 수행할 수 있습니다. 그러나 이 솔루션은 별로 아름답지 않습니다. Strimzi는 다른 연산자를 사용하여 주제 관리를 지원합니다. 여기에는 개선의 여지가 있습니다.

백업 및 복구

이제 Kafka의 가용성은 Kubernetes의 가용성에 따라 달라집니다. Kubernetes 클러스터가 실패하면 최악의 시나리오에서는 Kafka 클러스터도 실패합니다. 머피의 법칙에 따르면 이런 일이 반드시 발생하고 데이터가 손실됩니다. 이러한 유형의 위험을 줄이려면 좋은 백업 개념을 갖추십시오. MirrorMaker를 사용할 수 있습니다. 또 다른 옵션은 여기에 설명된 대로 S3를 사용하는 것입니다. 우편 잘란도 출신.

결론

중소 규모의 Kafka 클러스터로 작업할 때는 추가적인 유연성을 제공하고 운영자 경험을 단순화하므로 Kubernetes를 사용하는 것이 좋습니다. 매우 중요한 비기능 대기 시간 및/또는 처리량 요구 사항이 있는 경우 다른 배포 옵션을 고려하는 것이 더 나을 수 있습니다.

출처 : habr.com