I was looking for a solution to run several Kubernetes Clusters in our private cloud. I was first going for OpenStack but soon recognized that this was not what I wanted. Then I found OpenNeubla and that there is even a ready to run Kubernetes Appliance on board. Guess how happy I was!?
Meanwhile I have a cluster running and I’m testing a lot. I like the concept of OpenNebula very much. I have a few questions concerning the Kubernetes Appliance:
How will the versioning been done in general? Is the appliance version independent from the OpenNebula Version? Can we expect new versions of the appliance when there are major or important updates e.g. for docker, k8s, etc…?
How are severe CVE issues solved? Will there be updates available?
The appliance runs on a Centos7 image. Is it save to perform regular updates on this VM without the risk of corrupting the k8s appliance?
Are there chances that the k8s appliance will disappear again from the marketplace?
I’ll answer few questions and @osp will answer the rest.
Marketplace appliance consist of service version, one-context version, build iteration and build date. E.g.: 1.13.4-5.8.0-3.20190315 refers to Kubernetes 1.13.4 and one-context packages 5.8.0. Version is independent to the OpenNebula.
Yes, we’ll be refreshing the appliances soon with new versions.
Has it disappeared already (I’m not aware of that)? Anyway, there are no plans to remove this from the Marketplace, but to get feedback from the users and improve.
Licence is as the rest of OpenNebula / contextualization scripts, Apache. Scripts in new build will have the licence in the header.
Source code is not publicly on GitHub, users can find it only deployed in the appliances. To report any bugs / request features, you can open issue in one or marketplace (https://github.com/OpenNebula/marketplace) repositories.
@vholer already answered many of your questions I will then answer the rest. Because those points 2 and 3 are related I will answer them together (below the TL;DR section).
TL;DR
CVE is always danger, but sometimes the fix can be postponed - updated appliance will be soon.
It is not so easy as yum/dnf update - yes, it can break your deployment.
If you provide kubernetes environment to the third party (clients) and have no real saying what it is running inside then some CVE can be potentially danger - user can escalate privileges etc.
If you are referencing to this: https://kubernetes.io/blog/2019/02/11/runc-and-cve-2019-5736/ then there is also some guidance how to fix it. This is a severe and it will be fixed with the new release of appliance - soon - or you can fix it by yourself with some know-how.
We did not attempted to fix it at the time of release because the latest kubernetes version (at that time) did not support officially the fixed version of docker - we have chosen the path of a working and supported release from kubernetes.io. There is a new kubernetes version and this CVE should be fixed already.
For the upgrades - I believe that once you instantiate the VM it is your responsibility to manage it. So you should do upgrades of the underlying operating system. It is true that simple yum/dnf update could break things. Kubernetes is one of those project where updating can be painful and can break everything.
But if you disable kubernetes and docker repo then yum/dnf update should be safe - the point is to not touch docker.
We have been waiting for some feedback from the users so we did not have some set schedule to release updated appliances as of yet. But new updated kubernetes appliance is on the way.
Although, new updated appliance would not save you if you already have something deployed - you would have to redeploy you environment anyway.
So if you wish to have your VM up-to-date then you must learn how to do it (with kubernetes) or redeploy with new release of our appliance. There is a third option - to use some other kubernetes implementation like rancher’s rke which is designed to do seamless upgrades (they claim that - we did not test it) - but it is completely different project which reimplements kubernetes API. We could add it if there would be a demand.
I hope that I answered your question in satisfying way - the new updated kubernetes release will come in a matter of a week or two.
If you have other questions - keep asking. And sorry for the delay in our reply
This does not affect the functionality of the appliance whatsoever but it is certainly misleading - appliance will be updated again due to this, but it should not be a showstopper for using the current release.
