Replace a Node in the Control Plane
Replace a failed Virtual Appliance cluster node in the control plane and restore high availability.
- At least two of the three control plane nodes must remain active to maintain
etcd/dqlitequorum.CAUTION: Data can be lost if two or more nodes fail simultaneously. See High Availability Considerations. - Deploy the replacement node by using the same Virtual Appliance version as the existing control plane nodes. See Deploy Splunk AppDynamics On-Premises Virtual Appliance.
- SSH access to the remaining nodes.
Important Considerations
Persistent data stored on the failed node's local disk is not automatically migrated to the replacement node. Kubernetes reschedules pods to healthy nodes, but stateful workloads (databases, Elasticsearch) rely on their own replication mechanisms for data availability.
- Identify the failed control plane node.
- Run the following command to view the cluster nodes.
CODE
appdctl show clusterSample Output:
CODENODE | ROLE | RUNNING ----------------+-------+--------- 10.0.0.1:19001 | voter | true 10.0.0.2:19001 | voter | true 10.0.0.3:19001 | voter | trueNote: The output may continue to showRUNNING: trueeven if the control plane node is failed. Therefore, you must confirm the node status usingmicrok8s kubectl get nodes. - Verify the Kubernetes node status.
CODE
microk8s kubectl get nodesSample Output:
CODENAME STATUS ROLES AGE VERSION node-1 Ready master 30d v1.34.8 node-2 Ready master 30d v1.34.8 node-3 NotReady master 30d v1.34.8In this example,
node-3has failed and requires replacement.
- Run the following command to view the cluster nodes.
- Remove the failed node from the cluster:
CODE
microk8s remove-node <node-ip-address> --forceFor example:
CODEmicrok8s remove-node 10.0.0.3 --forceNote: After removing a node, the cluster temporarily loses high availability. Themicrok8s statusoutput showshigh-availability: nountil a replacement node is added.- Verify whether the node is removed.
CODE
appdctl show clusterSample Output:
CODENODE | ROLE | RUNNING --------------------+-------+--------- 10.0.0.1:19001 | voter | true 10.0.0.2:19001 | spare | true - Verify the Kubernetes node status.
CODE
microk8s kubectl get nodesSample Output:
CODENAME STATUS ROLES AGE VERSION node-1 Ready master 30d v1.34.8 node-2 Ready master 30d v1.34.8
- Verify whether the node is removed.
- To initialize a replacement node, deploy the Virtual Appliance image version as the existing cluster:
- Deploy a node using the same Virtual Appliance version as the existing version. See Deploy Splunk AppDynamics On-Premises Virtual Appliance.
- Verify the boot status of the replacement node:
CODE
appdctl show bootSample Output:
CODENAME | STATUS | ERROR -------------------+-----------+------- cloud-init-config | Succeeded | -- enable-time-sync | Succeeded | -- firewall-setup | Succeeded | -- storage-setup | Succeeded | -- hostname | Succeeded | -- microk8s-setup | Succeeded | -- netplan | Succeeded | -- ssh-setup | Succeeded | -- cert-setup | Succeeded | --Note:Ensure that all services appear as
Succeeded. If any service appears asFailed, restart the virtual machine. If it still fails, redeploy the virtual machine.
- Add the replacement node to the cluster.
- Run the following command on a healthy cluster node to generate the join token:
CODE
appdctl cluster add-nodeSample Output:
CODEEnter the following command on the node as master to join the cluster: appdctl cluster join 10.0.0.1:25000/0b0e24950c829e2df614a1d8866d703f/0950dca162dd Enter one of the following command to join the node as a worker: appdctl cluster join 10.0.0.1:25000/0b0e24950c829e2df614a1d8866d703f/0950dca162dd --worker microk8s.join 10.0.0.1:25000/0b0e24950c829e2df614a1d8866d703f/0950dca162dd --worker - Run the following command to join the replacement node to the cluster's control plane.
CODE
appdctl cluster join <copy-the-generated-join-token>For example:
CODEappdctl cluster join 10.0.0.1:25000/0b0e24950c829e2df614a1d8866d703f/0950dca162ddSample Output:
JSON{ "status": "WARNING: Hostpath storage is enabled and is not suitable for multi node clusters.\n\nContacting cluster at 10.0.0.1\nWaiting for this node to finish joining the cluster. .. .. .. .. .. \nSuccessfully joined the cluster.\n" }CAUTION: Do not use the--workerflag when replacing a failed node. The replacement node must join the control plane to restore high availability anddqlitequorum. - Verify the cluster includes the replacement node:
CODE
appdctl show clusterSample Output:
CODENODE | ROLE | RUNNING --------------------+-------+--------- 10.0.0.1:19001 | voter | true 10.0.0.2:19001 | voter | true 10.0.0.4:19001 | voter | true - Verify the Kubernetes node status.
CODE
microk8s kubectl get nodesSample Output:
CODENAME STATUS ROLES AGE VERSION node-1 Ready master 30d v1.34.8 node-2 Ready master 30d v1.34.8 node-4 Ready master 2m v1.34.8
Once the replacement node successfully joins the cluster, it initiates data replication from existing nodes. - Run the following command on a healthy cluster node to generate the join token:
- Verify the data replication status using the following command:
CODE
appdcli run infra_inspectSample Output:
CODENAME READY STATUS RESTARTS AGE appd-mysqlsh-0 1/1 Running 0 4m33s appd-mysql-0 2/2 Running 0 4m33s appd-mysql-1 2/2 Running 0 4m33s appd-mysql-2 2/2 Running 0 4m33s appd-mysql-router-9f8bc6784-g7zx7 1/1 Running 0 5s appd-mysql-router-9f8bc6784-fhjnp 1/1 Running 0 5s appd-mysql-router-9f8bc6784-wrcwk 1/1 Running 0 5s - Verify whether the high-availability status is restored.
CODE
microk8s statusSample Output:
CODEmicrok8s is running high-availability: yes datastore master nodes: 10.0.0.1:19001 10.0.0.2:19001 10.0.0.4:19001 datastore standby nodes: none