container orchestration - chicago coder conference 2016

1This information is confidential and prepared by Uptake solely for the use of the intended recipient

Container OrchestrationMariano GonzalezRob Mills

code: http://bit.ly/container-orchestration-codeslides: http://bit.ly/container-orchestration-slides


Before we get startedPre-requisites


Pre-requisites

• Docker Toolbox (http://bit.ly/docker-toolbox)– docker– docker-machine– docker-compose

• Kubernetes (http://bit.ly/kubernetes-install)– brew install kubernetes-cli

• Git (optional - to pull the code)– brew install git

• Code examples (http://bit.ly/container-orchestration-code)– git clone https://github.com/eschizoid/container-orchestration.git

Install (or have installed)

http://bit.ly/docker-toolbox

http://bit.ly/kubernetes-install

http://bit.ly/container-orchestration-code


Who are these guys?


Mariano Gonzalez

Mariano is a Chicago-based computer geek originally from Mexico. He loves working with all types of middleware technologies such as Apache Camel, IBM Integration Bus, Mule and Spring Integration just to mention a few. He has been using Java for almost 10 years, implementing multiple kinds of applications for different business fields (insurance, banking, and trade shows). Mariano used to work for Peapod.com before joining Uptake. He enjoyed sharing his knowledge about Java platforms SE/EE and it's huge ecosystem.

[email protected]

Rob MillsRob is a technology enthusiast and born problem solver originally from Boston. His experience covers the full stack, including mobile applications, rich single page javascript UIs, e-Commerce applications, enterprise middleware integration applications, and document management applications for clients and employers in a number of verticals. He loves sharing his passion for software engineering in all languages but has a professional background in mostly Java stacks. Rob currently works for Uptake, a predictive analytics/big data/IoT company, as a Software Engineering Manager.

[email protected]

mailto:[email protected]

mailto:[email protected]


1. Frameworks overviewa. Marathonb. Kubernetes

2. Workshopa. Marathonb. Kubernetes

3. Conclusions

4. QA

Agenda


Why should I care?


Why should I care?

Is your (Dev)Ops team

… always putting out fires?… building special snowflake servers?… supporting applications that they

have no idea how they work?… generally overworked (by volume or

by scope)?


“The Other end of the spear: the tooth-to-tail ratio (T3R) in modern military operations” by John J. McGrathhttp://www-cgsc.army.mil/carl/download/csipubs/mcgrath_op23.pdf

3:1Support : Infantry

Why should I care?

U.S. Military deployments

http://www-cgsc.army.mil/carl/download/csipubs/mcgrath_op23.pdf


Why should I care?

So what if you could

… allow your DevOps team to focus on more sustainable infrastructure approaches?

… have a clear handoff between operations and developers?

… allow your developers to reliably ship new changes with minimal DevOps support?

… decrease the DevOps workload?


Ok, now I care.

• More reliable deployments - containers are the same throughout the pipeline

• Narrower DevOps responsibilities - they deliver the underlying hosts and the frameworks* and nothing else

• Keep application domain knowledge with the application - engineers can better see and control how their application runs

• Fewer man-hours required to prototype or test new deployments

The Promise

*please use chef, ansible, puppet, salt, CloudFoundry or the like.


Let’s start at the beginningJust to level-set everyone


The Old Old Way of Application deployments

App

OS Kernellib

App App Applib liblib liblib lib lib lib


App

OS Kernel

lib lib lib

Applib lib lib

Applib lib lib

Applib lib lib

New Old Way


Definition

orchestration(noun)

\ˌor-kə-ˈstrā-shən\

the automated arrangement, coordination, and management of complex computer systems, middleware and services

Chicago Coder Conference June 6-8, 2016

https://en.wikipedia.org/wiki/Middleware_(distributed_applications)


Framework Background



“an open-source system for automating deployment, scaling, and management of containerized applications”




“production-grade container orchestration platform”



Kubernetes


So, to rephrase...

a mixed of best practices and an opinionated technology stack to provide a robust, scalable way of managing containers



Kubernetes

• Pods• Flat Networking Space• Labels• Services• Replication Controllers• Docker

Key components

Not going to demonstrate today, but come talk to us about it!


Kubernetes Way

Pod

Proxykubelet

App2

lib lib lib

App1

lib lib libcAdvisor

Pod

kube-proxykubelet

App4

lib lib lib

App3

lib lib libcAdvisor

kubectl

API’s (Rest)

Replication Controller (REST)

Schedulingactuator

Scheduler

OS Kernel OS Kernel

etcd


Marathon+ Mesos


Marathon

a UI for an infrastructure abstraction to enable running compute units at scale



Marathon

• Mesos– Master– Agent(s) (a.k.a. Slave(s))

• Marathon• Zookeeper• Docker*

Key components

*Actually optional, but not for the purposes of this presentation


OS Kernel

Mesos/Marathon Way

Agent

OS Kernel

Agent

OS Kernel

Agent

Master

marathon-lb

lib lib lib

api

lib lib lib App

cURL

api

lib lib lib


Workshop


Marathon / Kubernetes Workshop

1. Setup infrastructure

2. Self healing capabilities (Kubernetes)

3. Scale up down the app

4. Blue-Green (Marathon) / Rolling deployments


Workshop


Results...but really, our opinions


AdvantagesService discovery and replication baked-in Feature rich command-line client for remote container-level management (kubectl)Powerful control over multiple-containers services (Pods and Services)Rolling deploymentsGCE integration

DisadvantagesCan only deploy Docker containersBlue/Green deployments are roll-your-ownLess matureCan only use etcd (skydns)Alerts not supported OOTB (however there are many options: Google Cloud Monitoring, Bosun +

InfluxDB, Reimann + InfluxDB)Can’t modify the running pods/services/containers using the UI

Kubernetes


AdvantagesRequires fewer pieces to get runningCan continue to run Mesos frameworks like Spark and other processes (not Docker-only)Easy-to-do Blue/Green deploymentsGreater compatibility for service discovery frameworksFull control the deployments via the UI

DisadvantagesNot as much control over multiple-container servicesDocumentation sometimes sucks and the configuration or execution isn’t always intuitiveService discovery doesn’t come OOTBNot backed by GoogleAlerts not supported OOTB (and not many options besides Prometheus)

Mesos+Marathon


So who is the winner?


• you only have containerized apps• you are already using Google Compute Engine• you want to use the kubernetes label-based service-discovery, load-

balancing, and replication control• you already have monitoring and alerting frameworks

We recommend going with Kubernetes if...


• you are using any of the Mesos frameworks like – Hadoop, Storm or Spark for big data processing– Chronos for time-based scheduling

• you already have service discovery other than etcd• you’re using any cloud provider other than Google Compute Engine

We recommend starting with Marathon + Mesos if...


The End?


But really, here’s what’s coming

+

38This information is confidential and prepared by Uptake solely for the use of the intended recipienthttps://mesosphere.com/blog/2015/09/25/kubernetes-and-the-dcos/


Questions?

code: http://bit.ly/container-orchestration-codeslides: http://bit.ly/container-orchestration-slides