Kubernetes Objects-Pod in detail

Pod, Service, Volume, and Namespace are considered as the four basic objects within a Kubernetes cluster. A good description of how the cluster on a daily basis looks like can be provided and described in terms of applications, workloads, network resources, and disk space. There are many other containers in Kubernetes that are just combinations of basic objects.

The Pod is the smallest deployment unit in the Kubernetes cluster that can be created and managed. In order to fully understand the implementation principles and best practices of the Kubernetes, you need to make sure you know the Kubernetes implementation principles and best practices, too.

We are going to discuss the Pod in two parts here. The first part will introduce the features that must be understood in order for a Pod to be successful, and the second part will introduce the important events that are found in the life cycle of a Pod, from the inception of the Pod until its final deletion. How the level is being maintained.

This YAML file defines the containers and commands that are running when a Pod begins, and its strategy for restarting, whether the Kubernetes controller can pull it up after the current Pod has an error or if the execution ends. In addition to these more obvious settings, metadata metadata is often very critical for configuring. The name is the unique identifier of the current entity in the Kuberentes cluster, and it can be easily selected by label labels.

apiVersion: v1
kind: Pod
metadata:
  name: string
  namaspace: string
  labels:
  - name: string
  annotations:
  - name: string
spec:
  containers:
  - name: string
    images: string
    imagePullPolice: [Always | Never | IfNotPresent]
    command: [string]
    args: [string]
    workingDir: string
    volumeMounts:
    - name: string
      mountPath: string
      readOnly: boolean
    ports:
    - name: string
      containerPort: int
      hostPort: int
      protocol: string
    env:
    - name: string
      value: string
    resources:
      limits:
        cpu: string
        memory: string
      requests:
        cpu: string
        memory: string
    livenessProbe:
      exec:
        command: [string]
      httpGet:
        path: string
        port: int
        host: string
        scheme: string
        httpHeaders:
        - name: string
          value: string
      tcpSocket:
        port: int
      initialDelaySeconds: number
      timeoutSeconds: number
      periodSeconds: number
      successThreshold: 0
      failureThreshold: 0
    securityContext:
      privileged: false
  restartPolicy: [Always | Never | OnFailure]   
  nodeSelector: object
  imagePullSecrets:
  - name: string
  hostNetwork: false
  volumes:
  - name: string
    emptyDir: {}
    hostPath:
      path: string
    secret:
      secretName: string
      items:
      - key: string
        path: string
    configMap:
      name: string
      items:
      - key: string
        path: string

There are many ideas inside the same Pod that merit special consideration. The container is the first. One or more containers will run concurrently in the pod. They can share resources such as network, storage, CPU, and memory with these containers. We will concentrate on the three principles of Pod containers, volumes, and networks in this section.

Basic usage of Pod

The pod is a series of containers, actually. The specifications for the running of containers in k8s are: the container’s main program must run in the foreground, not in the background. For example, a program in the Go language can directly run a binary file; the main class can be run in a Java language; and a tomcat program can be written as a running script. The application can be converted into a way to run in the foreground. Or via the process management tool of the supervisor, that is, the supervisor operates in the foreground, and the supervisor controls the application to run in the background.

Multiple applications can be put together in a Pod when multiple applications are closely connected, and multiple containers in the same Pod can interact with each other through localhost (Pod can be understood as a virtual Machine, shared network and storage volume)Multiple applications can be put together in a Pod when multiple applications are closely connected, and multiple containers in the same Pod can interact with each other through localhost (Pod can be understood as a virtual Machine, shared network and storage volume)

Pod commands Here

Static pod

The Static Pods are kubelet-managed and exist only on particular Node Pods. No API Server can handle them, no ReplicationController, Deployment, or DaemonSet can be associated with them, and kubelet is unable to verify their health.

Static Pods are always generated by the kubelet and run on the node where the kubelet is located at all times.

You need to set the “-config” kubelet startup parameter, define the directory where the configuration file that kubelet wants to control is stored, and kubelet will periodically search the directory and build operations based on the directory’s .yaml or .json files. Unable to remove the Static Pod via API Server (if it is deleted, it will become pending state). If you need to uninstall the Pod, delete this directory from the yaml or json file.

EXAMPLE:

The configuration directory is /etc/kubelet.d/, and the initialization parameters are configured as follows: — config=/etc/kubelet.d/, and this directory includes static-web.yaml.

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    name: static-web
spec:
  containers:
  - name: static-web
  image: nginx
  ports:
  - name: web
    containerPort: 80

Pod container sharing volume

Several containers in the same Pod will share the amount of storage volume at the Pod level. Volume can be described as multiple forms. It is possible to mount several containers separately, and it is possible to mount the Pod Volume as the appropriate directory within the container.

For example in the case: Pod-level volume: “app-logs” used to write log files to tomcat, busybox used to read log files.

pod-volumes-applogs.yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-pod
spec:
  containers:
  - name: tomcat
    image: tomcat
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: app-logs
      mountPath: /usr/local/tomcat/logs
  - name: pankajapp
    image: pankajapp
    command: ["sh","-c","tailf /logs/catalina*.log"]
    volumeMounts:
    - name: app-logs
      mountPath: /logs
  volumes:
  - name: app-logs
    emptuDir: {}

View log

kubectl logs <pod_name> -c <container_name>
kubectl exec -it <pod_name> -c <container_name> – tail /usr/local/tomcat/logs/catalina.xx.log

Pod configuration management

The Kubernetes v1.2 version provides a unified cluster configuration management solution-ConfigMap.

ConfigMap: Configuration management of container applications

Scenes that can be used:
Created in the container as an environmental variable. 
Set the startup parameters of the startup command of the container (need to be set as environment variables). 
Mount a volume in the form of a file or directory within the container. 
In kubernetes, ConfigMap is stored in the form of one or more key:values for application use. The value of a variable (for example: apploglevel=info) or the content of a full configuration file (for example: server.xml= <?xml…>) may be described.
You can use the yaml configuration file to create a ConfigMap, or use the kubectl create configmap order.

Create ConfigMap

Via yaml file

cm-appvars.yaml

apiVersion: v1
kind: ConfigMap
metadata:
 name: cm-appvars
data:
 apploglevel: info
 appdatadir: /var/data
Common commands
kubectl create -f cm-appvars.yaml
kubectl get configmap
kubectl describe configmap cm-appvars
kubectl get configmap cm-appvars -o yaml

Via kubectl command line

To create a configmap by creating kubectl, use the -from-file or -from-literal parameters to specify the information, and you can specify multiple parameters on a line.
1) You can create a ConfigMap from a file with the -from-file parameter, define a key name, or create a ConfigMap that includes several keys on a single command line.
Kubectl generates the NAME config map —from-file=[key=]source —from-file=[key=]source
2) Build from a directory with parameter -from-file. The name of each configuration file in the directory is set as the key and the value is set to the content of the file.
Kubectl produces the Term configmap —from-file=config-files-dir
3) Create from text through -from-literal, and create the required key=value directly as the ConfigMap content.
Kubectl generates a NAME config map —from-literal=key1=value1 —from-literal=key2=value2=value2=value1=value1
In container applications, there are two ways of using ConfigMap:
Get the content from environment variables in the ConfigMap. 
By volume mounting, install the content in the ConfigMap as a file or directory within the container.

By way of environment variables

ConfigMap yaml file: cm-appvars.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-appvars
data:
  apploglevel: info
  appdatadir: /var/data

Pod yaml file: cm-test-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: cm-test-pod
spec:
  containers:
  - name: cm-test
image: pankajapp
    command: ["/bin/sh","-c","env|grep APP"]
    env:
    - name: APPLOGLEVEL
      valueFrom:
        configMapKeyRef:
          name: cm-appvars
          key: apploglevel
    - name: APPDATADIR
      valueFrom:
        configMapKeyRef:
          name: cm-appvars
          key: appdatadir

Create command:

kubectl create -f cm-test-pod.yaml
kubectl get pods — show-all
kubectl logs cm-test-pod
Restrictions on the usage of ConfigMap 
1. Before Pod, ConfigMap must be developed, 
2.It is also possible to describe ConfigMap as belonging to Namespace. It can be referenced only by Pods in the same namespace. 
3.Kubelet is only supported by Pods that can be handled by the ConfigMap API Server. Unable to reference the Static Pod. 
4.The container can only be installed as a directory when the Pod mounts the ConfigMap, and can not be mounted as a file.

Pod life cycle

Pod status

Pod restart strategy

Description:

Replication Controller, Task, DaemonSet, and Kubelet are the controllers that can handle pods (static Pod).

RC and DaemonSet: Always must be set, and the container must be running on an ongoing basis. 
Job: OnFailure or Never, to ensure that after execution the container does not restart. 
Kubelet: Restart a Pod when it crashes, irrespective of the importance of the RestartPolicy environment, and the Pod does not carry out a health check.

Common state transition scenarios

Pod health check

Two types of probes check the health status of the Pod: LivenessProbe and ReadinessProbe.

ProbeLiveness 
Used to determine whether the container is still alive (running state). 
Kubelet will destroy the container and deal with it according to the container’s restart strategy if the LivenessProbe probe detects that the container is unsafe. 
If the container does not contain the LivenessProbe probe, kubelet considers the return value of the probe to always be “success”. 
ReadinessProbe For Preparation 
It is used to determine if the container is initiated (read state) and the request can be accepted. 
The status of the Pod will be changed if the ReadnessProbe probe fails. The Endpoint Controller will delete from the Endpoint of the Service the Endpoint containing the Pod where the container is placed.

Thank you Reading this, keep following me for new updates.

Pankaj K.