One of the most interesting details that I found when using K3s (https://k3s.io/) is the way to deploy Traefik, in which it uses a Helm chart (note: in Kubernetes the command to execute is sudo kubectl, but in k3s is sudo k3s kubectl because it is integrated to use minimal resources). We found that helm is not installed, but we can see a job running the helm client so that we can have its power without the need to have tiller running (the helm server) that uses resources that we can save, but how does it work? Klipper Helm The first detail we can see is the use of a job (a task that is usually executed only once as a container) based on the image “rancher/klipper-helm” (https://github.com/rancher/klipper-helm) running a helm environment by simply downloading it and running a single script: https://raw.githubusercontent.com/rancher/klipper-helm/master/entry As a requirement you are going to require a system account with administrator permissions in the kube-system namespace, for “traefik” it is: What we must take into account is the need to create the service account and at the end of the installation task with helm remove it since it will not be necessary until another removal or update helm operation. As an example we will create a task to install a weave-scope service using the helm chart (https://github.com/helm/charts/tree/master/stable/weave-scope) Service Creation We create a workspace to isolate the new service (namespace in kubernetes, project in Openshift) that we will call helm-weave-scope: We create a new system account and assign the administrator permissions: Our next step is to create the task, for this we create it in the task.yml file: Execution And we execute it with: What will launch all the processes that the chart has: Result We can observe the correct installation of the application without the need to install Helm or tiller running on the system: Update With the arrival of Helm v3, Tiller is not necessary and now is much simpler to use. To explain its operation, see Helm v3 to deploy PowerDNS over Kubernetes.
Oracle “copy” oVirt platform and endorses it: https://blogs.oracle.com/virtualization/announcing-oracle-linux-virtualization-manager Does this mean that Oracle VM is ended as we know it and there is a new fully manageable platform?