This container sets up the initial entry in a kubeconfig file that Cloudify Manager (and potentially other components) can use to access multiple Kubernetes clusters. The initial entry is for the central site.
The container runs a short Python script to completion. It's meant to be run as an init container or as a standalone Kubernetes Job. (In the R4 ["Dublin"] release, it's run as an init container for the Cloudify Manager pod.) The script works by using the Kubernetes API to get three pieces of information about the cluster where the script is running:
The script combines this information with other values provided from command line arguments and/or defaults to create a kubeconfig-style structure that it uses to update an existing Kubernetes ConfigMap. (It uses an existing ConfigMap, rather than creating a new one, in order to work well with the OOM Helm deployment strategy. The OOM Helm charts create an empty ConfigMap, so that Helm knows about the ConfigMap and can delete it cleanly when uninstalling. If the script created a new ConfigMap, Helm would not know about it and would not delete it during an uninstall operation.)
The table below shows the command line arguments that can be passed to the script via the "args" array in the Kubernetes spec for the container. | Argument | Description | Required? | Default |----------|-------|-----------|-------- |--namespace, -n | Namespace where CM will run | Yes | None |--location, -l | Name of the central location | No | "central" |--user, -u | User name for authorization | No | "user00" |--configmap, -c | Name of the ConfigMap where the kubeconfig is stored | No | "multisite-kubeconfig-configmap" |--key, -k | Key under which the kubeconfig is stored (when mounted on a container, this will be file name)| No | "kubeconfig"