![Why micro-services?
● Breaking down the SILOs
○ State of the Art of Micro-services @adrianco: http://youtu.
be/nMTaS07i3jk
● By cleanly defining the api’s between services and load balancing across
those services, it enables clever deployments
○ 1:64 gets some special UI to test
○ Rolling upgrades
○ Never go down
○ Autoscale only the service that needs it.
● Portability, flexibility, speed of development ....
○ Continuous Deployment [github push -> go build -> Run] O(minutes)](https://image.slidesharecdn.com/k8sdockermadison-150302202403-conversion-gate01/85/Docker-Madison-Introduction-to-Kubernetes-8-320.jpg)
![Principles & Concepts
● Design Principles
● Core Concepts
○ Pods & Containers
○ Services
○ Labels
○ Controller(s) - replication controller
○ Selector
● Other Concepts [skip for today]
○ events](https://image.slidesharecdn.com/k8sdockermadison-150302202403-conversion-gate01/85/Docker-Madison-Introduction-to-Kubernetes-14-320.jpg)
Docker Madison, Introduction to Kubernetes
- 2. Overview ● Motivation / Mission / Vision ● Architectural Overview ● Operations ● Demo
- 3. Assumption: You already know about Docker &| have attended the other meetups or talks. I’m going to skip Docker.
- 5. What is kubernetes? ● Greek for “Helmsman” ● Kubernetes is an open source system for managing containerized applications across multiple hosts, providing basic mechanisms for deployment, maintenance, and scaling of applications. It’s APIs are intended to serve as the foundation for an open ecosystem of tools, automations systems, and higher-level API layers. ● Kubernetes establishes robust declarative primitives for maintaining the desired state requested by the user. These primitives are the main value added by Kubernetes.
- 6. What’s the motivation for kubernetes? Develop a set of common declarative primitives that operators can leverage to build a reliable micro-service architecture in a composable manner. Tools around this core construct “could” provide additional features, including cluster management (elasticity ...), federation, etc.
- 7. Why? A part of this is market positioning and commercialization, while the other part is experience and opinions. Google has years of experience managing containers at scale under Borg & Omega. By exposing a subset of these features targeting specific use cases they present themselves(GCE) as the defacto cloud provider for running your container workloads to meet those use cases. It’s a legit positioning move for the shift from vm’s -> containers.
- 8. Why micro-services? ● Breaking down the SILOs ○ State of the Art of Micro-services @adrianco: http://youtu. be/nMTaS07i3jk ● By cleanly defining the api’s between services and load balancing across those services, it enables clever deployments ○ 1:64 gets some special UI to test ○ Rolling upgrades ○ Never go down ○ Autoscale only the service that needs it. ● Portability, flexibility, speed of development .... ○ Continuous Deployment [github push -> go build -> Run] O(minutes)
- 9. Use Case Example You are going to create a new super awesome webpage kittenpicsABC123.com, and you want to make $$$ off of it with the following requirements: ● Use Containers ● You want to continuously deploy cool new changes ○ advertising changes ● Resilient against multiple failures ● Replicated-layers that are load-balanced ● SOA++
- 10. Front End v1 v1 v1 v1 c1 internet Mid-Tier v1 v1 v1 v1 c1 Back-end v1 v1 v1 v1 c1 kittenpicsABC123.com
- 11. Why declarative vs. imperative? ● Common use case patterns immerge, so make them simple ● Doesn’t require a high level of understanding to get started, which reduces the barrier to entry. ● Imperative could be used in many non-standard ways that was never intended, especially if there is state. ● ...
- 12. State Space IaaS Manage your own machines PaaS Swipe my credit card and make my .jar just work and scale I consider k8’s as a ⅔ lob towards PaaS.
- 14. Principles & Concepts ● Design Principles ● Core Concepts ○ Pods & Containers ○ Services ○ Labels ○ Controller(s) - replication controller ○ Selector ● Other Concepts [skip for today] ○ events
- 15. Design Principles - thockin’s crib Declarative Feedback Control loops : Controller = loop Simple Modular Legacy compatible Network-centric : IP per pod Treat machines as Cattle not Pets Open Source
- 17. What is a POD? A pod (as in a pod of whales or pea pod) correspond to a collocated group of “containers” with shared volumes. A pod models an application-specific "logical host" in a containerized environment. It may contain one or more containers which are relatively tightly coupled -- in a pre- container world, they would have executed on the same physical or virtual host.
- 18. Why Pods? ● Pods are tightly coupled. ● Pods facilitate data sharing, and are a group of containers that are scheduled onto the same host ○ shared mount ○ shared network namespace/IP and port space ○ higher order abstraction to the low level interface ○ Composable micro-services ● Pods abstract the gritty details of container ● Unit of scheduling
- 19. What are Services? Yet Another Reuse of Nomenclature In-order-to Confuse Everyone pirate speak - (YAR-NICE)
- 20. What are Services? A Kubernetes service is an abstraction which defines a logical set of pods and a policy by which to access them - sometimes called a micro-service. The goal of services is to provide a bridge for non-Kubernetes-native applications to access backends without the need to write code that is specific to Kubernetes. A service offers clients an IP and port pair which, when accessed, redirects to the appropriate backends. The set of pods targetted is determined by a label selector. It’s a NAT’d load-balanced proxy, whose IPADDR is injected into the containers that are using that service via an environment variable.
- 22. What are Labels? Labels are key/value pairs that are attached to objects, such as pods. Labels can be used to organize and to select subsets of objects. They are created by users at the same time as an object. Each object can have a set of key/value labels set on it, with at most one label with a particular key. "labels": { "key1" : "value1", "key2" : "value2" }
- 23. What are Replication Controllers? A replication controller ensures that a specified number of pod "replicas" are running at any one time. If there are too many, it will kill some. If there are too few, it will start more. As opposed to just creating singleton pods or even creating pods in bulk, a replication controller replaces pods that are deleted or terminated for any reason, such as in the case of node failure.
- 24. Replication Controller Use Cases ● Rescheduling ○ Fault tolerant ● Scaling ○ up or down cluster management tools ● Rolling Updates ○ application readiness = ? ● Multiple Release Tracks ○ stable, prod, canary
- 25. What is a Selector? Label selectors permit very simple filtering by label keys and values. Currently, label selectors only support these forms: key1 key1 = value11 key1 != value11 key1 in (value11, value12, ...) key1 not in (value11, value12, ...)
- 27. API Server Scheduling KCM (loops) Kubelet Proxy Deployment Master Minions cadvisor
- 29. Runtime behavior ● apiserver ○ main entry point for *operations ● scheduler ○ matches pods to nodes. ● kube controller manager ○ node controller ■ checks machine + pod health ○ replication controller ■ verifies total count is correct. ○ … (quota) ● kubelet ○ runs pods ● proxy ○ load balancing
- 30. Demo