Deis @ Kubernetes London

Deis: PaaS on Kubernetes at the Kubernetes London Meetup.

Transcript

1. Kubernetes London
2. About Me • Creator and CTO of Deis • Largest external contributor to Docker during its formative months • Helped shape operational best practices for CoreOS and etcd
3. About Deis • Acquired by Engine Yard in April 2015 • Leading open source PaaS with 5.7 million downloads • Building products for the Kubernetes Ecosystem ◦ Deis Workflow ◦ Deis Helm I have Kubernetes, now what?
4. The Deis Mission
5. Accelerate the transformation to cloud native computing
6. Empower Developers • Create applications • Deploy code or Docker images • Configure runtime environment • Manage releases and rollbacks • Run administrative commands • View aggregated logs • Scale out via the process model • Collaborate with a team … with simple, easy-to-use CLIs and APIs
7. Empower Operators Cloud Native Operational Model Infrastructure Ops Cluster Ops Application Ops
8. Cloud Native
9. Cloud Native Computing Foundation Source: https://cncf.io/
10. What is a Cloud Native Application? 1. Container packaged 2. Dynamically scheduled 3. Microservice based
11. CNCF: Scope Source: https://docs.google.com/presentation/d/11kp272oeNxpvNTZVYMoH5LsdrLRXIm2PTD5DrVjYFZs/edit#slide=id.gd6a2cee48_23_49
12. CNCF: Composite Microservices Source: https://docs.google.com/presentation/d/11kp272oeNxpvNTZVYMoH5LsdrLRXIm2PTD5DrVjYFZs/edit#slide=id.geba7160b9_10_113
13. CNCF: Publication & Deployment CI/CD drives immutable infrastructure • components are replaced not modified • images are baked on demand Deployment services use monitoring data to canary, roll forward, roll back Changes propagate through dependency graphs automatically subject to policy Source: https://docs.google.com/presentation/d/11kp272oeNxpvNTZVYMoH5LsdrLRXIm2PTD5DrVjYFZs/edit#slide=id.geba7160b9_10_120
14. CNCF: Technologies The initial focus of the Cloud Native Computing Foundation will be integrating the orchestration layer of the container ecosystem. Joyent, CoreOS, IBM, VMWare, Cisco, Weaveworks and others have all offered up relevant technology and we look forward to working closely as a group to bring the disparate projects together cleanly. Kubernetes has been offered as a seed technology. Source: https://docs.google.com/presentation/d/11kp272oeNxpvNTZVYMoH5LsdrLRXIm2PTD5DrVjYFZs/edit#slide=id.gd6a2cee48_23_49
15. Kubernetes
16. What is Kubernetes? Greek for “Helmsman”; also the root of the words “governor” and “cybernetic” • Runs and manages containers • Inspired and informed by Google’s experiences and internal systems • Supports multiple cloud and bare-metal environments • Supports multiple container runtimes • 100% Open source, written in Go Manage applications, not machines
17. Google Cloud Platform kubelet UI kubelet CLI API users master nodes etcd kubelet scheduler controllers apiserver The 10,000 Foot View
18. Google Cloud Platform UI API Container Cluster All You Really Care About
19. and 1000s more... Kubernetes Real World Adoption
20. Kubernetes Concepts
21. Google Cloud Platform 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) Labels
22. Google Cloud Platform App: MyApp Phase: prod Role: FE App: MyApp Phase: test Role: FE App: MyApp Phase: prod Role: BE App: MyApp Phase: test Role: BE App = MyApp, Role = FE Selectors
23. Google Cloud Platform Pods Small group of containers & volumes Tightly coupled The atom of scheduling & placement Shared namespace • share IP address & localhost • share IPC, etc. Managed lifecycle • bound to a node, restart in place • can die, cannot be reborn with same ID Example: data puller & web server Consumers Content Manager File Puller Web Server Volume Pod
24. Google Cloud Platform Volumes Very similar to Docker’s concept Pod scoped storage Share the pod’s lifetime & fate Support many types of volume plugins • Empty dir (and tmpfs) • Host path • Git repository • GCE Persistent Disk • AWS Elastic Block Store • iSCSI • NFS • GlusterFS • Ceph File and RBD • Cinder • Secret • ...
25. Google Cloud Platform ReplicationControllers A simple control loop Runs out-of-process wrt API server Has 1 job: ensure N copies of a pod • if too few, start some • if too many, kill some • grouped by a selector Cleanly layered on top of the core • all access is by public APIs Replicated pods are fungible • No implied order or identity ReplicationController - name = “my-rc” - selector = {“App”: “MyApp”} - podTemplate = { ... } - replicas = 4 API Server How many? 3 Start 1 more OK How many? 4
26. Google Cloud Platform Services A group of pods that work together • grouped by a selector Defines access policy • “load balanced” or “headless” Gets a stable virtual IP and port • sometimes called the service portal • also a DNS name VIP is managed by kube-proxy • watches all services • updates iptables when backends change Hides complexity - ideal for non-native apps Client Virtual IP
27. Google Cloud Platform Secrets Problem: how to grant a pod access to a secured something? • don’t put secrets in the container image! 12-factor says: config comes from the environment • Kubernetes is the environment Manage secrets via the Kubernetes API Inject them as virtual volumes into Pods • late-binding • tmpfs - never touches disk node API Pod Secret
28. Google Cloud Platform HorizontalPodAutoScalers Automatically scale ReplicationControllers to a target utilization • CPU utilization for now • Probably more later Operates within user-defined min/max bounds Set it and forget it Status: BETA in Kubernetes v1.1 ... Stats
29. Google Cloud Platform DaemonSets Problem: how to run a Pod on every node • or a subset of nodes Similar to ReplicationController • principle: do one thing, don’t overload “Which nodes?” is a selector Use familiar tools and patterns Status: ALPHA in Kubernetes v1.1 Pod
30. Google Cloud Platform PersistentVolumes A higher-level abstraction • insulation from any one cloud environment Admin provisions them, users claim them Independent lifetime and fate Can be handed-off between pods and lives until user is done with it Dynamically “scheduled” and managed, like nodes and pods Claim
31. Google Cloud Platform Namespaces Problem: I have too much stuff! • name collisions in the API • poor isolation between users • don’t want to expose things like Secrets Solution: Slice up the cluster • create new Namespaces as needed • per-user, per-app, per-department, etc. • part of the API - NOT private machines • most API objects are namespaced • part of the REST URL path • Namespaces are just another API object • One-step cleanup - delete the Namespace • Obvious hook for policy enforcement (e.g. quota)
32. Google Cloud Platform New and coming soon • Jobs (run-to-completion) • Cron (scheduled jobs) • Privileged containers • Downward API • Interactive containers • Bandwidth shaping • Simpler deployments • Third-party API objects • HA master • Easier to run as non-root • Scalability++ • Performance++ • Easier installation & setup • Config injection • Cluster federation • More volume types • Private Docker registry • External DNS integration • Volume auto-provisioning • Node fencing • DiY Cloud Provider plugins • More container runtimes (e.g. Hyper) • Better auth{n,z} • Network policy • Big data integrations • Better affinity policies • Device scheduling (e.g. GPUs)
33. Why Kubernetes? (for us) • Vibrant community • Declarative APIs • Right abstractions • Promotes loose coupling Represents Google’s 10+ years experience with containers at scale
34. Using Kubernetes is really complicated
35. Deis Workflow
36. What is Deis Workflow? • Private PaaS running on your own infrastructure • Simple developer experience on top of Kubernetes • Force multiplier for operations teams
38. Deis Workflow for Developers git push deis master deis ps deis scale web=5 deis config:set key THING=foo
39. Deis Workflow for Operators kubectl helm
40. Deis Helm
41. The best way to find, share and use software built for Kubernetes
42. Why Helm? Should be easy to… • Get up and running with common workloads • Define new workloads • Collaborate on workload definitions
43. Helm vs. Workflow • Workflow focused on 12-factor applications • Helm focused on non-12-factor applications ◦ Databases ◦ Queues ◦ Caches • Helm promotes a Kubernetes-native approach • Helm is a tool for operators, not developers Helm is used to install Workflow
44. Demo
45. Road to Workflow 2.0 • Beta 1 ◦ Released March 25, 2016 • Theme: Operator UX ➔ Beta 2 ◦ Target April 13, 2016 • Theme: Stability ➔ Beta 3 ◦ Target April 27, 2016 • Theme: Monitoring ➔ Beta 4 ◦ Target May 11, 2016 • Release Candidate ◦ Target May 25, 2016 • Deis Workflow Stable ➔ June 8, 2016
46. Workflow 2.1 Deis Doctor Teams and Permissions Service Broker
48. Questions?