Kubernetes for nodeJS dev

Course notes from Dan Wahlin’s excellent pluralsight course titled: Kubernetes from Developers: Core Concepts

Introduction

A way to manage containers.
Alternative to docker-swarm.
Locally, using docker compose is fine, but not ideal for production. For production we can scale, self-heal, update containers better, better networking capabilities, etc…
Works by having one master node which manages a number of other nodes.

Running locally

Run via docker desktop. Turn on kubernetes in dashboard. In terminal run commands to master node via the kubectl command.

Web UI dashboard

UI view of kubernetes clusters.

Run locally

https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
kubectl describe secret -n kube-system
# copy first token which is of type service-account-token
kutectl proxy
# open in browser http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/
# paste on token

Nodes

A node is a collection of pods. The master node communicates with a cluster of nodes, each node contains a pod, each pod contains a container, (usually). Has agent to communicate with master called, kubelet. Has container runtime. Has networking via, kube-proxy.

Master node

Contains a number of services:

• Store, which is like a DB of nodes in the cluster.
• Controller manager, managing requests.
• Scheduler, when updates will occur.
• API server, $kudectl, to communicate with node.

Pods

A pod is a packaging for a container. You can have many pods on a given node. Usually one pod will contain one container. They can easily be removed and new ones created, (old ones can not be bought back). They have unique IP address. Containers within pods have unique ports. They never expand nodes.

Useful pod commands

# run a pod
kubectl run [podname] --image=nginx
# get pods
kubectl get pods
# port forward so pod can be called externally
kubectl port-forward [podname] 8080:80
# delete pod
kubectl delete pod [podname]
# information about a pod
kubectl describe pod [podname]
# exec into pod, (browse file structure)
kubectl exec [podname] -it sh

YAML file

apiVersion: v1
kind: Pod
metadata:
 name: my-nginx
 labels:
  app: nginx
  rel: stable
spec:
 containers:
 - name: my-nginx
   image: nginx
   ports:
   - containerPort: 80

Useful YAML pod commands

# create the pod from yaml file
kubectl create -f file.yml
# create will error if exists, use apply to take down and create
kubectl apply -f file.yml
# edit in console
kubectl edit
# patch specific property
kubectl patch
# delete, (alternative to just deleting a pod)
kubectl delete -f file.yml

Probes

Used internally to find out the health of a container. User can create their own probes.

• Liveness probe, determines health of pod, (e.g. hit health check endpoint).
• Readiness probe, when it’s ready for requests to start being made.

Deployments / ReplicaSets

ReplicaSets document how we want the pods managed.
Deployment wraps replicaSets, uses replicaSets to manage pods. Used to scale pods. Uses a pod template instead of creating a pod yaml directly.

Useful deployment commands

# get deployment
kubectl get deployment --show-labels
# get deployment by label
kubectl get deployment -l app=nginx
# delete deployment
kubectl delete deployment [deploymentname]
# scale deployment by 5 pods
kubectl scale deployment [deploymentname] --replicas=5

YAML file

apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-nginx
 labels:
  app: my-nginx
spec:
 replicas: 2
 selector:
  matchLabels:
   app: my-nginx
 template:
  metadata:
   labels:
    app: my-nginx
  spec:
   containers:
   - name: my-nginx
     image: nginx
     ports:
     - containerPort: 80

Useful YAML deployment commands

# create the deployment from yaml file
kubectl create -f file.yml
# create will error if exists, use apply to take down and create
kubectl apply -f file.yml
# delete, (alternative to just deleting a deployment)
kubectl delete -f file.yml

Zero downtime deployments

Rolling, blue-green, canary, rollbacks.

Rolling example. Two existing and two new pods. Adds first new pod, removes first old pod, adds second new pod, removed second old pod.
This happens by default when we run kubectl apply.

Services

Entry point for accessing pods. Labels are used to associate pods with services. Pod, and their IPs, are ephemeral, unlike services, so services are used to abstract this. They do pod load balancing.

Types

1. ClusterIP, default, talks via internal IPs within cluster.
2. NodePort, has IP on node and sets up static port.
3. LoadBalancer, external IP as LB for nodes.
4. ExternalName, service to DNS.

# port forward a deployment or service as well as a pod
kubectl port-forward deployment/[deploymentname] 8080:80
kubectl port-forward service/[servicename] 8080:80

YAML file

apiVersion: v1
kind: Service
metadata:
 name: nginx-clusterip
spec:
 type: ClusterIP
 selector:
  app: my-nginx
 ports:
 - port: 8080
   targetPort: 80

Storage

Volumes are a way of storing data which can be accessed between pods. Similar to how volumes are mounted for containers, but with greater options.

Types

1. emptyDir, stored only during life of pod.
2. hostPath, mounts to nodes filesystem.
3. nfs, mounted to network file system volume on network.
4. configMap/secret, key value pairs for secrets.
5. persistentVolumeClaim, persistent storage, e.g. NFS, cloud.
6. cloud, global storage.
7. plus more…

persistentVolumeClaim

PV, is the persistent volume.

PVC, pv claim, link between the pod and the PV.

Storage class

A way of templating persistent volumes as they can be dynamically created rather than having to contact admin.

ConfigMaps

Way to store config info and provide it to containers, (e.g. env var/secrets). Can be set via ConfigMap manifest, key value pair file using kubectl to upload to kubernetes from-file or from-env-file , individual data values from-literal .

Useful configMap commands

# get a configMap
kubectl get cm [configmapname] -o yaml
# create a configMap from env file
# settings.config
  testEnvVal1=1
  testEnvVal2=2
kubectl create cm [configmapname] --from-env-file=setting.config

Secrets

Can be created on an individual bases via kubectl, from a file or separate command for TLS certs.

# create a secret
kubectl get secrets
# create a secret
kubectl create secret generic [configmapname] --from-literal=pwd=my-password

YAML examples

kubernetes/examples

Course

All information taken from Dan Wahlin’s excellent pluralsight course titled: Kubernetes from Developers: Core Concepts

Kubernetes for Developers: Core Concepts