 Hello, everyone. Welcome to KubeCon. My name is Jakub Schultz and I'm one of the maintainers of the project called Strimsy and in this lightning talk I will talk about what is Strimsy and about the thing we are working on most these days, months and that's Zookeeper removal from Apache Kafka. If you don't know Strimsy, we are a CNCF incubating project. We actually moved to incubation from Sandbox quite recently so we're a that's a big achievement for us and we are of course open source project open source community under the Apache license 2.0 and we focus on running Apache Kafka on Kubernetes in a most easy and Kubernetes native way as possible and for that we provide a bunch of operators. We have one operator which kind of runs all the different Kafka server components such as the brokers, mirror maker, connect, but we have also some other operators for managing users or topics and we have also some smaller tools and utilities for for making your life easier when you run Kafka on Kubernetes. We try to cover all the different things there are to the Kafka application life cycle from the initial deployment and installation, operations, monitoring and and the things such as security and we of course try to also play nicely with all the other cloud native projects and all the other open source projects and try to integrate them as much as possible instead of reinventing the wheel and the thing we are working on most lately and which I will really focus most right now on is in the top left corner where you see the zookeeper and the Kafka part that's where there are some major changes happening and that's where a lot of the work is. So if you run Kafka before you probably know that for a long time it has been always dependent on zookeeper for managing metadata bootstrapping the clusters, electing the controller node and so on but it's changing and zookeeper is being replaced by something what's called craft which stands for Kafka raft and it's kind of Kafka's own take on the raft protocol or algorithm for keeping the core room and this is something that's working progress since 2019 and it's still going on and that's not because people are lazy or slow but it's because it's really huge effort with a lot of changes both in the Apache Kafka project itself but also a lot of changes for us in in streams in which we have to adjust the motivation for that is a to get rid of zookeeper zookeeper does some things really great but it has also some issues so yeah that might be helpful but also we want to simplify the deployment and the operations of Apache Kafka because it doesn't make much sense that you need to know two different systems two different projects how to run them how to operate them just to run Apache Kafka so this should kind of simplify things the way it is implemented is that the Kafka nodes will have two different roles one of the role is the controller role which is basically the part of the Kafka node which will take over the zookeeper responsibilities managing the core room managing the metadata and the second role is the broker role which is what's used to deliver the messages between the clients and what's interesting is that these roles can be also mixed in the same process in the same jvm in the same container so that gives you quite a wide range of architectures for your zookeeper as Kafka clusters where you can start with this most simple example where you have just a single container single pot doing both roles and doing everything if you want some high availability you can just kind of scale it and add more containers running in parallel to give you the availability but if you want to scale more then it doesn't make much sense to keep scaling the controller so you can add just some additional nodes only with the broker roles and then finally if you have some bigger clusters for production it might make sense to have just the dedicated containers or pots for the for the controllers where you can exactly control how many resources they will get and then you have the separate brokers and that's kind of the architecture we expect most for production clusters but in Strimsy in general we want to support all of these architectures because we have people using Strimsy for different use cases and we also want to allow transitioning between them because that's how you can grow your cluster with your project as for the timeline last week really Strimsy 04 day which in terms of the craft or zookeeper as Kafka support was a major release because it now enables the craft support by default so you can just decide on your own whether you want to use craft or zookeeper without enabling any alpha level feature gates and it's also the first version where we added the support for migration of the existing zookeeper clusters to craft so that you can try that out if you have any existing clusters there are still some limitations I don't think the limitations are necessarily production critical but it's good to be transparent about them so that everyone can decide whether they think that this is ready for production or whether they want to wait a bit longer one of the limitations is that the scaling of the controllers has all kind of limitations right now also the unclean leader election right now is not supported these are basically in the Apache Kafka project itself on the Strimsy side for example right now we don't support the j-bot storage in the craft mode but these limitations they should be addressed in later this year basically so yeah even if you think that these are blocking for you for production right now then soon this should be gone as well and that's it for my talk as already said if you see me anywhere here around the floor feel free to talk to me if you have anything about Strimsy or Kafka on Kubernetes and if you have the all access pass then also this afternoon I have a talk about this on the data on Kubernetes day which goes a bit more into detail about how the things work thanks