Notes from episode 5 of TGIK: Pod Params and Probes
Over the past few months I’ve been trying to learn everything there is to know about Kubernetes. Kubernetes is an amazing technology for deploying and scaling containers though it comes with a cost. It’s an incredibly complex piece of software and there are a ton of bells and whistles to become familiar with. One way that I’ve found for coming up to speed is Joe Beda’s weekly TGIK live broadcast. This occurs each Friday at 4PM EST and is CHOCK full of fantastic information. In episode five Joe talks about pod parameters and probes. You can watch it here:
Here are some of my takeways from the episode:
ReplicaSets are layered on top of pods.
Deployments are layered on top of ReplicaSets.
The kubectl run –generator option can be used to generate specific types of resources at runtime.
–generator=run/v1 creates a replication controller.
–restart=Always creates a deployment.
–restart=OnFailure creates a job.
–schedule= creates a cron job.
Taking the base API object produced by kubectl get pod NAME -o yaml won’t work out of the box due to system-specific information being present (e.g., resourceVersion).
The export option provides a better way to create a base YAML file to work off of (still pretty chatty):
$ kubectl get pods ubuntu -o yaml --export
To get the base object kubectl sends to the API server you can use:
$ kubectl run ubuntu --image=ubuntu -o yaml --dry-run
The kubectl “-w” option allows you to watch for changes to a resource:
$ kubectl get pods ubuntu -w -o wide
The restart policy controls what to do when a pod fails. Three options are available though not all resource support these options:
Always
OnFailure
Never
Pods are assigned to a node for their entire lifetime.
Replica sets allow you to define the number of pods you want. Kubernetes will ensure that this number is always available. The replication controller is the Kubernetes entity responsible for managing replica sets.
Kubernetes doesn’t reschedule pods. It recreates them.
If you set RestartPolicy to Never the pod won’t be restarted. But if the pod fails it will get re-scheduled to another node.
apply is a declarative management approach where the changes you applied to a live object are maintained even if you applied other changes to the object.
Horizontal pod autoscaler allows you to automatically scale the number of pods in a replication controller, deployment or replica set based on a set of criteria (e.g., CPU utilization).
Pod format when replica sets are used:
REPLICASET-HASHOFDESCRIPTIONOFREPLICASET-UNIQUEID
Two types of probes:
readiness probes indicate that the resource is ready to receive traffic.
liveness probes indicate that the resource is functioniong correctly and should continue receiving traffic.