Kubernetes Intro
1 like306 views
This document provides an overview of Kubernetes. It begins by introducing Kubernetes and its origins at Google. It then discusses key Kubernetes concepts like pods, deployments, services, ingress, namespaces, labels, and storage. It explains how Kubernetes provides automation of application deployment, scaling, and management using containers. It also discusses how Kubernetes helps enable continuous integration, continuous deployment, and digital transformation. The document concludes by mentioning the Kubernetes ecosystem and Cloud Native Computing Foundation.
![Key Pod Container Attributes
● name - The name of the container
● image - The container image
● ports - array of ports to expose. Can
be granted a friendly name and
protocol may be specified
● env - array of environment variables
● command - Entrypoint array (equiv
to Docker ENTRYPOINT)
● args - Arguments to pass to the
command (equiv to Docker CMD)
Container
name: nginx
image: nginx:stable-alpine
ports:
- containerPort: 80
name: http
protocol: TCP
env:
- name: MYVAR
value: isAwesome
command: [“/bin/sh”, “-c”]
args: [“echo ${MYVAR}”]](https://image.slidesharecdn.com/kubernetesintroantonioojea-200306171327/85/Kubernetes-Intro-17-320.jpg)
Kubernetes Intro
- 2. Who am I
- 6. Digital Transformation Developers ● Continuous Deployment ● SaaS ● Open Source Sysadmins ● Automated Infrastructure ○ On Premises ○ Cloud Providers ● Virtual vs Real ● SRE: SLAs, SLOs, ... DEVO PS CLO UD INFRA
- 7. Devops
- 9. The “Kubernetes” Phenomenon ● Created by Google engineers based on the internal Google's Borg system ● Kubernetes v1.0 was released on July 21, 2015, donated by Google to the Cloud Native Computing Foundation (Linux Foundation)
- 10. KubeCon + CloudNativeCon Attendance
- 12. Kubernetes is ... A platform for automating: ● deployment, ● scaling, and ● management of containerized applications. It “just” provides the building blocks. Kubernetes is not a platform as a service (PaaS). Kubernetes is not an infrastructure as a service (IaaS). It doesn't dictate many of the important aspects of your desired system
- 13. “Traditional Deployments” ● Automation with “configuration management” frameworks or custom scripts ○ Additional code to maintain ● Packages as main artifacts ○ Dependency nightmare: OS, libraries, language versions, ... ● Developers not involved in deployments “Kubernetes Deployments” ● Declarative deployment ○ Yaml file ○ It can be imperative too ● Containers as main artifacts ○ Self contained ○ Reproducible builds ● Developer directly to production
- 14. Kubernetes Architecture “The entire system can now be described as an unbounded number of independent asynchronous control loops reading and writing from/to a schematized resource store as the source of truth. This model has proven to be very resilient, evolvable, and extensible.” - Brian Grant, co-chair emeritus, SIG-Architecture
- 16. Pods Smallest “unit of work” Represent processes running on the cluster Ephemeral Pods share: ● One or more container ● Volumes ● Namespaces ● Unique network IP ● Running directives
- 17. Key Pod Container Attributes ● name - The name of the container ● image - The container image ● ports - array of ports to expose. Can be granted a friendly name and protocol may be specified ● env - array of environment variables ● command - Entrypoint array (equiv to Docker ENTRYPOINT) ● args - Arguments to pass to the command (equiv to Docker CMD) Container name: nginx image: nginx:stable-alpine ports: - containerPort: 80 name: http protocol: TCP env: - name: MYVAR value: isAwesome command: [“/bin/sh”, “-c”] args: [“echo ${MYVAR}”]
- 19. Drive current state → desired state Observed state is truth ● Open World -- anything can happen Act independently ● event-driven rather than centralized orchestration ● But level-based for fault tolerance observe diff act Control loops
- 20. Workloads ● A Deployment provides declarative updates for Pods and ReplicaSets. ● A ReplicaSet’s purpose is to maintain a stable set of replica Pods running. ● Satefulsets: Manages the deployment and scaling of a set of Pods and provides guarantees about the ordering and uniqueness of these Pods. ● A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. ● A Job creates one or more Pods and ensures that a specified number of them successfully terminate.
- 21. Networking Pod networking ● Pods can communicate with all other containers without NAT. ● Nodes can communicate with all Pods without NAT, and vice-versa. ● The IP that a Pod sees itself as is the same IP that others see it as.
- 22. Services, Load Balancers and Networking Services are an abstract way to expose an application running on a set of Pods. ● ClusterIP ● NodePort ● LoadBalancer ● Ingress
- 23. Services
- 24. Ingress – Name Based Routing apiVersion: extensions/v1beta1 kind: Ingress metadata: name: name-virtual-host-ingress spec: rules: - host: first.bar.com http: paths: - backend: serviceName: service1 servicePort: 80 - host: second.foo.com http: paths: - backend: serviceName: service2 servicePort: 80 - http: paths: - backend: serviceName: service3 servicePort: 80 ● An API object that manages external access to the services in a cluster ● Provides load balancing, SSL termination and name/path-based virtual hosting ● Gives services externally-reachable URLs
- 25. Ingress
- 26. Namespaces Namespaces are a logical cluster or environment, and are the primary method of partitioning a cluster or scoping access. apiVersion: v1 kind: Namespace metadata: name: prod labels: app: MyBigWebApp
- 27. Labels and Selectors Labels are key/value pairs that are attached to objects, such as pods. Selectors use labels to filter or select objects, and are used throughout Kubernetes. apiVersion: v1 kind: Pod metadata: name: pod-label-example labels: app: nginx env: prod spec: containers: - name: nginx image: nginx:stable-alpine ports: - containerPort: 80 nodeSelector: gpu: nvidia
- 28. Configuration Kubernetes allow to separate your configurations from your Pods and components using ConfigMaps and Secrets. ● ConfigMaps are useful for storing and sharing non-sensitive, unencrypted configuration information ● Secrets, ideal for username/passwords, certificates or other sensitive information that should not be stored in a container.
- 29. Storage Pods by themselves are useful, but many workloads require exchanging data between containers, or persisting some form of data. For this we have: ● Volumes ● PersistentVolumes ● PersistentVolumeClaims ● StorageClasses
- 30. Volumes ● Storage that is tied to the Pod’s Lifecycle. ● A pod can have one or more types of volumes attached to it. ● Can be consumed by any of the containers within the pod. ● Survive Pod restarts; however their durability beyond that is dependent on the Volume Type.
- 31. Persistent Volumes ● A PersistentVolume (PV) represents a storage resource. ● PVs are a cluster wide resource linked to a backing storage provider: NFS, GCEPersistentDisk, RBD etc. ● Their lifecycle is handled independently from a pod ● CANNOT be attached to a Pod directly. Relies on a PersistentVolumeClaim
- 32. PersistentVolumeClaims ● A PersistentVolumeClaim (PVC) is a namespaced request for storage. ● Satisfies a set of requirements instead of mapping to a storage resource directly. ● Ensures that an application’s ‘claim’ for storage is portable across numerous backends or providers.
- 33. Example: 3 Tier Application MySQLWordpressnginx
- 35. Kubernetes Ecosystem and CNCF
- 36. Contact
- 37. Q&A