Creating a fast Kubernetes Development Workflow

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....
     > 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!
     

     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. mail@bastianhofmann.de
     https:/
     /twitter.com/BastianHofmann
     

     View Slide