Kubernetesтеги Кафка кластери үчүн ылайыктуу өлчөмдү аныктоо

Эскертүү. котормо.: Бул макалада Banzai Cloud анын ыңгайлаштырылган куралдары Кафканы Kubernetes ичинде колдонууну жеңилдетүү үчүн кантип колдонсо болорун мисал менен бөлүшөт. Төмөнкү инструкциялар сиз инфраструктураңыздын оптималдуу өлчөмүн кантип аныктай аларыңызды жана талап кылынган өткөрүү жөндөмдүүлүгүнө жетүү үчүн Кафканын өзүн конфигурациялоону көрсөтөт.

Apache Kafka ишенимдүү, масштабдуу жана жогорку натыйжалуу реалдуу убакыт агымдык системаларын түзүү үчүн бөлүштүрүлгөн агымдык платформа болуп саналат. Анын таасирдүү мүмкүнчүлүктөрүн Kubernetes аркылуу кеңейтүүгө болот. Бул үчүн биз иштеп чыктык Open Source Kafka оператору жана курал деп аталган Supertubes. Алар сизге Кафканы Kubernetes'те иштетүүгө жана анын ар кандай өзгөчөлүктөрүн колдонууга мүмкүндүк берет, мисалы, брокердин конфигурациясын тактоо, метрикага негизделген масштабдоо, балансты өзгөртүү, стойкаларды билүү, "жумшак" (сылык) жаңыртууларды чыгаруу ж.б.

Кластериңизде Supertubes колдонуп көрүңүз:

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

Же байланыш документтер. Сиз ошондой эле Кафканын кээ бир мүмкүнчүлүктөрү жөнүндө окуй аласыз, алар менен иштөө Supertubes жана Кафка операторунун жардамы менен автоматташтырылган. Биз алар жөнүндө блогдо буга чейин жазганбыз:

• Ой жок! Kubernetes үчүн дагы бир Кафка оператору;
• Prometheus метрикасынын негизинде Кафканы көзөмөлдөп, иштетиңиз;
• Kubernetes боюнча Кафка rack маалымдуулугу;
• Apache Кафканы Istio аркылуу иштетүү - эталон;
• Колдонуучу аутентификацияланган жана Кафка оператору менен башкарылган кластерлерге кирүү;
• Kubernetes'те Кафканы жаңыртуу жана динамикалык конфигурациялоо;
• Кафка үчүн элчи протокол чыпкасы, тор.

Кафка кластерин Kubernetesте жайгаштырууну чечкенде, сиз негизги инфраструктуранын оптималдуу өлчөмүн аныктоо жана өткөрүү жөндөмдүүлүгүнүн талаптарын канааттандыруу үчүн Кафка конфигурацияңызды тактоо зарылдыгына туш болосуз. Ар бир брокердин максималдуу иштеши эстутум, процессор, дисктин ылдамдыгы, тармак өткөрүү жөндөмдүүлүгү ж.

Идеалында, брокердин конфигурациясы инфраструктуранын бардык элементтери максималдуу мүмкүнчүлүктөрүн пайдалангандай болушу керек. Бирок, чыныгы жашоодо бул орнотуу абдан татаал. Колдонуучулар бир же эки компонентти (диск, эстутум же процессор) максималдуу пайдалануу үчүн брокерлерди конфигурациялайт. Жалпысынан алганда, брокер анын конфигурациясы эң жай компонентти толук көлөмдө колдонууга мүмкүндүк бергенде максималдуу өндүрүмдүүлүктү көрсөтөт. Ошентип, биз бир брокер көтөрө ала турган жүк жөнүндө болжолдуу түшүнүк ала алабыз.

Теориялык жактан алганда, биз берилген жүктү көтөрүү үчүн талап кылынган брокерлердин санын да эсептей алабыз. Бирок, иш жүзүндө ар кандай деңгээлдеги конфигурациянын көптөгөн варианттары бар, андыктан белгилүү бир конфигурациянын потенциалдуу иштешин баалоо өтө кыйын (эгер мүмкүн болбосо). Башкача айтканда, кээ бир берилген аткаруунун негизинде конфигурацияны пландаштыруу абдан кыйын.

Supertubes колдонуучулары үчүн биз адатта төмөнкү ыкманы колдонобуз: биз кандайдыр бир конфигурациядан (инфраструктура + орнотуулардан) баштайбыз, андан кийин анын иштешин өлчөйбүз, брокердин жөндөөлөрүн тууралап, процессти кайра кайталайбыз. Бул инфраструктуранын эң жай компоненти толук пайдаланылганга чейин болот.

Ошентип, биз кластерге белгилүү бир жүктү көтөрүү үчүн канча брокерлер керек экендиги жөнүндө так түшүнүк алабыз (брокерлердин саны башка факторлорго да көз каранды, мисалы, ийкемдүүлүктү камсыз кылуу үчүн билдирүү репликаларынын минималдуу саны, бөлүмдөрдүн саны. лидерлер жана башкалар). Мындан тышкары, биз инфраструктуранын кайсы компоненттери вертикалдуу масштабды талап кыларын түшүнөбүз.

Бул макалада баштапкы конфигурациялардагы эң жай компоненттерден максималдуу пайда алуу жана Кафка кластеринин өткөрүү жөндөмдүүлүгүн өлчөө үчүн жасаган кадамдарыбыз жөнүндө сөз болот. Жогорку ийкемдүү конфигурация үчүн кеминде үч иштеп жаткан брокер талап кылынат (min.insync.replicas=3), үч түрдүү жеткиликтүүлүк зонасында бөлүштүрүлгөн. Kubernetes инфраструктурасын конфигурациялоо, масштабдоо жана көзөмөлдөө үчүн биз гибриддик булуттар үчүн өзүбүздүн контейнер башкаруу платформабызды колдонобуз - түтүк. Ал жер-жерлерде (жылаңач металл, VMware) жана булуттардын беш түрүн (Alibaba, AWS, Azure, Google, Oracle), ошондой эле алардын каалаган айкалышын колдойт.

Кафка кластеринин инфраструктурасы жана конфигурациясы жөнүндө ойлор

Төмөндөгү мисалдар үчүн биз булут провайдери катары AWSди жана Kubernetes бөлүштүрүүчүсү катары EKSти тандадык. Окшош конфигурацияны колдонуу менен ишке ашырууга болот П.К.Э. - CNCF тарабынан тастыкталган Banzai Cloud компаниясынан Кубернетес бөлүштүрүү.

диск

Amazon ар кандай сунуштарды берет EBS көлөмүнүн түрлөрү. Өзөгүндө gp2 и io1 жогорку өткөрүү жөндөмдүүлүгүн камсыз кылуу үчүн, бирок, SSD дисктер бар gp2 топтолгон кредиттерди керектейт (I/O кредиттери), ошондуктан биз түрүн артык көрдүк io1, бул ырааттуу жогорку өткөрүү мүмкүнчүлүгүн сунуш кылат.

Мисал түрлөрү

Кафканын иштеши операциялык системанын бет кэшине абдан көз каранды, ошондуктан бизге брокерлер (JVM) жана барак кэш үчүн жетиштүү эстутумга ээ инстанциялар керек. Instance c5.2xlarge - жакшы башталыш, анткени ал 16 ГБ эстутумга ээ жана EBS менен иштөө үчүн оптималдаштырылган. Анын кемчилиги ар бир 30 саатта 24 мүнөттөн ашык эмес максималдуу аткарууну гана камсыз кыла алат. Эгер жумуш жүгүңүз узак убакыт бою эң жогорку аткарууну талап кылса, башка үлгү түрлөрүн карап көргүңүз келет. Биз дал ушундай кылдык, токтоп калдык c5.4xlarge. Бул максималдуу өткөрүү мүмкүнчүлүгүн камсыз кылат 593,75 Мб/сек. EBS көлөмүнүн максималдуу өткөрүү жөндөмдүүлүгү io1 инстанциядан жогору c5.4xlarge, ошондуктан инфраструктуранын эң жай элементи бул инстанция түрүнүн киргизүү/чыгаруу жөндөмдүүлүгү болушу мүмкүн (жүгүн сыноолорубуз да тастыкташы керек).

тармак

Тармактын өткөрүү жөндөмдүүлүгү VM инстанциясынын жана дискинин иштешине салыштырмалуу жетиштүү чоң болушу керек, антпесе тармак тоскоолдукка айланат. Биздин учурда, тармак интерфейси c5.4xlarge 10 Гб/сек ылдамдыгын колдойт, бул VM инстанциясынын киргизүү/чыгаруу жөндөмдүүлүгүнөн кыйла жогору.

Брокерди жайылтуу

CPU, эстутум, тармак жана диск ресурстары үчүн башка процесстер менен атаандашпоо үчүн брокерлерди атайын түйүндөргө жайгаштыруу керек (Кубернетеде пландаштырылган).

Java версиясы

Логикалык тандоо Java 11, анткени ал Docker менен шайкеш келет, анткени JVM брокер иштеп жаткан контейнерде жеткиликтүү процессорлорду жана эстутумду туура аныктайт. CPU чектөөлөрү маанилүү экенин билип, JVM ички жана ачык GC жиптеринин жана JIT жиптеринин санын белгилейт. Биз Кафканын образын колдондук banzaicloud/kafka:2.13-2.4.0Java 2.4.0деги Кафка 2.13 (Scala 11) версиясын камтыйт.

Эгерде сиз Kubernetesтеги Java/JVM жөнүндө көбүрөөк билгиңиз келсе, төмөнкү постторубузду текшериңиз:

• Эмне үчүн менин Java колдонмом OOMKilled;
• Java 10 тиркемелери үчүн контейнерлерди кантип туура өлчөө керек.

Брокердин эстутумунун жөндөөлөрү

Брокердин эс тутумун конфигурациялоонун эки негизги аспектиси бар: JVM жана Kubernetes подъезди үчүн орнотуулар. JVM өз эстутумунда жайгашкан Java мета мейкиндигине жана Кафка активдүү колдонгон операциялык система бетинин кэшине орун берүү үчүн подколь үчүн коюлган эстутум чеги максималдуу үймөк өлчөмүнөн чоң болушу керек. Сыноолорубузда биз параметрлери бар Кафка брокерлерин ишке киргиздик -Xmx4G -Xms2G, жана поддон үчүн эс чеги болгон 10 Gi. JVM үчүн эстутум орнотуулары автоматтык түрдө колдонулушу мүмкүн экенин эске алыңыз -XX:MaxRAMPercentage и -X:MinRAMPercentage, поддон үчүн эстутум чегине негизделген.

Брокер процессорунун жөндөөлөрү

Жалпысынан алганда, сиз Кафка колдонгон жиптердин санын көбөйтүү менен параллелизмди жогорулатуу менен аткарууну жакшыртсаңыз болот. Кафка үчүн процессорлор канчалык көп болсо, ошончолук жакшы. Тестибизде биз 6 процессордун чеги менен баштадык жана бара-бара (итерациялар аркылуу) алардын санын 15ке жеткирдик. Мындан тышкары, биз num.network.threads=12 брокер орнотууларында тармактан маалыматтарды кабыл алган жиптердин санын көбөйтүү жана аны жөнөтүү. Жолдоочу брокерлер репликаларды тез ала албагандыгын дароо таап, алар көтөрүлүштү num.replica.fetchers жолдоочу брокерлер лидерлердин билдирүүлөрүн кайталаган ылдамдыгын жогорулатуу үчүн 4.

Жүктөө түзүү куралы

Кафка кластери (салыштырылып жаткан) максималдуу жүктөмүнө жеткенге чейин тандалган жүк генераторунун кубаттуулугу түгөнүп калбасын камсыздашыңыз керек. Башка сөз менен айтканда, жүк генерациялоо инструментинин мүмкүнчүлүктөрүнө алдын ала баа берүү, ошондой эле ал үчүн жетиштүү сандагы процессорлор жана эс тутум менен инстанциялардын түрлөрүн тандоо керек. Бул учурда биздин курал Кафка кластери көтөрө алгандан да көбүрөөк жүктү чыгарат. Көптөгөн эксперименттерден кийин биз үч нускага чечтик c5.4xlarge, алардын ар биринде генератор иштеп турган.

Бенчмаркинг

Иштин натыйжалуулугун өлчөө төмөнкү этаптарды камтыган кайталануучу процесс:

• инфраструктураны түзүү (EKS кластери, Кафка кластери, жүктөрдү генерациялоо инструменти, ошондой эле Prometheus жана Grafana);
• өндүрүмдүүлүктүн чогултулган көрсөткүчтөрүндөгү кокус четтөөлөрдү чыпкалоо үчүн белгилүү бир мезгилге жүктү түзүү;
• байкалган көрсөткүчтөрдүн негизинде брокердин инфраструктурасын жана конфигурациясын тууралоо;
• Кафка кластеринин өткөрүү жөндөмдүүлүгүнүн керектүү деңгээлине жеткенге чейин процессти кайталоо. Ошол эле учурда, ал ырааттуу кайталанууга жана өткөрүү жөндөмдүүлүгүнүн минималдуу вариацияларын көрсөтүүгө тийиш.

Кийинки бөлүмдө сыноо кластерин салыштыруу процессинде аткарылган кадамдар сүрөттөлөт.

аспаптар

Базалык конфигурацияны тез жайгаштыруу, жүктөрдү түзүү жана өндүрүмдүүлүктү өлчөө үчүн төмөнкү куралдар колдонулган:

• Banzai Cloud Pipeline Amazonдан EKS кластерин уюштуруу үчүн c Prometheus (Кафканы жана инфраструктуралык көрсөткүчтөрдү чогултуу үчүн) жана Графана (бул көрсөткүчтөрдү көрүү үчүн). Биз пайдаландык интеграцияланган в түтүк федеративдүү мониторинг, борборлоштурулган журналдарды чогултуу, аялуу жерлерди сканерлөө, кырсыктан калыбына келтирүү, ишкана деңгээлиндеги коопсуздукту жана башка көптөгөн нерселерди камсыз кылган кызматтар.
• Sangrenel — Кафка кластерин жүктөөнү текшерүү үчүн курал.
• Кафканын көрсөткүчтөрүн жана инфраструктурасын визуалдаштыруу үчүн Grafana панелдери: Кубернетес Кафка, Түйүндү экспорттоочу.
• Kubernetesте Кафка кластерин орнотуунун эң оңой жолу үчүн Supertubes CLI. Zookeeper, Кафка оператору, Элчи жана башка көптөгөн компоненттер орнотулган жана Kubernetes'те өндүрүшкө даяр Кафка кластерин иштетүү үчүн туура конфигурацияланган.
  • Орнотуу үчүн supertubes CLI берилген көрсөтмөлөрдү колдонуу бул жерде.

EKS кластери

атайын жумушчу түйүндөр менен EKS кластерин даярдоо c5.4xlarge Кафка брокерлери менен поддондор үчүн ар кандай жеткиликтүүлүк зоналарында, ошондой эле жүк генератору жана мониторинг инфраструктурасы үчүн атайын түйүндөр.

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

EKS кластери иштеп баштагандан кийин, анын интеграцияланганын иштетиңиз мониторинг кызматы — ал Прометей менен Графананы кластерге жайгаштырат.

Кафка системасынын компоненттери

Supertubes CLI аркылуу EKSге Кафка системасынын компоненттерин (Зоокепер, кафка-оператор) орнотуңуз:

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

Кафка кластери

Демейки боюнча, EKS түрү EBS көлөмүн колдонот gp2, ошондуктан сиз көлөмдөрдүн негизинде өзүнчө сактоо классын түзүшүңүз керек io1 Кафка кластери үчүн:

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

Брокерлер үчүн параметрди коюу min.insync.replicas=3 жана үч түрдүү жеткиликтүүлүк зоналарындагы түйүндөрдө брокер подкасттарын жайгаштырыңыз:

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

Темалар

Биз параллелдүү үч жүк генераторунун инстанциясын иштеттик. Алардын ар бири өз темасына жазат, башкача айтканда, жалпысынан үч тема керек:

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

Ар бир тема үчүн репликация коэффициенти 3 болуп саналат — жогорку жеткиликтүү өндүрүш системалары үчүн сунушталган минималдуу маани.

Жүктөө түзүү куралы

Биз жүк генераторунун үч нускасын ишке киргиздик (ар бири өзүнчө темада жазылган). Жүктөлүүчү генератор поддондору үчүн түйүндөрдүн жакындыгын алар үчүн бөлүнгөн түйүндөрдө гана пландаштыруу керек:

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

Белгилей кетчү бир нече пункттар:

• Жүктөө генератору 512 байт узундуктагы билдирүүлөрдү жаратат жана аларды Кафкага 500 билдирүүлөрдүн партияларында жарыялайт.
• Аргумент колдонуу -required-acks=all Кафка брокерлери билдирүүнүн бардык синхрондуу репликалары кабыл алынганда жана тастыкталганда жарыялоо ийгиликтүү деп эсептелет. Бул эталондо биз лидерлердин билдирүүлөрдү кабыл алуу ылдамдыгын гана эмес, ошондой эле алардын жолдоочуларынын билдирүүлөрдү кайталоосун да өлчөдүк дегенди билдирет. Бул тесттин максаты керектөөчүлөрдүн окуу ылдамдыгын баалоо эмес (керектөөчүлөр) OS баракчасынын кэшинде дагы эле калган жакында кабыл алынган билдирүүлөр жана аны дискте сакталган билдирүүлөрдү окуу ылдамдыгы менен салыштыруу.
• Жүк генератору параллелдүү 20 жумушчуну иштетет (-workers=20). Ар бир жумушчуда жумушчунун Кафка кластерине байланышы бар 5 продюсер бар. Натыйжада ар бир генератордо 100 продюсер бар жана алардын баары Кафка кластерине билдирүү жөнөтүшөт.

Кластердин ден соолугуна мониторинг жүргүзүү

Кафка кластерин жүктөө тестирлөө учурунда, биз анын ден соолугуна да мониторинг жүргүзүп, поддонду өчүрүп күйгүзүү, синхрондоштуруудан тышкары репликалар жана минималдуу термелүүлөр менен максималдуу өткөрүү мүмкүнчүлүгүн текшердик:

• Жүктөө генератору жарыяланган билдирүүлөрдүн саны жана ката ылдамдыгы жөнүндө стандарттык статистиканы жазат. Ката деңгээли ошол эле бойдон калууга тийиш 0,00%.
• Круиз контролу, kafka-оператор тарабынан жайгаштырылган, биз ошондой эле кластердин абалын көзөмөлдөй турган башкаруу тактасын камсыз кылат. Бул панелди көрүү үчүн:

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

• ISR деңгээли («синхрондогон» репликалардын саны) кичирейүү жана кеңейүү 0гө барабар.

Өлчөө натыйжалары

3 брокерлер, билдирүү көлөмү - 512 байт

Бөлүмдөр үч брокерге бирдей бөлүштүрүлгөндүктөн, биз өндүрүмдүүлүккө жетише алдык ~500 Mb/s (болжол менен секундасына 990 миң билдирүү):

JVM виртуалдык машинасынын эстутум керектөөсү 2 ГБ ашкан эмес:

Дисктин өткөрүү жөндөмдүүлүгү брокерлер иштеп жаткан бардык үч инстанциядагы киргизүү/чыгаруу түйүнүнүн максималдуу өтүмдүүлүгүнө жетти:

Түйүндөр боюнча эстутумдун колдонулушу боюнча маалыматтардан системанын буферлөө жана кэштөө ~10-15 ГБ талап кылынганын көрүүгө болот:

3 брокерлер, билдирүү көлөмү - 100 байт

Кабардын көлөмү азайган сайын өткөрүү жөндөмдүүлүгү болжол менен 15-20% төмөндөйт: ар бир билдирүүнү иштетүүгө кеткен убакыт ага таасир этет. Мындан тышкары, процессордун жүктөмү дээрлик эки эсеге өстү.

Брокер түйүндөрүндө дагы эле пайдаланылбаган өзөктөр бар болгондуктан, Кафканын конфигурациясын өзгөртүү менен иштөөнү жакшыртууга болот. Бул оңой иш эмес, андыктан өткөрүү жөндөмдүүлүгүн жогорулатуу үчүн чоңураак билдирүүлөр менен иштөө жакшы.

4 брокерлер, билдирүү көлөмү - 512 байт

Сиз жөн гана жаңы брокерлерди кошуу жана бөлүмдөрдүн балансын сактоо менен Кафка кластеринин иштешин оңой көтөрө аласыз (бул жүктүн брокерлердин ортосунда бирдей бөлүштүрүлүшүн камсыздайт). Биздин учурда, брокерди кошкондон кийин, кластердин өткөрүү жөндөмдүүлүгү көбөйдү ~580 Mb/s (~1,1 миллион билдирүү секундасына). Өсүш күтүлгөндөн аз болуп чыкты: бул негизинен бөлүмдөрдүн дисбаланс менен түшүндүрүлөт (бардык брокерлер өз мүмкүнчүлүктөрүнүн туу чокусунда иштешпейт).

JVM машинасынын эстутум керектөө 2 ГБ төмөн бойдон калды:

Дисктери бар брокерлердин ишине бөлүмдөрдүн тең салмаксыздыгы таасир эткен:

табылгалары

Жогоруда келтирилген итеративдик ыкма жүздөгөн керектөөчүлөрдү камтыган татаал сценарийлерди камтуу үчүн кеңейтилиши мүмкүн, кайра бөлүштүрүү, жаңыртууларды жаңыртуу, поддонду өчүрүү ж.б. Мунун баары ар кандай шарттарда Кафка кластеринин мүмкүнчүлүктөрүнүн чегин баалоого, анын ишиндеги тоскоолдуктарды аныктоого жана алар менен күрөшүүнүн жолдорун табууга мүмкүндүк берет.

Биз Supertubes кластерин тез жана оңой жайгаштыруу, аны конфигурациялоо, брокерлерди жана темаларды кошуу/алып салуу, эскертүүлөргө жооп берүү жана жалпысынан Кафканын Кубернетесте туура иштешин камсыз кылуу үчүн иштеп чыктык. Биздин максат – негизги тапшырмага көңүлүңүздү бурууга (“Кафка билдирүүлөрүн түзүү” жана “керектөө”) жардам берүү жана бардык оор ишти Supertubes менен Кафка операторуна тапшыруу.

Эгерде сизди Banzai Cloud технологиялары жана Open Source долбоорлору кызыктырса, анда компанияга жазылыңыз GitHub, LinkedIn же Twitter.

Котормочудан PS

Биздин блогдон дагы окуңуз:

• «K8sдеги Redis оператору менен бир окуя жана бул маалымат базасынан маалыматтарды талдоо үчүн утилиталардын мини-серепи";
• «RabbitMQнын Kubernetesке үзгүлтүксүз миграциясы";
• «CoreOS ичинен zetcd: ZooKeeperди... etcd сактагычына алмаштыруу«.

Source: www.habr.com