This topic is weighed 5% on exam

Understand how to monitor all cluster components.

Understand how to monitor applications.

  • liveness probes - periodically executed and container restarted if probe fail
    • livenessProbe
    • set initialDelaySeconds: 15 (so container has time to spin up before probing starts)
      • Three different mechanisms:
        • An HTTP GET probe performs an HTTP GET request on the container’s IP address, a port and path you specify. If the probe receives a response, and the response code doesn’t represent an error (in other words, if the HTTP response code is 2xx or 3xx), the probe is considered successful. If the server returns an error response code or if it doesn’t respond at all, the probe is considered a failure and the container will be restarted as a result.
        • A TCP Socket probe tries to open a TCP connection to the specified port of the container. If the connection is established successfully, the probe is successful. Otherwise, the container is restarted.
        • An Exec probe executes an arbitrary command inside the container and checks the command’s exit status code. If the status code is 0, the probe is successful. All other codes are considered failures.
      • readiness probes - periodically executed and determines if pod is read to receive client requests
        • Three types of probes:
          • An Exec probe, where a process is executed. The container’s status is determined by the process’ exit status code.
          • An HTTP GET probe, which sends an HTTP GET request to the container and the HTTP status code of the response determines whether the container is ready or not.
          • A TCP Socket probe, which opens a TCP connection to a specified port of the container. If the connection is established, the container is considered ready.
        • if pod reports not ready, pod is removed from service
      • Liveness probes keep pods healthy by killing off unhealthy containers and replacing them with new, healthy ones, whereas readiness probes make sure that only pods that are ready to serve requests receive them.

Manage cluster component logs.

  • Components running under systemd write logs to journald
    • containerised components log under /var/log
      • Master (/var/log or /var/log/containers)
        • /var/log/kube-apiserver.log – API Server, responsible for serving the API
        • /var/log/kube-scheduler.log – Scheduler, responsible for making scheduling decisions
        • /var/log/kube-controller-manager.log – Controller that manages replication controllers
      • Worker Nodes (/var/log or /var/log/containers)
        • /var/log/kubelet.log – Kubelet, responsible for running containers on the node
        • /var/log/kube-proxy.log – Kube Proxy, responsible for service load balancing

Manage application logs.