Introduction to Containers - From Docker to Kubernetes and everything in between

1
© 2018 Brent Laster@BrentCLaster
1
Version 1.4
05/22/20

2
2
@BrentCLaster
Prerequisites
▪ Modern system with at least 8G of memory and 20G free storage
▪ VirtualBox installed and running
▪ http://www.virtualbox.org
▪ Virtual machine (.ova file) installed in VirtualBox
▪ https://www.dropbox.com/s/2hqrbtny9qufbfu/ato-ws.ova?dl=0
▪ Or can copy off of one of the USB drives
▪ Workshop docs are in
https://github.com/brentlaster/conf/ato2019
▪ Setup doc is at
▪ https://github.com/brentlaster/conf/blob/master/ato2019/cws-setup.pdf
▪ Labs doc for workshop
▪ https://github.com/brentlaster/conf/blob/master/ato2019/cws-labs.pdf

3
3
Introduction to Containers:
From Docker to Kubernetes and
everything in-between
Brent Laster

4
4
@BrentCLaster
About me
▪ R&D Director
▪ Global trainer – training (Git, Jenkins, Gradle,
Gerriit, Continuous Pipelines)
▪ Author -
▪ OpenSource.com
▪ Professional Git book
▪ Jenkins 2 – Up and Running book
▪ Continuous Integration vs. Continuous Delivery vs.
Continuous Deployment mini-book on Safari
▪ https://www.linkedin.com/in/brentlaster
▪ @BrentCLaster

5
5
@BrentCLaster
Book – Professional Git
▪ Extensive Git reference, explanations, and
examples
▪ First part for non-technical
▪ Beginner and advanced reference
▪ Hands-on labs

6
6
@BrentCLaster
Jenkins 2 Book
▪ Jenkins 2 – Up and Running
▪ “It’s an ideal book for those who are new to
CI/CD, as well as those who have been
using Jenkins for many years. This book will
help you discover and rediscover Jenkins.”
By Kohsuke Kawaguchi, Creator of Jenkins

7
Jenkins X Book
▪ In progress
▪ Early release chapters
available on O’Reilly

8
8
@BrentCLaster
Agenda
▪ Containers, images, and layers
▪ Docker – building/creating/composing images
▪ Kubernetes - clusters/objects/behavior/debugging
▪ Helm – releases/charts
▪ Istio – control/data planes/sidecar proxy/traffic shaping
▪ GitOps – if time allows
▪ Monitoring – if time allows

9
9
What’s in a container?
• A container is a standard
unit of software that
functions like a fully
provisioned machine
installed with all the
software needed to run an
application.
• It’s a way of packaging
software so that
applications and their
dependencies have a self-
contained environment to
run in, are insulated from
the host OS and other
applications - and are
easily ported to other
environments.
• A container is NOT a VM.
A container leverages
several features of the
Linux OS to “carve out” a
self-contained space to
run in. Containers are running instances of images.
Images define what goes into a container.
Containers are built from images.
What are Containers?

10
Benefits of Containers
▪ Easy to create and deploy once image is defined.
▪ Best practices of continuous development, integration, and deployment allow for
frequent and reliable builds and deployments.
▪ Quick/easy rollbacks due to image immutability.
▪ Created at build/release time instead of at deployment time – so applications are
decoupled from the infrastructure.
▪ Provide observability through application health and signals – not just from the
OS.
▪ Because environment is self-contained, runs the same on all infrastructure –
laptop, desktop, cloud, etc.
▪ Portable across any OS or cloud that supports containers.
▪ Manage application instead of infrastructure
▪ Allows applications such as microservices to be loosely coupled, distributed, and
managed and deployed dynamically. Removes the need for monolithic stacks.
▪ Resource isolation and (hopefully) effective utilization.
(Paraphrased from: https://kubernetes.io/docs/concepts/overview/what-is-
kubernetes/)

11
What is a container image?
▪ A container image is a read-only template used to create a
container.
▪ Container images are like a snapshot of a container.
▪ Images are stored in a “registry” – like repository for images.
▪ Images are generally considered to be “immutable”. That is,
once they are created, the image should not be changed. If a
change is needed, a new image should be created.
▪ Immutability does not imply that containers can’t be changed
by configuration or environment, etc.
▪ Container images are built up from layers.
▪ The docker “build” command is used to create images.

12
What is an image layer?
▪ A Docker image is built up from a
series of layers.
▪ Each layer results from an instruction
(modification) in the Dockerfile.
▪ Layers are “stacked” on top of ones
before.
▪ Each layer is only the set of
differences from the last one.
▪ Think of a base layer as being an OS
image.
▪ Each layer is R/O except for last one.
▪ Last/top layer is “container layer”.
▪ Container layer is thin R/W layer.
▪ All changes made to running container
go in that layer.
▪ From https://docs.docker.com/storage/storagedriver/

13
Creating and tracking layers to images
3f00bed1e02a | COPY dir:6a0…
ba16edb35eb9 | mysql:5.5.45
24f4da862742 | ENTRYPOINT["/ent……
19e729dca1ee | CMD["mysqld"]

14
How do layers & images intersect with the
operating system?
▪ Layers can be viewed as single union of all
filesystems - Linux’s Union File System allows
you to stack different file systems and look
through
▪ R/O files can be modified via Copy on Write (cow)
– pulling them up to R/W layer when needed
▪ Other Linux facilities like cgroups and
namespaces help us keep our containers
separate
ccae61fe0274
read-only
}read
write
UNION FILE
SYSTEM
SERVICE
UNION
FILE
SYSTEM
• Layers are basically like files to the O/S
• Image layers are R/O (aka – “immutable”)
• We create a container from an image via the run command. Adds
another layer – a R/W one – changes can be made here (“mutable”)

15
Managing Content Across Containers
▪ Major difference between a container
and an image is the top writeable
layer.
▪ All writes (new content or modifying
content) are stored in the writable
layer.
▪ So multiple containers can share
access to the same underlying image
and yet have their own data.
▪ Layering also simplifies
rebuilding/updating images – only
layers that changed need to be
updated
▪ Layers stored locally on disk (usually
/var/lib/docker)
▪ Docker uses storage drivers to
manage the contents of the image
layers and the writeable layer
▪ From https://docs.docker.com/storage/storagedriver/

16
What is Docker?
▪ (Marketing) From docker.com
An open platform for distributed applications for developers and
sysadmins.
Open source project to ship any app as a lightweight
container
▪ (Technical)
Thin wrapper around Linux Container technology
Leverages 3 functionalities from Linux to provide isolated
environment in the OS
» union filesystem - data
» namespaces - visibility (pid)
» cgroups - control groups (resources)
▪ Provides restful interface for service
▪ Provides description format for containers
▪ Provides API for orchestration

17
How Containers from Docker differ from VM
▪ A VM requires a Hypervisor
and a Guest OS to create
isolation; Docker uses Linux
container technologies to run
processes in separate
spaces on the same OS
▪ Because it doesn’t require
the Hypervisor and a Guest
OS, Docker is:
▪ Faster to startup
▪ More portable (can run an
image unchanged in
multiple environments)
Server
Host OS
Docker
RuntimeRuntime
App 1 App 2
App 1 App 2
Server
Host OS
Hypervisor (such as
Virtual Box)
GuestOS
GuestOS
Runtime Runtime
VM Environment Docker Environment
Virtual
Machine
Container

18
What is a Dockerfile?
▪ Way to create a Docker
image ( a plan)
▪ A text file that contains (in
order) all of the instructions
to build an image
▪ Has a specific format and
structure
▪ Each instruction in a
Dockerfile can create a
read-only layer

19
19
@BrentCLaster
Dockerfile to Image to Container
Build Run

20
Docker Commands

21
About Docker Tags
▪ Docker tags are user-friendly aliases for the “hex” ids of generated images
▪ Way of referring to an image
▪ Like how Git tags refer to particular commits
▪ Two general ways to create a tag
▪ Via docker build
» docker build –t IMAGE_NAME[:TAG] .
docker build -t roar-db:v1 .
▪ Via tag command
» docker tag IMAGE_ID IMAGE_NAME[:TAG]
docker tag 19e729dca1ee roardb:v1.1
» docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]
docker tag roar-db:v1.1 roar-db:prod
▪ Tagging for private registries
▪ Private repositories run on a REGISTRYHOST
» Example: localhost:5000
▪ Need to tag image with REGISTRYHOST info
» docker tag [OPTIONS] IMAGE[:TAG] [REGISTRYHOST/][USERNAME/]NAME[:TAG]
docker tag roar-db:v1.1 localhost:5000/roar-db:v1.1
▪ Using “:latest” tag
▪ “latest” does NOT mean most recent – it means “default”
▪ “latest” = default tag if tag not explicitly specified
▪ Avoid it and use meaningful tags instead

22
22
How do we think about this?
▪ Consider analogy of installing software on a
machine…
▪ And then provisioning systems for users
User R/W
User R/W

23
Docker Commands
▪ https://devhints.io/docker

24
24
Lab 1: Building Docker Images

25
How do we work with multiple containers?
▪ Docker compose tool allows us to start containers
together
▪ Uses service specifications in docker-compose.yml file
▪ Simplifies running multiple containers that need to be
“linked” together
▪ Composing containers together is essentially a 3-step
process
▪ Create needed Dockerfiles for each part of app
▪ Define services that make up the app in a docker-
compose.yml file
▪ Run docker-compose up and it starts and runs your
app
▪ Docker run
▪ Could also use docker run command in extended
form with –link option
▪ Docker stack
▪ Command in Docker CLI - lets you mange cluster
of containers via Swarm (competitor to Kubernetes)
▪ Can also leverage docker-compose.yml file
▪ Kubernetes or Kubernetes Environments

26
Overall Docker Flows
▪ Docker images are stored in a registry
▪ A Dockerfile describes how to create a new image
▪ docker build creates the new image
▪ docker run starts up a container with an image
▪ A docker compose file describes how to create containers and link multiple ones together
▪ docker-compose executes a compose file and runs the unit
Registry
Image 1
Image 2
Image 3
Image 4
Host System
OS
D
o
c
k
e
r
Container 1
Container 2
Dockerfile
FROM …..
COPY….
RUN…
Image A
Image A
Image B
Compose.yml
IMAGE
A…..
IMAGE B….
LINK…
-{

27
Our Example App
▪ Simple app with two
pieces
▪ Webapp on the front
▪ Mysql database on the
backend
▪ Written in Java
▪ Simple REST API
▪ War file is produced for
webapp
▪ Managed in Tomcat
▪ R.O.A.R. (Registry of Animal Responders)

28
Docker Commands
▪ https://devhints.io/docker & https://www.mankier.com

29
Open Container Initiative (OCI)

30
Other Players in the Container Space

31
31
Lab 2: Composing Images Together

32
Debugging Docker containers
▪ Identify container that is problem
▪ Gather information about state - docker inspect
▪ Gather information about what’s happened - docker
logs
▪ Verify assumptions, such as what ports are exposed –
docker port
▪ See what’s gone into image - docker history
▪ Actually connect into container’s filesystem -- docker
exec
▪ How to tell what’s going on – one approach

33
Docker Inspect
▪ https://docs.docker.com/engine/reference/commandlin
e

34
Docker Logs
▪ https://docs.docker.com/engine/reference/commandline

35
Docker Port

36
Docker History

37
Docker Exec

38
What is a Docker Registry?
▪ Place to store Docker
images
▪ Push or pull from
▪ Can be public or private
▪ Can be secure or insecure
▪ Public Docker registry is
default (hub.docker.com)
▪ Private registries
- Hosted at some
path:port
- Require images to be
tagged with host info
(path:port) in their
name to let Docker
understand which
registry to work with
- Example: if registry is
at localhost:5000 then
image should be
localhost:5000/myimag
e and not just myimage

39
Docker Stop

40
Docker rm

41
Docker rmi

42
42
Lab 3: Debugging Docker Containers

43
43
@BrentCLaster
What is Kubernetes?
▪ A portable, extensible platform for managing containerized workloads and services
(cluster orchestration system)
▪ Name derived from Greek for helmsman, thus the icon
▪ Frequently abbreviated as “k8s”
▪ Formerly known as “borg” – an internal Google project
▪ Open-sourced by Google in 2014
▪ Groups containers that make up an application into logical units for easy
management and discovery.
▪ Goal is to provide a robust platform for running many containers.
▪ Allows automation of deployment, scaling, and managing containerized workloads.
▪ Kubernetes provides you with a framework to run distributed systems (of containers)
resiliently.
▪ Takes care of
▪ scaling requirements
▪ failover
▪ deployment patterns

44
44
@BrentCLaster
So how do we think about this?
▪ Analogy: Datacenter for containers
▪ If we think of images/containers as
being like computers we stage and use
▪ We can think of Kubernetes as being
like a datacenter for those containers
▪ Main jobs of datacenter
» Provide systems to service needs
(regardless of the applications)
» Keep systems up and running
» Add more systems / remove
systems depending on load
» Deal with systems that are having
problems
» Deploy new systems when needed
- Provide simple access to pools of
systems
- Etc..

45
45
@BrentCLaster
Kubernetes is everywhere
▪ Has effectively “won the war”
over other competitors
▪ Docker swarm
▪ Mesos
▪ Cloud providers all endorse it
and provide ways to get a
Kubernetes cluster
▪ Implementations on other
enterprise platforms

46
Kubernetes Features
▪ Service discovery and load-balancing
▪ Automated rollouts and rollbacks
▪ Storage orchestration
▪ Batch execution
▪ Self healing
▪ Secret and configuration management
▪ Horizontal scaling
▪ Automatic bin packing

47
47
@BrentCLaster
K8s Quick Terminology
▪ Cluster - an HA set of computers coordinated by k8s to work as a unit.
▪ Pods – object that contains and manages one or more containers and any
attached volumes
▪ Service – abstraction that groups together pods based on identifiers called
labels (or other characteristic)
▪ Deployment – defines a stateless app with a set number of pod replicas
(scaled instances)
▪ Ingress – resource that lets cluster applications be exposed to external traffic
▪ Namespace - a logical area that groups k8s items like pods

48
48
@BrentCLaster
Kubernetes Clusters
▪ A k8s cluster is an HA set of
computers coordinated by k8s
to work as a unit.
▪ Abstractions we have in k8s
allow you to deploy containers
in the cluster w/o tying them to
a specific host.
▪ K8s automates distribution and
scheduling of containers across
cluster in an efficient manner.
▪ Nodes in a cluster are either
▪ master – coordinates the work
▪ nodes – run the applications
▪ Simplest example is a one node
cluster, such as minikube
▪ Kubernetes is about clusters

49
49
@BrentCLaster
What is minikube?
▪ Minikube is a simple program to learn about or work with
small k8s deployments
▪ Creates a VM on your local machine
▪ Deploys a cluster containing only one node
▪ Has a CLI that starts and stops it, etc.
▪ Otherwise behaves like standard k8s

50
Config
Worker
Cluster Overview
etcd
API server
Controller Manager
kubectl
PodPod Pod Pod Pod
Kube-proxy Kubelet Kubelet Kube-proxy
Master
Worker
Scheduler
Container Network Interface (CNI) Calico FlannelWeave
Image
Registry

51
How are containers organized on K8S?
▪ K8s clusters have nodes
▪ Nodes run pods
▪ Pods are wrapped around
one or more containers
▪ Pods are front-ended by
services
▪ Pods are scaled (replicated)
by deployments
▪ Namespaces group objects
like pods, services,
deployments together

52
Pod
▪ Smallest deployable unit in Kubernetes
▪ Represents a group of one or more
containers and any shared resources,
such as
▪ Volumes
▪ Unique Cluster IP address
▪ Pods are scheduled on nodes
▪ Usually automatically by master
▪ Can specify nodes to run on with selector
▪ Scheduling takes into account node’s
resources
▪ Containers should only be scheduled
together if they are tightly couple and
need to share resources such as disk
▪ Pod is scheduled and runs on a node
▪ https://kubernetes.io/docs/tutorials/kube
rnetes-basics/explore/explore-intro/

53
Namespaces
▪ Unique working area within cluster
▪ provide a logical partition of the cluster’s resources
▪ kubernetes resources are scoped to a namespace
▪ all resources within a namespace must have unique names
▪ kubernetes allows for assigned quotas for resource limitations
within a namespace
▪ namespace of default is used if none other is specified
▪ Object is abbreviated as “ns”
▪ Option is “-n” to select other than current one
▪ Can set context to change current one
▪ https://www.joshdurbin.net/posts/2018-04-kubernetes-basics/

54
What is kubectl?
▪ Kubectl is the command line interface for running commands against k8s clusters
▪ Different pronunciations – usually either “kube control” or “kube cuttle” or “kube cuddle”
▪ Uses a “kube config” file to understand which cluster to work against and any necessary
configuration information (kube config file may be sharable to other instantiations)
▪ Basic syntax is : kubectl [command] [TYPE] [NAME] flags
▪ command describes operation to do on one or more resources (such as get,
describe, logs, create, apply, delete, etc.)
▪ TYPE is resource type – case insensitive – can specify the singular, plural,
or abbreviate forms (kubectl get pod = kubectl get pods = kubectl get po)
▪ NAME is the case-sensitive name of a resource (kubectl get pod ABC)
» If no name, gets information for all resources
▪ flags – optional flags
▪ Examples:
» kubectl get - get basic information about existence of objects
» kubectl apply – create/update applications from files defining resources
» kubectl create - create a new object
» kubectl describe – get detailed info about current state of an object
» kubectl delete – delete an object

55
Kubectl Command Line Syntax
▪ Resources can be referred to with
separate resource and name
▪ kubectl describe pod mypod-name
▪ Syntax from kubectl get <type>
▪ Resources can be referred to with
resource/name syntax
▪ kubectl describe pod/mypod-name
▪ This syntax will be returned from a
kubectl get all
▪ Options can be in different
locations
▪ kubectl -n <namespace> get all
▪ kubectl get all –n <namespace>
▪ Can use different forms of
resource type names
▪ singular, plural, abbreviations (ex:
pod, pods, po)
▪ Abbreviations exist for most
resources
▪ po = pod, svc = service, deploy =
deployment, etc.

56
YAML and K8S specifications
▪ YAML is a type of markup language to define Kubernetes specs for resources
▪ Stored in .yaml or .yml text file
▪ Kubectl apply can take such a file as input and update cluster based on specs
▪ Turns yaml specs into resources/objects running in cluster
▪ Kubectl get –o yaml can be used to dump out spec and status as yaml from
running object
▪ Conventional block format uses a
hyphen + space to denote a new item in
a list
▪ Keys are separated from values by a
colon + space; indented blocks use
indentation and newlines to separate
key-value pairs
▪ Strings do not (generally) require
quotation marks
▪ Data structure hierarchy is maintained
by outline indentation

57
Understanding Kubernetes Objects
▪ To work with k8s objects, you use the k8s API
▪ Kubectl command-line tool makes calls to API for you
▪ Could also use k8s api client libraries
▪ K8s objects are persistent entities in the k8s system.
▪ K8s uses these entities to represent the state of the cluster.
▪ They can describe:
» What application containers are running and on which nodes.
» Resources available to applications.
» Policies around how those applications behave.
▪ Kubernetes object is “record of intent”
▪ After creation, k8s will work to ensure object exists
▪ Creating an object declares what you want cluster workload to look like
▪ Known as cluster’s “desired state”
▪ Declarative model vs. imperative model

58
Kubernetes is a Desired-State System
▪ User supplies desired state via declaring it in manifests
▪ Kubernetes works to balance the current state and the
desired state
▪ Desired state – what you want your production environment to be
▪ Current (observed) state – current status of your production
environment
Desired state
Current (Observed)
state
Kubernetes
Reconciliation
loop

59
Defining a Kubernetes Object in text
▪ When creating an object in k8s, have to
provide
▪ object spec to describe desired
▪ basic info, such as a name
▪ K8s API expects info as JSON in body of
request
▪ But, usually provide it from YAML file
▪ Kubectl command line converts to JSON
for you
▪ Required fields
▪ apiVersion – which version of the k8s API is
being used to create the object
▪ kind - what kind of object to create
▪ Metadata - data that helps uniquely identify the
object, such as name, UID, namespace
(optional)
▪ Ojbect’s spec
» Format different for every k8s object
» Contains nested fields specific to the object
» Can find details on specs in the API
reference
https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-
objects/

60
Kubernetes Objects - Spec and Status
▪ Every running k8s
object includes two
nested object fields
▪ spec
» User-provided
» Describes desired
state for the object
▪ status
» Provided and
updated by k8s
system
» Describes the
actual state of the
object

61
Selectors/Labels
▪ Labels are the mechanisms we use to organize
Kubernetes obects.
▪ Label is a key-value pair without any pre-defined
meaning.
▪ Kubectl get has option “--show-labels” to show
labels from objects
▪ Can add label to object with “kubectl label”
command
▪ We can filter based on a label
▪ --selector is long form of option
▪ -l is short form
▪ Most k8s objects support set-based selectors
(choosing which items based on a set to select
from). If we have pods from upper left, then we
can do:
▪ Labels can apply to other objects, such as
nodes and services
▪ Types: “Equality-based” (=, !=) “Set-based” ( in
())
http://kubernetesbyexample.com/labels/

62
Deployments
▪ A deployment can be
thought of as a
“supervisor” for pods.
▪ Once deployed, can see
the deployment, the
replicaset, and the pods
▪ Naming of the pods and
replicaset are derived
from the deployment
name
▪ http://kubernetesbyexampl
e.com/deployments/
▪ Spinning Up Pods

63
Deployments
▪ What happens if we make a significant change (update version to 1.0)
and apply it to the running instance?
▪ kubectl apply -f d10.yaml deployment "sise-deploy“
▪ Pods with old versions are terminated and new ones created with the
updated version
▪ And new replicaset is created
▪ http://kubernetesbyexample.com/deployments/
▪ Updating Pods

64
Deployments vs. Pods
▪ Using Pods without Deployments
Pod
K8S Node
Namespace
8080
kubectl
8080
▪ Objects run within node and
namespace
▪ Objects created from spec
▪ Pods encompass containers
▪ Ways to connect directly to them
▪ If pod goes away (and still need
functionality), must manually start a
new one
▪ Different ip address on new one

65
Deployments vs. Pods
▪ Pods with Deployments
Pod
Kubernetes
Namespace
80808080
kubectl
Deployment
10Replica Set
▪ Deployments include both a
replicaset and pods
▪ Specs for both
▪ If pod goes away, replicaset
starts up a new one automatically
– up to number of replicas
specified
▪ Different ip address on new one

66
Services
▪ Service in Kubernetes provides a level of
abstraction for pods
▪ Pods may be “volatile” so can’t rely on their
respective IP addresses to connect to long-term
▪ A service provides a virtual, consistent IP to
connect to for a set of pods
▪ Pods can be selected by labels
▪ Virtual IP of a service is not connected to an
actual network interface
▪ Rather, it exists to forward traffic to one or more
pods g an initial deployment or update, you can
check status with
“kubectl rollout status deploy/<name>
▪ Kube-proxy process (running on every node) is
responsible for keeping the mapping between
the virtual IP and the pods up-to-date
▪ Kube-proxy queries the API server to learn about
new services
▪ http://kubernetesbyexample.com/services/
▪ Providing a virtual, stable connection for not-so-stable pods

67
Services
▪ Without Services
Pod
K8S Node
Namespace
8080
Deployment
2
Pod
8080
IP
172.17.0.21
IP
172.17.0.228080
IP
172.17.0.23
8080
1Replica Set
▪ We can connect to
individual pods (if
allowed)
▪ If in deployment and pod
goes away, we lose
access to that pod
▪ ReplicaSet in deployment
will spin up another one
but won’t have same
address
▪ Similar situation if a pod
becomes unusable
▪ - may have other pods
that could handle needs,
but no way to
automatically discover or
connect

68
Services
▪ With a service
name= roar-web
K8S Node
Namespace
8080
Deployment
2
name=roar-web
8080
IP
172.17.0.21
IP
172.17.0.228080
IP
172.17.0.23
8080
Service31789
NodeIP
8089
1Replica Set
Endpoints
Selector:
name = roar-web
IP 172.17.0.23
IP 172.17.0.21
IP 172.17.0.22
▪ Service provides virtual
address for us to
connect to for frontend
▪ Uses labels to select
“pool” of backend pods
to map to
▪ Endpoints for a service
are list of available ip
addresses for usable
pods
▪ Example service here
is NodePort
▪ If one pod goes down
or becomes
unavailable, service
can connect to another
pod
▪ Spec is shown below

69
Types of Services
▪ ClusterIP
▪ Default K8S service
▪ Provides service inside cluster for
other apps in cluster to access
▪ No external access (except via
kubectl proxy for debugging, etc.)
▪ NodePort
▪ Most basic way to get external traffic
to service
▪ Opens up a port on the K8S node
▪ Any traffic going to that port on the
node is forwarded to the service
▪ Uses node IP address
▪ Only ports in range 30000-32767
▪ LoadBalancer
▪ Gives you Load Balancer with single
IP that forwards all traffic to service
▪ Default method for directly exposing
a service
▪ No filtering, no routing
▪ Cost factor on clouds
▪ ExternalName
▪ Maps service to contents of an
external name field (foo.bar.com)
▪ Returns a CNAME record with that
value
port
Serviceport
port
port
Serviceport
port
port
Serviceport
port
External
Traffic
Internal
Traffic
ClusterIP
NodePort
Cluster
Namespace
NodeCluster
NamespaceNamespace
LoadBalancer
External
Traffic
node
port
Network
Load
Balancer

70
▪ Container in a pod ~ server in a rack
▪ Pod ~ rack of servers
▪ Deployment ~ multiple racks (replicas)
Data Center Analogy
70
▪ Functions: Uptime, scaling, redundancy…
▪ Service ~ central control /
login server
▪ Namespace ~ server room
Service

71
Other K8S Objects
▪ ConfigMaps
▪ Alternatives to hard-coding data or using environment variables
▪ Could specify environment variables in Dockerfile or k8s yaml file
▪ Bad part of environment variables is they are tied to container or
deployment.
▪ To change them, must modify container or redo deployment.
▪ Data must also be duplicated across objects.
▪ https://medium.com/google-cloud/kubernetes-configmaps-and-
secrets-68d061f7ab5b
▪ Alternative is secrets for confidential data and configmaps for non-
confidential data
▪ Difference between Secrets and ConfigMaps are that Secrets are
obfuscated with a Base64 encoding.
▪ Can be created like any other objects in Kubernetes.

72
Configmaps and Secrets
▪ Environment variables set up in spec
▪ Create secret for API Key
▪ Could specify environment variables in
▪ Create configmap for language
▪ To change them, must modify container
▪ Update spec to use those
▪ https://medium.com/google-cloud/kubernetes-configmaps-and-secrets-68d061f7ab5b
▪ Ways to store key-value information and obfuscate info

73
Persistence: Volumes and Claims
▪ Container filesystem
▪ Container level
▪ Ephemeral (if container goes away, changes made while it was
running are lost)
▪ Volume
▪ Data storage defined at the pod level
▪ Uses:
» Preserve data across container crashes
» Provide a means to share data across containers in a pod
▪ Has same lifecycle as enclosing container – deletion of pod delete
the volume
▪ Persistent Volume
▪ Llifecycle independent of any pod
▪ Persistent Volume Claim
▪ Defines specific amount of storage requested
▪ Define s specific access modes
▪ Kubernetes finds a specific matching Persistent Volume and
matches it to claim
▪ PVC’s have different access modes they can specify
» ReadWriteOnce – one bound Pod with R/W access
» ReadOnlyMany – many bound Pods with R only access
» ReadWriteMany – many bound Pods with R/W access
https://www.joshdurbin.net/posts/2018-04-kubernetes-basics/
▪ Definition

74
74
Lab 4: Exploring and Deploying into
Kubernetes

75
What is Helm?
▪ Like yum, apt but for K8s
▪ Bundles related manifests (such as deployment.yaml,
sevice.yaml, etc.) into a “chart”
▪ When installing chart, Helm creates a “release”
▪ Lifecycle management
▪ Create, Install, Upgrade, Rollback, Delete, Status, Versioning
▪ Benefits
▪ Templating, Repeatability, Reliability, Multiple Environment, Ease
of collaboration
▪ Package Manager and Lifecycle Manager for K8s

76
Why do we need something like this?
▪ Scale and complexity
▪ Microservice = Pod + Deployment+ ReplicationSet +
Ingress + Service times # of microservices
▪ Duplication of values across objects
▪ Hard to override values
▪ Managing lifecycle of all the objects is challenging

77
Helm Components
▪ Helm is the client
▪ Command line client
▪ Interacts with Tiller
server
▪ Does local chart
development
▪ Tiller is the server
▪ Resides In-cluster
▪ Listens to the Helm
client
▪ Interacts with the
Kubernetes API server
▪ Manages the lifecycle
Helm
(Client)
Cluster
Tiller
(Server)
K8S API
ServerREST

78
Helm Charts
▪ Collection of k8s resource definition
files inside a directory
▪ Can deploy simple and complex
applications
▪ Most files can be “templated”
» Go template variations
▪ Values to instantiate in templates
come from values.yaml or command
line overrides
▪ _helpers.tpl is a helper template file
that can define “functions”
▪ Can have directories of chart
directories
▪ Application Deployment Blueprints

79
Helm Topology
▪ Chart – a package; a bundle of K8s resources
▪ Release – a chart instance loaded into K8s
» Same chart can be installed several times into the same cluster
» Each such chart will have its own release
▪ Repository – a repository of published charts
▪ Template - a K8s configuration file mixed with Go/Sprig templates

80
Helm Operations
▪ Helm init – install Tiller to running cluster – will setup any
necessary local configuration
▪ Helm create – create a new chart
▪ Helm delete – given a release name, delete the release from
Kubernetes ( use --purge to remove release completely)
▪ Helm install – install a chart
▪ Helm lint – check a chart for issues
▪ Helm list – list releases of charts installed
▪ Helm rollback – rollback a release to a previous revision
▪ Helm status – check status of objects deployed with a helm
release
▪ Helm template – Locally render templates
▪ Helm upgrade – upgrade a release (--recreate-pods option if
needed)

81
Helm Charts
▪ The Go templating language
▪ Template directives look for values
and insert them
▪ A template directive is enclosed in
{{ }}
▪ Values passed into a template can
be thought of as “namespaced”
where a “.” separates each
element
▪ A leading dot means start at
topmost level
▪ So .Release.Name = “start at top
of namespace, look for a “Release”
object and then find the “Name”
element inside
▪ Certain items, such as “Release”
are built –in
▪ Can do dry-run to see rendered
version
▪ Templating Language
Values file
Template file
Rendered file

82
Helm Charts
▪ Allow you to override values
easily
▪ Overrides can come from
» Child charts
» Additional values files
» Command-line values
▪ --set has a higher precedence
than the values.yaml file
▪ Values can also be structured
▪ Lower scoping requires more
levels (more “.”s)
https://helm.sh/docs/chart_template_
guide/
Templates fileValues file

83
Helm Charts
▪ Also can use “functions” and “pipelines”
in templates
▪ Functions
» Transform data values in a way to
make them more useful
» Ex: drink: {{ quote
.Values.favorite.drink }}
» Calling quote function and passing
1 argument
» Helm has over 60 built-in functions
from Go template language or Sprig
templates
▪ Pipelines = “|”
» Lets you chain functions together
» See example to right
https://helm.sh/docs/chart_template_guide/
Values file
Templates file
Rendered file

84
Helm Initialize Cluster
▪ Installs tiller; setups any necessary configuration
API server
Tiller
(pod)
Cluster
helm init

85
Helm Install a Chart
▪ helm install <chart>
Cluster
helm install
<chart> --name
Foo
Tiller
(pod)
Service
A
Deployment
A
Ingress
A
Release Foo 1
API server

86
Helm Upgrading a Chart
Cluster
helm upgrade Foo
<chart>
Service
A
Deployment
A
Ingress
A
Release Foo 2
▪ helm upgrade <release> <chart>
Deployment
B
Tiller
(pod)
API server

87
Deployment
B
Helm Rollback
Cluster
helm rollback Foo
1
Service
A
Deployment
A
Ingress
A
Release Foo 3
▪ helm history <release> (to see revision numbers)
▪ helm rollback <release> <revision>
Tiller
(pod)
API server

88
88
Lab 5: Using Helm

89
Init Containers
▪ In addition to having
multiple containers, pods
can have 0 to many “init
containers”
▪ Init containers
▪ Run at startup (before
other containers)
▪ Run serially
▪ Must all exit cleanly in
order for the regular
containers to begin
execution
https://www.joshdurbin.net/posts/2018-04-
kubernetes-basics/

90
Istio is a Service Mesh. What is a service
mesh?
▪ Lets you connect, secure, and control services.
▪ Example of a service mesh : network of microservices and interactions between
them.
▪ Typical service mesh functions: discovery, load balancing, failure recovery,
metrics, monitoring, A/B testing, canary rollouts, rate-limiting, access control,
end-to-end authentication.
▪ Requires few or no changes to service code.
▪ Add istio support as a sidecard proxy – additional container in your pod.
▪ Intercepts all network traffic between microservices.Containers within a pod can
find each other via localhost.
https://istio.io/docs/concepts/what-is-istio/
▪ Open Platform to connect, monitor, and secure microservices

91
How does Istio work?
▪ Istio deploys an Istio proxy (called an Istio sidecar) next to each service
▪ All of the traffic meant for a service is directed to the proxy
▪ Proxy uses policies to decide how, when, or if that traffic should be
deployed to the service
▪ Also enables sophisticated techniques such as canary deployments,
fault injections, and circuit breakers
▪ Istio runs in a Linux container in the Istio Kubernetes pods using an
Istio sidecar implementation and when required injects and extracts
functionality and information based on the configuration needed.
▪ https://itnext.io/istio-service-mesh-the-step-by-step-guide-
adf6da18bb9a

92
Istio Architecture
▪ The data plane is composed of a set of intelligent
proxies (Envoy) deployed as sidecars. These proxies
mediate and control all network communication between
microservices along with Mixer, a general-purpose policy
and telemetry hub.
▪ The control plane manages and configures the proxies
to route traffic. Additionally, the control plane configures
Mixers to enforce policies and collect telemetry.
▪ https://istio.io/docs/concepts/what-is-istio/
▪ The Data Plane and the Control Plane

93
Adapter (plugin)
Istio – Service Mesh and Data Plane
▪ How is the service
mesh implemented?
▪ Microservices exist in pods in a cluster
▪ Traffic is ultimately routed to them
▪ A network proxy container is injected as
a “sidecar” into the pod
▪ All network traffic (HTTP, REST, etc.)
goes through the sidecar proxy first
▪ Microservice instance is only aware of
its local proxy and not of the larger
network.
▪ Distributed network abstracted away
from microservice programmer.
Cluster
cluster traffic
Microservice1
Microservice2
Microservice3
cluster traffic
cluster traffic
cluster traffic
▪ What is a data
plane?
▪ In effect, sidecar proxies make
up the data (with Mixer)
▪ Mixer - Istio component
responsible for policy
enforcement and telemetry
collection (plugins for interfacing
with other hosts and backends
▪ Data plane provides:
▪ Service Discovery – what
backend/upstream service
instances are available? Health
checking – are upstream instances
healthy and ready to accept traffic?
▪ Authorization/authentication –
for incoming requests, can called
be validated and allowed to do
what they are asking?
▪ Routing – which upstream service
group should a REST request be
sent to?
▪ Load Balancing –which specific
service instance in a group should
a request be sent to and what retry
values, timeout, etc?
▪ Observability – for a request
produce detailed logging, tracing,
and statistics info.
▪ Overall data plane looks at,
translates, and forwards each
network packet that goes to or
comes from its corresponding
microservice instance.
Mixer
Data Plane
▪ What is Envoy?
▪ High-performance proxy developed to mange
all inbound and outbound traffic for all
services in the service mesh.Microservices
exist in pods in a cluster
▪ Most basic Istio functionality comes from
Envoy (load balancing, fault injection, etc.)

94
Istio – Control Plane
▪ What is a control plane?
▪ Takes the group of individual, stateless sidecare proxies and
creates a distributed system from them.
▪ Features
▪ Automatic load-balancing
▪ Fine-grained traffic control
▪ Pluggable policy layer and configuration API
▪ Automatic metrics, logs, and traces
▪ Secure service-to-service communication
▪ Components
▪ Pilot
» Configures all Envoy proxy instances in mesh
» Provides service discovery for sidecars
» Core component for traffic mgmt.
» Uses configuration from Galley
▪ Galley
» Distribution and centralized config mgmt.
» Insulates rest of Istio components from K8S
» Validates config from users
▪ Citadel
» Provides strong end-user authentication and
authentication between services
» Uses mutual TLS
» Built-in credential and identity mgmt
Cluster
Microservice1
Microservice2
Microservice3
Mixer
CitadelGalleyPilot
Adapter (plugin)
Config data
to proxies Config data
TLS certs to
proxies
Control Plane

95
Istio K8s Objects
▪ Describes a load balancer operating
at edge of mesh receiving incoming or
outgoing HTTP/TCP connections.
▪ Spec describes
▪ Set of ports that should be exposed
▪ Type of protocol to use
▪ Configuration for load balancer, etc.
▪ Example: sets up a proxy to act as a
load balancer exposing port 80 (http),
443 (https), etc.
▪ Applied to proxy running on a pod with
label app: my-gateway-controller
▪ https://istio.io/docs/reference/config/n
etworking/v1alpha3/virtual-service/
▪ Gateway

96
Istio K8s Objects
▪ Defines a set of traffic routing rules when a
host is addressed
▪ Each routing rule defines matching criteria
for traffic of a particular protocol
▪ If traffic is matched, sent to a named
destination (k8s) service (or subset of it)
▪ Traffic source can also be matched in
routing rule
▪ Allows routing to be customized for client
contexts
▪ Example: All http traffic by default goes to
pods of the “reviews” service with label
“version:v1”
▪ Http requests with path starting with
/wpcatalog or /consumercatalog get
rewritten to /newcatalog and sent to pods
with label “version: v2”.
https://istio.io/docs/reference/config/networ
king/v1alpha3/virtual-service/
▪ VirtualService

97
Istio K8s Objects
▪ Works with VirtualService
▪ Declares subset/version of a route destination
▪ Declares named service subsets
▪ https://istio.io/docs/reference/config/networking/v1alpha3/virtu
al-service/
▪ DestinationRule

98
VirtualService Variation
▪ HTTPFaultInjection.Abort

99
VirtualService Variation
▪ HTTPFaultInjection.Delay

100
Adapter (plugin)
Istio – The Big Picture
▪ Istio extends the functionality of Kubernetes
▪ Still requires deployment & service
▪ In addition to the control plane and data
planes, uses additional pieces for routing
functionality
▪ Gateway
» load balancer at edge of mesh
» Configures how proxies load
balance HTTP, TPC, or gRPC traffic
» No traffic routing
▪ Virtual Services
» configures ordered list of routing
rules
» Controls how proxies route requests
for a service within mesh
▪ Destination Rules
» configure policies you want Istio to
apply to a request after enforcing
routing rules from virtual service
▪ Gate way is “bound” to virtual service to
specify routing
▪ Istio components run in namespace “istio-
system”
▪ Routing examples
▪ Traffic shifting
▪ Fault injection
▪ Delay injection
Cluster
Microservice1
Deployment app-current
Mixer
CitadelGalleyPilot
Config data
to proxies Config data
TLS certs to
proxies
VirtualService
DestinationRules
Deployment app-new
metadata:
labels:
version: current
metadata:
labels:
version: new
Traffic ShiftingFault InjectionDelay Injection
Service
Gateway
app namespace
istio-system namespace

101
101
Lab 6: Working with Istio

102
102
What is GitOps?
▪ Way to do Continuous Delivery
▪ Works by using Git as source of truth for declarative infrastructure and
workloads
▪ Per k8s, this means using “git push” instead of “kubectl create/apply” or
“helm install/upgrade”
▪ In traditional CI/CD pipeline, CD (per CI process) creates build artifacts and
promotes them to production
▪ In GitOps pipeline model, ANY change to production must be committed in
source control prior to being applied to cluster
▪ Should ideally be done through pull request/merge request
▪ Advantages
▪ Code review for changes
▪ Tracking of who did what
▪ Rollback is via Git
▪ Whole infrastructure can be recreated from source contrl
https://www.weave.works/blog/managing-helm-releases-the-gitops-way

103
103
GitOps with Kubernetes – what do you
need?
▪ a Git repository with your workloads definitions in YAML format,
Helm charts and any other Kubernetes custom resource that
defines your cluster desired state (config repository)
▪ a container registry where your CI system pushes immutable
images (no latest tags, use semantic versioning or git commit sha)
▪ an operator that runs in your cluster and does a two-way
synchronization:
▪ watches the registry for new image releases
▪ based on deployment policies
» updates the workload definitions with the new image tag
» commits the changes to the config repository
▪ watches for changes in the config repository and applies them to
your cluster

104
104
Managing Helm Releases the GitOps Way

105
Kubernetes Dashboard
▪ Visual interface to the cluster
• General-purpose, web-
based UI for clusters
• Can get overall status
about objects in the cluster
• Invoke via “minikube
dashboard” or “kubectl
apply” from location and
then “kubectl proxy”
• Can also create or modify
objects via “+ CREATE”
link
• Can type in json or
yaml
• Can upload a spec file

106
Prometheus
▪ Event Monitoring and Alerting
• Open-source application for event
monitoring and alerting
• Records realtime metrics in a time-
series database
• Powerful query language - PromQL
• Prometheus “monitoring platform”
usually has
• Multiple exporters that typically
run on the monitored host to
export metrics
• Prometheus to centralize and
store the metrics
• Alertmanager to trigger alerts
based on the metrics
• Grafana to produce dashboards
https://en.wikipedia.org/wiki/Promethe
us_(software)

107
Grafana
▪ Metric analytics and visualization suite
• Way to visualize time series for
infrastructure and application
analytics
• Allows users to build
dashboards with graphs, panels,
etc.
• Accepts data from many data
sources including:
• Graphite
• Elasticsearch
• InfluxDB
• Prometheus
• MySQL
• Postgres
• Cloudwatch

108
108
Bonus Lab: Monitoring

109
109
That’s all - thanks!

Introduction to Containers - From Docker to Kubernetes and everything in between

More Related Content

What's hot (20)

Similar to Introduction to Containers - From Docker to Kubernetes and everything in between (20)

More from All Things Open (20)

Recently uploaded (20)

Introduction to Containers - From Docker to Kubernetes and everything in between