Hi all
We are now building, testing, and shipping separate MicroOS
installation media in addition to the long established Kubic Media
You can download it today from
https://download.opensuse.org/tumbleweed/iso/openSUSE-MicroOS-DVD-x86_64-Cu…
Below are some FAQ's to explain why we're doing this, which will
likely be a part of a future MicroOS website/blogpost/marketing.
Meanwhile please download, play around, and let us know what you think!
Feel free to question/add/comment/correct any of the FAQs also.
FAQ
===
Q: What is openSUSE MicroOS?
A: MicroOS is a Tumbleweed based operating system focused on being the
perfect "single purpose" operating system.
Q: What is meant by "single purpose" Operating System?
A: Traditional Operating Systems are designed and implemented with an
assumption that they will be deployed on a system that could do
multiple tasks at once (eg. Web Server, and Mail Server). The
operating system needs to therefore be designed in a particular way
that allows the simultaneous running, maintenance, and upgrade of the
OS and all the services atop it.
This creates complex real world issues, such as ensuring multiple
systems running the same OS all act the same way after upgrades,
regardless of which services they run.
A "single purpose" OS assumes that a single installed system will only
be used for one task, with other tasks being handled by either other
means or other systems. This could be multiple VMs or physical
machines each running a "single purpose" OS, or using some kind of
containerisation framework to provide multiple services.
Q: What are the benefits of MicroOS for "single purpose" workloads?
A: MicroOS is built around the same transactional-update stack long
used in Kubic. Transactional Updates are the perfect update mechanism
for "single purpose" systems, as they guarantee that the running
system never changes, and that any changes that do occur happen in
single atomic operations that can trivially be undone. With MicroOS
Transactional Updates are automatic by default, patching the whole OS,
rebooting and able to rollback without any user interaction.
This makes it perfect for systems that need to be deployed, do one
job, and keep doing it for a long time even while the OS and service
provided are receiving updates for a long period of time.
As a Tumbleweed derivative, MicroOS benefits from having all of the
software packages available from regular Tumbleweed.
This means
Q: What system roles can be chosen when installing MicroOS?
A: There are currently two system roles in MicroOS
"MicroOS" which provides the standard MicroOS runtime environment,
with no services installed or configured.
"MicroOS Container Host" which adds the Podman so the system is ready
and configured to run containers as its "single purpose".
If you have any ideas for additional System Roles that should be
offered with MicroOS, please reply with your suggestion.
Q: What is the difference between MicroOS and Kubic?
A: Kubic is now a derivative of MicroOS and identifies itself as such
in it's /etc/os-release.
Kubic has been and will continue to be focused on Containers and
Kubernetes, whereas regular MicroOS is intended to be used for a more
diverse range of use cases.
The Kubic system role that was formerly called "openSUSE MicroOS" is
now renamed "MicroOS Container Host" and is absolutely identical to
the "MicroOS Container Host" provided by the MicroOS install media.
Q: Will there be official qcow/vmware/vagrant images?
A: Yes, absolutely. We would also expect there to be Raspberry Pi
images soon as MicroOS should be a perfect fit for many users of that
hardware
--
To unsubscribe, e-mail: opensuse-kubic+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kubic+owner(a)opensuse.org
Hi,
Recently I'm trying to deploy Cilium on Kubic and to create k8s manifest
which is using Kubic container images.
Everything is going well except one thing - I'm not sure what to do with
cilium-cni binary (a CNI plugin which needs to be visible by kubelet).
I assumed that since we use (almost) vanilla Kubernetes with kubeadm,
kubelet is going to look for plugins in /opt/cni/bin and that I can just
mount that directory, then copy the binary there from the initContainer
(or as a part of preStart step). But it seems that kubelet is lookng
only at /usr/lib/cni, which is read only and there are only CNI plugins
installed from packages.
I see two potential solutions:
1. Changing the cni-bin-dir parameter for Kubelet to
`/usr/lib/cni,/opt/cni/bin` to support both CNI plugins installed on
host and those installed dynamically.
2. Adding cilium-cni package to patterns-containers.
What do you think?
BTW, I have the manifest here:
https://github.com/kubic-project/k8s-manifests/blob/cilium/cilium.yaml
It should work if you do `transactional-update pkg install cilium-cni`
and restart nodes before.
Cheers,
Michal
--
To unsubscribe, e-mail: opensuse-kubic+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kubic+owner(a)opensuse.org
Hi,
As learning exercise for go and gRPC and to kill some time on airports
and in planes I started to implement a client/server tool using gRPC
in go. While the original idea was to replace a dbus implementation,
I had to find out that gRPC was not suiteable for that case so I used
it to replace my scripts to setup kubernetes on openSUSE Kubic ;)
The result is with kubicd/kubicctl a client/server architecture,
using MutualTLS and certificates for authentication and encrypted
communication.
It has RBAC, so you can define which user can do what based on his
certificate.
Else you can initialize the control plane of the kubernetes master,
add nodes, remove nodes and reboot nodes. You can upgrade the kubernetes
cluster (tested from kubernetes 1.13.4 to 1.14) and download the
kubeconfig file.
Since salt is used to communicate with the nodes, there are the
following prerequires:
1. kubicd needs to run on the machine, which should become the
kubernetes master
2. salt master needs to run on the same machine
3. all nodes need to be a minion reporting to the salt master.
- on the nodes: echo "master: <hostname>" > /etc/salt/minion.d/master.conf
systemctl enable --now salt-minion
- on the master: salt-key -A to accept the minions
kubicd and kubicctl packages are part of the openSUSE Tumbleweed
repositories. So after installation of openSUSE Kubic, you can install
them with "transactional-update pkg install kubicd" on the master node.
We will add them to the openSUSE Kubic media the next days.
kubicctl can run on any machine you like, so even on your personal
workstation.
Test coverage, documentation and error handling could need quite some
improvements ;), so feel free to create pull requests and file issues.
Any kind of feedback is greatly appreciated!
I also hope that we can improve the salt usage and integrate it into
installer, so that you don't need to setup salt at your own before.
The github project can be found here:
https://github.com/thkukuk/kubic-control
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: opensuse-kubic+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kubic+owner(a)opensuse.org
Hi all,
Just sharing the good news - the CNCF has certified that Kubic 0408
and later are Certified Kubernetes Version 1.14
Thanks to all who helped make it happen
- Rich
--
To unsubscribe, e-mail: opensuse-kubic+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kubic+owner(a)opensuse.org
Hi all,
I just realised I didn't announce my intention to do this beforehand
Patterns-caasp has been removed from Factory, after being replaced by
patterns-microos and patterns-containers
This is all part of our previously discussed effort to offer MicroOS
as separate media in addition to the Kubic media
If you were using any patterns-caasp-* pattern packages, you will find
them replaced by patterns-microos-* or patterns-containers-*
I did also tidy up a bit of a naming. I removed "SUSE" from all the
pattern provides references, and replaced all the "-" hyphens from the
names with "_" underscores to make specfiles more readable.
Functionally though, the new patterns do the same as the old ones, so
everything should be 1-1 replaceable with the new patterns. The new
patterns should provide/obsolete the old patterns smoothly during
upgrades.
If you have any references to the old patterns which are now broken,
with this information you should be able to find the new equivalents
Thanks!
- Richard
--
To unsubscribe, e-mail: opensuse-kubic+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kubic+owner(a)opensuse.org
Hi,
We're starting to look at MicroOS as the base OS for our Kubernetes stacks. And as we're now using RKE to deploy k8s, we're stuck with Docker right now.
Added to this, we have other things to customize in order to ease the OS deployment (mostly targeting, but not limited to bare metal deployment)
Two questions here:
1) Can I (I assume yes) leverage kiwi to build a raw image (as our metal deployer requires raw image)? If so, I haven't found how to do it in the available docs
2) Providing that everything is automated and standardized, using cloud-init NoCloud datasource is not an option (as it's unlikely we'll be having a connected unpartitioned disk to hold the cloud-init configuration), and I haven't been able to make the LocalDisk datasource (again, I most probably just haven't the docs required to make it work).
Thanks!
Christian
--
To unsubscribe, e-mail: opensuse-kubic+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kubic+owner(a)opensuse.org
