Microservice Architekturen praktisch - Kubernetes (Architecture Summit 2018)

Transcript

1. Kubernetes Microservice Architekturen praktisch Jörg Müller - @joergm Eberhard Wolff - @ewolff 12.9.2018 
 Berlin / Architecture Summit
2. Prerequisites & rules • Kubernetes know-how not necessary, but it doesn’t hurt • Basic knowledge about Docker is assumed • Demos can be followed but don’t have to • github.com/JoergM/kubernetes_workshop_demos • Please ask questions!
3. Kubernetes Overview
4. Docker Recap
5. Docker container at runtime • Isolated process • Separate f ile system • Own network address and port space
6. Docker container - advantages • Better isolation than package management on same machine • e.g. multiple versions of core libraries • not necessary to coordinate available ports • Faster startup than virtual machine images • Better resource usage compared to VMs
7. Docker images • Standardized format • Container hierarchies and difference f ile system • Registries • Unique name format 
 (Registry/username/imagename:version) • Simple Text-Format to create new images (Docker f ile)
8. Docker images - advantages • Deployment format independent of implementation technology • Same deliverable in all stages (Development, CI, Tests, Production) • Container hierarchies allow simpler patch management • De f inition simpler than most package manager de f initions
9. What is Kubernetes?
10. Kubernetes — adds to Docker • Handling of multiple servers • Scheduling of containers • Networking • Failure handling • Service Discovery features • Many other useful abstractions for container interactions
11. Kubernetes - executive summary • Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications • Marketing claim: • Planet Scale • Never Outgrow • Run Anywhere
12. Kubernetes — brief history • Designed by Google, later donated to Cloud Native Computing Foundation • Heavily in f luenced by Google's internal Borg system • Code name: Project Seven • Initial release: 7 June 2014 / 15 December 2015 ( f irst stable version)
13. Ways to learn Kubernetes • Online Tryouts • https://labs.play-with-k8s.com/ • https://www.katacoda.com/courses/kubernetes/ playground • Local installation • Minikube • Docker native
14. Kubernetes Providers • Cloud providers (Google GKE, Azure AKS, Amazon EKS) • „Distributions" (Giantswarm, Rancher, Tectonic …) • Self-Install (kubeadm, KOPS …) • https://github.com/kelseyhightower/kubernetes-the- hard-way • PaaS solutions (OpenShift, CloudFoundry …)
15. Sync. Microservices - Challenges • Deployment • Con f iguration • Service Discovery • Load Balancing • Routing • Resilience
16. github.com/JoergM/ kubernetes_workshop_demos
17. Pods
18. Pod • Deployment-Unit in Kubernetes • A pod consists of one or more containers • Containers in a pod share network • Containers in a pod can share volumes • Each pod receives its own cluster-wide and cluster internal IP address
19. Pod with a single container Pod C
20. Sharing network Pod C C localhost
21. Sharing volumes Pod C C
22. Pods with init containers Pod C 1
23. Complex pod patterns Pod init ssl auth app
24. github.com/JoergM/kubernetes_workshop_demos/pods DEMO
25. Deployments
26. Deployment • Declares a state of Pods • Is used for scaling up N instances of the same pod • Is used to deploy old or new revisions of a pod
27. Deployment Deployment Replicas: 4 ... Pod Pod Pod Pod
28. Deployment Pod Pod Pod Deployment Replicas: 4 ... Pod
29. Deployment Deployment Replicas: 4 ... Pod Pod Pod Pod replica set handles self healing Pod
30. Deploying new versions • Rolling update • Recreate • Blue Green • Canary
31. github.com/JoergM/kubernetes_workshop_demos/deployments DEMO
32. Rolling Update • Default variant • No service downtime • Both versions get traf f ic at the same time • consider setting maxUnavailable/ maxSurge
33. Recreate • Activated setting type • Involves downtime • no version con f licts
34. Prelude Service • IP and DNS for multiple Pods • Loadbalancing • Uses Labels to f ind Pods Service Pod Pod order-service 172.30.0.1:80 Label A Label A
35. Blue / Green • No version con f licts • No downtime • High resource usage • Involves custom handling by Switching service labels Service
36. Canary • Slowly testing new versions • No Downtime • Both versions get traf f ic at the same time • Some custom handling of multiple deployments
37. github.com/JoergM/kubernetes_workshop_demos/deployments DEMO
38. Sync. Microservices - Challenges • Deployment • Con f iguration • Service Discovery • Load Balancing • Routing • Resilience
39. Con f iguration
40. Con f ig Maps • Provide Pods with con f iguration data • from • literal values • f iles • directories
41. Con f ig Maps • In Pods as • environment variables • f iles • directories
42. github.com/JoergM/kubernetes_workshop_demos/con f iguration DEMO
43. Interlude Basic concepts
44. Cluster overview Cluster Node Node Node Master Master Master Node …
45. Master Components Cluster Node Node Node Master Master Master Node … Master api-server etcd scheduler controller-manager
46. Node Components Cluster Node Node Node Master Master Master Node … Node container-runtime kubelet kube-proxy network
47. API Objects • Persistent (in etcd) • Represent the desired state of the cluster • Have • Spec • Status
48. Controller • Watch the Api Server for changes • Perform Operations on changes • Creation/ Deletion or Update on other API objects • Running a reconciliation loop
49. Cluster Master API Objects interaction $ kubectl run … api-server etcd Node kubelet docker scheduler 1 2 3 4
50. Sync. Microservices - Challenges • Deployment • Con f iguration • Service Discovery • Load Balancing • Routing • Resilience
51. Services
52. Service Overview Service Pod Pod order-service 172.30.0.1:80 Label A Label A
53. Service • Is an abstraction which de f ines a logical set of pods and a policy by which to access them • Usually represents a micro-service • Different types of services possible • Discovery inside Cluster via DNS • It’s not a physical LoadBalancer (more later)
54. Service type ClusterIP Cluster ClusterIP 172.30.0.1 Node 1 Node 2 Node 3 Consumer Pod Pod
55. Service type NodePort Cluster Node 1 Node 2 Node 3 Pod Pod :80 :80 :80 Consumer
56. Service type LoadBalancer Cluster Node 1 Node 2 Pod Pod Consumer LoadBalancer
57. Service type External… Cluster internal service name/IP Node 1 Consumer External Service
58. github.com/JoergM/kubernetes_workshop_demos/services DEMO
59. Sync. Microservices - Challenges • Deployment • Con f iguration • Service Discovery • Load Balancing • Routing • Resilience
60. Ingress
61. Ingress Cluster Pod Ingress-Controller :80 Pod Service A Service B Pod Pod default default /order /items /foo
62. Ingress Controller • Creates a LoadBalancer service that points to a pod, which runs a reverse proxy (nginx, haproxy, Apache, trae f ik) • Uses IngressRules to describe which DNS and/or path should point to which service • Always needs a default service
63. Ingress controller implementations • nginx • trae f ik • voyager • GCE ingress • Kong • …
64. github.com/JoergM/kubernetes_workshop_demos/ingress DEMO
65. Sync. Microservices - Challenges • Deployment • Con f iguration • Service Discovery • Load Balancing • Routing • Resilience
66. Resilience • Not yet part of standard infrastructure • Auto-Healing already gives a lot of stability • Implementation on Application level (e.g. Hystrix) • Using additional components e.g. Envoy Proxy
67. Service meshes
68. Service Meshes • Providing common infrastructure for microservices • Features • Circuit Breaking • TLS • Authentication • Tracing • …
69. Service Mesh basics Cluster Pod1 Service Sidecar Pod2 Service Sidecar Mesh Control Plane
70. Projects to look at • linkerd (https://linkerd.io/) • Envoy Proxy (https://www.envoyproxy.io/) • Istio (https://istio.io/) • Conduit (https://conduit.io/)
71. Deploying complex applications
72. Helm
73. Helm • Package management for Kubernetes: update, rollback, create, version, share, and publish applications • Ready to use Kubernetes-applications (but always check the sources — like … for real, do it) • Handy for deployment*: persistent history and easy rollback for free • https://helm.sh/
74. Helm cont. • Part of Cloud Native Computing Foundation • Includes the possibility to template Kubernetes con f ig f iles (e.g. for handling different clusters with the same con f igs)
75. github.com/JoergM/kubernetes_workshop_demos/helm DEMO
76. Operators
77. Operators • Idea to automate the knowledge of a human Operator • Not only install automated, but operate automated • The Operator itself run on Kubernetes too • Uses Kubernetes API to do his job • https://coreos.com/operators/
78. Advanced Features • Create Backups • Autoscale • Autoupdate installed Software
79. Operator examples • etcd • Vault • Prometheus • Elasticsearch • Ka f ka
80. Operator Framework • Published on KubeCon 2018 • Operator SDK to create your own Operators • Operator Lifecycle Manager - managing operators in a cluster • Operator Metering - gathering data on operators
81. Jörg Müller 
 Principal Consultant innoQ Deutschland GmbH joerg.mueller@innoq.com @joergm t.me/joerg_m - architecture, development, devOps - focus on platform & infrastructure
82. www.innoq.com OFFICES Monheim Berlin Offenbach Munich Zurich FACTS ~125 employees Privately owned Vendor-independent SERVICES Strategy & technology consulting Digital business models Software architecture & development Digital platforms & infrastructures Knowledge transfer, coaching & trainings CLIENTS Finance Telecommunications Logistics E-commerce Fortune 500 SMBs Startups