Kubernetes - Pod and Container Configuration

Instead of using default values we can add some configs rudimentary checks or application specific check etc.

Probes

These probe conditions will be set by the application developers it self

Liveness Probe

• Many application running for long periods of time eventually transition to broken states, and cannot recover except being restarted.

• Kubernetes provides liveness probes to detect and remedy such situations.

• Whether the application is running or not

• upon failure - container will be restarted according to policy

Readiness Probe

• Applications running for long period of time eventually transition to broken states, and should be taken out of service so the traffic no longer routes to them.

• Kubernetes provides readiness probes to detect and handle such situations.

• whether the container is ready to accept the traffic or ready to service requests

• upon failure - pod is removed from the service so no request are sent to it.

Probe Handlers

• Exec

  • run an command inside the container

  • success: return code from command is 0

• TCPSocket

  • TCP check

  • success: port is open and accepting the connection

• HTTPGet

  • invoke HTTP GET against url

  • success: Any 2xx or 3xx HTTP response

Probe Options

• initialDelaySeconds

  • how long to delay probing after container started

• periodSeconds

  • how often to perform the probe; default = 10

• timeoutSeconds

  • default = 1

Resource Management

The scheduler need to know where the pod to run according to the resource available

Resources

• CPU Unit (if we mention 1 CPU unit in k8s it maps to below values)

  • 1 AWS vCPU

  • 1 GCP Core

  • 1 Azure vCore

  • 1 Hyperthread on a bare-metal Intel processor with HyperThreading

• CPU Value

  • 0.1 == 100m

  • one hundred millicpu / 10% of CPU unit

• Memory Unit

  • E, P, T, G, M, K - 10 base

  • Ei, Pi, Ti, Gi, Mi, Ki - power of 2 based

• Memory Values

  • 1Gi == 1.073741824 GB

  • 1G == 1.0 GB

Resource Requests

• Can be thought of as “minimum resource required” specification

• helps Kubernetes more efficiently schedule pods

• Pods will be schedules if the sum of resource requests of the scheduled Containers is less then the capacity of the node.

• resource: requests: memory: “1Gi” cpu: “1”

Resource Limits

• Protect against a runaway app

• If a container exceeds its memory limit, it might terminated

• If a container exceeds its memory requests, it likely that the pod will forcefully terminated whenever the node runs out of memory

• resource: limits: memory: “1Gi” cpu: “1”