Before we begin

Organizational stuff

Is you PC ready?

(we will need this later)

Download image

Contract

1. Ask about anything!
2. Make notes!
3. Do your exercises, and we can guarantee you will gain understanding of how things works
4. If you feel you need a break, tell us/write us!

Introduction

Goal of the workshop

Follow us

https://slides.com/d/XFe5jYs/live

all slides

Exercises

https://github.com/ptrstpp950/k8s-allegro

folder: exercises/XX-

~time

"name"

description

ask, if you do not understand

Big bang theory

Definitions are hard

When someone asks for them, so we will create them together

If you can’t feed a team with two pizzas, it’s too large. That limits a task force to five to seven people, depending on their appetites 

Jeff Bezos

A bit lasagna and ravioli

Modern one

Deployment

orchestration (platform)

• Is it responsible for scaling?
• Is it responsible for monitoring?
• Is it responsible for deployments?
• Is it responsible for configuration?
• Is it responsible for ...?

Kubernetes

• From Greek, meaning helmsman or pilot
• Does not limit the types of applications supported
• Does not deploy source code and does not build your application
• Does not provide application-level services
• Does not dictate logging, monitoring, or alerting solutions
• Does not provide nor mandate a configuration language/system
• Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems

K8s

• What's k8s?

K8s

• Where do you know it is used?
• Where can you use it?
• Who uses it?
• ...

K8s discussion

WHY not K8s?

Docker

It's not rocket science

Tooling...

Deployment...

Scaling

But docker have:

• Swarm

• Compose

?

Kubernetes in action

How to work

Docker Desktop

Docker is popular container platform allowing to run linux* containers on variety of platforms including Windows and Mac.

Docker Inc. provides kubernetes cluster for local development - this cluster is hosted in... containers ;)

It's a good tool to be used on daily basis if we are working with docker too. If not, why bother.

* to serve the greater good of humanity and the World, let's not talk about windows containers...

Docker Rancher Desktop

Docker is popular container platform allowing to run linux* containers on variety of platforms including Windows and Mac.

Docker Inc. Rancher provides kubernetes cluster for local development - this cluster is hosted in... containers ;)

It's a good tool to be used on daily basis if we are working with docker too. If not, why bother.

* to serve the greater good of humanity and the World, let's not talk about windows containers...

minikube

Minikube is a tool that makes it easy to run Kubernetes locally.

Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop on day-to-day basis.

installation

minikube

Windows - Hyper-V virtual switch

minikube

basic commands

exercise - connect

Instructions:

• Choose one preferred option (or more)
• if ssh - try accessing it
• minikube
  • on ubuntu run: minikube start --memory 8192
  • locally run: minikube start
  • run: minikube status host, kubelet and api should be running
• docker
  • Check in UI if kubernetes is running

Time Cap:

5 min

01

K8S - main concepts

Ubiquitous Language

Birds-eye view

Main blocks of K8S

* plane

Master Node

• API - RESTful API used by all components to communicate
• Scheduler - assign nodes to deployable components
• Controller Manager - performs cluster-wide operations like, registering new nodes, or replicating components
• etcd - key-value store keeping the current state of the application and configuration. Only API talks to etcd.

Worker Node

• Kubelet - is responsible for everything that runs on worker node, this is the only component that needs to be executed as binary on node, all others might be deployed over kubernetes as part of kubernetes (🤯)
• Kube Proxy - responsible for providing network access to containers in the cluster
• Container Runtime - shim over different container technologies like Docker, CRI-O or containerd

One API to rule them all

• Core of K8S is REST API
• This API is consumed by
  • Dashboard (UI) - clickable
  • kubectl (CLI) - imperative
  • and all k8s main components (scheduler, controller manager) and more

Pre-Basics

Things we should understand to understand basics :)

kubectl

• CLI client for K8S Api Server
• The basic tool to work with k8s from
• Allows imperative communications:
  • operations on live objects
  • no history of operations
  • no easy way to revert changes
  • we say what to do, not what state we want

kubectl

installation

kubectl

verification

We need kubectl working so make sure that version check did worked for you

yaml

• Human-readable data serialization language
• Whitespace indentation is used to denote structure
• Tab characters are never allowed as indentation
• "Missing ;" (in yaml missing space) with yaml escalates quickly and is hard to fix
• Allows declarative communication
  • we are describing a desire state, k8s will do all steps needed to achieve this

yaml

tools

• Amazingly notepad is quite good
• Whatever tool suites you
• Visual Studio Code have two nice plugins:
  • Kubernetes
  • YAML Support by Red Hat

demo - Code with plugins

01

VS Code Plugins

VS Code Plugins

VS Code Plugins

VS Code Plugins

Make sure you have a way to write YAML files - w/ or w/o intellisense

Dumpster

our amazing application

Dumpster

• Simple node application
• Our goal is not to write app, but learn about kubernetes
• App is containerized and available on docker hub
• Default image we will be working with gutek/dumpster:v1
• We will be playing with different tags - v1, v2 etc
• Source  for v1 is in repo

Dumpster

endpoints

• /data - list files in directory /var/data
• /env - list all environment variables
• /* - general endpoint printing version number and host name

Dumpster

code

Dumpster

docker

PKAD

alternativly

• Instead of simple dumpster, we can use pkad, application that shows on UI a lot of kubernetes functionality
• All demos and sample code are using by default dumpster, but you can always change this to:
  
  poznajkubernetes/pkad

Dashboard

API walkthrough with definitions

Accessing Dashboard

minikube

Accessing Dashboard

docker

Dashboard

demo - create pod from UI

Instructions:

• create pod with name dumpster-pod
• image: gutek/dumpster:v1
• service: Internal
• Port: 80 -> 8080

02

Dashboard&definitions

A Pod:

• is the basic building block - unit in the K8s object model that you create or deploy
• encapsulates an application container, storage resources, a unique network IP, ...
  
•  represents a unit of deployment: a single instance of an application in Kubernetes​

demo - pod definition and logs

Instructions:

• open pod
• take a look at logs
• take a look at pods definition under edit button (note, we will come back to it later on)

03

exercise - Access Pod

Instructions:

• use pod created during demo of name dumpster-pod
• pod is web application that is accessible on url path: /
• might help: port mapping is 80 -> 8080
• find a way to open application

Time Cap:

5 min

02

discussion - Access Pod

• Did you manage to access pod?
• How did you achieve that?
• How we can make pod available from Internet using ui?

02

let's do it together

demo - accessing pod

• Accessing pod
  • using a proxy (pod and internal) (http://localhost:8001/api/v1/namespaces/default/pods/http:POD_NAME:8080/proxy/ )
  • using a terminal in UI

04

Dashboard&definitions

A ReplicaSet:

• build on top of replication controller
• is a type of Controller, it controls Pods :)
• ensures that a specified number of pod replicas are running at any given time
• should be managed by a Deployment

exercise - Delete POD

Instructions:

• open our app in browser (using one of the ways described before) 
• check hostname
• delete dumpster-pod-* pod
• keep attention on the pod name (especially on * part) and pod age
• might required browser refresh

Time Cap:

5 min

03

Dashboard&definitions

A Deployment:

• provides declarative updates for Pods and ReplicaSets

• You describe a desired state in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. 

Dashboard&definitions

A Service:

• is an abstraction which defines a logical set of Pods and a policy by which to access them

• the set of Pods targeted by a Service is (usually) determined by a Label Selector 

• makes pod available externally (adds external access)

exercise - Scale up & down

Instructions:

• Scale up deployment
• Check number of pods and their names
• Access pod using service abstraction
• Check hostname
• Delete Pod that was shown
• Refresh your browser
• Optional: Scale down

Time Cap:

5 min

04

demo - exposing

• Exposing pod
  • Internal
  • External
  • There are two more ways, we will learn about them during a course

04

Dashboard&definitions

A Service Type can be:

• ClusterIP - exposes the service on a cluster-internal IP. This is the default ServiceType 
• NodePort - Exposes the service on each Node’s IP at a static port (the NodePort). Access to service can be done with http(s)://NodeExternalIP:NodePort
• continue next slide :)

Dashboard&definitions

A Service Type can be:

• LoadBalancer - Exposes the service externally using a cloud provider’s load balancer
• ExternalName - Maps the service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value

Dashboard&definitions

A ConfigMap:

• binds configuration files, command-line arguments, environment variables, port numbers, and other configuration artifacts to your Pods' containers and system components at runtime.
• is useful for storing and sharing non-sensitive, unencrypted configuration information

Dashboard&definitions

A Secret:

• is intended to hold sensitive information: password, OAuth tokens, ssh keys, ...

• is safer and more flexible than putting it verbatim in a pod definition or in a docker image

• is stored as base64

exercise - discover a secret

Instructions:

• Try to find value of token secret
• When you are ready raise your hand

Time Cap:

-

05

Dashboard&definitions

A Label:

• is key/value pairs that are attached to objects, such as pods, services, ...
• do not directly imply semantics
• is human friendly description used for search, grouping, etc

Bare metal underhood :

• CPU stats
• memory stats
• allocations

Dashboard&definitions

dashboard - quick trick

Common commands

kubectl

Open shell/cmd and play along :)

kubectl config

• allows working with more than one k8s clusters

kubectl cluster-info

• information about cluster services and roles

kubectl explain

• explain what specific resource is
• nice help, not really useful later on

kubectl get|describe

• display details of resource

demo - get yaml for UI pod

Instructions:

• using kubectl
• and describe
• get yaml for pod deployed

??

Basics

Things we should know

Cleanup

how to clean up our mess

Instructions:

• Clean your instance
• Use commands from prev slide (kubectl delete ...)
• Try do it step by step without --all argument
• Hint: Do you remember:
  • kubectl get deployments
  • kubectl get pods

exercise - clean up

Time Cap:

5 min

06

discussion - clean up

• Do you feel powerful?
• Is it dangerous?
• did you deleted kubernetes service? if not, why?
• Can I do it at home?

06

Pod

let's look at a structure from the dashboard

• apiVersion - RESTful verison of API (part of path)
• kind - object type
• metadata - information about the object
• labels - key-value object identification
• spec - desire state of the object
• containers - containers specification 
• name - name of the container
• image - docker/rkt image to use
• ports - ports that container exposes, completely OPTIONAL!

Pod

yaml structure

Pod

deployment

exercise - create and get yaml

Instructions:

• open and view pod.yaml
• deploy pod pod.yaml using create command
• use kubectl to get yaml of deployed pod
• open yaml and compare it to pod.yaml

Time Cap:

10 min

07

discussion - create and get yaml

• What differences are in files?
• Why these files vary?

07

Pod

what exactly happens when create is executed?

exercise - apply and get yaml

Instructions:

• deploy pod pod.yaml using apply
• answer: what was your intention?

Time Cap:

5 min

08

discussion - apply and get yaml

• Where you able to apply pod?
• What issue did you encounter?
• How you would like it to behave in this situation?

08

Pod

delete

exercise - compare yaml

Instructions:

• clear environment using delete cmd

• deploy pod.yaml using create
• get yaml of deployed pod - save it under create-pod.yaml
• delete pod (whatever option you choose)
• deploy pod pod.yaml using apply
• get yaml of deployed pod - save it under apply-pod.yaml
• compare two yamls - the create and apply one
• whats the difference?

Time Cap:

10 min

09

discussion - compare yaml

• What options did you use to delete pod?
  • Did you use downloaded yaml file to delete?
• What are the differences between two files?

09

Pod

how to access pod from the command line

exercise - access pod

Instructions:

• access pod using all three options
• with each option, get result from query / on pod app

Time Cap:

5 min

10

discussion - access pod

• Did you manage to do all three options?
• What options had been most difficult?
• What options do you prefer?

10

Pod

best practices

• never use :latest in image specification
• pod's are rarely used as single deployment units
• provide containerPort even thought is not needed
• always specify label
• add annotations
• always specify a container name
• when using create always add --save-config=true (nice explanation why and when to use it)

Pods are ephemeral

Pets VS. cattle

Labels

a way to describe resource

• Used across k8s
• One resource can have multiple labels
• Labels are used in selectors to find all resources that meet criteria, for instance:
  • find frontend of version 1
  • find all pods responsible for handling back-end requests

Labels

example

Labels

kubectl

exercise - add labels to pod

Instructions:

• add following labels to pod.yaml:
  • version, app and tier - whatever value
  • and workshop=true
• apply pod.yaml
• check if labels had been applied using kubectl
• remove all resources with workshop=true label

Time Cap:

10 min

11

discussion - add lables to pod

• for what we can use labels?
• did your label worked? did you needed to change it?
• did you manage to remove all resource of given label?

11

demo - adding labels manually

• We can also add labels manually when needed
• For instance, we want to remove all except one pod having a specific label
• Or we want to remove label that pod have so we can investigate it and let kubernetes handle rest for us

from now on you can clean your k8s by deleting everything under

workshop=true

label

Services

exposing pods

• Services allow exposing pods that match specific label selectors to:
  • internal network - ClusterIP
  • publicly available port number - NodePort
  • publicly available IP address - LoadBalancer
• Also allows:
  • mapping external service as "local" one - ExternalName

Services

template

• kind - we are working with service
• spec - desire state of the object
• type - type of the service - ClusterIP (default), NodePort, LoadBalancer, ExternalName
• selector - label selector of pods that should be exposed by given service
• ports - mapping between service port and pod ports

Services

ports

• name - name that we can give to current port, needed if more than one port defined
• protocol - protocol used in communication: TCP (default), UDP & SCTP 
• port - port number on service to which client (user) connects to
• targetPort - port on the pod to which connects to. we can use names instead of numbers allowing us to dynamically change ports on pods or to have different port on each pod

Services

kubectl

exercise - ClusterIP

Instructions:

• apply pod.yaml
• try to create ClusterIP service for pod.yaml
• you can use template.yaml to help with structure
• get internal IP address of deployed service
• try to access service

Time Cap:

10 min

12

discussion - ClusterIP

• what are the differences between service and pod names?
• what ClusterIP is doing for you that you could not achieve without it?
• were you able to access ClusterIP service?

12

demo - accessing ClusterIP

We have three options to access ClusterIP service

• kubectl port-forward
• kubectl proxy
• kubectl exec POD_NAME -- curl http://service_name

??

Services

ClusterIP

exercise - ping ClusterIP

Instructions:

• access pod that ClusterIP expose as service
• try to ping ClusterIP IP address
• try to curl ClusterIP IP address

Time Cap:

5 min

13

discussion - ping ClusterIP

• Were you able to ping ClusterIP?
• Were you able to curl ClusterIP?
• Do you have an idea why this happens?

13

exercise - Env Vars ClusterIP

Instructions:

• clear all pods and services
• apply pod.yaml
• Create ClusterIP service for pod.yaml, you can use template.yaml to help with structure
• execute /env endpoint of exposed pod (by doing this over ClusterIP or pod) - save result
• delete and create pod again (do not delete service)
• compare results of /env endpoint

Time Cap:

10 min

14

discussion - Env Vars ClusterIP

• What did you notice?
• What are differences between /env endpoints?
• Have you notice something interesting?

14

exercise - ClusterIP pods

Instructions:

• clear all pods and services and apply pod-one.yaml
• create ClusterIP service of name dumpster
• execute kubectl describe svc dumpster and save results
• apply pod-two.yaml
• execute kubectl describe svc dumpster and compare results with previous one
• what are endpoints?
• can you figure this out?

Time Cap:

10 min

15

discussion - ClusterIP pods

• What was different?
• What are endpoints?

15

Pros

• Internally visible service by IP and DNS
• Base for all service types

Cons

• Not available externally
• Should not be exposed publicly - don't depend on kubectl proxy

Services

ClusterIP

When to use it:

• Internal dashboard
• Internal proxy to external service - i.e. all microservices call this service to get to external service
• giving a name to set of pods that act as a backend

Services

ClusterIP

exercise - NodePort

Instructions:

• apply pod.yaml
• create NodePort service for pod.yaml
• do it manually - if you have issues, take a look at template from prev exercise
• get yaml of deployed service, notice differences between your's yaml and deployed service
• access exposed NodePort service

Time Cap:

10 min

16

discussion - NodePort

• did you specify nodePort in settings?
• what are differences between ClusterIP and NodePort?
• how did you access your's service?
• when do you think this is a good solution?

16

demo - accessing NodePort

??

Services

NodePort

Pros

• Service available from all nodes
• One Service per port

Cons

• One Service per port
• Limited number of available ports (30 000 - 32 767)
• Address depends on node IP - if that changes, all clients needs to be updated

Services

NodePort

When to use it:

• for development purpose
• as a per of bigger solution - for instance, most cloud services required service of type NodePort when using ingress

Services

NodePort

Services

LoadBalancer

• LoadBalancer is not part of k8s
• K8s provides an interface that specific provider should implement
• LoadBalancer is different depending on the cloud we are using and how we do a setup on-prem
• When we request LoadBalancer from k8s, K8s ask the provider to create one externally

exercise - LoadBalancer

Instructions:

• apply pod.yaml
• create LoadBalancer service for pod.yaml
• you can use template.yaml to help with structure
• access exposed LoadBalancer

17

Time Cap:

10 min

discussion - LoadBalancer

• Did you deployed LoadBalancer?
• How did you know it was deployed?
• Where you able to access LoadBalancer?
• How did you do it?

17

demo - accessing LoadBalancer

Most important: LoadBalancer -> NodePort -> ClusterIP, so NodePort is ClusterIP, and LoadBalancer is NodePort and ClusterIP

??

Services

LoadBalancer

Services

LoadBalancer

k8s in action, manning

Services

Load Balancer

Pros

• "Cloud" native - on-prem available
• No filtering - all traffic is routed to service

Cons

• One Load Balancer per Service!
• Might be expensive
• No filtering - all traffic is routed to service

Services

Load Balancer

when to use it:

• When we want to expose service externally
• Define IP/dns for our service

Services

Load Balancer

how it's normally done?

• If we have all the money in the world, we can create as many LoadBalancers as we want
• Generally, we have one LoadBalancer per our solution
• LoadBalancer is used with Ingress
• Ingress is responsible for managing k8s routes, and external LoadBalancer manage access to ingress
• So when we will talk about Ingress? soooon :)

when in doubt, remember you can always clean everything:

workshop=true

Deployments

Deployments

a way to create MANY pods ;)

• Allows to manage process of deploying scalable solution to k8s
• Declaratively manage ReplicaSet
• Allows by default two kind of deployments:
  • recreate - replace existing version with new version, called Recreate in k8s
  • ramped - slowly replace version 1 with version 2, default in k8s and called RollingUpdate.
• if our deployment update fails, the previous version keep's running!

Deployments

template

• replicas - number of "template" instances
• selector - how do we know how many instances there are
• template - pod yaml w/o apiVerson and kind. you can have only one template per deployment

Deployments

kubectl

Deployments vs ReplicaSet

• There is no vs
• Deployments manage ReplicaSets
• ReplicaSets manage pods replications
• There is Replication Controller vs ReplicaSet

Deployment

ReplicaSet

Deployments

naming

• metadata.name - a name of deployment and base name for ReplicaSet and Pod
• dumpster-naming-01 - it's just a label
• dumpster-naming-container - it's just a name of the container in Pod(s), each separate Pod might have same name of container

• 585cdbd6cf - hash of spec.template, for instance execute kubectl get pods --show-lables
• 585cdbd6cf-7zm27 - random generated, we can achieve this with generateName

exercise - deploy pods

Instructions:

• modify & use deploy.yaml
• make sure that deploy creates 3 replicas
• deploy should work on workshop=true and app=api label
• make sure that 3 instances have been deployed
• download deployed yaml and check deployment strategy
• access web application deployed by this deploy.yaml

Time Cap:

10 min

18

discussion - deploy pods

• did you manage to deploy 3 instances?
• were you able to access web application?
  • how?
  • why not?
• what deployment strategy had been set?

18

Deployments

available strategies - RollingUpdate (default)

• strategy.type - defines the current strategy type selected. RollingUpdate is the default one, other option is Recreate
• rollingUpdate.maxUnavailable - how many pods might be unavailable in the current moment
• rollingUpdate.maxSurge - how many pods might be created over a total number of replicas

Deployments

available strategies - Recreate

• strategy.type - when recreate is selected all current pods are removed before new one are installed

RollingUpdate

RollingUpdate

RollingUpdate

RollingUpdate

RollingUpdate

RollingUpdate

exercise - deployment order

Instructions:

• create two files: service.yaml and deploy.yaml
• in service.yaml define NodePort exposing pods that have app=api label
• in deploy.yaml create deployment for gutek/dumpster:v1 image that will have labels defined in service.yaml
• write down assumptions: what needs to be deployed first
• verify your assumptions

Time Cap:

20 min

19

discussion - deployment order

• What were your assumptions?
• Were you right?
• Does order matter?

19

demo - RollingUpdate

• create service
• run in while curl
• create deployment
• create new deployment

Deployment strategies

https://github.com/ContainerSolutions/k8s-deployment-strategies

discussion - deployment strategies

• How to create different deployment types?
• What can you use?

19

Deployments

managing deployments from kubectl

exercise - fix deployment

Instructions (use kubectl only):

• deploy deploy.yaml (hint: use --record=true)
• deploy new-deploy.yaml
• check deployment status
• check what has changed (hint: --revision)
• in editor fix and re-deploy new-deploy.yaml

Time Cap:

10 min

20

discussion - fix deployment

• what have you use to see what has changed?
• what has changed?
• is there other way of fixing this rather than editing yaml?
  • which way is better?

20

Deployments

when do we know that our pod is alive?

• livenessProbe - defines when POD is alive
• httpGet - verify that container is running by executing following path on given port
• failureThreshold - how many times we should  times try before give up, default 3
• periodSeconds - checks again after Ns, default 10s
• initialDelaySeconds - wait Ns before checking
• timeoutSeconds - finish request after Ns, default 1s

exercise - liveliness

Instructions:

• deploy dep.yaml
• modify dep.yaml to include livelinessProbe
  • set httpGet:path to /test url
• re-deploy dep.yaml with changes
• confirm that deployment did succeeded/failed

Time Cap:

10 min

ATTENTION: 29

discussion - liveliness

• Did deployment succeed?
• How did you know if deployment did succeed/failed?
• Change url to /healthz  and deploy again

29

Deployments

when do we know that our pod is ready/deployed?

• readinessProbe - defines when POD is ready to receive requests
• httpGet - verify that container is running by executing following path on given port
• failureThreshold - how many times we should  times try before give up, default 3
• periodSeconds - checks again after Ns, default 10s
• initialDelaySeconds - wait Ns before checking
• timeoutSeconds - finish request after Ns, default 1s

clean up reminder :)

workshop=true

label

exercise - readiness

Instructions:

• modify dep.yaml to include readiness probe
  • set httpGet.path to /healthz url
• deploy dep.yaml, see what happens
• play around with failureThreshold, periodSeconds initalDelaySeconds and timoutSeconds to find best and working solution

Time Cap:

10 min

30

discussion - readiness

• What happened after first deployment?
• Did you found perfect set of parameters that works in this case?
• What values have you used?

30

Deployments

liveliness & readiness best practies

• Always specify
• If you do not have special endpoint, try access your's default one
• It have impact on deployment time, however it makes sure that your services are running as expected
• Sometimes being more explicit helps when and if k8s change defaults

Deployments

help with zero-downtime

our app might need extra time to shutdown gracefully

Deployments

best practices

• Deployments are good for stateless services
• The more details you add to yaml, the better control of deployment process you will have
• Start with 1 replica! extend if needed
• Use labels
• Remember to add --record
• Monitor deployments - you will not get an alert that old replica set is still working and new had failed
• add liveliness and readiness probes

Tasks

Jobs

fire and forget

• All system have "tasks"
• Units of work that needs to be done on schedule
• Mostly processing thing

Jobs

template

• spec.template - pod template
• rest is self explanatory

Jobs

kubectl

demo - job

• execute single job
• check status of the job
• check log of the job
• clean up

00-jobs

CronJobs

template

• schedule - cron schedule of job
• jobTemplate - exactly the same as in Job
• job.Tempalte.spec.template - pod template
• rest is self explanatory

Configuration

Namespaces

group application

• Virtual cluster
• Allows to separate applications
• i.e. namespace per env, namespace per team
• Allows scoping resource names - two namespaces can have resources of the same name
• Add complexity to all queries

Namespaces

kubectl

Namespace

template

• name- name of our namespace
• metadata.namespace- name of the namespace where given object should be placed

exercise - Namespace

Instructions:

• create namespace k8s
• deploy pod to newly created namespace
• list pod in the new namespace
• delete all pods under the new namespace

Time Cap:

10 min

21

discussion - Namespace

• is it doable?
• how did you query all pods?
• how we could leverage namespaces?
• is there a better way so we do not need to set namespace all the time?
• what will happen if you delete namespace?

21

ConfigMaps

common configuration

• Reusable configuration
• Many ways of using:
  • as a mounted file/volume
  • as environmental variables

ConfigMaps

kubectl

ConfigMaps

template

• data - key value list of configurations

Pod

passing parameters

• env- list of environmental variables
• name/value - key/value list of environmental variables passed to pod 

exercise - Pod evn

Instructions:

• do clean-up
• add env parameters to pod-and-service.yaml:
  • month: december
  • channel: stable
• deploy pod-and-service.yaml using apply
• open deployed service pod-env url in browser
• check under /env if env parameter exists

Time Cap:

5 min

22

discussion - Pod evn

• how this can be used?
• what its missing?
• what improvements would you add to env to make it usable?
• is there any other way to access pods env?

22

Pod

passing parameters from config map

• envFrom.configMapRef - add all env variables from config map of name. Config map needs to exist prior pod creation
• valueFrom.configMapKeyRef - takes value from key located in the config map of name

exercise - config map with env

Instructions:

• clean up
• create config map with two keys and values
• add reference to all keys and values to pod-and-sevice.yaml (hint: use valueFrom.configMapKeyRef)
• deploy config map using apply
• deploy pod pod-and-service.yaml using apply
• verify that env variables had been created by opening pod-cm-env service

Time Cap:

10 min

23

discussion - config map with env

• why would you use valueFrom?
• for what you can use config maps as env variables?

23

ConfigMaps

best practices

• Extract common configuration to file
• Inject extra information about env
• if it config is not pod specific, add it to config map - easier to manage

Secrets

common configuration in base64

• Works similar to ConfigMaps
• Allow storing and re-using key value pair 
• Value is not encrypted, is in plain text
• Value is base64 encoded
• Where confgMap was used we can change that to secret:
  • configMapKeyRef -> secretKeyRef
  • configMapRef -> secretRef
  • configMap -> secret
  • name -> secretName

Secrets

kubectl

Secrets

template

• data - key value list of configurations, whereas value is in base64

Secrets

in pods

Secrets

best practices

• For dev/test env only
• Use whenever there is something like password
• Make sure its not checked in into repro
• SECRETS are not secure, encrypted value stores!
• Only protection is RBAC

Volumes

Volumes

types

• There are a lot of types, few basics are:
• emptyDir - lives as long as pod does, allow sharing data between containers
• configMap - allow hosting config map key/values as file/content
• secret - same as configMap
• nfs - Network Folder Share mounted into pod, we need nfs server
• downwardAPI - expose pod properties to container including all metadata from pod definition etc.
• projected - mount configMap, secret, downwardAPI into single folder
• hostPath - node file system mounted into pod
• azureDisk, azureFile, awsElasticBlockStore, gcePersistentDisk - cloud storage
• persistentVolume/Claim - abstraction over cloud and other storage's, allows claiming PersistentVolume resource

demo - empty dir

• volumeMounts
  • name - name of the mount to be used
  • mountPath - local (container) path to be used to which name will be mounted, it "hides" anything that is present under that path
• volumes
  • name - name of the volume to be used in pod
  • emptyDir - empty directory 

note - gitRepo

• is deprecated
• we can achieve same thing with emptyDir
• initContainers

initContainers

demo - config map as volume

• volumeMounts
  • name - name of the mount to be used
  • mountPath - local (container) path to be used to which name will be mounted, it "hides" anything that is present under that path
• volumes
  • name - name of the volume to be used in
  • configMap - volume comes from config map of name local-cm 

00-volume-cm

demo - secret as volume

• volumeMounts
  • name - name of the mount to be used
  • mountPath - local (container) path to be used to which name will be mounted, it "hides" anything that is present under that path
• volumes
  • name - name of the volume to be used in pod
  • secret - volume comes from secret of name local-cm 

00-volume-secret

emptyDir, configMap, secret, hostPath contains data as long as Pod/Node works. They do not sync data back!

PersistentVolume/Claims

decoupling storage technology

PersistentVolume

template

• capacity.storage - size of the storage
• accessMode - how this volume can be mounted in nodes
• persistentVolumeReclaimPolicy - what should be done with volume when pod is not using it any more? Retain - leave it with content, after its release from claim. But its not usable, to use it again, you need to delete and create same one again. Recycle - clears content and make it available to re-use. Delete - deletes volume and data.
• hostPath - type of storage

PersistentVolumeClaim

template

• volumeMode - can be on PV too, they need to match, introduced in 1.13 k8s
• resource.requests.storage - how big storage we need
• accessModes - same as in PV
• storageClassName - specify which provisioner should be use to provision PV. PV and PVC needs to match, we can leave this empty
• selector - same as in Deployments, filter PV by lables

Using PersistentVolumeClaim

in Pod

demo - Simple PVC on Azure

• use AKS
• apply pvc.yaml
• apply pod.yaml
• create file at /mnt/azure
• destroy pod & recreate it
• find disk with 
• More https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv

00-volume-azure

Ingress

Ingress
/ˈɪnɡrɛs/

The action or fact of going in or entering; the capacity or right of entrance.

Ingress

installation

Attention: Ingress

Changed into:

Ingress

default configuration

Ingress

using external load balancer

• best way to do this is during installation
• after installation we need to manually update dynamically named service
• there is no guarantee that this will work
• best solution:

Ingress

Default backend

Ingress

default backend

Ingress

Fanout routing

Ingress

Fanout routing

Ingress

Name based virtual hosting

Ingress

Name based virtual hosting

Ingress

Rewrite target

exercise - ingress

Instructions:

• create 3 deployments (v1, v2 & v3 dumpster version) and 3 services for deployments
• create ingress that will map paths based on deployment name
• use ingress base file: ingress.yaml
• validate that you can open pages for each of 3 deployments

Time Cap:

10 min

31

discussion - ingress

• were you able to create 3 distinct ingress paths?
• did they worked?
• why ingress can be useful?

31

Imperative

few operations that might be useful

kubectl run

• runs particular images (pod)
• creates deployment for for managing pod
• will be removed in next versions of K8S

• good for quick demos

kubectl set

• updates particular property of the resource

• whenever you do this, always! update yaml to have that changes included
• rule: don't do it on production... unless your boss asks you to do this ;)

exercise - update image

Instructions:

• run image gutek/dumpster:v1
• describe deployment to get:
  • deployment name
  • container name
• update image to gutek/dumpster:v2 (hint: use values from previous point)
• check pod image using describe command

Time Cap:

15 min

24

discussion - update image

• Did it fill right to update image manually?
• What could go wrong?
• Did you know about --dry-run funcionality?

24

kubectl scale

• manually scale instances of pod manage by ReplicaSet and/or deployment

• when needed can save ass
• always analyze why you needed to use scale manually

https://youtu.be/kOa_llowQ1c?t=1022

kubectl expose

• expose resource (pod, deployment, replicates etc.) as new service

exercise - run and expose

Instructions:

• use only kubectl
• run gutek/dumpster:v1 with 6 replicas
• expose it as service
• make sure you can access service
• change image to gutek/dumpster:v2
• open browser and check deployed version

Time Cap:

15 min

25

discussion - run and expose

• how easy was to crate deployment without yaml?
• was it easy to update/set properties?
• how did you solve issue with exposing deployment as service?

25

Advanced

Good to know things

Limits & autoscaling

Preparation

few things...

Pod

resource limit

• resources.requests - we needs this memory and cpu to run this pod

• resources.limits - we maximum will take this memory and cpu utilization

exercise - resource limit

Instructions:

• play with resource requests in deploy.yaml
• try to utilize 50% of memory
• try to utilize 60% of cpu
• once 50% of memory is utilized, change replicas to 7 and see what happens

Time Cap:

15 min

27

discussion - resource limit

• What was the status of the pod that could no be created?
• Were you able to set proper parameters so deployment took exactly 50% of memory and 60% of cpu?
• How did yo achieve it?

27

ResourceQuota

• Allows specify desire limits

• It can be applied globally or locally

• It needs to be turned on --enable-admission-plugins

ResourceQuota

• spec.hard defines list of quotas for current namespace

LimitRange

• Allows specify desire limits of possible resources usage per pod

• Also allows specify ratio aspect of the resources used in Pod

• It needs to be turned on --enable-admission-plugins

LimitRange

• limits defines limits of resources for pod or container

Autoscaling

how to scale based on resources?

• Currently deployments does not scale automatically - only manually
• During heavy load the only way of scale is to execute kubectl scale
• Autoscaling gives as tools to manage scaling depending on resource usage

Autoscaling

kubectl - imperatively

Autoscaling

template

• apiVersion - autoscaling/v1 allows only scale on

• targetCPUUtilizationPercentage, beta allows scaling on multiple metrics

to make it WORK pods needs to define resources

Autoscaling

template

MAIN THING TO TAKE FROM THIS TEMPLATE

autoscaling/v1 allows only scale on cpu utilization %

autoscaling/v2beta1 allows to scale on multiple metrics

to make it WORK pods needs to define resources

demo - autoscaling

Instructions:

• set resources limit/requests and deploy deploy.yaml
• create autoscaler using kubectl (cpu resource needs to be defined) or template.yaml
• set minimum replicas to 5, maximum to 15
• in new shell tab execute:

• see if it autoscaled, if not play around with metrics and redeploy

00-hpa

discussion - autoscaling

• Did you notice autoscaler in work?
• how long did it take to make autoscaling scale?

28

KEDA - advanced autoscaling

• Kubernetes Event Driven Autoscaler
• When normal metrics are not enough

KEDA

KEDA - autoscalers

Vertical Pod Autoscaler

• "Automagically" adjusts the CPU and memory reservations
• Free space/resources for other pods
• Extension to K8s - separate repo https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler
• On AKS as an extention

VPA - components

• Recommender - monitors current and past resource consumption and recommend new values for CPU and memory requests
• Updater - it checks if managed pods have correct recourses set and kill them if not, so they can be recreated with updated requests
• Admission Plugin - it sets the correct resource requests on new pods (created or recreated by their controller due to Updater's activity).

Before demo

demo - VPA

Instructions:

• installation + verification (check readme)

00-vpa

VPA - known limitations

• Pod can be recreated on different node
• VPA cannot guarantee that pods it evicts or deletes will be successfully recreated. This can be partly addressed using Cluster autoscaler
• VPA does not evict pods which are not run under a controller
• VPA shouldn't be used with HPA on CPU and memory (custom metrics are ok)
• VPA performance has not been tested in large clusters.
• VPA reacts to most OOM events, but not in all situations.
  
• VPA recommendation might exceed available resources
  

DemonSets & StatefulSets

DNS

how things are resolved

my-svc.my-namespace.svc.cluster.local
dumpster-svc.default.svc.cluster.local

pod-ip.my-namespace.pod.cluster.local
10-10-10-10.default.pod.cluster.local

more options

DeamonSet

• ensures that each node have a running copy of pod
• we can filter-out nodes that should not have pods - if needed

DeamonSet

template

DeamonSet

kubectl

demo - deamon set

Instructions:

• deploy ds.yaml
• check where pods are deployed

00-ds-create

StatefulSet

• if we need predicable name of pods so we can use it in predicable way
• we need a predicable way of upgrading
• predicable way of destroying pods
• use "new kind of service"

StatefulSet

headless service

StatefulSet

template

StatefulSet

kubectl

demo - stateful set

Instructions:

• deploy ss.yaml
• how to access pods?

00-ss-create

StatefulSet

dns

pod-NUMBER.service-name.namespace.svc.cluster.local

dumpster-ss-2.dumpster-ss-svc.default.svc.cluster.local

Affinity

Affinity & Anti-Affinity 

• Defines how pod can be scheduled on node
• Defined how pod can't be scheduled on node
• Allows to specify nodes on which pod's should be deployed

• nodeSelector - label selector of node to select

Node Selector

• nodeName - select node by name

Node Name

Node Affenity

• requiredDuringSchedulingIgnoredDuringExecution - hard limit, it needs to be fullfill before pod can be scheduled
• preferredDuringSchedulingIgnoredDuringExecution - soft limit, it would be good if the requirements can be fullfilled

Node Affinity

Pod Affinity/Ani-Affinity

Design Patterns

multi container systems

helm

vs

kustomize

problem

• multiple env
• differences:
  • "load"
  • "power"
  • domains
  • namespaces
  • ....

How to solve it?

• copy per environment
• "tokens" in files
• tools:
  • helm
  • kustomize

Theory

• Template engine -> Helm
• Overlay engine -> Kustomize

helm

• Package manager for k8s
• Allows installing packages as well as packaging our own solution as "deployable package"
• helm installation is simple as kubectl - binary file

chart

service.yaml

helm

basic commands

helm

• Package manager for k8s
• Allows installing packages as well as packaging our own solution as "deployable package"
• helm installation is simple as kubectl - binary file

Pros

• Powerful
• Like any other package manager (apt-get, mvn, npm)
• A huge chart library

Cons

• Another abstraction level
• Learning curve
• Produces spaghetti 

helm

kustomize

• Built-in in kubectl
• Overlay engine
• K.I.S.S

demo -kustomize

• build base dir
• build overlay dir
• kubectl apply -k

00-kustomization

Pros

• Native support
• Easy to understand
• Minimal change

Cons

• Primitive
•  It breaks DRY rule

kustomize

Monitoring & debugging

Monitoring & Debugging

• some monitoring and debugging tools depends on k8s environment
• some are provided by kubectl and dashboard
• some needs extra installations i.e. from helm

Monitoring & Debugging

kubectl

Monitoring & Debugging

dashboard

exercise - check log

Instructions:

• create pod with image gutek/dumpster:v1
• deploy it
• execute / endpoint
• check logs

Time Cap:

10 min

32

discussion - check log

• did you were able to find out what had gone wrong?
• when if this would happen on app start, would log still worked?

32

External tools

grafana

External tools

grafana

External tools

wave

External tools

wave

External tools

debugging

Popular tools:

- Telepresence

- Bridge to Kubernetes

External tools

debugging

Tools for devs

Autocomplete

kubectx & kubens

oh-my-....

• oh-my-zsh
• oh-my-bash
• oh-my-posh + magic tooltips

IDE: Lens/k9s/kui

Container Registry

demo - private registry

upload image to private registry

• Login into private registry with docker

docker login devszkolak8s.azurecr.io -u USER -p PASS

• Tag image

docker tag gutek/dumpster:v1 devszkolak8s.azurecr.io/YOUR_NAME/dumpster:v1

• Push image

docker push devszkolak8s.azurecr.io/YOUR_NAME/dumpster:v1

00-private-registry

demo - private registry p.2

register private registry in K8S

Command

kubectl create secret docker-registry regcred

     --docker-server=devszkolak8s.azurecr.io

     --docker-username=USER

     --docker-password=PASS

     --docker-email=email@email.com

00-private-registry

demo - private registry p.3

deploy pod

• deploy pod with image from private registry

 containers:
  - name: private-reg-container
    image: <your-private-image>
  imagePullSecrets:
  - name: regcred

00-private-registry

discussion - private container registry

• Secrets can be useful :)
• Easy
• ...

CI/CD

making a pipeline

CI /CD - build

1. Build your image
2. Tag it with build number:
   • {build_number}
   • develop-{build_number}
3. Push it to registry
4. After build export  == build artifacts:
   • tag
   • deployment.yaml
   • docker image should be in registry

CI /CD - release

1. Extract artifacts (image tag + deployment.yaml)
2. Replace image tag in deployment.yaml
3. Validate YAML (e.g. kubeval)
4. Set variables+configs+secrets if needed
5. Run apply 

      kubectl apply -f deployment.yml

6. Verify deployment with 

      kubectl rollout status deployment NAME_FROM_YML

7. If deployment doesn't succeed in time-period revert rollout and mark release as failed:

        kubectl rollout undo deployment NAME_FROM_YML

demos - CI /CD - build

https://dev.azure.com/poznajkubernetes/_git/pkad?path=%2Fazure-pipelines.yml

https://gitlab.com/poznajKubernetes/pkad-gitlab/-/blob/master/.gitlab-ci.yml

Databases on K8s

To run or not to run

Different view

source

CKAD

what is needed

• Core Concepts:
  • Understand Kubernetes API primitives
  • Create and configure basic Pods
• Multi-Container Pods
  • Understand Multi-Container Pod design paterns (e.g. ambasador, adapter, sidecar)
• Pod Design
  • Understand how to use Labels, Selectors, and Annotations
  • Understand Deployments and how to perform roling updates
  • Understand Deployments and how to perform rolebacks
  • Understand Jobs and CronJobs
• State Persistence
  • Understand PersistentVolumeClaims for storage

• Configuration
  • Understand ConfigMaps
  • Understand SecurityContexts
  • Define an application’s resource requirements
  • Create & consume Secrets
  • Understand ServiceAccounts
• Observability
  • Understand LivenesProbes and ReadinesProbes
  • Understand container logging
  • Understand how to monitor applications in Kubernetes
  • Understand debugging in Kubernetes
• Services & Networking
  • Understand Services
  • Demonstrate basic understanding of NetworkPolicies

After workshop

Resources

• Kubernetes documentation
• Kubernetes słownik
• and everything that is on following slides

Amazon, Manning

Amazon

Amazon

Amazon ($$$), Microsoft (Free)

Playlist

edX free course