Troubleshooting the Tetrate Management Plane
How to troubleshoot a replacement Management Plane installation.
The Management Plane and Control Plane installations are managed by operators. If you make a configuration change, you can monitor the operator logs to watch progress and identify any errors.
Manage the iam-signing-key
The iam-signing-key is used to generate, validate and rotate tokens that are given to the Control Plane Clusters for communication to the Management Plane.
If you could not recover and restore the original iam-signing-key, you will need to refresh the tokens on each Control Plane manually:
-
Log into each Control Plane cluster
-
Rotate tokens by deleting the old tokens:
kubectl delete secret otel-token oap-token ngac-token xcp-edge-central-auth-token -n istio-system
-
Verify that the Control Planes are now connecting to and synchronising with the new Management Plane
The Control Planes won't synchronize
Check the logs of ControlPlane Envoy, looking for errors regarding connections to the Management Plane or errors regarding token validation:
kubectl logs deploy/edge -n istio-system -f
Delete the existing tokens on the Control Plane as described above, and verify that these tokens are re-generated on the Control Plane.
kubectl get secrets otel-token oap-token ngac-token xcp-edge-central-auth-token -n istio-system
If the tokens are not regenerated:
- Check the firewall rules between the Control Pane instance and the new Management Plane instance, and ensure that connections are allowed
- Ensure that the Management Plane is using the same Root CA
Cannot Access external components such as postgres
- Validate the firewall rules to postgres or any other external component.
- Verify the credentials passed via helm or in mp-values.yaml