Kubernetes(k8s)— Concepts — Containers

Containers

Each container that you run is repeatable; the standardization from having dependencies included means that you get the same behavior wherever you run it.

Containers decouple applications from the underlying host infrastructure. This makes deployment easier in different cloud or OS environments.

Each node in a Kubernetes cluster runs the containers that form the Pods assigned to that node. Containers in a Pod are co-located and co-scheduled to run on the same node.

1. Container images

A container image is a ready-to-run software package containing everything needed to run an application: the code and any runtime it requires, application and system libraries, and default values for any essential settings.

1.1 Image names

Container images are usually given a name such as pause, example/mycontainer, or kube-apiserver. Images can also include a registry hostname; for example: fictional.registry.example/imagename, and possibly a port number as well; for example: fictional.registry.example:10443/imagename.

If you don’t specify a registry hostname, Kubernetes assumes that you mean the Docker public registry.

After the image name part you can add a tag (in the same way you would when using with commands like docker or podman). Tags let you identify different versions of the same series of images.

1.2 Updating images

1.2.1 Image pull policy

• IfNotPresent
  the image is pulled only if it is not already present locally.

• Always
  every time the kubelet launches a container, the kubelet queries the container image registry to resolve the name to an image digest. If the kubelet has a container image with that exact digest cached locally, the kubelet uses its cached image; otherwise, the kubelet pulls the image with the resolved digest, and uses that image to launch the container.

• Never
  the kubelet does not try fetching the image. If the image is somehow already present locally, the kubelet attempts to start the container; otherwise, startup fails. See pre-pulled images for more details.

Default image pull policy

if you omit the imagePullPolicy field, and you specify the digest for the container image, the imagePullPolicy is automatically set to IfNotPresent.
if you omit the imagePullPolicy field, and the tag for the container image is :latest, imagePullPolicy is automatically set to Always;
if you omit the imagePullPolicy field, and you don’t specify the tag for the container image, imagePullPolicy is automatically set to Always;
if you omit the imagePullPolicy field, and you specify the tag for the container image that isn’t :latest, the imagePullPolicy is automatically set to IfNotPresent.

1.2.2 ImagePullBackOff

The status ImagePullBackOff means that a container could not start because Kubernetes could not pull a container image
he BackOff part indicates that Kubernetes will keep trying to pull the image, with an increasing back-off delay.

Kubernetes raises the delay between each attempt until it reaches a compiled-in limit, which is 300 seconds (5 minutes).

1.3 Serial and parallel image pulls

you can set the field serializeImagePulls to false in the kubelet configuration.

1.3.1 Maximum parallel image pulls

When serializeImagePulls is set to false, the kubelet defaults to no limit on the maximum number of images being pulled at the same time. If you would like to limit the number of parallel image pulls, you can set the field maxParallelImagePulls in kubelet configuration.

1.4 Multi-architecture images with image indexes

Kubernetes itself typically names container images with a suffix -$(ARCH). For backward compatibility, please generate the older images with suffixes.

1.5 Using a private registry

1.5.1 Configuring nodes to authenticate to a private registry

1.5.2 Kubelet credential provider for authenticated image pulls

1.5.3 Interpretation of config.json

2. Container Environment

2.1 Container environment

The Kubernetes Container environment provides several important resources to Containers:

• A filesystem, which is a combination of an image and one or more volumes.
• Information about the Container itself.
• Information about other objects in the cluster.

2.1.1 Container information

hostname

The Pod name and namespace are available as environment variables through the downward API.

User defined environment variables from the Pod definition are also available to the Container, as are any environment variables specified statically in the container image.

2.1.2 Cluster information

3. Runtime Class

RuntimeClass is a feature for selecting the container runtime configuration. The container runtime configuration is used to run a Pod’s containers.

3.1 Motivation

You can set a different RuntimeClass between different Pods to provide a balance of performance versus security.

3.2 Setup

3.2.1 Configure the CRI implementation on nodes

3.2.2 Create the corresponding RuntimeClass resources

# RuntimeClass is defined in the node.k8s.io API group
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  # The name the RuntimeClass will be referenced by.
  # RuntimeClass is a non-namespaced resource.
  name: myclass 
# The name of the corresponding CRI configuration
handler: myconfiguration 

3.3 Usage

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

3.3.1 CRI Configuration

• containerd
  /etc/containerd/config.toml

• CRI-O
  /etc/crio/crio.conf

3.4 Scheduling

By specifying the scheduling field for a RuntimeClass, you can set constraints to ensure that Pods running with this RuntimeClass are scheduled to nodes that support it. If scheduling is not set, this RuntimeClass is assumed to be supported by all nodes.

3.4.1 Pod Overhead

Pod overhead is defined in RuntimeClass through the overhead field.

4. Container Lifecycle Hooks

4.1 Container hooks

• PostStart
• PreStop

4.1.1 Hook handler implementations

There are two types of hook handlers that can be implemented for Containers:

Exec - Executes a specific command, such as pre-stop.sh, inside the cgroups and namespaces of the Container. Resources consumed by the command are counted against the Container.
HTTP - Executes an HTTP request against a specific endpoint on the Container.

4.1.2 Hook handler execution

the Kubernetes management system executes the handler according to the hook action, httpGet and tcpSocket are executed by the kubelet process, and exec is executed in the container.

If either a PostStart or PreStop hook fails, it kills the Container.

4.1.3 Hook delivery guarantees

Hook delivery is intended to be at least once.

4.1.4 Debugging Hook handlers

If a handler fails for some reason, it broadcasts an event. For PostStart, this is the FailedPostStartHook event, and for PreStop, this is the FailedPreStopHook event.

kubectl describe pod lifecycle-demo