Why utils?
The core DANM project demonstrates that a concise E2E networking suite brings tremendous value to any Kubernetes cluster - even if you don't need multiple interfaces!
Scope creep is a real thing though. As it usually happens with projects after they have seen considerable production usage, more and more interesting use-cases rear up their -ugly? beautiful?- heads with time.
What if we could do this awesome thing too? And that?
Who wouldn't want to have network policing for multiple interfaces, different provider integrations, autonomous IP management and so on, and so on?
New features all sound very exciting for developers, but they also increase operation complexity at the same time. To effectively manage this complexity without compromising on the user experience of the existing DANM suite, we decided to implement all future DANM platform enhancements as independent, loosely coupled, and most importantly optional Controllers / Operators.
But don't worry, this doesn't mean the existing DANM API and its related core project will not see development anymore!
Danm-utils is the project which houses this catalogue of value-adding DANM platform components, and we are proud to release the first one called...
Cleaner
Network management, and the CNI ecosystem has some known design flaws DANM was created to address. One of the most important Day 0 feature was a unique IPAM module, capable of handling discontinous, cluster-wide allocations.
As projects following in our footstep quickly learned this comes with the extra burden of efficiently managing a synchronized external state store at scale. What most people haven't realised yet is that keeping this store up for a prolonged period of time, in an asynchrous and "only" IT-reliable environment such as Kubernetes takes a lot of hard work.
Kubernetes's simplistic network management view boils down to two operations: adding a Pod, and deleting a Pod. But what happens with an already existing Pod and its -node-independent- allocations when a node looses network connectivity?
Or maybe the whole Node goes down?
Or maybe the whole cluster goes down?
The CNI architecture doesn't have an answer to these questions, and we have seen time and time again that old allocations weren't getting properly cleaned-up because the orchestrator didn't have an API to convey such changes.
Enter Cleaner! This administrative component was created to monitor the cluster, and recognize when one of the aforementioned scenarios happen.
Cleaner is capable of determining if an old DANM allocation is dangling, or is still attached to an existing instance.
When dangling allocations are observed Cleaner also makes sure to reconcile the observed cluster state with the expected one.
This is particularly important in an environment where static IP allocations are used, as not being able to re-instantiate a component relying on a static allocation can even lead to a perpetual outage, requiring manual intervention.
Not anymore with Cleaner's self-healing magic! If you rely on DANM's powerful IPAM to manage the IP addresses in your cluster, and especially if you use static allocations we strongly suggest installing Cleaner in your long-running, production environment,
Showalloc
Speaking of DANM's IPAM, the main reason behind its flexibility and unparallaled capabilities is the storage algorithm it employs to compress and store information. You might've been wondering at some point what the hell that strange looking string in your networks' Spec.Options.Alloc/Alloc6 field is, haven't you?
Compression saves space, but also results in ambiguity. Sometimes it would be nice to look at a network and just see if an IP is allocated already, or not!
Showalloc is a handy command line utility capable of doing just that! It uses DANM's own compression algorithm to inspect a network on your behalf, and "decode" its allocations into a human readable format.
It can figure out if a specific IP is reserved or not, or can show the status of each addresses within a range. Not just that, but it can even tell you which Pod is currently reserving a particular address.
Debugging DANM allocations is now as easy as:
showalloc -kubeconf .kube/config -dnet test-net1
172.168.10.0 : reserved (network base address)
172.168.10.10 : allocated (Pod: cinfo-danm-0)
172.168.10.11 : allocated (Pod: cinfo-danm-1)
172.168.10.12 : allocated (Pod: cinfo-danm-2)
172.168.10.13 : allocated (Pod: cinfo-danm-3)
172.168.10.255 : reserved (broadcast address)