RKE1 on Support Tools

Migrating from RKE1 to RKE2 Using pv-migrate: A Targeted Storage Migration Tool

Thu, 13 Mar 2025 01:49:00 -0500

With RKE1 reaching end-of-life on July 31, 2025, organizations need efficient solutions for migrating their persistent data to RKE2 clusters. For teams focused specifically on storage migration, pv-migrate offers a specialized, lightweight approach for transferring Persistent Volume Claims (PVCs) across clusters.

Migrating from RKE1 to RKE2 Using Longhorn DR Volumes: A Kubernetes-Native Approach

Thu, 13 Mar 2025 01:48:00 -0500

With RKE1 reaching its end-of-life on July 31, 2025, organizations running Longhorn for persistent storage have a powerful built-in option for migration to RKE2. Longhorn’s Disaster Recovery (DR) volumes provide a Kubernetes-native approach that synchronizes data directly between clusters for efficient, low-downtime migration.

Migrating from RKE1 to RKE2 Using Velero: An Open-Source Approach

Thu, 13 Mar 2025 01:45:00 -0500

With RKE1 approaching its end-of-life date on July 31, 2025, organizations need reliable migration strategies to transition to RKE2. Velero, an open-source backup and restore tool for Kubernetes, offers a cost-effective approach for this migration that works across diverse environments.

Migrating from RKE1 to RKE2 Using Kasten K10: A Complete Backup and Restore Guide

Thu, 13 Mar 2025 01:44:00 -0500

With RKE1’s end-of-life approaching on July 31, 2025, organizations need efficient strategies to migrate to RKE2. Kasten K10 by Veeam provides a powerful Kubernetes-native solution for this migration that handles both application state and data persistence.

Migrating from RKE1 to RKE2 Using CloudCasa: A Backup and Restore Approach

Thu, 13 Mar 2025 01:42:00 -0500

With RKE1 reaching end-of-life on July 31, 2025, organizations need reliable strategies to migrate their workloads to RKE2. CloudCasa offers a powerful backup and restore approach for this migration, providing a comprehensive solution that handles both stateless and stateful workloads.

Migrating from RKE1 to RKE2 using YAML Export/Import

Wed, 12 Mar 2025 00:00:00 -0500

Migrating from RKE1 to RKE2 can be done in multiple ways, and one of the simplest is YAML Export/Import. This method is ideal for stateless workloads where persistent storage migration is not required. It’s a fast and effective way to move Deployments, Services, ConfigMaps, and other Kubernetes resources with minimal dependencies.

Migrating from RKE1 to RKE2: A Seamless Transition with SUSE Rancher Prime

Wed, 12 Mar 2025 00:00:00 -0500

Migrating from RKE1 to RKE2 is an essential transition for organizations relying on Rancher-managed Kubernetes clusters. With RKE1 reaching end-of-life (EOL) on July 31, 2025, moving to RKE2 ensures ongoing support, security updates, and performance improvements.

Kubernetes Master Class: A Seamless Approach to Rancher & Kubernetes Upgrades

Mon, 14 Oct 2024 17:30:00 -0500

Kubernetes Master Class: A Seamless Approach to Rancher & Kubernetes Upgrades

Upgrading your Rancher and Kubernetes clusters requires a strategic approach to minimize downtime and ensure seamless operation. This guide covers rules, backup operations, planning steps, and upgrade procedures for Rancher and Kubernetes environments using RKE1 and RKE2.

High-Level Rules for Upgrades

Create an upgrade plan
- Using the rule listed below, create a plan for all of your upgrades and follow it.
- You might need to do multiple upgrades to get to the latest version.
- Please use Rancher Upgrade Tool to help you pick the right version(s) to upgrade to. Rancher Upgrade Tool
Don’t Rush Upgrades:
- Allow at least 24 hours between upgrades to ensure the stability of each component.
- Give yourself plenty of time for backups, testing, monitoring, and rollback. I recommend at least 4hr change window for each upgrade.
Don’t Stack Upgrades:
- Avoid upgrading Rancher, Kubernetes, and Docker/Containerd in one session to reduce risk. Perform them sequentially.
Backups Are Mandatory:
- Take ETCD snapshots and use the Rancher Backup Operator to ensure quick recovery in case of failure.
Upgrade Order:
- Follow the sequence: Rancher → Kubernetes → Docker/Containerd → Operating System.
Pause CI/CD Pipelines:
- Halt pipelines using the Rancher API to prevent conflicts during upgrades.
Test in Non-Production Environments:
- Always validate upgrades in a lab environment before deploying to production.
Review Release Notes and Support Matrix:
- Check the Rancher release notes and Kubernetes support matrix to avoid issues with version incompatibilities.
Monitor and Verify:
- Continuously monitor the health of nodes and pods after each upgrade to ensure everything is running smoothly.

A Deep Dive into CoreDNS with Rancher: Best Practices and Troubleshooting

Wed, 14 Aug 2024 05:15:00 -0500

In the evolving landscape of Kubernetes, DNS plays a crucial role in ensuring smooth service discovery and communication within and outside the cluster. CoreDNS, a flexible and scalable DNS server, has been the default choice for Kubernetes since version 1.14. In this post, we’ll dive into CoreDNS’s role within Rancher-managed Kubernetes environments, particularly focusing on RKE1 and RKE2. We’ll explore common issues, troubleshooting techniques, and best practices to optimize your CoreDNS setup.

Rancher Backups and Disaster Recovery for RKE1

Sun, 30 Jun 2024 23:18:00 -0500

Eventually, something will happen that requires restoring a Kubernetes cluster. That’s not a question of if but when.

In the case of Kubernetes, this means regularly backing up the etcd datastore.

How regular? The choice is yours. It is up to you how much data you are willing to lose.

For example, a highly active cluster may take snapshots every fifteen minutes or even every five minutes. In the case of a cluster that does not receive a lot of activity, a snapshot of the cluster might be taken daily.

You can never be fired for having too many backups.

As a default, RKE takes a snapshot every six hours and keeps it for one day, but you can change the settings in the cluster.yaml.

Any time you wish, you can run a snapshot by executing the command rke etcd snapshot-save and passing it the name of the backup and the location of cluster.yml. This command will write a snapshot of all the etcd hosts to /opt/rke/etcd-snapshots. It is possible to mount an NFS volume there, or you can configure RKE to copy the snapshot to S3 to restore it.