A general trend in IT infrastructure is containerization. At FourCo IT Services, we also notice more and more of our customers wanting to use containers for their platform, more specifically running containers on Kubernetes. Nowadays, every major Cloud provider has its own managed Kubernetes solution:
-
…. and even more
Quick development of Kubernetes
The first version of Kubernetes was released in July 2015, already 5 years ago. Kubernetes is still rapidly evolving with new features, design updates, and bug fixes. The community releases new Kubernetes minor versions, as generally available approximately every three months, and each minor version was supported for about nine months after it is first released. However, from Kubernetes version 1.19 the project maintains release branches for one year following the initial release of a new minor version. As an example, we will look here at current AWS EKS supported versions.
AWS EKS
Looking at AWS EKS, they actively support three versions. Currently, these are:
-
1.14.9 (deprecated)
-
1.15.11
-
1.16.13
-
1.17.9
If we look at for example version 1.13 based on the AWS blog, it was supported from June 19, 2019. After they released version 1.16, the AWS blog states an end of life date for version 1.13 of June 30, 2020. This means at least once every year you need to upgrade the cluster to the newest version.
(Dis)Advantages of Kubernetes in the Cloud
What are the (dis)advantages of a Managed Kubernetes solution?
Advantages
-
Up and running quickly: With a managed service, you are up and running very quickly. If you are starting to explore the possibilities of containerization and Kubernetes, you can focus on the deployment of your application instead of investing time and resources in the creation of your own cluster.
-
High availability: The cloud providers ensure that the control planes are scaled across multiple AZ’s/zones for high availability and fault tolerance.
-
Secure: The latest security patches are applied to your control planes.
-
Integration with other services: EKS delivers deep integration with services such as CloudWatch, AutoScaling, IAM, App Mesh, while GKE delivers the solution with an integrated cloud monitoring
-
Autoscale: Possibility of automatically scaling your cluster based on resource utilization (CPU, memory)
Disadvantages
-
Costs: For GKE and EKS, you pay approximately $0.10/hour, excluding the worker nodes.
-
Not cloud-agnostic: For complex infrastructures, you aren’t able to easily move applications between multiple cloud providers. You’ll have to handle the task of container orchestration on these other clouds as well.
-
No integration: Although we stated it also as a benefit, this is mainly integrations within the same cloud provider. For most of the managed services, it doesn’t allow integration with other managed Kubernetes services.
A common misconception about using Kubernetes in the cloud is that maintenance of the Kubernetes infrastructure is no longer required. Unfortunately, this is not the case.
Maintenance of Kubernetes in the Cloud
All cloud Kubernetes services contain the Kubernetes Control Planes. Upgrading these managed services is easier (next, next, finish) in comparison to self-hosted Kubernetes clusters. However, thorough preparation is still required for upgrading your cluster.
Upgrade strategy
Before we upgrade clusters to the newest supported version, we execute the following strategy.
-
Examine the Kubernetes version upgrade prerequisites
-
Examine Kubernetes changes
-
Test first
-
Backup and recovery
Examine the Kubernetes version upgrade prerequisites
Based on the documentation provided by the cloud provider, we analyze if there are prerequisites which require our attention.
Examine Kubernetes changes
While Kubernetes is rapidly evolving, It could be that a Kubernetes version doesn’t support certain APIs anymore, for example: Kubernetes deprecated APIs removed in version 1.16. In this case, it is important to align these findings with the creator of the Kubernetes manifest files or helm charts.
Test first
Although it seems obvious, we highly recommend using a separate cluster which is a copy of the production cluster to perform your upgrade. In this case, you can execute a test upgrade without disturbing the production environment. After the upgrade went successful on your test cluster, you can start to plan the update on the production cluster.
Backup and recovery
Before we even start an update of the cluster, we always make sure that the current state is backed up in case of issues. To back up a cluster, we deploy the backup and recovery tool called Velero on clusters. In the next blog, I will explain in more detail on Velero and show you how this tool can be used in one of your clusters.
In the working field of Kubernetes clusters, you will also find opinions that you don’t need to backup your cluster if all your deployed applications are maintained in a git repo. This seems a legitimate reason for the applications side. However, you do need to make sure that backups of your persistent data are also taken care off.
Upgrading an existing cluster
After a solid analysis has been done and we are ready to perform the actual upgrade, the update consists of two parts:
-
Updating the master nodes (control plane)
-
Updating the worker nodes
First, your master nodes need to be updated, followed by the worker nodes. Upgrading a cluster needs to be done on a version by version basis, meaning from version 1.15 to, 1.16 and from 1.16 to 1.17 etc. As an example, this will result in the following activities
-
Update master node from version 1.15 to 1.16
-
Update worker nodes from version 1.15 to 1.16
-
Test the functionality and working of the cluster/applications as well as examine the log files
Once everything is successful, continue to the next update, the same process repeats.
Conclusion
As already stated before, a common misconception about using Kubernetes in the cloud is that maintenance of the Kubernetes infrastructure is no longer required. You need to address the maintenance of your cluster on your infrastructure maintenance agenda.
If you need any help with this FourCo IT Service can help you maintain your clusters.
As already stated above in my next blog I will introduce the backup and recovery tool called Velero
