Quickly following the rise of microservices came the rise of containers to help build and deploy microservices. But how do you manage them effectively to get the best performance while simultaneously reducing cost? Thankfully, there are many solutions out there that can help you orchestrate large clusters of containers to autoscale up or down. During this hands on talk, we will be using three of the most popular open source solutions Kubernetes, Marathon, and Docker Swarm to orchestrate container clusters in order to demonstrate the pros and cons of using each solution. After leaving the talk, you will be able to pick the solution that best fits your needs.
%in kempton park+277-882-255-28 abortion pills for sale in kempton park
Container orchestration - Chicago Coder Conference 2016
1. 1This information is confidential and prepared by Uptake solely for the use of the intended recipient
Container Orchestration
Mariano Gonzalez
Rob Mills
code: http://bit.ly/container-orchestration-code
slides: http://bit.ly/container-orchestration-slides
2. 2This information is confidential and prepared by Uptake solely for the use of the intended recipient
Before we get started
Pre-requisites
3. 3This information is confidential and prepared by Uptake solely for the use of the intended recipient
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)
4. 4This information is confidential and prepared by Uptake solely for the use of the intended recipient
Who are these guys?
5. 5This information is confidential and prepared by Uptake solely for the use of the intended recipient
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.
mariano.gonzalez.mx@gamil.com
Rob Mills
Rob 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.
me@robgmills.com
6. 6This information is confidential and prepared by Uptake solely for the use of the intended recipient
1. Frameworks overview
a. Marathon
b. Kubernetes
1. Workshop
a. Marathon
b. Kubernetes
1. Conclusions
2. QA
Agenda
7. 7This information is confidential and prepared by Uptake solely for the use of the intended recipient
Why should I care?
8. 8This information is confidential and prepared by Uptake solely for the use of the intended recipient
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)?
9. 9This information is confidential and prepared by Uptake solely for the use of the intended recipient
“The Other end of the spear: the tooth-to-tail ratio (T3R) in modern military operations” by John J. McGrath
http://www-cgsc.army.mil/carl/download/csipubs/mcgrath_op23.pdf
3:1
Support : Infantry
Why should I care?
U.S. Military deployments
10. 10This information is confidential and prepared by Uptake solely for the use of the intended recipient
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?
11. 11This information is confidential and prepared by Uptake solely for the use of the intended recipient
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.
12. 12This information is confidential and prepared by Uptake solely for the use of the intended recipient
Let’s start at the beginning
Just to level-set everyone
13. 13This information is confidential and prepared by Uptake solely for the use of the intended recipient
The Old Old Way of Application deployments
App
OS Kernel
lib
App App App
lib liblib liblib lib lib lib
14. 14This information is confidential and prepared by Uptake solely for the use of the intended recipient
App
OS Kernel
lib lib lib
App
lib lib lib
App
lib lib lib
App
lib lib lib
New Old Way
15. 15This information is confidential and prepared by Uptake solely for the use of the intended recipient
Definition
orchestration
(noun)
ˌȯr-kə-ˈstrā-shən
the automated arrangement,
coordination, and management of
complex computer systems, middleware
and services
Chicago Coder Conference June 6-8, 2016
16. 16This information is confidential and prepared by Uptake solely for the use of the intended recipient
Framework Background
17. 17This information is confidential and prepared by Uptake solely for the use of the intended recipient
Framework Background
“an open-source system for automating
deployment, scaling, and management of
containerized applications”
Chicago Coder Conference June 6-8, 2016
18. 18This information is confidential and prepared by Uptake solely for the use of the intended recipient
Framework Background
“production-grade container orchestration
platform”
Chicago Coder Conference June 6-8, 2016
19. 19This information is confidential and prepared by Uptake solely for the use of the intended recipient
Kubernetes
20. 20This information is confidential and prepared by Uptake solely for the use of the intended recipient
So, to rephrase...
a mixed of best practices and an
opinionated technology stack to provide a
robust, scalable way of managing
containers
Chicago Coder Conference June 6-8, 2016
21. 21This information is confidential and prepared by Uptake solely for the use of the intended recipient
Kubernetes
• Pods
• Flat Networking Space
• Labels
• Services
• Replication Controllers
• Docker
Key components
Not going to demonstrate today, but come talk to us about it!
22. 22This information is confidential and prepared by Uptake solely for the use of the intended recipient
Kubernetes Way
Pod
Proxykubelet
App2
lib lib lib
App1
lib lib lib
cAdvisor
Pod
kube-proxykubelet
App4
lib lib lib
App3
lib lib lib
cAdvisor
kubectl
API’s (Rest)
Replication Controller
(REST)
Scheduling
actuator
Scheduler
OS Kernel OS Kernel
etcd
23. 23This information is confidential and prepared by Uptake solely for the use of the intended recipient
Marathon
+ Mesos
24. 24This information is confidential and prepared by Uptake solely for the use of the intended recipient
Marathon
a UI for an infrastructure abstraction to
enable running compute units at scale
Chicago Coder Conference June 6-8, 2016
25. 25This information is confidential and prepared by Uptake solely for the use of the intended recipient
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
26. 26This information is confidential and prepared by Uptake solely for the use of the intended recipient
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
27. 27This information is confidential and prepared by Uptake solely for the use of the intended recipient
Workshop
28. 28This information is confidential and prepared by Uptake solely for the use of the intended recipient
Marathon / Kubernetes Workshop
1. Setup infrastructure
1. Self healing capabilities (Kubernetes)
1. Scale up down the app
1. Blue-Green (Marathon) / Rolling deployments
29. 29This information is confidential and prepared by Uptake solely for the use of the intended recipient
Workshop
30. 30This information is confidential and prepared by Uptake solely for the use of the intended recipient
Results
...but really, our opinions
31. 31This information is confidential and prepared by Uptake solely for the use of the intended recipient
Advantages
Service 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 deployments
GCE integration
Disadvantages
Can only deploy Docker containers
Blue/Green deployments are roll-your-own
Less mature
Can 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
32. 32This information is confidential and prepared by Uptake solely for the use of the intended recipient
Advantages
Requires fewer pieces to get running
Can continue to run Mesos frameworks like Spark and other processes (not Docker-only)
Easy-to-do Blue/Green deployments
Greater compatibility for service discovery frameworks
Full control the deployments via the UI
Disadvantages
Not as much control over multiple-container services
Documentation sometimes sucks and the configuration or execution isn’t always intuitive
Service discovery doesn’t come OOTB
Not backed by Google
Alerts not supported OOTB (and not many options besides Prometheus)
Mesos+Marathon
33. 33This information is confidential and prepared by Uptake solely for the use of the intended recipient
So who is the winner?
34. 34This information is confidential and prepared by Uptake solely for the use of the intended recipient
• 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...
35. 35This information is confidential and prepared by Uptake solely for the use of the intended recipient
• 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...
36. 36This information is confidential and prepared by Uptake solely for the use of the intended recipient
The End?
37. 37This information is confidential and prepared by Uptake solely for the use of the intended recipient
But really, here’s what’s coming
+
38. 38This information is confidential and prepared by Uptake solely for the use of the intended recipient
https://mesosphere.com/blog/2015/09/25/kubernetes-and-the-dcos/
39. 39This information is confidential and prepared by Uptake solely for the use of the intended recipient
Questions?
code: http://bit.ly/container-orchestration-code
slides: http://bit.ly/container-orchestration-slides
Notas del editor
Mariano
Mariano
Mariano
Mariano
Mariano / Rob
Mariano
Rob
Rob
Show of hands:
If you have more “support” engineers (devops/ops) than software engineers?
If you have a 1:1 ratio of “support” engineers to software engineers?
If you have more than 1:3 ratio of “support” engineers to software engineers?
At Uptake, we have a 1:8 ratio (we’re hiring)
Rob
Rob
Mariano
Who has used containers such as Docker, marathon or kubernetes?
Mariano- Handling libraries and environment variables from env to env to can be difficult
Mariano- Still running with docker you deploy your container manually
Mariano
Rob
Rob
Rob
Mariano
Mariano- Opinionated because you have have to use etcd and docker
- The service discovery can be done only through etcd
Mariano
Pods- Are group of containers that are deployed and scheduled together. Pods are the atomic unit of scheduling in Kubernetes- A pod will typically include 1 to 5 containers which work together to provide a service.
- Are meant boe be destroyed continually as the system evolves.
Flat Networking Space
- In the default Docker networking, containers live on a private subnet- In Kubernetes, containers within a pod share an IP address, but the address space is “flat” across all pods, meaning all pods can talk to each other without any Network Address (NAT)
Labels
- Key-value pairs attached to objects in Kubernetes, primarily pods, used to describe identifying characteristics of the object.
e.g. version: dev and tier: frontend. - Using labels, it is easy to do grouping tasks such as assigning pods to load-balanced groups or moving pods between groups.
Services- Services can be connected to pods by using label selectors; for example my “cache” service may connect to several “redis” pods identified by the label selector “type”: “redis”. - The service will automatically round-robin requests between the pods. - In this way, services can be used to connect parts of a system to each other.- Using services provides a layer of abstraction that means applications do not need to know internal details of the service they are calling; for example application code running inside a pod only needs to know the name and port of the database service to call, it does not care how many pods make up the database, or which pod it talked to last time. Kubernetes will set up a DNS server for the cluster that watches for new services and allows them to be addressed by name in application code and configuration files.
Replication controllers- Are the normal way to instantiate pods in Kubernetes (typically, you don’t use the Docker CLI in Kubernetes)- They control and monitor the number of running pods (called replicas) for a service.
Mariano
Kubelet
- For monitoring apps
Proxy- Forwards request using round robin
SkyDNS
- Service discovery built on top of etcd
Kube2sky - Bridge between skydns and kubernetes
Hyperkube- binary distribution of kubernetes servers
Rob
Rob
RobMesos - execution framework
Mesos Master - Coordinator for all of the agents in the cluster.
Converts commands into resource offers containing a bunch of parameters such as how much CPU, memory, etc to make available to the running process
Mesos Agent (Slave) - Execution target for any of the resource offers
Determines if the host that the agent is running on is capable of executing any of the resource offers from the master
Zookeeper - Consensus engine for determining things like which Mesos Master is actually the main Master
Docker - The underlying container API
This is all your Ops team needs to configure and manage in order to deploy a robust container cluster. There are some other things that they should probably still take care of, such as log aggregation and host discovery.
Rob
Mariano
Does anyone have any questions? Do you understand the frameworks at at basic level?
Mariano
Does anyone have any questions? Do you understand the frameworks at at basic level?
Rob
Mariano
Rob
Rob
Mariano
Rob
Rob
Rob
Rob
Best of both worlds?
Better scaling
Can run the existing big data frameworks
Finer grained control over your container execution