Kubernetes

For Beginners

Unrestricted
Agenda
● Introduction ● Concepts
○ Legacy Systems ○ Core
○ Docker ○ Workloads
○ Docker-Compose ○ Network
○ Docker-Swarm ○ Storage
○ What isKubernetes? ○ Configuration
○ What doesKubernetes do? ○ Auth and Identity
○ Helm
● Architecture
○ MiniKube
○ MasterComponents
○ NodeComponents ● Behind theScenes
○ Additional Services ● Deployment from Beginning to
○ Kubectl End
○ Kube Config ● AKS Deployment Demo
○ End to End AKS Deployment
Introduction
Legacy Systems
Legacy App Deployment Model on Bare Metal Servers.
Legacy Systems
App Deployment on Virtual Machines Overview.
Welcome Docker
Virtual Machines vs Docker Containers
Virtual Machines

 Virtual machines (VMs) are an abstraction of physical hardware turning one server into
many servers.
 The hypervisor allows multiple VMs to run on a single machine.
 Each VM includes a full copy of an operating system, the application, necessary binaries
and libraries - taking up tens of GBs.
 VMs can also be slower to boot.

Container:

 Containers are an abstraction at the app layer that packages code and dependencies together.
 Multiple containers can run on the same machine and share the OS kernel with other containers,
each running as isolated processes in user space.
 Containers typically take up less space than VMs.
 Docker Workshops
Docker Basics:
https://www.katacoda.com/courses/docker/deploying-first-Container
Dockerize NodeJs:
https://www.katacoda.com/courses/docker/3
  Compose is a tool for defining and running
multi-container Docker applications.

 With Compose, you use a YAML file to configure

your application’s services. Then, with a single command,
you create and start all the services from your configuration.

 Compose is great for development, testing,

and staging environments, as well as CI workflows

Workshop:
COMPOSE
https://www.katacoda.com/boxboat/courses/df-dev/02-docker-compose
  Docker Swarm is a clustering and scheduling
tool for Docker containers.

 With Swarm, IT administrators and developers

can establish and manage a cluster of Docker
nodes as a single virtual system.

Workshop:
SWARM
https://www.katacoda.com/courses/docker-orchestration/getting-started-with-swarm-mode
https://www.katacoda.com/boxboat/courses/df-ops/01-docker-swarm
=
Intro - What is Kubernetes?

Kubernetes or K8s was a project spun out of Google as a open source

next-gen container scheduler designed with the lessons learned from
developing and managing Borg and Omega.

Kubernetes was designed from the ground-up as a loosely coupled collection

of components centered around deploying, maintaining, and scaling
applications.
 Intro - What Does Kubernetes do?

Kubernetes is the linux kernel of distributed systems.

It abstracts away the underlying hardware of the nodes and provides a

uniform interface for applications to be both deployed and consume the
shared pool of resources.

Workshop:
https://www.katacoda.com/loodse/courses/kubernetes/kubernetes-01-playground
Kubernetes
Architecture
Architecture Overview

Masters - Acts as the primary control plane for Kubernetes. Masters are
responsible at a minimum for running the API Server, scheduler, and cluster
controller. They commonly also managestoring cluster state, cloud-provider
specific components and other cluster essential services.

Nodes -Are the ‘workers’ of a Kubernetes cluster. They run a minimal agent
that manages the node itself, and are tasked with executing workloads as
designated by the master.
Architecture
Overview
Master
Components
Master Components

● Kube-apiserver
● Etcd
● Kube-controller-manager
● Cloud-controller-manager
● Kube-scheduler
kube-apiserver

The apiserver provides aforward facing REST interface into the kubernetes
control plane and datastore. All clients, including nodes, users and other
applications interact with kubernetes strictly through the API Server.

It is the true core of Kubernetes acting 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.

kubectl api-resources  to see all api resources

etcd

Etcd acts as the cluster datastore; providing a strong, consistent and highly
available key-value store used for persisting cluster state.
kube-controller-manager

The controller-manager is the primary daemon that manages all core

component control loops. It monitors the cluster state via the apiserver and
steers the cluster towards the desired state.
cloud-controller-manager

The cloud-controller-manager is a 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 PersistentVolumeLabels .
kube-scheduler

Kube-scheduler is averbose policy-rich engine that evaluates workload

requirements and attempts to place it on a matching resource. These
requirements can include such things as general hardware reqs, affinity,
anti-affinity, and other custom resource requirements.
Node
Components
Node Components

● Kubelet
● Kube-proxy
● Containerruntime engine
kubelet

Acts as the node agent responsible for managing pod lifecycle 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 and performs connection

forwarding or load balancing for Kubernetes cluster services.

Available ProxyModes:

● Userspace
● iptables
● ipvs (alpha in 1.8)
Container Runtime

With respect to Kubernetes, 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)
Additional Services

Kube-dns -Provides cluster wide DNS Services. Services are resolvable to

<service>.<namespace>.svc.cluster.local.

Heapster - Metrics Collector for kubernetes cluster, used by some resources

such as the Horizontal Pod Autoscaler. (required for kubedashboard metrics)

Kube-dashboard -A general purpose web based UI for kubernetes.

Kubectl

kubectl [command] [TYPE] [NAME] [flags]

command: operation to perform (verb)

TYPE: the resource type to perform the operation on NAME: Specifies the name of the

resource

flags: optional flags

Workshop:
https://www.katacoda.com/courses/kubernetes/kubectl-run-containers
$KUBECONFIG
• Multiple configurations files as a list of paths
• KUBECONFIG
• Append new configurations temporarily

KUBECTX:

https://github.com/ahmetb/kubectx
Workshops:
KubeAdm
https://www.katacoda.com/loodse/courses/kubernetes/kubernetes-03-cluster-
setup

App Deployment:
https://www.katacoda.com/boxboat/courses/kubernetes-basic/module-2
Kubernetes
Concepts
Kubernetes Concepts - Core

Cluster - A collection of hosts that aggregate their available resources including cpu, ram,disk,
and their devices into ausable pool.

Master - The master(s)represent a collection of components that makeup the control plane of
Kubernetes. These components are responsible for all cluster decisions including both
scheduling and responding to cluster events.

Node - A single host, physical or virtual capable of running pods. A node is managedby the
master(s), and at a minimum runs both kubelet and kube-proxy to be considered part of the
cluster.

Namespace - A logical cluster or environment. Primary method of dividing acluster or

scoping access.
Concepts - Core (cont.)

Label - Key-value pairs that are used to identify, describe and group together related sets of
objects. Labels have astrict syntax and available character set.*

Annotation - Key-value pairs that contain non-identifying information or metadata.

Annotations do not have the the syntax limitations aslabels and can contain structured or
unstructured data.

Selector - Selectors use labels to filter or select objects. Both equality-based (=,==,!=)or
simple key-value matching selectors are supported.

* https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set
 Labels, and Annotations,
and Selectors

Labels:
app:nginx
tier: frontned

Annotations
description: “nginxfrontend”

Selector:
app:nginx
tier: frontend
Concepts - Workloads

Pod - A pod is the smallest unit of work or management resource within Kubernetes. It is
comprised of one or more containers that share their storage, network, and context
(namespace, cgroupsetc).

ReplicationController - Method of managing pod replicas and their lifecycle. Their

scheduling, scaling, and deletion.

ReplicaSet - Next Generation ReplicationController. Supports set-based selectors.

Deployment - A declarative method of managing stateless Pods and ReplicaSets. Provides

rollback functionality in addition to more granular update control mechanisms.
Deployment
ReplicaSet
Contains configuration
Generated ReplicaSet
of how updates or
fromDeployment spec.
‘deployments’ should be
managed in addition to
the pod template used to
generate theReplicaSet.

Workshop:
https://www.katacoda.com/boxb
oat/courses/kf1/03-deployments
Concepts - Workloads (cont.)

StatefulSet - A controller tailored to managing Pods that must persist or maintain state.Pod
identity including hostname,network, and storagewill be persisted.

DaemonSet - Ensures that all nodes matching certain criteria will run aninstance of a
supplied Pod. Ideal for cluster wide services such aslog forwarding, or health monitoring.
 StatefulSet

● Attaches to ‘headeless service’ (not shown) nginx.

● Pods given unique ordinal namesusing the pattern
<statefulset name>-<ordinal index>.
● Creates independent persistent volumes based on
the ‘volumeClaimTemplates’.
 DaemonSet

● Bypasses defaultscheduler
● Schedules asingle instance on every host while
adhering to tolerances and taints.

Workshop:
https://www.katacoda.com/reselbob/scenario
s/k8s-daemonset-w-node-affinity
Concepts – Network
Networking - Fundamental Rules

1) All Pods can communicate with all other Pods without NAT
2) All nodes can communicate with all Pods (andvice-versa) without NAT.
3) The IP that aPod sees itself as is the same IP that others see it as.
Networking - Fundamentals Applied

Containers in a pod exist within the same network namespace and share an
IP;allowing for intrapod communication over localhost.

Pods are given a cluster unique IP for the duration of its lifecycle, but the pods
themselves are fundamentally ephemeral.

Services are given a persistent cluster unique IP that spans the Pods lifecycle.

External Connectivity is generally handed by an integrated cloud provider or

other external entity (load balancer)
Networking -CNI

Networking within Kubernetes is plumbed via the Container Network

Interface (CNI), an interface between a container runtime and a network
implementation plugin.

Compatible CNI Network Plugins:

● Calico ● kube-router
● Cillium ● Multus
● Contiv ● OpenVSwitch
● Contrail ● OVN
● Flannel ● Romana
● GCE ● Weave
Concepts - Network

Service - Services provide amethod of exposing and consuming L4 Pod network accessible
resources. They use label selectors to map groups of pods and ports to a cluster-unique virtual
IP.

Ingress - An ingress controller is the primary method of exposing a cluster service (usually
http) to the outside world. These are load balancers or routers that usually offer SSL
termination, name-basedvirtual hosting etc.
 Service

● Acts as the unified method of accessing replicated pods.

● Four majorService Types:
○ CluterIP -Exposes service on astrictly cluster-internal IP (default)
○ NodePort -Serviceis exposed on each node’sIP on astatically
defined port.
○ LoadBalancer -Works in combination with acloud provider to
exposeaservice outside the cluster on astatic externalIP.
○ ExternalName -used to references endpoints OUTSIDE the cluster
by providing astatic internally referenced DNS name.

Workshop:
https://www.katacoda.com/boxboat/courses/kf2/01-services
 Ingress Controller

● Deployed asapod to one or more hosts

● Ingress controllers are anexternal
controller with multiple options.
○ Nginx
○ HAproxy
○ Contour
○ Traefik
● Specific features and controller specific
configuration is passed through
annotations.

Workshop:
https://www.katacoda.com/boxboat/courses/kf2/03-ingress
 Concepts - Storage
Volume - Storage that is tied to the Pod Lifecycle, consumable by one or more
containers within the pod.

PersistentVolume - A PersistentVolume (PV) represents a storage resource. PVs are

commonly linked to a backing storage resource, NFS, GCEPersistentDisk, RBD etc. and are
provisioned ahead of time. Their lifecycle is handled independently from a pod.

PersistentVolumeClaim - A PersistentVolumeClaim (PVC) is a request for storage that

satisfies a set of requirements instead of mapping to a storage resource directly. Commonly
used with dynamically provisioned storage.

StorageClass - Storageclasses are an abstraction on top of an external storage resource.

These will include a provisioner, provisioner configuration parameters as well as a PV
reclaimPolicy.

Workshop:
https://www.katacoda.com/courses/kubernetes/storage-introduction
Concepts -Configuration

ConfigMap - Externalized data stored within kubernetes that can be referenced as a

commandline argument,environment variable,or injected asa file into a volume mount.Ideal
for separating containerized application from configuration.

Secret - Functionally identical to ConfigMaps, but stored encoded asbase64, and encrypted at
rest (ifconfigured).
 ConfigMaps and Secrets

● Can be used in Pod Config:

○ Injectedasafile
○ Passedas an environment variable
○ Used asa container command (requires passing asenv var)

Workshop:
https://www.katacoda.com/javajon/courses/kubernetes-fundamentals/configmap-secret
 Concepts - Auth and Identity (RBAC)

[Cluster]Role - Roles contain rules that act as a set of permissions that apply verbs like “get”,
“list”, “watch” etc over resources that are scoped to apiGroups. Roles are scoped to namespaces,
and ClusterRoles are applied cluster-wide.

[Cluster]RoleBinding - Grant the permissions asdefined in a [Cluster]Role to one or more

“subjects” which can be auser, group, or service account.

ServiceAccount- ServiceAccounts provide a consumable identity for pods or external

services that interact with the cluster directly and are scoped to namespaces.

Workshop:
https://www.katacoda.com/boxboat/courses/kf2/04-misc
 [Cluster]Role

● Permissions translate to url

path. With “”defaulting to core
group.

● Resources act asitems the role

should be granted access to.

● Verbs are the actions the role

can perform on the referenced
resources.
[Cluster]RoleBinding

● Can reference multiple subjects

● Subjects can be of kind:
○ User
○ Group
○ ServiceAccount
● roleRef targets asingle role only.
 What is HELM

• Package manager • Benefits

• Like yum, apt but for • Repeatability
Kubernetes • Reliability
• Search and reuse or start from • Multiple environment
scratch
• Ease collaboration
• Lifecycle Management
• Manage Complexity
• Create
• Install
• Upgrade/Rollback
• Delete
• Status
• Versioning
 • Helm Client
• Command-line client
• Interacts with Tiller Server
• Local chart development
• Tiller Server
Helm • In-cluster
• Listens to the Helm client
Components • Interacts with Kubernetes API Server
• Manages the lifecycle

gRPC REST Kubernetes

Workshop: Helm Client TillerServer
API Server
https://www.katacoda.com/javajon/c Kubernetes Cluster
ourses/kubernetes-pipelines/helm
 MINIKUBE

https://www.katacoda.com/javajon/courses/kubernetes-fundamentals/minikube
Behind
The Scenes
Deployment From
Beginning to End
Kubectl

1)Kubectl performs client side

validation on manifest (linting).

2)Manifest is prepared and serialized

creating aJSON payload.
APIserver Request Loop

3)Kubectl authenticates to apiserver via x509,jwt,

http auth proxy, other plugins, or http-basic auth.

4)Authorization iterates over available AuthZ

sources:Node, ABAC, RBAC, or webhook.

5)AdmissionControlchecks resource quotas,

other security relatedchecks etc.

6)Request is stored in etcd.

7)Initializers are given opportunity to mutate request before the object is published.

8)Request is published on apiserver.

Deployment Controller

9)Deployment Controller is notified of the new

Deployment viacallback.

10)Deployment Controller evaluates cluster state and

reconciles the desired vs current state and forms a
request for the new ReplicaSet.

11)apiserver request loop evaluatesDeployment

Controller request.

12)ReplicaSet ispublished.
ReplicaSet Controller

13)ReplicaSet Controller is notified of the new ReplicaSet

via callback.

14)ReplicaSet Controller evaluates cluster state and

reconciles the desired vs current state and forms arequest
for the desired amount of pods.

15)apiserver request loop evaluatesReplicaSet

Controller request.

16)Pods published, and enter ‘Pending’ phase.

Scheduler

17)Scheduler monitors published pods with no

‘NodeName’ assigned.

18)Applies scheduling rules and filters to find a

suitable node to host the Pod.

19)Scheduler creates abinding of Pod to Node and

POSTs toapiserver.

20)apiserver request loop evaluatesPOST request.

21)Pod status is updated with node binding and sets

status to‘PodScheduled’.
Kubelet -PodSync

22)The kubelet daemonon every node polls the apiserver filtering

for pods matching its own ‘NodeName’; checking its current state
with the desired state published through the apiserver.

23)Kubelet will then move through a series of internal processes to

prepare the pod environment. This includes pulling secrets,
provisioning storage,applying AppArmor profiles and other various
scaffolding. During this period, it will asynchronously be POST’ing
the ‘PodStatus’ to the apiserver through the standard apiserver
request loop.
Pause and Plumbing

24)Kubelet then provisions a ‘pause’ container via the

CRI (Container Runtime Interface). The pause container
acts asthe parent container for the Pod.

25)The network is plumbed to the Pod via the CNI

(Container Network Interface), creating a veth pair
attached to the pause container and to a container
bridge (cbr0).

26)IPAM handled by the CNI plugin assigns anIP to the

pause container.
Kubelet - Create
Containers
24)Kubelet pulls the container Images.

25)Kubelet first creates and starts any init containers.

26)Once the optional init containers complete, the

primary pod containers are started.
Pod Status

27)If there are any liveless/readiness probes, these are executed before the
PodStatus isupdated.

28)If all complete successfully, PodStatus is set to ready and the container
has startedsuccessfully.

The Pod is Deployed!

END to END AKS DEMO
Questions?
Resources:

1. https://www.slideshare.net/BobKillen?utm_campaign=profiletracking&ut
m_medium=sssite&utm_source=ssslideview
2. https://www.katacoda.com/
3. https://kubernetes.io/