From Engines to Orchestrators

23
From Engines to Orchestrators http://calcotestudios.com/feto Lee Calcote Sept 30th, 2016

Transcript of From Engines to Orchestrators

SystemContainersLike a VMFull OS imageMultiple processes

ApplicationContainersSingle process

Use namespaces to deal with resource isolation for a single process.

Use cgroups to manage resources for a group of processes.

Similarities:

@lcalcote

rktdockerrunCkurma

---

containerdsystemd-nspawn

OpenVZSolaris ZonesBSD jailsLinux-VServerAIX WPARsLXC

----

LXDCGManagermachinectl

----

qemu-kvm, lkvm

System ContainerEngines

ApplicationContainer Engines

ContainerSpecifications

@lcalcote

Implemented by -

is the canonicalimplementation

leverages runC  is an implementation

of for FreeBSD using jails andZFS

rkt

KurmaJetpack

Implemented by -

 is the referenceimplementation

 is a hypervisor-basedruntime

launches anIntel VT-x secured ClearContainers 2.0 hypervisor

 

runC

runV

cc-oci-runtime

@lcalcote

a specification for the lifecycle of a running container

tooling for the runtime

 

a software shipping container image format spec with security and naming ascomponents

tooling for the image 

runtime-spec

runtime-tools

image-spec

image-tools

 

 

https://opencontainers.org

Get Started with your Enginesand get your engines started

Popular Engineprocess models

rkt executes as CLI; no daemon

Can run Docker Images and also AppContainer Images (ACIs)

Security has been a focal concern 

uses HTTPS to locate and download remoteACIs and their attached signatures

Docker Engine runs a daemon

rkt

systemd

$ rkt run postgres

application

systemd

$ docker run postgres

application

Docker Engine

containerd

runC

Definition:

[ awr -k uh -streyt -or][k uh n- tey-ner]

CoreCapabilities

Cluster Management

Host Discovery

Host Health Monitoring

Scheduling

Orchestrator Updates and Host

Maintenance

Service Discovery

Networking and Load-Balancing

AdditionalKey Capabilities

Application Health Monitoring

Application Deployments

Application Performance Monitoring

One size does not fit all.

@lcalcote

A strict apples-to-apples comparison is inappropriate and not theobjective, hence  characterizing  and  contrasting.

Genesis & Purpose

an opinionated framework for building distributed systems

or as its tagline states "an open source system for automating deployment, scaling, and

operations of applications."

Written in Golang, Kubernetes is lightweight, modular andextensible

considered a third generation container orchestrator led byGoogle, Red Hat and others.

bakes in load-balancing, scale, volumes, deployments, secret management and cross-

cluster federated services among other features.

Declaratively, opinionated with many key features included

 

@lcalcote

Genesis & Purpose

Swarm is simple and easy to setup.  

Swarm is responsible for the clustering and scheduling aspects of orchestration.    

Originally an imperative system, now declarative  

Swarm’s architecture is not complex as those of Kubernetes and Mesos  

Written in Golang, Swarm is lightweight, modular and extensible

@lcalcote

Genesis & PurposeMesos is a distributed systems kernel

stitches together many different machines into a logical computer

Mesos has been around the longest (launched in 2009)

and is arguably the most stable, with highest (proven) scale currently

Mesos is written in C++

with Java, Python and C++ APIs

Marathon as a Framework

Marathon is one of a number of frameworks (Chronos and Aurora other examples) that may

be run on top of Mesos

Frameworks have a scheduler and executor. Schedulers get resource offers. Executors run

tasks.

Marathon is written in Scala

@lcalcote

Summary

Lee Calcote

linkedin.com/in/leecalcote

@lcalcote

blog.gingergeek.com

[email protected]

Thank you. Questions?

clouds, containers, infrastructure,

applications  and their management