| |

Talks With Microsoft – Kubernetes

Recently in my current role, I’ve been chatting with some engineers at Microsoft & it’s been a great experience to learn from some of the best in the field. I’ve precisely been querying them regarding Azure, Azure DevOps & AKS, in addition to surrounding technologies, practices, etc. One thing that I have learned a lot about it Kubernetes, including topics such as how to prevent noisy neighbours within your cluster, how to control the west-east traffic & so on.

Having gone over just how the ingress/egress controllers actually work was quite interesting to learn & to be perfectly honest, it’s not what I would’ve expected prior to one of the conference meetings that we held. Previously I had imagined something totally different & to be totally transparent I feel a little stupid for thinking that in the first place.

NetworkPolicy’s, again, another area which I had little knowledge on, I wasn’t sure if that was for handling some form of networking external to the cluster, internal or both, etc. Now I have a better understanding & now I’m aware that with this approach, you can control the traffic within the cluster itself, you can define what pod can talk to what-other pod & it’s great! From this meeting I’ve learned that it’s always best to block everything initially, then slowly open up to pods that need to talk to that specific pod. To aid my point, here’s some code provided by Steve Leonard from Microsoft. In his example you can see that he’s specifying that the front end can talk to the middle-tier application, which can then talk to the back end, but the front end can’t communicate with the backend directly.

Going back to noisy neighbours, this is something that Steve has also covered with us & to prevent problems such as noisy neighbours, one simple solution is to take advantage of LimitRange’s. With a LimitRange, as the name would suggest, you can limit the amount of resources that a pod or a container is able to utilise. In the real world, this is beautiful, having experienced issues related to noisy neighbours within a Kubernetes cluster, it’s hard to imagine not taking advantage of this API.


For the most part, I’m really beginning to love using kubernetes within the Azure ecosystem, however, as Steve has said himself, it’s still a very new technology. From the perspective of an enterprise company, it’s great, but it would be even better if it was more mature & there were less changes. I mean of course, like any new technology, there’s going to be a lot of change initially. So I’m really looking forward to seeing how Kubernetes evolves in the oncoming years, I’m honestly somewhat excited to see it mature, to see more very well documented examples online, more documentation, etc.

Similar Posts

Notify of
Inline Feedbacks
View all comments