kuberesources.md

https://pmcgrath.net/using-pod-security-policies-with-kubeadm

Limits & Resources

2 types of resources: CPU and memory

Resource request: requests is what the container/pod is guaranteed to get. The scheduler will only place the pod on a node that will give it that resource. Defaults are 0.5 CPU and 256 MB RAM

Resource limits: limits ensure the container/pod never goes above a specified value. CPU will be throttled and if more memory will be consumed than the limit the OOM will kick in and the pod will be restarted.

apiVersion: v1
kind: Pod
spec:
  containers:
    - name: nginx
      image: nginx:alpine
      resources:
        requests:
          memory: "1Gi"
          cpu: 1
        limits:
          memory: "2Gi"
          cpu: 2

You can specify a default for request and limits for a namespace:

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 512Mi
    defaultRequest:
      memory: 256Mi
    type: Container

Resource Quotas

Resource quotas are used to slice up the resources for diffent teams in a multi-tenant cluster based on the namespace they are using. Example: Team A gets 20 cores and 10 GB RAM assigned to their namespace through a ResourceQuota object which tracks and ensures it does not exceed resource limits defined in the ResourceQuota.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: demo
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: 2Gi
    limits.cpu: "10"
    limits.memory: 4Gi

LimitRange

Works well in conjunction with Resource Quotas. While a Quota looks at the whole namespace LimitRange enforce on individual containers/pods.

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-min-max
  namespace: demo
spec:
  limits:
  - max:
      cpu: "800m"
      memory: "800Mi"
    min:
      cpu: "200m"
      memory: "200Mi"
    default:
      cpu: "500m"
      memory: "500Mi"
    defaultRequest:
      cpu: "200m"
      memory: "200Mi"
    type: Container

Health Checks & Readniness Probes

Create custom health checks. Two types:

• Readiness probe - lets k8 know when your app is ready to serve traffic
• Liveness probe - lets k8 know if your app is alive or dead. If dead, k8 will restart it.

We can define three types of probes (of the two above):

• HTTP
• Command
• TCP

Example:

spec:
  containers:
  - name: liveness
    livenessProbe:
      httpGet:
        path: /health
        port: 8080