Right now, clusterlint analyzes the workloads after they have been deployed on a managed/self hosted platform. This is great because:
- Users may not deploy everything into a cluster from one place, and actual deployments can diverge from manifests.
- It can be used to identify problems that can occur on a cluster even if manifests were alright (example: not setting resource requests and limits)
Adding a feature to lint the manifests before attempting to deploy the workloads on a cluster can be useful to prevent bad configs. This will be particularly useful if there is CI/CD in place to automatically deploy the workloads after making sure that all the configs are fine. This can act as a sanity check before the config is merged in a SCM repository.
Right now, clusterlint analyzes the workloads after they have been deployed on a managed/self hosted platform. This is great because:
Adding a feature to lint the manifests before attempting to deploy the workloads on a cluster can be useful to prevent bad configs. This will be particularly useful if there is CI/CD in place to automatically deploy the workloads after making sure that all the configs are fine. This can act as a sanity check before the config is merged in a SCM repository.