# Kubernetes application demo

Video: https://www.youtube.com/watch?v=CXOPwtJ7qDI&list=PLZLVmS9rf3nN1Rj-TAqFEzFM22Y1kJmvn

The goal of this lesson is to have a crash course of kubernetes, so that someone (who knows a bit about kubernetes already) can deploy a simple app to k8s cluster. We probably won't say everything that someone needs, but hopefully you will know where to start reading to accomplish your need.

We can consider two kinds of services:
* A service runs and that connects to other servers, but doesn't need incoming connections
* A server that accepts incoming connections from outside.

What you want out of this:
- Just a brief glimpse. Will need to leave before 10.30, too
- Better understanding of when I would need Kubernetes, or when to learn it better
- To learn if it is worth using instead of singularity and docker and its relation to using slurm.
- learn about some basic simple tasks and concepts.
- .

## Background reading

???

https://kubernetes.io/docs/tutorials/

## When is kubernetes used

## Basic concepts

Kubernetes is a container orchestration system. In short, it runs containers and provides a coherent way to manage them that scales to extremely large deployments. The most important part is how it provides high-level declarative management.

An example of a deployment would be 50 web server containers, 10 caches, 5 memcachd servers, 3 database replicas all working together. When you need to update the web servers, you decleare the change it kubernetes will automatically roll out the change, making sure that there are enough running at any time to serve incoming requests.

Of course, this power comes at a cost. There are a lot of concepts to learn, for example, for small deployments. It can be hard to figure out what you need to do.

### When do we use kubernetes

### Example
For example, instead of having this:

docker run --volume= container-name:version

You create this kubernetes yaml:

---
apiVersion: v1
kind: Pod
metadata:
  name: csit-bot
  labels:
    app: zulip-bot
spec:
  containers:                       # There can be multiple containers
    - name: bot
      image: zulip-bot
      imagePullPolicy: ifNotPresent
      volumeMounts:                 # What to mount inside.
                                    # Note the indirection, volumes definitions
                                    # separate from volume monuts
        - name: zuliprc-mount
          mountPath: /config
          readOnly: true
  volumes:
    - name: zuliprc-mount
      secret:
        secretName: zuliprc-csit

## Kubernetes objects

Kubernetes is organized into **objects** (Example: deployment, pod volume). These is a uniform representation of each type of object, as seen in:
- YAML representation in files (as seen above)
- Internal representation as queried from the command line utilities/API
- Representation sent to API to create objects.

You can read about each of these type of objects via the API docs, which I have found to be the best place to look:
https://kubernetes.io/docs/reference/kubernetes-api/
... though you have to know what kind of objects you need for a certain task, and tutorials to connect things together.

Additionally, list of all objects and their fields on a single page in https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/

Below, you should learn how to go from the API definition of an object to something usable.

### Objects you may need
- **Pod**
- Fundamental unit of computing
- May have one or more containers within them
- **container**
- Example properties: image, env,
- **Deployment**
- Orchestrates pods running
- Keeps n number of pods running
- **Volume**
- Defines something that can be mounted
- For example
- ConfigMap
- Secret
- Folder on the host machine
- PersistentVolumeClaim
- **VolumeMount**
- Where a volume is mounted inside a pod
- **Secret**
- Like ConfigMap, but designed to hold sensitive data/config
- **ConfigMap**
- A key-value store within the kubernetes
- **Service**
- A pod is designed to be restartable, so the IP addresses of relevant pods could change at any time.
- A service is like a reverse proxy to a selection of pods. Can have its own
- **Ingress**
- Maps incoming HTTP(s) connections to services

## Steps

## Deployment
* NS=namespace_name
* kubectl -n $NS apply -f deployment.yaml
* kubectl get -n $NS pods
* kubectl describe -n $NS pod NAME - look at logs

Example deployment: https://github.com/AaltoSciComp/zulip-bots/

Question: what do you think so far?
- What I wonder is whether this has somehow magical automatic load-balancer configuration, routing, automatic scaling, basically just as Simppa said
* Pods thrown anywhere in cluster
* Service points to set of Pods, providing basic routing and load balancing
* Automatic scaling is available based on e.g. average CPU / memory usage of a Deployment. Too much load? Automatically create new Pods to help the situation.
* If running bare-metal, no service type of "LoadBalancer" available - Ingress resources allow running HTTP(S) services easily, though. LoadBalancers are handled by cloud providers.
* I think LoadBalancer is the only way if you need other than HTTP/HTTPS ports accessible outside the cluster.
* Technically, NodePort exists - it's clunky if just using that (port range 30000-32767) and not mapping to the ports via other means, but works. Also has firewall implications
* ^^ I guess that is no automatic LoadBalancing but direct connections from outside to a specific pod
* It still load balances afaik - all the nodes in cluster listen to the defined port, and map traffic to a node that contains an instance of the desired Pod. And the selection of Pod happens in the basic round robin fashion.
* ^^ I think you are correct.
* Maybe I was thinking of ports in the lower range (under 30000). That might be difficult with NodePort. But it seems that this range can be defined by the k8s admins - dont think many providers allow that though.
- .
- .
- .

## Possible traps

## Feedback

Questions-comments:
- .
- .
- .
- .

## See next / also

API reference: https://kubernetes.io/docs/tutorials/