Interview with Shaik Zoheb

Dario: Shaik, it’s great to have you here. You’ve been a Kubernetes platform engineer for quite some time, and now you’re a Kamaji ambassador. How does it feel to be part of this journey?

Shaik Zoheb: Thanks, Dario! It’s honestly an incredible experience. I’ve been working with Kubernetes for years, but discovering Kamaji felt like uncovering a hidden gem. Becoming an ambassador for Kamaji is a privilege because it allows me to share how it simplifies the complexities of Kubernetes control planes. Seeing how it helps organisations overcome real-world challenges keeps me excited every day. Plus, I get to work with an amazing community of engineers who are pushing the boundaries of Kubernetes management.

Dario: That’s amazing to hear! How did you first come across Kamaji, and what was the problem you were trying to solve?

Shaik Zoheb: I was researching solutions for hybrid control planes. The challenge was ensuring that control planes could reside in the cloud—leveraging availability zones for resilience—while worker nodes remained on-premise to comply with strict data regulations. Traditional Kubernetes setups made this overly complicated, requiring a lot of manual intervention and operational overhead.

I was specifically looking for a way to have my control planes in a cloud provider while ensuring that my worker nodes, which processed sensitive data, stayed within a tightly regulated on-prem environment. This is where Kamaji came in—offering a fully managed way to run control planes as Custom Resources within a central management cluster. It was exactly what I needed!

Dario: That’s exactly the kind of challenge Kamaji was designed to solve! How has Kamaji changed your approach to managing hybrid control planes?

Shaik Zoheb: It’s been a game-changer! Kamaji abstracts away the complexities of managing multiple Kubernetes control planes by turning them into simple Custom Resources (CRs) within a management cluster. This allows us to provision, scale, and manage control planes declaratively without worrying about the nitty-gritty details of traditional Kubernetes control plane deployment. It’s like having a Kubernetes-native control plane factory!

With Kamaji, I don’t have to worry about setting up etcd, API servers, or controllers manually for each new control plane. Everything is automated and centrally managed. This means I can deploy dozens of clusters with minimal operational overhead, something that would be a nightmare with traditional approaches.

Dario: That’s a great way to put it! One of Kamaji’s key features is its ability to automatically integrate the Kubernetes API Server with the Konnectivity machinery. Can you share your experience with that?

Shaik Zoheb: Absolutely! In a hybrid setup, network connectivity between control planes and worker nodes is always a pain point. Kubernetes natively assumes that the API server should be able to reach the kubelets directly for actions like exec, logs, and port-forward. But in real-world scenarios, especially in highly secure environments where instances don’t have public IPs, or NAT support, this is a massive challenge.

Normally, you’d have to manually configure and maintain Kubernetes’ Konnectivity components to bridge this gap. This involves running Konnectivity agents on worker nodes and ensuring they can reach the Konnectivity server that proxies the API server requests. The problem? If any component fails, your cluster effectively loses its ability to execute critical commands on worker nodes.

This is where Kamaji shines: it automatically deploys and reconciles Konnectivity agents and server, ensuring that if anything fails, it gets fixed without intervention. I’ve seen cases where network interruptions caused disruptions or where a configuration drift could have potentially created an outage, but Kamaji stepped in, reconfigured all the components, and resumed everything without us even noticing. That level of self-healing is a lifesaver!

Dario: That’s exactly why we built this feature into Kamaji. Kubernetes networking can be tricky, especially when security constraints prevent direct communication between control planes and workers. With Kamaji, we wanted to remove that burden entirely.

Shaik Zoheb: And you’ve done a fantastic job! Honestly, I think a lot of Kubernetes engineers don’t fully appreciate how tricky API server-to-kubelet communication can be until they run into these challenges in production. Kamaji just makes it work, and that’s a huge relief.

Dario: That’s music to my ears! What would you say to engineers who are still hesitant about trying Kamaji?

Shaik Zoheb: I’d tell them that Kamaji eliminates so much of the operational burden associated with managing Kubernetes control planes. If you’re running multi-tenant environments, hybrid setups, or just want to simplify your Kubernetes management, Kamaji is a no-brainer. Plus, the community is fantastic, and the project is evolving rapidly.

For those who are skeptical, I’d say: try it out! Deploy a management cluster, spin up a few control planes, and see how much easier it makes your life. The ability to declaratively manage control planes like any other Kubernetes resource is a paradigm shift. Once you experience it, you won’t want to go back!

Dario: I couldn’t have said it better myself. Thanks for sharing your insights, Shaik. It’s great to have passionate engineers like you championing Kamaji!

Shaik Zoheb: The pleasure is mine! Excited to see where Kamaji goes next.

If you want to learn more about the Hybrid Control Planes approach covered by Shaik, check out his video tutorial on CLASTIX YouTube channel.