Add documentation about how to install Kubeapps offline #1766
Conversation
docs/user/offline-installation.md
Outdated
|
|
||
| ```bash | ||
| wget -P charts/ https://charts.bitnami.com/bitnami/mongodb-7.10.10.tgz | ||
| wget -P charts/ https://charts.bitnami.com/bitnami/postgresql-8.9.1.tgz |
There was a problem hiding this comment.
I assume you're intentionally doing this without the helm cli which would pull the correct versions for you? Hmm, though later you're using helm for the install anyway, so given you're assuming both network here and having the helm cli (later) couldn't the above 3 steps (and manual checking for correct versions) be adjusted to be: (using 3.6 since it's available now, just to demo)
helm pull --untar https://charts.bitnami.com/bitnami/kubeapps-3.6.0.tgz
helm dep update ./kubeapps
and updating below to install kubeapps from the directory?
Note, doing the above results in the following chart deps downloaded:
ls -l kubeapps/charts
total 72
drwxr-xr-x 4 michael michael 4096 Jun 4 11:04 mongodb
-rw-r--r-- 1 michael michael 25913 Jun 4 11:04 mongodb-7.14.5.tgz
drwxr-xr-x 5 michael michael 4096 Jun 4 11:04 postgresql
-rw-r--r-- 1 michael michael 33358 Jun 4 11:04 postgresql-8.10.5.tgz
There was a problem hiding this comment.
right, I wanted to keep this helm free for downloading stuff but it's true that it's easier that way
docs/user/offline-installation.md
Outdated
| tag: 1.17.10-debian-10-r10 | ||
| ``` | ||
|
|
||
| For this guide I am using [Kubernetes in Docker (`kind`)](https://github.com/kubernetes-sigs/kind) so depending on your cluster provider, this process will change. In this case, it's enough to pull the image and load it with `kind`: |
There was a problem hiding this comment.
Might be worth being clear that kind load is just ensuring the image is already available on the (single) k8s node. If you did this with another cluster, you'd need to ensure it was present on all nodes, I think? I haven't looked for docs for AWS/GKE for how to do that, but it'd be worth checking to include links here and being sure it's straight forward before we recommend this option.
There was a problem hiding this comment.
well, there are many options, from loading the images in the node to use a private registry as you say. I didn't want to cover all the use cases but I will make it clear that we are using a single node cluster.
| kind load docker-image bitnami/nginx:1.17.10-debian-10-r10 | ||
| ``` | ||
|
|
||
| You will need to follow a similar process for every image present in the values file. |
There was a problem hiding this comment.
I'm not sure of the worth of recommending this method, given that it'll break if k8s has to relocate a pod to another (new) node. Wouldn't it be fair to assume that users in such an env would have access to an internal docker registry? (artifactory, harbor, whatever), in which case they should be pushing the images there and updating the registry/repository values?
Ah - or perhaps the cluster has no egress during installation / setup but does later? It might be worth noting this assumption (and that it'll break without it, and people would be better off using an internal registry)?
There was a problem hiding this comment.
okay, yes, adding both possibilities
Description of the change
Follow up of #1751. Documentation of how to install Kubeapps in an air-gapped environment.