Balance innovation and agility with security and compliance
risks using a 3-step process across all cloud infrastructure.
Step up business agility without compromising
security or compliance
Everything you need to become a Kubernetes expert.
Always for free!
Everything you need to know about Magalix
culture and much more
As our organizations continue to shift back towards the left, developers will continue to gain more access and ownership over their own services . Developers can build, test and deploy faster than ever before. That means there are going to be a few more hands inside the Kubernetes cookie jar, so to speak.
For operations teams, whether they’re managing hundreds of microservices over tens of clusters, or just deploying their first set of pods to production, it can be at times difficult to remember exactly what each microservice does, which applications they are a part of, let alone who to contact when there is an issue with that service. Thankfully, Kubernetes helps us solve this problem with Labels.
Teams move fast. They won’t always cross their Ts and dot their Is. Everything is fine when it’s fine, obviously, but when the fire alarm goes off, especially in the middle of the night, support teams scramble to troubleshoot the issue. They need everything at their disposal to triage and remedy the problem. The last thing they want to do is to play detective at 3:00AM. Waking up to triage an issue you know nothing about doesn’t make any sense.
In organizations where development teams share the load when it comes to supporting their own services, setting up each developer and building specific alerting swimlanes for each service can be a lot of overhead, impeding on any self-service efforts that may have already been established. On top of that, how do you make sure every entity remains compliant across your entire fleet of clusters?
What if there was a way to solve these problems easily?
Have you ever had a label maker? The problem with label makers is that once you have access to one, everything seems to need a label. But you have to type it in and attach it to something. The same goes for Kubernetes labels. There may be some manual label attachment at first, but after you are done with the first round, you’ll be able to quickly organize your Kuberentes entities and figure out exactly what is what.
At Magalix, we add an owner label to almost everything. As our microservice footprint grows, so do our responsibilities. Maintaining Kubernetes clusters across various cloud providers and empowering dev teams to manage their own workloads can eventually lead to situations we described above. To ensure we don’t miss this step, we created a KubeAdvisor owner label policy to run across all of our clusters. This allows team to:
We all want to be proactive. Don’t let your teams find out who owns what by way of downtime. At Magalix, we use the owner label because that works for us, but in your organization, maybe you have other information or metadata that is just as important. Don’t limit yourself to only what we do internally. Since labels can be any alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (_), dots (.), and alphanumerics in between, come up with your own policies to get you on the right path towards a properly governed.
Prevent Kubernetes NetworkPolicy misconfigurations by enforcing policy as code