Skip to main content

Kubernetes in Action Book

Chapter - Introducing Kubernetes API Objects​

An example of parsing yaml files using yq

kubectl get node kind-control-plane -o yaml | yq e ".status.nodeInfo"

Status Conditions​

Understand the difference between lastHeartbeatTime vs lastTransitionTime under .status.conditions

If a node starts to behave strangely, check the conditions.

kubectl get node kind-control-plane -o yaml | yq e ".status.conditions"

Chapter - Running worklodas in Pods​

5.1 - Understanding PODs​

Understanding why we need PODs​

  • POD - is a running instance of an application
  • Each container is like an isolated computer or virtual machine.
  • Running multiple processes in a container makes it difficult to manage the container, hence the POD is introuduced.
  • POD is a wrapper around the containers. Related containers can be grouped together in a POD.
  • PODs are the smallest unit of deployment in Kubernetes.
  • POD allows inter connected containers to share resources and communicate with each other.
  • POD allows related containers to be managed as a single unit.
  • Container run time restarts the container only when the root process dies.
  • Containers inside a POD does not share PID namespace, hence they can not send signals to each other.
  • ... signals like SIGINIT, SIGTERM, SIGKILL etc...
  • Its the sharing of namespaces that gives the processes running in different containers inside a POD the impression that they are are running together eventhough they are running in separate containers.

Organizing Containers into PODs​

  • Frontend POD
  • Backend POD
  • Splitting the frontend and backend into separate PODs allows Kubernetes to run them on different nodes, which improves the utilization of hardware resources, horizontal scaling.
  • Sidecar containers are used to provide additional functionality to the main container. ex: logging, monitoring, debugging, rverse proxy (to convert https to http and forward to main container).

5.2 - Creating PODs from YAML​

  • kubectl run kiada --image=santosharakere/kiada:0.1 --dry-run=client -o yaml
  • kubectl run kiada --image=santosharakere/kiada:0.1 --dry-run=client -o yaml > test.yaml
  • kubectl apply -f pod.kiada.yaml
  • kubectl get pod kiada -o yaml
  • kubectl get pod kiada
  • kubectl get pod kiada -o wide
  • kubectl describe pod kiada
  • kubectl get events

5.3 - Interacting with PODs and Application​

Kubernetes network model dictates that each POD should be accessible from any other POD in the cluster. Each Node can reach POD in any other Node in the cluster.

  • docker exec -it kind-worker bash

Run a bash container on one of the Nodes and try to access the POD running on any of the Node in the cluster.

  • kubectl run --image=curlimages/curl -it --restart=Never --rm client-pod curl 10.244.1.2:8080
  • curl 10.244.1.2:8080

To open a communication path with the POD, start a proxy on your local computer which forwards your local computer's port to the POD's port.

  • kubectl port-forward kiada 8080:8080 long communication path
  • curl localhost:8080 in a separate terminal
  • port-forward can also be used with Services
  • kubectl logs kiada -f stream application logs in realtime, current container logs
  • kubectl logs kiada --previous -f previous container logs
  • kubectl logs kiada --timestamps=true -f with timestamps
  • kubectl logs kiada --timestamps -f for boolean flags, the value can be omitted
  • kubectl logs kiada --since=12m filter by time
  • kubectl logs kiada --since-time=2023-09-17T18:30:00Z filter by time
  • kubectl logs kiada --tail=10 last several lines
  • kubectl logs kiada --tail 10 equals (=) can be omitted
  • Restart the command when the logs are rotated or a new container is created
  • Deleting a POD will delete the logs
  • kubectl cp kiada:html/index.html /tmp/index.html
  • cp /tmp/index.html kiada:html
  • kubectl exec kiada -- ps aux execute any binary present in the container
  • kubectl exec kiada -- curl -s localhost:8080 withuout --, -s is interprested an an argument to kubectl
  • kubectl exec -it kiada -- bash
  • kubectl debug -it kiada --image=busybox --target=kiada
  • kubectl attach kiada
  • kubectl apply -f pod.kiada-stdin.yaml
  • kubectl attach -i kiada-stdin

5.4 - Running multiple containers in a POD​

  • Envoy Proxy - https://www.envoyproxy.io/
  • kubectl port-forward kiada-ssl 8080 8443 9901
  • curl https://localhost:8443 --insecure
  • curl https://localhost:8443 -k
  • curl http://localhost:8080
  • curl https://example.com:8443 --resolve example.com:8443:127.0.0.1 --cacert kiada-ssl-proxy-0.1/example-com.crt
  • kubectl logs kiada-ssl -c kiada -f
  • kubectl logs kiada-ssl --container kiada -f
  • kubectl logs kiada-ssl --container envoy -f
  • kubectl logs kiada-ssl --all-containers
  • kubectl exec -it kiada-ssl -c envoy -- bash

5.5 - Running additional containers at POD startup​

Introducing init Containers​

  • Init containers are run in sequence, one after the other
  • They must all finish successfully before the main containers of the POD is/ are started
  • Initialize files in the volume before the main container starts
  • Initialize PODs networking system
  • Delay the start of main container until a pre-condition is met
  • Notify an external service that the POD is about to start

Adding init Containers to a POD​

  • kubectl apply -f pod.kiada-init.yaml

Inspecting init Containers​

  • kubectl logs kiada-init -c network-check
  • kubectl apply -f pod.kiada-init-slow.yaml
  • kubectl exec -it kiada-init-slow -c init-demo -- sh

5.6 - Deleting PODs and Other Objects​

Deleting a POD by name​

  • kubectl delete pod kiada
  • kubectl delete pod kiada --wait=false
  • Knowing exactly how containers are shut down is important, if you want to give good experience to your clients.
  • You an not stop and start a POD. You can only delete and recreate it
  • kubectl delete pods kiada-init kiada-init-slow delete multiple PODs

Deleting Objects defined in the manifest file​

  • kubectl delete -f pod.kiada-ssl.yaml
  • kubectl delete -f pod.kiada-ssl.yaml,pod.kiada.yaml
  • kubectl apply -f Chappter05/
  • kubectl delete -f Chappter05/
  • kubectl delete -f Chappter05/ --recursive if the directory contains sub-directories

Deleting all PODs​

  • kubectl delete pods --all

Deleting objects using all keyword​

  • kubectl delete all --all
  • kubectl delete events,all --all

Chapter 6 - Managing the POD Lifecycle​

List of Yaml files used in order​

  1. pod.kiada.yaml
  2. pod.kiada-liveness.yaml

6.1 - Understanding the POD's status​

Understanding the POD phase​

  • kubectl apply -f pod.kiada.yaml
  • kubectl get pod kiada -o yaml | yq e '.status.phase'

Understanding the POD conditions​

  1. PodScheduled
  2. Initialized
  3. ContainersReady
  4. Ready
  • kubectl get pod kiada -o yaml | yq e '.status.conditions'

Understanding the Container status​

  • kubectl get pod kiada -o yaml | yq e '.status.containerStatuses'
  • init containers will have their status reported under initContainerStatuses

6.2 - Keeping Containers Healthy​

Understanding Container Auto Restart​

Checking the Container's state using Liveness Probe​

Creating HTTP GET Liveness probe​

Observing Liveness Probe in action​

kubectl exec kiada-liveness -c envoy -- tail -f /tmp/envoy.admin.log

kubectl logs kiada-liveness -c envoy -p

Using the exec and tcpSocket liveness probe types​

Using a startup probe when application is slow to start​

Creating effective liveless probe handlers​

6.3 - Executing actions at Container startup and shutdown​

Using post-start hooks to perform actions when the container starts​

Using pre-stop hooks to run a process just before the container terminates​

6.4 - Understanding the POD's lifecycle​

Understanding the initialization stage​

Understanding the run stage​

Understanding the termination stage​

Visualizing the full lifecycle of the PODs containers​

Other Commands​

  • kubectl describe node kind-worker is more readable and and displays more information
  • kubectl get node kind-worker -o yaml
  • kubectl get events
  • kubectl get events -o wide
  • kubectl get events --field-selector type=Normal
  • kubectl explain events

Notes​

Events are crucial for debugging a cluster.

Controllers reconcile the actual state of the object/ cluster with the desired state. They generate events to reveal what they have done.

Controllers bring the objects to life.

References​