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

openSUSE Kubic - What is this?

openSUSE Kubic - What is this?

openSUSE Kubic is the SUSE Container as a Service Platform based on openSUSE Tumbleweed. In this talk, we want to present what this is, how this works, how people can get involved.

Thorsten Kukuk

May 26, 2017

More Decks by Thorsten Kukuk

Other Decks in Technology


  1. openSUSE Kubic SUSE Container as a Service Platform on openSUSE

    Tumbleweed Alexander Herzig – [email protected] Federica Teodori – [email protected] Thorsten Kukuk – [email protected]
  2. Application delivery supply chain has changed Introducing Project Kubic Why

    Project Kubic?
  3. Micro-Services are fun • Monolithic approaches do not meet our

    requirements • VMs add significant resources and management overhead • Running apps in containers is cool, but we need new tools Introducing Project Kubic Why Project Kubic?
  4. Setting up a cluster should be easy So should maintaining

    it be, as well Introducing Project Kubic Why Project Kubic?
  5. • Container based architectures are growing • Containers change IT

    infrastructure • Containers speed up application delivery • Containers provide portability across environments • Containers make applications scale faster Introducing Project Kubic Why Project Kubic?
  6. • re-designing the operation system to Container needs – Kubic

    rethinks the OS design • combining a powerful stack based on: – openSUSE Tumbleweed – SALTSTACK – Docker project – Kubernetes Introducing Project Kubic Why Project Kubic?
  7. Join Project Kubic Build the next generation Container OS with

  8. 8 openSUSE Kubic

  9. 9 openSUSE Kubic • What is this? • SUSE Container

    as a Service Platform based on openSUSE Tumbleweed
  10. 10 In a Nutshell: • OS focused only on containers

    • Minimal images designed for one special Use Case • Transactional Updates • Focused on large deployments • Reduced end-user interactions • Ready to run • Rolling release • Based on openSUSE Tumbleweed RPMs • Own installer, different setup
  11. 11 As Picture I get all the required support from

    the OS I’m small but powerful to run as many containers as needed
  12. 12 System-Infrastructure Overview Cluster Nodes (etcd + Kubernetes Master) SCC/CDN

    SMT Log Server Administration Node
  13. 13 How far are we? • SUSE MicroOS is ported

    (all features including Kubernetes) • Containers for Administration Dashboard are still missing • Installation images are building • Images for KVM, XEN,VMWare are still missing • Integration in openQA is missing • Documentation: Available only for SUSE CaaS Platform
  14. 14 Design

  15. 15 Highlights • Ready to run out of the box

    • No simple bash login prompt where admins have to configure everything! • Btrfs with snapshots and rollback for transactional updates • Read-only filesystem with overlayfs for /etc • Cloud-init for initial configuration (Network, Accounts, Salt) • SALT for full system configuration • Administration Node with dashboard to manage cluster
  16. 16 Delivery (planned) • Installer for Bare Metal: • Standard

    installation ISO image for Administration or Cluster Node • RPM for automatic mass installation of Cluster Nodes (PXE, USB) • Provides /srv/tftpboot files for PXE boot and installation • Can be used to create bootable USB stick or DVD with syslinux • Cloud and virtualization: Provide ready to run images • KVM, VMWare, XEN
  17. 17 Package Format Stay with RPM • RPM advantages •

    Well known format used by several major distributions • Proofed working toolchain from building RPMs to customer delivery • Lot of customers have already policies and toolchain for RPM updates • Signed, easy to verify • Verification of installed system possible • Delta-RPM to save bandwidth
  18. 18 Two Step System Configuration • System should be pre-configured

    as far as possible • Best case: no additional configuration by Sysadmin necessary • Cloud-init to configure the Base OS • Network • SALT • SSH, host key and user keys • Password • Timezone • Keyboard • NTP Can be done via SALT instead
  19. 19 Btrfs as filesystem – Layout (1/2) • Base OS

    and snapshots are read-only • Subvolumes to store data are read-write • Example: /var/log, /var/cache, /var/crash and similar directories • Use overlayfs for /etc (for cloud-init and salt) • Introduce /var/lib/overlay/{work,etc} for overlayfs • Full stateless system: • Remove content of /var/lib/overlay/etc/ and /var/lib/cloud => Not recommended, since even /etc/machine-id can go lost!
  20. 20 Btrfs as filesystem – Layout (2/2) /@/<subvolumes> - Standard

    subvolumes → /cloud-init-config - Configuration files for cloud-init → /var/lib/docker - Storage for container → /var/{cache,crash,log} - Storage for system data → /var/lib/stateless/{work,etc} - Storage for overlayfs → /.snapshots/1/snapshot - Initial installation of Base OS → /.snapshots/2/snapshot - Base OS after first update → /.snapshots/3/snapshot - Base OS after second update
  21. 21 Update • Transactional Updates • Automatic updates • Can

    be disabled • Maintenance Window • Policy defined updates • Standard RPM with zypper, snapper and btrfs progs • Delivery in the same way as for openSUSE Tumbleweed • Process to get updates, fixes, features is the same as for Tumbleweed • SMT as local proxy
  22. 22 Definition A “transactional update” is a kind of update

    that: • Is atomic • Either fully applied or not at all • The update does not influence your running system • Can be rolled back • If the upgrade fails or if the update is not compatible, you can quickly restore the situation as it was before the upgrade
  23. 23 Packages • openSUSE Kubic contains all packages: • Necessary

    to boot the system • Necessary to configure and run the stack • No general purpose OS • New packages will be introduced if needed • Packages will be removed if no longer needed • No guarantee for a stable ABI • Additional RPMs are installable, but can break automatic update => Customer workload has to run in containers
  24. 24 Installer – Only for Bare Metal

  25. 25 Different kind of Setups • Administration Node with Dashboard

    • Cluster Nodes • No services • Installed RPMs are always the same • Difference are the running services and containers
  26. 26 Installation Media • Installation Media similar to openSUSE Tumbleweed

    or Leap • Installer useable for Administration and Cluster Nodes • RPM based • Autoinstallation for Cluster Nodes • Create autoyast.xml on or download from the Administration Node • Have minimal image doing autoyast installation by • booting from USB disk • PXE boot
  27. 27 One-Page Installer • Partition harddisk • same behavior as

    with SLES 12 • Only visible if no automatic proposal is possible • Create btrfs filesystem with subvolumes • No other root filesystem supported • Install Base OS into first snapshot • Configure and install bootloader
  28. 28

  29. 29 Differences compared to Tumbleweed

  30. 30 Differences to openSUSE Tumbleweed (1/2) • Update of packages

    • Read-only root filesystem • transactional-update [up|dup|patch] instead of zypper • Recommended: transactional-update dup • Additional Packages or PTFs • transactional-update ptf [install|remove] <RPM1>...<RPMn> • Rollback • transactional-update rollback [number] instead of snapper rollback [number]
  31. 31 Differences to openSUSE Tumbleweed (2/2) • transactional-update will generate

    kdump initrd • No YaST module available, configuration during installation or manual • AutoYaST • Needs to run in first stage only mode • Configure options from second stage are not available
  32. 32 Where to get it? ISO Image: http://download.opensuse.org/tumbleweed/iso/ Documentation: https://www.suse.com/betaprogram/caasp-beta/#documentation

    Git: https://github.com/kubic-project Else standard openSUSE devel projects
  33. 33 Thank you. Questions?

  34. None