Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kubic - openSUSEs Container Starship

Richard Brown
February 21, 2018

Kubic - openSUSEs Container Starship

Containers, Containers, Containers - The world seems to be going container crazy. openSUSE has a strong heritage with containers, being one of the first distributions to support lxc, but as time has moved on it's become more apparent that traditional, general purpose, operating systems provide as many problems for running containers as they solve.

Container admins need an operating system platform that can provide their container runtime (Docker, Cri-O, etc) and their container orchestration tooling (Kubernetes, etc), and then generally get out of their way, so they can focus on the containers and their contents.

Requirements include absolutely fully automatic updates,while updating far more often than a traditional enterprise distribution (to get the latest from this fast moving ecosystem), all the while never breaking, or at least automatically rolling back to a working state if it does.

Impossible? Some say so, CoreOS and Red Hat have taken the route of re-inventing wheels with their Container Linux & Red Hat Atomic systems.

openSUSE takes a different route. This talk introduces Kubic, details how it is the perfect operating system for running container workloads, explore how it leverages our existing expertise in rolling releases, btrfs, snapshots, and rollbacks, and explains how it forms the base of SUSE's commercial Container as a Service Platform.

Richard Brown

February 21, 2018

More Decks by Richard Brown

Other Decks in Programming


  1. Topics • What is the Kubic Project? • The Problem

    with Traditional Distributions • Transactional Updates In Detail • MicroOS – *SUSE enters the Atomic-Era • Cool Things you can do with MicroOS Today • Just the Beginning – Kubic as a Container Service Platform
  2. Kubic Project • Founded in May 2017 • Sub-Project of

    the openSUSE Project • Focused on Container Technologies incl: – MicroOS, Tumbleweed-based Cluster Host OS – Velum, Kubernetes Cluster Bootstrapper & MicroOS Cluster Dashboard • Upstream of SUSE Container as a Service Platform (CaaSP)
  3. Why? • Micro-Services are fun – Why bother with complex

    installations when someone else's solution is a docker pull away? – VMs are comparably resource and management heavy – Lots of positive momentum behind containers, but tools are lacking
  4. Why? • Containers are disruptive – Diferent requirements from the

    OS – Faster delivery expectations – Portability increases support demands – Containerized clusters want to run at scale
  5. Why? • Setting up a container host should be easy

    – No point saving time with containers just to waste it administering a machine – Containers should take care of themselves, why can’t the host system?
  6. Upgrading a Running System Is DANGEROUS • Services are running

    • Users are doing things • Sofware changes things (sometimes on purpose!) • Not all packages are packaged properly (sorry)
  7. Reality does not make things easy Rolling Releases bring larger

    challenges • Intrusive Updates (SysV init → systemd) • Major version updates of complex stacks (GNOME, KDE) • What should I do if the update breaks my system?
  8. Reality does not make things easy Critical Mission Systems are

    even worse • Update should not interrupt services Service interruption more expensive than regular reboots • Updates need to be fully applied perfectly, or no changes made System state should never be undefined/questionable RPM post-installation scripting can lead to an undefined state
  9. What is a Transactional Update? An Update that: • Is

    Atomic – Either fully applied, or not at all – Update does not influence the running system • Can be rolled back – A failed or incompatible update can be quickly discarded to restore the previous system conditions
  10. Other Solutions • Several Diferent Partitions – Waste of Disk

    Space • Special package formats (rpm-ostree, snap, etc) – Need to learn something new – Can’t re-use existing packages → And you need to redesign systems, tools & company policies
  11. All you need • btrfs root filesystem with snapshots/rollback enabled

    • snapper • zypper (or package manager of your choice) • btrfsprogs
  12. Transactional Updates ro ro ro ro curr. root rw 1

    ro-Clone 2 Change rw 3 zypper up
  13. Transactional Updates ro ro ro ro curr. root ro 1

    ro-Clone 2 Change rw 3 zypper up Change ro 4
  14. Transactional Updates ro ro ro ro curr. root New root

    1 ro-Clone 2 Change rw 3 zypper up Change ro 5 “Rollforward” btrfs subvol set-default 4
  15. How to do transactional updates • transactional-update [up|dup|patch] • transactional-update

    pkg [install|remove|update] $PKG1..$PKGN – Install anything you’d like • BONUS: transactional-update shell
  16. Transactional Updates – Rollback ro ro ro ro curr. root

    New root 1 Rollback btrfs subvol set-default
  17. Advantages • btrfs: – Snapshots with CoW are space eficient

    – Deduplication possible – btrfs send/receive – update with golden images • rpm: – Existing packages can be used – No need to learn new tools, policies remain valid
  18. Disadvantages • Currently limited to btrfs only • Special requirements

    of RPMs – Care needs to be made that files are in the right place – User data & configuration should be converted on use, not during package install • Reboot needed to activate changes
  19. Dealing with Configuration Files • rootfs snapshots always contain package-provided

    files for /etc • overlayfs used to transparently store/overlay user-provided files for /etc
  20. openSUSE MicroOS • openSUSE Tumbleweed-derivative utilising transactional- updates & read-only

    rootfs • Docker installed and enabled by default (for now) • Download/Install from https://sofware.opensuse.org/distributions/tumbleweed
  21. MicroOS Example Use Cases • Rolling Server – Use the

    latest of everything with no risk – Web (esp. NodeJS, Ruby, etc) – Virtualisation host – Media Server
  22. Why? • Setting up a container host should be easy

    – No point saving time with containers just to waste it administering a machine – Containers should take care of themselves, why can’t the host system?
  23. What’s Next? • Setting up a container cluster should be

    easy – No point saving time with containers just to waste it administering a cluster of machines – Containers should take care of themselves, why can’t the cluster? – Cluster admins should be able to seemlessly bootstrap, monitor and upgrade whole clusters at once
  24. Current Status • “Unconfigured Cluster Node” - fully supported system-role

    in Kubic • Can be used to setup a Kubernetes Cluster Manually • https://kubernetes.io/docs/getting-started-guides/scratch/ #bootstrapping-the-cluster
  25. Current Status • Velum & related “Container-as-a-Service Platform” containers are

    not working yet • Contributions welcome • https://github.com/kubic-project/container-images • Alternatives being investigated – OpenShif – kubeadm
  26. License This slide deck is licensed under the Creative Commons

    Attribution-ShareAlike 4.0 International license. It can be shared and adapted for any purpose (even commercially) as long as Attribution is given and any derivative work is distributed under the same license. Details can be found at https://creativecommons.org/licenses/by-sa/4.0/ General Disclaimer This document is not to be construed as a promise by any participating organisation to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. openSUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for openSUSE products remains at the sole discretion of openSUSE. Further, openSUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All openSUSE marks referenced in this presentation are trademarks or registered trademarks of SUSE LLC, in the United States and other countries. All third-party trademarks are the property of their respective owners. Credits Template Richard Brown [email protected] Design & Inspiration openSUSE Design Team http://opensuse.github.io/branding- guidelines/