Strimzi를 사용하여 GKE에 Apache Kafka 배포

Autopilot Standard

---

이 가이드에서는 Strimzi 연산자를 사용하여 Apache Kafka 클러스터를 배포하는 방법을 설명합니다.

Kafka는 처리량이 높은 대용량 실시간 스트리밍 데이터를 처리하도록 설계된 오픈소스 분산 메시징 시스템입니다. 처리 태스크와 분석 태스크를 지원하도록 서로 다른 시스템과 애플리케이션 간에 안정적으로 데이터를 전송할 수 있는 스트리밍 데이터 파이프라인을 빌드할 수 있습니다.

연산자는 커스텀 리소스를 사용하여 애플리케이션과 해당 구성요소를 관리하는 소프트웨어 확장 프로그램입니다. 연산자를 사용하는 이유에 대한 자세한 내용은 오픈소스 Kubernetes 문서의 연산자 패턴을 참조하세요. Strimzi 연산자는 배포 옵션에 유연성을 제공하며 Kubernetes taint와 허용 범위를 사용하여 전용 노드에서 Kafka를 실행할 수 있게 해줍니다.

이 가이드는 Kafka 클러스터를 GKE에 배포하는 데 관심이 있는 플랫폼 관리자, 클라우드 설계자, 운영 전문가를 대상으로 합니다.

이 솔루션은 서드파티 연산자를 사용하여 Kafka 클러스터를 배포해 관리를 자동화하고 오류를 줄이는 방법을 알아보려는 경우에 좋은 출발점입니다. 보다 세부적인 운영 제어를 선호하는 경우 GKE에 가용성이 높은 Kafka 클러스터 배포를 참조하세요.

목표

• Apache Kafka용 GKE 인프라 계획 및 배포
• Strimzi 연산자 배포 및 구성
• Strimzi 연산자를 사용하여 Apache Kafka 구성

혜택

Strimzi에는 다음과 같은 이점이 있습니다.

• Strimzi 연산자는 Kafka 클러스터 관리에 간소화된 Kubernetes 기반 방식을 제공합니다. Strimzi는 Kafka 주제와 사용자를 나타내는 커스텀 리소스를 활용하여 클러스터 관리를 훨씬 더 간단하게 하고 Kubernetes 권장사항에 부합하게 합니다.
• Strimzi는 기본적으로 리스너의 인증서를 생성하고 TLS, SCRAM-SHA, OAuth와 같은 보안 인증 방법을 지원하여 보안을 우선시합니다. 또한 Strimzi는 모든 Kafka 리스너의 NetworkPolicy를 처리합니다.
• Strimzi는 외부 종속 항목에 의존하지 않습니다. 여기에는 Kafka 클러스터와 측정항목 내보내기 도구를 기본 제공하는 ZooKeeper 클러스터가 포함되어 있으므로 추가 도구를 사용할 필요가 없습니다. 특정 요구사항에 맞게 브로커 구성을 세밀하게 조정할 수도 있습니다.

배포 아키텍처

Kafka 클러스터는 브로커라고 하는 서버 하나 이상으로 구성됩니다. 이러한 서버는 공동작업을 수행하여 수신 데이터 스트림을 관리하고 소비자라고 하는 Kafka 클라이언트의 게시-구독 메시징을 용이하게 합니다.

Kafka 클러스터 내의 모든 데이터 파티션에는 해당 파티션에 대한 모든 읽기 및 쓰기 작업을 관리하는 리더 브로커가 할당됩니다. 파티션에는 리더 브로커의 작업을 수동 복제하는 팔로어 브로커가 하나 이상 있을 수도 있습니다.

일반적인 설정에서 ZooKeeper는 브로커 중에서 리더를 선택하고 문제가 발생할 경우 원활하게 장애 조치를 수행하여 Kafka 클러스터를 조정합니다.

KRaft 모드를 활성화하여 Zookeeper를 사용하지 않고도 Kafka 구성을 배포할 수도 있지만 이 방법은 KafkaTopic 리소스, 사용자 인증 정보 인증 등을 지원하지 않으므로 Strimzi 커뮤니티에서 프로덕션에 즉시 사용할 수 있는 것으로 간주되지 않습니다.

가용성 및 재해 복구

이 튜토리얼에서는 고가용성을 보장하고 재해 복구를 준비하도록 Kafka 클러스터와 ZooKeeper 클러스터에 별도의 노드 풀 및 영역을 사용합니다.

다음과 같은 이유로 Google Cloud에서 가용성이 높은 Kubernetes 클러스터를 확보하려면 여러 노드와 영역을 사용하는 것이 중요합니다.

• 내결함성: 여러 노드가 클러스터 간에 워크로드를 분산하여 노드 하나가 실패하면 다른 노드에서 태스크를 인계하여 다운타임과 서비스 중단을 방지할 수 있도록 합니다.
• 확장성: 여러 노드를 사용하면 수평 확장에서 필요에 따라 노드를 추가하거나 삭제할 수 있으므로 최적의 리소스 할당을 보장하고 증가한 트래픽 또는 워크로드 수요를 수용할 수 있습니다.
• 고가용성: 한 리전 내에서 여러 영역을 사용하면 중복성이 보장되고 단일 장애점 위험이 최소화됩니다. 전체 가용성 영역이 중단되면 클러스터는 다른 영역에서 계속 실행되어 서비스 가용성을 유지할 수 있습니다.
• 지리적 중복성: 리전 간에 노드를 스팬하면 클러스터의 데이터와 서비스가 지리적으로 분산되므로 단일 영역에 영향을 줄 수 있는 자연 재해, 정전, 기타 로컬 장애로부터 복원할 수 있습니다.
• 순차적 업데이트 및 유지보수: 여러 영역을 사용하면 클러스터의 전체 가용성에 영향을 주지 않고 개별 노드에서 순차적 업데이트와 유지보수를 수행할 수 있습니다. 이렇게 하면 필요한 업데이트와 패치를 원활하게 적용할 수 있으므로 지속적인 서비스가 보장됩니다.
• 서비스수준계약(SLA): Google Cloud는 멀티 영역 배포에 대한 SLA를 제공하므로 최소 수준의 업타임과 가용성을 보장합니다.

배포 다이어그램

다음 다이어그램에서는 GKE 클러스터의 여러 노드 및 영역에서 실행되는 Kafka 클러스터를 보여줍니다.

다이어그램에서 Kafka StrimziPodSet은 서로 다른 3개 영역의 노드 3개에 배포되어 있습니다. 필요한 포드 어피니티와 StrimziPodSet 커스텀 리소스 사양에서 토폴로지 분산 규칙을 설정하여 이 구성을 제어할 수 있습니다.

영역 하나가 실패하는 경우 권장 구성을 사용하면 GKE는 Kafka 및 Zookeeper 모두에 대해 새 노드에서 포드를 다시 예약하고 나머지 복제본에서 데이터를 복제합니다.

다음 다이어그램에서 서로 다른 영역 3개의 노드 3개에 배포된 ZooKeeper StrimziPodSet을 보여줍니다.

StrimziPodSet 커스텀 리소스

이 튜토리얼에서는 StatefulSets 대신 Strimzi 버전 0.29에 도입된 StrimziPodSet 커스텀 리소스를 사용합니다.

StrimziPodSet 리소스는 클러스터에 향상된 확장성을 제공하며 구성 옵션을 전달하여 포드를 더 세부적으로 변경할 수 있게 해줍니다. StrimziPodSet 리소스는 기본적으로 Strimzi 버전 0.35 이상에서 사용 설정됩니다.

비용

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

• Compute Engine
• GKE
• Prometheus용 관리형 서비스
• Backup for GKE

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

시작하기 전에

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
2. Install the Google Cloud CLI.

3. To initialize the gcloud CLI, run the following command:

   gcloud init

   Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.

4. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

5. Make sure that billing is enabled for your Google Cloud project.

6. Enable the Compute Engine, IAM, GKE, Backup for GKE, and Resource Manager APIs:

   gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com gkebackup.googleapis.com cloudresourcemanager.googleapis.com

7. Install the Google Cloud CLI.

8. To initialize the gcloud CLI, run the following command:

   gcloud init

   Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.

9. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

10. Make sure that billing is enabled for your Google Cloud project.

11. Enable the Compute Engine, IAM, GKE, Backup for GKE, and Resource Manager APIs:

    gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com gkebackup.googleapis.com cloudresourcemanager.googleapis.com

12. Grant roles to your user account. Run the following command once for each of the following IAM roles: roles/storage.objectViewer, roles/logging.logWriter, roles/container.clusterAdmin, roles/container.serviceAgent, roles/iam.serviceAccountAdmin, roles/serviceusage.serviceUsageAdmin, roles/iam.serviceAccountAdmin

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE

    • Replace PROJECT_ID with your project ID.

    • Replace USER_IDENTIFIER with the identifier for your user account. For example, user:[e-mail].

    • Replace ROLE with each individual role.

환경 준비

이 튜토리얼에서는 Cloud Shell을 사용하여 Google Cloud에서 호스팅되는 리소스를 관리합니다. Cloud Shell에는 kubectl, gcloud CLI, Helm, Terraform 등 이 튜토리얼에 필요한 소프트웨어가 사전 설치되어 있습니다.

Cloud Shell로 환경을 설정하려면 다음 단계를 따르세요.

1. Google Cloud 콘솔에서 Cloud Shell 활성화를 클릭하여 Google Cloud 콘솔에서 Cloud Shell 세션을 시작합니다. 그러면 Google Cloud 콘솔 하단 창에서 세션이 시작됩니다.

2. 환경 변수를 설정합니다.

   export PROJECT_ID=PROJECT_ID
   export KUBERNETES_CLUSTER_PREFIX=kafka
   export REGION=us-central1
   

   PROJECT_ID를 Google Cloud의 프로젝트 ID로 바꿉니다.

3. GitHub 저장소를 클론합니다.

   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
   

4. 작업 디렉터리로 변경합니다.

   cd kubernetes-engine-samples/streaming/
   

클러스터 인프라 만들기

이 섹션에서는 Terraform 스크립트를 실행하여 가용성이 높은 비공개 리전 GKE 클러스터를 만듭니다. 다음 단계에서는 제어 영역에 대한 공개 액세스를 허용합니다. 액세스를 제한하려면 비공개 클러스터를 만듭니다.

Standard 또는 Autopilot 클러스터를 사용하여 연산자를 설치할 수 있습니다.

Standard

다음 다이어그램에서는 서로 다른 영역 3개에 배포된 비공개 리전 Standard GKE 클러스터를 보여줍니다.

이 인프라를 배포하려면 Cloud Shell에서 다음 명령어를 실행합니다.

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=kafka/terraform/gke-standard init
terraform -chdir=kafka/terraform/gke-standard apply -var project_id=${PROJECT_ID} \
  -var region=${REGION} \
  -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

메시지가 표시되면 yes를 입력합니다. 이 명령어가 완료되고 클러스터에 준비 상태가 표시되는 데 몇 분 정도 걸릴 수 있습니다.

Terraform에서 다음 리소스를 만듭니다.

• Kubernetes 노드의 VPC 네트워크 및 비공개 서브넷
• NAT를 통해 인터넷에 액세스할 수 있는 라우터
• us-central1 리전의 비공개 GKE 클러스터
• 자동 확장이 사용 설정된 노드 풀 2개(영역당 노드 1~2개, 영역당 최소 노드 1개)
• 로깅 및 모니터링 권한이 있는 ServiceAccount
• 재해 복구를 위한 Backup for GKE
• 클러스터 모니터링을 위한 Google Cloud Managed Service for Prometheus

출력은 다음과 비슷합니다.

...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials strimzi-cluster --region us-central1"

Autopilot

다음 다이어그램에서는 비공개 리전 Autopilot GKE 클러스터를 보여줍니다.

인프라를 배포하려면 Cloud Shell에서 다음 명령어를 실행합니다.

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=kafka/terraform/gke-autopilot init
terraform -chdir=kafka/terraform/gke-autopilot apply -var project_id=${PROJECT_ID} \
  -var region=${REGION} \
  -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

메시지가 표시되면 yes를 입력합니다. 이 명령어가 완료되고 클러스터에 준비 상태가 표시되는 데 몇 분 정도 걸릴 수 있습니다.

Terraform에서 다음 리소스를 만듭니다.

• Kubernetes 노드의 VPC 네트워크 및 비공개 서브넷
• NAT를 통해 인터넷에 액세스할 수 있는 라우터
• us-central1 리전의 비공개 GKE 클러스터
• 로깅 및 모니터링 권한이 있는 ServiceAccount
• 클러스터 모니터링을 위한 Google Cloud Managed Service for Prometheus

출력은 다음과 비슷합니다.

...
Apply complete! Resources: 12 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials strimzi-cluster --region us-central1"

클러스터에 연결

클러스터와 통신하도록 kubectl을 구성합니다.

gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --region ${REGION}

클러스터에 Strimzi 연산자 배포

이 섹션에서는 Helm 차트를 사용하여 Strimzi 연산자를 배포합니다. Strimzi를 배포하는 몇 가지 다른 방법도 있습니다.

1. Strimzi Helm 차트 저장소를 추가합니다.

   helm repo add strimzi https://strimzi.io/charts/
   

2. Strimzi 연산자 및 Kafka 클러스터의 네임스페이스를 추가합니다.

   kubectl create ns kafka
   

3. Helm을 사용하여 Strimzi 클러스터 연산자를 배포합니다.

   helm install strimzi-operator strimzi/strimzi-kafka-operator -n kafka
   

   Strimzi 클러스터 연산자와 Kafka 클러스터를 다른 네임스페이스에 배포하려면 --set watchNamespaces="{kafka-namespace,kafka-namespace-2,...}" 매개변수를 helm 명령어에 추가합니다.

4. Helm을 사용하여 Strimzi 클러스터 연산자가 성공적으로 배포되었는지 확인합니다.

   helm ls -n kafka
   

   출력은 다음과 비슷합니다.

   NAME            NAMESPACE    REVISION    UPDATED                              STATUS    CHART                        APP VERSION
   strimzi-operator    kafka      1       2023-06-27 11:22:15.850545 +0200 CEST    deployed    strimzi-kafka-operator-0.35.0    0.35.0
   

Kafka 배포

연산자가 클러스터에 배포되면 Kafka 클러스터 인스턴스를 배포할 수 있습니다.

이 섹션에서는 기본 구성에 Kafka를 배포한 후 가용성, 보안, 관측 가능성 요구사항을 해결하기 위해 다양한 고급 구성 시나리오를 시도합니다.

기본 구성

Kafka 인스턴스의 기본 구성에는 다음 구성요소가 포함됩니다.

• 클러스터 일관성에 필요한 사용할 수 있는 복제본이 최소 2개 있는 Kafka 브로커 복제본 3개
• 클러스터를 형성하는 ZooKeeper 노드 복제본 3개
• Kafka 리스너 두 개: 인증 없이 하나, Strimzi에서 생성된 인증서로 TLS 인증을 활용하는 하나
• Kafka의 경우 4GB, ZooKeeper의 경우 2GB로 설정된 자바 MaxHeapSize 및 MinHeapSize
• Kafka의 경우 5GB 메모리 요청 및 한도(기본 서비스의 경우 4GB, 측정항목 내보내기 도구의 경우 0.5GB) 및 ZooKeeper의 경우 2.5GB(기본 서비스의 경우 2GB, 측정항목 내보내기 도구의 경우 0.5GB)와 함께 Kafka 및 ZooKeeper 모두에 대한 CPU 리소스 1개 및 CPU 한도 2개의 CPU 리소스 할당
• 다음 요청 및 한도가 포함된 항목 연산자:
  • tlsSidecar: 100m/500m CPU 및 128Mi 메모리
  • topicOperator: 100m/500m CPU 및 512Mi 메모리
  • userOperator: 500m CPU 및 2Gi 메모리
• premium-rwo storageClass를 사용하여 각 포드에 할당된 스토리지 100GB
• 노드 간에 올바른 배포를 보장하고 각 노드 풀과 다른 영역을 활용하는 각 워크로드에 구성된 톨러레이션(toleration), nodeAffinities, podAntiAffinities
• 자체 서명된 인증서로 보호되는 클러스터 내 통신: 클러스터와 클라이언트(mTLS)를 위한 별도의 인증 기관(CA). 다른 인증 기관을 사용하도록 구성할 수도 있습니다.

이 구성은 프로덕션에 사용 가능한 Kafka 클러스터를 만드는 데 필요한 최소 설정을 나타냅니다. 다음 섹션에서는 클러스터 보안, 액세스 제어 목록(ACL), 주제 관리, 인증서 관리 등과 같은 측면을 해결하는 커스텀 구성을 보여줍니다.

기본 Kafka 클러스터 만들기

1. 기본 구성을 사용하여 새 Kafka 클러스터를 만듭니다.

   kubectl apply -n kafka -f kafka-strimzi/manifests/01-basic-cluster/my-cluster.yaml
   

   이 명령어는 CPU 및 메모리 요청과 한도, 블록 스토리지 요청, 프로비저닝된 포드를 Kubernetes 노드 간에 배포하기 위한 taint와 어피니티의 조합이 포함된 Strimzi 연산자의 Kafka 커스텀 리소스를 만듭니다.

2. Kubernetes에서 필요한 워크로드를 시작하는 동안 몇 분 정도 기다립니다.

   kubectl wait kafka/my-cluster --for=condition=Ready --timeout=600s -n kafka
   

3. Kafka 워크로드가 생성되었는지 확인합니다.

   kubectl get pod,service,deploy,pdb -l=strimzi.io/cluster=my-cluster -n kafka
   

   출력은 다음과 비슷합니다.

   NAME                                            READY   STATUS  RESTARTS   AGE
   pod/my-cluster-entity-operator-848698874f-j5m7f   3/3   Running   0        44m
   pod/my-cluster-kafka-0                          1/1   Running   0        5m
   pod/my-cluster-kafka-1                          1/1   Running   0        5m
   pod/my-cluster-kafka-2                          1/1   Running   0        5m
   pod/my-cluster-zookeeper-0                      1/1   Running   0        6m
   pod/my-cluster-zookeeper-1                      1/1   Running   0        6m
   pod/my-cluster-zookeeper-2                      1/1   Running   0        6m
   
   NAME                                TYPE      CLUSTER-IP   EXTERNAL-IP   PORT(S)                             AGE
   service/my-cluster-kafka-bootstrap  ClusterIP   10.52.8.80   <none>      9091/TCP,9092/TCP,9093/TCP          5m
   service/my-cluster-kafka-brokers    ClusterIP   None         <none>      9090/TCP,9091/TCP,9092/TCP,9093/TCP   5m
   service/my-cluster-zookeeper-client   ClusterIP   10.52.11.144   <none>      2181/TCP                            6m
   service/my-cluster-zookeeper-nodes  ClusterIP   None         <none>      2181/TCP,2888/TCP,3888/TCP          6m
   
   NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/my-cluster-entity-operator   1/1   1          1         44m
   
   NAME                                            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
   poddisruptionbudget.policy/my-cluster-kafka     2             N/A             1                   5m
   poddisruptionbudget.policy/my-cluster-zookeeper   2             N/A             1                   6m
   

연산자는 다음 리소스를 만듭니다.

• Kafka 및 ZooKeeper의 경우 StrimziPodSets 2개
• Kafka 브로커 복제본을 위한 포드 3개
• ZooKeeper 복제본을 위한 포드 3개
• 클러스터 일관성을 위해 복제본 2개의 최소 가용성을 보장하는 PodDisruptionBudgets 2개
• Kubernetes 클러스터 내에서 연결하는 Kafka 클라이언트의 부트스트랩 서버 역할을 하는 my-cluster-kafka-bootstrap이라는 서비스. 모든 내부 Kafka 리스너가 이 서비스에서 제공됩니다.
• Kafka 브로커 포드 IP 주소의 DNS 변환을 직접 사용 설정하는 my-cluster-kafka-brokers라는 헤드리스 서비스. 이 서비스는 브로커 간 통신에 사용됩니다.
• Kafka 브로커가 클라이언트로 ZooKeeper 노드에 연결할 수 있게 해주는 my-cluster-zookeeper-client라는 서비스
• ZooKeeper 포드 IP 주소의 DNS 변환을 직접 사용 설정하는 my-cluster-zookeeper-nodes라는 헤드리스 서비스. 이 서비스는 ZooKeeper 복제본 간에 연결하는 데 사용됩니다.
• topic-operator 및 user-operator가 포함되고 커스텀 리소스 KafkaTopics 및 KafkaUsers의 관리를 용이하게 하는 my-cluster-entity-operator라는 배포

또한 모든 포드 및 네임스페이스에서 Kafka 리스너에 쉽게 연결할 수 있게 해주는 NetworkPolicies 2개를 구성할 수 있습니다. 또한 이러한 정책은 ZooKeeper에 대한 연결을 브로커로 제한하고 클러스터 포드와 클러스터 통신 전용 내부 서비스 포트 간 통신을 사용 설정합니다.

인증 및 사용자 관리

이 섹션에서는 Kafka 리스너를 보호하고 클라이언트와 사용자 인증 정보를 공유하도록 인증과 승인을 사용 설정하는 방법을 보여줍니다.

Strimzi는 개별 User Operator 및 사용자 구성을 정의하는 해당 Kubernetes 커스텀 리소스인 KafkaUser를 사용하여 Kubernetes 기본 사용자 관리 방법을 제공합니다. 사용자 구성에는 인증 및 승인 설정이 포함되며 해당 사용자를 Kafka에 프로비저닝합니다.

Strimzi는 사용자 이름 및 비밀번호 기반 인증(SCRAM-SHA-512) 또는 TLS와 같은 여러 인증 메커니즘을 지원하는 Kafka 리스너와 사용자를 만들 수 있습니다. 또한 OAuth 2.0 인증을 사용할 수도 있습니다. 이 방법은 보안 및 외부 사용자 인증 정보 관리로 인해 인증에 비밀번호이나 사용자 인증 정보를 사용하는 방법 보다 더 좋은 방법으로 간주되는 경우가 많습니다.

Kafka 클러스터 배포

이 섹션에서는 다음을 포함하여 사용자 관리 기능을 보여주는 Strimzi 연산자를 배포하는 방법을 보여줍니다.

• 리스너 중 하나에서 비밀번호 기반 인증(SCRAM-SHA-512)이 사용 설정된 Kafka 클러스터
• 복제본 3개가 있는 KafkaTopic
• 사용자에게 주제에 대한 읽기 및 쓰기 권한이 있음을 지정하는 ACL이 포함된 KafkaUser

1. 포트 9094에서 비밀번호 기반 SCRAM-SHA-512 인증과 간단한 승인으로 리스너를 사용하도록 Kafka 클러스터를 구성합니다.

   kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/my-cluster.yaml
   

2. Topic, User, 클라이언트 포드를 만들어 Kafka 클러스터에 대한 명령어를 실행합니다.

   kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/topic.yaml
   kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/my-user.yaml
   

   사용자 인증 정보가 있는 Secret my-user는 클라이언트 포드에 볼륨으로 마운트됩니다.

   이러한 사용자 인증 정보는 사용자에게 비밀번호 기반 인증(SCRAM-SHA-512)이 사용 설정된 리스너를 사용하여 주제에 메시지를 게시할 수 있는 권한이 있는지 확인합니다.

3. 클라이언트 포드를 만듭니다.

   kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/kafkacat.yaml
   

4. 클라이언트 포드가 Ready가 될 때까지 몇 분 정도 기다린 후 연결합니다.

   kubectl wait --for=condition=Ready pod --all -n kafka --timeout=600s
   kubectl exec -it kafkacat -n kafka -- /bin/sh
   

5. my-user 사용자 인증 정보로 새 메시지를 생성하고 사용해 봅니다.

   echo "Message from my-user" |kcat \
     -b my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9094 \
     -X security.protocol=SASL_SSL \
     -X sasl.mechanisms=SCRAM-SHA-512 \
     -X sasl.username=my-user \
     -X sasl.password=$(cat /my-user/password) \
     -t my-topic -P
   kcat -b my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9094 \
     -X security.protocol=SASL_SSL \
     -X sasl.mechanisms=SCRAM-SHA-512 \
     -X sasl.username=my-user \
     -X sasl.password=$(cat /my-user/password) \
     -t my-topic -C
   

   출력은 다음과 비슷합니다.

   Message from my-user
   % Reached end of topic my-topic [0] at offset 0
   % Reached end of topic my-topic [2] at offset 1
   % Reached end of topic my-topic [1] at offset 0
   

   CTRL+C를 입력하여 소비자 프로세스를 중지합니다.

6. 포드 셸을 종료합니다.

   exit
   

백업 및 재해 복구

Strimzi 연산자에서는 백업 기능이 기본 제공하지 않지만 특정 패턴을 따라 효율적인 백업 전략을 구현할 수 있습니다.

Backup for GKE를 사용하여 백업할 수 있습니다.

• Kubernetes 리소스 매니페스트
• Strimzi API 커스텀 리소스와 백업 중인 클러스터의 Kubernetes API 서버에서 추출된 정의
• 매니페스트에서 찾은 PersistentVolumeClaim 리소스에 해당하는 볼륨

Backup for GKE를 사용하여 Kafka 클러스터를 백업 및 복원하는 방법에 대한 자세한 내용은 재해 복구 준비를 참조하세요.

Strimzi 연산자를 사용하여 배포한 Kafka 클러스터를 백업할 수도 있습니다. 다음을 백업해야 합니다.

• KafkaTopics 및 KafkaUsers와 같은 Strimzi API의 모든 커스텀 리소스가 포함된 Kafka 구성
• Kafka 브로커의 PersistentVolume에 저장된 데이터

Strimzi 구성을 포함하여 Kubernetes 리소스 매니페스트를 Git 저장소에 저장하면 필요할 때 리소스를 새 Kubernetes 클러스터에 다시 적용할 수 있으므로 Kafka 구성을 별도로 백업할 필요가 없습니다.

Kafka 서버 인스턴스 또는 Kafka가 배포된 Kubernetes 클러스터가 손실된 시나리오에서 Kafka 데이터 복구를 보호하려면 reclaimPolicy 옵션을 Retain으로 설정하여 Kafka 브로커의 볼륨을 프로비저닝하는 데 사용되는 Kubernetes 스토리지 클래스를 구성하는 것이 좋습니다. 또한 Kafka 브로커 볼륨의 스냅샷을 만드는 것이 좋습니다.

다음 매니페스트에서는 reclaimPolicy 옵션 Retain을 사용하는 StorageClass를 설명합니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: premium-rwo-retain
...
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

다음 예시에서는 Kafka 클러스터 커스텀 리소스의 spec에 추가된 StorageClass를 보여줍니다.

# ...
spec:
  kafka:
    # ...
    storage:
      type: persistent-claim
      size: 100Gi
      class: premium-rwo-retain

이 구성을 사용하면 스토리지 클래스를 사용하여 프로비저닝된 PersistentVolume은 해당 PersistentVolumeClaim이 삭제되더라도 삭제되지 않습니다.

기존 구성과 브로커 인스턴스 데이터를 사용하여 새 Kubernetes 클러스터에서 Kafka 인스턴스를 복구하려면 다음 안내를 따르세요.

1. 기존 Strimzi Kafka 커스텀 리소스(Kakfa, KafkaTopic, KafkaUser 등)를 새 Kubernetes 클러스터에 적용합니다.
2. PersistentVolumeClaim에서 spec.volumeName 속성을 사용하여 새 Kafka 브로커 인스턴스 이름이 있는 PersistentVolumeClaim을 이전 PersistentVolume으로 업데이트합니다.

삭제

이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.

프로젝트 삭제

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.

• 프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
• 커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.

여러 아키텍처, 튜토리얼, 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

개별 리소스 삭제

기존 프로젝트를 사용한 경우 삭제하지 않으려면 개별 리소스를 삭제합니다.

1. 환경 변수를 설정합니다.

   export PROJECT_ID=${PROJECT_ID}
   export KUBERNETES_CLUSTER_PREFIX=kafka
   export REGION=us-central1
   

2. terraform destroy 명령어를 실행합니다.

   export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
   terraform -chdir=kafka/terraform/FOLDER destroy -var project_id=${PROJECT_ID}   \
     -var region=${REGION}  \
     -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}
   

   FOLDER를 gke-autopilot 또는 gke-standard로 바꿉니다.

   메시지가 표시되면 yes를 입력합니다.

3. 연결되지 않은 모든 디스크를 찾습니다.

   export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,zone)")
   

   기본적으로 Strimzi는 스토리지에 deleteClaim: false 매개변수를 사용하므로 이 단계가 필요합니다. 클러스터를 삭제해도 모든 디스크를 계속 사용할 수 있습니다.

4. 디스크를 삭제합니다.

   for i in $disk_list; do
     disk_name=$(echo $i| cut -d'|' -f1)
     disk_zone=$(echo $i| cut -d'|' -f2|sed 's|.*/||')
     echo "Deleting $disk_name"
     gcloud compute disks delete $disk_name --zone $disk_zone --quiet
   done
   

다음 단계

• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기