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.

1. Kubernetes
Antonio Ojea
aojeagarcia@suse.com

2. Who am I

3. Computing Evolution

4. Application Deployment Evolution

5. Continuous Integration
Continuous Deployment
Feature
Development
Continuous
Integration
Continuous
Deployment

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

8. What’s a container

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

11. Kubernetes is ...

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

15. Kubernetes Components

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

34. Demo: https://github.com/aojea/kubernetes-labs/tree/master/nginx-wordpress-mysql
https://asciinema.org/a/307833

35. Kubernetes Ecosystem and CNCF

36. Contact

37. Q&A