{"id":71213,"date":"2020-02-24T16:09:17","date_gmt":"2020-02-24T13:09:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes"},"modified":"2020-03-03T16:14:29","modified_gmt":"2020-03-03T13:14:29","slug":"opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes","title":{"rendered":"Definindo o tamanho adequado para um cluster Kafka no Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota do tradutor.<\/b>: Neste artigo, a Banzai Cloud compartilha um exemplo do uso de suas ferramentas especiais para facilitar a opera\u00e7\u00e3o do Kafka dentro do Kubernetes. As instru\u00e7\u00f5es apresentadas ilustram como determinar o tamanho ideal da infraestrutura e configurar o pr\u00f3prio Kafka para alcan\u00e7ar a capacidade de throughput desejada.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/8a598ec7db091c2944a6442f9bc124da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nApache Kafka \u00e9 uma plataforma de streaming distribu\u00edda para construir sistemas de processamento de dados em tempo real que s\u00e3o confi\u00e1veis, escal\u00e1veis e de alto desempenho. Suas impressionantes capacidades podem ser ampliadas com o Kubernetes. Para isso, desenvolvemos <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\/kafka-operator\">o operador Kafka de c\u00f3digo aberto<\/a><\/noindex> e uma ferramenta chamada <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/supertubes\/overview\/\">Supertubes<\/a><\/noindex>. Elas permitem executar o Kafka no Kubernetes e usar v\u00e1rias de suas funcionalidades, como ajuste fino da configura\u00e7\u00e3o do broker, escalonamento baseado em m\u00e9tricas com rebalanceamento, consci\u00eancia sobre rack (rack awareness), rollout de atualiza\u00e7\u00f5es de forma <i>(graciosa)<\/i> , etc.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<blockquote><p>Experimente o Supertubes em seu cluster:<\/p>\n<pre><code class=\"bash\">curl https:\/\/getsupertubes.sh | sh e supertubes install -a --no-democluster --kubeconfig<\/code><\/pre>\n<p>\nOu entre em contato com <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/supertubes\/cli\/reference\/\">documenta\u00e7\u00e3o<\/a><\/noindex>. Tamb\u00e9m \u00e9 poss\u00edvel ler sobre algumas funcionalidades do Kafka, cujo funcionamento foi automatizado com o uso do Supertubes e do operador Kafka. J\u00e1 escrevemos sobre isso no blog:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-operator\/\">Oh n\u00e3o! Mais um operador Kafka para Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-alert\/\">Monitore e opere o Kafka com base nas m\u00e9tricas do Prometheus<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-rack-awareness\/\">Consci\u00eancia sobre rack do Kafka no Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-on-istio-performance\/\">Executando Apache Kafka sobre Istio \u2014 benchmark<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-topic-user-management\/\">Clusters autenticados e controlados por acesso com o operador Kafka<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-rolling-upgrade\/\">Atualiza\u00e7\u00e3o cont\u00ednua do Kafka e configura\u00e7\u00e3o din\u00e2mica no Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-envoy-protocol-filter\/\">Filtro de protocolo Envoy para Kafka, mesclado<\/a><\/noindex>.<\/li>\n<\/ul>\n<\/blockquote>\n<p>\nAo decidir implantar um cluster Kafka no Kubernetes, voc\u00ea seguramente enfrentar\u00e1 o desafio de determinar o tamanho ideal da infraestrutura b\u00e1sica e a necessidade de ajustar a configura\u00e7\u00e3o do Kafka para atender aos requisitos de throughput. O m\u00e1ximo desempenho de cada broker \u00e9 definido pelo desempenho dos componentes da infraestrutura subjacente, como mem\u00f3ria, processador, velocidade do disco, largura de banda da rede, etc.<\/p>\n<p>Idealmente, a configura\u00e7\u00e3o do broker deve ser tal que todos os elementos da infraestrutura sejam utilizados ao m\u00e1ximo de suas capacidades. No entanto, na vida real, essa configura\u00e7\u00e3o \u00e9 bastante complexa. \u00c9 mais prov\u00e1vel que os usu\u00e1rios ajustem a configura\u00e7\u00e3o dos brokers de forma a maximizar o uso de um ou dois componentes (disco, mem\u00f3ria ou processador). Em geral, um broker mostra desempenho m\u00e1ximo quando sua configura\u00e7\u00e3o permite explorar ao m\u00e1ximo o componente mais lento. Assim, podemos ter uma ideia do tipo de carga que um \u00fanico broker pode suportar.<\/p>\n<p>Teoricamente, tamb\u00e9m podemos estimar o n\u00famero de brokers necess\u00e1rios para lidar com uma carga espec\u00edfica. No entanto, na pr\u00e1tica, as op\u00e7\u00f5es de configura\u00e7\u00e3o em diferentes n\u00edveis s\u00e3o tantas que avaliar o desempenho potencial de uma configura\u00e7\u00e3o espec\u00edfica \u00e9 bastante dif\u00edcil (se n\u00e3o imposs\u00edvel). Em outras palavras, \u00e9 muito complicado planejar uma configura\u00e7\u00e3o com base em um desempenho desejado.<\/p>\n<p>Para os usu\u00e1rios do Supertubes, geralmente adotamos a seguinte abordagem: come\u00e7amos com uma configura\u00e7\u00e3o (infraestrutura + ajustes), medimos seu desempenho, ajustamos as configura\u00e7\u00f5es do broker e repetimos o processo. Isso continua at\u00e9 que o potencial do componente mais lento da infraestrutura seja totalmente utilizado.<\/p>\n<p>Dessa forma, conseguimos ter uma ideia mais clara de quantos brokers o cluster precisa para lidar com uma carga espec\u00edfica (o n\u00famero de brokers tamb\u00e9m depende de outros fatores, como o n\u00famero m\u00ednimo de r\u00e9plicas de mensagens para garantir a resili\u00eancia, o n\u00famero de l\u00edderes de parti\u00e7\u00e3o, etc.). Al\u00e9m disso, obtemos uma compreens\u00e3o de qual componente de infraestrutura \u00e9 desej\u00e1vel para escalonamento vertical.<\/p>\n<p>Neste artigo, falaremos sobre as etapas que tomamos para \"extrair o m\u00e1ximo\" dos componentes mais lentos nas configura\u00e7\u00f5es iniciais e medir a largura de banda do cluster Kafka. Uma configura\u00e7\u00e3o de alta resili\u00eancia requer pelo menos tr\u00eas brokers em funcionamento (<code>min.insync.replicas=3<\/code>), distribu\u00eddos em tr\u00eas zonas de disponibilidade diferentes. Para configura\u00e7\u00e3o, escalabilidade e monitoramento da infraestrutura do Kubernetes, utilizamos nossa pr\u00f3pria plataforma de gerenciamento de cont\u00eaineres para nuvens h\u00edbridas \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\/pipeline\">Pipeline<\/a><\/noindex>. Ela suporta on-premise (bare metal, VMware) e cinco tipos de nuvens (Alibaba, AWS, Azure, Google, Oracle), al\u00e9m de qualquer combina\u00e7\u00e3o delas.<\/p>\n<h2>Reflex\u00f5es sobre a infraestrutura e a configura\u00e7\u00e3o do cluster Kafka<\/h2>\n<p>\nPara os exemplos abaixo, escolhemos a AWS como fornecedor de servi\u00e7os de nuvem e o EKS como a distribui\u00e7\u00e3o do Kubernetes. Uma configura\u00e7\u00e3o semelhante pode ser realizada usando <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\/pke\">PKE<\/a><\/noindex> \u2014 uma distribui\u00e7\u00e3o do Kubernetes da Banzai Cloud, certificada pela CNCF.<\/p>\n<h3>Disco<\/h3>\n<p>\nA Amazon oferece diferentes <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.aws.amazon.com\/AWSEC2\/latest\/UserGuide\/ebs-volume-types.html\">tipos de volumes EBS<\/a><\/noindex>. A base <i>gp2<\/i> e <i>io1<\/i> consiste em discos SSD, no entanto, para garantir alta taxa de transfer\u00eancia <i>gp2<\/i> consome cr\u00e9ditos acumulados <i>(- I\/O credits)<\/i>, por isso preferimos o tipo <i>io1<\/i>, que oferece alta taxa de transfer\u00eancia est\u00e1vel.<\/p>\n<h3>Tipos de inst\u00e2ncias<\/h3>\n<p>\nO desempenho do Kafka depende muito do cache de p\u00e1gina do sistema operacional, portanto, precisamos de inst\u00e2ncias com mem\u00f3ria suficiente para os brokers (JVM) e cache de p\u00e1gina. A inst\u00e2ncia <i>c5.2xlarge<\/i> \u00e9 um bom come\u00e7o, pois possui 16 GB de mem\u00f3ria e <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.aws.amazon.com\/AWSEC2\/latest\/UserGuide\/ebs-optimized.html\">\u00e9 otimizada para trabalhar com EBS<\/a><\/noindex>. Sua desvantagem \u00e9 que consegue fornecer desempenho m\u00e1ximo por no m\u00e1ximo 30 minutos a cada 24 horas. Se a carga de trabalho exigir desempenho m\u00e1ximo por mais tempo, devemos considerar outros tipos de inst\u00e2ncias. Foi exatamente isso que fizemos, optando por <i>c5.4xlarge<\/i>. Ela oferece uma taxa de transfer\u00eancia m\u00e1xima de <b>593,75 MB\/s<\/b>. A taxa de transfer\u00eancia m\u00e1xima do volume EBS <i>io1<\/i> \u00e9 superior \u00e0 da inst\u00e2ncia <i>c5.4xlarge<\/i>, portanto, o elemento mais lento da infraestrutura, aparentemente, \u00e9 a taxa de transfer\u00eancia de I\/O desse tipo de inst\u00e2ncia (o que tamb\u00e9m deve ser confirmado pelos resultados de nossos testes de carga).<\/p>\n<h3>Rede<\/h3>\n<p>\nA largura de banda da rede deve ser suficientemente alta em compara\u00e7\u00e3o ao desempenho da inst\u00e2ncia VM e do disco; do contr\u00e1rio, a rede se torna um gargalo. No nosso caso, a interface de rede <i>c5.4xlarge<\/i> suporta uma velocidade de at\u00e9 10 Gb\/s, o que \u00e9 significativamente superior \u00e0 taxa de transfer\u00eancia de I\/O da inst\u00e2ncia VM.<\/p>\n<h3>Desdobramento dos brokers<\/h3>\n<p>\nOs brokers devem ser implantados (planejados no Kubernetes) em n\u00f3s dedicados para evitar competi\u00e7\u00e3o com outros processos por recursos de CPU, mem\u00f3ria, rede e disco.<\/p>\n<h3>Vers\u00e3o do Java<\/h3>\n<p>\nA escolha l\u00f3gica \u00e9 o Java 11, pois ele \u00e9 compat\u00edvel com Docker na medida em que a JVM identifica corretamente os processadores e a mem\u00f3ria dispon\u00edveis para o cont\u00eainer em que o broker est\u00e1 sendo executado. Sabendo que os limites de CPU s\u00e3o importantes, a JVM define internamente e de forma transparente o n\u00famero de threads do GC e threads do compilador JIT. Utilizamos a imagem Kafka <code>banzaicloud\/kafka:2.13-2.4.0<\/code>, incluindo a vers\u00e3o Kafka 2.4.0 (Scala 2.13) em Java 11.<\/p>\n<blockquote><p>Se voc\u00ea deseja saber mais sobre Java\/JVM no Kubernetes, confira nossas publica\u00e7\u00f5es:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/java-resource-limits\/\">Por que meu aplicativo Java est\u00e1 OOMKilled<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/java10-container-sizing\/\">Como dimensionar corretamente cont\u00eaineres para aplicativos Java 10<\/a><\/noindex>.<\/li>\n<\/ul>\n<\/blockquote>\n<p><\/p>\n<h3>Configura\u00e7\u00f5es de mem\u00f3ria do broker<\/h3>\n<p>\nExistem dois aspectos principais na configura\u00e7\u00e3o da mem\u00f3ria do broker: as configura\u00e7\u00f5es para a JVM e para o pod do Kubernetes. O limite de mem\u00f3ria definido para o pod deve ser maior do que o tamanho m\u00e1ximo do heap, para que a JVM tenha espa\u00e7o suficiente para o metasp\u00e7o Java, que est\u00e1 na sua pr\u00f3pria mem\u00f3ria, e para o cache de p\u00e1ginas do sistema operacional, que o Kafka utiliza ativamente. Em nossos testes, executamos brokers Kafka com os par\u00e2metros <code>-Xmx4G -Xms2G<\/code>, e o limite de mem\u00f3ria para o pod era <code>10 Gi<\/code>. Note que as configura\u00e7\u00f5es de mem\u00f3ria para a JVM podem ser obtidas automaticamente com <code>-XX:MaxRAMPercentage<\/code> e <code>-X:MinRAMPercentage<\/code>, com base no limite de mem\u00f3ria para o pod.<\/p>\n<h3>Configura\u00e7\u00f5es de CPU do broker<\/h3>\n<p>\nDe modo geral, \u00e9 poss\u00edvel aumentar o desempenho aumentando o paralelismo com o aumento do n\u00famero de threads utilizadas pelo Kafka. Quanto mais processadores dispon\u00edveis para o Kafka, melhor. Em nosso teste, come\u00e7amos com um limite de 6 processadores e, gradualmente (em itera\u00e7\u00f5es), aumentamos esse n\u00famero para 15. Al\u00e9m disso, configuramos <code>num.network.threads=12<\/code> nas configura\u00e7\u00f5es do broker, para aumentar o n\u00famero de threads que recebem dados da rede e os enviam. Imediatamente percebemos que os brokers seguidores n\u00e3o conseguiam replicar as mensagens rapidamente o suficiente, ent\u00e3o aumentamos <code>num.replica.fetchers<\/code> para 4, a fim de aumentar a velocidade com que os brokers seguidores replicavam mensagens dos l\u00edderes.<\/p>\n<h3>Ferramenta de gera\u00e7\u00e3o de carga<\/h3>\n<p>\n\u00c9 importante garantir que o potencial do gerador de carga escolhido n\u00e3o se esgote antes que o cluster Kafka (cujo benchmark est\u00e1 sendo realizado) atinja sua carga m\u00e1xima. Em outras palavras, \u00e9 necess\u00e1rio fazer uma avalia\u00e7\u00e3o pr\u00e9via das capacidades da ferramenta de gera\u00e7\u00e3o de carga, al\u00e9m de escolher inst\u00e2ncias com um n\u00famero adequado de processadores e mem\u00f3ria. Com isso, nossa ferramenta gerar\u00e1 mais carga do que o cluster Kafka consegue suportar. Ap\u00f3s muitos experimentos, escolhemos tr\u00eas inst\u00e2ncias <i>c5.4xlarge<\/i>, em cada uma das quais foi iniciado um gerador.<\/p>\n<h2>Benchmarking<\/h2>\n<p>\nA medi\u00e7\u00e3o de desempenho \u00e9 um processo iterativo que inclui as seguintes etapas:<\/p>\n<ul>\n<li> configura\u00e7\u00e3o da infraestrutura (cluster EKS, cluster Kafka, ferramenta de gera\u00e7\u00e3o de carga, al\u00e9m de Prometheus e Grafana);<\/li>\n<li> gera\u00e7\u00e3o de carga por um determinado per\u00edodo para filtrar varia\u00e7\u00f5es aleat\u00f3rias nas m\u00e9tricas de desempenho coletadas;<\/li>\n<li> ajuste da infraestrutura e da configura\u00e7\u00e3o do broker com base nas m\u00e9tricas de desempenho observadas;<\/li>\n<li> repeti\u00e7\u00e3o do processo at\u00e9 que o n\u00edvel desejado de throughput do cluster Kafka seja alcan\u00e7ado. Este deve ser reproduc\u00edvel de forma est\u00e1vel e demonstrar varia\u00e7\u00f5es m\u00ednimas no throughput.<\/li>\n<\/ul>\n<p>\nNa pr\u00f3xima se\u00e7\u00e3o, descrevemos as etapas realizadas durante o benchmarking do cluster de teste.<\/p>\n<h3>Ferramentas<\/h3>\n<p>\nPara uma r\u00e1pida implementa\u00e7\u00e3o da configura\u00e7\u00e3o b\u00e1sica, gera\u00e7\u00e3o de carga e medi\u00e7\u00e3o de desempenho, foram utilizadas as seguintes ferramentas:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/pipeline\/overview\/\">Banzai Cloud Pipeline<\/a><\/noindex> para a organiza\u00e7\u00e3o do cluster EKS da Amazon com <noindex><a rel=\"nofollow\" href=\"https:\/\/prometheus.io\/\">Prometheus<\/a><\/noindex> (para coleta de m\u00e9tricas do Kafka e da infraestrutura) e <noindex><a rel=\"nofollow\" href=\"https:\/\/grafana.com\/\">Grafana<\/a><\/noindex> (para visualiza\u00e7\u00e3o dessas m\u00e9tricas). Utilizamos <b>servi\u00e7os integrados<\/b> em <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\/pipeline\">Pipeline<\/a><\/noindex> que oferecem monitoramento federado, coleta centralizada de logs, varredura de vulnerabilidades, recupera\u00e7\u00e3o de desastres, seguran\u00e7a de n\u00edvel corporativo e muito mais.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/jamiealquiza\/sangrenel\">Sangrenel<\/a><\/noindex> \u00e9 uma ferramenta para testes de carga do cluster Kafka.<\/li>\n<li> Pain\u00e9is Grafana para visualiza\u00e7\u00e3o das m\u00e9tricas do Kafka e da infraestrutura: <noindex><a rel=\"nofollow\" href=\"https:\/\/grafana.com\/grafana\/dashboards\/10123\">Kubernetes Kafka<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/grafana.com\/grafana\/dashboards\/1860\">Node Exporter<\/a><\/noindex>.<\/li>\n<li> Supertubes CLI para a configura\u00e7\u00e3o mais simples de um cluster Kafka no Kubernetes. Zookeeper, Kafka operator, Envoy e muitos outros componentes s\u00e3o instalados e corretamente configurados para executar um cluster Kafka pronto para produ\u00e7\u00e3o no Kubernetes.\n<ul>\n<li> Para a instala\u00e7\u00e3o <i>supertubes CLI<\/i> siga as instru\u00e7\u00f5es fornecidas <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/supertubes\/cli\/install\/\">aqui<\/a><\/noindex>.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/23ecf423b1ea66813406943ae7eabf61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Cluster EKS<\/h3>\n<p>\nPrepare o cluster EKS com n\u00f3s de trabalho dedicados <i>c5.4xlarge<\/i> em diferentes zonas de disponibilidade para os pods com brokers Kafka, assim como n\u00f3s dedicados para o gerador de carga e a infraestrutura de monitoramento.<\/p>\n<pre><code class=\"bash\">banzai cluster create -f https:\/\/raw.githubusercontent.com\/banzaicloud\/kafka-operator\/master\/docs\/benchmarks\/infrastructure\/cluster_eks_202001.json<\/code><\/pre>\n<p>\nQuando o cluster EKS estiver funcionando, ative o seu <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/pipeline\/features\/integrated-services\/\">servi\u00e7o de monitoramento<\/a><\/noindex> \u2014 ele implantar\u00e1 o Prometheus e o Grafana no cluster.<\/p>\n<h3>Componentes do Kafka<\/h3>\n<p>\nInstale os componentes do Kafka (Zookeeper, kafka-operator) no EKS usando o supertubes CLI:<\/p>\n<pre><code class=\"bash\">supertubes install -a --no-democluster --kubeconfig<\/code><\/pre>\n<p><\/p>\n<h3>Cluster Kafka<\/h3>\n<p>\nPor padr\u00e3o, EKS utiliza volumes EBS do tipo <i>gp2<\/i>, portanto, \u00e9 necess\u00e1rio criar uma classe de armazenamento separada baseada em volumes <i>io1<\/i> para o cluster Kafka:<\/p>\n<pre><code class=\"plaintext\">kubectl create -f - &lt;&lt;EOF\napiVersion: storage.k8s.io\/v1\nkind: StorageClass\nmetadata:\n  name: fast-ssd\nprovisioner: kubernetes.io\/aws-ebs\nparameters:\n  type: io1\n  iopsPerGB: &quot;50&quot;\n  fsType: ext4\nvolumeBindingMode: WaitForFirstConsumer\nEOF<\/code><\/pre>\n<p>\nDefina para os brokers o par\u00e2metro <code>min.insync.replicas=3<\/code> e implante os pods dos brokers em n\u00f3s em tr\u00eas zonas de disponibilidade diferentes:<\/p>\n<pre><code class=\"bash\">supertubes cluster create -n kafka --kubeconfig  -f https:\/\/raw.githubusercontent.com\/banzaicloud\/kafka-operator\/master\/docs\/benchmarks\/infrastructure\/kafka_202001_3brokers.yaml --wait --timeout 600<\/code><\/pre>\n<p><\/p>\n<h3>T\u00f3picos<\/h3>\n<p>\nExecutamos paralelamente tr\u00eas inst\u00e2ncias do gerador de carga. Cada uma delas grava em seu pr\u00f3prio t\u00f3pico, ou seja, precisamos de tr\u00eas t\u00f3picos no total:<\/p>\n<pre><code class=\"bash\">supertubes cluster topic create -n kafka --kubeconfig  -f -&lt;&lt;EOF\napiVersion: kafka.banzaicloud.io\/v1alpha1\nkind: KafkaTopic\nmetadata:\n  name: perftest1\nspec:\n  name: perftest1\n  partitions: 12\n  replicationFactor: 3\n  retention.ms: &#039;28800000&#039;\n  cleanup.policy: delete\nEOF\n\nsupertubes cluster topic create -n kafka --kubeconfig  -f -&lt;&lt;EOF\napiVersion: kafka.banzaicloud.io\/v1alpha1\nkind: KafkaTopic\nmetadata:\n    name: perftest2\nspec:\n  name: perftest2\n  partitions: 12\n  replicationFactor: 3\n  retention.ms: &#039;28800000&#039;\n  cleanup.policy: delete\nEOF\n\nsupertubes cluster topic create -n kafka --kubeconfig  -f -&lt;&lt;EOF\napiVersion: kafka.banzaicloud.io\/v1alpha1\nkind: KafkaTopic\nmetadata:\n  name: perftest3\nspec:\n  name: perftest3\n  partitions: 12\n  replicationFactor: 3\n  retention.ms: &#039;28800000&#039;\n  cleanup.policy: delete\nEOF<\/code><\/pre>\n<p>\nPara cada t\u00f3pico, o fator de replica\u00e7\u00e3o \u00e9 3 \u2014 o valor m\u00ednimo recomendado para sistemas de produ\u00e7\u00e3o de alta disponibilidade.<\/p>\n<h3>Ferramenta de gera\u00e7\u00e3o de carga<\/h3>\n<p>\nExecutamos tr\u00eas inst\u00e2ncias do gerador de carga (cada uma escrevendo em um t\u00f3pico separado). Para os pods do gerador de carga, \u00e9 necess\u00e1rio definir a afinidade do n\u00f3, para que eles sejam programados apenas nos n\u00f3s dedicados a eles:<\/p>\n<pre><code class=\"plaintext\">apiVersion: extensions\/v1beta1\nkind: Deployment\nmetadata:\n  labels:\n    app: loadtest\n  name: perf-load1\n  namespace: kafka\nspec:\n  progressDeadlineSeconds: 600\n  replicas: 1\n  revisionHistoryLimit: 10\n  selector:\n    matchLabels:\n      app: loadtest\n  strategy:\n    rollingUpdate:\n      maxSurge: 25%\n      maxUnavailable: 25%\n    type: RollingUpdate\n  template:\n    metadata:\n      creationTimestamp: null\n      labels:\n        app: loadtest\n    spec:\n      affinity:\n        nodeAffinity:\n          requiredDuringSchedulingIgnoredDuringExecution:\n            nodeSelectorTerms:\n            - matchExpressions:\n              - key: nodepool.banzaicloud.io\/name\n                operator: In\n                values:\n                - loadgen\n      containers:\n      - args:\n        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092\n        - -topic=perftest1\n        - -required-acks=all\n        - -message-size=512\n        - -workers=20\n        image: banzaicloud\/perfload:0.1.0-blog\n        imagePullPolicy: Always\n        name: sangrenel\n        resources:\n          limits:\n            cpu: 2\n            memory: 1Gi\n          requests:\n            cpu: 2\n            memory: 1Gi\n        terminationMessagePath: \/dev\/termination-log\n        terminationMessagePolicy: File\n      dnsPolicy: ClusterFirst\n      restartPolicy: Always\n      schedulerName: default-scheduler\n      securityContext: {}\n      terminationGracePeriodSeconds: 30<\/code><\/pre>\n<p>\nAlguns pontos a serem observados:<\/p>\n<ul>\n<li> O gerador de carga gera mensagens de 512 bytes e as publica no Kafka em lotes de 500 mensagens.<\/li>\n<li> Com o argumento <code>-required-acks=all<\/code> a publica\u00e7\u00e3o \u00e9 considerada bem-sucedida quando todas as r\u00e9plicas sincronizadas da mensagem s\u00e3o recebidas e confirmadas pelos brokers do Kafka. Isso significa que, no benchmark, medimos n\u00e3o apenas a velocidade dos l\u00edderes que recebem mensagens, mas tamb\u00e9m a de seus seguidores, que replicam as mensagens. O prop\u00f3sito deste teste n\u00e3o \u00e9 avaliar a velocidade de leitura dos consumidores <i>(consumers)<\/i> de mensagens rec\u00e9m-recebidas, que ainda permanecem no cache de p\u00e1ginas do SO, e sua compara\u00e7\u00e3o com a velocidade de leitura das mensagens armazenadas no disco.<\/li>\n<li> O gerador de carga executa simultaneamente 20 workers (<code>-workers=20<\/code>). Cada worker cont\u00e9m 5 producers, que compartilham a conex\u00e3o do worker com o cluster Kafka. Assim, cada gerador conta com 100 producers, todos enviando mensagens para o cluster Kafka.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Monitoramento do estado do cluster<\/h3>\n<p>\nDurante os testes de carga do cluster Kafka, tamb\u00e9m monitoramos sua sa\u00fade, para garantir que n\u00e3o houvesse reinicializa\u00e7\u00f5es de pods, r\u00e9plicas desincronizadas e que a capacidade m\u00e1xima fosse alcan\u00e7ada com m\u00ednimas flutua\u00e7\u00f5es:<\/p>\n<ul>\n<li> O gerador de carga registra estat\u00edsticas padr\u00e3o sobre o n\u00famero de mensagens publicadas e o n\u00edvel de erros. A porcentagem de erros deve permanecer em <code>0,00%<\/code>.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/linkedin\/cruise-control\">Cruise Control<\/a><\/noindex>, o kafka-operator implementado fornece um painel de monitoramento, onde tamb\u00e9m podemos observar o estado do cluster. Para visualizar este painel, execute:\n<pre><code class=\"bash\">supertubes cluster cruisecontrol show -n kafka --kubeconfig<\/code><\/pre>\n<\/li>\n<li> N\u00edvel de ISR <i>(n\u00famero de r\u00e9plicas \"in-sync\")<\/i> shrink e expansion s\u00e3o iguais a 0.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Resultados das medi\u00e7\u00f5es<\/h2>\n<p><\/p>\n<h3>3 brokers, tamanho das mensagens \u2014 512 bytes<\/h3>\n<p>\nCom as partitions distribu\u00eddas uniformemente entre tr\u00eas brokers, conseguimos alcan\u00e7ar um desempenho <i>~500 Mb\/s (aproximadamente 990 mil mensagens por segundo)<\/i>:<\/p>\n<p><img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/df65ff6a1a26e28d5e5a7a5ab1a20d98.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/15c5883c0056c651f0a0bd14e9991967.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/9b708fa5ce809b0d059cba9f5edfbb2f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO consumo de mem\u00f3ria pela JVM n\u00e3o excedeu 2 Gb:<\/p>\n<p><img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/3320e2eea891055cc0935da492d18ee9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/6e3976c310309aa8be45fa3fdf547750.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/94baa1b689ae854693fb7cc4ed6e105e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA capacidade de throughput do disco atingiu a capacidade m\u00e1xima de I\/O do n\u00f3 em todas as tr\u00eas inst\u00e2ncias onde os brokers estavam funcionando:<\/p>\n<p><img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/408139ad33cda1294755660df1c128a8.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/391d2df0ddfe82f94abdb200370ff775.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/e7e9fd021a2cdc71992ce672363a78ec.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDos dados sobre o uso de mem\u00f3ria pelos n\u00f3s, pode-se observar que o buffering do sistema e caching ocuparam cerca de 10-15 Gb:<\/p>\n<p><img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/781887507e01a4903b86871961ff9260.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/63f10177f01342039f04192ea93c8bca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/48b992cc73a968b3d3b1442f96562c4e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>3 brokers, tamanho das mensagens \u2014 100 bytes<\/h3>\n<p>\nCom a redu\u00e7\u00e3o no tamanho das mensagens, a capacidade de throughput cai cerca de 15-20%: impacta o tempo gasto no processamento de cada mensagem. Al\u00e9m disso, a carga no CPU aumentou quase duas vezes.<\/p>\n<p><img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/2f7dc5a94da371cfe17c9e0fc0ec1941.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/986160a3a4e099a0dbb8aeefaf6f1c2f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/c08244457bf4dbfadf52838d4ea2969e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nComo ainda h\u00e1 n\u00facleos n\u00e3o utilizados nos n\u00f3s dos brokers, a performance pode ser melhorada ajustando a configura\u00e7\u00e3o do Kafka. Esta \u00e9 uma tarefa complexa, portanto, para aumentar a capacidade de throughput, \u00e9 melhor trabalhar com mensagens de maior tamanho.<\/p>\n<h3>4 brokers, tamanho das mensagens \u2014 512 bytes<\/h3>\n<p>\n\u00c9 f\u00e1cil aumentar o desempenho do cluster Kafka simplesmente adicionando novos brokers e mantendo o equil\u00edbrio das partitions (isso garante uma distribui\u00e7\u00e3o uniforme da carga entre os brokers). No nosso caso, ap\u00f3s adicionar um broker, a capacidade do cluster aumentou para <i>~580 Mb\/s (~1,1 milh\u00e3o de mensagens por segundo)<\/i>. O aumento foi menor do que o esperado: isso \u00e9 principalmente explicado pelo desequil\u00edbrio das partitions (nem todos os brokers est\u00e3o operando em sua capacidade m\u00e1xima).<\/p>\n<p><img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/8c8d2e70739add3c3f88fe42acf98c46.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/a6e4812270c04487de0ad39b996a13f8.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/6162c04cfb87b9d9cd0f3147a4ae1647.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/dae5de3b14be212c679f3627a3b77d7b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO consumo de mem\u00f3ria da m\u00e1quina JVM permaneceu abaixo de 2 GB:<\/p>\n<p><img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/0bca07a817d7da3104b08de10979f049.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/7e1e64f80ec140f13e171cfe3be930ce.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/5e9700b1e54e45f9cd5fa018ec07dba1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/4ba0c4b59bfe72bcb0d2f22056c47d79.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO desempenho dos brokers com armazenamento foi afetado pelo desequil\u00edbrio das partitions:<\/p>\n<p><img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/2b8ed3c21adf70c751d1daa6d4c41895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/77b980869b99903d9de5cd7d43d79291.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/f2f9569a3a1ef0ce35e89b2e52e4a8b2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definindo o tamanho adequado para um cluster Kafka no Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/191d6d97b32b2128c5cfd3914171de15.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Como resultado, obtemos um servi\u00e7o de \"monitoramento como servi\u00e7o\", automatizado na linha de produ\u00e7\u00e3o de integra\u00e7\u00e3o cont\u00ednua. O desenvolvedor ou testador precisa apenas definir a lista de m\u00e9tricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lan\u00e7amentos: todas as notifica\u00e7\u00f5es sobre desempenho, consumo de recursos ou regress\u00f5es arquitet\u00f4nicas.<\/h2>\n<p>\nA abordagem iterativa apresentada acima pode ser expandida para abranger cen\u00e1rios mais complexos, envolvendo centenas de consumers, reparticionamento, atualiza\u00e7\u00f5es em camadas, reinicializa\u00e7\u00f5es de pods, etc. Tudo isso nos permite avaliar os limites do cluster Kafka em diferentes condi\u00e7\u00f5es, identificar gargalos em seu funcionamento e encontrar maneiras de mitig\u00e1-los.<\/p>\n<p>Desenvolvemos o Supertubes para o r\u00e1pido e f\u00e1cil deployment do cluster, sua configura\u00e7\u00e3o, adi\u00e7\u00e3o\/removal de brokers e t\u00f3picos, resposta a alertas e garantia do correto funcionamento do Kafka no Kubernetes como um todo. Nosso objetivo \u00e9 ajudar a focar na tarefa principal (gerar e consumir mensagens Kafka), enquanto toda a carga pesada \u00e9 delegada ao Supertubes e ao kafka operator.<\/p>\n<p>Se voc\u00ea est\u00e1 interessado em tecnologias e projetos Open Source da Banzai Cloud, siga a empresa em <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\">GitHub<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.linkedin.com\/company\/banzaicloud\">LinkedIn<\/a><\/noindex> ou <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/BanzaiCloud\">Twitter<\/a><\/noindex>.<\/p>\n<h2>P.S. do tradutor<\/h2>\n<p>\nConfira tamb\u00e9m em nosso blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/480722\/\">Uma hist\u00f3ria com o operador Redis no K8s e uma breve an\u00e1lise das ferramentas para an\u00e1lise de dados deste banco de dados<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/450662\/\">Migra\u00e7\u00e3o descomplicada do RabbitMQ para Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/329224\/\">zetcd da CoreOS: Substituindo o ZooKeeper por\u2026 armazenamento etcd<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/488920\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Banzai Cloud \u0434\u0435\u043b\u0438\u0442\u0441\u044f \u043f\u0440\u0438\u043c\u0435\u0440\u043e\u043c \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u0435\u0451 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0445 \u0443\u0442\u0438\u043b\u0438\u0442 \u0434\u043b\u044f \u043e\u0431\u043b\u0435\u0433\u0447\u0435\u043d\u0438\u044f \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 Kafka \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 Kubernetes. \u041f\u0440\u0438\u0432\u043e\u0434\u0438\u043c\u044b\u0435 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0446\u0438\u0438 \u0438\u043b\u043b\u044e\u0441\u0442\u0440\u0438\u0440\u0443\u044e\u0442, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0438\u0442\u044c \u043e\u043f\u0442\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u0439 \u0440\u0430\u0437\u043c\u0435\u0440 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0441\u0430\u043c\u0443 Kafka \u0434\u043b\u044f \u0434\u043e\u0441\u0442\u0438\u0436\u0435\u043d\u0438\u044f \u0442\u0440\u0435\u0431\u0443\u0435\u043c\u043e\u0439 \u043f\u0440\u043e\u043f\u0443\u0441\u043a\u043d\u043e\u0439 \u0441\u043f\u043e\u0441\u043e\u0431\u043d\u043e\u0441\u0442\u0438. Apache Kafka \u2014 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u0430\u044f \u0441\u0442\u0440\u0438\u043c\u0438\u043d\u0433\u043e\u0432\u0430\u044f \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0430 \u0434\u043b\u044f \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u043d\u0430\u0434\u0451\u0436\u043d\u044b\u0445, \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u044b\u0445 \u0438 \u0432\u044b\u0441\u043e\u043a\u043e\u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u043e\u0442\u043e\u043a\u043e\u0432\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u0440\u0435\u0430\u043b\u044c\u043d\u043e\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":71214,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-71213","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Banzai Cloud \u0434\u0435\u043b\u0438\u0442\u0441\u044f \u043f\u0440\u0438\u043c\u0435\u0440\u043e\u043c \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u0435\u0451 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0445 \u0443\u0442\u0438\u043b\u0438\u0442 \u0434\u043b\u044f \u043e\u0431\u043b\u0435\u0433\u0447\u0435\u043d\u0438\u044f \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 Kafka \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 Kubernetes.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041e\u043f\u0440\u0435\u0434\u0435\u043b\u044f\u0435\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0438\u0439 \u0440\u0430\u0437\u043c\u0435\u0440 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 Kafka \u0432 Kubernetes | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Banzai Cloud \u0434\u0435\u043b\u0438\u0442\u0441\u044f \u043f\u0440\u0438\u043c\u0435\u0440\u043e\u043c \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u0435\u0451 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0445 \u0443\u0442\u0438\u043b\u0438\u0442 \u0434\u043b\u044f \u043e\u0431\u043b\u0435\u0433\u0447\u0435\u043d\u0438\u044f \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 Kafka \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 Kubernetes.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-24T13:09:17+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-03-03T13:14:29+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Definindo o tamanho adequado para o cluster Kafka no Kubernetes | ProHoster","description":"Nota do tradutor: Neste artigo, a Banzai Cloud compartilha um exemplo do uso de suas ferramentas especiais para facilitar a opera\u00e7\u00e3o do Kafka dentro do Kubernetes.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u043f\u0440\u0435\u0434\u0435\u043b\u044f\u0435\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0438\u0439 \u0440\u0430\u0437\u043c\u0435\u0440 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 Kafka \u0432 Kubernetes | ProHoster","og:description":"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Banzai Cloud \u0434\u0435\u043b\u0438\u0442\u0441\u044f \u043f\u0440\u0438\u043c\u0435\u0440\u043e\u043c \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u0435\u0451 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0445 \u0443\u0442\u0438\u043b\u0438\u0442 \u0434\u043b\u044f \u043e\u0431\u043b\u0435\u0433\u0447\u0435\u043d\u0438\u044f \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 Kafka \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 Kubernetes.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-24T13:09:17+00:00","article:modified_time":"2020-03-03T13:14:29+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"71213","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:06:22","updated":"2022-10-04 20:58:00","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/71213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=71213"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/71213\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/71214"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=71213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=71213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=71213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}