My take on Kubernetes
My learnings along the way to Kubernetes heaven.
Masters and Nodes
Machines in a Kubernetes cluster are referred to as Nodes. A Kubernetes cluster contains two types of Nodes:
-
Master Nodes
-
Worker Nodes
Usually, Master Nodes are referred to as “Masters” and Worker Nodes are called “Nodes”. Maters host the control plane and Nodes are where you run user applications.
Hosted Kubernetes
Workflow
Breaking down the Dockerfile
# use the node:current slim image as the base
FROM node:current-slim
# copy the application and dependencies from the current directory
# into the /src directory
COPY . /src
RUN cd /src; npm install
# informs Docker that the container listens on the specified network ports
# at runtime
EXPOSE 8080
CMD cd /src && node ./app.js
Containerisation
The process of building an application into a container image is called containerisation.
docker image build -t andrewchaa/qsk-course:1.0 .
docker image ls
Host the image on a registry
docker login --username andrewchaa
docker image push andrewchaa/qsk-course:1.0
Deploying the first application
# nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx-container
image: registry.hub.docker.com/library/nginx
kubectl apply -f nginx.yaml
# port forward to open the pod
kubectl port-forward --address 0.0.0.0 nginx 3000:80
kubectl get pods
# stream logs
kubectl logs --follow nginx
The workers
Where our applications actually run.
The master
In the reconciliation loop, the master compares the current state with the desired state and makes the necessary changes
Difference between pods and containers
Multiple containers can run inside a single pod. A way to group containers
Executing commands in a container running in the pod
kubectl exec nginx -- ls
kubectl exec -it nginx -- bash
kubectl exec -it apache -- sh
root@nginx:/#
Killing pods
kubectl delete pod nginx
kubectl delete -f nginx.yaml
kubectl get pods
Deployment
-
Scale the applications by increasing or decreasing the number of replicas
-
Roll out new versions of the application without downtime
-
Easily rollback bad releases
apiVersion: apps/v1
kind: Deployment
metadata:
name: hellok8s # unique name for the deployment
spec:
replicas: 1
selector: # manage all the pods tha have a label called app with
matchLabels: # the value hellok8s
app: hellok8s
template:
metadata:
labels:
app: hellok8s
spec:
containers:
- image: brianstorti/hellok8s:v1
name: hellok8s-container
kubectl apply -f deployment.yaml
# deployment.apps/hellok8s created
kubectl get deployments
# NAME DESIRED CURRENT UP-TO-DATE AVAILABLE
# hellok8s 1 1 1 1
kubectl get pods
# NAME READY STATUS RESTARTS
# hellok8s-6678f66cb8-42jtr 1/1 Running 0
kubectl port-forward hellok8s-78997b6f8f-zwv62 --address 0.0.0.0 3004567
Controlling the Rollout Rate
-
maxSurge
: define how many pods we can have exceeding our desiredreplica
count. The default value is 25% -
maxUnavailable
: defines how many pods we can have below the desired count
spec:
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
Probing bad releases
readinessProbe
: make the container ready to start receiving requests only after it has received a specified number of successful responses
spec:
spec:
containers:
- image: brianstorti/hellok8s:buggy # Adding a buggy version
name: hellok8s-container
readinessProbe:
periodSeconds: 1
successThreshold: 5
httpGet:
path: /
port: 4567
livenessProbe
: Kubernetes will keep calling this probe periodically to make sure the pod is healthy.
spec:
spec:
containers:
- image: brianstorti/hellok8s:v2
name: hellok8s-container
readinessProbe:
periodSeconds: 1
successThreshold: 5
httpGet:
path: /
port: 4567
livenessProbe:
httpGet:
path: /
port: 4567
Comments