Pods

Pod:- definition of how to run a container?  

Inspecting POD Resource Usage

Kubernetes Metric Server

In order to view metrics about the resources pods and containers are using, we need an add-on to collect and provide that data. One such add-on is Kubernetes Metric Server. 

kubectl top 

with kubectl top we can view data about resource usage in our pods and nodes. kubectl top also supports flags like --sort-by and --selector

kubectl top pod --sort-by <JSONPATH> -- selector <selector> 

Command to install metric server commont

kubectl apply -f https://raw.githubusercontent.com/linuxacademy/content-cka-resources/master/metrics-server-components.yaml

to check its installed

kubectl get --raw /apis/metrics.k8s.io/

kubectl top pod // to check CPU usage and memory 

kubectl top node  // to check CPU usage of nodes

Application Configuration :-

When we are running applications in kubernetes, we may want to pass dyunamic values to our applications at runtime to control how they behave. This is known as application configuraiton. 

ConfigMaps :-

We can store configuration data in kubernetes using ConfigMaps. 

ConfigMaps store data in the form of a key-value map. configMap data can be passed to our container applications. 

Secrets :-

Secrets are similar to ConfigMaps but are designed to store sensitive data, such as passwords or API keys, more securely. They are created and used similarly to ConfigMaps. 

apiVersion: v1

kind: Secret

metadata:

    name: my-secret

type: Qpaque

data:

  username: user

 passsword: mypass

Environment Variables :- 

We can pass ConfigMap and Secret data to our containers as environment variables. These variables will be visible to our container process. 

Configuration Volumes :-

Configuration data from ConfigMAps and Secrets can also be passed to containers in the form of mounted volumes. This will cause the configuration data to appear in the files available  to the container file system. 

Each top-level key in the configuration data will appear as a file containing al keys below that top-level key. 

Resource Requests :- 

Resource requests allow us to define an amount of resources (such as CPU or memory) we expect a container to use. The kubernetes scheduler will use resource requests to avioid scheduling pods on nodes that do not have enough available resources. 

Note:- Containers are allowed to use more or less than the requested resources. Resources requests only affect scheduling. 

Memory is measured in bytes. CPU is measured in CPU units, which are 1/1000 of one CPU.

resources:

requests:

cpu: "250m"

memory: "128Mi"

Resource limits

Resource limits provide a way for us to limit the amount of resources our containers can use. 

The container runtime is responsible for enforcing these limits, 

and different container runtimes do this differently

Note: Some runtimes will enforce these container processes that attempt to use more than the allowed amount of resources. 

Container Health 

K8s Provides a number of features that allow us to build robust solutions, such as the ability to automatically restart unhealthy containers.

To make the most of these features, k8s needs to be able to accurately determine the status of your applications. This means actively monitoring container health 

Liveness Probes

Liveness probles allow us to automatically determine weather or not a container application is in healthy state

By default k8s will only consider  to be "down" if the container process tops. 

Liveness probes allow us to customize this detection mechanism and make it more sophisticated. 

Startup Probes:-

Startup probes are very similar to liveness probes. However, while liveness probes run constantly on schedule, startup probes run at container startup and stop running once they succeed. 

They are used to determine when the application has successfully started up. Startup probes are especially useful for legacy applications that can have long startup times. 

Readiness Probes 

Readiness probes are used to determine when a container is ready to accept requests.

When you have a service backed by multiple container endpoints, user traffic will not be sent to a particular pod until its containers have all passed the readiness check defined by their readiness

Use readiness probes to prevent user traffic from being sent to pods that are still in the process of starting up. 

Restart Policies

kuberntes can automatically restart containers when they fail. 

Restart polices allow us to customize this behavior by defining when we want a pod containers to be automatically restarted

Restart policies are an important component of self-healing applications, which are automatically repaired when a problem arises. 

There are three possible values for a pods restart policy in k8s: Always, OnFailure, and Never. 

Always :-

Always is the default restart policy in kuberntes,

With this policy, containers will always be restarted if they stop, even if they completed successfully. Use this policy for applications that should always be running. 

OnFailure :- 

The OnFailure restart policy will restart containers only if the container process exits with an error code or the container is deterimined to be unhealthy by a liveness proble. 

Use this policy for applications that need to run successfully and then stop. 

Never :- 

The never restart policy will cause the pod's containers to never be restarted, even if the container exits or liveness probe fails. Use this for applications that should run once and never be automatically restarted

What is multi-Container pod ?

A kubernetes Pod can have one more containers. A pod with more than one container is multi-container pod. 

A multi-container Pod, the container share resources such as network and storage. They can interact with one another, working together to provide functionality. 

Best Practice: Keep containers in separate pods unless they need to share resources. 

Cross-Container interaction

Containers sharing the same Pod can interact with one another using shared resources. 

Network :-

Container share the same networking namespace and can communicate with one another on any port, even if that port is not exposed to the cluster. 

Storage :- 

Containers can use volumes to share data in a Pod. 

Example usage case

We have an application that is hard-coded to write log output to a file on disk.

We add a secondary container to the pod (sometimes called a sidecar) that reads the log file form a shared volume and prints to the console so the log output will appear in the container log. 

Pod - Container - volume - sidecar container 

Init Containers

init Containers are containers that run once during the startup process of a pod. A pod can have any number of init containers, 

and they will each run once (in order) to completion.

init containers1 :

init container run to completion before the next init container or app container startup

init container2 

we can have any number of init containers, and each will run in order.

App Containers

App container will start up only once all init containers have completed 

init Containers :- 

We can use init containers to perform a varitey of startup task.

They can contain and use software and setup scripts that are not needed by your main containers.

They are often useful in keeping your main containers lighter and more secure by offloading startup tasks to a separate container.

Use cases for init containers

Some sample use cases for init containers:

Cause a pod to wait for another k9s resource to be created before finishing startup

Perform sensitive startup steps securely outside of app  containers

populate data into a shared volume at startup 

communicate with another service at startup