{"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\/es\/blog\/administrirovanie\/opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes","title":{"rendered":"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota de traducci\u00f3n.<\/b>: En este art\u00edculo, Banzai Cloud comparte un ejemplo del uso de sus herramientas especiales para facilitar la operaci\u00f3n de Kafka dentro de Kubernetes. Las instrucciones proporcionadas ilustran c\u00f3mo se puede determinar el tama\u00f1o \u00f3ptimo de la infraestructura y configurar Kafka para alcanzar la capacidad de rendimiento requerida.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/8a598ec7db091c2944a6442f9bc124da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nApache Kafka es una plataforma de streaming distribuida para crear sistemas de streaming en tiempo real que sean confiables, escalables y de alto rendimiento. Sus impresionantes capacidades se pueden ampliar utilizando Kubernetes. Para ello, hemos desarrollado <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\/kafka-operator\">el operador Kafka de c\u00f3digo abierto<\/a><\/noindex> y una herramienta llamada <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/supertubes\/overview\/\">Supertubes<\/a><\/noindex>. Estas permiten ejecutar Kafka en Kubernetes y usar sus diversas funciones, como la configuraci\u00f3n avanzada del broker, escalado basado en m\u00e9tricas con reequilibrio, rack awareness, \"despliegue suave\" <i>(graceful)<\/i> de actualizaciones, etc.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<blockquote><p>Prueba Supertubes en tu cl\u00faster:<\/p>\n<pre><code class=\"bash\">curl https:\/\/getsupertubes.sh | sh y supertubes install -a --no-democluster --kubeconfig<\/code><\/pre>\n<p>\nO consulta <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/supertubes\/cli\/reference\/\">la documentaci\u00f3n<\/a><\/noindex>. Tambi\u00e9n puedes leer sobre algunas de las capacidades de Kafka, cuyo manejo est\u00e1 automatizado mediante Supertubes y el operador Kafka. De ello ya hemos escrito en el blog:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-operator\/\">\u00a1Oh no! \u00a1Otro operador Kafka para Kubernetes!<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-alert\/\">Monitorea y opera Kafka bas\u00e1ndote en m\u00e9tricas de Prometheus<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-rack-awareness\/\">Conciencia de rack en Kafka sobre Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-on-istio-performance\/\">Ejecutando Apache Kafka a trav\u00e9s de Istio \u2014 benchmark<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-topic-user-management\/\">Cl\u00fasteres autenticados y controlados por acceso con el operador Kafka<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-rolling-upgrade\/\">Actualizaci\u00f3n en caliente de Kafka y configuraci\u00f3n din\u00e1mica en 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, en malla<\/a><\/noindex>.<\/li>\n<\/ul>\n<\/blockquote>\n<p>\nAl decidir desplegar un cl\u00faster de Kafka en Kubernetes, seguramente te enfrentar\u00e1s al problema de determinar el tama\u00f1o \u00f3ptimo de la infraestructura b\u00e1sica y la necesidad de un ajuste fino de la configuraci\u00f3n de Kafka para cumplir con los requisitos de capacidad de rendimiento. El rendimiento m\u00e1ximo de cada broker est\u00e1 determinado por el rendimiento de los componentes de infraestructura subyacentes, como la memoria, el procesador, la velocidad del disco, la capacidad de la red, etc.<\/p>\n<p>Idealmente, la configuraci\u00f3n del broker debe ser tal que todos los elementos de la infraestructura se utilicen al m\u00e1ximo de su capacidad. Sin embargo, en la vida real, dicha configuraci\u00f3n es bastante compleja. Es m\u00e1s probable que los usuarios ajusten la configuraci\u00f3n de los brokers de manera que maximicen el uso de uno o dos componentes (disco, memoria o procesador). En general, un broker muestra el rendimiento m\u00e1ximo cuando su configuraci\u00f3n permite aprovechar al m\u00e1ximo el componente m\u00e1s lento. As\u00ed podemos obtener una idea aproximada de la carga que puede manejar un solo broker.<\/p>\n<p>Te\u00f3ricamente, tambi\u00e9n podemos estimar el n\u00famero de brokers necesarios para manejar una carga dada. Sin embargo, en la pr\u00e1ctica, hay tantas opciones de configuraci\u00f3n en diferentes niveles que es bastante dif\u00edcil (si no imposible) evaluar el rendimiento potencial de una cierta configuraci\u00f3n. En otras palabras, planificar una configuraci\u00f3n bas\u00e1ndose en un rendimiento espec\u00edfico es muy complicado.<\/p>\n<p>Para los usuarios de Supertubes, generalmente aplicamos el siguiente enfoque: comenzamos con una cierta configuraci\u00f3n (infraestructura + ajustes), luego medimos su rendimiento, ajustamos la configuraci\u00f3n del broker y repetimos el proceso una vez m\u00e1s. Esto contin\u00faa hasta que se aproveche completamente el potencial del componente m\u00e1s lento de la infraestructura.<\/p>\n<p>De esta manera, obtenemos una visi\u00f3n m\u00e1s clara de cu\u00e1ntos brokers se necesitan en un cl\u00faster para manejar una carga determinada (el n\u00famero de brokers tambi\u00e9n depende de otros factores, como el n\u00famero m\u00ednimo de r\u00e9plicas de mensajes para garantizar la resiliencia, el n\u00famero de l\u00edderes de partici\u00f3n, etc.). Adem\u00e1s, obtenemos una idea de qu\u00e9 componente de la infraestructura se beneficia del escalado vertical.<\/p>\n<p>En este art\u00edculo, abordaremos los pasos que tomamos para \"exprimir al m\u00e1ximo\" los componentes m\u00e1s lentos en las configuraciones iniciales y medir la capacidad de procesamiento del cl\u00faster Kafka. Una configuraci\u00f3n altamente resistente requiere al menos tres brokers en funcionamiento (<code>min.insync.replicas=3<\/code>), distribuidos en tres zonas de disponibilidad diferentes. Para la configuraci\u00f3n, escalado y monitoreo de la infraestructura de Kubernetes, utilizamos nuestra propia plataforma de gesti\u00f3n de contenedores para nubes h\u00edbridas \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\/pipeline\">Pipeline<\/a><\/noindex>. Soporta on-premise (bare metal, VMware) y cinco tipos de nubes (Alibaba, AWS, Azure, Google, Oracle), as\u00ed como cualquier combinaci\u00f3n de ellas.<\/p>\n<h2>Reflexiones sobre la infraestructura y configuraci\u00f3n del cl\u00faster Kafka<\/h2>\n<p>\nPara los ejemplos a continuaci\u00f3n, hemos elegido AWS como proveedor de servicios en la nube y EKS como distribuci\u00f3n de Kubernetes. Una configuraci\u00f3n similar se puede implementar con <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\/pke\">PKE<\/a><\/noindex> \u2014 distribuci\u00f3n de Kubernetes de Banzai Cloud, certificada por la CNCF.<\/p>\n<h3>Disco<\/h3>\n<p>\nAmazon ofrece diferentes <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.aws.amazon.com\/AWSEC2\/latest\/UserGuide\/ebs-volume-types.html\">tipos de vol\u00famenes EBS<\/a><\/noindex>. En su base, <i>gp2<\/i> y <i>io1<\/i> se basan en discos SSD, sin embargo, para garantizar un alto rendimiento <i>gp2<\/i> consume cr\u00e9ditos acumulados <i>(I\/O credits)<\/i>, por lo que preferimos el tipo <i>io1<\/i>, que ofrece un rendimiento alto y estable.<\/p>\n<h3>Tipos de instancias<\/h3>\n<p>\nEl rendimiento de Kafka depende en gran medida de la cach\u00e9 de p\u00e1ginas del sistema operativo, por lo que necesitamos instancias con suficiente memoria para los brokers (JVM) y para la cach\u00e9 de p\u00e1ginas. La instancia <i>c5.2xlarge<\/i> es un buen comienzo, ya que tiene 16 GB de memoria y <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.aws.amazon.com\/AWSEC2\/latest\/UserGuide\/ebs-optimized.html\">est\u00e1 optimizada para trabajar con EBS<\/a><\/noindex>. Su desventaja es que puede ofrecer un rendimiento m\u00e1ximo durante no m\u00e1s de 30 minutos cada 24 horas. Si la carga de trabajo requiere un rendimiento m\u00e1ximo durante per\u00edodos m\u00e1s prolongados, es conveniente considerar otros tipos de instancias. As\u00ed lo hicimos, eligiendo <i>c5.4xlarge<\/i>. Proporciona un rendimiento m\u00e1ximo de <b>593,75 MB\/s<\/b>. El rendimiento m\u00e1ximo del volumen EBS <i>io1<\/i> es superior al de la instancia <i>c5.4xlarge<\/i>, por lo que el elemento m\u00e1s lento de la infraestructura parece ser el rendimiento I\/O de este tipo de instancia (lo que tambi\u00e9n deber\u00edan confirmar los resultados de nuestras pruebas de carga).<\/p>\n<h3>Red<\/h3>\n<p>\nEl ancho de banda de la red debe ser lo suficientemente grande en comparaci\u00f3n con el rendimiento de la instancia VM y el disco, de lo contrario, la red se convierte en un cuello de botella. En nuestro caso, la interfaz de red <i>c5.4xlarge<\/i> soporta velocidades de hasta 10 Gb\/s, lo cual es significativamente superior al rendimiento I\/O de la instancia VM.<\/p>\n<h3>Despliegue de brokers<\/h3>\n<p>\nLos brokers deben desplegarse (planificarse en Kubernetes) en nodos dedicados para evitar competir con otros procesos por recursos de CPU, memoria, red y disco.<\/p>\n<h3>Versi\u00f3n de Java<\/h3>\n<p>\nLa opci\u00f3n l\u00f3gica es Java 11, ya que es compatible con Docker en el sentido de que la JVM identifica correctamente los procesadores y la memoria disponibles para el contenedor en el que se ejecuta el broker. Sabiendo que los l\u00edmites de CPU son importantes, la JVM establece de manera interna y transparente el n\u00famero de hilos de GC y hilos del compilador JIT. Usamos la imagen de Kafka <code>banzaicloud\/kafka:2.13-2.4.0<\/code>, incluida la versi\u00f3n Kafka 2.4.0 (Scala 2.13) en Java 11.<\/p>\n<blockquote><p>Si desea saber m\u00e1s sobre Java\/JVM en Kubernetes, consulte nuestras siguientes publicaciones:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/java-resource-limits\/\">Por qu\u00e9 mi aplicaci\u00f3n Java fue OOMKilled<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/java10-container-sizing\/\">C\u00f3mo dimensionar correctamente los contenedores para aplicaciones Java 10<\/a><\/noindex>.<\/li>\n<\/ul>\n<\/blockquote>\n<p><\/p>\n<h3>Configuraciones de memoria del broker<\/h3>\n<p>\nExisten dos aspectos clave en la configuraci\u00f3n de la memoria del broker: la configuraci\u00f3n para la JVM y para el pod de Kubernetes. El l\u00edmite de memoria establecido para el pod debe ser mayor que el tama\u00f1o m\u00e1ximo del heap, para que la JVM tenga espacio para el metaspacio de Java, que reside en su propia memoria, y para la cach\u00e9 de p\u00e1ginas del sistema operativo, que Kafka utiliza activamente. En nuestras pruebas, ejecutamos brokers de Kafka con par\u00e1metros <code>-Xmx4G -Xms2G<\/code>, y el l\u00edmite de memoria para el pod era <code>10 Gi<\/code>. Tenga en cuenta que las configuraciones de memoria para la JVM se pueden obtener autom\u00e1ticamente usando <code>-XX:MaxRAMPercentage<\/code> y <code>-X:MinRAMPercentage<\/code>, basado en el l\u00edmite de memoria del pod.<\/p>\n<h3>Configuraciones de CPU del broker<\/h3>\n<p>\nEn general, se puede aumentar el rendimiento aumentando el paralelismo mediante el aumento del n\u00famero de hilos utilizados por Kafka. Cuantos m\u00e1s procesadores est\u00e9n disponibles para Kafka, mejor. En nuestra prueba comenzamos con un l\u00edmite de 6 procesadores y gradualmente (por iteraciones) aumentamos el n\u00famero a 15. Adem\u00e1s, configuramos <code>num.network.threads=12<\/code> en la configuraci\u00f3n del broker para aumentar el n\u00famero de hilos que reciben datos de la red y los env\u00edan. Al descubrir que los brokers seguidores no pueden recibir r\u00e9plicas lo suficientemente r\u00e1pido, aumentamos <code>num.replica.fetchers<\/code> a 4 para aumentar la velocidad con la que los brokers seguidores replican mensajes de los l\u00edderes.<\/p>\n<h3>Herramienta de generaci\u00f3n de carga<\/h3>\n<p>\nSe debe asegurar que el potencial del generador de carga elegido no se agote antes de que el cl\u00faster de Kafka (el cual est\u00e1 siendo sometido a benchmark) alcance su carga m\u00e1xima. En otras palabras, se debe realizar una evaluaci\u00f3n previa de las capacidades de la herramienta de generaci\u00f3n de carga, as\u00ed como elegir para ella tipos de instancias con suficiente cantidad de procesadores y memoria. En este caso, nuestra herramienta producir\u00e1 m\u00e1s carga de la que puede manejar el cl\u00faster de Kafka. Despu\u00e9s de muchos experimentos, optamos por tres instancias <i>c5.4xlarge<\/i>, en cada una de las cuales se ejecut\u00f3 el generador.<\/p>\n<h2>Benchmarking<\/h2>\n<p>\nLa medici\u00f3n del rendimiento es un proceso iterativo que incluye las siguientes etapas:<\/p>\n<ul>\n<li> configuraci\u00f3n de la infraestructura (cl\u00faster EKS, cl\u00faster Kafka, herramienta de generaci\u00f3n de carga, as\u00ed como Prometheus y Grafana);<\/li>\n<li> generaci\u00f3n de carga durante un per\u00edodo espec\u00edfico para filtrar desviaciones aleatorias en las m\u00e9tricas de rendimiento recopiladas;<\/li>\n<li> ajuste de la infraestructura y la configuraci\u00f3n del broker basado en las m\u00e9tricas de rendimiento observadas;<\/li>\n<li> repetir el proceso hasta alcanzar el nivel de capacidad requerido del cl\u00faster Kafka. Este debe ser consistentemente reproducible y mostrar variaciones m\u00ednimas en la capacidad.<\/li>\n<\/ul>\n<p>\nEn la siguiente secci\u00f3n se describen los pasos que se llevaron a cabo en el proceso de benchmarking del cl\u00faster de prueba.<\/p>\n<h3>Herramientas<\/h3>\n<p>\nPara el despliegue r\u00e1pido de la configuraci\u00f3n b\u00e1sica, la generaci\u00f3n de carga y la medici\u00f3n del rendimiento se utilizaron las siguientes herramientas:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/pipeline\/overview\/\">Banzai Cloud Pipeline<\/a><\/noindex> para organizar el cl\u00faster EKS de Amazon con <noindex><a rel=\"nofollow\" href=\"https:\/\/prometheus.io\/\">Prometheus<\/a><\/noindex> (para la recolecci\u00f3n de m\u00e9tricas de Kafka e infraestructura) y <noindex><a rel=\"nofollow\" href=\"https:\/\/grafana.com\/\">Grafana<\/a><\/noindex> (para la visualizaci\u00f3n de estas m\u00e9tricas). Aprovechamos <b>servicios integrados<\/b> en <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\/pipeline\">Pipeline<\/a><\/noindex> que ofrecen monitoreo federado, recolecci\u00f3n centralizada de logs, escaneo de vulnerabilidades, recuperaci\u00f3n ante fallos, seguridad a nivel empresarial y mucho m\u00e1s.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/jamiealquiza\/sangrenel\">Sangrenel<\/a><\/noindex> es una herramienta para pruebas de carga del cl\u00faster Kafka.<\/li>\n<li> Paneles de Grafana para la visualizaci\u00f3n de m\u00e9tricas de Kafka e infraestructura: <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 la configuraci\u00f3n m\u00e1s sencilla de un cl\u00faster de Kafka en Kubernetes. Zookeeper, el operador de Kafka, Envoy y muchos otros componentes est\u00e1n instalados y configurados correctamente para ejecutar un cl\u00faster de Kafka listo para producci\u00f3n en Kubernetes.\n<ul>\n<li> Para la instalaci\u00f3n <i>supertubes CLI<\/i> siga las instrucciones proporcionadas <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/supertubes\/cli\/install\/\">aqu\u00ed<\/a><\/noindex>.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/23ecf423b1ea66813406943ae7eabf61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Cl\u00faster EKS<\/h3>\n<p>\nPrepare el cl\u00faster EKS con nodos de trabajo dedicados <i>c5.4xlarge<\/i> en diferentes zonas de disponibilidad para los pods con brokers de Kafka, as\u00ed como nodos dedicados para el generador de carga y la infraestructura de monitoreo.<\/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>\nCuando el cl\u00faster EKS est\u00e9 en funcionamiento, active su <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/pipeline\/features\/integrated-services\/\">servicio de monitoreo<\/a><\/noindex> \u2014 desplegar\u00e1 Prometheus y Grafana en el cl\u00faster.<\/p>\n<h3>Componentes del sistema Kafka<\/h3>\n<p>\nInstale los componentes del sistema Kafka (Zookeeper, kafka-operator) en EKS utilizando supertubes CLI:<\/p>\n<pre><code class=\"bash\">supertubes install -a --no-democluster --kubeconfig<\/code><\/pre>\n<p><\/p>\n<h3>Cl\u00faster Kafka<\/h3>\n<p>\nPor defecto, en EKS se utilizan vol\u00famenes EBS de tipo <i>gp2<\/i>, por lo que es necesario crear una clase de almacenamiento separada basada en vol\u00famenes <i>io1<\/i> para el cl\u00faster de 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>\nEstablezca el par\u00e1metro para los brokers <code>min.insync.replicas=3<\/code> y despliegue los pods de brokers en nodos en tres diferentes zonas de disponibilidad:<\/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>\nEjecutamos en paralelo tres instancias de un generador de carga. Cada una escribe en su propio t\u00f3pico, es decir, en total necesitamos tres t\u00f3picos:<\/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, el factor de replicaci\u00f3n es 3, que es el valor m\u00ednimo recomendado para sistemas de producci\u00f3n altamente disponibles.<\/p>\n<h3>Herramienta de generaci\u00f3n de carga<\/h3>\n<p>\nEjecutamos tres instancias del generador de carga (cada una escribiendo en un tema separado). Para los pods del generador de carga, es necesario especificar la afinidad del nodo para que se programen solo en los nodos dedicados para ellos:<\/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>\nAlgunos puntos a tener en cuenta:<\/p>\n<ul>\n<li> El generador de carga genera mensajes de 512 bytes y los publica en Kafka en lotes de 500 mensajes.<\/li>\n<li> Con el argumento <code>-required-acks=all<\/code> la publicaci\u00f3n se considera exitosa cuando todas las r\u00e9plicas sincronizadas del mensaje son recibidas y confirmadas por los brokers de Kafka. Esto significa que en la evaluaci\u00f3n medimos no solo la velocidad con la que los l\u00edderes reciben los mensajes, sino tambi\u00e9n la de sus seguidores, que replican los mensajes. El objetivo de esta prueba no es evaluar la velocidad de lectura de los consumidores <i>(consumidores)<\/i> de mensajes reci\u00e9n llegados, que a\u00fan permanecen en la cach\u00e9 de p\u00e1ginas del sistema operativo, y su comparaci\u00f3n con la velocidad de lectura de los mensajes almacenados en disco.<\/li>\n<li> El generador de carga ejecuta 20 trabajadores en paralelo (<code>-workers=20<\/code>). Cada trabajador contiene 5 productores, que comparten la conexi\u00f3n del trabajador al cl\u00faster de Kafka. En total, cada generador cuenta con 100 productores, todos enviando mensajes al cl\u00faster de Kafka.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Monitoreo del estado del cl\u00faster<\/h3>\n<p>\nDurante las pruebas de carga del cl\u00faster de Kafka, tambi\u00e9n monitoreamos su salud para asegurarnos de que no hubiera reinicios de pods, r\u00e9plicas desincronizadas y capacidad m\u00e1xima de procesamiento con m\u00ednimas fluctuaciones:<\/p>\n<ul>\n<li> El generador de carga escribe estad\u00edsticas est\u00e1ndar sobre la cantidad de mensajes publicadas y el nivel de errores. El porcentaje de errores debe mantenerse en: <code>0,00%<\/code>.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/linkedin\/cruise-control\">Cruise Control<\/a><\/noindex>, desplegado por el kafka-operator, proporciona un panel de monitoreo en el que tambi\u00e9n podemos observar el estado del cl\u00faster. Para ver este panel, ejecute:\n<pre><code class=\"bash\">supertubes cluster cruisecontrol show -n kafka --kubeconfig<\/code><\/pre>\n<\/li>\n<li> El nivel ISR <i>(n\u00famero de r\u00e9plicas \"in-sync\")<\/i> shrink y expansion es igual a 0.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Resultados de las mediciones<\/h2>\n<p><\/p>\n<h3>3 br\u00f3kers, tama\u00f1o de mensaje \u2014 512 bytes<\/h3>\n<p>\nCon las particiones distribuidas uniformemente entre tres corredores, logramos alcanzar un rendimiento <i>~500 Mb\/s (aproximadamente 990 mil mensajes por segundo)<\/i>:<\/p>\n<p><img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/df65ff6a1a26e28d5e5a7a5ab1a20d98.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/15c5883c0056c651f0a0bd14e9991967.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/9b708fa5ce809b0d059cba9f5edfbb2f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl consumo de memoria de la m\u00e1quina virtual JVM no excedi\u00f3 2 Gb:<\/p>\n<p><img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/3320e2eea891055cc0935da492d18ee9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/6e3976c310309aa8be45fa3fdf547750.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/94baa1b689ae854693fb7cc4ed6e105e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa capacidad de procesamiento del disco alcanz\u00f3 el m\u00e1ximo rendimiento de I\/O del nodo en las tres instancias donde operaban los br\u00f3kers:<\/p>\n<p><img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/408139ad33cda1294755660df1c128a8.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/391d2df0ddfe82f94abdb200370ff775.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/e7e9fd021a2cdc71992ce672363a78ec.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLos datos sobre el uso de memoria de los nodos indican que el buffering y el almacenamiento en cach\u00e9 del sistema tomaron aproximadamente 10-15 Gb:<\/p>\n<p><img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/781887507e01a4903b86871961ff9260.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/63f10177f01342039f04192ea93c8bca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/48b992cc73a968b3d3b1442f96562c4e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>3 br\u00f3kers, tama\u00f1o de mensaje \u2014 100 bytes<\/h3>\n<p>\nCon la reducci\u00f3n del tama\u00f1o de los mensajes, la capacidad de procesamiento disminuye aproximadamente en un 15-20%: esto se debe al tiempo requerido para procesar cada mensaje. Adem\u00e1s, la carga en el procesador aument\u00f3 casi el doble.<\/p>\n<p><img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/2f7dc5a94da371cfe17c9e0fc0ec1941.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/986160a3a4e099a0dbb8aeefaf6f1c2f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/c08244457bf4dbfadf52838d4ea2969e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDado que todav\u00eda hay n\u00facleos no utilizados en los nodos de los br\u00f3kers, se puede mejorar el rendimiento modificando la configuraci\u00f3n de Kafka. Esta no es una tarea sencilla, por lo que para aumentar la capacidad de procesamiento es mejor trabajar con mensajes de mayor tama\u00f1o.<\/p>\n<h3>4 br\u00f3kers, tama\u00f1o de mensaje \u2014 512 bytes<\/h3>\n<p>\nEs f\u00e1cil aumentar el rendimiento del cl\u00faster de Kafka simplemente a\u00f1adiendo nuevos corredores y manteniendo el balance de las particiones (esto asegura una distribuci\u00f3n uniforme de la carga entre los corredores). En nuestro caso, tras a\u00f1adir un corredor, el ancho de banda del cl\u00faster aument\u00f3 a <i>~580 Mb\/s (~1,1 millones de mensajes por segundo)<\/i>. El crecimiento fue menor de lo esperado: esto se explica principalmente por el desequilibrio en las particiones (no todos los corredores est\u00e1n operando en su capacidad m\u00e1xima).<\/p>\n<p><img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/8c8d2e70739add3c3f88fe42acf98c46.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/a6e4812270c04487de0ad39b996a13f8.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/6162c04cfb87b9d9cd0f3147a4ae1647.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/dae5de3b14be212c679f3627a3b77d7b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl consumo de memoria de la m\u00e1quina JVM se mantuvo por debajo de 2 GB:<\/p>\n<p><img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/0bca07a817d7da3104b08de10979f049.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/7e1e64f80ec140f13e171cfe3be930ce.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/5e9700b1e54e45f9cd5fa018ec07dba1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/4ba0c4b59bfe72bcb0d2f22056c47d79.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl trabajo de los corredores con almacenamiento se vio afectado por el desequilibrio en las particiones:<\/p>\n<p><img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/2b8ed3c21adf70c751d1daa6d4c41895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/77b980869b99903d9de5cd7d43d79291.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/f2f9569a3a1ef0ce35e89b2e52e4a8b2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Determinando el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/191d6d97b32b2128c5cfd3914171de15.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Conclusiones<\/h2>\n<p>\nEl enfoque iterativo presentado anteriormente puede ampliarse para abarcar escenarios m\u00e1s complejos, que incluyen cientos de consumidores, reparticionamiento, actualizaciones en caliente, reinicios de pods, etc. Todo esto nos permite evaluar los l\u00edmites del cl\u00faster de Kafka en diversas condiciones, identificar cuellos de botella en su funcionamiento y encontrar formas de mitigarlos.<\/p>\n<p>Desarrollamos Supertubes para el despliegue r\u00e1pido y f\u00e1cil del cl\u00faster, su configuraci\u00f3n, agregaci\u00f3n\/eliminaci\u00f3n de corredores y temas, respuesta a alertas y aseguramiento del correcto funcionamiento de Kafka en Kubernetes en general. Nuestro objetivo es ayudar a concentrarse en la tarea principal (\"generar\" y \"consumir\" mensajes de Kafka), dejando todo el trabajo pesado a Supertubes y al kafka-operator.<\/p>\n<p>Si te interesan las tecnolog\u00edas y proyectos de c\u00f3digo abierto de Banzai Cloud, sigue a la empresa en <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> o <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/BanzaiCloud\">Twitter<\/a><\/noindex>.<\/p>\n<h2>P.D. del traductor<\/h2>\n<p>\nTambi\u00e9n puedes leer en nuestro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/480722\/\">Una historia con el operador Redis en K8s y un mini-resumen de las herramientas para analizar datos de esta base de datos<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/450662\/\">Migraci\u00f3n no trivial de RabbitMQ en Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/329224\/\">zetcd de CoreOS: Reemplazando ZooKeeper con\u2026 almacenamiento etcd<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fuente: <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.2 - 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\/es\/blog\/administrirovanie\/opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\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\/es\/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\udd47Definiendo el tama\u00f1o adecuado para un cl\u00faster de Kafka en Kubernetes | ProHoster","description":"Nota del traductor: En este art\u00edculo, la empresa Banzai Cloud comparte un ejemplo del uso de sus herramientas especiales para facilitar la operaci\u00f3n de Kafka en el contexto de Kubernetes.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/71213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=71213"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/71213\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/71214"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=71213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=71213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=71213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}