September 11, 2023 By Kodie Glosser
Marissa Treible
3 min read

Planning and managing your cloud ecosystem and environments is critical for reducing production downtime and maintaining a functioning workload. In the “Managing your cloud ecosystems” blog series, we cover different strategies for ensuring that your setup functions smoothly with minimal downtime.

Previously, we covered keeping your workload running when updating worker nodes, managing major, minor and patch updates, and migrating workers to a new OS version. Now, we’ll put it all together by keeping components consistent across clusters and environments.

Example setup

We’ll be analyzing an example setup that includes the following four IBM Cloud Kubernetes Service 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:

NameIDStateCreatedWorkersLocationVersionResource Group NameProvider
vpc-dev  bs34jt0biqdvescnormal2 years ago6Dallas1.25.10_1545defaultvpc-gen2
vpc-qac1rg7o0vnsob07normal2 years ago6Dallas1.25.10_1545defaultvpc-gen2
vpc-prod-dalcfqqjkfd0gi2lrkunormal4 months ago6Dallas1.25.10_1545defaultvpc-gen2
vpc-prod-lonbroe71f2c59ilhonormal4 months ago6London1.25.10_1545defaultvpc-gen2
Scroll to view full table

Each cluster has six worker nodes. Below is a list of the worker nodes running on the dev cluster. You can list a cluster’s worker nodes by running ibmcloud ks workers --cluster <clustername>:

IDPrimary IPFlavorStateStatusZoneVersion
kube-bstb34vesccv0-vpciksussou-default-008708f  10.240.64.63   bx2.4×16  normalreadyus-south-2  1.25.10_1548
kube-bstb34jt0bcv0-vpciksussou-default-00872b7  10.240.128.66  bx2.4×16  normalreadyus-south-3  1.25.10_1548
kube-bstb34jesccv0-vpciksussou-default-008745a  10.240.0.129   bx2.4×16  normalreadyus-south-1  1.25.10_1548
kube-bstb3dvesccv0-vpciksussou-ubuntu2-008712d  10.240.64.64   bx2.4×16  normalreadyus-south-2  1.25.10_1548
kube-bstb34jt0ccv0-vpciksussou-ubuntu2-00873f7  10.240.0.128   bx2.4×16  normalreadyus-south-3  1.25.10_1548
kube-bstbt0vesccv0-vpciksussou-ubuntu2-00875a7  10.240.128.67  bx2.4×16  normalreadyus-south-1  1.25.10_1548
Scroll to view full table

Keeping your setup consistent

The example cluster and worker node outputs include several component characteristics that should stay consistent across all clusters and environments.

For clusters

  • The Provider type indicates whether the cluster’s infrastructure is VPC or Classic. For optimal workload function, ensure that your clusters have the same provider across all your environments. After a cluster is created, you cannot change its provider type. If one of your cluster’s providers does not match, create a new one to replace it and migrate the workload to the new cluster. Note that for VPC clusters, the specific VPC that the cluster exists in might be different across environments. In this scenario, make sure that the VPC clusters are configured the same way to maintain as much consistency as possible.
  • The cluster Version indicates the Kubernetes version that the cluster master runs on—such as 1.25.10_1545. It’s important that your clusters run on the same version. Master patch versions—such as _1545—are automatically applied to the cluster (unless you opt out of automatic updates). Major and minor releases—such as 1.25 or 1.26—must be applied manually. If your clusters run on different versions, follow the information in our previous blog installment to update them. For more information on cluster versions, see Update Types in the Kubernetes service documentation.

For worker nodes

Note: Before you make any updates or changes to your worker nodes, plan your updates to ensure that your workload continues uninhibited. Worker node updates can cause disruptions if they are not planned beforehand. For more information, review our previous blog post.

  • The worker Version is the most recent worker node patch update that has been applied to your worker nodes. Patch updates include important security and Kubernetes upstream changes and should be applied regularly. See our previous blog post on version updates for more information on upgrading your worker node version.
  • The worker node Flavor, or machine type, determines the machine’s specifications for CPU, memory and storage. If your worker nodes have different flavors, replace them with new worker nodes that run on the same flavor. For more information, see Updating flavor (machine types) in the Kubernetes service docs.
  • The Zone indicates the location where the worker node is deployed. For high availability and maximum resiliency, make sure you have worker nodes spread across three zones within the same region. In this VPC example, there are two worker nodes in each of the us-south-1, us-south-2 and us-south-3 zones. Your worker node zones should be configured the same way in each cluster. If you need to change the zone configuration of your worker nodes, you can create a new worker pool with new worker nodes. Then, delete the old worker pool. For more information, see Adding worker nodes in VPC clusters or Adding worker nodes in Classic clusters.
  • Additionally, the Operating System that your worker nodes run on should be consistent throughout your cluster. Note that the operating system is specified for the worker pool rather than the individual worker nodes, and it is not included in the previous outputs. To see the operating system, run ibmcloud ks worker-pools -cluster <clustername>. For more information on migrating to a new operating system, see our previous blog post.

By keeping your cluster and worker node configurations consistent throughout your setup, you reduce workload disruptions and downtime. When making any changes to your setup, keep in mind the recommendations in our previous blog posts about updates and migrations across environments.

Wrap up

This concludes our blog series on managing your cloud ecosystems to reduce downtime. If you haven’t already, check out the other topics in the series:

Learn more about IBM Cloud Kubernetes Service clusters
Was this article helpful?
YesNo

More from Cloud

Enhance your data security posture with a no-code approach to application-level encryption

4 min read - Data is the lifeblood of every organization. As your organization’s data footprint expands across the clouds and between your own business lines to drive value, it is essential to secure data at all stages of the cloud adoption and throughout the data lifecycle. While there are different mechanisms available to encrypt data throughout its lifecycle (in transit, at rest and in use), application-level encryption (ALE) provides an additional layer of protection by encrypting data at its source. ALE can enhance…

Attention new clients: exciting financial incentives for VMware Cloud Foundation on IBM Cloud

4 min read - New client specials: Get up to 50% off when you commit to a 1- or 3-year term contract on new VCF-as-a-Service offerings, plus an additional value of up to USD 200K in credits through 30 June 2025 when you migrate your VMware workloads to IBM Cloud®.1 Low starting prices: On-demand VCF-as-a-Service deployments begin under USD 200 per month.2 The IBM Cloud benefit: See the potential for a 201%3 return on investment (ROI) over 3 years with reduced downtime, cost and…

The history of the central processing unit (CPU)

10 min read - The central processing unit (CPU) is the computer’s brain. It handles the assignment and processing of tasks, in addition to functions that make a computer run. There’s no way to overstate the importance of the CPU to computing. Virtually all computer systems contain, at the least, some type of basic CPU. Regardless of whether they’re used in personal computers (PCs), laptops, tablets, smartphones or even in supercomputers whose output is so strong it must be measured in floating-point operations per…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters