Move Cluster from One Control Plane CIDR to Another¶

This procedure allows you to migrate a single-node ARTESCA deployment to use a new control plane CIDR. This operation updates all cluster components including etcd, kubernetes API server and kubelet configurations.

Important

Only perform this procedure with the assistance of Scality Support.

Security Considerations¶

All cluster communications use TLS encryption during the migration.
etcd data is preserved throughout the process.
Kubernetes RBAC settings remain unchanged.
No service account tokens are invalidated.

Limitations¶

This procedure is designed for single-node deployments only.
The operation requires temporary cluster downtime.
Network interface changes must be performed manually before running the command.

Warning

Do not perform this procedure on multi-node deployments.

Prerequisites¶

Network Interface Reconfiguration¶

Before running the move-cluster command, reconfigure the network interface(s) to use the new control plane CIDR on the node.

nmcli (command line)

[artesca-os@bootstrap ~]$

# Example: Moving from 192.168.1.0/24 to 10.0.1.0/24
sudo nmcli connection modify <connection-name> ipv4.addresses 10.0.1.10/24
sudo nmcli connection modify <connection-name> ipv4.gateway 10.0.1.1
sudo nmcli connection up <connection-name>

If you have nameservers configured within the old control plane CIDR, update them using the following command:

[artesca-os@bootstrap ~]$

sudo nmcli connection modify <connection-name> ipv4.dns <nameserver>

nmtui (interactive)

[artesca-os@bootstrap ~]$

sudo nmtui

Navigate to Edit a connection.
Choose your connection.
Navigate to IPv4 CONFIGURATION and update the IP configuration.

If you have nameservers configured within the old control plane CIDR, navigate to DNS servers and update them.

To ensure the changes are applied, restart the network manager.

[artesca-os@bootstrap ~]$

sudo systemctl restart NetworkManager

Procedure¶

[artesca-os@bootstrap ~]$

sudo ./artesca-installer move-cluster

Tip

You can enter all options from the command line, if you do not want input prompts. Check --help for information about the options.

Process Overview¶

The migration process includes the following steps:

Validation: Confirms single-node deployment and network compatibility.
Node Preparation: Cordons the node and creates a temporary dummy interface.
Configuration Update: Updates bootstrap configuration with new CIDR.
Component Reconfiguration: Updates kubelet, Salt, and repository configurations.
Cluster Services: Restarts etcd, API server, and other control plane components.
Network Updates: Updates etcd peer URLs and cluster networking.
Cleanup: Removes temporary interfaces and uncordons the node.

Post-Migration Tasks¶

Front-end Reconfiguration¶

You may need to reconfigure the front end to use the new control plane CIDR if the Management IP used was on the old control plane CIDR. Please refer to the Change Management IP procedure.

Validation¶

Verify that the migration was successful.

Check the cluster status

Check the nodes status

[artesca-os@bootstrap ~]$

sudo kubectl --kubeconfig=/etc/kubernetes/admin.conf \
   get nodes

Check the pods status

[artesca-os@bootstrap ~]$

sudo kubectl --kubeconfig=/etc/kubernetes/admin.conf \
   get pods --all-namespaces

Check the Artesca UI accessibility

Retrieve the new control plane IP.

[artesca-os@bootstrap ~]$

export NEW_CP_IP=$(sudo salt-call metalk8s_network.get_control_plane_ingress_ip --out txt | awk '{print $2}')
echo "$NEW_CP_IP"

Access the Artesca UI

[artesca-os@bootstrap ~]$

curl -k https://${NEW_CP_IP}:8443

Workload Plane CIDR¶

If you also need to change the workload plane CIDR, refer to the Change a Workload Plane CIDR procedure.

Note

The control plane and workload plane migrations are independent operations and can be performed separately.

Single-network consolidation¶

The new control plane CIDR may be set equal to the workload plane CIDR to consolidate the control plane and workload plane onto a single network on the single-node deployment. Overlaps with the pods or services CIDRs are still rejected.