In order to minimize production downtime and maintain effective workloads, planning and managing your cloud ecosystem and environments are essential. In this blog series, “Managing your cloud ecosystems,” we provide strategies for ensuring a smooth setup with minimal downtime.

In previous articles, we discussed various topics such as updating worker nodes while keeping the workload running, managing major, minor, and patch updates, and migrating workers to a new operating system (OS) version. Now, let’s bring it all together by focusing on the importance of keeping components consistent across clusters and environments.

Example Setup

Let’s analyze an example setup that consists of four IBM Cloud Kubernetes Service (IKS) VPC clusters:

• One development cluster
• One QA test cluster
• Two production clusters (one in Dallas and one in London)

You can view a list of clusters in your account by running the ibmcloud ks cluster ls command.

Name	ID	State	Created	Workers	Location	Version	Resource Group Name	Provider
vpc-dev	bs34jt0biqdvesc	normal	2 years ago	6	Dallas	1.25.10_1545	default	vpc-gen2
vpc-qa	c1rg7o0vnsob07	normal	2 years ago	6	Dallas	1.25.10_1545	default	vpc-gen2
vpc-prod-dal	cfqqjkfd0gi2lrku	normal	4 months ago	6	Dallas	1.25.10_1545	default	vpc-gen2
vpc-prod-lon	broe71f2c59ilho	normal	4 months ago	6	London	1.25.10_1545	default	vpc-gen2

Each cluster has six worker nodes. Below is a list of the worker nodes running on the development cluster:

ID	Primary IP	Flavor	State	Status	Zone	Version
kube-bstb34vesccv0-vpciksussou-default-008708f	10.240.64.63	bx2.4×16	normal	ready	us-south-2	1.25.10_1548
kube-bstb34jt0bcv0-vpciksussou-default-00872b7	10.240.128.66	bx2.4×16	normal	ready	us-south-3	1.25.10_1548
kube-bstb34jesccv0-vpciksussou-default-008745a	10.240.0.129	bx2.4×16	normal	ready	us-south-1	1.25.10_1548
kube-bstb3dvesccv0-vpciksussou-ubuntu2-008712d	10.240.64.64	bx2.4×16	normal	ready	us-south-2	1.25.10_1548
kube-bstb34jt0ccv0-vpciksussou-ubuntu2-00873f7	10.240.0.128	bx2.4×16	normal	ready	us-south-3	1.25.10_1548
kube-bstbt0vesccv0-vpciksussou-ubuntu2-00875a7	10.240.128.67	bx2.4×16	normal	ready	us-south-1	1.25.10_1548

Maintaining Consistency in Your Setup

The example cluster and worker node outputs highlight various component characteristics that should remain consistent across all clusters and environments.

For Clusters

• The Provider type indicates whether the cluster’s infrastructure is VPC or Classic. To ensure optimal workload function, make sure your clusters have the same provider across all environments. If a cluster’s provider does not match, create a new cluster with the desired provider and migrate the workload to the new cluster. Note that for VPC clusters, the specific VPC might differ across environments. In such cases, ensure that the VPC clusters are configured similarly for consistency.
• The cluster Version indicates the Kubernetes version that the cluster master runs on. It’s important for all clusters to run on the same version. Master patch versions are automatically applied (unless you opt out of automatic updates), but major and minor releases must be applied manually. If your clusters are running on different versions, refer to our previous blog post on updating clusters. For more information on cluster versions, consult the Kubernetes service documentation on Update Types.

For Worker Nodes

Note: Before making any updates or changes to your worker nodes, it’s crucial to plan your updates to avoid disruptions to your workload. Worker node updates can cause disruptions if not planned properly. For more information, refer to our previous blog post.

• The worker Version represents the most recent patch update applied to your worker nodes. Regularly applying patch updates is essential as they include important security and Kubernetes changes. Refer to our previous blog post on version updates for more information on upgrading your worker node version.
• The worker node Flavor refers to the machine type and determines the specifications for CPU, memory, and storage. If your worker nodes have different flavors, replace them with new worker nodes of the same flavor. For details, see the Kubernetes service documentation on Updating flavor (machine types).
• The Zone indicates the location where the worker node is deployed. For high availability and maximum resiliency, make sure the worker nodes are spread across three zones within the same region. In our example, there are two worker nodes in each of the us-south-1, us-south-2, and us-south-3 zones. Ensure that your worker node zones are configured consistently across all clusters. If you need to change the zone configuration, create a new worker pool with the desired zone settings and delete the old worker pool. For more information, consult the Kubernetes service documentation on Adding worker nodes in VPC clusters or Adding worker nodes in Classic clusters.
• Additionally, the Operating System running on your worker nodes should be consistent throughout your cluster. Note that the operating system is specified for the worker pool rather than individual worker nodes, and it is not included in the previous outputs. To check the operating system, run the command ibmcloud ks worker-pools -cluster <clustername>. For information on migrating to a new operating system, refer to our previous blog post.

By maintaining consistent configurations across your clusters and worker nodes, you can reduce workload disruptions and downtime. When making any changes to your setup, remember to follow the recommendations in our previous blog posts regarding updates and migrations across environments.

Wrap Up

This concludes our blog series on managing cloud ecosystems to minimize downtime. If you have not already done so, be sure to check out the other topics in this series.

Learn more about IBM Cloud Kubernetes Service clusters here.

FAQs

1. Why is it important to keep your cloud setup consistent?

Consistency in your cloud setup ensures that components such as clusters, providers, versions, worker nodes, flavors, zones, and operating systems remain the same across environments. This consistency reduces disruptions and downtime in your workload, providing a smoother and more reliable experience.

2. Can I change the provider type of a cluster after it is created?

No, once a cluster is created, you cannot change its provider type. If you need to switch providers, you must create a new cluster with the desired provider and migrate your workload to the new cluster.

3. Are automatic updates applied to cluster master patch versions?

Yes, automatic updates are applied to cluster master patch versions unless you opt out of this feature. Major and minor releases, however, must be applied manually.

4. How can I ensure high availability and resiliency for worker nodes?

To ensure high availability and resiliency, it is recommended to spread worker nodes across three zones within the same region. This allows for continuity in case of failures or disruptions in any one zone. Configuring worker node zones consistently across all clusters is essential for maximum resiliency.

5. Can I update worker node flavors without causing disruptions?

Yes, you can update worker node flavors without causing disruptions. Simply replace the existing worker nodes with new ones that run on the desired flavor. This process ensures a seamless transition without any negative impact on your workload.