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.

23c080ae997a17e4b7dac91bde1083bc?s=128

Thorsten Kukuk

May 26, 2017
Tweet

Transcript

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

    Tumbleweed Alexander Herzig – aherzig@suse.com Federica Teodori – fteodori@suse.com Thorsten Kukuk – kukuk@suse.com
  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

    us
  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