Microk8s: Add direct support for Helm
There are some projects, like kubeflow or draft, then leverage helm in their solution.
Using Draft and targeting microk8s is an interesting use case.
Draft .. https://github.com/azure/draft
carmine
All 33 comments
What does this mean? You want Helm embedded in the microk8s snap?
tvansteenburgh
on 17 Jul 2018
I’m thinking something along the lines of:
microk8s.enable helm
microk8s.helm ..
May need to alias helm=microk8s.help, assuming draft uses that as part of its solution, but that can be done outside.
carmine
on 17 Jul 2018
I'd rather see helm as it's own snap and a clear way to configure helm to
use microk8s cluster
On Tue, Jul 17, 2018, 12:23 Carmine Rimi notifications@github.com wrote:
I’m thinking something along the lines of:
microk8s.enable helm
microk8s.helm ..—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/juju-solutions/microk8s/issues/70#issuecomment-405642789,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAET1fQkdFqc7qMJ-Q-sG3gWk2DGA7W4ks5uHg-HgaJpZM4VTDT1
.
marcoceppi
on 17 Jul 2018
Makes sense for the helm CLI to be a snap. The server piece, tiller, feels more natural as a component to enable in microk8s. It also feels like things within the kubernetes space on GitHub would be natural part of the enable motion. We do this for DNS and dashboard already.
carmine
on 17 Jul 2018
I've been able to get helm working with microk8s by setting KUBECONFIG to the snap's config. Maybe a general solution would be to have a microk8s.env command that exports KUBECONFIG so that it's set in the current shell, and then a plethora of k8s integration tools will just work?
cmars
on 30 Jul 2018
Basically, something like this:
$ microk8s.env
export KUBECONFIG=/snap/microk8s/153/client.config
$ eval $(microk8s.env)
$ helm init
Creating /home/c/.helm
Creating /home/c/.helm/repository
Creating /home/c/.helm/repository/cache
Creating /home/c/.helm/repository/local
Creating /home/c/.helm/plugins
Creating /home/c/.helm/starters
Creating /home/c/.helm/cache/archive
Creating /home/c/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /home/c/.helm.
Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.
Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation
Happy Helming!
I think it'd be cool if the helm project decided to distribute helm as a snap, but I wouldn't want to make that a prereq for helm working with microk8s...
cmars
on 30 Jul 2018
So I'm able to install the tiller with the above, however, I'm unable to install anything with helm due to storage issues. Any idea what's causing these i/o timeouts?
[tiller] 2018/07/30 20:25:44 preparing install for
[storage] 2018/07/30 20:25:44 getting release "innocent-bobcat.v1"
[storage/driver] 2018/07/30 20:26:14 get: failed to get "innocent-bobcat.v1": Get https://10.152.183.1:443/api/v1/namespaces/kube-system/configmaps/innocent-bobcat.v1: dial tcp 10.152.183.1:443: i/o timeout
[tiller] 2018/07/30 20:26:14 info: generated name innocent-bobcat is taken. Searching again.
[storage] 2018/07/30 20:26:14 getting release "ponderous-lamb.v1"
[storage/driver] 2018/07/30 20:26:44 get: failed to get "ponderous-lamb.v1": Get https://10.152.183.1:443/api/v1/namespaces/kube-system/configmaps/ponderous-lamb.v1: dial tcp 10.152.183.1:443: i/o timeout
[tiller] 2018/07/30 20:26:44 info: generated name ponderous-lamb is taken. Searching again.
[storage] 2018/07/30 20:26:44 getting release "toned-clownfish.v1"
[storage/driver] 2018/07/30 20:27:14 get: failed to get "toned-clownfish.v1": Get https://10.152.183.1:443/api/v1/namespaces/kube-system/configmaps/toned-clownfish.v1: dial tcp 10.152.183.1:443: i/o timeout
[tiller] 2018/07/30 20:27:14 info: generated name toned-clownfish is taken. Searching again.
[storage] 2018/07/30 20:27:14 getting release "goodly-sparrow.v1"
[storage/driver] 2018/07/30 20:27:44 get: failed to get "goodly-sparrow.v1": Get https://10.152.183.1:443/api/v1/namespaces/kube-system/configmaps/goodly-sparrow.v1: dial tcp 10.152.183.1:443: i/o timeout
[tiller] 2018/07/30 20:27:44 info: generated name goodly-sparrow is taken. Searching again.
[storage] 2018/07/30 20:27:44 getting release "pondering-dog.v1"
[storage/driver] 2018/07/30 20:28:14 get: failed to get "pondering-dog.v1": Get https://10.152.183.1:443/api/v1/namespaces/kube-system/configmaps/pondering-dog.v1: dial tcp 10.152.183.1:443: i/o timeout
[tiller] 2018/07/30 20:28:14 info: generated name pondering-dog is taken. Searching again.
[tiller] 2018/07/30 20:28:14 warning: No available release names found after 5 tries
[tiller] 2018/07/30 20:28:14 failed install prepare step: no available release name found
[storage] 2018/07/30 20:28:21 listing all releases with filter
[storage/driver] 2018/07/30 20:28:51 list: failed to list: Get https://10.152.183.1:443/api/v1/namespaces/kube-system/configmaps?labelSelector=OWNER%3DTILLER: dial tcp 10.152.183.1:443: i/o timeout
[storage] 2018/07/30 20:29:13 listing all releases with filter
[storage/driver] 2018/07/30 20:29:43 list: failed to list: Get https://10.152.183.1:443/api/v1/namespaces/kube-system/configmaps?labelSelector=OWNER%3DTILLER: dial tcp 10.152.183.1:443: i/o timeout
[tiller] 2018/07/30 20:31:30 preparing install for
[storage] 2018/07/30 20:31:30 getting release "jaundiced-seal.v1"
[storage/driver] 2018/07/30 20:32:00 get: failed to get "jaundiced-seal.v1": Get https://10.152.183.1:443/api/v1/namespaces/kube-system/configmaps/jaundiced-seal.v1: dial tcp 10.152.183.1:443: i/o timeout
[tiller] 2018/07/30 20:32:00 info: generated name jaundiced-seal is taken. Searching again.
[storage] 2018/07/30 20:32:00 getting release "looping-orangutan.v1"
[storage/driver] 2018/07/30 20:32:30 get: failed to get "looping-orangutan.v1": Get https://10.152.183.1:443/api/v1/namespaces/kube-system/configmaps/looping-orangutan.v1: dial tcp 10.152.183.1:443: i/o timeout
[tiller] 2018/07/30 20:32:30 info: generated name looping-orangutan is taken. Searching again.
[storage] 2018/07/30 20:32:30 getting release "cranky-serval.v1"
[storage/driver] 2018/07/30 20:33:00 get: failed to get "cranky-serval.v1": Get https://10.152.183.1:443/api/v1/namespaces/kube-system/configmaps/cranky-serval.v1: dial tcp 10.152.183.1:443: i/o timeout
[tiller] 2018/07/30 20:33:00 info: generated name cranky-serval is taken. Searching again.
[storage] 2018/07/30 20:33:00 getting release "vigilant-ferrit.v1"
[storage/driver] 2018/07/30 20:33:30 get: failed to get "vigilant-ferrit.v1": Get https://10.152.183.1:443/api/v1/namespaces/kube-system/configmaps/vigilant-ferrit.v1: dial tcp 10.152.183.1:443: i/o timeout
[tiller] 2018/07/30 20:33:30 info: generated name vigilant-ferrit is taken. Searching again.
[storage] 2018/07/30 20:33:30 getting release "voting-scorpion.v1"
[storage/driver] 2018/07/30 20:34:00 get: failed to get "voting-scorpion.v1": Get https://10.152.183.1:443/api/v1/namespaces/kube-system/configmaps/voting-scorpion.v1: dial tcp 10.152.183.1:443: i/o timeout
[tiller] 2018/07/30 20:34:00 info: generated name voting-scorpion is taken. Searching again.
[tiller] 2018/07/30 20:34:00 warning: No available release names found after 5 tries
[tiller] 2018/07/30 20:34:00 failed install prepare step: no available release name found
@cmars how did you get these error messages? I was able to deploy mysql without any issues after microk8s.enable storage:
> helm install stable/mysql
NAME: dapper-sloth
LAST DEPLOYED: Tue Jul 31 11:18:12 2018
NAMESPACE: default
STATUS: DEPLOYED
RESOURCES:
==> v1beta1/Deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
dapper-sloth-mysql 1 1 1 0 0s
==> v1/Secret
NAME TYPE DATA AGE
dapper-sloth-mysql Opaque 2 0s
==> v1/ConfigMap
NAME DATA AGE
dapper-sloth-mysql-test 1 0s
==> v1/PersistentVolumeClaim
NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE
dapper-sloth-mysql Bound pvc-443393ba-949a-11e8-bbdf-f8cab834928e 8Gi RWO microk8s-hostpath 0s
==> v1/Service
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
dapper-sloth-mysql 10.152.183.99 <none> 3306/TCP 0s
NOTES:
MySQL can be accessed via port 3306 on the following DNS name from within your cluster:
dapper-sloth-mysql.default.svc.cluster.local
To get your root password run:
MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace default dapper-sloth-mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo)
To connect to your database:
1. Run an Ubuntu pod that you can use as a client:
kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il
2. Install the mysql client:
$ apt-get update && apt-get install mysql-client -y
3. Connect using the mysql cli, then provide your password:
$ mysql -h dapper-sloth-mysql -p
To connect to your database directly from outside the K8s cluster:
MYSQL_HOST=127.0.0.1
MYSQL_PORT=3306
# Execute the following commands to route the connection:
export POD_NAME=$(kubectl get pods --namespace default -l "app=dapper-sloth-mysql" -o jsonpath="{.items[0].metadata.name}")
kubectl port-forward $POD_NAME 3306:3306
mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD}
ktsakalozos
on 31 Jul 2018
Regarding the microk8s.env suggestion, we already provide instructions on either having microk8s provide a kubectl alias with the config already setup or accessing the config data for use with an external kubectl (either via the standard microk8s.kubectl config view --raw or via the microk8s.config helper). I'm not sure if exposing the file in the snap directory directly is a good idea, as it seems like an internal implementation detail.
johnsca
on 31 Jul 2018
@ktsakalozos Good to know it is possible to get helm working with microk8s! I think I'm having more general problems with the microk8s storage feature. Anything I should try to get it working?
c@ccube:~$ sudo snap install microk8s --edge --classic
microk8s (edge) v1.11.1 from 'canonical' installed
...
c@ccube:~microk8s.kubectl get pods --namespace kube-system
NAME READY STATUS RESTARTS AGE
hostpath-provisioner-9979c7f64-vvcht 0/1 CrashLoopBackOff 6 9m
tiller-deploy-597c48f967-b2n5r 1/1 Running 0 9m
c@ccube:~$ microk8s.kubectl logs --namespace kube-system hostpath-provisioner-9979c7f64-vvcht
F0731 14:58:41.366029 1 hostpath-provisioner.go:162] Error getting server version: Get https://10.152.183.1:443/version: dial tcp 10.152.183.1:443: i/o timeout
c@ccube:~$ microk8s.kubectl get events -w --namespace kube-system |grep hostpath
11m 11m 2 hostpath-provisioner-9979c7f64-vvcht.15467b89866c0115 Pod Warning FailedScheduling default-scheduler no nodes available to schedule pods
11m 11m 1 hostpath-provisioner-9979c7f64-vvcht.15467b8a315cf346 Pod Normal Scheduled default-scheduler Successfully assigned kube-system/hostpath-provisioner-9979c7f64-vvcht to ccube
1m 11m 46 hostpath-provisioner-9979c7f64-vvcht.15467b8a441968a2 Pod Warning MissingClusterDNS kubelet, ccube pod: "hostpath-provisioner-9979c7f64-vvcht_kube-system(e4352833-94d0-11e8-b6f4-d05099c0bc55)". kubelet does not have ClusterDNS IP configured and cannot create Pod using "ClusterFirst" policy. Falling back to "Default" policy.
9m 11m 3 hostpath-provisioner-9979c7f64-vvcht.15467b8acabc7175 Pod spec.containers{hostpath-provisioner} Normal Pulling kubelet, ccube pulling image "cdkbot/hostpath-provisioner:latest"
9m 11m 3 hostpath-provisioner-9979c7f64-vvcht.15467b8bb52e8052 Pod spec.containers{hostpath-provisioner} Normal Pulled kubelet, ccube Successfully pulled image "cdkbot/hostpath-provisioner:latest"
9m 11m 3 hostpath-provisioner-9979c7f64-vvcht.15467b8bc021eb79 Pod spec.containers{hostpath-provisioner} Normal Created kubelet, ccube Created container
9m 11m 3 hostpath-provisioner-9979c7f64-vvcht.15467b8bcb755658 Pod spec.containers{hostpath-provisioner} Normal Started kubelet, ccube Started container
9m 10m 2 hostpath-provisioner-9979c7f64-vvcht.15467b9a7a707178 Pod spec.containers{hostpath-provisioner} Warning BackOff kubelet, ccube Back-off restarting failed container
11m 11m 1 hostpath-provisioner-9979c7f64.15467b8986697cac ReplicaSet Normal SuccessfulCreate replicaset-controller Created pod: hostpath-provisioner-9979c7f64-vvcht
11m 11m 1 hostpath-provisioner.15467b8979acbccc Deployment Normal ScalingReplicaSet deployment-controller Scaled up replica set hostpath-provisioner-9979c7f64 to 1
Turns out there is a snap for helm, it's a little buried in the install instructions, but they mention it: https://docs.helm.sh/using_helm/#from-snap-linux
And it works, but there's a little trickery involved in getting it to use the microk8s kubeconfig:
c@ccube:~$ sudo snap install helm
helm 2.9.1 from 'snapcrafters' installed
c@ccube:~$ /snap/bin/helm init
Please copy Kubernetes config to /home/c/snap/helm/common/kube/config.
c@ccube:~$ cp /snap/microk8s/current/client.config /home/c/snap/helm/common/kube/config
c@ccube:~$ /snap/bin/helm init
Creating /home/c/snap/helm/common/repository
Creating /home/c/snap/helm/common/repository/cache
Creating /home/c/snap/helm/common/repository/local
Creating /home/c/snap/helm/common/plugins
Creating /home/c/snap/helm/common/starters
Creating /home/c/snap/helm/common/cache/archive
Creating /home/c/snap/helm/common/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /home/c/snap/helm/common.
Warning: Tiller is already installed in the cluster.
(Use --client-only to suppress this message, or --upgrade to upgrade Tiller to the current version.)
Happy Helming!
c@ccube:~$ /snap/bin/helm version
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
I needed to manually install socat (xenial) to fix helm snap:
$ helm version
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
E0801 01:10:01.866225 9405 portforward.go:331] an error occurred forwarding 38419 -> 44134: error forwarding port 44134 to pod 69ec444ce3d5f15bbff8de9d73319c06b69cc1278e107308c9f988405ffdb245, uid : unable to do port forwarding: socat not found.
Error: cannot connect to Tiller
So, slight update to the get-it-working instructions:
$ snap install microk8s --edge --classic
$ snap install helm
$ sudo apt install socat
...
$ microk8s.enable
$ helm init
Please copy Kubernetes config to /home/ubuntu/snap/helm/common/kube/config.
$ microk8s.kubectl config view --raw > ~/snap/helm/common/kube/config
$ helm init
...
$ helm version
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
cprov
on 1 Aug 2018
@cmars could you share the logs of the hostpath-provisioner (microk8s.kubectl logs <the pod> and microk8s.kubectl describe <the pod>)? Also, how much free disk space do you have on the host?
ktsakalozos
on 1 Aug 2018
@cprov do you think the socat missing deserves an issue here: https://github.com/snapcrafters/helm ?
ktsakalozos
on 1 Aug 2018
@ktsakalozos good point, https://github.com/snapcrafters/helm/issues/17
cprov
on 1 Aug 2018
@ktsakalozos There's about 136G free on the host. Command output you requested:
$ microk8s.kubectl get pods --namespace kube-system
NAME READY STATUS RESTARTS AGE
hostpath-provisioner-9979c7f64-7ntjw 0/1 CrashLoopBackOff 10 14m
kube-dns-864b8bdc77-m527m 2/3 CrashLoopBackOff 9 10m
kube-registry-proxy-b9v24 1/1 Running 0 9m
kube-registry-v0-g9qhm 1/1 Running 0 9m
tiller-deploy-759cb9df9-tqxc4 1/1 Running 0 11m
$ microk8s.kubectl logs hostpath-provisioner-9979c7f64-7ntjw --namespace kube-system
F0802 22:18:58.384885 1 hostpath-provisioner.go:162] Error getting server version: Get https://10.152.183.1:443/version: dial tcp 10.152.183.1:443: i/o timeout
$ microk8s.kubectl describe po/hostpath-provisioner-9979c7f64-7ntjw --namespace kube-system
Name: hostpath-provisioner-9979c7f64-7ntjw
Namespace: kube-system
Priority: 0
PriorityClassName: <none>
Node: ccube/192.168.88.71
Start Time: Thu, 02 Aug 2018 17:05:55 -0500
Labels: k8s-app=hostpath-provisioner
pod-template-hash=553573920
Annotations: <none>
Status: Running
IP: 10.1.1.14
Controlled By: ReplicaSet/hostpath-provisioner-9979c7f64
Containers:
hostpath-provisioner:
Container ID: docker://4cfb4b5f657639244c560ab190238f5907059c9626b9ac35b9ab8d50b91b0a49
Image: cdkbot/hostpath-provisioner:latest
Image ID: docker-pullable://cdkbot/hostpath-provisioner@sha256:339f78eabc68ffb1656d584e41f121cb4d2b667565428c8dde836caf5b8a0228
Port: <none>
Host Port: <none>
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Error
Exit Code: 255
Started: Thu, 02 Aug 2018 17:18:28 -0500
Finished: Thu, 02 Aug 2018 17:18:58 -0500
Ready: False
Restart Count: 10
Environment:
NODE_NAME: (v1:spec.nodeName)
PV_DIR: /var/snap/microk8s/common/default-storage
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-cn5z8 (ro)
/var/snap/microk8s/common/default-storage from pv-volume (rw)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
pv-volume:
Type: HostPath (bare host directory volume)
Path: /var/snap/microk8s/common/default-storage
HostPathType:
default-token-cn5z8:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-cn5z8
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 14m default-scheduler Successfully assigned kube-system/hostpath-provisioner-9979c7f64-7ntjw to ccube
Normal Pulling 13m (x3 over 14m) kubelet, ccube pulling image "cdkbot/hostpath-provisioner:latest"
Normal Pulled 13m (x3 over 14m) kubelet, ccube Successfully pulled image "cdkbot/hostpath-provisioner:latest"
Normal Created 13m (x3 over 14m) kubelet, ccube Created container
Normal Started 13m (x3 over 14m) kubelet, ccube Started container
Warning BackOff 12m (x2 over 13m) kubelet, ccube Back-off restarting failed container
Warning MissingClusterDNS 12m (x11 over 14m) kubelet, ccube pod: "hostpath-provisioner-9979c7f64-7ntjw_kube-system(3ac26712-96a0-11e8-8a19-d05099c0bc55)". kubelet does not have ClusterDNS IP
configured and cannot create Pod using "ClusterFirst" policy. Falling back to "Default" policy.
Normal Pulled 7m (x4 over 10m) kubelet, ccube Successfully pulled image "cdkbot/hostpath-provisioner:latest"
Normal Created 7m (x4 over 10m) kubelet, ccube Created container
Normal Started 7m (x4 over 10m) kubelet, ccube Started container
Normal Pulling 5m (x5 over 10m) kubelet, ccube pulling image "cdkbot/hostpath-provisioner:latest"
Warning BackOff 36s (x33 over 10m) kubelet, ccube Back-off restarting failed container
@cmars I see that there is a problem accessing the kubernetes service. This is probably also why your dns service is crashlooping.
The most probable reason is that the machine you have microk8s installed on (I assume a laptop?) changed its IP (eg from a reboot/switch to another network). The kubernetes apiserver listens on the default interface of the host machine so if the machine changes IP the api server needs to be restarted. Can you please try a:
sudo snap disable microk8s
sudo snap enable microk8s
This has been recently documented in the project's README. We are open to any suggestion on how to handle this in a better way.
ktsakalozos
on 6 Aug 2018
Thanks @ktsakalozos. The snap disable/enable seems to get the hostpath provisioner and dns services running again, but they keep crashlooping and I'm still unable to install a chart.
This is on a server machine that has a lot of network interfaces and addresses on virtual network bridges (docker0, virbr0, etc.). Perhaps the choice of default network is wrong, and it will be necessary to specify a network address for microk8s to bind/connect to?
cmars
on 6 Aug 2018
The pods are using the cbr0 interface and they should be able to reach the host's default interface where the kube-apiserver is listening. Could you check that the pods can reach the apiserver by
microk8s.kubectl exec -it <any_pod> -- /bin/sh and then try to reach the port 8080 on the IP where the apiserver is? I would expect this to fail.
You could use the --bind-address and --advertise-address arguments on the apiserver to have it use another interface (https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/). To do so you will need to edit the /var/snap/microk8s/current/args/kube-apiserver file and then restart the service with sudo systemctl restart snap.microk8s.daemon-apiserver.
ktsakalozos
on 6 Aug 2018
@ktsakalozos Thanks & yes I think the bind address is the issue here. The concern I have is that microk8s will probably work well on hosts with a single network interface (it works great on a multipass VM), but may result in odd breakage & a poor user experience when the host has multiple NICs. Perhaps a microk8s.setup subcommand could prompt the user, in a similar fashion to lxd init?
cmars
on 16 Aug 2018
This is getting way off topic from the original issue though.. helm works fine for me w/microk8s when there's a single ethernet adapter, such as in a VM. Should I open a new issue to track the issue w/multiple NICs?
cmars
on 16 Aug 2018
I am a big +1 for the microk8s.setup/init. There are a few setup steps that need the user's input (accept forward traffic and enable dns/storage/dashboard to name a few). Yes, please open a new issue to work on multiple NICs. Thanks
ktsakalozos
on 16 Aug 2018
It seems that the original issue of Helm integration with MicroK8s has been (partly) solved?
In the documentation I see the command microk8s.enable helm (https://microk8s.io/docs/)
local server connection
I have an issue with connecting to the local server, however.
$ microk8s.enable helm
$ microk8s.helm init
Creating /home/*user*/.helm
Creating /home/*user*/.helm/repository
Creating /home/*user*/.helm/repository/cache
Creating /home/*user*/.helm/repository/local
Creating /home/*user*/.helm/plugins
Creating /home/*user*/.helm/starters
Creating /home/*user*/.helm/cache/archive
Creating /home/*user*/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /home/*user*/.helm.
Error: error installing: the server could not find the requested resource
Also, when I try to install an Airflow chart (https://github.com/tekn0ir/airflow-chart):
microk8s.helm dependency update
Hang tight while we grab the latest from your chart repositories...
...Unable to get an update from the "local" chart repository (http://127.0.0.1:8879/charts):
Get http://127.0.0.1:8879/charts/index.yaml: dial tcp 127.0.0.1:8879: connect: connection refused
...Successfully got an update from the "stable" chart repository
Update Complete.
Saving 1 charts
Downloading postgresql from repo https://kubernetes-charts.storage.googleapis.com/
Deleting outdated charts
$ microk8s.helm install --name my-airflow -f values.yaml .
Error: could not find tiller
system
- Ubuntu 18.04
- microk8s v1.16.0 920 1.16/candidate canonical✓ classic
NumesSanguis
on 3 Oct 2019
@NumesSanguis let me replay here what we discussed over at the #microk8s slack channel.
At the time of this writing helm has not released a version that works with v1.16 [1]. As soon as a release comes out we will have to update the addon script [2] to pick it up.
While we wait you have two options:
- use MicroK8s v1.15 with
sudo snap install microk8s --classic --channel=1.15/stable - go through the issue [3] and try any workarounds described there.
Apologies for any inconvenience.
[1] https://github.com/helm/helm/releases
[2] https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/actions/enable.helm.sh#L13
[3] https://github.com/helm/helm/issues/6374
ktsakalozos
on 3 Oct 2019
Just in case it helps:
I have been using helm v3.0.0-beta.3 (which doesnt use tiller) with microk8s v1.16.0 (920) and it seems to work fine.
jareks
on 3 Oct 2019
Just in case it helps:
I have been using helm v3.0.0-beta.3 (which doesnt use tiller) with microk8s v1.16.0 (920) and it seems to work fine.
What steps did you take to use Helm v3?
NumesSanguis
on 3 Oct 2019
To make this easier for anyone stuck like I was, this following command worked:
microk8s.helm init --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | microk8s.kubectl apply -f -
andrewfinnell
on 4 Oct 2019
To make this easier for anyone stuck like I was, this following command worked:
microk8s.helm init --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | microk8s.kubectl apply -f -
Thank you! That finally worked for me. I would appreciate if you could explain the parameters you used in brief.
chrishoerl
on 14 Oct 2019
Just in case it helps:
I have been using helm v3.0.0-beta.3 (which doesnt use tiller) with microk8s v1.16.0 (920) and it seems to work fine.
I'm also currious how to use helm v3 with microk8s
may u share the steps ?
thx
r8code
on 16 Oct 2019
@r8code
I think all I did was to download Linux amd64 binary from: https://github.com/helm/helm/releases/tag/v3.0.0-beta.4
In any case, there's plenty of documentation there too.
jareks
on 16 Oct 2019
hello.
I can't enable helm because of proxy.
How to set http proxy for microk8s?
$ sudo http_proxy=proxyip:port https_proxy=proxyip:port microk8s.enable helm
Enabling Helm
Fetching helm version v2.16.0.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:02:10 --:--:-- 0curl: (7) Failed to connect to get.helm.sh port 443: timed out
Failed to enable helm
Hokwang
on 10 Dec 2019
microk8s.enable helm and microk8s.enable helm3 (in master branch) are now available as addons.
balchua
on 14 Jan 2020
Related issues
termie
·
5Comments
toxsick
·
4Comments
NumesSanguis
·
3Comments
mthaddon
·
5Comments
edsiper
·
5Comments
Most helpful comment
Basically, something like this: