Transferring roles from the master node
There is not enough resource capacity on the master node when the master and management nodes are in the same host file.
Symptoms
The log message file becomes too large and utilizes disk space.
Causes
There are master and management nodes in the same host file.
Resolving the problem
Transfer the node roles to a new host file: management, proxy, and Vulnerability Advisor.
Transferring management roles
Important: The PersistentVolumes must be transferred to a new node because some pods have local storage data on the management node.
-
Remove the management label from your master node:
-
Get the label for your master node by running the following command:
kubectl get nodes <master.node.name> --show-labels
Your output might resemble the following content:
beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=<master.node.name>,management=true,node-role.kubernetes.io/management=true
-
Remove the
management
role labels from your master node by running the following command:kubectl label nodes <master.node.name> management- node-role.kubernetes.io/management-
Your output might resemble the following message:
<master.node.name> labeled
-
Verify the
management
role labels are removed from your master node by running the following command:kubectl get nodes <master.node.name> --show-labels
Your output might resemble the following content:
beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=<master.node.name>
-
-
Add your new management node with the following steps:
-
Prepare your new management node for installation. For more information, see Preparing the new node for installation.
-
Remove the IP address of your master node in the host file on your management node. To access your host file, run the following command:
vi /etc/hosts
-
Add a new management node to your IBM Cloud Private cluster by running the following command:
docker run -e LICENSE=accept --net=host \ -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee management -l \ ip_address_managementnode1,ip_address_managementnode2
-
- Create PersistentVolumes on your new management node with the following steps:
- On each node, create a local storage directory by running the following commands:
mkdir -p /var/lib/icp/logging/elk-data && chmod 755 /var/lib/icp/logging/elk-data
- Create a
pv.yaml
file for each node. Your PersistentVolume file might resemble the following content:apiVersion: v1 kind: PersistentVolume metadata: name: logging-datanode-<management_node_name> # replace <management_node_name with the name of the ICP management node, can be found using kubectl get nodes spec: accessModes: - ReadWriteOnce capacity: storage: 20Gi # adjust to customer need local: path: /var/lib/icp/logging/elk-data # adjust to customer need nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <management_node_name> # set to name of the ICP management node, can be found using kubectl get nodes persistentVolumeReclaimPolicy: Retain storageClassName: logging-storage-datanode
- Create a PersistentVolume by running the following command:
kubectl create -f pv.yaml
- On each node, create a local storage directory by running the following commands:
-
Move the local storage data from the master node onto your new management node. Transfer the
elasticsearch
data with the following steps:-
Backup the
elasticsearch
data by creating a compressed archive file of the data from the storage directory by running the following command:tar -czf ~/logging-backup.tar.gz /var/lib/icp/logging/elk-data/*
-
Use your server copy to transfer the data file onto your new master node by running the following command:
scp ~/logging-backup.tar.gz <node_user>@<node_ip>:~/logging-backup.tar.gz
-
Restore the
elasticsearch
data by replacing the files in local storage directory by the files that are extracted from the compressed archive file by running the following commands:rm -r /var/lib/icp/logging/elk-data/* tar -C /var/lib/icp/logging/elk-data -xzf ~/logging-backup.tar.gz --strip-components 2
-
-
Migrate the
logging
,metering
,monitoring
, andkey-management
services to your new management node.-
Disable the services on your master nodes. See Disable services for more information.
-
You can disable the services from your
config.yaml
file. Update themanagement_services
parameter. Yourconfig.yaml
file might resemble the following contents:management_services: logging: disabled metering: disabled monitoring: disabled key-management: disabled
-
You can also disable the services by running the following command:
docker run --rm -t -e LICENSE=accept --net=host -v $(pwd):/installer/cluster ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee addon
-
-
Delete the PersistentVolumeClaim and PersistentVolumes of the
logging
service with the following steps:-
Get the PersistentVolumeClaim and PersistentVolumes of the
logging
service by running the following commands:kubectl get pvc -n kube-system | grep data-logging-elk-data kubectl get pv | grep logging-datanode
-
Delete the PersistentVolumeClaim and PersistentVolumes of the
logging
service by running the following commands:kubectl delete pvc <persistent-volume-claim-name> -n kube-system kubectl delete pv <persistent-volume-name>
-
-
Enable the services on your master nodes.
-
You can enable the services from your
config.yaml
file. Update themanagement_services
parameter. Yourconfig.yaml
file might resemble the following contents:management_services: logging: enabled metering: enabled monitoring: enabled key-management: enabled
-
You can also enable the services by running the following command:
docker run --rm -t -e LICENSE=accept --net=host -v $(pwd):/installer/cluster ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee addon
-
-
-
Verify that your pods are transferred onto your new management node by running the following command:
kubectl get pods -n kube-system -o custom-columns=Name:.metadata.name,STATUS:.status.phase,NODE:.spec.nodeName
Your output might resemble the following information:
logging-elk-client-74d744cdc6-l7ds5 Running <new-node-name> logging-elk-data-0 Running <new-node-name> metering-* Running <new-node-name> monitoring-* Running <new-node-name> key-management-* Running <new-node-name>
Your management node roles are transferred to a new node.
Transferring proxy roles
-
Prepare your new proxy node for installation. For more information, check Preparing the new node for installation.
-
Add your new proxy node to your IBM Cloud Private cluster by running the following command:
docker run -e LICENSE=accept --net=host \ -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee proxy -l \ ip_address_proxynode1,ip_address_proxynode2
-
Remove the
proxy
label from your master node.-
Get the label for your master node by running the following command:
kubectl get nodes <master.node.name> --show-labels
-
Remove the
proxy
role labels from your master nodes by running the following command:kubectl label nodes <master.node.name> proxy- node-role.kubernetes.io/proxy-
-
Verify that the
proxy
role labels are removed from your master node by running the following command:kubectl get nodes <master.node.name> --show-labels
-
-
Delete and transfer the following pods onto your new management node:
nginx-ingress-controller
default-http-backend
istio-egressgateway
istio-ingressgateway
To delete the pods, run the following commands:
kubectl get pods --all-namespaces -o=custom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace | grep -E 'nginx-ingress-controller|default-http-backend|istio-ingressgateway|istio-egressgateway' | while read pods; do pods_name=$(echo $pods | awk '{print $1}'); pods_namespace=$(echo $pods | awk '{print $2}'); echo "-----------------------------------------------------------------------" echo "| Pods: ${pods_name}" echo "| Namespace: ${pods_namespace}" echo "-----------------------------------------------------------------------" echo "Deleting proxy pod ${pods_name} ..." kubectl delete pods ${pods_name} -n ${pods_namespace} --grace-period=0 --force &>/dev/null done
Note: If the
k8s-proxy-vip
pod exists on your master node, you must move the pod to the/etc/cfc/pods/k8s-proxy-vip.json
file onto your new proxy node. Verify thatk8s-proxy-vip
pod exists and move it by running the following commands:kubectl get k8s-proxy-vip -n kube-system scp etc/cfc/pods/k8s-proxy-vip.json <node_user>@<node_ip>:etc/cfc/pods/k8s-proxy-vip.json
The
kube-scheduler
reschedules the pods to your new proxy node. -
Verify that your pods are transferred to your new proxy node by running the following command:
kubectl get pods -n kube-system -o custom-columns=Name:.metadata.name,STATUS:.status.phase,NODE:.spec.nodeName
Your output might resemble the following information:
nginx-ingress-controller Running <new-node-name> default-http-backend Running <new-node-name>
Your proxy node roles are transferred to a new node.
Transferring vulnerability advisor roles
Important: The PersistentVolumes must be transferred to a new node because some pods have local storage data on the management node.
-
Remove the
va
label from your master node with the following steps:-
Get the label for your master node by running the following command:
kubectl get nodes <master.node.name> --show-labels
-
Remove the
va
role label by running the following command:kubectl label nodes <master.node.name> va- node-role.kubernetes.io/va-
-
Verify that the
va
role label is removed from your master node by running the following command:kubectl get nodes <master.node.name> --show-labels
-
-
Add your new VA node with the following steps:
-
Prepare your new VA node for installation. For more information, see Preparing the new node for installation.
-
Remove the IP address of your master node from your host file on your VA node. To access your host file, run the following command:
vi /etc/hosts
-
Add a new vulnerability advisor node to your IBM Cloud Private cluster by running the following command:
docker run --rm -t -e LICENSE=accept --net=host -v \ $(pwd):/installer/cluster ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee va -l \ ip_address_vanode1,ip_address_vanode2
-
- Create PersistentVolumes on the new VA node
- On each node, you need to create a local storage directory for
minio
,zookeeper
andkafka
by running the following commands:mkdir -p /var/lib/icp/va/minio/ && chmod 755 /var/lib/icp/va/minio/ mkdir -p /var/lib/icp/va/zookeeper/ && chmod 755 /var/lib/icp/va/zookeeper/ mkdir -p /var/lib/icp/va/kafka/ && chmod 755 /var/lib/icp/va/kafka/
- Create a
pv-minio.yaml
,pv-zookeeper.yaml
, andpv-kafka.yaml
file for each node with following contents:apiVersion: v1 kind: PersistentVolume metadata: name: minio-<va_node_name> # replace <va_node_name with the name of the ICP va node, can be found using kubectl get nodes spec: accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain capacity: storage: 20Gi # adjust to customer need local: path: /var/lib/icp/va/minio/ # adjust to customer need nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <va_node_name> # set to name of the ICP va node, can be found using kubectl get nodes storageClassName: minio-storage
apiVersion: v1 kind: PersistentVolume metadata: name: kafka-<va_node_name> # replace <va_node_name with the name of the ICP va node, can be found using kubectl get nodes spec: accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain capacity: storage: 5Gi # adjust to customer need local: path: /var/lib/icp/va/kafka/ # adjust to customer need nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <va_node_name> # set to name of the ICP va node, can be found using kubectl get nodes storageClassName: kafka-storage
apiVersion: v1 kind: PersistentVolume metadata: name: zookeeper-<va_node_name> # replace <va_node_name with the name of the ICP va node, can be found using kubectl get nodes spec: accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain capacity: storage: 5Gi # adjust to customer need local: path: /var/lib/icp/va/zookeeper/ # adjust to customer need nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <va_node_name> # set to name of the ICP va node, can be found using kubectl get nodes storageClassName: zookeeper-storage
- Create the PersistentVolumes by running the following commands:
kubectl create -f pv-minio.yaml kubectl create -f pv-kafka.yaml kubectl create -f pv-zookeeper.yaml
- On each node, you need to create a local storage directory for
-
Move the local storage data from the master node onto your new VA node. Transfer the
minio
,zookeeper
, andkafka
data with the following steps:-
Back up the
minio
,zookeeper
, andkafka
data by creating a compressed archive file of the data from the storage directory by running the following commands:tar -czf ~/minio-backup.tar.gz /var/lib/icp/va/minio/* tar -czf ~/zookeeper-backup.tar.gz /var/lib/icp/va/zookeeper/* tar -czf ~/kafka-backup.tar.gz /var/lib/icp/va/kafka/*
-
Use your service copy to transfer the data file onto your new master node by running the following commands:
scp ~/minio-backup.tar.gz <node_user>@<node_ip>:~/minio-backup.tar.gz scp ~/zookeeper-backup.tar.gz <node_user>@<node_ip>:~/zookeeper-backup.tar.gz scp ~/minio-backup.tar.gz <node_user>@<node_ip>:~/minio-backup.tar.gz
-
Restore the
minio
,zookeeper
andkafka
data by replacing the files in local storage directory by the files extracted from the compressed archive file by running the following commands:rm -r /var/lib/icp/va/minio/* rm -r /var/lib/icp/va/zookeeper/* rm -r /var/lib/icp/va/kafka/* tar -C /var/lib/icp/va/minio -xzf ~/minio-backup.tar.gz --strip-components 2 tar -C /var/lib/icp/va/zookeeper -xzf ~/zookeeper-backup.tar.gz --strip-components 2 tar -C /var/lib/icp/va/kafka -xzf ~/kafka-backup.tar.gz --strip-components 2
-
-
Migrate the VA services to your new management node with the following steps:
-
Disable the VA services on your master nodes. See Disable services.
- You can disable the VA services from your
config.yaml
file. Update themanagement_services
parameter. Yourconfig.yaml
file might resemble the following contents:management_services: vunerability=advisor: disabled
- You can also disable the VA by running the following command:
docker run --rm -t -e LICENSE=accept --net=host -v $(pwd):/installer/cluster ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee addon
- You can disable the VA services from your
-
Delete the PersistentVolumeClaims and PersistentVolumes of the
minio
,zookeeper
, andkafka
services with the following steps:-
Get the PersistentVolumeClaims and PersistentVolumes of
minio
,zookeeper
, andkafka
by running the following commands:kubectl get pvc -n kube-system | grep minio kubectl get pv | grep minio kubectl get pvc -n kube-system | grep zookeeper kubectl get pv | grep zookeeper kubectl get pvc -n kube-system | grep kafka kubectl get pv | grep kafka
-
Delete the PersistentVolumeClaims and PersistentVolumes of the
minio
,zookeeper
, andkafka
services by running the following commands:kubectl delete pvc <persistent-volume-claim-name> -n kube-system kubectl delete pv <persistent-volume-name>
-
-
Enable the services on your master nodes.
-
You can enable the services from your
config.yaml
file. Update themanagement_services
parameter. Yourconfig.yaml
file might resemble the following contents:management_services: vulnerability-advisor: enabled
-
You can also enable the services by running the following command:
docker run --rm -t -e LICENSE=accept --net=host -v $(pwd):/installer/cluster ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee addon
-
-
-
Verify that your pods are transferred to your new VA node by running the following command:
kubectl get pods -n kube-system -o custom-columns=Name:.metadata.name,STATUS:.status.phase,NODE:.spec.nodeName
Your output might resemble the following information:
vulnerability-advisor-compliance-annotator Running <new-node-name>
Your Vulnerability Advisor node roles are transferred to a new node.