My take on Kubernetes
— kubernetes, docker — 3 min read
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 baseFROM node:current-slim
# copy the application and dependencies from the current directory # into the /src directoryCOPY . /srcRUN cd /src; npm install
# informs Docker that the container listens on the specified network ports # at runtimeEXPOSE 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 andrewchaadocker image push andrewchaa/qsk-course:1.0
Deploying the first application
# nginx.yamlapiVersion: v1kind: 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 podkubectl port-forward --address 0.0.0.0 nginx 3000:80kubectl get pods
# stream logskubectl 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 -- bashkubectl exec -it apache -- shroot@nginx:/#
Killing pods
kubectl delete pod nginxkubectl 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/v1kind: Deploymentmetadata: name: hellok8s # unique name for the deploymentspec: 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