<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Controller on Anish Bista</title><link>https://anishbista.org/tags/controller/</link><description>Recent content in Controller on Anish Bista</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 24 Jan 2026 15:56:13 +0000</lastBuildDate><atom:link href="https://anishbista.org/tags/controller/index.xml" rel="self" type="application/rss+xml"/><item><title>Event-Driven Design: The Core Principle Behind Kubernetes Architecture</title><link>https://anishbista.org/blog/event-driven-design-the-core-principle-behind-kubernetes-architecture/</link><pubDate>Sat, 24 Jan 2026 15:56:13 +0000</pubDate><guid>https://anishbista.org/blog/event-driven-design-the-core-principle-behind-kubernetes-architecture/</guid><description>&lt;blockquote>
&lt;p>&lt;strong>Note:&lt;/strong> This is a handwritten blog. In this blog, we should explore the event where the architecture of Kubernetes is discussed. It will be very short.&lt;/p>&lt;/blockquote>
&lt;p>As you know, Kubernetes follows an event-driven architecture. The Kubernetes control plane heavily consumes events. But most distributed systems follow RPCs to trigger behavior, but Kubernetes does not.&lt;/p>
&lt;p>Reason behind why Kubernetes is not built using RPCs:&lt;/p>
&lt;ol>
&lt;li>&lt;strong>Tight coupling:&lt;/strong> RPCs create strong dependencies between components. In Kubernetes, control plane components must remain loosely coupled to evolve and scale independently.&lt;/li>
&lt;li>&lt;strong>Poor failure handling:&lt;/strong> RPCs expect the caller and callee to be alive at the same time. In a distributed system like Kubernetes, transient failures are common and break this assumption.&lt;/li>
&lt;li>&lt;strong>Scalability limits:&lt;/strong> Synchronous RPC calls don’t scale well when thousands of objects and controllers are involved. They can easily become bottlenecks.&lt;/li>
&lt;/ol>
&lt;p>Let’s understand this scenario with one simple example. When you create a Deployment, the following happens:&lt;/p></description></item><item><title>What is the most powerful feature of Kubernetes ?</title><link>https://anishbista.org/blog/what-is-the-most-powerful-feature-of-kubernetes/</link><pubDate>Fri, 16 Jan 2026 07:26:14 +0000</pubDate><guid>https://anishbista.org/blog/what-is-the-most-powerful-feature-of-kubernetes/</guid><description>&lt;p>&lt;em>&lt;strong>Note: This is hand written blog. In this blog, we gonna discuss about that feature which become one of the main reason behind the success of Kubernetes.&lt;/strong>&lt;/em>&lt;/p>
&lt;p>Let’s start with a bit of history. Before Docker and Kubernetes, Google had been running an containers and orchestration system called Borg internally for so many years. Docker changed the way software is built. So, Googlers definitely had the confidence that something called Kubernetes was going to create a lot of impact in the upcoming decade and I would say google was right.&lt;/p></description></item></channel></rss>