Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Deis @ London PaaS User Group (LOPUG)

Deis @ London PaaS User Group (LOPUG)

Deis: PaaS on Kubernetes as presented at London PaaS User Group (LOPUG).

Gabe Monroy

April 11, 2016
Tweet

More Decks by Gabe Monroy

Other Decks in Technology

Transcript

  1. 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
  2. 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?
  3. 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
  4. What is a Cloud Native Application? 1. Container packaged 2.

    Dynamically scheduled 3. Microservice based
  5. 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
  6. 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
  7. 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
  8. Google Cloud Platform kubelet UI kubelet CLI API users master

    nodes etcd kubelet scheduler controllers apiserver The 10,000 Foot View
  9. Why Kubernetes? (for us) • Vibrant community • Declarative APIs

    • Right abstractions • Promotes loose coupling Represents Google’s 10+ years experience with containers at scale
  10. What is Deis Workflow? • Private PaaS running on your

    own infrastructure • Simple developer experience on top of Kubernetes • Force multiplier for operations teams
  11. Deis Workflow for Developers git push deis master deis ps

    deis scale web=5 deis config:set key THING=foo
  12. Why Helm? Should be easy to… • Get up and

    running with common workloads • Define new workloads • Collaborate on workload definitions
  13. 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
  14. 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
  15. Workflow 2.1 Private Registry Support (imagePullSecrets) Private Applications (non-routeable apps)

    K8S 1.2 Support: Feature flag, where it makes sense Builder using Jobs Controller using Deployments
  16. 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
  17. 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
  18. 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
  19. 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 • ...
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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)
  27. 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)