一、Pod生命周期
二、Pod的相位
1、Pod相位含义
2、Pod相位图解
三、Pod的创建过程
1、用户通过kubectl或其他API客户端提交pod spec给API Server
2、API Server尝试着将pod对象的相关信息存入etcd中、待写入操作之执行完成，API Server即会返回确认信息至客户端
3、API Server开始反映etcd中的变化
4、所有组件均使用"watch"机制来跟踪检查API Server上的相关变动
5、kube-scheduler通过其"watcher" 觉察到API Server创建新的pod对象但尚未绑定至任何工作节点
6、kube-scheduler为pod对象挑选一个工作节点并将结果信息更新至API Server
7、调度结果信息由API Server更新至etcd存储系统，而且API Server也开始反映此pod对象的调度结果
8、pod被调度到目标工作节点上的kubelet尝试在当前节点上调用docker启动容器并将容器的结果状态会送至API Server
9、API Server将pod信息存入etcd系统中
10、在etcd确认写入操作成功完成后，API Server将确认信息发送至相关的kubelet，事件将通过它被接受
四、Pod生命周期过程中的重要阶段（初始化容器）
1、官方手册
kubectl explain pod.spec.initContainers
[root@master ~]# kubectl explain pod.spec.initContainers
KIND: Pod
VERSION: v1
RESOURCE: initContainers <[]Object>
DESCRIPTION:
List of initialization containers belonging to the pod. Init containers are
executed in order prior to containers being started. If any init container
fails, the pod is considered to have failed and is handled according to its
restartPolicy. The name for an init container or normal container must be
unique among all containers. Init containers may not have Lifecycle
actions, Readiness probes, Liveness probes, or Startup probes. The
resourceRequirements of an init container are taken into account during
scheduling by finding the highest request/limit for each resource type, and
then using the max of of that value or the sum of the normal containers.
Limits are applied to init containers in a similar fashion. Init containers
cannot currently be added or removed. Cannot be updated. More info:
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
A single application container that you want to run within a pod.
FIELDS:
args <[]string>
Arguments to the entrypoint. The docker image's CMD is used if this is not
provided. Variable references $(VAR_NAME) are expanded using the
container's environment. If a variable cannot be resolved, the reference in
the input string will be unchanged. The $(VAR_NAME) syntax can be escaped
with a double $$, ie: $$(VAR_NAME). Escaped references will never be
expanded, regardless of whether the variable exists or not. Cannot be
updated. More info:
https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell
command <[]string>
Entrypoint array. Not executed within a shell. The docker image's
ENTRYPOINT is used if this is not provided. Variable references $(VAR_NAME)
are expanded using the container's environment. If a variable cannot be
resolved, the reference in the input string will be unchanged. The
$(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME).
Escaped references will never be expanded, regardless of whether the
variable exists or not. Cannot be updated. More info:
https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell
env <[]Object>
List of environment variables to set in the container. Cannot be updated.
envFrom <[]Object>
List of sources to populate environment variables in the container. The
keys defined within a source must be a C_IDENTIFIER. All invalid keys will
be reported as an event when the container is starting. When a key exists
in multiple sources, the value associated with the last source will take
precedence. Values defined by an Env with a duplicate key will take
precedence. Cannot be updated.
image <string>
Docker image name. More info:
https://kubernetes.io/docs/concepts/containers/images This field is
optional to allow higher level config management to default or override
container images in workload controllers like Deployments and StatefulSets.
imagePullPolicy <string>
Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always
if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated.
More info:
https://kubernetes.io/docs/concepts/containers/images#updating-images
lifecycle <Object>
Actions that the management system should take in response to container
lifecycle events. Cannot be updated.
livenessProbe <Object>
Periodic probe of container liveness. Container will be restarted if the
probe fails. Cannot be updated. More info:
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
name <string> -required-
Name of the container specified as a DNS_LABEL. Each container in a pod
must have a unique name (DNS_LABEL). Cannot be updated.
ports <[]Object>
List of ports to expose from the container. Exposing a port here gives the
system additional information about the network connections a container
uses, but is primarily informational. Not specifying a port here DOES NOT
prevent that port from being exposed. Any port which is listening on the
default "0.0.0.0" address inside a container will be accessible from the
network. Cannot be updated.
readinessProbe <Object>
Periodic probe of container service readiness. Container will be removed
from service endpoints if the probe fails. Cannot be updated. More info:
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
resources <Object>
Compute Resources required by this container. Cannot be updated. More info:
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
securityContext <Object>
Security options the pod should run with. More info:
https://kubernetes.io/docs/concepts/policy/security-context/ More info:
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
startupProbe <Object>
StartupProbe indicates that the Pod has successfully initialized. If
specified, no other probes are executed until this completes successfully.
If this probe fails, the Pod will be restarted, just as if the
livenessProbe failed. This can be used to provide different probe
parameters at the beginning of a Pod's lifecycle, when it might take a long
time to load data or warm a cache, than during steady-state operation. This
cannot be updated. This is a beta feature enabled by the StartupProbe
feature flag. More info:
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
stdin <boolean>
Whether this container should allocate a buffer for stdin in the container
runtime. If this is not set, reads from stdin in the container will always
result in EOF. Default is false.
stdinOnce <boolean>
Whether the container runtime should close the stdin channel after it has
been opened by a single attach. When stdin is true the stdin stream will
remain open across multiple attach sessions. If stdinOnce is set to true,
stdin is opened on container start, is empty until the first client
attaches to stdin, and then remains open and accepts data until the client
disconnects, at which time stdin is closed and remains closed until the
container is restarted. If this flag is false, a container processes that
reads from stdin will never receive an EOF. Default is false
terminationMessagePath <string>
Optional: Path at which the file to which the container's termination
message will be written is mounted into the container's filesystem. Message
written is intended to be brief final status, such as an assertion failure
message. Will be truncated by the node if greater than 4096 bytes. The
total message length across all containers will be limited to 12kb.
Defaults to /dev/termination-log. Cannot be updated.
terminationMessagePolicy <string>
Indicate how the termination message should be populated. File will use the
contents of terminationMessagePath to populate the container status message
on both success and failure. FallbackToLogsOnError will use the last chunk
of container log output if the termination message file is empty and the
container exited with an error. The log output is limited to 2048 bytes or
80 lines, whichever is smaller. Defaults to File. Cannot be updated.
tty <boolean>
Whether this container should allocate a TTY for itself, also requires
'stdin' to be true. Default is false.
volumeDevices <[]Object>
volumeDevices is the list of block devices to be used by the container.
volumeMounts <[]Object>
Pod volumes to mount into the container's filesystem. Cannot be updated.
workingDir <string>
Container's working directory. If not specified, the container runtime's
default will be used, which might be configured in the container image.
Cannot be updated.
2、初始化过程详解
1、用于运行特定的工具程序，处于安全等方面的原因、这些程序不适于包含在主容器镜像中
2、提供主容器镜像中不具备的工具程序或自定义代码
3、为容器镜像的构建和部署人员提供了分离、独立工作的途径、使的他们不必协同起来制作单个镜像文件
4、初始化容器和主容器处于不同的文件系统视图中、因此可以分贝安全地使用敏感数据，例如Secrets资源
5、初始化容器要先于应用容器穿行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件的到满足
3、初始化容器注意事项
4、模板示例
apiVersion: apps/v1
kind: DaemonSet
metadata:
......
spec:
selector:
....
template:
- matchExpressions:
.....
initContainers:
- name: install-cni
image: quay.io/coreos/flannel:v0.12.0-arm64
command:
- cp
args:
- -f
- /etc/kube-flannel/cni-conf.json
- /etc/cni/net.d/10-flannel.conflist
volumeMounts:
- name: cni
mountPath: /etc/cni/net.d
- name: flannel-cfg
mountPath: /etc/kube-flannel/
五、Pod生命周期过程中的重要阶段（容器启动后钩子）
1、容器启动后钩子
2、两种生命周期钩子
1、官方文档
[root@master chapter4]# kubectl explain pod.spec.containers.lifecycle
KIND: Pod
VERSION: v1
RESOURCE: lifecycle <Object>
DESCRIPTION:
Actions that the management system should take in response to container
lifecycle events. Cannot be updated.
Lifecycle describes actions that the management system should take in
response to container lifecycle events. For the PostStart and PreStop
lifecycle handlers, management of the container blocks until the action is
complete, unless the container process fails, in which case the handler is
aborted.
FIELDS:
postStart <Object>
PostStart is called immediately after a container is created. If the
handler fails, the container is terminated and restarted according to its
restart policy. Other management of the container blocks until the hook
completes. More info:
https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks
preStop <Object>
PreStop is called immediately before a container is terminated due to an
API request or management event such as liveness/startup probe failure,
preemption, resource contention, etc. The handler is not called if the
container crashes or exits. The reason for termination is passed to the
handler. The Pod's termination grace period countdown begins before the
PreStop hooked is executed. Regardless of the outcome of the handler, the
container will eventually terminate within the Pod's termination grace
period. Other management of the container blocks until the hook completes
or until the termination grace period is reached. More info:
https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks
2、钩子函数
args不能强依赖postStart里的command
3、钩子处理程序的实现
4、模板用例
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: ikubernetes/myapp:v1
lifecycle:
postStart:
exec:
command: ["/bin/sh","-c","echo $(hostname) | lifecycle hooks handler > /usr/share/nginx/html/test.html"]
六、Pod生命周期过程中的重要阶段（容器探针检测及重启策略）
1、容器的存活性探针
1、检查方法
2、livenessProbe
2、就绪性探针
3、重启策略
容器程序发生崩溃或容器身亲高潮处限制的资源等原因都可能会导致pod对象的终止此时是否应该重建改pod对象则屈居于其重启策略属性的定义
1、always：但凡pod对象终止就重启，此为默认重启
2、onfailure：仅在pod对象出错时方才将其重启
3、never从不重启
需要注意的是：重启策略适用于pod对象中的所有容器，而且他仅用于控制在同一节点上重新启动pod对象的相关容器
首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将有kubelet延迟一段时间后进行
且反复的重启操作的延时时常一次为10秒、20秒、40秒、80秒、160秒和300秒、300秒是最大延迟时长
事实上、一旦绑定到一个节点、pod对象将永远不会被绑定到另外一个节点，它要么重启、要么终止、直到节点发生故障被删除
五、Pod的终止过程
1、用户发送删除pod对象的命令
2、API Server中的pod对象会随着实践的推移而更新，在宽限期内(默认为30秒)，pod视为"dead"
3、将pod标记为"terminating" 状态
4、(与第3步同时运行)kubelet在监控到pod对象转为"terminating"状态的同时启用pod关闭过程
5、(与第3步同时运行)端点控制器监控到pod对象的关闭行为时从所有匹配到端点的service资源的端点列表中移除
6、如果当前pod对象定义了prestop钩子处理器，则在其标记为"terminating"后即会以同步的方式启动指定；若宽限期结束后则第2步被重新执行额外获取一个时长为2秒的小宽期限
7、pod对象中的容器进程收到TRRM信号
8、宽限期结束后，若存在任何一个仍在运行的进行，那么pod对象即会受到SIGKILL信号
9、kubelet请求API Server将此pod资源的宽限期设置为0从而完成删除操作。它变得对用户不可见
默认情况下，所有删除操作的宽限期都是30秒，不过kubelet delete命令可以使用 "--grace-period=<seconds>" 选项自定义其时长，若使用0值则表示直接强制删除制定的资源，不过、此时需要同时为命令使用 "--force" 选项