Tentukan saiz yang sesuai untuk gugusan Kafka dalam Kubernetes

Catatan. terjemah: Dalam artikel ini, Banzai Cloud berkongsi contoh cara alatan tersuainya boleh digunakan untuk menjadikan Kafka lebih mudah digunakan dalam Kubernetes. Arahan berikut menggambarkan cara anda boleh menentukan saiz optimum infrastruktur anda dan mengkonfigurasi Kafka sendiri untuk mencapai daya pemprosesan yang diperlukan.

Apache Kafka ialah platform penstriman teragih untuk mencipta sistem penstriman masa nyata yang boleh dipercayai, berskala dan berprestasi tinggi. Keupayaan mengagumkannya boleh dilanjutkan menggunakan Kubernetes. Untuk ini kami telah membangunkan Pengendali Kafka Sumber Terbuka dan alat yang dipanggil Supertiub. Mereka membenarkan anda menjalankan Kafka di Kubernetes dan menggunakan pelbagai cirinya, seperti memperhalusi konfigurasi broker, penskalaan berasaskan metrik dengan pengimbangan semula, kesedaran rak, "lembut" (anggun) melancarkan kemas kini, dsb.

Cuba Supertubes dalam kelompok anda:

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

Atau hubungi dokumentasi. Anda juga boleh membaca tentang beberapa keupayaan Kafka, kerja yang diautomatikkan menggunakan Supertubes dan pengendali Kafka. Kami telah menulis tentang mereka di blog:

• Oh tidak! Satu lagi pengendali Kafka untuk Kubernetes;
• Pantau dan kendalikan Kafka berdasarkan metrik Prometheus;
• Kesedaran rak Kafka pada Kubernetes;
• Menjalankan Apache Kafka di atas Istio - penanda aras;
• Pengguna disahkan dan mengakses kluster terkawal dengan pengendali Kafka;
• Kafka rolling upgrade dan konfigurasi dinamik pada Kubernetes;
• Penapis protokol utusan untuk Kafka, dijalin.

Apabila anda memutuskan untuk menggunakan kluster Kafka pada Kubernetes, anda mungkin akan berhadapan dengan cabaran untuk menentukan saiz optimum infrastruktur asas dan keperluan untuk memperhalusi konfigurasi Kafka anda untuk memenuhi keperluan pemprosesan. Prestasi maksimum setiap broker ditentukan oleh prestasi komponen infrastruktur asas, seperti memori, pemproses, kelajuan cakera, lebar jalur rangkaian, dsb.

Sebaik-baiknya, konfigurasi broker harus sedemikian rupa sehingga semua elemen infrastruktur digunakan dengan keupayaan maksimumnya. Walau bagaimanapun, dalam kehidupan sebenar persediaan ini agak rumit. Kemungkinan besar pengguna akan mengkonfigurasi broker untuk memaksimumkan penggunaan satu atau dua komponen (cakera, memori atau pemproses). Secara umumnya, broker menunjukkan prestasi maksimum apabila konfigurasinya membenarkan komponen paling perlahan digunakan sepenuhnya. Dengan cara ini kita boleh mendapatkan gambaran kasar tentang beban yang boleh dikendalikan oleh satu broker.

Secara teorinya, kami juga boleh menganggarkan bilangan broker yang diperlukan untuk mengendalikan beban tertentu. Walau bagaimanapun, dalam praktiknya terdapat begitu banyak pilihan konfigurasi pada tahap yang berbeza sehingga sangat sukar (jika tidak mustahil) untuk menilai potensi prestasi konfigurasi tertentu. Dalam erti kata lain, sangat sukar untuk merancang konfigurasi berdasarkan beberapa prestasi tertentu.

Bagi pengguna Supertubes, kami biasanya mengambil pendekatan berikut: kami mulakan dengan beberapa konfigurasi (infrastruktur + tetapan), kemudian ukur prestasinya, laraskan tetapan broker dan ulangi proses sekali lagi. Ini berlaku sehingga komponen infrastruktur yang paling perlahan digunakan sepenuhnya.

Dengan cara ini, kami mendapat gambaran yang lebih jelas tentang berapa banyak broker yang diperlukan oleh kluster untuk mengendalikan beban tertentu (bilangan broker juga bergantung pada faktor lain, seperti bilangan minimum replika mesej untuk memastikan daya tahan, bilangan partition pemimpin, dsb.). Di samping itu, kami mendapat cerapan tentang komponen infrastruktur yang memerlukan penskalaan menegak.

Artikel ini akan membincangkan tentang langkah-langkah yang kami ambil untuk memanfaatkan sepenuhnya komponen yang paling perlahan dalam konfigurasi awal dan mengukur daya pengeluaran gugusan Kafka. Konfigurasi yang sangat berdaya tahan memerlukan sekurang-kurangnya tiga broker yang sedang berjalan (min.insync.replicas=3), diedarkan merentasi tiga zon kebolehcapaian yang berbeza. Untuk mengkonfigurasi, menskala dan memantau infrastruktur Kubernetes, kami menggunakan platform pengurusan kontena kami sendiri untuk awan hibrid - Paip. Ia menyokong di premis (logam kosong, VMware) dan lima jenis awan (Alibaba, AWS, Azure, Google, Oracle), serta mana-mana gabungan daripadanya.

Pemikiran tentang infrastruktur dan konfigurasi kelompok Kafka

Untuk contoh di bawah, kami memilih AWS sebagai pembekal awan dan EKS sebagai pengedaran Kubernetes. Konfigurasi serupa boleh dilaksanakan menggunakan P.K.E. - Pengedaran Kubernetes daripada Banzai Cloud, disahkan oleh CNCF.

Диск

Amazon menawarkan pelbagai Jenis volum EBS. Pada intinya gp2 и io1 terdapat pemacu SSD, walau bagaimanapun, untuk memastikan daya pemprosesan yang tinggi gp2 menggunakan kredit terkumpul (Kredit I/O), jadi kami lebih suka jenisnya io1, yang menawarkan daya pemprosesan tinggi yang konsisten.

Jenis contoh

Prestasi Kafka sangat bergantung pada cache halaman sistem pengendalian, jadi kami memerlukan contoh dengan memori yang mencukupi untuk broker (JVM) dan cache halaman. Contoh c5.2x besar - permulaan yang baik, kerana ia mempunyai 16 GB memori dan dioptimumkan untuk bekerja dengan EBS. Kelemahannya ialah ia hanya mampu memberikan prestasi maksimum tidak melebihi 30 minit setiap 24 jam. Jika beban kerja anda memerlukan prestasi puncak dalam tempoh yang lebih lama, anda mungkin ingin mempertimbangkan jenis contoh lain. Itulah yang kami lakukan, berhenti di c5.4x besar. Ia menyediakan daya pemprosesan maksimum dalam 593,75 Mb/s. Daya pemprosesan maksimum volum EBS io1 lebih tinggi daripada contoh c5.4x besar, jadi elemen infrastruktur yang paling perlahan mungkin ialah daya pemprosesan I/O jenis contoh ini (yang ujian beban kami juga harus disahkan).

Сеть

Daya tampung rangkaian mestilah cukup besar berbanding dengan prestasi tika dan cakera VM, jika tidak rangkaian menjadi kesesakan. Dalam kes kami, antara muka rangkaian c5.4x besar menyokong kelajuan sehingga 10 Gb/s, yang jauh lebih tinggi daripada daya pemprosesan I/O bagi tika VM.

Kerahan Broker

Broker harus digunakan (dijadualkan dalam Kubernetes) ke nod khusus untuk mengelakkan bersaing dengan proses lain untuk sumber CPU, memori, rangkaian dan cakera.

versi Java

Pilihan logik ialah Java 11 kerana ia serasi dengan Docker dalam erti kata bahawa JVM dengan betul menentukan pemproses dan memori yang tersedia untuk bekas di mana broker sedang berjalan. Mengetahui bahawa had CPU adalah penting, JVM secara dalaman dan telus menetapkan bilangan utas GC dan utas JIT. Kami menggunakan imej Kafka banzaicloud/kafka:2.13-2.4.0, yang termasuk Kafka versi 2.4.0 (Scala 2.13) pada Java 11.

Jika anda ingin mengetahui lebih lanjut tentang Java/JVM di Kubernetes, lihat siaran berikut kami:

• Mengapa aplikasi Java saya OOMKilled;
• Cara mensaiz bekas dengan betul untuk aplikasi Java 10.

Tetapan memori broker

Terdapat dua aspek utama untuk mengkonfigurasi memori broker: tetapan untuk JVM dan untuk pod Kubernetes. Had memori yang ditetapkan untuk pod mestilah lebih besar daripada saiz timbunan maksimum supaya JVM mempunyai ruang untuk metaspace Java yang berada dalam memorinya sendiri dan untuk cache halaman sistem pengendalian yang Kafka gunakan secara aktif. Dalam ujian kami, kami melancarkan broker Kafka dengan parameter -Xmx4G -Xms2G, dan had ingatan untuk pod ialah 10 Gi. Sila ambil perhatian bahawa tetapan memori untuk JVM boleh diperoleh secara automatik menggunakan -XX:MaxRAMPercentage и -X:MinRAMPercentage, berdasarkan had memori untuk pod.

Tetapan pemproses broker

Secara umumnya, anda boleh meningkatkan prestasi dengan meningkatkan keselarian dengan menambah bilangan utas yang digunakan oleh Kafka. Lebih banyak pemproses tersedia untuk Kafka, lebih baik. Dalam ujian kami, kami bermula dengan had 6 pemproses dan secara beransur-ansur (melalui lelaran) meningkatkan bilangannya kepada 15. Selain itu, kami menetapkan num.network.threads=12 dalam tetapan broker untuk menambah bilangan benang yang menerima data daripada rangkaian dan menghantarnya. Dengan serta-merta mendapati bahawa broker pengikut tidak dapat menerima replika dengan cukup cepat, mereka membangkitkan num.replica.fetchers kepada 4 untuk meningkatkan kelajuan di mana broker pengikut mereplikasi mesej daripada pemimpin.

Alat Penjanaan Beban

Anda harus memastikan bahawa penjana beban yang dipilih tidak kehabisan kapasiti sebelum gugusan Kafka (yang sedang ditanda aras) mencapai beban maksimumnya. Dalam erti kata lain, adalah perlu untuk menjalankan penilaian awal keupayaan alat penjanaan beban, dan juga memilih jenis contoh untuknya dengan bilangan pemproses dan memori yang mencukupi. Dalam kes ini, alat kami akan menghasilkan lebih banyak beban daripada gugusan Kafka boleh kendalikan. Selepas banyak percubaan, kami menyelesaikan tiga salinan c5.4x besar, setiap satunya mempunyai penjana yang sedang berjalan.

Penandaarasan

Pengukuran prestasi ialah proses berulang yang merangkumi peringkat berikut:

• menyediakan infrastruktur (kluster EKS, kluster Kafka, alat penjanaan beban, serta Prometheus dan Grafana);
• menjana beban untuk tempoh tertentu untuk menapis sisihan rawak dalam penunjuk prestasi yang dikumpul;
• melaraskan infrastruktur dan konfigurasi broker berdasarkan petunjuk prestasi yang diperhatikan;
• mengulangi proses sehingga tahap daya pemprosesan kelompok Kafka yang diperlukan dicapai. Pada masa yang sama, ia mesti boleh dihasilkan semula secara konsisten dan menunjukkan variasi minimum dalam daya pemprosesan.

Bahagian seterusnya menerangkan langkah-langkah yang telah dilakukan semasa proses penanda aras kelompok ujian.

Tools

Alat berikut telah digunakan untuk menggunakan konfigurasi garis dasar dengan cepat, menjana beban dan mengukur prestasi:

• Talian Paip Awan Banzai untuk menganjurkan kluster EKS dari Amazon c Prometheus (untuk mengumpul metrik Kafka dan infrastruktur) dan grafana (untuk menggambarkan metrik ini). Kami mengambil kesempatan bersepadu в Paip perkhidmatan yang menyediakan pemantauan bersekutu, pengumpulan log berpusat, pengimbasan kelemahan, pemulihan bencana, keselamatan gred perusahaan dan banyak lagi.
• Sangrenel — alat untuk menguji beban kelompok Kafka.
• Papan pemuka Grafana untuk menggambarkan metrik dan infrastruktur Kafka: Kubernetes Kafka, Pengeksport Nod.
• Supertubes CLI untuk cara termudah untuk menyediakan gugusan Kafka pada Kubernetes. Zookeeper, pengendali Kafka, Utusan dan banyak komponen lain dipasang dan dikonfigurasikan dengan betul untuk menjalankan gugusan Kafka sedia pengeluaran di Kubernetes.
  • Untuk memasang tiub super CLI gunakan arahan yang diberikan di sini.

Kelompok EKS

Sediakan kelompok EKS dengan nod pekerja khusus c5.4x besar dalam zon ketersediaan yang berbeza untuk pod dengan broker Kafka, serta nod khusus untuk penjana beban dan infrastruktur pemantauan.

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

Setelah kluster EKS siap dan berjalan, dayakan ia bersepadu perkhidmatan pemantauan — dia akan menggunakan Prometheus dan Grafana ke dalam kelompok.

Komponen sistem Kafka

Pasang komponen sistem Kafka (Zookeeper, kafka-operator) dalam EKS menggunakan supertubes CLI:

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

Kelompok Kafka

Secara lalai, EKS menggunakan volum jenis EBS gp2, jadi anda perlu membuat kelas storan berasingan berdasarkan volum io1 untuk kelompok Kafka:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

Tetapkan parameter untuk broker min.insync.replicas=3 dan gunakan pod broker pada nod dalam tiga zon ketersediaan yang berbeza:

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

Topik

Kami menjalankan tiga contoh penjana beban secara selari. Setiap daripada mereka menulis topik mereka sendiri, iaitu, kami memerlukan tiga topik secara keseluruhan:

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

Untuk setiap topik, faktor replikasi ialah 3—nilai minimum yang disyorkan untuk sistem pengeluaran yang sangat tersedia.

Alat Penjanaan Beban

Kami melancarkan tiga salinan penjana beban (setiap satu menulis dalam topik yang berasingan). Untuk pod penjana beban, anda perlu menetapkan pertalian nod supaya ia dijadualkan hanya pada nod yang diperuntukkan untuknya:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

Beberapa perkara yang perlu diperhatikan:

• Penjana beban menjana mesej sepanjang 512 bait dan menerbitkannya kepada Kafka dalam kelompok 500 mesej.
• Menggunakan hujah -required-acks=all Penerbitan dianggap berjaya apabila semua replika mesej yang disegerakkan diterima dan disahkan oleh broker Kafka. Ini bermakna bahawa dalam penanda aras kami mengukur bukan sahaja kelajuan pemimpin menerima mesej, tetapi juga pengikut mereka mereplikasi mesej. Tujuan ujian ini bukan untuk menilai kelajuan membaca pengguna (pengguna) menerima mesej baru-baru ini yang masih kekal dalam cache halaman OS, dan perbandingannya dengan kelajuan membaca mesej yang disimpan pada cakera.
• Penjana beban menjalankan 20 pekerja secara selari (-workers=20). Setiap pekerja mengandungi 5 pengeluar yang berkongsi sambungan pekerja dengan gugusan Kafka. Akibatnya, setiap penjana mempunyai 100 pengeluar, dan mereka semua menghantar mesej kepada gugusan Kafka.

Memantau kesihatan kluster

Semasa ujian beban gugusan Kafka, kami juga memantau kesihatannya untuk memastikan tiada permulaan semula pod, tiada replika yang tidak segerak dan pemprosesan maksimum dengan turun naik yang minimum:

• Penjana beban menulis statistik standard tentang bilangan mesej yang diterbitkan dan kadar ralat. Kadar ralat harus kekal sama 0,00%.
• Kawalan Cruise, digunakan oleh kafka-operator, menyediakan papan pemuka di mana kami juga boleh memantau keadaan kluster. Untuk melihat panel ini lakukan:

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• tahap ISR (bilangan replika "selaras") pengecutan dan pengembangan adalah sama dengan 0.

Hasil pengukuran

3 broker, saiz mesej - 512 bait

Dengan pembahagian yang sama rata pada tiga broker, kami dapat mencapai prestasi ~500 Mb/s (kira-kira 990 ribu mesej sesaat):

Penggunaan memori mesin maya JVM tidak melebihi 2 GB:

Daya tampung cakera mencapai daya tampung nod I/O maksimum pada ketiga-tiga kejadian di mana broker sedang berjalan:

Daripada data tentang penggunaan memori oleh nod, ia berikutan bahawa penimbalan sistem dan caching mengambil masa ~10-15 GB:

3 broker, saiz mesej - 100 bait

Apabila saiz mesej berkurangan, daya pemprosesan berkurangan kira-kira 15-20%: masa yang dibelanjakan untuk memproses setiap mesej mempengaruhinya. Di samping itu, beban pemproses telah hampir dua kali ganda.

Memandangkan nod broker masih mempunyai teras yang tidak digunakan, prestasi boleh dipertingkatkan dengan menukar konfigurasi Kafka. Ini bukan tugas yang mudah, jadi untuk meningkatkan daya pengeluaran adalah lebih baik untuk bekerja dengan mesej yang lebih besar.

4 broker, saiz mesej - 512 bait

Anda boleh meningkatkan prestasi kluster Kafka dengan mudah dengan hanya menambah broker baharu dan mengekalkan keseimbangan partition (ini memastikan bahawa beban diagihkan secara sama rata antara broker). Dalam kes kami, selepas menambah broker, hasil kluster meningkat kepada ~580 Mb/s (~1,1 juta mesej sesaat). Pertumbuhan ternyata kurang daripada yang dijangkakan: ini terutamanya dijelaskan oleh ketidakseimbangan partition (tidak semua broker bekerja pada puncak keupayaan mereka).

Penggunaan memori mesin JVM kekal di bawah 2 GB:

Kerja broker dengan pemacu dipengaruhi oleh ketidakseimbangan partition:

Penemuan

Pendekatan berulang yang dibentangkan di atas boleh diperluaskan untuk merangkumi senario yang lebih kompleks melibatkan ratusan pengguna, pembahagian semula, kemas kini rolling, mulakan semula pod, dsb. Semua ini membolehkan kami menilai had keupayaan gugusan Kafka dalam pelbagai keadaan, mengenal pasti kesesakan dalam operasinya dan mencari cara untuk memeranginya.

Kami mereka bentuk Supertubes untuk menggunakan kluster dengan cepat dan mudah, mengkonfigurasinya, menambah/mengalih keluar broker dan topik, bertindak balas kepada makluman dan memastikan Kafka secara umum berfungsi dengan baik pada Kubernetes. Matlamat kami adalah untuk membantu anda menumpukan perhatian pada tugas utama ("menjana" dan "menggunakan" mesej Kafka), dan menyerahkan semua kerja keras kepada Supertubes dan pengendali Kafka.

Jika anda berminat dengan teknologi Awan Banzai dan projek Sumber Terbuka, langgan syarikat di GitHub, LinkedIn atau Twitter.

PS daripada penterjemah

Baca juga di blog kami:

• «Satu cerita dengan pengendali Redis dalam K8s dan semakan mini utiliti untuk menganalisis data daripada pangkalan data ini»;
• «Penghijrahan RabbitMQ yang lancar ke Kubernetes»;
• «zetcd daripada CoreOS: Menggantikan ZooKeeper dengan...etcd storan'.

Sumber: www.habr.com