 Yeah, de beleza. Alá, pessoal, tudo bem? Obrigado. Cara, Rodrigo, quem não sabe, a gente trabalha no mesmo time aqui na Red Hat. A gente é parte de um time de especialistas e ele é o cara de integração. O cara mais uma integração aqui na Red Hat em Latin. Então, é um cara super bacana para falar de hoje para a gente subcar, cara. Rodrigo, não vou tomar seu tempo. O palco é seu. Fica à vontade aí e eu vou ficar monitorando o chat aqui. Beleza. Vamos lá. Olá, pessoal, tudo bem? Deixa eu ver se eu vejo o chat do pessoal aqui. Vou pedir para o pessoal dar um oi aí no chat para falar de onde que está, mais ou menos. Pô, eu sou o Rodrigo de Brasília. Eu sou Thiago de Portaleza, não sei. Então, pessoal, eu sou o Rodrigo Ramalho. Eu estou aqui em Brasília, na capital aí. E, como ela falou, eu sou responsável pela parte de integração, pela área de integração na América Latina da Red Hat. Então, eu venho acompanhando alguns projetos bem interessantes. E hoje, através desse bate-papo aqui, eu vou tentar compartilhar um pouco desses experiências que eu tenho consolidado nesse projeto e mostrando um pouquinho desse ecossistema do Kafka aí, um pouco mais complicado, um pouco mais didático para todo mundo. Beleza? Ah, estou vendo o chat do pessoal. Vai puxar isso. Ah, beleza. Agora estou vendo. O editor está aí. Pô, o editor aqui. Eu não reencar. Show. Acho que está com um delezinho aí. A gente não está vendo tantos mensagens. Mas, pessoal, esse meu talk vai ser... Esse meu nosso bate-papo aqui, não vai ser tão hard, codando, hard, assim. Acho que é um pouco mais ops. Como a gente fala de Kafka, a gente vai muito para o lado de... Eu queria focar mais um lado de operação. Obviamente, vou mostrar vários conselhos que é muito importante para os devs estarem entendendo aí. Mas, eu vou também mostrar muita coisa de ops. Mas, é muito importante que devs estejam compreendendo bem esses conselhos para você tomar as decisões corretas na parte arquitetural, que eu acho que é um dos grandes que eu canhar, e de aqueles com quem trabalha com Kafka, que é exatamente estar trabalhando em forma cirúrgica na hora de montar a arquitetura do Kafka. Quem trabalha com Kafka sabe que ele é muito sensível a arquitetura dele. Se você não estiver com os conceitos bem fundamentais, você acaba pecando aí em alguns pontos, beleza? Deixa eu compartilhar a minha tela aqui. Vamos lá, pessoal. Vamos começar do começo. O que é o Kafka? Então, se você vir aqui buscar a parte Kafka na internet, normalmente você vem aqui para essa página da comunidade do Kafka mesmo, uma parte Kafka. Mas dando uma lida nesses conceitos aqui, eu confesso que a primeira vez que eu entrei aqui, tentando entender por mim mesmo o que era o Kafka, eu li, vi um monte de coisa e não entendi nada. Basicamente, sabe que a resposta se depende? Se você pergunta alguma coisa e a pessoa responde, depende. Foi mais ou menos o que eu entendi aqui desses conceitos que eu vi na página. Então, deixa eu tentar explicar talvez de uma forma mais didática que a gente vai passando por esses conceitos, mas talvez numa ordem um pouco mais natural. Então, a gente faz essa baliza e depois a gente vai para um problema como que a gente escala o Kafka e tal, que a gente vai naturalmente chegar no... Por que faz sentido usar o Kubernetes ou não? Quando e etc, beleza? Então, vamos lá. Para começar falando nisso, pessoal, vou falar do PubSub. Acho que todo mundo conhece esse pattern um pattern onde você envia uma mensagem e outras aplicações fazem um Subscribe de uma mensagem e estão recebendo essas mensagens. O legal que está usando o PubSub é que quem está produzindo a mensagem não precisa conhecer quem está consumindo essas mensagens. Então, você tem uma arquitetura distribuída e desacoplada. Então, por exemplo, vamos falar no sistema de uma eCommerce. Então, a gente tem um pedido de compra entrando aqui. Então, a gente pode ter, não sei, processando pagamento aqui. A gente pode ter um outro sistema responsável pelo entrega desses pacotes. A gente pode ter um outro sistema que faz a parte de data analytics, para ver, por exemplo, quais são os produtos que estão mais em alta, aquele e-mail, etc. processando isso, etc. Então, a gente tem esse pattern um pattern antigo. É uma coisa que a gente usa tem bastante tempo. Só que a gente não tinha meios de tornar isso tão distribuído e de maneira acho que tão fácil assim. Então, o Kafka teve algumas sacadas durante sua implementação. A primeira sacada que eu acho que teve do Kafka foi em dividir as mensagens em tópicos. Isso permitiu com que você escrevesse essa mensagem aqui dentro desse canal e ela fosse dividida em áreas diferentes de armazenamento. Então, ele armazenava em nenhum lugar, em um que a gente chama de partição, e essa partição era replicada entre outros brokers, outros máquinas. E... Opa! Abrir uma coisa aqui. Espera. Então, isso permitia com que você tivesse não só uma alta disponibilidade dessa mensagem, mas que você conseguisse consumir isso de maneira paralela também. Então, isso já começou a trazer uma distribuição maior, que eu conseguia ler de maneira paralela essas mensagens. E isso foi evoluindo para algumas outras coisas que a gente vai comentar. Então, por exemplo, imagina nesse exemplo que a gente estava dando aqui, onde eu consigo, por exemplo, estar consumindo essas mensagens naquela parte de data analytics, isso seja um processo demorado. E eu quero paralelizar essa minha leitura do Kafka aí. Então, eu posso estar nesse mesmo subscribe aqui, criando várias instâncias, ou seja, eu posso criar um grupo dessas aplicações de data analytics, e essas aplicações podem estar paralelizando esse mesmo processo, que é o conceito de grupo que o Kafka implementou também. Então, essas sacadas do Kafka foi tornando ele popular e foi diferenciando ele dos outros brokers que a gente tinha inicialmente. Um outro fundamento que eu acho que foi uma sacada boa do Kafka e nesse processo. O Kafka começou a armazenar a mensagem que a gente colocava aqui nesse top. Então, isso permitia que você fizesse o reprocessamento desses mensagens. Então, essa mensagem a gente ficava armazenada ali com um top fit file system, que a gente vai voltar nesse top fit file system, que isso aí é sempre um top fit caso de confusão. E ele permitia que você navegasse de maneira histórica nesses eventos e estivesse reconsumindo ele ali sempre. Então, por exemplo, se eu fosse... Imagina que eu estou aqui com um top fit que é um fit de notícias, por exemplo. Eu poderia não só estar capturando as últimas notícias, mas eu quero consumir as notícias das últimas três semanas, das últimas quatro semanas, o que é uma diferença fundamental dos outros brokers que a gente tem. A gente não consegue fazer esse tipo de consulta nos eventos que estão sendo armazenadas. Então, isso vai dando uma característica pro Kafka que exatamente é essa. Ele armazenha esses eventos, guarda essa maneira com que ele guarda, pode... é parametrizada, você define o quanto tempo, o qual o tamanho, e permite que outras aplicações estejam não só consumindo esses eventos, mas decidindo como que ele consome esses eventos. Então, assim, fundamentalmente o Kafka é bem isso. Só que a maneira com que esse esquema de partições que eu falei permite o Kafka escalar, faz ele ser uma plataforma realmente usada para grandes processamentos de dados. Então, ele acaba sendo muito comum para casos de uso de... de inteligência artificial, por exemplo, log aggregation, etc. Ou seja, sempre que você tem um volume de dados muito grande, você acaba... uma arquitetura desse tipo aqui acaba sendo muito útil. Beleza? Então, assim, se você parar pra pensar hoje, hoje em dia não precisa ser uma aplicação muito popular para a necessidade de uma escalabilidade considerável. Então, se você fizer uma aplicação aí que talvez ela fique viral por alguns dias, pronto, já... talvez fazendo da maneira antiga, porque como que o pessoal fazia? Assim, era um microserviço fazendo requisições HTTP síncronas para outros microserviços. Então, desse jeito, realmente fica muito difícil de você ter essa escalabilidade massa e acaba prejudicando o seu desempenho. Então, se você voltar aqui para a praia do Kafka, vocês lembram que eu falei que ele armazena os dados em Fire System. Aí você fala, putz, caramba. Fire System, né? Lento pra caramba, tal. E a gente veio com essa premissa durante muito tempo. Mas o Kafka, se a gente falar na documentação, se a gente falar na documentação do stream, deixa eu mostrar aqui uma imagem dizendo o Kafka que eu queria buscar para com vocês. Você dá uma olhada aí nas entranhas do Kafka, como que ele armazena as mensagens? Ele armazena as mensagens dentro de uma partição. Eu vou explicar para vocês, mais ou menos, de maneira bem rápida, que isso cinta o que são esses outros pontos. Mas eu queria chamar atenção para esse ponto particular. Está vendo que ele está armazenando as mensagens aqui dentro dessa partição e as mensagens de maneira serial. É um formato de log mesmo. Ele está sempre fazendo a pende-on. E qual é o ponto, pessoal? Quando a gente está usando Fire System e a gente usa essa estrutura de log, ou seja, a gente está sempre fazendo a pende dentro, o sistema operacional funciona muito bem com esse tipo de acesso ao Fire System. Então, se você estiver usando o sistema que ele faz a pende-on, usando esse tipo de log e do Fire System, o sistema operacional sabe como otimizar isso de maneira absurda. Então, vou te contar um exemplo bem didático. Se você tem uma máquina local com 32GB, 64GB, você vai ver que muitas vezes sua aplicação está usando 20GB, 16GB, não sei disso. Mas você vê que a sua outra memória, o restante da sua memória, não está disponível. Ele está alocado. É o tal do read-a-head. O que o sistema operacional está fazendo? Quando você tenta ler um bloco, ou um dado dentro de uma partição, ele traz os blocos à frente à medida que você tem memória disponível. Então, quando você vai ler esse dado, você não está lendo o Fire System, você já está lendo ele da memória, que é o tal do pende-cache. Então, na verdade, você não está tirando os dados, principalmente os dados quentes do Fire System, você já está tirando esses dados diretamente da memória, por isso que acaba sendo tão rápido. Então, tem muita gente que fala assim, eu acho que tem muita memória para o Kafka, mas a pessoa está olhando para a JVM, mas o grande sacado não é os dados que estão na JVM. Você tem que olhar para os dados que estão no pende-cache do sistema operacional. Porque é isso que vai deixar o seu Kafka muito mais performático em relação a você deixar uma memória pequenininha e ele acessando aquela memória ali de cada. Beleza, até agora, pessoal? Ah, acho que não tenho uma mensagem com o chat, beleza? Tá bom. Então, assim, eu vou fazer um Kafka 101 aqui, fica em cinco minutos, só para balizar todo mundo aí. Então, o Kafka, a estrutura, eu vou dar uma sapidona dele aqui. Cadê? Então, é muito parecido aquela imagem lá que você falou, só para apresentar uns conceitos para... Se vocês entenderem esses conceitos, fica muito mais fácil depois vocês montarem a arquitetura de vocês dentro do Kafka. No Kafka, você vai ter o conceito de Brokers, que são como máquinas, e você vai criar os seus tópicos, muito provavelmente, vocês já estão querendo esses tópicos, quando a gente fala dessas partições, é onde serão replicadas as mensagens, beleza, quando elas chegarem. Então, a partição é onde fatas essas mensagens estão sendo armazenadas, mas, geralmente, para a quesita de tolerância, falhas, a disponibilidade, você tem vários Brokers. E, por consequência, o seu tópico vai ter várias partições, e essas partições vão ser replicadas no tópico 1, e esse tópico está sendo replicado nesses vários Brokers, então, vou criar três tópicos aqui, o tópico 1, que tem três partições, o tópico 2, que tem três partições, e aqui o tópico 3, que só tem um. Então, quando você vai ler essas mensagens ou produzir essas mensagens no Kafka, o Kafka elege um líder. Então, você tem sempre uma partição que a líder e as outras são fólogas, ela está sendo replicada, e consumindo as mensagens só da esquipação que a líder. Então, isso é um conceito muito importante também para a gente entender. Então, aqui, por exemplo, tem um que o tópico 1 está com líder no Broker A, o tópico B, o líder no Broker C, e o tópico 3 no Broker C. Então, se você tiver uma disponibilidade do Broker C inteiro, pessoal, o que acontece com o tópico 1? Nada, ele simplesmente continua servindo as mensagens do meu partição zero aqui do Broker A. Com o tópico 2 também nada, porque aqui o líder dele estava no Broker B, mas o tópico 3, ele foi afetado, ele está disponível até que esse Broker seja restabelecido. Então, assim, você não perdeu mensagens, tem muita gente que vai assim, você está tendo perda de mensagens. Não é bem perda, né? Você não está servindo e nem recebendo nada, mas você não perdeu. Quando esse Broker restabelecer, você vai continuar recebendo as mensagens normalmente, beleza? Então, assim, se tiver uma outra disponibilidade do Broker B, agora sim, você teve um líder afetado aqui e o que vai acontecer é simplesmente ele vai passar esse líder para o tópico 2 e vai estar tudo ok, beleza? Então, é assim que o tópico, que a mensagem chega no CAF, que ela chega em uma partição, é distribuída para as outras partições e é eleito onde é lido e consumido esses dados diretamente do B, beleza? Então, produzir, né, sempre naquele esquema de de aprende onde, né, etc. Consumir, quando você vai consumir uma mensagem do CAF, como eu falei que você pode consultar essa mensagem, né? Então, você pode dizer como que você é consumir, né? Se você quer consumir somente as últimas, se você quer consumir a partir de um offset específico, né? Então, quando se armazer na mensagem, você vai ao offset, tá vendo? Que é a posição que ela tá ali dentro dessa sua estrutura de log, dentro da partição. Então, você fala assim, quero consumir a mensagem a partir do offset 4. Então, ela vai vir aqui 4, 5, 6 e vai consumir nessa hora. Você pode consumir por exemplo, de trás para frente. Então, quero consumir 4, 3, 2, 1, 0, por exemplo, né? Então, depende muito de como, o que que a sua aplicação quer fazer, mas ele te dá a total liberdade para estar navegando nesse stream de eventos que você tem aqui dentro do CAF, beleza? E mas você, para consumir a mensagem do CAF, né? Só você chegar com um consumer, né? Você tem que ingressar em um consumer group. Porque assim, para produzir mensagem no CAF, que é muito simples. Você pode ter vários prodúcios produzindo ele prodúcios que você não vai ter meio que problema nenhum, né? Agora, para consumir não é tão simples assim, tá? Você tem algumas limitações. Então, assim, por exemplo, você vai consumir a mensagem, você ingressa um consumer group desse aqui e começa a consumir essas mensagens de diferentes partições. Então, se eu tenho um consumer só, ele tá consumindo essa mensagem de diferentes partições, das 4 partições. Se eu tenho 2 consumers dentro do mesmo grupo, eu consumo de 2 partições para esse consumer e 2 partições para esse consumer. É, e assim, pessoal, só falando quando que a gente tem vários consumidores dentro do mesmo grupo, é quando a gente quer fazer paralelismo, né? Ou seja, eu quero consumir essas mensagens de maneira mais rápida, né? Mais ou menos aquele exemplo que eu dei do data analítico. Então, imagina que eu tenho lá antes, eu tinha uma instância fazendo aquele processamento, agora eu quero ter 10 instâncios para processar esses eventos mais rápido. Para você ter essas 10 instâncios processando esses eventos mais rápido e não consumir os mesmos eventos tem que estar dentro do mesmo grupo. Então, quando você vai adicionar no Consumers aqui dentro do mesmo grupo a gente está falando de paralelismo, beleza? É sempre que a gente quer paralelismo? Não, depende do caso de euro, beleza? Então, se tiver 3 consumers vai ser basicamente isso. Então, assim, basicamente aqui a ideia é que Consumers não compartilham a mesma partição. Então, isso evita que a gente esteja consumindo o mesmo dado de maneira repetida. Caso eventuais fale que a gente não vai explorar aqui, beleza? Mais de maneira, digamos assim, a hora of the box você não deveria consumir mensagens repetidas dentro desse mesmo se você estiver dentro do mesmo grupo. Tem uma exceção aqui que é o seguinte se você tiver mais... Desculpa. Se você tiver mais Consumers aqui então aqui eu tenho 4 partições, né pessoal? Então, assim, esse design do cático traz uma limitação, né? Que é qual? Se você tiver mais Consumers do que partições o que vai acontecer com esse cara aqui? Ele simplesmente vai ficar offline, né? Esse seu consumidor, ele vai ficar parado. Não vai ser entregue nenhum tipo de mensagem pra ele. Então, quando você poder definir quantas partições você tem muito importante você saber que esse é o número máximo de Consumers que você vai ter dentro do mesmo grupo. Beleza? Tá. Então assim, esse é o resumão, né? Pra fechar esse resumião eu vou falar aqui do do do Mirror Break, né? Então, assim, eu tenho um Data Center e quero replicar mensagens pra outro Data Center, né? Existe um componente que é o Mirror Break que nada mais é do que um Consumidor que consome mensagens dentro de um top e põe dentro de outro top só que dentro de outro Data Center. Então, o Kafka usa a mesma estrutura que ele tem de Consumers e Producers pra replicar mensagens entre diferentes Data Centers, né? Sendo que aí tem mecanismos de sincronismo, né? Replicação de Opset, etc. É um pouco mais complexo que isso. Mas, assim, falando de bem alto nível é assim que funciona. Beleza? Então, pessoal, se assim a gente a... em... em a noite, né? O Kafka é essa estrutura, tá? Só que é o que que aconteceu. Quando você vai fazer o deployment do Kafka em ambientes tradicionais, etc., né? Você geralmente vai abrir os seus terminais lá, vai subir as suas instâncias do Zoom Keeper, né? Parecido com isso aqui, né? Você sobe as suas instâncias dos Zoom Keepers, atribui um ID cara, qualquer tipo de autenticação, etc. Depois que isso tá pronto você sobe os seus Brokers, né? Então, Kafka, pelo menos ainda, né? Tá quase saindo aí uma versão do Kafka que não vai depender mais dos Zoom Keepers, né? É... Mas, por enquanto, ainda é assim. Então, você vai ter os seus nós do Kafka em execução e... e ele vai sincronizar com o Zoom Keeper, né? Você tem cada broker desse que tem o seu ID certinho, que você informa para o Zoom Keeper e ele sobe. Então, assim, você faz esse processo bem manual mesmo, tá, pessoal? Então, você vai lá na CLI subindo cada um dos Brokers, etc. E você vai tentando orquestrar isso tudo. Então, acaba sendo meio difícil, tá? Principalmente a manutenção de um ambiente desse. Imagina que cada célula dessa aqui é uma máquina diferente, beleza? Que tem partições, tem tópicos e etc. Como a gente estava comentando. Então, qual que foi, assim, qual que é o grande lance, né? Então, assim, por que que o Kubernetes entra nessa jogada, né? Qual que é o sentido de ter o Kafka dentro do Kubernetes, né? O Kubernetes ele tem alguns fundamentos, né? Muito interessantes, por exemplo. Que são os genélicos para qualquer aplicação. Então, por exemplo, quando uma aplicação ela fica indisponível é um padrão o Kubernetes vai lá e restabelece essa aplicação. Ou seja, ele faz um restart nessa aplicação, né? Então, é quando você quer fazer um scaling de uma aplicação, né? Então, é muito simples, você vai lá no seu reputation controller, etc. Clica na setinha e ele escala novos novos essa aplicação. Então, a grande ideia de ter isso dentro do Kubernetes é entregar ao Kafka os recursos que o Kubernetes tem por design, né? Então, a ideia é tirar proveito de todo, assim, do melhor dos dois mundos, né? A gente continua tendo todos os benefícios do Kafka mais as capacidades nativas do Kubernetes nesse novo ecossistema, né? Então, assim, por exemplo, lá, como que tinha falado para vocês? Cada nozinho desse aqui, ele tem um storage atrelado aí, né? Ele está persistindo num disco. O Kubernetes, por padrão, se esse nó sai de um, de uma máquina e vai para outro, você consegue levar esse disco junto. Se você fosse fazer isso usando máquinas audituais, até o trabalho, aquela sendo bem maior. E o Kubernetes praticamente é por gameplay, né? Se o Kubernetes vai configurar direitinho, você não vai ter problemas para fazer isso, beleza? Então, como que seria esse casamento aí, né? Então, basicamente o no Kafka, dentro do Kubernetes, né? A gente tem ele sendo provida através do projeto Open Source Streams, né? Então, para quem não conhece, né, pode vir aqui já visitar essa paginazinha que eu entrei no começo da apresentação, né? Então, é exatamente o Kafka dentro do Kubernetes, né? A comunidade é bem legal, tá pessoal bem ativo também. Então, você pode estar vendo aí a melhor forma que você consegue ficar, tá? Então, ah, seja escrevendo um blog post, ceno, com código mesmo, né? Seja, enfim, tem diversas maneiras de você estar colaborando, documentação, etc. Vou voltar aqui, então, aqui, por exemplo, pessoal, quando, qual que é a grande sacada, né? Dentro do Kubernetes existe o Custom Resource Definitions, né? Que os Custom Resource, que são recursos customizados, né? Então, do mesmo jeito que a gente tem um pod dentro do Kubernetes, que a gente tem o serviço, né? O service, depende mesmo de que a gente tenha um halter, etc. Um ingress, etc. Tudo isso são resources já definidos pelo Kubernetes. A gente pode criar resources customizados, que são resources criados pela gente mesmo. Então, só que eu quiser criar um recurso do tipo Rodrigo lá dentro, eu posso. Então, basicamente o que foi feito nesse projeto é criar um cursor resource, né? O que foi feito aí, que seria o do string. Então, foi feito esse operato e basicamente criaram definições. Então, a gente vai ver que quando a gente for criar instância do Kafka, você vai ver que eu tenho uma definição do tipo Kafka agora dentro do Kubernetes. Então, o que eu acho legal é isso, é que através desses Custom Resource, você apresenta Kubernetes maneiras de operacionar recursos que não são recursos padrões do Kubernetes. Então, aqui no caso, a gente está introduzindo Kafka por dentro do Kubernetes e está falando assim, sempre que alguém fizer um deployment do recurso do tipo Kafka, um recurso do tipo tópico, um recurso do tipo Kafka User, você vai operar dessa maneira aqui. Então, toda essa lógica está escrita aqui dentro do operator, beleza? Então, a gente tem esse Kafka Cursor Resource e ele que vai gerenciar, por exemplo, um deployment do Kafka, você sempre tem que fazer o deployment do suqip primeiro, depois do Kafka Cluster e depois você cria outros CRDs, né? Quando você vai fazer, por exemplo, um update nesse cluster é o operator que faz isso de maneira coordenada. Então, basicamente, o que ele vai fazer? Ele vai falar, bom, eu primeiro atualizo o meu Custom Resource definir meus Custom Resource depois eu tenho que atualizando cada uma da célula dos suqip quando elas já estiverem pronto, eu vou começar o Roaring deployment ali dentro do Kafka Cluster e isso vai permitir que eu tenha um deployment sem disponibilidade. Então, tudo isso é a inteligência que é construída aqui dentro desse operato, tá, pessoal? Então, que nem eu tinha falado do processo, se vocês fazem o deployment do Kafka de maneira tradicional, assim, gerenciando os gerenos, só aqui nessa definição só aqui nessa definição vocês teriam que se preocupar com toda segurança do suqipper, com toda segurança dos Kafka Brokers, ou seja, como que os produtos e o consumo se consumiriam, se configurariam aqui como que esses instâncias do suqip se comunicariam entre si como que o suqip se fala com Kafka e como que o Kafka fala com o próprio sinoso do Kafka são praticamente cinco pontos aí que você teria que configurar de somente de segurança. Então, nisso você pode definir se é excesso ou se é plain text, etc. Depende da maneira se vai ser certificado digital, etc. Beleza? Então desculpa pela introdução super demorada já foi mais vantagem do meu tempo. Então, vamos a obra aqui, né, eu vou mostrar pra vocês isso na prática como que a gente faria aí pra estar, por exemplo, provisionando um cluster Kafka desse e algumas operações básicas que a gente faria aí dentro dele. Beleza? Então, a primeira coisa que eu vou fazer é criar um name space aqui dentro do OpenShift, beleza? Então, aqui eu vou criar um name space chamado KafkaNet. Então, agora que a gente tem um espaço separado, por exemplo, a gente vai falar que é um quartinho aqui dentro do OpenShift a gente consegue criar nossas próprias coisas, instanciar nossas próprias coisas. Tá o primeiro ponto é a gente instalar o operator do strings lembra do custom resource que a gente falou lá? Então, a gente instala isso através do operator hub, né, então estou aqui no meu Kubernetes, no OpenShift eu vim aqui no meu operator hub e vou instanciar através desse meu operator hub que é um catálogo de operator, beleza? E o strings base é um operator. Então, eu vim aqui e falo que sim, aí ele me dá um detalhamento básico do projeto, né, onde eu encontro mais informações, as últimas features, etc. Eu sempre gosto, sempre que dá uma lista nesse aqui que mostra um resumo legal das últimas versões. Então, passa um install, ele me pergunta qual que é o canal, né, que eu quero a última versão estável, tá bom pra mim e eu quero instalar só nesse name space que a gente tá brincando aqui, que é o KafkaNet. Vamos instalar ele cluster-wide, né, no cluster inteiro. Então, basicamente, o que ele tá fazendo é fazendo a instalação do operator, né, uma vez que a gente tiver o operator instalado, aí sim a gente consegue criar as nossas definições, né, por exemplo, que é um Kafka cluster, criar um tópico, criar um usuário, etc. como a gente tava falando, né. Então, um operator, ele fica um tempo inteiro, né, um operator, ele fica vendo qual que é o que é que você definiu contra o que que está em execução e ele sempre fica reconciando isso, né. Então, esse é o grande papel do operator aqui. Deixa eu ver se tem alguma mensagem no chat, por enquanto. Ah, agora eu achei o chat. Eu tava vendo o chat errado, tem uma opção. Beleza. Vou voltar aqui pro nosso OpenShift. Tá beleza, a gente tem um operator aqui, ele tá instalado. Eu vou mudar pra esse perspectivo de developer, que é um perspectivo um pouco mais amigável pra gente, e vou agora fazer o deploymente do meu custom resource definition, lembra? Então, pra fazer isso, eu vim aqui adicionar. Eu falo que é um recurso, né, que é baseado no operator e aqui ele me dá vários. Eu quero esse Kafka aqui, tá vendo? Então, exatamente é um cluster Kafka. Eu simplesmente preciso clicar aqui, criar em create. Ele vai me dar duas opções agora, que é como criar usando uma estrutura de formulário, né. Tem gente que prefere preenchendo formulário e tem gente que prefere ir direto numa estrutura tipo enema, né. Então, enema é legal quando você já tem ele definido. Por exemplo, você só vem aqui e cola esse enema diretamente e fala, ah, eu tenho um já tudo definido aqui e vou simplesmente colar. Mas vamos comentar alguma coisa, não vou passar pelo esforço e viu não, tá pessoal? Vou vim aqui direto no enema, pode ser. Então, aqui eu tenho o kind Kafka. Então, lembra que eu falei que o padrão não existe esse kind Kafka no Kubernetes, né. Então, graças aí ao nosso pereito agora, o Kubernetes entende o que é um objeto Kafka, beleza. Então, aqui o nome, né, que eu dei pra ele aqui, qual que é o meu fator de replicação, né. Vou colocar três. Não vou passar por todos aqui porque tomaria muito tempo. Mas basicamente lembra aquelas, aquelas autenticações que eu falei pra vocês, que são mais ou menos um cinco, que a gente define ali entre os brokers, entre os o keepers, etc. Eles meio que já vêm definido aqui pra gente já usando TLS, né, para as aplicações, etc. Então, isso é bem interessante porque economiza bastante tempo da gente, né. Então, a gente tá fazendo um deployment de um Kafka aqui com um clique de botão, assim a gente não definiu nada, só tô mostrando pra vocês aqui, né. Então, ele já tá fazendo com alta disponibilidade, né, com três réplicas. Histórias, eu tô fazendo fm, né, pra título de demo aqui, mas eu poderia estar usando qualquer tipo de storage que eu, que eu quisesse aqui. E os keeper também, eu tô fazendo um deployment dele com três réplicas, beleza. Então, eu vim aqui, create e a partir desse momento a gente vai fazer aqui a ação de um CRD, tá, que é a definição do Kafka em si. Então, ele vai fazer aquela execução da ordem que a gente tinha visto lá atrás, pessoal, que é o que? Bom, eu faço o provisionamento do meu Custom Resource, né. A partir do momento que eu faço o provisionamento do meu Custom Resource, eu vou fazer o provisionamento dos o keepers. Lembra que a gente colocou três instâncias lá? E os o keepers precisam estar disponíveis primeiros para o deployment do zookeeper. Uma vez que o zookeeper tá pronto, tá vendo, com as o zookeeper com as o mais escuro, né. Quer dizer que ele já tá pronto para receber requisições. Agora ele começa o provisionamento dos brokers, sim, né, que é onde reside os tópicos, as mensagens, etc. Então, esperar aqui um pouquinho do deployment. Então, beleza. Aqui eu tenho, então, o meu zookeeper, né, instanciado, o Kafka broker também tá deployado, etc. E o legal, pessoal, é o que eu falei pra vocês. Aqui a gente já tem a nossa estrutura, né, que ele tá só deployando o restante daqueles Custom Resource que eu tinha comendo as vocês, os tópicos, os usuários, etc. Mas aqui eu já tenho toda a estrutura do Kubernetes funcionando, né. Então, sim, isso que eu acho fenomenal, né, que, por exemplo, posso vim aqui já na parte de monitoramento e ver como é que tá o uso de... Ainda tá, ainda não pegou, né. Mas, deixa eu ver se pegou desse aqui. Que tá muito fresco, né. Esse aqui já tá um pouquinho melhor. Deixa eu ver se já tem algum âmbito aqui. Aqui tá começando a capturar, entendeu? Então, sim, a gente já tem informações de uso de memória. Aqui ainda não, porque tá muito recente, mas ainda tá só não tá pintado, tá vendo? Então, a gente consegue ver quanto o CPU tá usando, que tem uma segunda transmissão de pacotes, bandas, etc. E nada disso é do Kafka. Tudo isso é do Kubernetes, né. Então, assim, é um das grandes vantagens que eu acho, por exemplo, você vim aqui nessa instância. Bom, o que acontece, por exemplo, se essa minha instância aqui sofrerá um crash, por exemplo. Ou vim aqui e vou deletar esse pod, por exemplo. Então, ah, essa minha instância aí, eu não sei se foi uma interrupção lá, teve um GC que ferrou lá, alguém teve que ir lá e reiniciar. Então, automaticamente o Kubernetes vai lá e vai reconciliar esse pod, ou seja, vai reproduzionar ele já levando stories, tudo bonitinho aí do gente que a gente já conhece para nossas aplicações. Então, é a gente aproveitar do melhor que o Kubernetes tem para oferecer. Então, eu costumo falar de um casamento aí dos dois mundos. Então, a gente tem a extração do melhor dos dois. Beleza. Enquanto ele reconciliar aqui, eu vou mostrar uma outra coisa que é, por exemplo, se a gente quisesse, em vez de ter três cafas, a gente ter cinco. Cara, acaba que é muito simples, porque assim, primeiro a gente fez o deployment do cafas praticamente com um click de botão, então não teve trabalho para fazer. A gente pode vim aqui nesse cara e editar aquele mesmo resorcio definitivamente que a gente fez. A gente pode simplesmente estar vindo aqui e falando assim, aqui no Zulkip eu tenho três réplicas. Aqui para os meus brokers eu tenho três também. Então, em vez de três agora eu quero cinco. E reconceito. E automaticamente o Kafka vai estar cuidando de fazer esse alt scaling desses nossos recursos e para cinco pods. Demorando um pouquinho aqui, mas ele vai desenrolar. Ele vai estar criando aquela outra instância que caiu. Beleza, então assim, para a gente não perder tempo, ele vai, eu acho que ele vai criar a cinco lá, tem, às vezes tem um pequeno probleminha que quando, por exemplo, como eu deleitei uma instância, ele vai falar que aquela não é a última versão que eu estava alterando. Pode ter um pequeno probleminha. Mas vamos seguir com a demo porque a gente tem muito pouco tempo. Beleza? Então, eu vou pegar uma aplicação que eu tenho também, que eu acho bem didática para a gente estar fazendo deployment aqui. Beleza? Basicamente agora eu posso vir aqui no meu console? Você está vendo o meu console? Está pequena letra. Cubic.tl GetCafca CafcaDemo Então, agora eu estou listando o recurso Cafca que eu tenho dentro desse meu CafcaDemo aqui. Então, como eu estava mostrando para vocês, eu poderia vir aqui e estar fazendo Cubic.tl GetCafca Que era a mesma operação que eu fiz via interface para poder fazer isso aqui. Você vai procurar aqui quantos... está cinco réplicas aqui mesmo. Então, ele está se resolvendo desse crash aqui. Eu não sei o que está acontecendo aqui, mas ele está tentando se resolver e, assim que ele conseguir, ele vai escalar isso e ir para cinco. Beleza? Sem perder tempo, vamos fazer o seguinte. Eu vou fazer um deployment de uma aplicação. Eu vou fazer o deployment aqui, que ele não está conseguindo desenrolar ali, mas infelizmente a gente não tem tempo para ficar esperando. Eu vou fazer o deployment e vamos fazer para que funcione. Beleza? Então, sim, pessoal. Na verdade, antes, eu queria fazer alguns tests. Então, por exemplo, agora que eu tenho meu Cosset profissionado, posso estar criando um tópico, por exemplo. Então, está vendo que já tem alguns tópicos que o Cafca cria por padrão, e o tópico novo, por exemplo, eu poderia fazer diretamente aqui, também, pela interface. Eu posso fazer aqui diretamente, pulando o Emel, ou eu posso vir aqui, no mesmo esquema que a gente fez. Então, vira padrão, né? Eu vim aqui, procuro pelo Operator, procuro, por exemplo, a estrutura cátrica tópico, está vendo? Então, agora eu vou fazer o deployment de um cátrico. Agora, diferente daquela estrutura de Emel e do Force Topic, beleza? Eu vou colocar três pações, cada duas lá, tenho um empalho, vou fazer dar certo aqui, que a gente terminou. Aí, viu lá que eu falei, ele fica tentando, é legal, do Kubernetes, é isso. Como eu falei, que o Operator fica reconciniando, então ele fica escutando, fica escutando, tentando resolver aquilo, tentando resolver quando ele resolve, vai embora. Então, ele resolveu aquela instância que estava em falha da instância, beleza? E agora, se eu vir aqui na minha lista de tópicos, eu tenho o meu Force Topic também queado. Então, já está pronto para receber mensais, né? Para quem é mais raiz, você pode estar fazendo a gerência do Kafka pela linha de comando, como você fazia no Kafka tradicional lá, né? Então, por exemplo, que basicamente eu estou fazendo é o que, entrando no meu Name Space, que é o Kafka demo, pegando o meu... Deixa eu sentar aqui as minhas variáveis de ambiente, perdão. Comsetando algumas variáveis de ambiente para ficar mais fácil que a nossa linha de comando, senão o comando fica muito longo, beleza? Então, por exemplo, eu posso listar os tópicos da maneira que eu faço no Kafka tradicional, usando os binários lá do Kafka, beleza? Então, aqui eu estou fazendo o que? Estou executando dentro do POD, meio que é o POD do Kafka mesmo, estou executando um binário que se chama Tópicos, onde eu peço para ele listar a minha estrutura de tópicos. Então, está vendo que ele listou aqui o meu First Top? Vamos falar, mas eu prefiro criar o tópico na mão. Não tem problema aqui, gente. Vamos fazer a criação de um segundo tópico. Vai render aqui, beleza?