Uninstall OSM Control Plane from Cluster
- Revision: 1
- Status: Implemented
Table of Contents
- Historical Context
- Looking Forward
A user should be able to delete all Kubernetes resources related to an OSM control plane installation using a CLI command.
A user can use
osm install to install an OSM control plane in a Kubernetes cluster to test out OSM. Once tested, they may want to uninstall the control plane components.
Make it easier to cleanup OSM control planes in test clusters
Delete all Kubernetes resources associated with OSM control plane.
- This version of the proposal will not handle removing any CRDs since these are cluster-wide resources that may be used by other OSM control planes, service mesh implementations or tools.
- This version of the proposal will not handle removing Envoy proxies from application pods. The user must re-start application Pods once the
osmcontrol plane has been uninstalled. Traffic will be interrupted.
- This version does not remove the
openservicemesh.io/monitored-bylabel from the Namespaces observed by an OSM control plane.
osm uninstall MESH_NAME
The CLI command will uninstall the
osm-controller Deployment, Service and any other resources associated with the OSM control plane with the given MESH_NAME.
osm CLI uses Helm libraries and a Helm chart under the hood to install an OSM control plane in a Kubernetes cluster. It also creates a namespace (
osm-system by default) to house the Kubernetes resources defined in and installed using the Helm chart. The
osm uninstall command works by deleting the Helm release associated with the control plane. The Helm release lives in the same namespace as the OSM control plane installation. The namespace will not be deleted because we don’t know what else for now the user has installed in that namespace. Because the SMI CRDs live in the chart’s
crds/ directory, they are protected from any delete action in Helm.
This command and all associated functionality should be unit tested. This command should be added to the simulations run by CI.
In future iterations of this feature, we should:
- have an option to delete the CRDs associated with OSM
- have an option to delete the namespace associate with the OSM control plane
- remove namespace labels/annotations associated with the OSM control plane
- have an automated way of removing the Envoy proxy and any OSM specific labels/annotations from application Pods
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.