JDD2015: Kubernetes - Beyond the basics - Paul Bakker
•
0 likes•77 views
KUBERNETES - BEYOND THE BASICS Kubernetes has answers to many questions related to clustering and the required low-level networking. When using Kubernetes for real live deployments we need more than those lower-level solutions however. We need things like automated deployments, load balancing for web applications, blue/green deployments and monitoring. This is all possible with Kubernetes when we start to look at Kubernetes as an API. In this talk you will learn to embrace the Kuberentes API and some of the patterns, tools and mechanisms we developed and use around Kubernetes to prepare for production grade deployments.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to JDD2015: Kubernetes - Beyond the basics - Paul Bakker
Similar to JDD2015: Kubernetes - Beyond the basics - Paul Bakker (20)
Recently uploaded
Recently uploaded (20)
JDD2015: Kubernetes - Beyond the basics - Paul Bakker
- 3. Automated, production ready Kubernetes cluster in steps7
- 4. Step Understanding Kubernetes 0 Terminology, and concepts to build upon
- 6. DockerDockerDockerDocker container Pods Node DockerDockerDockerDocker container Pods Node MyService Virtual IP Virtual IP Fixed IP Services
- 7. Deployment 101 Push your Docker container Create a new replication controller JSON file kubectl create -f mycontroller.json Replication Controller creates Pods
- 10. Updating my app Create a new Replication Controller JSON file kubectl create -f my-new-rc.json Scale down and delete old RC
- 11. Step Automated deployment (simplistic) 1 kubectl doesn’t feel like automation…
- 12. The simplest Automated deployment Don’t use kubectl, use the API! Build server creates Replication Controller using REST Build server destroys old cluster using REST
- 14. Curl example curl -X POST http://k8-master:8080/api/v1/namespaces/default/ replicationcontrollers -d '{ #Pod definition }’
- 15. What about downtime? Not quite there yet
- 16. Step Load balancing 2 Our containers are running, but how do we access them!?
- 17. DockerDockerDockerDocker container Pods Node DockerDockerDockerDocker container Pods Node HAProxy HTTP Virtual IP Virtual IP Fixed IP Custom load balancer confd etcd
- 18. Step Software defined network 3 Each Pod gets its own IP Access Pods from outside k8 on the flannel network
- 19. DockerDockerDockerDocker container Node DockerDockerDockerDocker container Pods Node HAProxy HTTP Virtual IP Virtual IP Fixed IP Flannel network Pods
- 20. Flannel: easy to setup & fast (on CoreOS) Weave: userspace implementation is slow, loads of features Project Calico: promising integration with Kubernetes Docker libnetwork: batteries included but swappable SDN - loads of options
- 21. Step Load balancer registration 4 How does the load balancer keep track of pods?
- 22. Cloud RTI Deployer Kubernetes API confd etcd Cloud RTI Deployer Watch update backend configurations watch changes HAProxy update config file
- 23. Step Blue / Green deployment 5 Auto deploy is great, but downtime not so much
- 24. Step 5 - Blue / Green Scale up new cluster Wait until healthy Switch backend in Load Balancer Dispose old cluster
- 25. How do we know a Pod is healthy? Its RUNNING status is not sufficient… Is the app fully started?
- 26. Introduce App level health checks DockerDockerDockerDocker container Node DockerDockerDockerDocker container Pods Node Deployer GET /health GET /health Pods Deploy Server
- 27. Kubernetes API HAProxy etcd Deployer Build Server Start deployment KubernetKubernetKubernetPods GET /health Create RC Switch Proxy Backend Read config confd Watch
- 28. Deployment descriptor { "useHealthCheck": true, "newVersion": "${bamboo.deploy.version}", "appName": "todo", "replicas": 2, "frontend": "rti-todo.amdatu.com", “podspec": { …. } }
- 29. "podspec": { "containers": [{ "image": “amdatu/mycontainer", "name": "todo", "ports": [{ "containerPort": 8080 }], "env": [ { "name": "version", "value": "${bamboo.deploy.version}" } ]}] }
- 33. Logging Centralised logging is key in a dynamic environment Assume you can’t access a pod ELK & Graylog are very useful for this
- 36. Step Configuration 7 Passing config to containers
- 37. Use environment variables dbName=todo-app host=${mongo} myconfig.cfg "podspec": { "env": [ { "name": "mongo", "value": "10.100.2.4" }, Deployment descriptor Approach 1
- 38. Use etcd etcd=localhost:2375 myconfig.cfg /apps/config/demo-app etcd Approach 2 [ { "name": "mongo", "value": "10.100.2.4" } ]
- 39. What to learn from all this? Docker and Kubernetes are awesome They are building blocks, not solutions Use the API!
- 40. And if you don’t want to do all this yourself…. Fully managed Kubernetes based clusters Logging and Monitoring Automated deployments
- 41. Thank you! Blog: http://paulbakker.io Twitter: @pbakker Mail: paul.bakker@luminis.eu