Das Gruselkabinett des Dr. Kube

Transcript

1. 1 BED-CON 2018
3. 3 http://pxhere.com/de/photo/901604
4. 4 CRONJOBS 4 https://pxhere.com/de/photo/237
8. 8 • Use Kubernetes CronJobs • Cluster-wide Scheduling • Save Ressources • https://kubernetes.io/docs/tasks/job/automated-tasks- with-cron-jobs
9. 9 APPLICATION SERVER 9 http://pxhere.com/de/photo/1241325
10. 10 • Deploying multiple Server instances, sharing a volume. • Applications are deployed to volume • Flaws • No Rolling-Upgrades • Manual Rollback • Single Point of Failure • What is your artifact? Persistent Volume /usr/local/tomcat/webapps/ ROOT.war App1.war
11. 11 VIEL HILFT VIEL 1 1 https://pxhere.com/de/photo/819785
12. 12 1 2 https://pxhere.com/de/photo/499735
13. 13 1 3 https://pxhere.com/de/photo/500088
14. 14 1 4 https://pxhere.com/de/photo/497849
15. 15 Use small base images 1 Short startup times No debugging tools Split different runtimes across different containers Lookout for your image size (e.g. package caches, …) 2 3 4 5 15 1 5 Small is beautiful https://pxhere.com/de/photo/864475
16. 16 • You don’t need debugging, you need observability: • Pod Lifecycles • Scaling • Cluster Rebalancing • Monitoring • Metrics • Cluster State • Tracing
17. 17 GOD POD 1 7 https://pxhere.com/de/photo/1061483
18. 18 • Running processes inside your container behing some init system (systemd, supervisord, …) • Hiding process state from your container runtime. • Restarts? • Separation of concerns? • Logs? • Patching? • Start-Up Times? Docker Container • supervisord • Application 1 • Application 2 • … • Applicaiton N
19. 19 • The bigger your pods, the harder your scheduling • Horizontal Scaling? • Pods are scheduled, upgraded and restarted as a unit • Use one pod per container, unless you know what you’re doing! Pod Application 1 Application 2 Application 3 Application N
20. 20 MATROSCHKA CLUSTER 2 0 https://pxhere.com/de/photo/842115
22. 22 • A technology is matroschka complete when it can be deployed onto itself. • The matroschka level is the number of layers between a deployment and the hosting deployment of the same technology.
23. 23 Nesting other clusters inside Kubernetes is tricky 1 Use StatefulSets for predictable Hostnames and Storage Provisioning Use clusters with reasonable recovery times from split brains and node failures Consider re-architecting your application into stateless containers 2 3 4 23 2 3 https://pxhere.com/de/photo/864475
24. 24 POD THE BUILDER 2 4 https://pxhere.com/de/photo/1087298
25. 25 • Docker Daemon is needed to build docker images • Solution: Passthrough of socket into build container • Paraphrasing: You are granting control of your host to not yet verified code. Host Build Docker Daemon App App Socket
26. 26 Possible solution: Docker-in-Docker (still need priviledged access to the linux kernel) 1 Evaluate alternative builders: kaniko, jib Mitigation: Split clusters between development and other stages Caveat: If building in cluster, look at serviceaccount, too! 2 3 4 26 2 6 https://pxhere.com/de/photo/864475 https://pxhere.com/de/photo/833821
27. 27 DER LETZTE SCHREI 2 7 https://pxhere.com/de/photo/764418
28. JOHN DOE 28 https://pxhere.com/de/photo/1059431
29. 29 • Which version are you running now? • Docker-Tags are not immutable • Rolling Upgrades work only when definitions are changed • What was deployed at what time?
31. 31 nicolas.byl@codecentric.de 31 http://www.twitter.com/NicolasByl
32. 32 BONUSLEVEL: SWEET MEMORIES 3 2 https://pxhere.com/de/photo/992494
33. 33 • Kubernetes knows hard and soft limits for memory and CPU • Take care if doing manually! • Strategies: • Hide behind workflow tool • Teach your users • compliance-check your deployments • Use an aware Runtime! (JDK 9+)