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. Different generator
options
create different objects: run-pod/v1 create a pod. run/v1 create a
replication controller. extensions/v1beta1 create a deployment (the
default). job/v1 create a job. batch/v1beta1 create a cron job. *
Different runtime options will create different types of
resources:
--restart=Never creates a pod. --generator=run/v1 creates a replication
controller. --restart=Always creates a deployment. --restart=OnFailure
creates a job. --schedule=
croncreates a cron job. Taking the base API object produced bykubectl get pod NAME -o yamlwon'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. What is the difference between apply and create?: create is an imperative management approach where you tell the API what you want to create, replace or delete. apply is a declarative management ap proach 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. Probe timers and success / fail values: initialDelaySeconds indicates the number of seconds to wait before sending the first probe. periodSeconds indicates how often to probe the resource. timeoutSeconds indicates the number of seconds until the probe times out. successThreshold is the minimum consecutive successes for the probe to be considered successful. failureThreshold is the minimum consecutive failures for the probe to be considered failed. Health checks should be local to the server to avoid upstream resources tainting your pod (and causing a restart). Services are a way to address a set of pods in a unified way. Finding the right metric to auto scale on is really hard problem. Display Kubernetes endpoints:
kubectl get endpoints
- You learn a TON from watching Joe debug issues live!
Things I need to learn more about:
- Autoscaling groups. * Conduct some tests to see how various types of criteria impact the Kubernetes auto scaler.