Creating a fast Kubernetes Development Workflow

Creating a fast Kubernetes Development Workflow

Ded87c77266697ee6981c2277bb97633?s=128

Bastian Hofmann

November 13, 2019
Tweet

Transcript

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

  2. None
  3. Container orchestration platform

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

  5. No vendor lock in

  6. Runs on

  7. Your laptop

  8. Bare metal

  9. Cloud Providers

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

    yourself
  11. Managed Kubernetes

  12. None
  13. Standardized APIs

  14. It works the same everywhere*

  15. It works the same everywhere* *mostly

  16. This talk is about how to use Kubernetes

  17. Not only for production workloads

  18. But in your development workflows

  19. Goal: Development environment as close to production as possible

  20. Kubernetes' standardized API makes this easier

  21. Agenda

  22. Deployment of a micro-service application

  23. Some tools to help with local development of this application

    on Kubernetes
  24. Let's have a look at the sample application

  25. None
  26. OpenStack Cloud LoadBalancer NGINX Ingress Controller NGINX Ingress Controller NGINX

    Ingress Controller web-application web-application MySQL Primary MySQL Secondary quote-svc quote-svc hello-svc hello-svc
  27. external-dns to create DNS entries automatically

  28. cert-manager to retrieve Let's Encrypt certificates automatically

  29. Database is managed by an Operator

  30. MySQL Operator MySQLCluster MySQL pods MySQL statefulset Kubernetes controller manager

    Discovers Creates Creates Discovers Monitors and manages
  31. If you are interested in the code and how to

    set it up: https:/ /github.com/syseleven/ golem-workshop
  32. Demo

  33. Writing this YAML files is tedious

  34. YAML files are tied to a specific version and a

    specific environment
  35. Production

  36. Staging

  37. Development

  38. Per Development team

  39. Per branch

  40. Per developer

  41. We need to maintain multiple, very similar YAML files with

    slightly different versions and configuration
  42. "Templating"

  43. Great tools because of standardized Kubernetes API

  44. Helm

  45. None
  46. Allows to install applications

  47. So called "charts"

  48. $ helm install stable/wordpress \ --name my-blog \ --namespace blog

  49. Charts can depend on other charts

  50. Multiple deployments of one chart possible

  51. Different release names

  52. Different namespaces

  53. Configuration with values

  54. None
  55. $ helm install stable/wordpress \ --name my-blog \ --namespace blog

    \ -f my-config-values.yaml
  56. Demo

  57. Writing your own charts is fairly easy

  58. Scaffolding to get started

  59. $ helm create quote-svc

  60. Helm lint

  61. Helm kubeval

  62. Helm test

  63. Demo

  64. Alternatives: Kustomize

  65. This works now great for production or staging or CI

  66. Still, for development:

  67. Make a code change

  68. Build docker image

  69. Push docker image

  70. Run helm install/upgrade with new image version

  71. Can this be quicker?

  72. Run everything locally

  73. docker-compose

  74. Duplication of the definition of how to run a container

  75. Inconsistencies

  76. If you have a lot of services, you have to

    run a lot locally
  77. Some services locally, some remote

  78. Service Discovery

  79. Not every service is exposed to the Internet

  80. Shared resources with other developers?

  81. Other options?

  82. Tilt

  83. $ tilt up

  84. Watches for code changes

  85. Rebuilds docker image

  86. Deploys to Kubernetes

  87. Sets up port-forwarding

  88. Can sync changed files directly into a running container

  89. Demo

  90. Alternatives: Skaffold Garden

  91. Debugging containers

  92. Most containers do not have all the debugging tools included

  93. Kubectl debug

  94. Debugging network traffic between containers

  95. Kubectl sniff

  96. Demo

  97. Another approach

  98. None
  99. Creates a two-way proxy between the Kubernetes cluster and you

  100. $ telepresence T: Starting proxy with method 'vpn-tcp'... @fhgbvx65xg|bash-3.2$ curl

    http://quote-svc/quote | jq '.' [ { "ID": 503, "title": "stefan sagmeister", "content": "<p>...</p>\n", "link": "https://quotesondesign.com/stefan- sagmeister-2/" } ]
  101. Swap a running deployment in the cluster with a local

    process
  102. ... or a locally running docker container

  103. $ 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.... > quote-svc@1.0.0 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!
  104. Demo

  105. Summary

  106. Powerful

  107. Great tooling because of common APIs

  108. Especially great if you have multiple services and don't want

    to run everything locally
  109. Test it 30 days For free Visit us at our

    booth
  110. mail@bastianhofmann.de https:/ /twitter.com/BastianHofmann http:/ /speakerdeck.com/u/bastianhofmann https:/ /github.com/syseleven/golem-workshop