Migrating your on premise workload to Kubernetes cloud provider seems to be very reasonable step nowadays.

The name Kubernetes comes from Greek and means helmsman or pilot. Google opened the Kubernetes project publicly in 2014. Kubernetes uses Google’s fifteen years of experience in launching large-scale services and combines them with the best ideas and practices developed by the community.

Containers are a good way to package and launch applications. In a production environment, you need to manage the containers in which the applications are running and ensure that there are no interruptions in their availability. For example, when one of the containers stops working, another must start. Wouldn’t it be easier for a system to do this?

And this is where Kubernetes comes to the rescue! Kubernetes provides an environment for running distributed systems with high reliability. Also supports application scaling, emergency switching, various deployment scenarios etc.

There are variety of things that should be taken into consideration in this process and we we are here to help and guide you!

Below you can find a simple checklist you can use when first time migrating to Kubernetes.

Checklist

General plan

• Choose your provider(s) – GKE (google cloud), AKS (AZURE), EKS (AWS) are most common.  In some solution (that requires the highest level of high availability) you can go to multicloud.
• Choose the way to provision your cluster. Declarative way (eg. terraform) is always better than imperative (scripting). Bare in mind that most probably you need more than one cluster (production cluster should be run on another account to keep isolation).
• Be aware of Kubernetes version offered by your provider.
• Take advantage of worker nodes autoscaling.
• Don’t DIY.  In case of any problem try to find official solution at first.
• Keep your non production cluster as similar as possible to PROD.
• For local development consider using k3s instead minikube. It is a lightweight version of kubernetes designed for local development (https://k3s.io/)
• Never deploy pod directly. Choose one of the controllers (eg. Deployment, StatefulSet)

Plan usage of your cluster

• Ensure isolation between teams and environments (namespaces).
• Limit resources per team (Resource Quota).
• Add Storage class(es) to your cluster – it enables dynamic volume provisioning.

Storage

• Use classical volumes for sharing data between containers in pod.
• Use persistent volumes for persistance of your data.
• Think of your persistent volumes as a network service. Be aware about some latencies (not so significant). Don’t speculate, just measure it.
• Use storage class delivered by chosen cloud provider.
• You can consider using project like https://rook.io/ for automatic storage management.
• Use persistent volumes along with stateful sets. Never use scaled deployment with it (it will fail at the time of creating second replica).

Security

• Run your containers as a non root user.
• Take advantage of docker image scanning.
• Consider using Pod Security Policy to limit host resources usage in containers.
• Plan authorization and authentication. Use Service Accounts (for application), consider using oidc provider for kubectl users.
• Narrow permissions as much as possible. You can test your permissions using kubectl auth can-i command.

Exposing Services

• Use ClusterIp service type whenever possible.
• Omit using LoadBalancer service type (Ingress Controller is an exception). It creates cloud specific load balancer. Additional costs will be added.
• Use Ingress Controller to expose your services. SSL termination should take place here. as well. Bu default NGNIX Ingress Controller doesn’t support pass through option.
• You can ensure sticky session on Ingress Controller and service level.

Tooling and images

• In lower environment you can use it as a long living deployment (you can exec into it and run diagnostic commands).
• Limit tools in application containers.
• Keep your images as thin as possible. Smaller images means faster container startup time.
• Use telepresence for remote application debugging. But keep in mind security while doing it.
• Use official images whenever possible. Take a look on long term support when choosing the base images.
• Between environments prefer image promotion over building a new image.
• Use latest tag only for testing purposes.

Above are some of the main issues. The Kubernetes serie will be continued…