Pod articles of Kubernetes study notes (5)

What are Pods?

Know and understand Pod

Pod is the smallest deployable computing unit created and managed in kubernetes.
Pod is like a pea pod, and the beans in pea pods are what we often call containers, which may be a group (one or more) of containers; these containers share resources such as storage, network, CPU, and memory, and Pod can be understood as Virtual machine, understand the container in the Pod as an application running in the virtual machine. These containers are relatively tightly coupled. These applications may be on the same physical host or virtual machine.
Kubernetes generally does not manage containers directly, but manages them through Pods.

The context of Pod can be understood as the union of multiple linux namespaces

• PID namespace (applications in the same Pod can see other processes)
• Network namespace (applications in the same Pod have permissions to the same IP address and port)
• IPC namespace (applications in the same Pod can communicate through VPC or POSIX)
• UTS namespace (applications in the same Pod share a host name)

Pods generally contain

• A set of (one or more) containers, generally one, is placed in a Pod unless the coupling is relatively strong and shared resources are required;
• For shared storage resources (such as data volume vloume), containers in a Pod can share storage space;
• Each pod will be assigned an independent IP address. The containers in the Pod share the same Pod IP and network port. The containers in the Pod can communicate with each other using localhost;

Containers in a Pod can be divided into two types:

• Work container: also our application container
• Initialization container: responsible for completing some initialization operations, the initialization container runs before the working container, so the working container will not be started until the initialization container is successfully executed

Manage and use Pods

Use pods

When actually using kubernetes, we generally don't create Pods directly, because the life cycle of Pods is the shortest and then destroyed after use.
The Pod will not heal itself. If the Node node where the Pod is located has insufficient resources or the Pod is in the maintenance state, the Pod will also be evicted. Kubernetes uses a higher-level controller (controller) abstraction layer to manage Pod instances. Although Pods can be used directly, Kubernetes usually uses controllers to manage Pods.

Pod controller in kubernetes (controller)

Pod controller is also known as workload (workload), the controller (controller) can create and manage multiple Pods, provide copy management, rolling upgrade and self-healing capabilities at the cluster level. For example, if a Node fails, the controller will automatically schedule the Pods on the node to other healthy Nodes.
Pod common controller

1. Deployment: Used to manage stateless Pod applications, it is currently the most widely used and best controller. It supports rolling update and rollback functions, and also provides declarative configuration. The two resource objects, ReplicaSet and Deployment, gradually replace the role of the previous RC;
2. StatefulSet: manage stateful Pod applications;
3. DaemonSet: Pod application used to manage daemon classes;
4. Job : It is used to manage Pod applications that only perform one-time tasks. The created Pod will exit immediately after executing the task without restarting or rebuilding;
5. Cronjob: used to manage periodic tasks, does not require continuous running Pod applications;
6. ReplicaSet: replica controller, used to maintain the number of Pods at the expected value set

Create pods

Create a Pod through a resource list

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment # 工作负载名称
  labels:
    app: nginx 
spec:
  replicas: 3 # 期望pod数量
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx # 容器名称
        image: nginx:1.14.2 # 容器镜像
        ports:
        - containerPort: 80 # 容器端口

kubectl apply -f nginx-deployment.yaml

Create Pods via the command line

kubectl run nginx-deploy --image=nginx:1.14.2 --port=80 --dry-run=true

Pod status
Pod common status generally has the following types :

1. Pending: The Pod has been created, but the scheduling has not been completed. Generally, this state will appear when there are insufficient working nodes in the cluster;
2. Running: Pod has been created and assigned to a certain node, all containers in Pod have been created, only one container is running or starting;
3. Successfulded: All containers in the Pod have been successfully terminated and cannot be restarted;
4. Failed: All containers in the Pod have been terminated, and at least one container has failed or terminated;
5. Unkonwn: the apiserver cannot obtain the current status of the Pod, usually caused by the loss of connection between the master and the node host where the Pod is located;
6. ImagePullBackOff: The image pull fails, which is usually caused by the incorrect configuration of the image name and the incorrect configuration of the image pull key;
7. CrashLoopBackOff: The container in the Pod failed to start, which may be caused by the failure of the health check and the incorrect configuration of the container;
8. Terminating: Pod is being deleted;
9. Completed: The main process inside the container has exited. Generally, this status will appear after the Job application finishes executing the task;
10. ContainerCreating: Pod is being created;
11. PodInitializing: Pod is being initialized;

Container restart strategy

12. Always: When the container fails, the kubelet automatically restarts the container;
13. OnFailure: When the container fails, the kubelet automatically restarts the container;
14. Never: Regardless of the running state of the container, kubelet will not restart the container

Container image pull strategy
If you do not specify an image pull strategy, the default strategy is Always
15. Always (always pull the image);
16. IfNotPresent (local image is preferred, if there is a local image, the image will not be pulled);
17. Never (Only use local mirroring, never pull, even if there is no local)
Health check
Health check (health check) is used to detect whether the application instance is working normally, and is a means to ensure business availability. By default, kubelet uses the running status of the container as the health basis, and cannot monitor the status of the application program in the container. If the program freezes, it will lead to failure to provide services and loss of traffic. Introducing the health check mechanism of kubernetes can ensure the healthy survival of containers.

There are three main types of health checks :

• startupProbe (startup detection): Indicates whether the application in the container has been started. If a startup probe is provided, all other probes are disabled until successful. If the start probe fails, the kubelet kills the container, which is subject to its restart policy. If the container does not provide a start probe, the default state is . Success;
• readinessProbe (readiness probe): Indicates whether the container is ready to respond to requests. If the readiness probe fails, the endpoint controller will remove the pod's IP address from all service's endpoints that match the pod. The ready state before the default initial delay is . If the container does not provide a readiness probe, the default state is . FailureSuccess;
• livenessProbe (inventory detection): Indicates whether the container is running. If liveness detection fails, Kubelet kills the container, which is bound by its restart policy. If the container does not provide a liveness probe, the default state is . Success

Health Checking Mechanisms
There are four different ways to check containers using probes. Each probe must define exactly one of the following four mechanisms:

• exec executes the specified command inside the container. Diagnostics A command is considered successful if it exits with a status code of 0.
• grpc performs remote procedure calls using gRPC. The target should implement gRPC health checks. If the response is successful, the diagnosis is considered successful. gRPC probes are an alpha feature and are only available if: Feature entry is enabled. statusSERVINGGRPCContainerProbe
• httpGet performs an HTTP request to the Pod's IP specifying the port and address on the path. Diagnostics are considered successful if the response has a status code greater than or equal to 200 and less than 400.
• TcpSocket
  performs TCP checks against the Pod's IP address on the specified port. The diagnosis is considered successful if the following conditions are met: the port is open. It counts as normal if the remote system (container) closes the connection immediately after opening it. Probe results

The health test results are divided into the following three types

1. Success: Indicates that the container has passed the health check;
2. Failure: indicates that the container has not passed the health check, and the pod will be redeployed or deleted at this time;
3. Unknown: It means that the current execution mechanism has not been completed, and no operation will be done at this time, and it will wait for the next mechanism to check.

Common Pod analysis commands :

1. kubectl describe -n "namespace_name" pod "pod_name" # query pod details;
2. kubectl logs -n "namespace_name" pod "pod_name" # query pod log details;
3. kubectl get pods -A -owide |grep “pod_name” # Query pod running status and detailed information