Creating a fast Kubernetes Development Workflow

1. @BastianHofmann Creating a fast Kubernetes Development Workflow Bastian Hofmann
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
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
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
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
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
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