DevNexus 2015: Kubernetes & Container Engine
Download as PPTX, PDF15 likes4,697 views
Kubernetes is an open source container cluster orchestration platform founded by Google. This presentation covers an overview of it's main concepts, plus how it fits into Google Cloud Platform. This was delivered by Kit Merker at DevNexus 2015 in Atlanta.
Ad
More Related Content
What's hot (20)
Viewers also liked (6)
Ad
Similar to DevNexus 2015: Kubernetes & Container Engine (20)
Ad
Recently uploaded (20)
DevNexus 2015: Kubernetes & Container Engine
- 1. @kitmerker Containers & Kubernetes Kit Merker / [email protected] / @kitmerker Product Manager Google Container Engine, Google Container Registry, Kubernetes
- 2. @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
- 3. @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
- 4. @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
- 5. @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
- 6. @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
- 7. @kitmerker Everything at Google runs in containers: • Gmail, Web Search, Maps, ... • MapReduce, batch, ... • GFS, Colossus, ... • Even GCE itself: VMs in containers
- 8. @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.
- 9. @kitmerker Why containers? • Performance • Repeatability • Isolation • Quality of service • Accounting • Visibility • Portability A fundamentally different way of managing applications Images by Connie Zhou
- 11. @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!
- 12. @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?
- 13. @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
- 14. @kitmerker
- 15. @kitmerker keep your apps running Demo: a taste of Kubernetes
- 16. @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.
- 17. @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
- 18. @kitmerker Pods
- 19. @kitmerker Pods
- 20. @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
- 21. @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
- 23. @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
- 24. @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
- 25. @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
- 26. @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
- 27. @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
- 28. @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
- 29. @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
- 30. @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
- 31. @kitmerker Replication Controllers Replication Controller - Name = “nifty-rc” - Selector = {“App”: “Nifty”, "Phase": "Dev", "Role": "FE"} - PodTemplate = { ... } - NumReplicas = 4
- 32. @kitmerker Replication Controllers node 1 f0118 node 3 node 4node 2 d9376 b0111 a1209 Replication Controller - Desired = 4 - Current = 4
- 33. @kitmerker Replication Controllers node 1 f0118 node 3 node 4node 2 Replication Controller - Desired = 4 - Current = 4 d9376 b0111 a1209
- 34. @kitmerker Replication Controllers node 1 f0118 node 3 node 4 Replication Controller - Desired = 4 - Current = 3 b0111 a1209
- 35. @kitmerker Replication Controllers node 1 f0118 node 3 node 4 Replication Controller - Desired = 4 - Current = 4 b0111 a1209 c9bad
- 36. @kitmerker scaling up & down Demo: more Kubernetes
- 37. @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
- 38. @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
- 39. @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
- 40. @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!
- 41. @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/
- 42. @kitmerker Push & Pull Demo: Google Container Registry
- 43. @kitmerker Kubernetes is Open Source We want your help! http://kubernetes.io https://github.com/GoogleCloudPlatform/kubernetes irc.freenode.net #google-containers @kubernetesio
- 44. @kitmerker Questions? Images by Connie Zhou http://kubernetes.io