[Readiness Probe]
Readiness Probe checks if an application inside a pod is ready to serve traffic.
If the Readiness Probe fails, Kubernetes will remove the pod from the pool of service endpoints until it passes. This ensures that only healthy pods receive traffic.
If a container does not provide a readiness probe, the default state is Success.
It is used to find out if the app is ready to handle requests.
It tell when the container is ready to start traffic.
It indicates whether the application running in the container is ready to accept requests.
It indicates whether applications running in a container are ready to receive traffic.
Services matching the pod are allowed to send traffic to it and if not the endpoints controller removes the pod from all matching Kubernetes Services.
It indicates app is ready to serve traffic.
By using a readiness probe, Kubernetes waits until the app is fully started before it allows the service to send traffic.
Kubernetes makes sure the readiness probe passes before allowing a service to send traffic to the pod.
If a readiness probe starts to fail, Kubernetes stops sending traffic to the pod until it passes.
If the readiness probe fails, the endpoints controller removes the Pod's IP address from the endpoints of all Services that match the Pod.
* If it succeeds, services matching the pod continue sending traffic to the pod.
* If it fails, the endpoints controller removes the pod from all Kubernetes Services matching the pod.

[Liveness Probe]
Liveness Probe checks if an application inside a pod is running.
If the Liveness Probe fails, Kubernetes will kill the pod and restart it.
This is useful for detecting and remedying situations where an application might be stuck or deadlocked.
If a container does not provide a liveness probe, the default state is Success.
It is used to determine whether a container is running OR not.
It is used to find out if the app is running correctly OR not.
It is responsible for restarting a container, if it in a deadlock.
It is used to find out if the app has crashed/deadlocked.
It indicates app is alive or dead.
If app is alive, then kubelet leaves it alone. If app is dead that means unhealthy, then the kubelet will kills the container and the container is restarted with the pod restartPolicy.
If liveness probe failed then the kubelet will try to restart the pod on the same node according to the restartPolicy configured for the pod.
* If it succeeds, no action is taken and no events are logged.
* If it fails, the kubelet kills the container and it is restarted in line with the pod restartPolicy.

[Startup Probe]
If a container does not provide a startup probe, the default state is Success.
It indicates whether the application within the container is started.
It tells when the container application has started.
It is very useful on slow-start applications then Startup probe allows our application to become ready.
It is use to find out if the app is initialized or not.
It indicates whether the application running in the container has fully started.
All other probes are disabled if a startup probe is provided until it succeeds.
It has higher priority over the two other probe types, which are disabled by Kubernetes until the startup probe is successful.
If the startup probe fails, the kubelet kills the container and the container is restarted with the pod restartPolicy.
* If it succeeds, other probes start their diagnostics. When a startup probe is defined other probes do not operate until it succeeds.
* If it fails, the kubelet kills the container and is restarted in line with the pod restartPolicy.
When the app is in the initializing stage the Startup Probe returns some http error code from 400 to 599.
As soon as the app is initialized the Startup Probe will return a http success code from 200 to 299. This means the probe succeeded, now the startup probe will not run again for the lifetime of that container.
If startup probe fail then kubelet will kill the container and restart the pod.

# Probes Handlers
● exec
Executes a specified command inside the container.
It runs a command inside the container.
It can run a command that can check whether or not app is healthy.
If the command returns with exit status code 0, then the container is marked as healthy.
● httpGet
It sends an HTTP Get request as a probe to the path defined, HTTP response code determines whether the probe is successful or not.
It performs an HTTP GET request against the Pod's IP address on a specified port and path.
It is considered successful if the response has a status code greater than or equal to 200 and less than 400 range indicates success, it marks the app as healthy. Any other code indicates failure.
* host - Host/IP to connect to (default: pod IP).
         Host name to connect to, defaults to the pod IP.
* scheme - Scheme to use when making the request (default: HTTP).
           Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
* path - Path to access on the HTTP server. Defaults to /.
* httpHeaders - An array of headers defined as header/value map.
                Custom headers to set in the request. HTTP allows repeated headers.
* port - Name or number of the port to access on the container. Number must be in the range 1 to 65535.
The kubelet sends an HTTP GET request to the server that is running in the container and listening on port no.
If the handler for the server's FILE location (eg: /healthz OR /index.html) path returns a success code, the kubelet considers the container to be alive and healthy. If the handler returns a failure code, the kubelet kills the container and restarts it.
The kubelet periodically perform HTTP Get requests on path FILE location (eg: /healthz OR /index.html) on port NO to determine if the container is still healthy.
● tcpSocket
It determine if the port is open, it is considered a success.
It tries to establish a TCP connection on the specified port.
It performs a TCP connection to check against the Pod's IP address on a specified port.
It is considered successful if the port is open.
It connects to a defined port to check if the port is open.
If it can establish a connection, the container is considered healthy and if it can’t it is considered unhealthy.

# Probes Parameters
● initialDelaySeconds
It specifies how long the probe has to wait to start after the container starts.
Number of seconds after the container has started before probes are initiated.
It specifies that the kubelet that it should wait NO seconds before performing the probe.
How many seconds to wait after the container has started.
Probes start running after initialDelaySeconds after container is started.
It instructs the probe operation to wait for a specified number of seconds before starting.
This is useful when your container needs some time to start and be fully functional.
Seconds after the container started and before probes start.
The default value is 0.
# Syntax :->                    initialDelaySeconds: NO
● periodSeconds
It specifies that the kubelet should check perform a any type of probe every NO seconds.
Wait time between probe executions.
Frequency of the pod.
The default value is 10.
# Syntax :->                    periodSeconds: NO
● timeoutSeconds
It will detect that the GET request is taking too long to get answered.
It will ensure that the GET request gets a response in no more than NO seconds.
When the probe exceeded NO seconds, instead it cancelled the request. Incoming connections are routed to other healthy pods.
Timeout for probe responses.
The default value is 1.
# Syntax :->                    timeoutSeconds: NO
● successThreshold
Threshold needed to mark the container healthy.
It attempts until the probe is considered successful after the failure.
How many success results received to transition from failure to a healthy state.
The default value is 1.
# Syntax :->                    successThreshold: NO
● failureThreshold
Threshold needed to mark the container unhealthy.
How many failed results received to transition from healthy to failure state.
The default value is 3.
# Syntax :->                    failureThreshold: NO
