Introduction to Kubernetes

Copyright © 2011 LOGTEL
Introduction to
Kubernetes
Samuel Dratwa
Samuel.dratwa@gmail.com

About the Copyright
This documentation is protected by Copyright © 2017 LOGTEL,
32 Shacham St., Petah Tikva, 49170, Israel. World rights reserved.
The possession and use of this documentation is subjected to the
restrictions contained in this license.
No part of this documentation may be stored in a retrieval system,
transmitted or reproduced in any way, including but not limited to
photocopy, photograph, magnetic or other record, without the prior
agreement and written permission of LOGTEL.
Participants of this seminar are entitled to keep their copy of this
documentation for references purposes only.
2

 Containers & Kubernetes Recap
 Containers life cycles
 Pods and Descriptors
 Label Selectors
 Services / ingress Services
 Replica Set / Daemon Sets
 Deployments
 Kubernetes concepts
 Resources (and ResourceQuota)
 Application lifecycle
 Networking
 Orchestration
 Hands-On
Agenda – Day 1
5

 Recap of 1st day and question answering
 Introduction to Rancher
 Creating a Cluster
 Deploying an Application
 Kubernetes concepts
 Rolling updates and rollbacks
 Config Map & Secrets
 Self-healing and auto-scaling applications
 Kubernetes Hands-On
 Updating a Pod
 Using Config Map
 Auto-Scaling
 Helm – concept and architecture
 Final thoughts and conclusions
Agenda – Day 2
6

App
A
Containers vs. VMs
Hypervisor (Type 2)
Host OS
Server
Gue
st
OS
Bin
s/
Libs
App
A’
Gue
st
OS
Bin
s/
Libs
App
B
Gue
st
OS
Bin
s/
Libs
AppA’
Docker
Host OS
Server
Bins/Li
bs
AppA
Bins/Libs
AppB
AppB’
AppB’
AppB’
VM
Container
Containers are isolated,
but share OS and, where
appropriate, bins/libraries
Gue
st
OS
Gue
st
OS
…result is significantly faster
deployment, much less
overhead, easier migration,
faster restart

Why are Docker containers
lightweight?
Bin
s/
Libs
App
A
Original App
(No OS to take
up space, resources,
or require restart)
AppΔ
Bins/
App
A
Bin
s/
Libs
App
A’
Gue
st
OS
Bin
s/
Libs
Modified App
Copy on write
capabilities allow
us to only save
the diffs
Between
container A and
container
A’
VMs
Every app, every copy of an
app, and every slight modification
of the app requires a new virtual server
App
A
Gue
st
OS
Bin
s/
Libs
Copy of
App
No OS. Can
Share bins/libs
App
A
Gue
st
OS
Gue
st
OS
VMs Containers

Docker is a “Shipping Container”
10

What’s missing
11

Options for Container Cloud Orchestration on Power
12
Docker Swarm/Datacenter KubernetesMesos
Docker Inc GoogleMesosphere
• Strengths
• Built-in to Docker 1.12 Engine
• Easy to use for Small Clouds
• Weaknesses
• Full Docker DC not on Power Yet
• Strengths
• Good for Batch and Analytics
• Lots of Apps in Catalog
• Weaknesses
• Less usage in Web Applications
• Requires Marathon Framework for
Web Apps
• Strengths
• Lots of Industry usage and
experience for Web Apps
• Synergy with Other parts of Client
Business for X86 Container Mgmt
• Weaknesses
• Significant Integration of many
components for Production Cloud

Source: Shippable.com http://blog.shippable.com/why-the-adoption-of-kubernetes-will-explode-in-2018
kubernetes won the container orchestration war...

Kubernetes Layout
14

Swarm
15

Kubernetes
 Pronounced /koo-ber-nay'-tace/
 A Greek term for “ship master”.
 Developed at/by Google.
 The third iteration of container management.
 Daddy was Omega.
 Grandaddy was Borg.
 Kubernetes is not a PaaS, just orchestration
(Docker is the PaaS)
 Kubernetes built to “planet scale”.
 Google wants us to stop writing Kubernetes and use k8s
instead
 100% Open source, written in Go
16

 Kubernetes is an open-source system for automating
deployment, scaling, and management of containerized
applications.
 Planet Scale
 Designed on the same principles that allows Google to run billions
of containers a week, Kubernetes can scale without increasing your
ops team.
 Never Outgrow
 Whether testing locally or running a global enterprise, Kubernetes
flexibility grows with you to deliver your applications consistently
and easily no matter how complex your need is
 Run Anywhere
 on-premise, hybrid, or public cloud infrastructure, letting you
effortlessly move workloads to where it matters to you.
17

Kubernetes Features
18

Scheduling Affinity/anti-
affinity
Health
monitoring
Failover
Scaling Networking Service
discovery
Coordinated
app upgrades

Kubernetes Layout
20

Master
 API Server—nearly all the components on the master and
nodes accomplish their respective tasks by making API
calls. These are handled by the API Server running on the
master.
 Etcd—Etcd is a service whose job is to keep and replicate
the current configuration and run state of the cluster. It is
implemented as a lightweight distributed key-value store
and was developed inside the CoreOS project.
 Scheduler and Controller Manager—These processes
schedule containers (actually pods) onto target nodes. They
also make sure that the correct numbers of these pods are
running at all times.
21

Node
 Kubelet - A special background process (daemon) that
runs on each node whose job is to respond to commands
from the master to create, destroy, and monitor the
containers on that host.
 Proxy - This is a simple network proxy that’s used to
separate the IP address of a target container from the
name of the service it provides.
 cAdvisor (optional) - Container Advisor is a special
daemon that collects, aggregates, processes, and exports
information about running containers. This information
includes information about resource isolation, historical
usage, and key network statistics.
22

Pods
 A pod is a collection of containers and volumes that are
bundled and scheduled together because they share a
common resource, usually a filesystem or IP address.
23

Why not just run multiple programs
in a single (Docker) container?
 Transparency. Making the containers within the pod
visible to the infrastructure enables the infrastructure to
provide services to those containers, such as process
management and resource monitoring. This facilitates a
number of conveniences for users.
 Decoupling software dependencies. The individual
containers may be versioned, rebuilt and redeployed
independently. Kubernetes may even support live updates
of individual containers someday.
 Ease of use. Users don’t need to run their own process
managers, worry about signal and exit-code propagation,
etc.
 Efficiency. Because the infrastructure takes on more
responsibility, containers can be lighter weight.
24

Kubernetes Architecture
26

Descriptors
apiVersion: v1
kind: Pod
metadata:
name: ""
labels:
name: ""
namespace: ""
annotations: []
generateName: ""
spec:
? "// See 'The spec schema' for
details."
: ~
{
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "",
"labels": {
"name": ""
},
"generateName": "",
"namespace": "",
"annotations": []
},
"spec": {
// See 'The spec schema' for details.
}
}
27
YAML is the clear winner. Especially in the context of Shannon’s Information Theory.
The same density of information can be transmitted in less lines with YAML.

Pod Spec
spec:
containers:
-
args:
- ""
command:
- ""
env:
-
name: ""
value: ""
image: ""
imagePullPolicy: ""
name: ""
ports:
-
containerPort: 0
name: ""
protocol: ""
resources:
cpu: ""
memory: ""
restartPolicy: ""
volumes:
-
emptyDir:
medium: ""
name: ""
secret:
secretName: ""
28

Pod spec example
apiVersion: v1
kind: Pod
metadata:
name: redis-django
labels:
app: web
spec:
containers:
- name: key-value-store
image: redis
ports:
- containerPort: 6379
- name: frontend
image: django
ports:
- containerPort: 8000
29

The Pod Lifecycle in a Cluster
Let’s say you want to fire up a pod. With kubectl you would:
1. Make a Pod request to the API server using a local pod
definition file.
2. The API server saves the info for the pod in ETCD.
3. The scheduler finds the unscheduled pod and schedules it
to a node.
4. Kubelet sees the pod scheduled and fires up Docker.
5. Docker runs the container.
 The entire lifecycle state of the pod is stored in ETCD.
Most of the things in Kubernetes are built on top of
Pods
30

kubectl create - Create a resource from a file
// Create a service using the definition in example-service.yaml.
$ kubectl create -f example-service.yaml
// Create a replication controller using the definition in example-
controller.yaml.
$ kubectl create -f example-controller.yaml
// Create the objects that are defined in any .yaml, .yml, or .json file
within the <directory> directory.
$ kubectl create -f <directory>
31

Labels
 A label is a key-value pair that is assigned to objects in k8s.
 Pods, services, etc
 Labels can be used to organize and to select subsets of objects
 Labels can be attached to objects at creation time and subsequently
added and modified at any time
32

Label Selectors
 Two kinds of label selectors
 equality-based (IS/IS NOT)
 tier = frontend
 tier != frontend
 tier != frontend, game = super-shooter-2
 set-based (IN/NOT IN)
 environment in (production, qa)
 tier notin (frontend, backend)
33

Services
 A Kubernetes Service is an abstraction which defines a
logical set of Pods and a policy by which to access them
 The set of pods gathered by a Service is determined by a
label selector
 A service is a long-lived, well-known endpoint that points to
a set of pods in a cluster. It consists of three things:
 external IP address (known as a portal, or sometimes a portal IP)
 port
 label selector.
34

Service Example
35

Basic Cluster
36
 When you launch a cluster, you get some built in services.
 Each one of these has their own endpoints and / or UIs.
 They run on the master directly though you could schedule
them across the cluster or other masters.
 To find the endpoints type: kubectl cluster-info

The base – container & spec
 The only required field in spec is containers.
it requires (mandatory only) two entries
 name
 image
 Part of the spec is for all containers in a pod:
 restartPolicy
 Volumes
 The spec is very extensible by design
 Specs don’t do anything by themselves;
for that you need a pod .
39

Pods
 Pods are just collections of containers that share a few
things:
 Access to volumes
 Networking
 Are co-located
 Restart together
 Usualy scale togther
 Etc.
 Pods can be run by themselves but have no guarantee to
restart or stay running or scale or do anything useful
40

Ingress Service
 Services point to a Pod or to an external source.
 With Pods a virtual endpoint is created then routed to using the
kube-proxy
 For non-pod services a virtual IP in the cluster is used to route
externally .
 Ingress Service = AWS API Gateway
 An Ingress Controller sits at the boundary of the cluster and routes
requests to Services
 One Ingress Controller can handle multiple domains
 Each route can point to a different Service
 Relies on the creation of an Ingress Controller in the cluster
(another service that is not enabled by default).
41

Daemon sets
 Daemons is an object that ensures that a copy of each Pod
runs on each node. This is commonly used to make sure
side-car containers are running across the cluster.
 If new nodes come up they’ll get a copy of the daemon set
and will come up.
 Daemon sets don’t have scaling rules.
42

Pet Sets – Statefull pods
 Introduced 1.3, Pet Sets allow you to create complex
microservices across the cluster.
 They have the ability to set dependency on other
containers.
 They require:
 A stable hostname, available in DNS
 An ordinal index
 Stable storage: linked to the ordinal & hostname
 It is used for statefull pods
43

Replcia Set
 A Replication Controller (deprecated) was the best way
to run Pods.
 You set a number of pods to run and the Replication Controller
made sure that the number was running across the cluster.
 Rolling updates could be performed by starting a new Replication
Controller and scaling up.
 A Replica Set differs from the Replication Controller
because it can be updated.
 If you update the Replica Set template you can fire and update and
automatically roll changes
 Rollbacks are also built in.
 Replica Set are not designed to be used directly.
For that you need Deployments.
44

replication controller ReplicaSet
apiVersion: v1
kind: ReplicationController
metadata:
name: rcweb
labels:
name: rcweb
spec:
replicas: 4
selector:
app: rcweb
phase: production
template:
metadata:
labels:
app: rcweb
role: frontend
phase: production
name: rcwebpod
spec:
containers:
- name: staticweb 45

Deployments, The king of the hill
 A Deployment controls the running state of Pods and
Replica Sets.
 In k8s it is the primary object you should be manipulating.
 Deployments have:
 History
 Rolling updates
 Pausing updates
 Roll-backs
46

A Virtual Cluster in Your Cluster
 A namespace as an isolated section of a cluster.
 It’s a virtual cluster in your cluster.
 Each cluster can have multiple namespaces.
 The root services have their own.
 Namespaces are in network isolation from each other and
can (are normally) used to house different environments on
the same cluster.
 resources (pods, services, replication controllers, etc.)
 policies (who can or cannot perform actions in their community)
 constraints (quota, etc.)
 Kubernetes starts with two initial namespaces:
 default - The default namespace for objects with no other
namespace.
 kube-system - The namespace for objects created by the
Kubernetes system
47

ResourceQuota (for namespace)
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota
spec:
hard:
cpu: "20"
memory: 1Gi
pods: "10"
replicationcontrollers: "20"
resourcequotas: "1"
services: "5"
48

ConfigMap
 ConfigMap is a resource available in kubernetes for managing
application configuration.
 The goal is to decouple the app configuration from the image content
in order to keep the container portable and k8s agnostic.
 ConfigMap are key value pairs of configuration data.
49

Kubernetes on public clouds
 Availability on the major cloud providers:
 There are a variety of CLI tools available
 automate deployment of Kubernetes
 enable production-quality Kubernetes clusters on AWS & other
clouds to be deployed quickly & easily
 some include node auto-scaling
 Also third-party companies providing Kubernetes-as-a-
Service on multiple public clouds
Native support Node auto-scaling
Google ✔ ✔
Azure ✔ ✗
AWS ✗ ✗

Windows Server Container Architecture
Source: Microsoft

Windows Server Node in Kubernetes
kubelet kube-proxy
Kubernetes
Master
Components
(unchanged)
Kubectl
(unchanged)
Windows Server 2016 Node
docker
Infra
container POD
container
Infra
container POD
container

Standalone
 Minikube
 https://github.com/kubernetes/minikube
 Runs a Kubernetes node on top of your favorite (probably
Virtualbox) VM.
 Lots of involvement from the K8s community.
 Kube-solo
 https://github.com/TheNewNormal/kube-solo-osx
 Uses the Corectl app to run a Kube VM
 Also has a multi-node version.
53

The Pod is the core Kubernetes Component
spec:
template:
spec:
containers:
- name: drupal
image: cr.io/repo/mydrupal:v1
54
 The Pod is the core component of
Kubernetes
 Collection of 1 or more containers
 Each pod should focus on one container,
however sidecar containers can be added
to enhance features of the core
container

Pods can Handle Scaling and Deployments
 Kubernetes Handles:
 System Performance
 Scale up/down the number of pods based
on CPU load or other criteria
 System Monitoring
 Probes to check the health of each pod
 Any unhealthy ones get killed and new
pod is put into service
 Deployments
 Deploy new versions of the container
 Control traffic to the new pods to test the
new version
 Blue/Green deployments
 Rolling deployments
55

Kubernetes Services tie together the pods
apiVersion: v1
kind: Service
metadata:
name: drupal
spec:
selector:
app: drupal
ports:
- name: http-port
port: 80
type: LoadBalancer
56
Kubernetes Services are used to control
communications with the pods
 Load balance the requests
 Don’t send traffic to the unhealthy
ones
 Only talk to the correct version

Services Structure allow multiple Components
 Service architecture allow Kubernetes to
handle things instead of us:
 Service discovery
 Load balancing
 Scaling
 Service discovery allows each pod just
needs to call the name of the service it
wants to talk to
 Services have multiple options
 Session based load balancing
 Single port based services
 External Services
 The Service architecture of Kubernetes can
be scaled up to handle as many services as
you would like for your system
57

Where Is the Infrastructure?
 You don’t have to worry about the
infrastructure
 The entire design of pods and services
is described with YAML files
 Nothing in deployments, pod
management, service discovery,
monitoring, etc required any
knowledge about how many servers,
IP addresses, load balancers, or
anything else with the infrastructure
 Behind the scenes, Kubernetes is
aware of all of the servers available,
load balancers, application gateways
and will configure them automatically
according to what is in the YAML files
58

DRUPAL EXAMPLES
59

Deployment
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: drupal
spec:
template:
spec:
containers:
- name: drupal
image:
cr.io/repo/mydrupal:v1
ports:
containerPort: 80
 Deployment—connects a Pod
with replication control and
rollout management
 Synchronizes app
configuration across instances
 Production deploys are as
simple as updating an image
tag
 No more bouncing apache on
a dozen servers
 Contains a Pod spec

Autoscaling
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
spec:
scaleTargetRef:
kind: Deployment
name: drupal
minReplicas: 2
maxReplicas: 10
targetCPUUtilizationPercentage: 50
 Realizes the promise of the cloud: scales your app in response to
load, in real time
 Kubernetes tracks resource utilization
 Responds by adding or removing pods to the Replica Set
 Kubernetes core supports CPU utilization
 Other resources are available via add-ons
 Pod autoscaling != node autoscaling
 Node autoscaling for GCE and AWS as add-ons
61

Service
apiVersion: v1
kind: Service
metadata:
name: drupal
spec:
selector:
app: drupal
ports:
- name: http-port
port: 80
type: LoadBalancer
 curl http://drupal/cron.php
 Manages ports and internal IP’s with
domain name resolution
 Opens ports on agent nodes
 Manages load balancing between pods
 Provisions cloud provider load balancer
 Exposes pods to Kubernetes service
discovery
62

External Service
kind: Service
apiVersion: v1
metadata:
name: mysql-service
spec:
type: ExternalName
externalName:
mysql.example.com
ports:
- port: 3306
 Use RDS and provider services when possible
 No need to hard code external services in your application
 Adds an external resource to Kubernetes service discovery
63

Deployment: Configuration Management
kind: Deployment
spec:
replicas: 2
template:
spec:
containers:
- name: drupal
ports:
containerPort: 80
env:
- name: DB_HOSTNAME
value: mysql-service
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-service-secrets
key: password
imagePullSecrets:
- name: registrykey
64
* $databases['default']['default'] = array(
* 'driver' => 'sqlite',
* 'database' =>
'/path/to/databasefilename',
* );
* @endcode
*/
$databases['default']['default'] = array(
'driver' => 'mysql',
'database' => 'mydrupaldb',
'username' => getenv('DB_USERNAME'),
'password' => getenv('DB_PASSWORD'),
'host' => getenv('DB_HOSTNAME'),
);
/**
* Access control for update.php script.
*
* If you are updating your Drupal installation
using
* are not logged in using either an account
with the
* updates" permission or the site
maintenance account
* created during installation), you will need

Deployment: Volumes
kind: Deployment
spec:
replicas: 2
template:
spec:
containers:
- name: drupal
ports:
containerPort: 80
volumeMounts:
- name: my-drupal-volume
mountPath: /drupal-
7.56/sites/files
volumes:
- name: my-drupal-volume
azureFile:
secretName: azure-storage-
secret
shareName: <pre-existing-file-
 Manages networked drives across
containers and VM’s
 volumeMounts sets the mount
path and references a named
volume
 Volumes can be defined as
 Pre-created named volumes
 Dynamically provisioned
Persistent Volume Claims
65

Google demo
 gcloud container clusters create example-cluster
 kubectl run hello-node --image=gcr.io/google-
samples/node-hello:1.0 --port=8080
 kubectl expose deployment hello-node --
type="LoadBalancer"
 kubectl cluster-info
 kubectl config view
 kubectl get pods
 kubectl get service
 gcloud container clusters describe example-cluster
68

Azure App Service
Quickly build, deploy, and scale web apps
Preview - now supports Windows Server containers

Fundamentals of Windows containers
and Windows container-based web
apps on Azure App Service

Azure Container Instances (ACI)
THR2206 - Run a serverless Kubernetes
cluster by bridging AKS and ACI
through the Virtual-Kubelet

Azure Kubernetes Service (AKS)
Fully managed Kubernetes orchestration service
Auto patching, auto scaling, auto updates
Use the full Kubernetes ecosystem (100% upstream)
Deeply integrated with Azure Dev Tools and services

Service Fabric
Windows and Linux Containers
Stateless and stateful microservices
Deploy on Azure, Azure Stack and on-premises

Service Fabric Mesh
Fully managed microservices platform, built on Service Fabric
Windows and Linux Containers

Optimizing
for microservice
development
Tracking multiple
deployment pipelines
while maintaining agile
updates
Focusing on business
logic instead of
microservice platform
maintenance
Dealing with the
complexity
of network communications
Monitoring and
governance at overarching
and granular levels
Achieving reliable state
and data consistency
without latency issues
Running highly
secure
applications at
scale
</>
.NET
</>

Optimizing
for microservice
development
Tracking multiple
deployment pipelines while
maintaining agile updates
Focusing on business logic
instead of microservice
platform maintenance
Dealing with the complexity
of interactions and network
communications
Monitoring and
governance at overarching
and granular levels
Achieving reliable state
and data consistency
without latency issues
Running highly
secure applications
at scale
Build Deploy Operate
Flexible
infrastructure
Lifecycle
managemen
t
24/7
availability &
performance
Elastic
scalabilit
y
Microservice
and
container
orchestratio
n
Security &
complianc
e
Health &
monitorin
g
Challenges
</>
Azure Service Fabric
.NET
</>
Build and deploy containers and microservices on Windows and Linux, at any scale, on any cloud

Programming
Models
Dev & Ops
Tooling
Orchestration Lifecycle
Management
Health &
Monitoring
Always On
Availability
Auto
Scaling
AzureOn-premises infrastructureAny cloudDev machine
Service Fabric: cloud application platform
Build OperateDeploy

Azure Service Fabric offerings
Bring your own infrastructure
Service Fabric
Standalone
On-premisesAny cloud
Dev machine
Dedicated Azure clusters
Azure
Service Fabric
Azure
Service Fabric Mesh
Serverless microservices
Service Fabric
Full Control Fully managed

Azure Service Fabric offerings
Bring your own infrastructure
Service Fabric
Standalone
On-premisesAny cloud
Dev machine
Dedicated Azure clusters
Azure
Service Fabric
Azure
Service Fabric Mesh
Serverless microservices
Virtual machines
OS patching
Runtime upgrades
Capacity planning
Network and
storage
Micro-billing
App deployment
You
Azure
Responsibility
Cluster capacity
Network and
storage
App deployment
Virtual machines
OS patching
Runtime
upgrades
Hardware
OS patching
Runtime upgrades
Cluster capacity
Network and storage
App deployment

Migrate existing applications as-is to the
cloud, including using containers, to reduce
cost and enable DevOps deployments
New applications conceived and built
with the cloud in mind using
microservices architecture

Azure Service Fabric is designed for mission-critical services
Power BI
Dynamic
s365
Intune
Cortana Skype for
business
Cosmos DB
IoT Hub
Event Hub
SQL Database
Azure
Monitor
Core
Azure
Services
Archive
Storage
Visual Studio
Team
Services
Stream
Analytics
Azure
Database for
PostgreSQL
Azure Database
for MySQL
Azure
Container
Registry
Event Grid

Introduction to Kubernetes

More Related Content

What's hot (20)

Similar to Introduction to Kubernetes (20)

More from Samuel Dratwa (13)

Recently uploaded (20)

Introduction to Kubernetes

Editor's Notes