{"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\/it\/blog\/administrirovanie\/opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes","title":{"rendered":"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota di traduzione.<\/b>: In questo articolo, Banzai Cloud condivide un esempio di utilizzo dei suoi strumenti speciali per semplificare l'operativit\u00e0 di Kafka all'interno di Kubernetes. Le istruzioni fornite illustrano come determinare la dimensione ottimale dell'infrastruttura e configurare Kafka per raggiungere la capacit\u00e0 richiesta.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/8a598ec7db091c2944a6442f9bc124da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nApache Kafka \u00e8 una piattaforma di streaming distribuita per la creazione di sistemi di streaming real-time affidabili, scalabili e ad alte prestazioni. Le sue impressionanti capacit\u00e0 possono essere ampliate con Kubernetes. Per questo abbiamo sviluppato <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\/kafka-operator\">l'operatore Kafka Open Source<\/a><\/noindex> e uno strumento chiamato <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/supertubes\/overview\/\">Supertubes<\/a><\/noindex>. Questi strumenti consentono di eseguire Kafka su Kubernetes e di sfruttare le sue varie funzionalit\u00e0, come la fine regolazione della configurazione del broker, la scalabilit\u00e0 basata su metriche con ribilanciamento, la consapevolezza del rack, l'aggiornamento 'graceful' <i>(graceful)<\/i> delle versioni e cos\u00ec via.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<blockquote><p>Prova Supertubes nel tuo cluster:<\/p>\n<pre><code class=\"bash\">curl https:\/\/getsupertubes.sh | sh e supertubes install -a --no-democluster --kubeconfig<\/code><\/pre>\n<p>\nOppure contattaci per. <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/supertubes\/cli\/reference\/\">documentazione<\/a><\/noindex>Puoi anche leggere alcune delle funzionalit\u00e0 di Kafka, la cui gestione \u00e8 automatizzata tramite Supertubes e l'operatore Kafka, di cui abbiamo gi\u00e0 parlato nel blog:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-operator\/\">Oh no! Un altro operatore Kafka per Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-alert\/\">Monitora e gestisci Kafka basato su metriche Prometheus<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-rack-awareness\/\">Consapevolezza del rack di Kafka su Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-on-istio-performance\/\">Esecuzione di Apache Kafka su Istio \u2014 benchmark<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-topic-user-management\/\">Cluster autenticati e controllati dall'accesso con l'operatore Kafka<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-rolling-upgrade\/\">Aggiornamento rolling di Kafka e configurazione dinamica su Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/kafka-envoy-protocol-filter\/\">Filtro di protocollo Envoy per Kafka, in mesh<\/a><\/noindex>.<\/li>\n<\/ul>\n<\/blockquote>\n<p>\nDecidendo di implementare un cluster Kafka su Kubernetes, dovrai sicuramente affrontare il problema di determinare la dimensione ottimale dell'infrastruttura di base e la necessit\u00e0 di una fine regolazione della configurazione di Kafka per soddisfare i requisiti di capacit\u00e0. Le massime prestazioni di ciascun broker sono determinati dalle prestazioni dei componenti dell'infrastruttura su cui si basa, come la memoria, il processore, la velocit\u00e0 del disco, la larghezza di banda della rete, ecc.<\/p>\n<p>Idealmente, la configurazione del broker dovrebbe essere tale che tutti gli elementi dell'infrastruttura vengano utilizzati al massimo delle loro capacit\u00e0. Tuttavia, nella vita reale, tale impostazione \u00e8 piuttosto complessa. \u00c8 pi\u00f9 probabile che gli utenti configurino i broker in modo da massimizzare l'utilizzo di uno o due componenti (disco, memoria o processore). In generale, un broker mostra prestazioni massime quando la sua configurazione consente di utilizzare a pieno il componente pi\u00f9 lento. Cos\u00ec possiamo avere un'idea approssimativa del carico che un singolo broker \u00e8 in grado di gestire.<\/p>\n<p>Teoricamente, possiamo anche stimare il numero di broker necessari per gestire un determinato carico. Tuttavia, nella pratica, le opzioni di configurazione a vari livelli sono cos\u00ec numerose che valutare le prestazioni potenziali di una configurazione \u00e8 molto complesso (se non impossibile). In altre parole, \u00e8 molto difficile pianificare una configurazione basandosi su una prestazione predefinita.<\/p>\n<p>Per gli utenti di Supertubes, di solito adottiamo il seguente approccio: partiamo da una certa configurazione (infrastruttura + impostazioni), quindi misuriamo le sue prestazioni, correggiamo le impostazioni del broker e ripetiamo il processo ancora una volta. Questo avviene fino a quando il potenziale del componente pi\u00f9 lento dell'infrastruttura non viene completamente utilizzato.<\/p>\n<p>In questo modo otteniamo un'idea pi\u00f9 chiara di quanti broker sono necessari nel cluster per gestire un determinato carico (il numero di broker dipende anche da altri fattori, come il numero minimo di repliche dei messaggi per garantire la resilienza, il numero di leader delle partizioni e cos\u00ec via). Inoltre, otteniamo un'idea su quale componente infrastrutturale sarebbe preferibile scalare verticalmente.<\/p>\n<p>In questo articolo parleremo dei passaggi che intraprendiamo per \"estrarre tutto\" dai componenti pi\u00f9 lenti nelle configurazioni iniziali e misurare la larghezza di banda del cluster Kafka. Una configurazione altamente resiliente richiede almeno tre broker attivi (<code>min.insync.replicas=3<\/code>), distribuiti su tre diverse zone di disponibilit\u00e0. Per la configurazione, scalabilit\u00e0 e monitoraggio dell'infrastruttura Kubernetes, utilizziamo la nostra piattaforma di gestione dei container per cloud ibridi \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\/pipeline\">Pipeline<\/a><\/noindex>. Supporta on-premise (bare metal, VMware) e cinque tipi di cloud (Alibaba, AWS, Azure, Google, Oracle), nonch\u00e9 qualsiasi combinazione di essi.<\/p>\n<h2>Riflessioni sull'infrastruttura e la configurazione del cluster Kafka<\/h2>\n<p>\nPer gli esempi riportati di seguito, abbiamo scelto AWS come fornitore di servizi cloud e EKS come distribuzione di Kubernetes. Una configurazione simile pu\u00f2 essere realizzata utilizzando <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\/pke\">PKE<\/a><\/noindex> \u2014 una distribuzione di Kubernetes di Banzai Cloud, certificata da CNCF.<\/p>\n<h3>Disco<\/h3>\n<p>\nAmazon offre diversi <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.aws.amazon.com\/AWSEC2\/latest\/UserGuide\/ebs-volume-types.html\">tipi di volumi EBS<\/a><\/noindex>. Alla base di <i>gp2<\/i> e <i>io1<\/i> ci sono dischi SSD, ma per garantire un'elevata larghezza di banda <i>gp2<\/i> consuma crediti di I\/O <i>(I\/O credits)<\/i>, quindi abbiamo preferito il tipo <i>io1<\/i>, che offre una larghezza di banda stabile e alta.<\/p>\n<h3>Tipi di istanze<\/h3>\n<p>\nLe prestazioni di Kafka dipendono fortemente dalla cache di pagina del sistema operativo, quindi abbiamo bisogno di istanze con una quantit\u00e0 adeguata di memoria per i broker (JVM) e la cache di pagina. L'istanza <i>c5.2xlarge<\/i> \u00e8 un buon inizio, poich\u00e9 ha 16 GB di memoria e <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.aws.amazon.com\/AWSEC2\/latest\/UserGuide\/ebs-optimized.html\">ottimizzata per lavorare con EBS<\/a><\/noindex>. Il suo svantaggio \u00e8 che \u00e8 in grado di fornire prestazioni massime per non pi\u00f9 di 30 minuti ogni 24 ore. Se il carico di lavoro necessita di prestazioni massime per un periodo di tempo pi\u00f9 lungo, \u00e8 opportuno considerare altri tipi di istanze. \u00c8 proprio quello che abbiamo fatto, optando per <i>c5.4xlarge<\/i>. Garantisce una larghezza di banda massima di <b>593,75 MB\/s<\/b>. La larghezza di banda massima del volume EBS <i>io1<\/i> \u00e8 superiore a quella dell'istanza <i>c5.4xlarge<\/i>, quindi il collo di bottiglia dell'infrastruttura sembra essere la larghezza di banda I\/O di questo tipo di istanza (cosa che dovrebbero confermare anche i risultati dei nostri test di carico).<\/p>\n<h3>Rete<\/h3>\n<p>\nLa larghezza di banda della rete deve rivelarsi sufficientemente grande rispetto alle prestazioni dell'istanza VM e del disco, altrimenti la rete diventa un collo di bottiglia. Nel nostro caso, l'interfaccia di rete <i>c5.4xlarge<\/i> supporta una velocit\u00e0 fino a 10 Gb\/s, che \u00e8 significativamente superiore alla larghezza di banda I\/O dell'istanza VM.<\/p>\n<h3>Distribuzione dei broker<\/h3>\n<p>\nI broker devono essere distribuiti (pianificati in Kubernetes) su nodi dedicati per evitare la competizione con altri processi per le risorse di CPU, memoria, rete e disco.<\/p>\n<h3>Versione Java<\/h3>\n<p>\nLa scelta logica \u00e8 Java 11, poich\u00e9 \u00e8 compatibile con Docker nel senso che la JVM riconosce correttamente i processori e la memoria disponibili nel contenitore in cui opera il broker. Sapendo che i limiti della CPU sono importanti, la JVM imposta internamente e in modo trasparente il numero di thread GC e thread del compilatore JIT. Abbiamo utilizzato l'immagine Kafka <code>banzaicloud\/kafka:2.13-2.4.0<\/code>, che include la versione Kafka 2.4.0 (Scala 2.13) su Java 11.<\/p>\n<blockquote><p>Se desideri saperne di pi\u00f9 su Java\/JVM su Kubernetes, dai un'occhiata ai nostri seguenti articoli:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/java-resource-limits\/\">Why my Java application is OOMKilled<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/blog\/java10-container-sizing\/\">How to correctly size containers for Java 10 applications<\/a><\/noindex>.<\/li>\n<\/ul>\n<\/blockquote>\n<p><\/p>\n<h3>Impostazioni di memoria del broker<\/h3>\n<p>\nCi sono due aspetti chiave nella configurazione della memoria del broker: le impostazioni per la JVM e per il pod di Kubernetes. Il limite di memoria impostato per il pod deve essere superiore alla dimensione massima dell'heap, in modo che la JVM abbia spazio per lo spazio metadati di Java, che si trova nella propria memoria, e per la cache di pagina del sistema operativo, che Kafka utilizza attivamente. Nei nostri test abbiamo eseguito broker Kafka con parametri <code>-Xmx4G -Xms2G<\/code>, mentre il limite di memoria per il pod era <code>10 Gi<\/code>. Tieni presente che le impostazioni di memoria per la JVM possono essere ottenute automaticamente utilizzando <code>-XX:MaxRAMPercentage<\/code> e <code>-X:MinRAMPercentage<\/code>, basato sul limite di memoria per il pod.<\/p>\n<h3>Impostazioni della CPU del broker<\/h3>\n<p>\nIn generale, \u00e8 possibile aumentare le prestazioni aumentando il parallelismo utilizzando un maggior numero di thread da parte di Kafka. Pi\u00f9 processori sono disponibili per Kafka, meglio \u00e8. Nel nostro test, siamo partiti con un limite di 6 processori e, progressivamente (a iterazioni), abbiamo aumentato il numero fino a 15. Inoltre, abbiamo impostato <code>num.network.threads=12<\/code> nelle impostazioni del broker, per aumentare il numero di thread che ricevono i dati dalla rete e li inviano. Notando immediatamente che i broker followers non potevano ricevere repliche abbastanza rapidamente, abbiamo aumentato <code>num.replica.fetchers<\/code> fino a 4, per aumentare la velocit\u00e0 con cui i broker followers replicavano i messaggi dai leader.<\/p>\n<h3>Strumento di generazione del carico<\/h3>\n<p>\n\u00c8 importante assicurarsi che il potenziale del generatore di carico scelto non si esaurisca prima che il cluster Kafka (il benchmark di cui si parla) raggiunga il suo carico massimo. In altre parole, \u00e8 necessario effettuare una valutazione preliminare delle capacit\u00e0 dello strumento di generazione del carico, oltre a scegliere per esso tipi di istanze con un numero sufficiente di processori e memoria. In questo modo il nostro strumento produrr\u00e0 pi\u00f9 carico di quanto il cluster Kafka possa gestire. Dopo molti esperimenti, ci siamo fermati su tre istanze <i>c5.4xlarge<\/i>, in cui \u00e8 stato avviato un generatore.<\/p>\n<h2>Benchmarking<\/h2>\n<p>\nLa misurazione delle prestazioni \u00e8 un processo iterativo che comprende le seguenti fasi:<\/p>\n<ul>\n<li> configurazione dell'infrastruttura (cluster EKS, cluster Kafka, strumento di generazione del carico, nonch\u00e9 Prometheus e Grafana);<\/li>\n<li> generazione di carico per un determinato periodo per filtrare le deviazioni casuali nei parametri di prestazione raccolti;<\/li>\n<li> ottimizzazione dell'infrastruttura e della configurazione del broker in base ai parametri di prestazione osservati;<\/li>\n<li> ripetizione del processo fino a raggiungere il livello di capacit\u00e0 richiesto del cluster Kafka. Questo deve essere riproducibile in modo stabile e dimostrare variazioni minime della capacit\u00e0.<\/li>\n<\/ul>\n<p>\nNella sezione successiva sono descritti i passaggi eseguiti durante il benchmark del cluster di test.<\/p>\n<h3>Strumenti<\/h3>\n<p>\nPer un rapido dispiegamento della configurazione di base, generazione di carico e misurazione delle prestazioni sono stati utilizzati i seguenti strumenti:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/pipeline\/overview\/\">Banzai Cloud Pipeline<\/a><\/noindex> per organizzare il cluster EKS di Amazon con <noindex><a rel=\"nofollow\" href=\"https:\/\/prometheus.io\/\">Prometheus<\/a><\/noindex> (per la raccolta delle metriche di Kafka e dell'infrastruttura) e <noindex><a rel=\"nofollow\" href=\"https:\/\/grafana.com\/\">Grafana<\/a><\/noindex> (per la visualizzazione di tali metriche). Abbiamo utilizzato <b>servizi<\/b> in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/banzaicloud\/pipeline\">Pipeline<\/a><\/noindex> integrati che forniscono monitoraggio federato, raccolta centralizzata dei log, scansione delle vulnerabilit\u00e0, recovery da guasti, sicurezza a livello enterprise e molto altro.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/jamiealquiza\/sangrenel\">Sangrenel<\/a><\/noindex> \u00e8 uno strumento per il testing del carico del cluster Kafka.<\/li>\n<li> Pannelli Grafana per la visualizzazione delle metriche di Kafka e dell'infrastruttura: <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 per una configurazione semplicissima del cluster Kafka in Kubernetes. Zookeeper, Kafka operator, Envoy e molti altri componenti sono installati e configurati correttamente per far funzionare un cluster Kafka pronto per la produzione in Kubernetes.\n<ul>\n<li> Per l'installazione <i>supertubes CLI<\/i> utilizza le istruzioni fornite <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/supertubes\/cli\/install\/\">qui<\/a><\/noindex>.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in 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>\nPrepara un cluster EKS con nodi di lavoro dedicati <i>c5.4xlarge<\/i> in diverse zone di disponibilit\u00e0 per i pod con broker Kafka, cos\u00ec come nodi dedicati per il generatore di carico e l'infrastruttura di monitoraggio.<\/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 il cluster EKS \u00e8 attivo, abilita la sua <noindex><a rel=\"nofollow\" href=\"https:\/\/banzaicloud.com\/docs\/pipeline\/features\/integrated-services\/\">servizio di monitoraggio<\/a><\/noindex> \u2014 distribuir\u00e0 Prometheus e Grafana nel cluster.<\/p>\n<h3>Componenti di sistema Kafka<\/h3>\n<p>\nInstalla i componenti di sistema Kafka (Zookeeper, kafka-operator) in EKS utilizzando 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>\nPer impostazione predefinita, in EKS vengono utilizzati volumi EBS di tipo <i>gp2<\/i>, quindi \u00e8 necessario creare una classe di archiviazione separata basata sui volumi <i>io1<\/i> per il 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>\nImposta per i broker il parametro <code>min.insync.replicas=3<\/code> e distribuite i pod del broker sui nodi in tre diverse zone di disponibilit\u00e0:<\/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>Argomenti<\/h3>\n<p>\nAbbiamo avviato in parallelo tre istanze del generatore di carico. Ognuna di esse scrive nel proprio argomento, quindi abbiamo bisogno di tre argomenti:<\/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>\nPer ogni argomento, il fattore di replicazione \u00e8 pari a 3 \u2014 il valore minimo raccomandato per sistemi di produzione altamente disponibili.<\/p>\n<h3>Strumento di generazione del carico<\/h3>\n<p>\nAbbiamo eseguito tre istanze del generatore di carico (ognuna scriveva su un argomento separato). Per i pod del generatore di carico \u00e8 necessario specificare l'affinit\u00e0 del nodo, in modo che vengano pianificati solo su nodi a loro dedicati:<\/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>\nAlcuni aspetti da tenere a mente:<\/p>\n<ul>\n<li> Il generatore di carico genera messaggi lunghi 512 byte e li pubblica in Kafka in batch di 500 messaggi.<\/li>\n<li> Utilizzando l'argomento <code>-required-acks=all<\/code> la pubblicazione \u00e8 considerata riuscita quando tutte le repliche sincronizzate del messaggio sono state ricevute e confermate dai broker Kafka. Ci\u00f2 significa che nel benchmark abbiamo misurato non solo la velocit\u00e0 dei leader nel ricevere i messaggi, ma anche dei loro seguaci, che replicano i messaggi. Questo test non valuta la velocit\u00e0 di lettura dei consumatori <i>(consumers)<\/i> di messaggi recentemente inviati, che rimangono ancora nella cache di pagina del sistema operativo, e la sua comparazione con la velocit\u00e0 di lettura dei messaggi memorizzati su disco.<\/li>\n<li> Il generatore di carico avvia 20 worker in parallelo (<code>-workers=20<\/code>). Ogni worker contiene 5 producer, che condividono la connessione del worker al cluster Kafka. Alla fine, ogni generatore conta 100 producer, e tutti inviano messaggi al cluster Kafka.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Monitoraggio dello stato del cluster<\/h3>\n<p>\nDurante il test del carico del cluster Kafka, abbiamo anche monitorato la sua salute per assicurarci che non ci fossero riavvii dei pod, repliche desincronizzate e massima capacit\u00e0 di throughput con fluttuazioni minime:<\/p>\n<ul>\n<li> Il generatore di carico registra statistiche standard sul numero di messaggi pubblicati e sul tasso di errori. La percentuale di errori deve rimanere al di sotto di <code>0,00%<\/code>.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/linkedin\/cruise-control\">Cruise Control<\/a><\/noindex>, distribuito con kafka-operator, fornisce un'interfaccia di monitoraggio in cui possiamo anche osservare lo stato del cluster. Per visualizzare questa interfaccia, eseguire:\n<pre><code class=\"bash\">supertubes cluster cruisecontrol show -n kafka --kubeconfig<\/code><\/pre>\n<\/li>\n<li> Livello ISR <i>(numero di repliche \"in-sync\")<\/i> shrink e expansion sono pari a 0.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Risultati delle misurazioni<\/h2>\n<p><\/p>\n<h3>3 broker, dimensione dei messaggi \u2014 512 byte<\/h3>\n<p>\nCon le partizioni equamente distribuite su tre broker, siamo riusciti a raggiungere prestazioni <i>~500 Mb\/s (circa 990.000 messaggi al secondo)<\/i>:<\/p>\n<p><img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/df65ff6a1a26e28d5e5a7a5ab1a20d98.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/15c5883c0056c651f0a0bd14e9991967.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/9b708fa5ce809b0d059cba9f5edfbb2f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl consumo di memoria dalla macchina virtuale JVM non ha superato i 2 Gb:<\/p>\n<p><img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/3320e2eea891055cc0935da492d18ee9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/6e3976c310309aa8be45fa3fdf547750.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/94baa1b689ae854693fb7cc4ed6e105e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa capacit\u00e0 di I\/O del disco ha raggiunto la massima capacit\u00e0 del nodo su tutte e tre le istanze in cui operavano i broker:<\/p>\n<p><img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/408139ad33cda1294755660df1c128a8.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/391d2df0ddfe82f94abdb200370ff775.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/e7e9fd021a2cdc71992ce672363a78ec.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDai dati sull'utilizzo della memoria dei nodi, si osserva che il buffering di sistema e la cache hanno occupato ~10-15 Gb:<\/p>\n<p><img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/781887507e01a4903b86871961ff9260.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/63f10177f01342039f04192ea93c8bca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/48b992cc73a968b3d3b1442f96562c4e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>3 broker, dimensione dei messaggi \u2014 100 byte<\/h3>\n<p>\nCon la diminuzione della dimensione dei messaggi, la capacit\u00e0 di throughput scende di circa il 15-20%: ci\u00f2 \u00e8 dovuto al tempo impiegato per elaborare ogni messaggio. Inoltre, il carico sulla CPU \u00e8 aumentato quasi di due volte.<\/p>\n<p><img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/2f7dc5a94da371cfe17c9e0fc0ec1941.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/986160a3a4e099a0dbb8aeefaf6f1c2f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/c08244457bf4dbfadf52838d4ea2969e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPoich\u00e9 sui nodi dei broker ci sono ancora core non utilizzati, \u00e8 possibile aumentare le prestazioni modificando la configurazione di Kafka. Questa \u00e8 un'operazione complessa, quindi per aumentare la capacit\u00e0 di throughput \u00e8 meglio lavorare con messaggi di dimensioni maggiori.<\/p>\n<h3>4 broker, dimensione dei messaggi \u2014 512 byte<\/h3>\n<p>\n\u00c8 possibile aumentare facilmente le prestazioni del cluster Kafka semplicemente aggiungendo nuovi broker e mantenendo l'equilibrio delle partizioni (questo garantisce una distribuzione uniforme del carico tra i broker). Nel nostro caso, dopo aver aggiunto un broker, la capacit\u00e0 del cluster \u00e8 aumentata fino a <i>~580 Mb\/s (~1,1 milioni di messaggi al secondo)<\/i>. La crescita si \u00e8 rivelata inferiore alle aspettative: ci\u00f2 \u00e8 principalmente dovuto a uno squilibrio delle partizioni (non tutti i broker operano al massimo delle loro capacit\u00e0).<\/p>\n<p><img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/8c8d2e70739add3c3f88fe42acf98c46.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/a6e4812270c04487de0ad39b996a13f8.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/6162c04cfb87b9d9cd0f3147a4ae1647.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/dae5de3b14be212c679f3627a3b77d7b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl consumo di memoria della macchina JVM \u00e8 rimasto al di sotto di 2 GB:<\/p>\n<p><img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/0bca07a817d7da3104b08de10979f049.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/7e1e64f80ec140f13e171cfe3be930ce.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/5e9700b1e54e45f9cd5fa018ec07dba1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/4ba0c4b59bfe72bcb0d2f22056c47d79.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl funzionamento dei broker con i dischi \u00e8 stato influenzato dallo squilibrio delle partizioni:<\/p>\n<p><img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/2b8ed3c21adf70c751d1daa6d4c41895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/77b980869b99903d9de5cd7d43d79291.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/f2f9569a3a1ef0ce35e89b2e52e4a8b2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Definiamo la dimensione adeguata per un cluster Kafka in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/02\/191d6d97b32b2128c5cfd3914171de15.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Conclusioni<\/h2>\n<p>\nL'approccio iterativo presentato sopra pu\u00f2 essere ampliato per coprire scenari pi\u00f9 complessi, inclusi centinaia di consumer, ripartizionamento, aggiornamenti rolling, riavvii dei pod e cos\u00ec via. Tutto ci\u00f2 ci consente di valutare i limiti delle capacit\u00e0 del cluster Kafka in diverse condizioni, identificare i colli di bottiglia nelle sue operazioni e trovare modi per affrontarli.<\/p>\n<p>Abbiamo sviluppato Supertubes per il rapido e facile deployment del cluster, la sua configurazione, l'aggiunta\/rimozione di broker e topic, la gestione degli allerta e il corretto funzionamento di Kafka in Kubernetes nel complesso. Il nostro obiettivo \u00e8 aiutare a concentrarsi sul compito principale (\"generare\" e \"consumare\" messaggi Kafka), delegando tutto il lavoro pesante a Supertubes e al kafka operator.<\/p>\n<p>Se ti interessano le tecnologie e i progetti Open Source di Banzai Cloud, segui l'azienda su <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.S. dal traduttore<\/h2>\n<p>\nLeggi anche nel nostro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/480722\/\">Una storia con l'operatore Redis in K8s e una mini-guida agli strumenti per l'analisi dei dati di questo DB.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/450662\/\">Migrazione non semplice di RabbitMQ in Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/329224\/\">zetcd di CoreOS: Sostituire ZooKeeper con... un archivio 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.1.1 - 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\/it\/blog\/administrirovanie\/opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\/it\/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\udd47Definire la dimensione adeguata per un cluster Kafka in Kubernetes | ProHoster","description":"Nota del traduttore: In questo articolo, Banzai Cloud condivide un esempio di utilizzo dei suoi strumenti speciali per facilitare l'operativit\u00e0 di Kafka all'interno di Kubernetes.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/opredelyaem-podhodyashhij-razmer-dlya-klastera-kafka-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/71213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=71213"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/71213\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/71214"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=71213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=71213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=71213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}