OpenStack is an open-source cloud computing platform that has gained significant traction in the telecoms sector. Meanwhile, OpenShift is a Kubernetes-based containerization platform developed by Red Hat.

The general availability of OpenStack Services on OpenShift means that organizations can now deploy cloud platforms as part of their containerized workflows. Red Hat touts the combination of the tools as a better way for organizations, especially in the telecom industry, to integrate traditional and cloud-native networks.

This is a significant step forward in how enterprises, particularly telecommunication service providers, can better unify traditional and cloud-native networks into a singular, modernized network fabric. Red Hat OpenStack Services on OpenShift opens up a new pathway for how organizations can rethink their virtualization strategies, making it easier for them to scale, upgrade and add resources to their cloud environments.

Red Hat says OpenStack Services on OpenShift allows compute node deployment up to 4x faster than Red Hat OpenStack Platform 17.1.

The company also touts the following benefits.

• Accelerated time-to-market with Ansible integration;
• A scalable OpenStack control plane that can manage Kubernetes-native pods running on Red Hat OpenShift;
• Easier day 2 operations for control plane and lifecycle management;
• Greater cost management and freedom to choose third party plug-ins and virtualize resources;
• Improved security and compliance scanning of the control plane and Role-based Access Control encrypts communications and memory cache;
• A deeper understanding about the health of your hybrid cloud with observability user interface, cluster observability operator and an OpenShift cluster logging operator;
• AI-optimized infrastructure supports hardware acceleration technologies to help ensure seamless integration and efficient utilization of specialized hardware for AI tasks.

Red Hat says OpenStack Services on OpenShift should be a boon for telecom companies, especially as they look to capitalize on AI developments.

By further blending Red Hat OpenStack Platform with Red Hat OpenShift, Red Hat will continue to help telecommunication service providers solve today’s problems while also preparing their environments to best capitalize on opportunities provided by intelligent networks that can leverage AI, flourish at the edge and scale on-demand. 94% of telecommunication companies in the Fortune 500 rely on Red Hat, underscoring our proven ability to support and modernize their networks. With Red Hat OpenStack Services on OpenShift, telecommunication service providers can expand new services, applications and revenue streams – propelling their business forward for 5G and beyond.

“Red Hat’s dedication to OpenStack is demonstrated through our extensive contributions to the project, our leadership in the OpenStack community and our focus on delivering enterprise-grade OpenStack solutions to our customers,” said Chris Wright, senior vice president of global engineering and chief technology officer. “This dedication must evolve as our customers’ needs change, and Red Hat OpenStack Services on OpenShift will help provide our OpenStack customers with a more unified, flexible application platform.”

The Importance of Scaling in Kubernetes

Scaling is one of the most critical aspects of cloud computing, particularly in containerized environments like Kubernetes. Effective scaling ensures that applications have the right amount of resources—neither too much nor too little—to meet their operational demands. This delicate balance is crucial because over-provisioning resources leads to unnecessary costs, while under-provisioning can degrade performance or even cause application failures.

As one Kubernetes expert from Sysxplore succinctly puts it: “Scaling is probably one of the most important aspects of computing and a common cause of bankruptcy if our processes use more memory and CPU than what they need—they’re wasting money or stealing those resources from others.” The goal, therefore, is to assign just the right amount of resources to processes, a task that Kubernetes helps achieve through its sophisticated scaling mechanisms.

Vertical Scaling: A Legacy Approach

Vertical scaling, or scaling up, involves adding more CPU and memory to an existing node or application. This method increases the capacity of individual components rather than adding more components to handle the load. In Kubernetes, vertical scaling is typically managed through the Vertical Pod Autoscaler (VPA), which adjusts the resource limits of pods based on their observed usage.

For legacy applications that cannot run multiple replicas, vertical scaling is often the only viable option. “Vertical scaling is useful for applications that cannot run multiple replicas—so single-replica applications might be good candidates for VPA and not much more,” says a Kubernetes consultant. However, the limitations of vertical scaling are evident; it does not work well with horizontal scaling, which is the preferred method in most modern cloud-native applications.

Moreover, vertical scaling in Kubernetes comes with certain caveats. Changes to pod resources often require a pod restart, which can be disruptive to application performance. As the consultant points out, “Single-replica applications are the best candidates for vertical scaling, but we do not tend to design applications like that anymore.” Consequently, while vertical scaling has its place, particularly in managing older applications, it is not the go-to strategy for most Kubernetes environments.

Horizontal Scaling: The Preferred Strategy

Horizontal scaling, or scaling out, is the process of increasing the number of replicas of a pod to distribute the load more evenly across multiple instances. This method is the cornerstone of Kubernetes’ scalability, allowing applications to handle increased traffic by simply adding more pods.

Kubernetes Scaling Strategies pic.twitter.com/1VeBxPN9L9

— sysxplore (@sysxplore) August 24, 2024

Horizontal Pod Autoscaler (HPA) is the primary tool for managing horizontal scaling in Kubernetes. HPA monitors metrics like CPU and memory usage and adjusts the number of pod replicas accordingly. “Horizontal scaling is a must for all applications that can run multiple replicas and do not get penalized by being dynamic,” the Sysxplore expert notes. This method is particularly effective for stateless applications, which can easily be replicated without worrying about data consistency across instances.

For example, an HPA configuration might specify that an application should have a minimum of two replicas and a maximum of five, scaling up when CPU usage exceeds 80%. This ensures that the application can handle varying loads without overburdening any single pod. However, HPA is not without its limitations. It primarily scales based on CPU and memory metrics, which may not capture the full picture of an application’s performance needs.

Event-Driven Scaling with KEDA

For more complex scaling requirements, particularly those involving external or custom metrics, Kubernetes Event-Driven Autoscaling (KEDA) offers a more flexible alternative to HPA. KEDA allows scaling based on a wide range of triggers, such as queue length, database load, or custom application metrics.

“KEDA shines for scaling based on any other criteria,” says a Kubernetes architect. Unlike HPA, which is limited to CPU and memory metrics, KEDA can scale applications based on virtually any metric that can be observed, making it ideal for event-driven applications. For instance, an e-commerce platform might use KEDA to scale its order processing service based on the number of pending orders in a queue, ensuring that the system can handle sudden spikes in demand.

KEDA works by extending the capabilities of HPA, integrating with various data sources such as Prometheus, Kafka, or Azure Monitor. This flexibility makes KEDA particularly powerful in environments where applications need to respond quickly to external events or where traditional resource metrics are insufficient to determine scaling needs.

Scaling Kubernetes Nodes: Vertical vs. Horizontal

Just as applications need to be scaled, so too do the nodes that run them. In Kubernetes, node scaling can be approached vertically or horizontally, each with its own set of considerations.

Vertical scaling of nodes involves adding more resources—CPU, memory, or storage—to existing nodes. While this might be necessary in certain on-premises environments, it is generally less efficient in cloud environments, where nodes are typically created and destroyed dynamically. “If a node is too small, create a bigger one and move the app that needed more capacity to that node,” advises the Sysxplore expert. The overhead involved in dynamically resizing nodes often makes horizontal scaling the more practical choice.

Horizontal scaling of nodes, managed by the Cluster Autoscaler, is the preferred method in Kubernetes environments. The Cluster Autoscaler automatically adjusts the number of nodes in a cluster based on the resource requirements of the pods running within it. This ensures that the cluster can handle varying workloads without the need for manual intervention.

For example, during a traffic spike, the Cluster Autoscaler might add additional nodes to ensure that all pods have the resources they need. Once the traffic subsides, the autoscaler reduces the number of nodes, saving costs by only using the resources that are necessary at any given time.

“Horizontal scaling of nodes is a no-brainer,” the expert asserts. “Enable Cluster Autoscaler right away—just do it.” This strategy not only optimizes resource utilization but also ensures that the cluster can scale up or down in response to real-time demands, providing both flexibility and cost-efficiency.

Best Practices for Kubernetes Scaling

Given the various scaling strategies available in Kubernetes, determining the best approach for your applications can be challenging. Here are some best practices to guide your scaling decisions:

1. Use Vertical Scaling for Legacy Applications: If your application cannot run multiple replicas, consider using VPA to manage its resource allocation. However, be mindful of the limitations and potential disruptions caused by pod restarts.
2. Leverage Horizontal Scaling for Modern Applications: For most cloud-native applications, horizontal scaling with HPA is the optimal choice. Ensure that your applications are designed to run multiple replicas and are stateless where possible.
3. Incorporate Event-Driven Scaling with KEDA: For applications that need to respond to external events or custom metrics, KEDA provides the flexibility needed to scale based on non-traditional metrics. Consider using KEDA alongside HPA for complex applications with diverse scaling requirements.
4. Automate Node Scaling with Cluster Autoscaler: Always enable the Cluster Autoscaler in your Kubernetes clusters. This ensures that your cluster can dynamically adjust its size to meet the resource demands of your applications, optimizing both performance and cost.
5. Monitor and Adjust Scaling Parameters: Scaling is not a set-it-and-forget-it process. Continuously monitor the performance of your scaling strategies and adjust parameters as needed to ensure optimal resource utilization.

Final Thoughts: Scaling Kubernetes for Success

Scaling in Kubernetes is a multifaceted challenge that requires a deep understanding of both the platform and your specific application needs. By leveraging the right combination of vertical and horizontal scaling strategies, along with tools like HPA, VPA, KEDA, and the Cluster Autoscaler, you can ensure that your Kubernetes deployments are both efficient and resilient.

As cloud computing continues to evolve, so too will the strategies for scaling Kubernetes. Staying informed about the latest developments and best practices will be key to maintaining a competitive edge in this dynamic landscape. Whether you’re scaling a small startup application or a large enterprise system, Kubernetes provides the tools you need to manage resources effectively, ensuring that your applications can grow and adapt in an ever-changing environment.