CKAD studying - application observability and maintenance
API Deprecation Policy
-
read up on Kubernetes API -> https://kubernetes.io/docs/concepts/overview/kubernetes-api/
-
deprecation - process of providing advanced warning of changes to the API, giving consumers time to update their code/processes
-
read up on the deprecation policy -> https://kubernetes.io/docs/reference/using-api/deprecation-policy/
-
apiVersion - field on a Kubernetes object that indicates which version of the API it is designed to be compatible with
-
deprecation window - period after deprecation that API versions are still supported
- GA (general availability) versions are supported the longer of 12 months or 3 releases after being deprecated
-
migration guide - details on API changes with each version of Kubernetes
Probes and Health Checks
-
Probe - part of the container spec that allows you to customize how Kubernetes detects the state of a container
- probes can run a command inside the container, e.g. making an HTTP request or attempting a TCP socket connection
-
read up on container probes -> https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
-
how to configure -> https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
Types of Probes
- Liveness - probes that check whether a container is healthy; unhealthy means it needs restarted
sample Pod with a livenessProbe
that uses a shell command to check healthiness
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: k8s.gcr.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
sample Pod with a livenessProbe
that uses HTTP to check healthiness
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: k8s.gcr.io/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
- Readiness - probes that determine when a container is fully started up and ready to receive user traffic
sample Pod with a readinessProbe
and livenessProbe
that tries making a TCP connection to check readiness and healthiness
apiVersion: v1
kind: Pod
metadata:
name: goproxy
labels:
app: goproxy
spec:
containers:
- name: goproxy
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
- Startup - probes that check container health during startup for slow-starting containers
Monitoring
-
monitoring - process of gathering data on the performance of containerized applications
-
access data with Metrics API
- install Metrics Server (component that gathers the metrics data for the Metrics API to return) -> https://github.com/kubernetes-sigs/metrics-server ->
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
- use
kubectl top
to view metrics data (Pod resource usage) once the Metrics Server gathered it (takes a few moments to gather data)
- install Metrics Server (component that gathers the metrics data for the Metrics API to return) -> https://github.com/kubernetes-sigs/metrics-server ->
Container Logging
-
container log - stores stdout/stderr console output for each container
kubectl logs [-f] [-p] POD [-c CONTAINER]
- use to view logs- https://jamesdefabia.github.io/docs/user-guide/kubectl/kubectl_logs/
- Data written to standard output will appear in the container log
Debugging
-
high-level process
- locate the problem - identify which component(s) are not working
- gather info on broken components
- make changes
-
check object status - quick way to locate broken Pod in the cluster
- use
kubectl get pods
to check the status of all Pods in a Namespace - https://jamesdefabia.github.io/docs/user-guide/kubectl/kubectl_get/
- use
-
check object configuration - gather more information on the relevant object(s)
- use
kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME)
or view the full object manifest
- use
-
check logs - container level and potentially cluster level to get more insight into what’s going on
- use
kubectl logs [-f] [-p] POD [-c CONTAINER]
to view container logs
- use