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:
- Discovering the Network Usage in a Kubernetes cluster.
- Attaching a Whisperer to any running Pod or workload in this 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 anywhere in the cluster, without leaving the UI.
A Controller may spawn Whisperers in a single POD, or in 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
- watches PODs events to list Sidecars Whisperers and Gociphers daemon sets
- access Kubernetes API to fetch latest Spider agents logs
- receives Network Usage from Gociphers and enriches them with metadata to allow Cluster discovery
How does it work?
Look at this blog post for details.
Content
This documentation describes: