Controllers management
Spider Controllers were first released with this blog post.
Concept
A Spider Controller is a Kubernetes service that is used to operate Spider in a remote Kubernetes cluster.
It allows:
- Attaching a Whisperer to any running Pod or workload in the cluster. Without causing a Pod restart.
- Watching existing Whisperers running in the cluster. Being Sidecars Whisperers or Attached.
- Watching existing Gociphers running in the cluster.
- Getting logs from any of these remote agents: Whisperers, Gociphers and the Controller itself.
Remote spawning of Whisperers
In short, a Controller allows you to spawn a Whisperer without leaving the UI.
A Controller may spawn Whisperers to a single POD, or to all replicas of the same Kubernetes workload, and dynamically check when a new whisperer is needed based on the workload lifecycle events. When the workload scales up or down.
It is great for troubleshooting, debugging, but may also be used for continuous observability and monitoring.
By default, you have a Spider Controller installed in the cluster when installing Spider.
But you may also install controllers to any remote cluster, and have them connected to the same Spider instance.
The controller:
- watches Kubernetes events to keep an inventory of Pods
- watches Whisperers events to maintain them (or remove them when needed)
- provides a DNS proxy for Whisperers to avoid them to have any specific Kubernetes role (RBAC) to list Pods
- respond in real time to UI requests
- lists Whisperers deployed on each Kube node for Gociphers
How does it work?
Look at this blog post for details.
Content
This documentation describes: