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.

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
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?