Basic introduction

Pod is a set of containers that share IPC, Network and UTS namespace. It is the basic unit of Kubernetes scheduling. The design concept of pod is to support multiple containers to share the Network and file system in one pod, and the services can be combined in a simple and efficient way such as interprocess communication and file sharing.

Pod features

• Containers containing multiple shared IPC, Network and UTC namespace s can communicate directly through localhost
• All Pod content containers can access shared volumes and shared data
• No fault tolerance: once the Pod directly created is scheduled, it will be bound to the Node. Even if the Node hangs, it will not be rescheduled (but automatically deleted). Therefore, it is recommended to use Deployment, daemon and other controllers to fault tolerance
• Graceful termination: when Pod is deleted, send SIGTERM to the processes in it first, and wait for a grace period before forcibly stopping the still running processes
• The privilege container (configured through SecurityContext) has the permission to change the system configuration

Pod status

k8s with podstatus Phase abstracts the state of Pod (but does not directly reflect the state of all containers). Possible phases include

• Pending: the API server has created the Pod, but one or more containers have not been created, including the process of downloading images through the network
• Running: all containers in pod have been created and dispatched to Node, but at least one container is still running or starting.
• Succeeded: after the pod is dispatched to the Node, the operation ends successfully and will not restart.
• Failed: all containers in the pod have been terminated, but at least one container failed to exit (that is, the exit code is not 0 or terminated by the system).
• Unknown: the status is unknown. Pod cannot be obtained normally for some reasons, usually because apiserver cannot communicate with kubelet.

You can query Pod Phase with kubectl command, as follows:

[root@node162 ~]# kubectl get po test -o jsonpath="{.status.phase}"
Running
[root@node162 ~]# 

PodrestartPolicy

The restartPolicy in PodSpec can be used to set whether to restart the exiting Pod, as follows:

• Always: when the container fails, Kubelet will automatically restart the container. The default value of RestartPolicy.
• OnFailure: Kubelet restarts when the container terminates and the exit code is not 0.
• Never: under no circumstances will Kubelet restart the container.

Set the hostname of Pod

It is implemented through spec.hostname parameter. If it is not set, metadata is used by default The value of the name parameter is the hostname of the Pod.

apiVersion: v1
kind: Pod
metadata:
  name: test
  labels:
    name: test
spec:
  hostname: test   ###Set the pod name to test
  containers:
  - image: nginx
    command: ["init"]
    name: nginx:latest

Pod health check

In order to ensure that the container is indeed in normal operation after deployment, Kubernetes provides two kinds of probes to detect the status of the container:

• LivenessProbe: detect whether the application is in a healthy state. If it is not healthy, delete and recreate the container.
• ReadinessProbe: detect whether the application is started and in the normal Service state. If it is not normal, it will not receive traffic from Kubernetes Service, that is, remove the Pod from the Service endpoint.
  k8s supports three ways to execute probes:
• exec: execute a command in the container if Command exit code If 0 is returned, it means the detection is successful, otherwise it means failure
• tcpSocket: perform a TCP check on the specified container IP and port. If the port is open, it means the detection is successful, otherwise it means failure
• httpGet: execute an HTTP Get request for the specified container IP, port and path. If the returned Status code Between [200400), it means the detection is successful, otherwise it means failure

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: nginx
  name: nginx
spec:
    containers:
    - image: nginx
      imagePullPolicy: Always
      name: http
      livenessProbe:
        httpGet:
          path: /
          port: 80
          httpHeaders:
          - name: X-Custom-Header
            value: Awesome
        initialDelaySeconds: 15
        timeoutSeconds: 1
      readinessProbe:
        exec:
          command:
          - cat
          - /usr/share/nginx/html/index.html
        initialDelaySeconds: 5
        timeoutSeconds: 1
    - name: goproxy
      image: gcr.io/google_containers/goproxy:0.1
      ports:
      - containerPort: 8080
      readinessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20
        

Container lifecycle hook

Container Lifecycle Hooks listen for specific events in the container lifecycle and execute the registered callback function when the event occurs. Two types of hooks are supported:

• postStart: execute immediately after the container is created. Note that because it is executed asynchronously, it cannot be guaranteed to run before ENTRYPOINT. If it fails, the container will be killed, and whether to restart will be decided according to the RestartPolicy
• preStop: execute before the container terminates. It is often used for resource cleanup. If it fails, the container will also be killed
  The callback function of the hook supports two ways:
• exec: execute the command in the container. If the exit status code of the command is 0, it means the execution is successful, otherwise it means failure
• httpGet: Send a GET request to the specified URL. If the returned HTTP status code is between [200, 400), it means that the request is successful, otherwise it means that it fails
  Examples of postStart and preStop hooks:

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        httpGet:
          path: /
          port: 80
      preStop:
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

Pod custom hosts

By default, the container's /etc/hosts is automatically generated by kubelet, and only includes localhost, podName, and so on. It is not recommended to modify the /etc/hosts file directly in the container, because it will be overwritten when the Pod is started or restarted.

The default /etc/hosts file format is as follows, where ECI runc block deployment FIO is podName:

[root@eci-runc-block-deployment-fio /]# cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
fe00::0	ip6-mcastprefix
fe00::1	ip6-allnodes
fe00::2	ip6-allrouters
172.10.0.44	eci-runc-block-deployment-fio

You can add hosts content through pod.Spec.HostAliases, such as

    spec:
      hostAliases:
      - ip: "10.224.1.100"
        hostnames:
        - "vip.test.com"

Pod time zone

Many containers are in the default UTC time zone, which may be inconsistent with the time zone of the Node of the cluster. You can configure the container with the same time zone as the Node through the HostPath storage plug-in, as follows:

apiVersion: v1
kind: Pod
metadata:
  name: time
spec:
  containers:
  - image: nginx:latest
    volumeMounts:
    - mountPath: /etc/localtime
      name: time
      readOnly: true
  volumes:
  - hostPath:
      path: /etc/localtime
      type: ""
    name: time