diff options
author | Jack Lucas <jflucas@research.att.com> | 2019-03-29 16:45:20 -0400 |
---|---|---|
committer | Jack Lucas <jflucas@research.att.com> | 2019-04-01 18:53:56 -0400 |
commit | f4a008369e54f6ac33e53040762f800e055a0675 (patch) | |
tree | e9c7802ba72153430d7a1c4a97c664c889f3f5a6 /multisite-init-container/README.md | |
parent | 5d9b841b815dd7a6b4f0e06b2da0074a9d268530 (diff) |
Set up kubeconfig ConfigMap
Add container to update configMap with info for central cluster.
Update Cloudify Manager version.
Issue-ID: DCAEGEN2-1136
Issue-ID: DCAEGEN2-1376
Change-Id: I593703b25c2ec9c8fde6ca10c9fc70255c6719a5
Signed-off-by: Jack Lucas <jflucas@research.att.com>
Diffstat (limited to 'multisite-init-container/README.md')
-rw-r--r-- | multisite-init-container/README.md | 33 |
1 files changed, 33 insertions, 0 deletions
diff --git a/multisite-init-container/README.md b/multisite-init-container/README.md new file mode 100644 index 0000000..ce4a0ed --- /dev/null +++ b/multisite-init-container/README.md @@ -0,0 +1,33 @@ +# Multisite Initialization Container +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: + 1. the address of the Kubernetes API server + 2. the CA certificate for the server + 3. an authorization token that can be presented with each API request. + +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" + + |