DevNexus 2015: Kubernetes & Container Engine

@kitmerker
Containers & Kubernetes
Kit Merker / kitm@google.com / @kitmerker
Product Manager
Google Container Engine, Google Container Registry, Kubernetes

@kitmerker
build and deploy vm images
• Curated runtimes
• Rich services
• Auto-everything
• … just add code
● Managed collections
● Declarative + Dynamic
Compute as a Continuum
PlatformCluster
• Basic atom
• Run anything
VM
More agility
More Flexibility
build and deploy containers build and deploy apps

@kitmerker
Containers are like VMs, but less overhead
Physical Processor
Virtual Processor
Operating System
Libraries
User Code
Physical Processor
Virtual Processor
Operating System
Libraries
User Code
Private
Copy
Shared
Private
Copy
Shared
Virtual Machines Containers

@kitmerker
Container Cluster Orchestration
Package & run your app as
containers
Find existing container
images from others
Deploy your container on
your laptop, server, or
cloud
Container Cluster
Orchestration Engine
Declarative management
hides complexity
Open Source, Runs Anywhere
Cluster-Oriented Container
Service
Full Google Cloud Platform
Infrastructure
Powered by Kubernetes
Kubernetes Container Engine

@kitmerker
But what ARE they?
Lightweight VMs
• no guest OS, lower overhead than VMs, but no virtualization hardware
Better packages
• no DLL hell
Hermetically sealed static binaries - portable!
• no external dependencies
Provide Isolation (from each other and from the host)
• Resources (CPU, RAM, Disk, etc.)
• Users
• Filesystem
• Network

@kitmerker
How?
Implemented by a number of (unrelated) Linux APIs:
• cgroups: Restrict resources a process can consume
• CPU, memory, disk IO, ...
• namespaces: Change a process’s view of the system
• Network interfaces, PIDs, users, mounts, ...
• capabilities: Limits what a user can do
• mount, kill, chown, ...
• chroots: Determines what parts of the filesystem a user can see

@kitmerker
Everything at Google runs in
containers:
• Gmail, Web Search, Maps, ...
• MapReduce, batch, ...
• GFS, Colossus, ...
• Even GCE itself: VMs in containers

@kitmerker
Everything at Google runs in
containers:
• Gmail, Web Search, Maps, ...
• MapReduce, batch, ...
• GFS, Colossus, ...
• Even GCE itself: VMs in containers
We launch over 2 billion
containers per week.

@kitmerker
Why containers?
• Performance
• Repeatability
• Isolation
• Quality of service
• Accounting
• Visibility
• Portability
A fundamentally different way of
managing applications
Images by Connie Zhou

@kitmerker
Docker
Source: Google Trends

@kitmerker
But what IS Docker?
An implementation of the container idea
A package format
An ecosystem
A company
An open-source juggernaut
A phenomenon
Hoorah! The world is starting to adopt containers!

@kitmerker
Now that we have containers...
Isolation: Keep jobs from interfering with each other
Scheduling: Where should my job be run?
Lifecycle: Keep my job running
Discovery: Where is my job now?
Constituency: Who is part of my job?
Scale-up: Making my jobs bigger or smaller
Auth{n,z}: Who can do things to my job?
Monitoring: What’s happening with my job?
Health: How is my job feeling?

@kitmerker
Enter Kubernetes
Greek for “Helmsman”; also the root of
the word “Governor”
• Container orchestrator
• Runs Docker containers
• Supports multiple cloud and bare-metal
environments
• Inspired and informed by Google’s
experiences and internal systems
• Open source, written in Go
Manage applications, not machines

@kitmerker
keep your apps running
Demo: a taste of Kubernetes

@kitmerker
Design principles
Declarative > imperative: State your desired results, let the system actuate
Control loops: Observe, rectify, repeat
Simple > Complex: Try to do as little as possible
Modularity: Components, interfaces, & plugins
Legacy compatible: Requiring apps to change is a non-starter
Network-centric: IP addresses are cheap
No grouping: Labels are the only groups
Bulk > hand-crafted: Manage your workload in bulk
Open > Closed: Open Source, standards, REST, JSON, etc.

@kitmerker
Primary concepts
Container: A sealed application package (Docker)
Pod: A small group of tightly coupled Containers
example: content syncer & web server
Controller: A loop that drives current state towards desired state
example: replication controller
Service: A set of running pods that work together
example: load-balanced backends
Labels: Identifying metadata attached to other objects
example: phase=canary vs. phase=prod
Selector: A query against labels, producing a set result
example: all pods where label phase == prod

@kitmerker
Pods
Small group of containers & volumes
Tightly coupled
• same node
The atom of cluster scheduling &
placement
Shared namespace
• share IP address & localhost
Ephemeral
• can die and be replaced
Example: data puller & web server
Pod
File Puller Web Server
Volume
Consumers
Content
Manager

@kitmerker
Pod networking
Pod IPs are routable
• Docker default is private IP
Pods can reach each other without NAT
• even across nodes
No brokering of port numbers
This is a fundamental requirement
• several SDN solutions

@kitmerker
10.1.1.0/24
10.1.1.93
10.1.1.113
Pod networking
10.1.2.0/24
10.1.2.118
10.1.3.0/24
10.1.3.129

@kitmerker
Labels
Arbitrary metadata
Attached to any API object
Generally represent identity
Queryable by selectors
• think SQL ‘select ... where ...’
The only grouping mechanism
• pods under a ReplicationController
• pods in a Service
• capabilities of a node (constraints)
Example: “phase: canary”
App: Nifty
Phase: Dev
Role: FE
App: Nifty
Phase: Dev
Role: BE
App: Nifty
Phase: Test
Role: FE
App: Nifty
Phase: Test
Role: BE

@kitmerker
Selectors
App: Nifty
Phase: Dev
Role: FE
App: Nifty
Phase: Test
Role: FE
App: Nifty
Phase: Dev
Role: BE
App: Nifty
Phase: Test
Role: BE

@kitmerker
App == NiftyApp: Nifty
Phase: Dev
Role: FE
App: Nifty
Phase: Test
Role: FE
App: Nifty
Phase: Dev
Role: BE
App: Nifty
Phase: Test
Role: BE
Selectors

@kitmerker
App == Nifty
Role == FE
App: Nifty
Phase: Dev
Role: FE
App: Nifty
Phase: Test
Role: FE
App: Nifty
Phase: Dev
Role: BE
App: Nifty
Phase: Test
Role: BE
Selectors

@kitmerker
App == Nifty
Role == BE
App: Nifty
Phase: Dev
Role: FE
App: Nifty
Phase: Test
Role: FE
App: Nifty
Phase: Dev
Role: BE
App: Nifty
Phase: Test
Role: BE
Selectors

@kitmerker
App == Nifty
Phase == Dev
App: Nifty
Phase: Dev
Role: FE
App: Nifty
Phase: Test
Role: FE
App: Nifty
Phase: Dev
Role: BE
App: Nifty
Phase: Test
Role: BE
Selectors

@kitmerker
App == Nifty
Phase == Test
App: Nifty
Phase: Dev
Role: FE
App: Nifty
Phase: Test
Role: FE
App: Nifty
Phase: Dev
Role: BE
App: Nifty
Phase: Test
Role: BE
Selectors

@kitmerker
Control loops
Drive current state -> desired state
Act independently
APIs - no shortcuts or back doors
Observed state is truth
Recurring pattern in the system
Example: ReplicationController
observe
diff
act

@kitmerker
Replication Controllers
Replication Controller
- Name = “nifty-rc”
- Selector = {“App”: “Nifty”,
"Phase":
"Dev",
"Role":
"FE"}
- PodTemplate = { ... }
- NumReplicas = 4

@kitmerker
node 1
f0118
node 3
node 4node 2
d9376
b0111
a1209
- Desired = 4
- Current = 4

@kitmerker
node 1
f0118
node 3
node 4node 2
- Desired = 4
- Current = 4
d9376
b0111
a1209

@kitmerker
node 1
f0118
node 3
node 4
- Desired = 4
- Current = 3
b0111
a1209

@kitmerker
node 1
f0118
node 3
node 4
- Desired = 4
- Current = 4
b0111
a1209
c9bad

@kitmerker
scaling up & down
Demo: more Kubernetes

@kitmerker
Services
A group of pods that act as one == Service
• group == selector
Defines access policy
• only “load balanced” for now
Gets a stable virtual IP and port
• called the service portal
• also a DNS name
VIP is captured by kube-proxy
• watches the service constituency
• updates when backends change
Hide complexity - ideal for non-native apps
Portal (VIP)
Client

@kitmerker
Services
10.0.0.1 : 9376
Client
kube-proxy
Service
- Name = “nifty-svc”
- Selector = {“App”: “Nifty”}
- Port = 9376
- ContainerPort = 8080
Portal IP is assigned
iptables
DNAT
TCP / UDP
apiserver
watch
10.240.2.2 : 808010.240.1.1 : 8080 10.240.3.3 : 8080
TCP / UDP

@kitmerker
Kubernetes Status & plans
Open sourced in June, 2014
• won the BlackDuck “rookie of the year” award
• so did cAdvisor :)
Google launched Google Container Engine (GKE)
• hosted Kubernetes
• https://cloud.google.com/container-engine/
Roadmap:
• https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/roadmap.md
Driving towards a 1.0 release in O(months)
• O(100) nodes, O(50) pods per node
• focus on web-like app serving use-cases

@kitmerker
The Goal: Shake things up
Containers is a new way of working
Requires new concepts and new tools
Google has a lot of experience...
...but we are listening to the users
Workload portability is important!

@kitmerker
Google Container Registry
• Securely store your container images
• Access Control / Image Encryption
• Inexpensive and scalable Google Cloud Storage
• Fast & Reliable Deployment
Try it out: cloud.google.com/tools/container-registry/

@kitmerker
Push & Pull
Demo: Google Container Registry

@kitmerker
Kubernetes is Open Source
We want your help!
http://kubernetes.io
https://github.com/GoogleCloudPlatform/kubernetes
irc.freenode.net #google-containers
@kubernetesio

@kitmerker
Questions?
Images by Connie Zhou
http://kubernetes.io

DevNexus 2015: Kubernetes & Container Engine

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to DevNexus 2015: Kubernetes & Container Engine

Similar to DevNexus 2015: Kubernetes & Container Engine (20)

Recently uploaded

Recently uploaded (20)

DevNexus 2015: Kubernetes & Container Engine