1. Kubernetes Informers:

   • An Informer is a client-side library in Kubernetes that allows you to watch and react to changes in resources within a Kubernetes cluster.

   • It provides real-time updates about the state of various Kubernetes objects (such as pods, services, deployments, etc.).

   • How it works:

     • The Informer leverages the Kubernetes API server’s watch functionality.

     • It establishes a persistent connection with the API server over HTTP or WebSocket.

     • The API server streams events (resource creations, updates, deletions) to the client.

     • The client processes these events based on its logic.

     • The API server sends event updates as changes occur in the cluster.

     • The client handles connection errors and timeouts, ensuring it stays informed about cluster changes.

2. Watches:

   • Watches are also used to observe changes in Kubernetes resources.

   • However, the main difference lies in how they handle failures:

     • A Watch can disconnect due to network problems or timeouts.

     • An Informer tries to re-list and re-watch to hide such failures from the caller.

   • Additionally, Informers include an in-memory cache, allowing you to use list/get semantics instead of event-driven semantics if you prefer.

In summary, Informers provide a more robust and reliable way to stay synchronized with cluster resources, handling potential issues gracefully. However, both approaches have their use cases, and the choice depends on your specific requirements.

Does informers have less API calls than watches?

Kubernetes Informers and Watches serve different purposes, and their behavior regarding API calls varies.

1. Informers:

   • API Calls: Informers do not inherently reduce the number of API calls compared to watches. They still rely on the same underlying watch functionality provided by the Kubernetes API server.

   • Functionality: Informers include additional features beyond watches, such as caching and listers. The in-memory cache allows you to use list/get semantics, which can reduce the need for repeated API calls when accessing resource data.

   • Robustness: Informers handle connection errors and timeouts more gracefully. If the connection is lost, they attempt to re-list and re-watch to hide failures from the caller.

   • Usage: Informers are commonly used when building custom controllers or operators. They provide a higher-level abstraction for working with resources.

2. Watches:

   • API Calls: Watches directly interact with the Kubernetes API server using watch requests. They receive real-time updates about resource changes but do not include additional features like caching.

   • Functionality: Watches are more lightweight and straightforward. They are suitable for scenarios where you need immediate notifications about resource changes without additional complexity.

   • Usage: Watches are often used in event-driven workflows, where responsiveness is critical. For example, when you want to react to pod creations, deletions, or updates in real time.

Here is the simpler break down.

1. Watch:

   • Imagine you’re watching a live sports game on TV. You see everything happening in real-time.

   • In Kubernetes, a Watch is like this live stream. It allows you to observe changes (like new pods being created or deleted) as they happen.

   • But here’s the catch: If your internet connection drops or there’s a timeout, you might miss some updates. It’s like losing signal during the game.

   • So, Watch can disconnect and miss events.

2. Informer:

   • Now think of an Informer as a dedicated reporter at the game. This reporter keeps track of everything that happens.

   • If the reporter misses something (maybe due to a network glitch), they’ll re-check the game stats and catch up.

   • In Kubernetes, an Informer maintains a local cache of resources (like pods). It periodically syncs with the server to stay up-to-date.

   • So, even if there’s a hiccup, the Informer tries its best to keep you informed without missing any action.

3. Advantages of Informer:

   • Robustness: An Informer handles network issues better. It re-lists and re-watches to hide failures.

   • Cache: The local cache allows you to use list/get operations (like checking the scorecard) instead of relying solely on events.