Default location of the kubeconfig file is ~/.kube/config
If the actual MEMORY usage of the container at run time exceeds the limit... The CONTAINER will be killed **Pod will remain, the container will therefore attempt th restart.
If the actual CPU usage of the container at run time exceeds the limit… The CPU will be "clamped”
While the container will continue to run.
---
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi" # **1G = 1000M, 1Gi = 1024M**
cpu: "500m" # **500/1000 of a core (50%) or just "0.5"**
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Commands to check metrics
Note: Enabling the Metrics Server
$ k top pod
NAME CPU(cores) MEMORY(bytes)
po 0m 17Mi
$ k top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
minikube 239m 3% 991Mi 6%
Kubernetes provides two essential mechanisms, readiness and liveness probes, to ensure the health and availability of containers running in a cluster. These probes help Kubernetes determine whether a container is ready to accept traffic and whether it is still alive and functioning properly.
A readiness probe is used to indicate whether a container is ready to serve traffic. It is used by Kubernetes to determine when a container is ready to receive requests from services or other containers. By default, a container is considered ready as soon as it starts running. However, in some cases, an application may require additional time to initialize or perform certain tasks before it can handle incoming requests. Readiness probes help handle such scenarios.
A readiness probe can be defined in the pod's configuration file or deployment specification using the readinessProbe field. It can be configured to perform various types of checks on the container, such as making an HTTP request to a specific endpoint, executing a command inside the container, or simply checking if the container's TCP socket is open on a particular port. If the probe fails, Kubernetes will temporarily remove the container's IP address from the service's load balancer, preventing it from receiving traffic until the probe succeeds.
Example readiness probe configuration in a pod's specification:
yamlCopy code
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: myapp-container
image: myapp-image
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
In this example, the readiness probe performs an HTTP GET request to the /healthz endpoint of the container, expecting a successful response (HTTP status code 200). The probe will start after an initial delay of 10 seconds and then be repeated every 5 seconds. If the probe fails, the container will be marked as not ready, and Kubernetes will stop sending traffic to it until the probe succeeds.