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.
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)
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 âconïŹguration
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 ïŹle
â 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 speciïŹed
â 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}â]
18.
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
diïŹ
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 speciïŹed 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
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 ïŹlter
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. ConïŹguration
Kubernetes allow to separate your conïŹgurations from your
Pods and components using ConïŹgMaps and Secrets.
â ConïŹgMaps are useful for storing and sharing non-sensitive, unencrypted
conïŹguration information
â Secrets, ideal for username/passwords, certiïŹcates 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.
â SatisïŹes 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.