Kubernetes
- 1. Presentation by Jul 2018 | Anastasios Gogos
- 2. HISTORY IAAS PAAS SAAS BAAS MAAS FAAS CLOUD-NATIVE SERVERLESS Containers Kubernetes Conclusions PRESENTATION STRUCTURE
- 3. HISTORY IAAS PAAS SAAS BAAS MAAS FAAS CLOUD-NATIVE SERVERLESS https://loige.co/from-bare-metal-to-serverless/ https://hackernoon.com/why-the-fuss-about-serverless-4370b1596da0
- 5. THE SaaS AGE Marc Benioff, 1999 launching Salesforce 1999
- 6. MTTRmean time to recovery N+1 multiple power-sources capacity planning
- 7. 2001, VMWare releases ESXi and server virtualization becomes a thing 2001
- 8. THE IaaS AGE 2002-2006 Amazon Web Services EC2 (Virtual Machine service), S3 (Scalable storage service) and SQS (message queuing system) 2006
- 11. Hype-cycle 2012
- 13. Scale-up or Scale-out? 2012
- 14. 2012
- 15. We still haven’t fixed the deployment times! apps are monoliths and this is a problem
- 16. Separation of concerns / Microservices
- 18. 2014, Kubernetes Containers at scale: Kubernetes 2014
- 20. 2018
- 22. 2014, AWS Lambda
- 23. What is it all about?
- 25. It’s a developer-focused wave of services @samnewman follows…
- 27. Containers Treating containers like a black box will eventually leave you in the dark. @kelseyhightower
- 28. @jpetazzo
- 29. @jpetazzo
- 31. …is a system container runtime designed to execute "full system containers", which generally consist of a full operating system image. An LXC process, in most common use cases, will boot a full Linux distribution such as Debian, Fedora, Arch, etc, and a user will interact with it similarly to how they would with a Virtual Machine image. LXC LXD …is similar to LXC but is a REST API on top of liblxc which forks a monitor and container process. This ensures the LXD daemon is not a central point of failure and containers continue running in case of LXD daemon failure. All other details are nearly identical to LXC.
- 32. “Docker’s architecture is fundamentally flawed” At the heart of Docker is a daemon process that is the starting point of everything Docker does. The docker executable is merely a REST client that requests the Docker daemon to do its work. Critics of Docker say this is not very Linux-like. Container Wars
- 33. Container Wars runC is a low-level container runtime and an implementation of the OCI spec. runC exposes and expects a user to understand low-level details of the host operating system and configuration containerd is a daemon to control runC.
- 34. Kubernetes
- 44. Though we can argue that containers at scale can be maintained manually, or with the help of some scripts, container orchestrators can make things easy for operators. Why Use Container Orchestrators?
- 45. • Bring multiple hosts together and make them part of a cluster • Schedule containers to run on different hosts • Help containers running on one host reach out to containers running on other hosts in the cluster • Bind containers and storage • Bind containers of similar type to a higher-level construct, like services, so we don't have to deal with individual containers • Keep resource usage in-check, and optimize it when necessary • Allow secure access to applications running inside containers. With all these built-in benefits, it makes sense to use container orchestrators to manage containers. Container orchestrators can:
- 46. • Start 5 containers using image atseashop/api:v1.3 • Place an internal load balancer in front of these containers • Start 10 containers using image atseashop/webfront:v1.3 • Place a public load balancer in front of these containers • It's Black Friday (or Christmas), traffic spikes, grow our cluster and add containers • New release! Replace my containers with the new image atseashop/webfront:v1.4 • Keep processing requests during the upgrade; update my containers one at a time Basic things we can ask Kubernetes to do @jpetazzo
- 47. • Basic autoscaling • Blue/green deployment, canary deployment • Long running services, but also batch (one-off) jobs • Overcommit our cluster and evict low-priority jobs • Run services with stateful data (databases etc.) • Fine-grained access control defining what can be done by whom on which resources • Integrating third party services (service catalog) • Automating complex tasks (operators) Other things that Kubernetes can do for us @jpetazzo
- 48. • Our container orchestrator puts a very strong emphasis on being declarative • Declarative: • I would like a cup of tea. • Imperative: • Boil some water. Pour it in a teapot. Add tea leaves. Steep for a while. Serve in cup. • Declarative seems simpler at first ... • ... As long as you know how to brew tea Declarative vs imperative @jpetazzo
- 49. • Virtually everything we create in Kubernetes is created from a spec • Watch for the spec fields in the YAML files later! • The spec describes how we want the thing to be • Kubernetes will reconcile the current state with the spec (technically, this is done by a number of controllers) • When we want to change some resource, we update the spec (desired state) • Kubernetes will then converge that resource Declarative vs imperative in Kubernetes @jpetazzo
- 50. • TL,DR: Our cluster (nodes and pods) is one big flat IP network. • In detail: • all nodes must be able to reach each other, without NAT • all pods must be able to reach each other, without NAT • pods and nodes must be able to reach each other, without NAT • each pod is aware of its IP address (no NAT) • Kubernetes doesn't mandate any particular implementation Kubernetes network model @jpetazzo
- 51. • Everything can reach everything • No address translation • No port translation • No new protocol • Pods cannot move from a node to another and keep their IP address • IP addresses don't have to be "portable" from a node to another (We can use e.g. a subnet per node and use a simple routed topology) • The specification is simple enough to allow many various implementations Kubernetes network model: the good @jpetazzo
- 52. • Everything can reach everything • if you want security, you need to add network policies • the network implementation that you use needs to support them • There are literally dozens of implementations out there (15 are listed in the Kubernetes documentation) • It looks like you have a level 3 network, but it's only level 4 (The spec requires UDP and TCP, but not port ranges or arbitrary IP packets) • kube-proxy is on the data path when connecting to a pod or container, and it's not particularly fast (relies on userland proxying or iptables) Kubernetes network model: the less good @jpetazzo
- 53. • Don't worry about the warning about kube-proxy performance • Unless you: • routinely saturate 10G network interfaces • count packet rates in millions per second • run high-traffic VOIP or gaming platforms • do weird things that involve millions of simultaneous connections (in which case you're already familiar with kernel tuning) Kubernetes network model: kube-proxy @jpetazzo
- 54. Conclusions
- 55. Thoughts from one of the creators of Kubernetes
- 56. Abstractions are NOT a new thing, It’s how CS evolved BUT…
- 57. When you go too far up, abstraction- wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all- encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all. Architecture Astronauts “ ”2001, Joel Spolsky Co-founder @stackoverflow @trello
- 58. (6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. (6a) (corollary). It is always possible to add another level of indirection. RFC 19251 April 1996 “ ”
- 59. We can solve any problem by introducing an extra level of indirection. FTSEFundamental Theorem of Software Engineering “ ”The theorem is often expanded by the humorous clause “…except for the problem of too many levels of indirection”
- 60. too many Abstractions = may create intrinsic Complexity issues of their own
- 65. That’s all…
- 66. Links • https://loige.co/from-bare-metal-to-serverless/ • https://hackernoon.com/why-the-fuss-about-serverless-4370b1596da0 • https://www.martinfowler.com/articles/serverless.html • https://www.slideshare.net/randybias/the-history-of-pets-vs-cattle-and-using-it-properly • https://www.slideshare.net/spnewman/what-is-this-cloud-native-thing-anyway • https://www.slideshare.net/spnewman/confusion-in-the-land-of-the-serverless • https://www.slideshare.net/JorgeMorales124/build-and-run-applications-in-a-dockerless-kubernetes-world • https://medium.com/@adriaandejonge/moving-from-docker-to-rkt-310dc9aec938 • https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html • https://www.slideshare.net/jpetazzo/anatomy-of-a-container-namespaces-cgroups-some-filesystem-magic-linuxcon