Kubic - openSUSEs Container Starship

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.

C4d991702dcb0afa2b2afd8464be7f66?s=128

Richard Brown

February 21, 2018
Tweet

Transcript

  1. Richard Brown openSUSE Chairman rbrown@opensuse.org Kubic Project openSUSE’s Container Starship,

    going where no distribution has gone before
  2. 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
  3. 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)
  4. Why? • Application delivery is changing – Containers – Flatpak/snaps/AppImage

  5. 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
  6. Why? • Containers are disruptive – Diferent requirements from the

    OS – Faster delivery expectations – Portability increases support demands – Containerized clusters want to run at scale
  7. 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?
  8. The Problem with Traditional Distributions

  9. “I NEVER want to touch a running system” - Every

    SysAdmin, ever
  10. 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)
  11. 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?
  12. 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
  13. Traditional Snapshots – An Imperfect Solution curr. root ro ro

    ro ro
  14. Traditional Snapshots – An Imperfect Solution curr. root ro ro

    ro ro ro ro-Clone 1
  15. Traditional Snapshots – An Imperfect Solution curr. root ro ro

    ro ro ro ro-Clone 1 zypper up 2
  16. Transactional Updates

  17. 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
  18. 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
  19. All you need • btrfs root filesystem with snapshots/rollback enabled

    • snapper • zypper (or package manager of your choice) • btrfsprogs
  20. Traditional Snapshots curr. root ro ro ro ro

  21. Transactional Updates ro ro ro ro curr. root

  22. ro Transactional Updates ro ro ro ro curr. root 1

    ro-Clone
  23. Transactional Updates ro ro ro ro curr. root rw 1

    ro-Clone 2 Change rw
  24. Transactional Updates ro ro ro ro curr. root rw 1

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

    ro-Clone 2 Change rw 3 zypper up Change ro 4
  26. 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
  27. Transactional Updates – Afer Reboot ro ro ro ro curr.

    root ro
  28. Transactional Updates – without Reboot ro ro ro ro curr.

    root ro ro New root
  29. 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
  30. Transactional Updates – Rollback ro ro ro ro curr. root

    New root 1 Rollback btrfs subvol set-default
  31. 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
  32. Advantages, cont. • Normal boot time • Very quick rollback

  33. 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
  34. Dealing with Configuration Files • rootfs snapshots always contain package-provided

    files for /etc • overlayfs used to transparently store/overlay user-provided files for /etc
  35. MicroOS

  36. 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
  37. Diferences from Tumbleweed • Update using transactional-update dup • Install/Remove

    packages using transactional-update pkg install|remove
  38. MicroOS Today

  39. MicroOS Example Use Cases • Containers – docker – runc

    – lxc – cri-o
  40. MicroOS Example Use Cases

  41. MicroOS Example Use Cases • Rolling Server – Use the

    latest of everything with no risk – Web (esp. NodeJS, Ruby, etc) – Virtualisation host – Media Server
  42. MicroOS on Raspberry Pi3

  43. Kubic Desktop

  44. Kubic Desktop https://rootco.de/2017-11-16-hackweek-2017-conclusion/

  45. Kubic Container Service Platform

  46. 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?
  47. 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
  48. Kubic Container Service Architecture Cluster Nodes (etcd + Kubernetes Master)

    Log Server Administration Node
  49. 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
  50. 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
  51. Join Us at www.opensuse.org

  52. 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 rbrown@opensuse.org Design & Inspiration openSUSE Design Team http://opensuse.github.io/branding- guidelines/