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

Creating a fast Kubernetes Development Workflow

Creating a fast Kubernetes Development Workflow

Bastian Hofmann

May 26, 2019
Tweet

More Decks by Bastian Hofmann

Other Decks in Programming

Transcript

  1. @BastianHofmann
    Creating a fast
    Kubernetes Development Workflow
    Bastian Hofmann

    View Slide

  2. View Slide

  3. Container orchestration platform

    View Slide

  4. Deploy, run and scale your services
    in isolated containers

    View Slide

  5. Very Powerful

    View Slide

  6. Large community

    View Slide

  7. Lot’s of large company backers

    View Slide

  8. No vendor lock in

    View Slide

  9. Standardized APIs

    View Slide

  10. Runs on

    View Slide

  11. Your laptop

    View Slide

  12. View Slide

  13. Bare metal

    View Slide

  14. Cloud Providers

    View Slide

  15. AWS

    View Slide

  16. Azure

    View Slide

  17. Google Cloud Platform

    View Slide

  18. And if you don't want to install and
    maintain Kubernetes yourself

    View Slide

  19. Managed Kubernetes

    View Slide

  20. View Slide

  21. Easy setup

    View Slide

  22. Easy upgrades

    View Slide

  23. Easy scaling

    View Slide

  24. Features

    View Slide

  25. Load Balancing

    View Slide

  26. Distributed Persistent Storage

    View Slide

  27. Backups

    View Slide

  28. Monitoring

    View Slide

  29. Support

    View Slide

  30. You can focus on what is important

    View Slide

  31. But this talk is about
    how to use Kubernetes

    View Slide

  32. Not only for production workloads

    View Slide

  33. But in your development workflows

    View Slide

  34. Kubernetes has standardized apis

    View Slide

  35. More and more integrations

    View Slide

  36. Great tools

    View Slide

  37. Agenda

    View Slide

  38. Introduction to Kubernetes

    View Slide

  39. Deployment of a simple application

    View Slide

  40. Deployment of a micro-service
    application

    View Slide

  41. Some tools for development with
    Kubernetes

    View Slide

  42. But first

    View Slide

  43. Why containers?

    View Slide

  44. Services run in isolation

    View Slide

  45. Everything needed to run a service in
    one image

    View Slide

  46. Make things …

    View Slide

  47. Easier to develop

    View Slide

  48. Easier to deploy

    View Slide

  49. Easier to upgrade system
    dependencies

    View Slide

  50. Easier to scale

    View Slide

  51. Better resource usage

    View Slide

  52. #safeThePlanet

    View Slide

  53. Kubernetes helps you to deploy, run
    and scale containers

    View Slide

  54. Let’s define some core concepts and
    terminology first

    View Slide

  55. Kubernetes Cluster

    View Slide

  56. • A docker image built from
    a Dockerfile that contains
    everything a service needs
    to run
    Image

    View Slide

  57. • A container runs a docker
    image.
    • Only 1 process can run
    inside of a container
    Container

    View Slide

  58. • A group of 1 or more
    containers
    • Same port space
    • Within a Pod:
    communication over
    localhost
    • Every Pod has it's own IP
    • All Pods can talk with each
    other
    • IPs change all the time
    Pod

    View Slide

  59. • Defines and manages how
    many instances of a pod
    should run
    • ReplicaSet is tied to a
    specific definition of a Pod
    which is tied to specific
    image versions of the
    container
    • Image versions in
    ReplicaSets can't be
    updated
    Replica Set

    View Slide

  60. • Manages updates and
    rollbacks of replica sets
    Deployment

    View Slide

  61. • Internal LoadBalancer
    • Makes all pods matching a
    set of labels accessible
    through a stable, internal
    IP address
    • You can attach external IP
    address through an cloud
    LoadBalancer
    Service

    View Slide

  62. • Makes a service
    accessible to the outside
    of Kubernetes through an
    ingress controller (e.g.
    nginx)
    • Traffic is routed by routing
    rules, usually Host header
    Ingress

    View Slide

  63. • A physical server
    • Containers get distributed
    automatically
    Node

    View Slide

  64. • Key/Value storage for
    configuration
    ConfigMap

    View Slide

  65. • Key/Value storage for
    configuration, usually
    passwords.
    Secret

    View Slide

  66. • Volumes can be mounted
    into a container to access
    a ConfigMap, Secret,
    persistent volumes with
    network storage or a folder
    on the node
    Volumes

    View Slide

  67. • Dedicated environment to
    deploy services in
    Namespaces

    View Slide

  68. CronJobs, DaemonSets,
    StatefulSets, ...

    View Slide

  69. Everything is a resource

    View Slide

  70. You interact with Kubernetes by
    creating, receiving, updating and
    deleting resources

    View Slide

  71. Kubernetes has controllers to listen
    on these interactions and get the
    cluster in the desired state

    View Slide

  72. The Kubernetes API can be extended
    with additional Resources and
    Controllers

    View Slide

  73. CustomResourceDefinitions

    View Slide

  74. Certificate, Backup, Restore,
    MySQLCluster, Function, ...

    View Slide

  75. kind: Deployment
    apiVersion: extensions/v1beta1
    metadata:
    name: symfony-demo
    spec:
    template:
    spec:
    containers:
    - name: symfony-demo
    image: symfony-demo:1.1.0
    ports:
    - containerPort: 80

    View Slide

  76. $ kubectl apply -f deployment.yaml

    View Slide

  77. $ kubectl get deployments
    NAME DESIRED CURRENT UP-TO-DATE AVAILABLE
    AGE
    symfony-demo 1 1 1 1
    21h

    View Slide

  78. $ kubectl get deployment symfony-demo -o yaml
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
    annotations:
    ...
    spec:
    ...
    template:
    ...
    spec:
    containers:
    - name: symfony-demo
    image: symfony-demo:1.1.0

    View Slide

  79. $ kubectl delete deployment symfony-demo

    View Slide

  80. Practical example

    View Slide

  81. We need a cluster

    View Slide

  82. Let’s deploy an application

    View Slide

  83. DEMO

    View Slide

  84. What did just happen?

    View Slide

  85. View Slide

  86. Deployment created

    View Slide

  87. Sees new Deployment
    And creates new
    ReplicaSet with 1 desired
    replica

    View Slide

  88. Sees new ReplicaSet and
    Creates Pod for ReplicaSet

    View Slide

  89. Sees new unscheduled Pod and
    Schedules it to Node

    View Slide

  90. Sees it is supposed to start a Pod
    And starts its Containers

    View Slide

  91. Service created

    View Slide

  92. Sees the new Service
    And configures
    IP Table Rules and DNS entries

    View Slide

  93. Sees the new Service has the
    Type LoadBalancer and creates
    An External LB at the Cloud Provider

    View Slide

  94. What about Configuration

    View Slide

  95. DEMO

    View Slide

  96. What about TLS and DNS

    View Slide

  97. You don't want to implement TLS
    certificate handling in every public
    service

    View Slide

  98. Ingress Controller and cert-manager

    View Slide

  99. The ingress controller (nginx) listens
    on Ingress Resources and configures
    itself to route incoming traffic based
    on the host header to the correct
    running pods

    View Slide

  100. Cert-manager listens on Ingresses
    and if they want TLS, requests a
    certificate from LetsEncrypt

    View Slide

  101. External-DNS listens on Ingresses
    and creates DNS entries at
    DigitalOcean

    View Slide

  102. How is traffic routed to the Pod

    View Slide

  103. OpenStack LoadBalancer

    View Slide

  104. DEMO

    View Slide

  105. What about Persistent Storage and
    Databases

    View Slide

  106. DEMO

    View Slide

  107. Writing this YAML files is tedious

    View Slide

  108. YAML files are tied to a specific
    version and a specific environment

    View Slide

  109. Production

    View Slide

  110. Staging

    View Slide

  111. Development

    View Slide

  112. Per Development team

    View Slide

  113. Per branch

    View Slide

  114. Per developer

    View Slide

  115. Built-in

    View Slide

  116. Namespaces

    View Slide

  117. Still we'd need to maintain multiple
    very similar YAML files with slightly
    different versions and configuration.

    View Slide

  118. "Templating"

    View Slide

  119. Great tools because of standardized
    Kubernetes API

    View Slide

  120. Helm

    View Slide

  121. View Slide

  122. Allows to install applications

    View Slide

  123. So called "charts"

    View Slide

  124. Writing your own charts if fairly easy

    View Slide

  125. Charts can depend on other charts

    View Slide

  126. Multiple deployments of one chart
    possible

    View Slide

  127. Different namespaces

    View Slide

  128. Different release names

    View Slide

  129. Configuration over values

    View Slide

  130. View Slide

  131. Different versions

    View Slide

  132. Different ingress urls

    View Slide

  133. $ helm install stable/wordpress --namespace bastian --name
    my-wordpress --values dev.yaml --values bastian.yaml

    View Slide

  134. Still:

    View Slide

  135. Make a code change

    View Slide

  136. Build docker image

    View Slide

  137. Push docker image

    View Slide

  138. Run helm install/upgrade with new
    image version

    View Slide

  139. Can this be quicker?

    View Slide

  140. Tilt

    View Slide

  141. Watches for changes

    View Slide

  142. Rebuilds docker image

    View Slide

  143. Deploys to Kubernetes

    View Slide

  144. You can use your helm templates

    View Slide

  145. $ tilt up

    View Slide

  146. Demo application

    View Slide

  147. web
    quote-svc
    hello-svc

    View Slide

  148. Not all services have an ingress

    View Slide

  149. Accessing Kubernetes from the
    outside

    View Slide

  150. web
    quote-svc
    hello-svc

    View Slide

  151. Getting a shell in a running container

    View Slide

  152. $ kubectl exec $POD_NAME -i -t -- /bin/bash

    View Slide

  153. Port forwarding through kubectl

    View Slide

  154. $ kubectl port-forward pod/$POD_NAME 8080:80

    View Slide

  155. $ kubectl port-forward service/$SERVICE_NAME 8080:80

    View Slide

  156. What about step debugging?

    View Slide

  157. Of course you can run everything
    locally

    View Slide

  158. But you develop only on one service

    View Slide

  159. There may be lots of services

    View Slide

  160. You don't want to expose all services
    publicly

    View Slide

  161. Port-forwarding all services is also
    work

    View Slide

  162. Telepresence

    View Slide

  163. View Slide

  164. Creates a two-way proxy between
    the Kubernetes cluster and you

    View Slide

  165. $ telepresence
    T: Starting proxy with method 'vpn-tcp'...
    @fhgbvx65xg|bash-3.2$ curl http://quote-svc/quote | jq '.'
    [
    {
    "ID": 503,
    "title": "stefan sagmeister",
    "content": "...\n",
    "link": "https://quotesondesign.com/stefan-
    sagmeister-2/"
    }
    ]

    View Slide

  166. Swap a running deployment in the
    cluster with a local process

    View Slide

  167. ... or a locally running docker
    container

    View Slide

  168. $ telepresence --swap-deployment quote-svc --namespace
    dev-flow-demo --expose 3000 --run npm run debug
    T: Starting proxy with method 'vpn-tcp',...
    T: Forwarding remote port 3000 to local port 3000....
    > [email protected] debug /Users/bhofmann/forge_test/quote-
    svc
    > nodemon --inspect quote-svc.js
    [nodemon] watching: *.*
    [nodemon] starting `node --inspect quote-svc.js`
    Debugger listening on ws://127.0.0.1:9229/83aa27ac-
    d879-4b50-a228-440354cca791
    quote svc listening on port 3000!

    View Slide

  169. Demo

    View Slide

  170. Summary

    View Slide

  171. Powerful

    View Slide

  172. Helpful

    View Slide

  173. Great tooling because of common
    APIs

    View Slide

  174. Especially great if you have multiple
    services and don't want to run
    everything locally

    View Slide

  175. I just picked helm, tilt and
    telepresence. There is more for
    different use-cases.

    View Slide

  176. http:/
    /speakerdeck.com/
    u/bastianhofmann

    View Slide

  177. https:/
    /github.com/bashofmann/
    kubernetes-dev-flow-demo

    View Slide

  178. [email protected]
    https:/
    /twitter.com/BastianHofmann

    View Slide