An introduction to k8 s.pptx
Download as PPTX, PDF0 likes515 views
Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery called pods. Replication controllers help maintain a desired number of pods running while services define a logical set of pods and a policy by which to access them.
An introduction to k8 s.pptx
- 1. An introduction to Kubernetes Sydney Docker Users Group November 2015 Greg Markey Infrastructure Engineer @ Optiver APAC
- 5. Pod
- 6. Pod
- 9. Service
- 10. Service
Editor's Notes
- #2: Self intro Optiver Why I’m testing Kubernetes
- #3: Mostly introduction; not much detail. Talking about high level concepts; theory of operation, how optiver uses (or wants to use) k8s. Began as a spiritual successor to Google’s “Borg”. Leverages their many years of experience running containers at scale. Written in Golang - open source. Container tech agnostic. Resilient and easily distributed; k8s itself comprises of multiple microservices. Ultimately we chose k8s because it is not strictly a product; Google using it to encourage multi-cloud. Containers encourage stateless design; k8s further encourages this, but does not actively prevent you from deploying stateful. Explain slide (each node/kubelet is phys, square is pod). Applications in k8s: a group of tightly coupled containers that are typically providing some service to each other. Perfect example: Microservices communicating via APIs. In the real world, it is unreasonable to assume everyone uses microservices.
- #4: Explain (high level cluster) Explain Kubelet. Explain example; AWS solution high level – k8s integration, simplified view of what a cluster might look like (excluding lots). We can trigger autoscaling events for our workers using ASG & SNS. v1, production ready July. v1.1.1 one week old. API is now stable. Many services have been identified as candidates for deployment to k8s (API servers, chat bots, bulk data loaders, reverse proxies, configuration management servers, anything in a JVM (e.g. Atlassian things)).
- #5: Explain tiny slide. Explain each component and why it is there. Explain Optiver “spec” or boilerplate application example: monitoring and log shipping are free. Explain the overhead of this model, and why it is better for us. K8S abstracts this complexity away from us. Developers are aware that it is unreasonable to expect all applications to be cloud native microservices. Applications or services in k8s can comprise of traditional software that has been successfully containerised. Benefit to our teams (dev test or deploy, dev svcs CI, infra supporting apps).
- #6: Pod is arguably most important primitive. Fundamental to overall architecture in k8s. Group of containers. Real world example; listener to actual service, includes Optiver boilerplate. Containers are within the same namespace. Pods can communicate with other pods via a cluster-wide IP using NAT. K8S provides pod metrics and arbitrary health checks for containers within. Pin to certain Kubelets with selectors. Do not know of any lost functionality as it is Docker under the hood; still have cgroups.
- #7: Explain manifest example. Describes desired state; k8s control loops constantly comparing current and desired.
- #8: Simple abstraction layer on Pods. Ensures that there are always n copies of your pod, where n is 1 or more. Pods will always be the same, but given unique suffix. Problematic for applications that care about exclusive locks (Confluence). There is no reason why more advanced logic cannot be implemented as part of the container entry point. Replication controllers allow for rolling, live upgrades of pods.
- #10: Service discovery mechanism. Provides transport layer (TCP/UDP) distribution of traffic across a cluster to the appropriate backend pod. Integrates with cloud load balancer services. Essentially a “frontend” to one or more pods that have matching labels.
- #12: Labels and selectors are used for matching pods to nodes, services to pods. Means that you can have more bespoke Kubelets to provide very specialised services.
- #13: Final thoughts