Manage 5G Core CNF lifecycles on Red Hat OpenShift
Here in this blog, we will learn how to manage 5G Core CNF lifecycles on Red Hat OpenShift.
Modern businesses relying on IT infrastructure must prioritize upgrades to stay competitive and secure. These updates are vital for adopting new features, addressing vulnerabilities, and complying with support requirements. For service providers in dynamic markets, regular upgrades are essential to offering advanced services, maintaining customer satisfaction, increasing revenue, and achieving sustained success. However, upgrades can be challenging, especially when they fall outside regular maintenance windows. Operations teams often delay upgrades due to time constraints.
Red Hat simplifies the upgrade, deployment, and configuration processes for OpenShift clusters running 5G core cloud-native network functions (CNFs). Its streamlined upgrade process ensures compatibility across CNFs, application platforms, and operating systems, reducing complexity and enhancing performance and reliability for 5G networks.
Preparing for a Red Hat OpenShift Upgrade
Thorough preparation is critical when upgrading between Red Hat OpenShift Extended Update Support (EUS) releases. By upgrading sequentially between releases, you can efficiently move from version 4.Y to 4.Y+2. Follow these steps to ensure success:
Step 1: Consult Documentation
Red Hat OpenShift documentation includes commands, release notes, and detailed configuration settings relevant to upgrades. Properly understanding these settings is essential, as misconfigurations can disrupt the process. Key configuration considerations include:
- Pod Disruption Budget (PDB): Ensure at least one pod can be down during voluntary disruptions.
- Anti-Affinity Rules: Spread pods across multiple worker nodes to streamline node reboots and upgrades.
- Graceful Shutdowns: Optimize
terminationGracePeriodSeconds
to allow pods sufficient time to shut down gracefully. - Readiness Probes: Ensure readiness probes are set correctly to avoid deployment issues during pod transitions.
Step 2: Determine the Correct Update Path
Use the Red Hat OpenShift Container Platform update graph tool to identify the appropriate update sequence. Address any flagged potential issues based on your cluster’s configuration.
Step 3: Plan CNF Upgrades
Maintaining 5G core CNFs during the upgrade is vital. Refer to Red Hat’s 5G core solution documentation for best practices tailored to telecommunications environments.
Step 4: Verify Operator Compatibility
Operators installed through the Operator Lifecycle Manager (OLM) are not upgraded automatically. Use the Red Hat OpenShift operator update checker to identify required updates, ensuring compatibility for intermediate and final releases.
Step 5: Update Offline Repositories
Follow industry best practices by verifying images before deploying them. Update offline repositories with the latest images to ensure a smooth upgrade process.
Step 6: Back Up etcd
The etcd
key-value store contains critical cluster data. Use the recommended backup procedures to securely store etcd
data outside the OpenShift environment.
Step 7: Pause Worker Node MachineConfigPools
Pausing MachineConfigPools (MCPs) allows configuration changes to be prepared without immediate implementation. This ensures worker nodes reboot only once during the EUS upgrade.
Step 8: Prepare for Firmware Updates
Some 5G core CNF changes may require firmware updates for bare-metal server clusters. Check the release notes for specific guidance.
Step 9: Verify Cluster Health
Ensure your cluster is healthy before starting the upgrade by running a cluster health verification command.
Performing the Red Hat OpenShift Upgrade
After completing the preparation steps, proceed with the upgrade as follows:
Step 10: Upgrade the Control Plane to 4.Y+1
Begin by updating the control plane and cluster operators to version 4.Y+1. This process involves rebooting control plane nodes without affecting CNF pods or worker nodes. Perform this step during a maintenance window.
Step 11: Upgrade OLM-Based Operators to 4.Y+1
Upgrade necessary OLM-based operators to ensure compatibility with the intermediate release. Ensure updated operator images are available in offline repositories.
Step 12: Upgrade the Control Plane to 4.Y+2
Proceed with upgrading the control plane and cluster operators to the final release, version 4.Y+2. Control plane nodes will reboot, while worker nodes remain unaffected.
Step 13: Upgrade OLM-Based Operators to 4.Y+2
Update the remaining OLM-based operators for compatibility with version 4.Y+2.
Step 14: Upgrade Worker Nodes
Unpause MCPs to update and reboot worker nodes. If the cluster has multiple MCPs, upgrade them incrementally as time permits.
Observations and Best Practices
Field experiences show that this process can minimize service disruptions, with minimal impact on signaling and payload traffic. However, unforeseen issues, such as hardware failures or undocumented network changes, may arise. To ensure success:
- Prepare thoroughly.
- Follow the recommended steps.
- Pause and verify progress as needed.
By adhering to these best practices, you can confidently upgrade your Red Hat OpenShift infrastructure and maintain optimal performance.