What not to do while operating Kubernetes

Kubernetes is the new standard of operation. This provides agility, quick to market and features are made availble in days. So, here is my recommendation on do’s and dont’s while running your production with Kubernetes.

Dont get carried away by community images, Find legit images or offical images from docker hub. Like redhat images, ubuntu, Centos and Alpine. Look for the name Docker Official Images. I have provided you a couple of images that were legit and works.

The ideal size of app image is less than 100 MB, but it is not possible always, So plesae try to keep it under 250 MB and max of 300 MB. If the size is bigger the Kubernetes nodes takes lot of time to pull and scale the service. The story will change for Windows containers, we can deal that in another article seperately.

Always make sure your Build pipelines includes the lastest offoical image and get it scaned by one of the image scanners avilable in the market — Aquasec, Google Container Scan or Twistlock. You cannot get 100% compliance as there is no fix in the community but compensate with runtime scanner. Going with out a check is like — opening the doors to hacker.

In addition to BaseImage Vulnerabilities, you have to look for static code analysis and bug fixes and always make sure you dont have a vulnerability that has a CVV score of 7 or more.

Run Aquascan or Twistlock run time Daemonsets on the Kubernetes to find out the anomolies and make sure to integrate with SSO and SIEM and forwarding these to SRE team.

In the iteration of migrating your VM to container, the first by product will be Monolithic service and it is reality of development, but follow through maturity of product and run atleast 5- 10 sprints to get them into a Microservice. Application Architects needs to understand the components of Kubernetes to slice and dice the product into control, data, application platforms. The easiet way to find it, how much amount of CPU and RAM quotes are required by this pod ( If he say the same specs of VM — like 4 VCPU, 16 GB). Then it is not a microservice, you just dumped the Jar to a Container. The ideal container limits are ( 200 milli cores, 256 MB RAM with burst to 1000 milli cores and 1 GB RAM). We dont live in a ideal world — so as long as it is 2 vCPU, 2 GB RAM, you can agree.

You can start with Kubernetes manifests or yams files, this is not scalable nor advisible. So stick to helm charts and this will give you better control on upgrades — canary or bluegreen based deployments.

Make sure to upgrade or have a scheduled story to upgrade Kubernetes AKS, EKS, GKE every 6 months ( we will not upgrade it to latest and greatest — run 1 version down — i.e., Kubernetes 1.17 or max of 1.18 ).

Solutions Architect & Cloud Engineering Manager