We continue with our discussion on Kubernetes Kustomization using manifests from a few posts earlier. 

The use of metadata to improve the information on the resource without having to introspect the resource helps in making decisions about the resources and for visibility between source and destination of transfer.
Till now, we have discussed custom resources and applying it for traditional clusters. Custom resources can be used with personal computing Kubernetes clusters such as those on windows. Two technologies made it possible for developers to overcome the reduced support on native development over Windows. First, the ability to specify insecure registry to house all the container images mean that the containers don’t require a login or have to go online to external registries to fetch their images. Second, the Kubernetes cluster for windows would accept this insecure registry as a parameter at startup to allow its orchestration framework to redirect all requests for container image lookups to the passed in registry. Together they helped the containers find and load their images for applications to run.
Kubernetes manifests can be applied across applications, services and charts. This makes it very powerful tool to add configmaps, secrets and change existing definitions.
It is not a full configuration management system or database. It’s limited set of Kustomization files provide Kubernetes specific customization. A tool for keeping it in sync with the deployments can work outside its scope since the kustomization files are declarative.