Kubernetes

An Introduction

CC-BY 4.0
Kubernetes v1.10 07/2018
Before We Begin
Requirements:
● Minikube:
https://github.com/kubernetes/minikube
● Virtualbox*:
https://www.virtualbox.org/wiki/Downloads
● kubectl:
https://kubernetes.io/docs/tasks/tools/install-kubectl/
● k8s-intro-tutorials repo:
https://github.com/mrbobbytables/k8s-intro-tutorials
 Kubernetes
An Introduction

CC-BY 4.0
Kubernetes v1.10 05/2018
$ whoami - Bob
Bob Killen
[email protected]
Senior Research Cloud Administrator
CNCF Ambassador
Github: @mrbobbytables
Twitter: @mrbobbytables
$ whoami - Jeff
Jeffrey Sica
[email protected]
Senior Research Database Administrator
Github: @jeefy
Twitter: @jeefy
 Project
Overview
What Does “Kubernetes” Mean?

Greek for “pilot” or

“Helmsman of a ship”

Image Source
What is Kubernetes?
● Project that was spun out of Google as an open source
container orchestration platform.
● Built from the lessons learned in the experiences of
developing and running Google’s Borg and Omega.
● Designed from the ground-up as a loosely coupled
collection of components centered around deploying,
maintaining and scaling workloads.
What Does Kubernetes do?
● Known as the linux kernel of distributed systems.
● Abstracts away the underlying hardware of the
nodes and provides a uniform interface for workloads to
be both deployed and consume the shared pool of
resources.
● Works as an engine for resolving state by converging
actual and the desired state of the system.
What can Kubernetes REALLY do?
● Autoscale Workloads
● Blue/Green Deployments
● Fire off jobs and scheduled cronjobs
● Manage Stateless and Stateful Applications
● Provide native methods of service discovery
● Easily integrate and support 3rd party apps
Most Importantly...

Use the SAME API

across bare metal and
EVERY cloud provider!!!
Who “Manages” Kubernetes?

The CNCF is a child entity of the Linux Foundation and

operates as a vendor neutral governance group.
Project Stats
● Over 38,000 stars on Github
● 1700+ Contributors to K8s Core
● Most discussed Repository by a large
margin
● 41,000+ users in Slack Team

07/2018
Project Stats
 A Couple
Key Concepts...
Pods
● Atomic unit or smallest
“unit of work”of Kubernetes.
● Pods are one or MORE
containers that share
volumes, a network
namespace, and are a part
of a single context.
Pods

They are
also
Ephemeral!
Services
● Unified method of accessing
the exposed workloads of Pods.
● Durable resource
○ static cluster IP
○ static namespaced
DNS name
Services
● Unified method of accessing
the exposed workloads of Pods.
● Durable resource
○ static cluster IP
○ static namespaced
DNS name

NOT Ephemeral!
Architecture
Overview
 Control Plane
Components

Architecture Overview
Control Plane Components

● kube-apiserver
● etcd
● kube-controller-manager
● kube-scheduler
kube-apiserver
● Provides a forward facing REST interface into the
kubernetes control plane and datastore.
● All clients and other applications interact with
kubernetes strictly through the API Server.
● Acts as the gatekeeper to the cluster by handling
authentication and authorization, request validation,
mutation, and admission control in addition to being the
front-end to the backing datastore.
etcd
● etcd acts as the cluster datastore.
● Purpose in relation to Kubernetes is to provide a strong,
consistent and highly available key-value store for
persisting cluster state.
● Stores objects and config information.
etcd
Uses “Raft Consensus”
among a quorum of systems
to create a fault-tolerant
consistent “view” of the
cluster.

https://raft.github.io/
Image Source
kube-controller-manager
● Serves as the primary daemon that
manages all core component control loops.
● Monitors the cluster state via the apiserver
and steers the cluster towards the
desired state.

List of core controllers:

https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-controller-manager/app/controllermanager.go#L332
kube-scheduler
● Verbose policy-rich engine that evaluates workload
requirements and attempts to place it on a matching
resource.
● Default scheduler uses bin packing.
● Workload Requirements can include: general hardware
requirements, affinity/anti-affinity, labels, and other
various custom resource requirements.
 Node
Components

Architecture Overview
Node Components

● kubelet
● kube-proxy
● Container Runtime Engine
kubelet
● Acts as the node agent responsible for managing the
lifecycle of every pod on its host.
● Kubelet understands YAML container manifests that it
can read from several sources:
○ file path
○ HTTP Endpoint
○ etcd watch acting on any changes
○ HTTP Server mode accepting container manifests
over a simple API.
kube-proxy
● Manages the network rules on each node.
● Performs connection forwarding or load balancing for
Kubernetes cluster services.
● Available Proxy Modes:
○ Userspace
○ iptables
○ ipvs (beta in 1.9)
Container Runtime Engine
● A container runtime is a CRI (Container Runtime
Interface) compatible application that executes and
manages containers.
○ Containerd (docker)
○ Cri-o
○ Rkt
○ Kata (formerly clear and hyper)
○ Virtlet (VM CRI compatible runtime)
 Optional
Services

Architecture Overview
cloud-controller-manager
● Daemon that provides cloud-provider specific
knowledge and integration capability into the core
control loop of Kubernetes.
● The controllers include Node, Route, Service, and add
an additional controller to handle things such as
PersistentVolume Labels.
Cluster DNS
● Provides Cluster Wide DNS for Kubernetes
Services.
○ kube-dns (default 1.10)
○ CoreDNS (future default)
Kube Dashboard

A limited, general
purpose web front end
for the Kubernetes
Cluster.
Heapster / Metrics API Server
● Provides metrics for use with other
Kubernetes Components.
○ Heapster (being deprecated)
○ Metrics API (current)
 Networking

Architecture Overview
Kubernetes Networking
● Pod Network
○ Cluster-wide network used for pod-to-pod
communication managed by a CNI (Container
Network Interface) plugin.
● Service Network
○ Cluster-wide range of Virtual IPs managed by
kube-proxy for service discovery.
Container Network Interface (CNI)
● Pod networking within Kubernetes is plumbed via the
Container Network Interface (CNI).
● Functions as an interface between the container runtime
and a network implementation plugin.
● CNCF Project
● Uses a simple JSON Schema.
CNI Overview
CNI Overview
CNI Plugins

● Amazon ECS ● GCE

● Calico ● kube-router
● Cillium ● Multus
● Contiv ● OpenVSwitch
● Contrail ● Romana
● Flannel ● Weave
Fundamental Networking Rules
● All containers within a pod can communicate with each
other unimpeded.
● All Pods can communicate with all other Pods without
NAT.
● All nodes can communicate with all Pods (and
vice-versa) without NAT.
● The IP that a Pod sees itself as is the same IP that
others see it as.
Fundamentals Applied
● Container-to-Container
○ Containers within a pod exist within the same
network namespace and share an IP.
○ Enables intrapod communication over localhost.
● Pod-to-Pod
○ Allocated cluster unique IP for the duration of its life
cycle.
○ Pods themselves are fundamentally ephemeral.
Fundamentals Applied
● Pod-to-Service
○ managed by kube-proxy and given a persistent
cluster unique IP
○ exists beyond a Pod’s lifecycle.
● External-to-Service
○ Handled by kube-proxy.
○ Works in cooperation with a cloud provider or other
external entity (load balancer).
Concepts
and
Resources
 The API
and
Object Model

Concepts and Resources

API Overview

● The REST API is the

true keystone of
Kubernetes.
● Everything within the
Kubernetes is as an
API Object.
Image Source
API Groups
Format:
● Designed to make it
/apis/<group>/<version>/<resource>
extremely simple to
both understand and Examples:

extend. /apis/apps/v1/deployments
/apis/batch/v1beta1/cronjobs
● An API Group is a REST
compatible path that acts as the type descriptor for a
Kubernetes object.
● Referenced within an object as the apiVersion and
kind.
API Versioning
Format:
● Three tiers of API maturity
/apis/<group>/<version>/<resource>
levels.
● Also referenced within the Examples:

object apiVersion. /apis/apps/v1/deployments

/apis/batch/v1beta1/cronjobs

● Alpha: Possibly buggy, And may change. Disabled by default.

● Beta: Tested and considered stable. However API Schema may
change. Enabled by default.
● Stable: Released, stable and API schema will not change.
Enabled by default.
Object Model
● Objects are a “record of intent” or a persistent entity that
represent the desired state of the object within the
cluster.
● All objects MUST have apiVersion, kind, and
poses the nested fields metadata.name,
metadata.namespace, and metadata.uid.
Object Model Requirements
● apiVersion: Kubernetes API version of the Object
● kind: Type of Kubernetes Object
● metadata.name: Unique name of the Object
● metadata.namespace: Scoped environment name that the object
belongs to (will default to current).
● metadata.uid: The (generated) uid for an object.

apiVersion: v1
kind: Pod
metadata:
name: pod-example
namespace: default
uid: f8798d82-1185-11e8-94ce-080027b3c7a6
Object Expression - YAML
● Files or other representations of Kubernetes Objects are generally
represented in YAML.
● A “Human Friendly” data serialization standard.
● Uses white space (specifically spaces) alignment to denote ownership.
● Three basic data types:
○ mappings - hash or dictionary,
○ sequences - array or list
○ scalars - string, number, boolean etc
Object Expression - YAML
apiVersion: v1
kind: Pod
metadata:
name: yaml
spec:
containers:
- name: container1
image: nginx
- name: container2
image: alpine
Object Expression - YAML
apiVersion: v1
kind: Pod Scalar
metadata:
Mapping
Hash name: yaml
Dictionary spec:
containers:
- name: container1
image: nginx
- name: container2
Sequence
image: alpine
Array
List
YAML vs JSON
apiVersion: v1 {
kind: Pod "apiVersion": "v1",
"kind": "Pod",
metadata:
"metadata": {
name: pod-example "name": "pod-example"
spec: },
containers: "spec": {
- name: nginx "containers": [
image: nginx:stable-alpine {
"name": "nginx",
ports: "image": "nginx:stable-alpine",
- containerPort: 80 "ports": [ { "containerPort": 80 } ]
}
]
}
}
Object Model - Workloads
● Workload related objects within Kubernetes
have an additional two nested fields spec
and status.
○ spec - Describes the desired state or
configuration of the object to be created.
○ status - Is managed by Kubernetes and describes
the actual state of the object and its history.
Workload Object Example
Example Object Example Status Snippet
status:
apiVersion: v1 conditions:
kind: Pod - lastProbeTime: null
metadata: lastTransitionTime: 2018-02-14T14:15:52Z

name: pod-example status: "True"

spec: type: Ready

containers: - lastProbeTime: null

lastTransitionTime: 2018-02-14T14:15:49Z
- name: nginx
status: "True"
image: nginx:stable-alpine
type: Initialized
ports: - lastProbeTime: null
- containerPort: 80 lastTransitionTime: 2018-02-14T14:15:49Z
status: "True"
type: PodScheduled
Lab - github.com/mrbobbytables/k8s-intro-tutorials/blob/master/cli

Using the API

(aka, using the CLI)
 ● Namespaces
Core ● Pods
● Labels
Objects ● Selectors
● Services

Concepts and Resources

Core Concepts
Kubernetes has several core building blocks
that make up the foundation of their higher
level components.

Namespaces
Pods Services
Labels Selectors
Namespaces
Namespaces are a logical cluster or environment, and are
the primary method of partitioning a cluster or scoping
access.

apiVersion: v1 $ kubectl get ns --show-labels

NAME STATUS AGE LABELS
kind: Namespace default Active 11h <none>
metadata: kube-public Active 11h <none>
name: prod kube-system Active 11h <none>
prod Active 6s app=MyBigWebApp
labels:
app: MyBigWebApp
Default Namespaces
● default: The default
$ kubectl get ns --show-labels
namespace for any object NAME STATUS AGE LABELS
default Active 11h <none>
without a namespace. kube-public Active 11h <none>
kube-system Active 11h <none>
● kube-system: Acts as
the home for objects and resources created by
Kubernetes itself.
● kube-public: A special namespace; readable by all
users that is reserved for cluster bootstrapping and
configuration.
Pod
● Atomic unit or smallest “unit of
work”of Kubernetes.
● Foundational building block of
Kubernetes Workloads.
● Pods are one or more containers
that share volumes, a network
namespace, and are a part of a
single context.
Pod Examples
apiVersion: v1 apiVersion: v1
kind: Pod
kind: Pod metadata:
name: multi-container-example
metadata: spec:
containers:
name: pod-example - name: nginx
image: nginx:stable-alpine
spec: volumeMounts:
- name: html
containers: mountPath: /usr/share/nginx/html
- name: content
- name: nginx image: alpine:latest
image: nginx:stable-alpine command: ["/bin/sh", "-c"]
args:
ports: - while true; do
date >> /html/index.html;
- containerPort: 80 sleep 5;
done
volumeMounts:
- name: html
mountPath: /html
volumes:
- name: html
emptyDir: {}
Key Pod Container Attributes
● name - The name of the container Container
● image - The container image
name: nginx
● ports - array of ports to expose. image: nginx:stable-alpine
Can be granted a friendly name and ports:
protocol may be specified - containerPort: 80
name: http
● env - array of environment variables protocol: TCP
● command - Entrypoint array (equiv env:
- name: MYVAR
to Docker ENTRYPOINT)
value: isAwesome
● args - Arguments to pass to the command: [“/bin/sh”, “-c”]
command (equiv to Docker CMD) args: [“echo ${MYVAR}”]
Labels
● key-value pairs that are used to
identify, describe and group
together related sets of objects or
resources.
● NOT characteristic of uniqueness.
● Have a strict syntax with a slightly
limited character set*.

* https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set
Label Example
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
Selectors
apiVersion: v1
Selectors use labels to filter kind: Pod
metadata:
or select objects, and are name: pod-label-example
used throughout Kubernetes. labels:
app: nginx
env: prod
spec:
containers:
- name: nginx
image: nginx:stable-alpine
ports:
- containerPort: 80
nodeSelector:
gpu: nvidia
 Selector Example
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
Selector Types
Equality based selectors allow for Set-based selectors are supported
simple filtering (=,==, or !=). on a limited subset of objects.
However, they provide a method of
filtering on a set of values, and
supports multiple operators including:
in, notin, and exist.

selector: selector:
matchLabels: matchExpressions:
gpu: nvidia - key: gpu
operator: in
values: [“nvidia”]
Services
● Unified method of accessing the exposed workloads
of Pods.
● Durable resource (unlike Pods)
○ static cluster-unique IP
○ static namespaced DNS name

<service name>.<namespace>.svc.cluster.local
Services
● Target Pods using equality based selectors.
● Uses kube-proxy to provide simple load-balancing.
● kube-proxy acts as a daemon that creates local
entries in the host’s iptables for every service.
Service Types
There are 4 major service types:
● ClusterIP (default)
● NodePort
● LoadBalancer
● ExternalName
ClusterIP Service
apiVersion: v1
ClusterIP services exposes a kind: Service
service on a strictly cluster metadata:
name: example-prod
internal virtual IP. spec:
selector:
app: nginx
env: prod
ports:
- protocol: TCP
port: 80
targetPort: 80
 Cluster IP Service
Name: example-prod
Selector: app=nginx,env=prod
Type: ClusterIP
IP: 10.96.28.176
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: 10.255.16.3:80,
10.255.16.4:80

/ # nslookup example-prod.default.svc.cluster.local

Name: example-prod.default.svc.cluster.local
Address 1: 10.96.28.176 example-prod.default.svc.cluster.local
NodePort Service
apiVersion: v1
● NodePort services extend the kind: Service
ClusterIP service. metadata:
name: example-prod
● Exposes a port on every spec:
type: NodePort
node’s IP. selector:
app: nginx
● Port can either be statically env: prod
defined, or dynamically taken ports:
- nodePort: 32410
from a range between protocol: TCP
30000-32767. port: 80
targetPort: 80
NodePort Service

Name: example-prod
Selector: app=nginx,env=prod
Type: NodePort
IP: 10.96.28.176
Port: <unset> 80/TCP
TargetPort: 80/TCP
NodePort: <unset> 32410/TCP
Endpoints: 10.255.16.3:80,
10.255.16.4:80
LoadBalancer Service
apiVersion: v1
● LoadBalancer services kind: Service
extend NodePort. metadata:
name: example-prod
● Works in conjunction with an spec:
type: LoadBalancer
external system to map a selector:
cluster external IP to the app: nginx
env: prod
exposed service. ports:
protocol: TCP
port: 80
targetPort: 80
LoadBalancer Service

Name: example-prod
Selector: app=nginx,env=prod
Type: LoadBalancer
IP: 10.96.28.176
LoadBalancer
Ingress: 172.17.18.43
Port: <unset> 80/TCP
TargetPort: 80/TCP
NodePort: <unset> 32410/TCP
Endpoints: 10.255.16.3:80,
10.255.16.4:80
ExternalName Service
apiVersion: v1
● ExternalName is used to kind: Service
reference endpoints metadata:
name: example-prod
OUTSIDE the cluster. spec:
type: ExternalName
● Creates an internal spec:
CNAME DNS entry that externalName: example.com
aliases another.
Lab - github.com/mrbobbytables/k8s-intro-tutorials/blob/master/core

Exploring
the Core
Lab - github.com/mrbobbytables/k8s-intro-tutorials/blob/master/core

Exploring
the Core
 ● ReplicaSet
● Deployment
● DaemonSet
Workloads ● StatefulSet
● Job
● CronJob

Concepts and Resources

Workloads
Workloads within Kubernetes are higher level
objects that manage Pods or other higher level
objects.

In ALL CASES a Pod Template is included,

and acts the base tier of management.
Pod Template
● Workload Controllers manage instances of Pods based
off a provided template.
● Pod Templates are Pod specs with limited metadata.
● Controllers use apiVersion: v1 template:
kind: Pod metadata:
Pod Templates to metadata: labels:
name: pod-example app: nginx
make actual pods. labels: spec:
app: nginx containers:
spec: - name: nginx
containers: image: nginx
- name: nginx
image: nginx
ReplicaSet
● Primary method of managing pod replicas and their
lifecycle.
● Includes their scheduling, scaling, and deletion.
● Their job is simple: Always ensure the desired
number of pods are running.
ReplicaSet
● replicas: The desired apiVersion: apps/v1
kind: ReplicaSet
number of instances of the Pod. metadata:
● selector:The label selector name: rs-example
spec:
for the ReplicaSet will manage replicas: 3
ALL Pod instances that it selector:
targets; whether it’s desired or matchLabels:
app: nginx
not. env: prod
template:
<pod template>
ReplicaSet
apiVersion: apps/v1 $ kubectl get pods
kind: ReplicaSet NAME READY STATUS RESTARTS AGE
metadata: rs-example-9l4dt 1/1 Running 0 1h
name: rs-example rs-example-b7bcg 1/1 Running 0 1h
spec: rs-example-mkll2 1/1 Running 0 1h
replicas: 3
selector: $ kubectl describe rs rs-example
Name: rs-example
matchLabels: Namespace: default
app: nginx Selector: app=nginx,env=prod
Labels: app=nginx
env: prod env=prod
template: Annotations: <none>
Replicas: 3 current / 3 desired
metadata: Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
labels: Pod Template:
app: nginx Labels: app=nginx
env=prod
env: prod Containers:
spec: nginx:
Image: nginx:stable-alpine
containers: Port: 80/TCP
- name: nginx Environment: <none>
Mounts: <none>
image: nginx:stable-alpine Volumes: <none>
ports: Events:
Type Reason Age From Message
- containerPort: 80 ---- ------ ---- ---- -------
Normal SuccessfulCreate 16s replicaset-controller Created pod: rs-example-mkll2
Normal SuccessfulCreate 16s replicaset-controller Created pod: rs-example-b7bcg
Normal SuccessfulCreate 16s replicaset-controller Created pod: rs-example-9l4dt
Deployment
● Declarative method of managing Pods via ReplicaSets.
● Provide rollback functionality and update control.
● Updates are managed through the pod-template-hash
label.
● Each iteration creates a unique label that is assigned to
both the ReplicaSet and subsequent Pods.
Deployment
● revisionHistoryLimit: The number of apiVersion: apps/v1
kind: Deployment
previous iterations of the Deployment to retain. metadata:
name: deploy-example
● strategy: Describes the method of updating spec:
the Pods based on the type. Valid options are replicas: 3
revisionHistoryLimit: 3
RollingUpdate or Recreate. selector:
matchLabels:
○ RollingUpdate: Cycles through app: nginx
env: prod
updating the Pods according to the strategy:
parameters: maxSurge and type: RollingUpdate
rollingUpdate:
maxUnavailable. maxSurge: 1
maxUnavailable: 0
○ Recreate: All existing Pods are killed template:
before the new ones are created. <pod template>
 RollingUpdate Deployment

Updating pod template generates a

new ReplicaSet revision.

R1 pod-template-hash:
676677fff
R2 pod-template-hash:
54f7ff7d6d

$ kubectl get replicaset

NAME DESIRED CURRENT READY AGE
mydep-6766777fff 3 3 3 5h

$ kubectl get pods

NAME READY STATUS RESTARTS AGE
mydep-6766777fff-9r2zn 1/1 Running 0 5h
mydep-6766777fff-hsfz9 1/1 Running 0 5h
mydep-6766777fff-sjxhf 1/1 Running 0 5h
 RollingUpdate Deployment

New ReplicaSet is initially scaled up

based on maxSurge.

R1 pod-template-hash:
676677fff
R2 pod-template-hash:
54f7ff7d6d

$ kubectl get replicaset

NAME DESIRED CURRENT READY AGE
mydep-54f7ff7d6d 1 1 1 5s
mydep-6766777fff 2 3 3 5h

$ kubectl get pods

NAME READY STATUS RESTARTS AGE
mydep-54f7ff7d6d-9gvll 1/1 Running 0 2s
mydep-6766777fff-9r2zn 1/1 Running 0 5h
mydep-6766777fff-hsfz9 1/1 Running 0 5h
mydep-6766777fff-sjxhf 1/1 Running 0 5h
 RollingUpdate Deployment

Phase out of old Pods managed by

maxSurge and maxUnavailable.

R1 pod-template-hash:
676677fff
R2 pod-template-hash:
54f7ff7d6d

$ kubectl get replicaset

NAME DESIRED CURRENT READY AGE
mydep-54f7ff7d6d 2 2 2 8s
mydep-6766777fff 2 2 2 5h

$ kubectl get pods

NAME READY STATUS RESTARTS AGE
mydep-54f7ff7d6d-9gvll 1/1 Running 0 5s
mydep-54f7ff7d6d-cqvlq 1/1 Running 0 2s
mydep-6766777fff-9r2zn 1/1 Running 0 5h
mydep-6766777fff-hsfz9 1/1 Running 0 5h
 RollingUpdate Deployment

Phase out of old Pods managed by

maxSurge and maxUnavailable.

R1 pod-template-hash:
676677fff
R2 pod-template-hash:
54f7ff7d6d

$ kubectl get replicaset

NAME DESIRED CURRENT READY AGE
mydep-54f7ff7d6d 3 3 3 10s
mydep-6766777fff 0 1 1 5h

$ kubectl get pods

NAME READY STATUS RESTARTS AGE
mydep-54f7ff7d6d-9gvll 1/1 Running 0 7s
mydep-54f7ff7d6d-cqvlq 1/1 Running 0 5s
mydep-54f7ff7d6d-gccr6 1/1 Running 0 2s
mydep-6766777fff-9r2zn 1/1 Running 0 5h
 RollingUpdate Deployment

Phase out of old Pods managed by

maxSurge and maxUnavailable.

R1 pod-template-hash:
676677fff
R2 pod-template-hash:
54f7ff7d6d

$ kubectl get replicaset

NAME DESIRED CURRENT READY AGE
mydep-54f7ff7d6d 3 3 3 13s
mydep-6766777fff 0 0 0 5h

$ kubectl get pods

NAME READY STATUS RESTARTS AGE
mydep-54f7ff7d6d-9gvll 1/1 Running 0 10s
mydep-54f7ff7d6d-cqvlq 1/1 Running 0 8s
mydep-54f7ff7d6d-gccr6 1/1 Running 0 5s
 RollingUpdate Deployment

Updated to new deployment revision

completed.

R1 pod-template-hash:
676677fff
R2 pod-template-hash:
54f7ff7d6d

$ kubectl get replicaset

NAME DESIRED CURRENT READY AGE
mydep-54f7ff7d6d 3 3 3 15s
mydep-6766777fff 0 0 0 5h

$ kubectl get pods

NAME READY STATUS RESTARTS AGE
mydep-54f7ff7d6d-9gvll 1/1 Running 0 12s
mydep-54f7ff7d6d-cqvlq 1/1 Running 0 10s
mydep-54f7ff7d6d-gccr6 1/1 Running 0 7s
DaemonSet
● Ensure that all nodes matching certain criteria will run
an instance of the supplied Pod.
● They bypass default scheduling mechanisms.
● Are ideal for cluster wide services such as log
forwarding, or health monitoring.
● Revisions are managed via a controller-revision-hash
label.
DaemonSet
● revisionHistoryLimit: The number of apiVersion: apps/v1
kind: DaemonSet
previous iterations of the DaemonSet to retain. metadata:
name: ds-example
● updateStrategy: Describes the method of spec:
updating the Pods based on the type. Valid revisionHistoryLimit: 3
options are RollingUpdate or OnDelete. selector:
matchLabels:
○ RollingUpdate: Cycles through app: nginx
updateStrategy:
updating the Pods according to the value type: RollingUpdate
of maxUnavailable. rollingUpdate:
maxUnavailable: 1
○ OnDelete: The new instance of the Pod template:
is deployed ONLY after the current spec:
nodeSelector:
instance is deleted. nodeType: edge
<pod template>
DaemonSet
● spec.template.spec.nodeSelector: apiVersion: apps/v1
kind: DaemonSet
The primary selector used to target nodes. metadata:
name: ds-example
● Default Host Labels: spec:
revisionHistoryLimit: 3
○ kubernetes.io/hostname
selector:
○ beta.kubernetes.io/os matchLabels:
○ beta.kubernetes.io/arch app: nginx
updateStrategy:
● Cloud Host Labels: type: RollingUpdate
rollingUpdate:
○ failure-domain.beta.kubernetes.io/zone maxUnavailable: 1
template:
○ failure-domain.beta.kubernetes.io/region spec:
○ beta.kubernetes.io/instance-type nodeSelector:
nodeType: edge
<pod template>
DaemonSet
apiVersion: apps/v1 $ kubectl get pods
kind: DaemonSet NAME READY STATUS RESTARTS AGE
metadata: ds-example-x8kkz 1/1 Running 0 1m
name: ds-example
spec:
revisionHistoryLimit: 3 $ kubectl describe ds ds-example
selector: Name: ds-example
Selector: app=nginx,env=prod
matchLabels: Node-Selector: nodeType=edge
app: nginx Labels: app=nginx
updateStrategy: env=prod
Annotations: <none>
type: RollingUpdate Desired Number of Nodes Scheduled: 1
rollingUpdate: Current Number of Nodes Scheduled: 1
maxUnavailable: 1 Number of Nodes Scheduled with Up-to-date Pods: 1
template: Number of Nodes Scheduled with Available Pods: 1
Number of Nodes Misscheduled: 0
metadata: Pods Status: 1 Running / 0 Waiting / 0 Succeeded / 0 Failed
labels: Pod Template:
app: nginx Labels: app=nginx
spec: env=prod
Containers:
nodeSelector: nginx:
nodeType: edge Image: nginx:stable-alpine
containers: Port: 80/TCP
Environment: <none>
- name: nginx Mounts: <none>
image: nginx:stable-alpine Volumes: <none>
ports: Events:
- containerPort: 80 Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 48s daemonset-controller Created pod: ds-example-x8kkz
StatefulSet
● Tailored to managing Pods that must persist or maintain
state.
● Pod identity including hostname, network, and
storage WILL be persisted.
● Pod lifecycle will be ordered and follow consistent
patterns.
StatefulSet
● Assigned a unique ordinal name following the
convention of ‘<statefulset name>-<ordinal index>’.
● Ordinal pattern is also passed to the Pod’s network
Identity and volumes.
● Revisions are managed via a controller-revision-hash
label
StatefulSet
apiVersion: apps/v1
kind: StatefulSet
<continued>
metadata: spec:
name: sts-example containers:
spec: - name: nginx
replicas: 2 image: nginx:stable-alpine
revisionHistoryLimit: 3 ports:
selector: - containerPort: 80
matchLabels: volumeMounts:
app: stateful - name: www
serviceName: app mountPath: /usr/share/nginx/html
updateStrategy: volumeClaimTemplates:
type: RollingUpdate - metadata:
rollingUpdate: name: www
partition: 0 spec:
template: accessModes: [ "ReadWriteOnce" ]
metadata: storageClassName: standard
labels: resources:
app: stateful requests:
storage: 1Gi
<continued>
StatefulSet
apiVersion: apps/v1
● revisionHistoryLimit: The number kind: StatefulSet
of previous iterations of the StatefulSet to metadata:
name: sts-example
retain. spec:
replicas: 2
● serviceName: The name of the revisionHistoryLimit: 3
associated headless service; or a service selector:
matchLabels:
without a ClusterIP. app: stateful
serviceName: app
updateStrategy:
type: RollingUpdate
rollingUpdate:
partition: 0
template:
<pod template>
StatefulSet
apiVersion: apps/v1
● updateStrategy: Describes the method of kind: StatefulSet
updating the Pods based on the type. Valid metadata:
name: sts-example
options are OnDelete or RollingUpdate. spec:
replicas: 2
○ OnDelete: The new instance of the Pod revisionHistoryLimit: 3
is deployed ONLY after the current selector:
matchLabels:
instance is deleted. app: stateful
serviceName: app
○ RollingUpdate: Pods with an ordinal updateStrategy:
greater than the partition value will be type: RollingUpdate
updated in one-by-one in reverse order. rollingUpdate:
partition: 0
template:
<pod template>
StatefulSet
● volumeClaimTemplates: spec:
containers:
Template of the persistent - name: nginx
image: nginx:stable-alpine
volume(s) request to use for ports:
each instance of the StatefulSet. - containerPort: 80
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: standard
resources:
requests:
storage: 1Gi
 Headless Service
<StatefulSet Name>-<ordinal>.<service name>.<namespace>.svc.cluster.local

apiVersion: v1 / # dig app.default.svc.cluster.local +noall +answer

kind: Service ; <<>> DiG 9.11.2-P1 <<>> app.default.svc.cluster.local +noall +answer
metadata: ;; global options: +cmd
app.default.svc.cluster.local. 2 IN A 10.255.0.5
name: app app.default.svc.cluster.local. 2 IN A 10.255.0.2
spec:
clusterIP: None
selector:
app: stateful / # dig sts-example-0.app.default.svc.cluster.local +noall +answer
ports: ; <<>> DiG 9.11.2-P1 <<>> sts-example-0.app.default.svc.cluster.local +noall +answer
- protocol: TCP ;; global options: +cmd
sts-example-0.app.default.svc.cluster.local. 20 IN A 10.255.0.2
port: 80
targetPort: 80

/ # dig sts-example-1.app.default.svc.cluster.local +noall +answer

$ kubectl get pods
NAME READY STATUS RESTARTS AGE ; <<>> DiG 9.11.2-P1 <<>> sts-example-1.app.default.svc.cluster.local +noall +answer
sts-example-0 1/1 Running 0 11m ;; global options: +cmd
sts-example-1 1/1 Running 0 11m
sts-example-1.app.default.svc.cluster.local. 30 IN A 10.255.0.5
 Headless Service
<StatefulSet Name>-<ordinal>.<service name>.<namespace>.svc.cluster.local

apiVersion: v1 / # dig app.default.svc.cluster.local +noall +answer

kind: Service ; <<>> DiG 9.11.2-P1 <<>> app.default.svc.cluster.local +noall +answer
metadata: ;; global options: +cmd
app.default.svc.cluster.local. 2 IN A 10.255.0.5
name: app app.default.svc.cluster.local. 2 IN A 10.255.0.2
spec:
clusterIP: None
selector:
app: stateful / # dig sts-example-0.app.default.svc.cluster.local +noall +answer
ports: ; <<>> DiG 9.11.2-P1 <<>> sts-example-0.app.default.svc.cluster.local +noall +answer
- protocol: TCP ;; global options: +cmd
sts-example-0.app.default.svc.cluster.local. 20 IN A 10.255.0.2
port: 80
targetPort: 80

/ # dig sts-example-1.app.default.svc.cluster.local +noall +answer

$ kubectl get pods
NAME READY STATUS RESTARTS AGE ; <<>> DiG 9.11.2-P1 <<>> sts-example-1.app.default.svc.cluster.local +noall +answer
sts-example-0 1/1 Running 0 11m ;; global options: +cmd
sts-example-1 1/1 Running 0 11m
sts-example-1.app.default.svc.cluster.local. 30 IN A 10.255.0.5
 Headless Service
<StatefulSet Name>-<ordinal>.<service name>.<namespace>.svc.cluster.local

apiVersion: v1 / # dig app.default.svc.cluster.local +noall +answer

kind: Service ; <<>> DiG 9.11.2-P1 <<>> app.default.svc.cluster.local +noall +answer
metadata: ;; global options: +cmd
app.default.svc.cluster.local. 2 IN A 10.255.0.5
name: app app.default.svc.cluster.local. 2 IN A 10.255.0.2
spec:
clusterIP: None
selector:
app: stateful / # dig sts-example-0.app.default.svc.cluster.local +noall +answer
ports: ; <<>> DiG 9.11.2-P1 <<>> sts-example-0.app.default.svc.cluster.local +noall +answer
- protocol: TCP ;; global options: +cmd
sts-example-0.app.default.svc.cluster.local. 20 IN A 10.255.0.2
port: 80
targetPort: 80

/ # dig sts-example-1.app.default.svc.cluster.local +noall +answer

$ kubectl get pods
NAME READY STATUS RESTARTS AGE ; <<>> DiG 9.11.2-P1 <<>> sts-example-1.app.default.svc.cluster.local +noall +answer
sts-example-0 1/1 Running 0 11m ;; global options: +cmd
sts-example-1 1/1 Running 0 11m
sts-example-1.app.default.svc.cluster.local. 30 IN A 10.255.0.5
 VolumeClaimTemplate
<Volume Name>-<StatefulSet Name>-<ordinal>

volumeClaimTemplates:
- metadata:
Persistent Volumes associated with a
name: www StatefulSet will NOT be automatically
spec:
accessModes: [ "ReadWriteOnce" ] garbage collected when it’s associated
storageClassName: standard StatefulSet is deleted. They must manually
resources:
requests: be removed.
storage: 1Gi

$ kubectl get pvc

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
www-sts-example-0 Bound pvc-d2f11e3b-18d0-11e8-ba4f-080027a3682b 1Gi RWO standard 4h
www-sts-example-1 Bound pvc-d3c923c0-18d0-11e8-ba4f-080027a3682b 1Gi RWO standard 4h
Job
● Job controller ensures one or more pods are executed
and successfully terminate.
● Will continue to try and execute the job until it satisfies
the completion and/or parallelism condition.
● Pods are NOT cleaned up until the job itself is deleted.
Job
● backoffLimit: The number of failures apiVersion: batch/v1
kind: Job
before the job itself is considered failed. metadata:
● completions: The total number of name: job-example
spec:
successful completions desired. backoffLimit: 4
completions: 4
● parallelism: How many instances of the parallelism: 2
pod can be run concurrently. template:
spec:
● spec.template.spec.restartPolicy: restartPolicy: Never
Jobs only support a restartPolicy of <pod-template>
type Never or OnFailure.
Job
apiVersion: batch/v1 $ kubectl describe job job-example
Name: job-example
kind: Job Namespace: default
metadata: Selector: controller-uid=19d122f4-1576-11e8-a4e2-080027a3682b
Labels: controller-uid=19d122f4-1576-11e8-a4e2-080027a3682b
name: job-example job-name=job-example
spec: Annotations:
Parallelism:
<none>
2
backoffLimit: 4 Completions: 4
Start Time: Mon, 19 Feb 2018 08:09:21 -0500
completions: 4 Pods Statuses: 0 Running / 4 Succeeded / 0 Failed
parallelism: 2 Pod Template:
Labels: controller-uid=19d122f4-1576-11e8-a4e2-080027a3682b
template: job-name=job-example
spec: Containers:
hello:
containers: Image: alpine:latest
Port: <none>
- name: hello Command:
image: alpine:latest /bin/sh
-c
command: ["/bin/sh", "-c"] Args:
args: ["echo hello from $HOSTNAME!"] echo hello from $HOSTNAME!
Environment: <none>
restartPolicy: Never Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
$ kubectl get pods --show-all Normal SuccessfulCreate 52m job-controller Created pod: job-example-v5fvq
NAME READY STATUS RESTARTS AGE Normal SuccessfulCreate 52m job-controller Created pod: job-example-hknns
job-example-dvxd2 0/1 Completed 0 51m Normal SuccessfulCreate 51m job-controller Created pod: job-example-tphkm
Normal SuccessfulCreate 51m job-controller Created pod: job-example-dvxd2
job-example-hknns 0/1 Completed 0 52m
job-example-tphkm 0/1 Completed 0 51m
job-example-v5fvq 0/1 Completed 0 52m
CronJob
An extension of the Job Controller, it provides a method of
executing jobs on a cron-like schedule.

CronJobs within Kubernetes

use UTC ONLY.
CronJob
● schedule: The cron schedule for apiVersion: batch/v1beta1
kind: CronJob
the job. metadata:
● successfulJobHistoryLimit: name: cronjob-example
spec:
The number of successful jobs to
schedule: "*/1 * * * *"
retain. successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 1
● failedJobHistoryLimit: The
jobTemplate:
number of failed jobs to retain. spec:
completions: 4
parallelism: 2
template:
<pod template>
CronJob
apiVersion: batch/v1beta1 $ kubectl describe cronjob cronjob-example
kind: CronJob Name: cronjob-example
Namespace: default
metadata: Labels: <none>
name: cronjob-example Annotations: <none>
spec: Schedule: */1 * * * *
Concurrency Policy: Allow
schedule: "*/1 * * * *" Suspend: False
successfulJobsHistoryLimit: 3 Starting Deadline Seconds: <unset>
failedJobsHistoryLimit: 1 Selector: <unset>
Parallelism: 2
jobTemplate: Completions: 4
spec: Pod Template:
completions: 4 Labels: <none>
parallelism: 2 Containers:
hello:
template: Image: alpine:latest
spec: Port: <none>
containers: Command:
/bin/sh
- name: hello -c
image: alpine:latest Args:
command: ["/bin/sh", "-c"] echo hello from $HOSTNAME!
Environment: <none>
args: ["echo hello from $HOSTNAME!"] Mounts: <none>
restartPolicy: Never Volumes: <none>
Last Schedule Time: Mon, 19 Feb 2018 09:54:00 -0500
Active Jobs: cronjob-example-1519052040
Events:
Type Reason Age From Message
$ kubectl get jobs ---- ------ ---- ---- -------
NAME DESIRED SUCCESSFUL AGE Normal SuccessfulCreate 3m cronjob-controller Created job cronjob-example-1519051860
cronjob-example-1519053240 4 4 2m Normal SawCompletedJob 2m cronjob-controller Saw completed job: cronjob-example-1519051860
cronjob-example-1519053300 4 4 1m Normal SuccessfulCreate 2m cronjob-controller Created job cronjob-example-1519051920
Normal SawCompletedJob 1m cronjob-controller Saw completed job: cronjob-example-1519051920
cronjob-example-1519053360 4 4 26s
Normal SuccessfulCreate 1m cronjob-controller Created job cronjob-example-1519051980
Lab - github.com/mrbobbytables/k8s-intro-tutorials/blob/master/workloads

Using Workloads
 ● Volumes
● Persistent
Volumes
Storage ● Persistent
Volume Claims
● StorageClass

Concepts and Resources

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, and StorageClasses.
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.
Volume Types

● awsElasticBlockStore ● flexVolume ● persistentVolumeClaim

● azureDisk ● flocker ● projected
● azureFile ● gcePersistentDisk ● portworxVolume
● cephfs ● gitRepo ● quobyte
● configMap ● glusterfs ● rbd
● csi ● hostPath ● scaleIO
● downwardAPI ● iscsi ● secret
● emptyDir ● local ● storageos
● fc (fibre channel) ● nfs ● vsphereVolume

Persistent Volume Supported

Volumes
● volumes: A list of volume objects to apiVersion: v1
kind: Pod
metadata:
be attached to the Pod. Every object name: volume-example
spec:
within the list must have it’s own containers:
- name: nginx
unique name. image: nginx:stable-alpine
volumeMounts:
- name: html
● volumeMounts: A container specific mountPath: /usr/share/nginx/html
ReadOnly: true
list referencing the Pod volumes by - name: content
image: alpine:latest
name, along with their desired command: ["/bin/sh", "-c"]
args:
mountPath. - while true; do
date >> /html/index.html;
sleep 5;
done
volumeMounts:
- name: html
mountPath: /html
volumes:
- name: html
emptyDir: {}
Volumes
● volumes: A list of volume objects to apiVersion: v1
kind: Pod
metadata:
be attached to the Pod. Every object name: volume-example
spec:
within the list must have it’s own containers:
- name: nginx
unique name. image: nginx:stable-alpine
volumeMounts:
- name: html
● volumeMounts: A container specific mountPath: /usr/share/nginx/html
ReadOnly: true
list referencing the Pod volumes by - name: content
image: alpine:latest
name, along with their desired command: ["/bin/sh", "-c"]
args:
mountPath. - while true; do
date >> /html/index.html;
sleep 5;
done
volumeMounts:
- name: html
mountPath: /html
volumes:
- name: html
emptyDir: {}
Volumes
● volumes: A list of volume objects to apiVersion: v1
kind: Pod
metadata:
be attached to the Pod. Every object name: volume-example
spec:
within the list must have it’s own containers:
- name: nginx
unique name. image: nginx:stable-alpine
volumeMounts:
- name: html
● volumeMounts: A container specific mountPath: /usr/share/nginx/html
ReadOnly: true
list referencing the Pod volumes by - name: content
image: alpine:latest
name, along with their desired command: ["/bin/sh", "-c"]
args:
mountPath. - while true; do
date >> /html/index.html;
sleep 5;
done
volumeMounts:
- name: html
mountPath: /html
volumes:
- name: html
emptyDir: {}
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.
● Generally provisioned by an administrator.
● Their lifecycle is handled independently from a pod
● CANNOT be attached to a Pod directly. Relies on a
PersistentVolumeClaim
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.
 Persistent Volumes and Claims

Cluster Cluster
Users Admins
PersistentVolume
● capacity.storage: The total apiVersion: v1
kind: PersistentVolume
amount of available storage. metadata:
name: nfsserver
● volumeMode: The type of volume, spec:
capacity:
this can be either Filesystem or storage: 50Gi
volumeMode: Filesystem
Block. accessModes:
- ReadWriteOnce
● accessModes: A list of the supported - ReadWriteMany
persistentVolumeReclaimPolicy: Delete
methods of accessing the volume. storageClassName: slow
Options include: mountOptions:
- hard
- nfsvers=4.1
○ ReadWriteOnce nfs:
○ ReadOnlyMany path: /exports
server: 172.22.0.42
○ ReadWriteMany
PersistentVolume
● persistentVolumeReclaimPolicy: apiVersion: v1
kind: PersistentVolume
The behaviour for PVC’s that have been metadata:
name: nfsserver
deleted. Options include: spec:
capacity:
○ Retain - manual clean-up storage: 50Gi
volumeMode: Filesystem
○ Delete - storage asset deleted by accessModes:
provider. - ReadWriteOnce
- ReadWriteMany
persistentVolumeReclaimPolicy: Delete
● storageClassName: Optional name of storageClassName: slow
the storage class that PVC’s can mountOptions:
- hard
reference. If provided, ONLY PVC’s - nfsvers=4.1
nfs:
referencing the name consume use it. path: /exports
server: 172.22.0.42
● mountOptions: Optional mount
options for the PV.
PersistentVolumeClaim
● accessModes: The selected method of kind: PersistentVolumeClaim
apiVersion: v1
accessing the storage. This MUST be a metadata:
subset of what is defined on the target PV name: pvc-sc-example
or Storage Class. spec:
accessModes:
○ ReadWriteOnce - ReadWriteOnce
○ ReadOnlyMany resources:
requests:
○ ReadWriteMany storage: 1Gi
storageClassName: slow
● resources.requests.storage: The
desired amount of storage for the claim
● storageClassName: The name of the
desired Storage Class
PVs and PVCs with Selectors
kind: PersistentVolume kind: PersistentVolumeClaim
apiVersion: v1 apiVersion: v1
metadata: metadata:
name: pv-selector-example name: pvc-selector-example
labels: spec:
type: hostpath accessModes:
spec: - ReadWriteMany
capacity: resources:
storage: 2Gi requests:
accessModes: storage: 1Gi
- ReadWriteMany selector:
hostPath: matchLabels:
path: "/mnt/data" type: hostpath
PVs and PVCs with Selectors
kind: PersistentVolume kind: PersistentVolumeClaim
apiVersion: v1 apiVersion: v1
metadata: metadata:
name: pv-selector-example name: pvc-selector-example
labels: spec:
type: hostpath accessModes:
spec: - ReadWriteMany
capacity: resources:
storage: 2Gi requests:
accessModes: storage: 1Gi
- ReadWriteMany selector:
hostPath: matchLabels:
path: "/mnt/data" type: hostpath
PV Phases
Available Bound Released Failed
PV is ready The PV has The binding An error has
and available been bound to PVC has been been
to be a claim. deleted, and encountered
consumed. the PV is attempting to
pending reclaim the
reclamation. PV.
StorageClass
● Storage classes are an abstraction on top of an external
storage resource (PV)
● Work hand-in-hand with the external storage system to
enable dynamic provisioning of storage
● Eliminates the need for the cluster admin to
pre-provision a PV
 StorageClass
2. StorageClass provisions
request through API with
1. PVC makes a request of external storage system.
the StorageClass.

uid: 9df65c6e-1a69-11e8-ae10-080027a3682b

4. provisioned PV is bound
to requesting PVC.
3. External storage system
creates a PV strictly satisfying
pv: pvc-9df65c6e-1a69-11e8-ae10-080027a3682b
the PVC request.
StorageClass
● provisioner: Defines the ‘driver’ to kind: StorageClass
apiVersion: storage.k8s.io/v1
be used for provisioning of the external metadata:
name: standard
storage. provisioner: kubernetes.io/gce-pd
● parameters: A hash of the various parameters:
type: pd-standard
configuration parameters for the zones: us-central1-a, us-central1-b
provisioner. reclaimPolicy: Delete
● reclaimPolicy: The behaviour for
the backing storage when the PVC is
deleted.
○ Retain - manual clean-up
○ Delete - storage asset deleted by
provider
Available StorageClasses

● AWSElasticBlockStore ● iSCSI
● AzureFile ● PhotonPersistentDisk
● AzureDisk ● Quobyte
● CephFS ● NFS
● Cinder ● RBD
● FC ● VsphereVolume
● FlexVolume ● PortworxVolume
● Flocker ● ScaleIO
● GCEPersistentDisk ● StorageOS
● Glusterfs ● Local

Internal Provisioner
Lab - github.com/mrbobbytables/k8s-intro-tutorials/blob/master/storage

Working with
Volumes
 ● ConfigMap
Configuration ● Secret

Concepts and Resources

Configuration
Kubernetes has an integrated pattern for
decoupling configuration from application or
container.

This pattern makes use of two Kubernetes

components: ConfigMaps and Secrets.
ConfigMap
● Externalized data stored within kubernetes.
● Can be referenced through several different means:
○ environment variable
○ a command line argument (via env var)
○ injected as a file into a volume mount
● Can be created from a manifest, literals, directories, or
files directly.
ConfigMap
apiVersion: v1
data: Contains key-value pairs of kind: ConfigMap
ConfigMap contents. metadata:
name: manifest-example
data:
state: Michigan
city: Ann Arbor
content: |
Look at this,
its multiline!
 ConfigMap Example
All produce a ConfigMap with the same content!

apiVersion: v1 $ kubectl create configmap literal-example \

> --from-literal="city=Ann Arbor" --from-literal=state=Michigan
kind: ConfigMap configmap “literal-example” created
metadata:
name: manifest-example
$ cat info/city
data: Ann Arbor
city: Ann Arbor $ cat info/state
Michigan
state: Michigan $ kubectl create configmap dir-example --from-file=cm/
configmap "dir-example" created

$ cat info/city
Ann Arbor
$ cat info/state
Michigan
$ kubectl create configmap file-example --from-file=cm/city --from-file=cm/state
configmap "file-example" created
 ConfigMap Example
All produce a ConfigMap with the same content!

apiVersion: v1 $ kubectl create configmap literal-example \

> --from-literal="city=Ann Arbor" --from-literal=state=Michigan
kind: ConfigMap configmap “literal-example” created
metadata:
name: manifest-example
$ cat info/city
data: Ann Arbor
city: Ann Arbor $ cat info/state
Michigan
state: Michigan $ kubectl create configmap dir-example --from-file=cm/
configmap "dir-example" created

$ cat info/city
Ann Arbor
$ cat info/state
Michigan
$ kubectl create configmap file-example --from-file=cm/city --from-file=cm/state
configmap "file-example" created
 ConfigMap Example
All produce a ConfigMap with the same content!

apiVersion: v1 $ kubectl create configmap literal-example \

> --from-literal="city=Ann Arbor" --from-literal=state=Michigan
kind: ConfigMap configmap “literal-example” created
metadata:
name: manifest-example
$ cat info/city
data: Ann Arbor
city: Ann Arbor $ cat info/state
Michigan
state: Michigan $ kubectl create configmap dir-example --from-file=cm/
configmap "dir-example" created

$ cat info/city
Ann Arbor
$ cat info/state
Michigan
$ kubectl create configmap file-example --from-file=cm/city --from-file=cm/state
configmap "file-example" created
 ConfigMap Example
All produce a ConfigMap with the same content!

apiVersion: v1 $ kubectl create configmap literal-example \

> --from-literal="city=Ann Arbor" --from-literal=state=Michigan
kind: ConfigMap configmap “literal-example” created
metadata:
name: manifest-example
$ cat info/city
data: Ann Arbor
city: Ann Arbor $ cat info/state
Michigan
state: Michigan $ kubectl create configmap dir-example --from-file=cm/
configmap "dir-example" created

$ cat info/city
Ann Arbor
$ cat info/state
Michigan
$ kubectl create configmap file-example --from-file=cm/city --from-file=cm/state
configmap "file-example" created
Secret
● Functionally identical to a ConfigMap.
● Stored as base64 encoded content.
● Encrypted at rest within etcd (if configured!).
● Ideal for username/passwords, certificates or other
sensitive information that should not be stored in a
container.
● Can be created from a manifest, literals, directories, or
from files directly.
Secret
apiVersion: v1
● type: There are three different types of kind: Secret
secrets within Kubernetes: metadata:
name: manifest-secret
○ docker-registry - credentials type: Opaque
used to authenticate to a container data:
username: ZXhhbXBsZQ==
registry password: bXlwYXNzd29yZA==
○ generic/Opaque - literal values
from different sources
○ tls - a certificate based secret
● data: Contains key-value pairs of
base64 encoded content.
 Secret Example
All produce a Secret with the same content!
apiVersion: v1 $ kubectl create secret generic literal-secret \
> --from-literal=username=example \
kind: Secret > --from-literal=password=mypassword
metadata: secret "literal-secret" created
name: manifest-example
type: Opaque $ cat info/username
data: example
username: ZXhhbXBsZQ== $ cat info/password
mypassword
password: bXlwYXNzd29yZA== $ kubectl create secret generic dir-secret --from-file=secret/
Secret "file-secret" created

$ cat secret/username
example
$ cat secret/password
mypassword
$ kubectl create secret generic file-secret --from-file=secret/username --from-file=secret/password
Secret "file-secret" created
 Secret Example
All produce a Secret with the same content!
apiVersion: v1 $ kubectl create secret generic literal-secret \
> --from-literal=username=example \
kind: Secret > --from-literal=password=mypassword
metadata: secret "literal-secret" created
name: manifest-example
type: Opaque $ cat info/username
data: example
username: ZXhhbXBsZQ== $ cat info/password
mypassword
password: bXlwYXNzd29yZA== $ kubectl create secret generic dir-secret --from-file=secret/
Secret "file-secret" created

$ cat secret/username
example
$ cat secret/password
mypassword
$ kubectl create secret generic file-secret --from-file=secret/username --from-file=secret/password
Secret "file-secret" created
 Secret Example
All produce a Secret with the same content!
apiVersion: v1 $ kubectl create secret generic literal-secret \
> --from-literal=username=example \
kind: Secret > --from-literal=password=mypassword
metadata: secret "literal-secret" created
name: manifest-example
type: Opaque $ cat info/username
data: example
username: ZXhhbXBsZQ== $ cat info/password
mypassword
password: bXlwYXNzd29yZA== $ kubectl create secret generic dir-secret --from-file=secret/
Secret "file-secret" created

$ cat secret/username
example
$ cat secret/password
mypassword
$ kubectl create secret generic file-secret --from-file=secret/username --from-file=secret/password
Secret "file-secret" created
 Secret Example
All produce a Secret with the same content!
apiVersion: v1 $ kubectl create secret generic literal-secret \
> --from-literal=username=example \
kind: Secret > --from-literal=password=mypassword
metadata: secret "literal-secret" created
name: manifest-example
type: Opaque $ cat info/username
data: example
username: ZXhhbXBsZQ== $ cat info/password
mypassword
password: bXlwYXNzd29yZA== $ kubectl create secret generic dir-secret --from-file=secret/
Secret "file-secret" created

$ cat secret/username
example
$ cat secret/password
mypassword
$ kubectl create secret generic file-secret --from-file=secret/username --from-file=secret/password
Secret "file-secret" created
Injecting as Environment Variable
apiVersion: batch/v1 apiVersion: batch/v1
kind: Job kind: Job
metadata: metadata:
name: cm-env-example name: secret-env-example
spec: spec:
template: template:
spec: spec:
containers: containers:
- name: mypod - name: mypod
image: alpine:latest image: alpine:latest
command: [“/bin/sh”, “-c”] command: [“/bin/sh”, “-c”]
args: [“printenv CITY”] args: [“printenv USERNAME”]
env: env:
- name: CITY - name: USERNAME
valueFrom: valueFrom:
configMapKeyRef: secretKeyRef:
name: manifest-example name: manifest-example
key: city key: username
restartPolicy: Never restartPolicy: Never
Injecting in a Command
apiVersion: batch/v1 apiVersion: batch/v1
kind: Job kind: Job
metadata: metadata:
name: cm-cmd-example name: secret-cmd-example
spec: spec:
template: template:
spec: spec:
containers: containers:
- name: mypod - name: mypod
image: alpine:latest image: alpine:latest
command: [“/bin/sh”, “-c”] command: [“/bin/sh”, “-c”]
args: [“echo Hello ${CITY}!”] args: [“echo Hello ${USERNAME}!”]
env: env:
- name: CITY - name: USERNAME
valueFrom: valueFrom:
configMapKeyRef: secretKeyRef:
name: manifest-example name: manifest-example
key: city key: username
restartPolicy: Never restartPolicy: Never
Injecting as a Volume
apiVersion: batch/v1 apiVersion: batch/v1
kind: Job kind: Job
metadata: metadata:
name: cm-vol-example name: secret-vol-example
spec: spec:
template: template:
spec: spec:
containers: containers:
- name: mypod - name: mypod
image: alpine:latest image: alpine:latest
command: [“/bin/sh”, “-c”] command: [“/bin/sh”, “-c”]
args: [“cat /myconfig/city”] args: [“cat /mysecret/username”]
volumeMounts: volumeMounts:
- name: config-volume - name: secret-volume
mountPath: /myconfig mountPath: /mysecret
restartPolicy: Never restartPolicy: Never
volumes: volumes:
- name: config-volume - name: secret-volume
configMap: secret:
name: manifest-example secretName: manifest-example
Lab - github.com/mrbobbytables/k8s-intro-tutorials/blob/master/configuration

Using ConfigMaps
and Secrets
Lab

Putting it all
Together
Where to go
From Here
SIGs
● Kubernetes components and features are
broken down into smaller self-managed
communities known as Special Interest
Groups (SIG).
● Hold weekly public recorded meetings and
have their own mailing lists and slack
channels.
 SIG List

https://github.com/kubernetes/community/blob/master/sig-list.md 5/21/2018
Working Groups
● Similar to SIGs, but are topic focused,
time-bounded, or act as a focal point for
cross-sig coordination.
● Hold scheduled publicly recorded meetings
in addition to having their own mailing lists
and slack channels.
 WG List

https://github.com/kubernetes/community/blob/master/sig-list.md 6/21/2018
Slack
Kubernetes CNCF
slack.k8s.io slack.cncf.io

40,000+ users 3,500+ users

160+ public channels 70+ public channels

7/12/2018
Meetups
Kubernetes CNCF
meetup.com/topics/kubernetes/ meetups.cncf.io

570+ groups 145+ groups

200,000+ members 73,000+ members
30+ countries
7/12/2018
Conventions

China: Europe:
November 14-15, 2018 May 21 – 23, 2010
Shanghai, China North America: Barcelona, Spain
December 11 - 13, 2018
Seattle, WA
6/21/2018
Other Communities
● Official Forum
https://discuss.kubernetes.io
● Subreddit
https://reddit.com/r/kubernetes
● StackOverflow
https://stackoverflow.com/questions/tagged/kubernetes
Links
● Free Kubernetes Courses
https://www.edx.org/

● Interactive Kubernetes Tutorials

https://www.katacoda.com/courses/kubernetes

● Learn Kubernetes the Hard Way

https://github.com/kelseyhightower/kubernetes-the-hard-way

● Official Kubernetes Youtube Channel

https://www.youtube.com/c/KubernetesCommunity

● Official CNCF Youtube Channel

https://www.youtube.com/c/cloudnativefdn

● Track to becoming a CKA/CKAD (Certified Kubernetes Administrator/Application Developer)

https://www.cncf.io/certification/expert/

● Awesome Kubernetes
https://www.gitbook.com/book/ramitsurana/awesome-kubernetes/details
Questions?