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