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:
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.
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
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
Where our applications actually run.
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:/#
kubectl delete pod nginx kubectl delete -f nginx.yaml kubectl get pods
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 desired
replicacount. 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