5. @rstarmer @mschulz
Why not just stick with VMs?
Bare Metal (Nova & Ironic)
x86, ARM, other processor
Memory
Local “block” storage subsystem
Hypervisor (Nova)
Hypervisor - Hardware access
management and segregation
ESX, KVM, Hyper-V, Xen, LPAR
Container (Nova)
OS level segregation of processes
Docker/LXC, Solaris containers
Hardware
APP APP APP
Host OS
bin/lib bin/lib bin/lib
Hardware
APP
OS
Hypervisor
APP
OS
APP
OS
Host OS
bin/lib bin/lib
Virtual machine
Guest
OS
bin/lib
Hardware
APP
bin/lib
Container Engine
APP
bin/lib
APP
bin/lib
Host OS
Container
@rstarmer
6. @rstarmer @mschulz
Developers get Containers
• Dev/Ops is a stepping stone for many developers
• Enabled application development models that were not previously
possible
• Ops is something to limit and reduce
• There is a growing #serverless community - focusing on just the
application again
@rstarmer
8. @rstarmer @mschulz
Still need to “operate” containers
• Can’t avoid some underlying operations
• Manage infrastructure failures gracefully
• Provide some scale services (e.g. Load balancing)
• Managing interactions and security between multi-container
services and solutions
• Manage and configure storage mappings
@rstarmer
9. @rstarmer @mschulz
The field of Container Management
• LXC and LXD or libvirt-lxc
• Docker and Docker(plus Swarm)
• Docker/RKT/(?LXC?) and Kubernetes
• Docker, LXC, etc. and Mesos/DCOS
• Docker Cloud, Rancher, DCOS, CoreOS Fleet….
@rstarmer
10. @rstarmer @mschulz
Management Functions
• Lifecycle Management
• Rolling Upgrades
• Scheduling
• Network Service
• Storage Mapping
• Seems like an IaaS might be of service
@rstarmer
12. @rstarmer @mschulz
Managing Containers
Container Management on OpenStack
• Leverage VMs to support Container engines
• Container Operating Environment deployed via HEAT
• Leverage Network services:
• LBaaS
• Kuryr
@rstarmer
13. @rstarmer @mschulz
HEAT
• Template based automation
• Access to all OpenStack resources and services:
• Compute – OS::Nova::
• Storage – OS::Cinder::,OS::Swift::
• Network – OS::Neutron::, OS::Neutron::LBaaS::
• Even HEAT – OS::Heat::
• Templates used across most OpenStack driven Kubernetes
deployments:
• Magnum
• Murano
@rstarmer
14. @rstarmer @mschulz
HEAT and CAPS
• CAPS: Chef, Ansible, Puppet, SaltStack
• Implements “state based” automation
• Simplifies service configuration vs. shell scripts
• Powerful automation tools for deployment
• Many applications are already supported
• HEAT implements the infrastructure services
• Still need to implement the application services
• Use SaltStack to provide “application” automation
@rstarmer
16. @rstarmer @mschulz
Kubernetes and Openstack
• OpenStack provides the IaaS model via HEAT
• HEAT triggers SaltStack deployment of Kubernetes
• Kubernetes supports Container Operations
• OpenStack can support additional underlying services:
• Network (Integrate with Kuryr, add LBaaS)
• Storage (add Cinder block, or Ceph)
@rstarmer
17. @rstarmer @mschulz
Kubernetes
@rstarmer
Greek for “Helmsman”; also the root of
the word “Governor”
• Orchestrator for containers
• Supports multi-cloud environments
• Inspired and informed by
Google’s experiences and
internalsystems
• Open source, written inGo
Manage applications, notmachines
18. @rstarmer @mschulz
Kubernetes manages your applications
@rstarmer
• Scheduling of where containers should run
• Lifecycle and health to keep containers running
• Discovery of containers and their location
• Monitoring of containers
• Control who can do things to containers
• Aggregates sets of containers into jobs
• Making jobs bigger or smaller by scaling up/down