Using microk8s 1.18 on Ububtu 20.04
microk8s 1.18 is bundled with istio 1.3.4 (released on 2019-11-01). istio 1.5.4 has been released on 2020-05-12.
What is the recommended approach to update the add-ons bundled with microk8s?
We just upgraded istio to 1.5.1. This upgrade should be on the edge channel (sudo snap install microk8s --classic --channel=edge).
To request an upgrade of an addon you can file an issue at [1] and we will try to make some time and work on it. Even better, you can become a contributor and submit a patch to upgrade the addon you desire (see for example [2]).
Alternatively, you can skip the addons mechanism and deploy the workload you desire manually.
[1] https://github.com/ubuntu/microk8s/issues
[2] https://github.com/ubuntu/microk8s/pull/1137
I am not too familiar with the microk8s code base to submit pull request. Just curious, do you have a document showing how to prepare the dev environment to work on the build & test of microk8s?
Back to the addon update. Let’s say, by emergency I must update the addon directly (and manually) outside of microk8s control. When microk8s is updated, how would microk8s handle that addon which had been modified?
For building MicroK8s have a look at [1].
If an addon does not match your needs you can ignore it and install the same workload (istio in this case) the way it is described in the upstream documentation. I guess this is what you mean by manually. MicroK8s will not be aware of that so it will not alter your workload in any way.
[1] https://github.com/ubuntu/microk8s/blob/master/docs/build.md
Not working: istio still remains at old version 1.34
$ sudo snap refresh microk8s --classic --channel=edge
$ sudo snap info microk8s
snap-id: EaXqgt1lyCaxKaQCU349mlodBkDCXRcg
tracking: 1.18/edge
refresh-date: today at 21:32 EDT
channels:
1.18/stable: v1.18.2 2020-04-27 (1379) 201MB classic
1.18/candidate: v1.18.3 2020-05-25 (1422) 201MB classic
1.18/beta: v1.18.3 2020-05-25 (1422) 201MB classic
1.18/edge: v1.18.3 2020-05-25 (1438) 201MB classic
installed: v1.18.3 (1438) 201MB classic
But istio addon, instead of v1.51, is still at the older version 1.34 which was bundled with microk8s 1.18.2
$ microk8s.istioctl version
client version: 1.3.4
control plane version: 1.3.4
We do not upgrade running workloads when upgrading MicroK8s. This means that if you have a workload setup in Istio 1.3.4 and a new addon version comes out the workload you have will continue operating under 1.3.4. To get the new addon version you will need to explicitly microk8s disable istio and then microk8s enable istio.
Please make sure you get microk8s from latest/stable:
sudo snap install microk8s --classic --channel=latest/edge
latest is important, because I see you are following the 1.18 track.
Hi @kjackal
Thanks very much for educating me. Now tracking latest/edge. Not sure what are the “risk” of using edge channel, but I am willing to play around.
We do not upgrade running workloads when upgrading MicroK8s. This means that if you have a workload setup in Istio 1.3.4 and a new addon version comes out the workload you have will continue operating under 1.3.4. To get the new addon version you will need to explicitly
microk8s disable istioand thenmicrok8s enable istio
This is a very important information. Maybe the microk8s documentation should add in the Install section a subitem “Upgrading add-ons” ?
Following your advice, I disable + enable the addons to have them upgraded with their latest version bundled in microk8s " v1.18.3 (1443) 211MB classic" latest/edge I just refreshed. The corresponding output show that there is a lots of object deleted. Does that mean whatever workloads I have deployed & configured using any of the addons being disabled are also deleted and need to be redeployed again?
$ microk8s disable dashboard dns istio registry storage
Disabling dashboard
serviceaccount "kubernetes-dashboard" deleted
service "kubernetes-dashboard" deleted
secret "kubernetes-dashboard-certs" deleted
secret "kubernetes-dashboard-csrf" deleted
secret "kubernetes-dashboard-key-holder" deleted
configmap "kubernetes-dashboard-settings" deleted
role.rbac.authorization.k8s.io "kubernetes-dashboard" deleted
clusterrole.rbac.authorization.k8s.io "kubernetes-dashboard" deleted
rolebinding.rbac.authorization.k8s.io "kubernetes-dashboard" deleted
clusterrolebinding.rbac.authorization.k8s.io "kubernetes-dashboard" deleted
deployment.apps "kubernetes-dashboard" deleted
service "dashboard-metrics-scraper" deleted
deployment.apps "dashboard-metrics-scraper" deleted
service "monitoring-grafana" deleted
service "monitoring-influxdb" deleted
service "heapster" deleted
deployment.apps "monitoring-influxdb-grafana-v4" deleted
serviceaccount "heapster" deleted
clusterrolebinding.rbac.authorization.k8s.io "heapster" deleted
configmap "heapster-config" deleted
configmap "eventer-config" deleted
deployment.apps "heapster-v1.5.2" deleted
dashboard disabled
Disabling DNS
Reconfiguring kubelet
Removing DNS manifest
serviceaccount "coredns" deleted
configmap "coredns" deleted
deployment.apps "coredns" deleted
service "kube-dns" deleted
clusterrole.rbac.authorization.k8s.io "coredns" deleted
clusterrolebinding.rbac.authorization.k8s.io "coredns" deleted
[sudo] password for userx:
DNS is disabled
Disabling Istio
namespace "istio-system" deleted
Istio is terminating
Disabling the private registry
namespace "container-registry" deleted
persistentvolumeclaim "registry-claim" deleted
deployment.apps "registry" deleted
service "registry" deleted
The registry is disabled. Use 'microk8s disable storage:destroy-storage' to free the storage space.
Disabling default storage
deployment.apps "hostpath-provisioner" deleted
storageclass.storage.k8s.io "microk8s-hostpath" deleted
serviceaccount "microk8s-hostpath" deleted
clusterrole.rbac.authorization.k8s.io "microk8s-hostpath" deleted
clusterrolebinding.rbac.authorization.k8s.io "microk8s-hostpath" deleted
Storage removed
Remove PVC storage at /var/snap/microk8s/common/default-storage ? (Y/N): Y
Storage space reclaimed
You can find the description of channels and tracks in [1]. I am grateful to anyone using the latest/edge channel as early feedback on our work is really valuable.
Any workloads unrelated to the addons you disable will be kept untouched. However note that if a workload uses an addon then it may be affected. Think for example a workload that uses storage resources from the storage addon. It is not possible for me to know if/how a workload is affected. You will have to check this in a case-by-case fashion.