一.Pod生命周期
在Kubernetes中,Pod的生命周期经历了几个重要的阶段。下面是Pod生命周期的详细介绍:
1.Pending(待处理):-
调度: Pod被创建后,首先进入“Pending”状态。此时,Kubernetes的调度器(Scheduler)会选择一个合适的节点来运行Pod。
-
资源分配: 在调度器选择了节点后,Pod仍在“Pending”状态,直到所有容器的镜像都被拉取下来,并且资源需求得到了满足。
- 初始化容器: 如果Pod定义了初始化容器(Init Containers),这些容器会在Pod的主容器之前启动。它们完成后,Pod状态会转变为“Running”。
在Kubernetes中,Pod的生命周期包括初始化容器(Init Containers)的特殊阶段。初始化容器是用于在Pod的主容器启动之前执行一些初始化任务的容器。它们是Pod的一部分,通常用于执行一些准备工作,例如数据库迁移、配置准备、依赖检查等。以下是有关初始化容器的详细生命周期信息:
### 初始化容器的生命周期 1. 定义阶段: - 在Pod的定义中,初始化容器与主容器一起列在Pod的规范(spec)中。每个初始化容器都可以有自己的镜像、命令、环境变量等配置。 2. 创建阶段: - 当Pod被创建时,初始化容器会根据Pod的规范进行启动。它们按照定义的顺序逐个启动。每个初始化容器都必须成功完成后,才会启动下一个初始化容器。 3. 启动阶段: - 顺序执行: 初始化容器会按照Pod规范中定义的顺序依次启动。如果一个初始化容器启动失败,Kubernetes会重试这个容器,直到成功或达到最大重试次数。 - 完成任务: 每个初始化容器会执行其定义的任务,并且必须成功退出(以状态码0结束)。如果容器失败退出(以非零状态码结束),Kubernetes会重试,直到容器成功完成或者重试次数达到限制。 4. 过渡到运行阶段: - 成功: 当所有的初始化容器成功完成其任务后,Pod会进入“Running”状态,随后主容器(Containers)才会启动。 - 失败: 如果某个初始化容器失败并且达到重试次数限制,整个Pod会标记为失败,主容器不会启动。 5. 终止阶段: - 终止: 一旦Pod的生命周期结束(无论是正常完成还是失败),初始化容器也会随之终止。Kubernetes会处理容器的清理工作,包括删除容器的日志和其他临时文件。 > ### 初始化容器的特点 > > - 顺序性: 初始化容器按定义顺序执行,一个初始化容器完成后,才会开始下一个初始化容器。 > - 隔离性: 初始化容器在Pod中的主容器之前运行,它们可以有不同的镜像和配置,与主容器的环境相互隔离。 > - 重试机制: 如果初始化容器失败,Kubernetes会根据配置的重试策略重试该容器,直到成功或者达到重试限制。 > > ### 使用场景 > > 初始化容器非常适用于以下场景: > > - 数据库初始化: 在应用启动之前执行数据库迁移或初始化操作。 > - 配置检查: 检查或生成配置文件,确保主容器启动所需的环境准备好。 > - 依赖服务检查: 确保所需的外部服务或资源在主容器启动之前可用。 > > 初始化容器提供了一种在Pod启动之前执行预处理任务的灵活方式,使得Pod的主容器能够在正确的环境中运行。
-
主容器启动: 所有的初始化容器成功运行后,Pod中的主容器开始启动。此时Pod处于“Running”状态。
-
健康检查: 在“Running”状态下,Kubernetes会持续进行健康检查(Liveness Probe)和就绪检查(Readiness Probe),以确保容器正常运行并能够接受流量。
完成任务: 如果Pod中的所有容器成功完成任务并退出(对于短生命周期的Pod,如Batch Job中的Pod),Pod会转变为“Succeeded”状态。
4.Failed(失败):任务失败: 如果Pod中的容器因故障或错误而退出,Pod将转变为“Failed”状态。这通常表示容器没有成功完成其任务。
5.Unknown(未知):状态不确定: 如果Kubernetes无法从节点获取Pod的状态,Pod会处于“Unknown”状态。这可能是由于节点不可达或其他通信问题引起的。
6.Terminating(终止中):-
终止: 当Pod被删除或终止时,Pod进入“Terminating”状态。在此状态下,Kubernetes会逐步停止Pod中的所有容器,并进行必要的清理工作。
-
Grace Period: Kubernetes会尊重Pod的终止宽限期(Grace Period),允许容器在关闭前完成它们的清理工作。终止宽限期可以通过Pod的
terminationGracePeriodSeconds
字段配置。
了解这些状态对于管理和调试Kubernetes中的应用非常重要。每个阶段和状态都有其特定的含义和影响,掌握它们可以帮助你更好地理解和控制Pod的行为。
二、Pod的探针
Kubernetes中的Pod探针用于检测容器的健康状态和就绪状态。主要有三种探针:
-
Liveness Probe(存活探针): 检查容器是否正常运行。如果探针失败,Kubernetes会重启容器。适用于检测容器是否陷入了死循环或挂起状态。
-
Readiness Probe(就绪探针): 确定容器是否准备好接受流量。探针失败会导致Pod从服务的负载均衡池中移除,直到容器恢复就绪状态。
-
Startup Probe(启动探针): 检测容器是否已启动。用于处理启动时需要较长时间的应用,避免在启动阶段被误判为不健康。(常用于脚本)
探针通常通过HTTP请求、TCP连接或执行命令来进行检查。
三、Pod的两个钩子
1.介绍
在Kubernetes中,Pod的两个钩子是:
-
生命周期钩子(Lifecycle Hooks):
-
postStart
: 在容器启动后立即执行的钩子。适用于需要在容器启动后执行某些任务的场景,例如初始化配置或启动一些后台进程。 -
preStop
: 在容器停止之前执行的钩子。适用于在容器停止之前进行清理操作或保存状态等操作。
生命周期钩子允许在容器的生命周期中特定的时间点执行自定义的脚本或命令。它们帮助开发者在容器的启动或停止时执行必要的操作。
-
-
终止钩子(Termination Hooks):
-
终止钩子是一个与生命周期钩子相似的概念,但在Kubernetes中并没有明确标记为“终止钩子”。而是在
preStop
钩子中定义了在容器停止之前要执行的操作,这也可以视为终止钩子的一部分。
-
2.配置示例
在Pod的定义中配置postStart
和preStop
的示例:
apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers: - name: example-container image: example-image lifecycle: postStart: exec: command: ["/bin/sh", "-c", "echo 'Container started' > /var/log/startup.log"] preStop: exec: command: ["/bin/sh", "-c", "echo 'Container is stopping' > /var/log/shutdown.log"]
3.作用
-
postStart
: 用于在容器启动后执行操作,比如配置、启动服务、或者进行一些初始化工作。需要注意的是,postStart
钩子是异步执行的,并不会等待操作完成后才继续执行容器中的主应用程序。 -
preStop
: 用于在容器停止之前执行清理任务,比如关闭连接、清理缓存或保存数据。preStop
钩子是同步的,Kubernetes会等待钩子完成后才会真正停止容器。
这些钩子提供了一种在容器生命周期特定阶段执行自定义操作的方式,有助于确保容器的状态管理和资源清理。
四、Pod删除过程
Pod的删除过程在Kubernetes中涉及几个关键步骤。了解这些步骤有助于更好地管理Pod的生命周期和确保应用的平稳运行。以下是Pod删除的基本流程:
Pod running----Terminating----prestop hook----SIGTRM----terminationGracePeriodSeconds----SIGKILL----Deleted1. 发起删除请求
当你通过kubectl delete pod <pod-name>
命令或通过API请求删除Pod时,Kubernetes会开始删除过程。
Kubernetes将Pod的状态标记为Terminating
。此时,Pod仍然存在,但已经不再接受新的流量或请求。
preStop
钩子(如果有)
如果Pod配置了preStop
生命周期钩子,Kubernetes会在停止容器之前执行这个钩子。preStop
钩子是同步的,Kubernetes会等待钩子完成后才会继续删除容器。
一旦preStop
钩子(如果有)完成,Kubernetes会向容器发送终止信号(通常是SIGTERM
)。容器接收到信号后应该开始优雅地关闭。
Kubernetes会等待容器在设定的terminationGracePeriodSeconds
(默认30秒)内完成关闭过程。这个时间可以通过Pod的spec配置项进行调整。如果容器在规定时间内没有优雅地关闭,Kubernetes会发送强制终止信号(SIGKILL
)来强制关闭容器。
容器关闭后,Kubernetes会从集群中删除Pod对象,包括相关的所有资源(例如日志、事件记录等)。Pod的终止状态也会被更新到Terminated
。
如果Pod是由ReplicaSet或Deployment管理的,ReplicaSet或Deployment控制器会检测到Pod的删除,并根据策略创建新的Pod以维持期望的副本数。
8. 清理如果Pod在删除之前进行了任何网络连接、挂载卷或存储的操作,Kubernetes会在Pod删除过程中清理这些资源,确保系统资源得到释放和回收。
#示例: apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers: - name: example-container image: example-image lifecycle: preStop: exec: command: ["/bin/sh", "-c", "echo 'Cleaning up before shutdown' > /var/log/shutdown.log"]
总结:Pod删除的过程确保了应用的优雅关闭和资源的正确管理。通过了解这些步骤,你可以更好地设计和管理你的Kubernetes集群,确保高效和可靠的服务运行。
五、ReplicaSet
ReplicaSet
是 Kubernetes 中的一个控制器,用于确保指定数量的 Pod 实例始终在运行。以下是 ReplicaSet
资源的字段介绍,包括 metadata
、spec
和 status
部分的详细说明:
1.metadata
name: (string) ReplicaSet 的名字。 namespace: (string) ReplicaSet 所在的命名空间。 labels: (map[string]string) 一组标签,用于标识和选择对象。 annotations: (map[string]string) 由用户定义的附加信息,用于存储任意的元数据。 creationTimestamp: (string) ReplicaSet 的创建时间。
2.spec
spec
部分定义了 ReplicaSet 的行为和期望状态。
replicas: (int32) 要维持的 Pod 副本数量。这个字段是可选的,如果未指定,默认值为 1。
selector: (LabelSelector) 选择器,用于指定要管理的 Pod。这个字段定义了一个标签选择器,用于选择 ReplicaSet 要管理的 Pod。 matchLabels: (map[string]string) 一组标签键值对,用于匹配 Pod。 matchExpressions: ([]LabelSelectorRequirement) 用于选择 Pod 的表达式。
template: (PodTemplateSpec) Pod 模板,用于创建管理的 Pod。包含以下字段: metadata: (ObjectMeta) Pod 的元数据,通常包含标签和注释。 spec: (PodSpec) Pod 的规范,定义了容器、卷、网络等。 containers: ([]Container) Pod 中的容器列表,每个容器定义了镜像、端口等。 volumes: ([]Volume) Pod 中的卷定义,用于存储数据。
3.status
status
部分描述了 ReplicaSet 的当前状态。
replicas: (int32) 当前 Pod 副本的数量。 fullyLabeledReplicas: (int32) 完全符合选择器的 Pod 数量。 readyReplicas: (int32) 准备就绪的 Pod 数量。 availableReplicas: (int32) 可用的 Pod 数量。 observedGeneration: (int64) 观察到的 ReplicaSet 的版本号。用于检测状态的更新。
六、Pod节点选择
在 Kubernetes 中,Pod 节点选择器(Node Selector)是一种用于指定 Pod 应该调度到哪个节点的机制。通过节点选择器,您可以控制 Pod 在集群中运行的节点,确保它们在符合特定条件的节点上运行。
如何使用节点选择器
1.标记节点: 首先,您需要为节点添加标签。标签是由键值对组成的,例如 role=frontend
。
kubectl label nodes <node-name> role=frontend
2.使用节点选择器: 在 Pod 的定义文件中,您可以使用 nodeSelector
来指定 Pod 应该调度到哪些节点。例如,如果您想让 Pod 只调度到标签为 role=frontend
的节点上,可以在 Pod 的 YAML 文件中指定节点选择器。
apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: my-image nodeSelector: role: frontend
示例:Pod 将只会调度到具有 `disktype=ssd` 标签的节点上 apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers: - name: example-container image: nginx nodeSelector: disktype: ssd
注意事项:
-
节点选择器的限制:节点选择器只能基于节点的标签来做选择,比较简单。如果需要更复杂的调度策略,可以使用
affinity
或taints and tolerations
。 -
节点标签:确保节点已经正确地标记了标签,否则 Pod 可能会因为找不到符合条件的节点而无法调度。
-
多重标签匹配:如果节点有多个标签,节点选择器会匹配所有指定的标签条件。
通过合理配置节点选择器,您可以优化资源分配,提高 Pod 的性能和稳定性。
七、制作查看删除标签
1.制作标签
使用 kubectl label
命令为 Pod 打标签。以下是语法和示例:
kubectl label pod <pod-name> <key>=<value>
-
<pod-name>
:Pod 的名称。 -
<key>
:标签的键。 -
<value>
:标签的值。
例如,为名为 my-pod
的 Pod 打上标签 env=production
:
kubectl label pod my-pod env=production
2.查看 Pod 标签
查看所有 Pods 的标签
kubectl get pods --show-labels
查看特定 Pod 的标签
kubectl describe pod <pod-name>
只显示特定 Pod 的标签
kubectl get pod <pod-name> --template '{{range $k, $v := .metadata.labels}}{{$k}}: {{$v}}{{"\n"}}{{end}}'
这条命令只显示指定 Pod 的标签,以键值对的形式。
查看指定标签名的pod信息
-L
选项允许你在输出表格中添加额外的标签列,以便于更直观地查看 Pods 的标签。 可以指定多个标签键,通过逗号分隔,例如:-L project,app。
kubectl get pods -L project,app
-l
选项:用于 过滤资源,根据标签选择器选择要显示的资源
kubectl get pods -l app=myapp
3.查看 Node 标签
查看所有 Nodes 的标签
kubectl get nodes --show-labels
查看特定 Node 的标签
kubectl describe node <node-name>
只显示特定 Node 的标签
kubectl get node <node-name> --template '{{range $k, $v := .metadata.labels}}{{$k}}: {{$v}}{{"\n"}}{{end}}'
这条命令只显示指定 Node 的标签,以键值对的形式。
查看指定标签名的node信息
kubectl get nodes -L project
kubectl get node -l nodemaster=yes
4.删除标签
要删除 Pod 的标签,可以使用 kubectl label
命令并将标签值设置为空。以下是语法和示例:
kubectl label pod <pod-name> <key>-
-
<pod-name>
:Pod 的名称。 -
<key>
:要删除的标签的键。
例如,删除名为 my-pod
的 Pod 上的 env
标签:
kubectl label pod my-pod env-
5.指定节点
方法一:通过nodeName方式
apiVersion: apps/v1 kind: ReplicaSet metadata: name: my-replicaset spec: replicas: 4 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: nodeName: node1 containers: - name: mycontainer image: harbor.hiuiu.com/nginx/nginx:1.21.5 imagePullPolicy: Never ports: - containerPort: 80 kubectl apply -f replicaset.yaml kubectl get pod -o wide
方法二:通过nodeSelector方式
#将pod加入标签为nodemaster=yes的node中,ReplicaSet只管理label为app=myapp的pod
kubectl explain rs.spec.template.spec.nodeSelector apiVersion: apps/v1 kind: ReplicaSet metadata: name: my-replicaset spec: replicas: 4 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: nodeSelector: nodemaster: "yes" containers: - name: mycontainer image: harbor.hiuiu.com/nginx/nginx:1.21.5 imagePullPolicy: Never ports: - containerPort: 80 kubectl apply -f replicaset.yaml kubectl get pod -o wide
八、node亲和性
1.node亲和性
Kubernetes 的节点亲和性(Node Affinity)是一种调度机制,用于控制 Pod 被调度到哪些节点上。它允许你指定 Pod 应该运行在哪些特定的节点上,基于节点的标签。
节点亲和性是节点选择的扩展,它的配置方式类似于 Pod 的调度策略,通过在 Pod 的 spec.affinity.nodeAffinity
部分进行定义。
节点亲和性的基本概念
节点亲和性定义了 Pod 对节点的选择规则。它可以是:
-
必需亲和性(RequiredDuringSchedulingIgnoredDuringExecution):这些规则必须满足,否则 Pod 将不会被调度到节点上。它是强制性的。
-
优先亲和性(PreferredDuringSchedulingIgnoredDuringExecution):这些规则是优先考虑的,但不是强制性的。Kubernetes 将尽量满足这些规则,但如果无法满足,也不会阻止 Pod 调度。
必需亲和性
kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution
#pod必须加入标签为zone=ky36或zone=ccc的node中
apiVersion: v1 kind: Pod metadata: name: pod-node-affinity-demo namespace: default labels: app: myapp spec: containers: - name: myapp image: harbor.hiuiu.com/nginx/nginx:1.21.5 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: zone operator: In values: - ky36 - ccc kubectl apply -f replicaset.yaml kubectl get pod -o wide
优先亲和性
kubectl explain pods.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution
apiVersion: v1 kind: Pod metadata: name: pod-node-affinity-demo namespace: default labels: app: myapp spec: containers: - name: myapp image: harbor.hiuiu.com/nginx/nginx:1.21.5 affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: zone operator: In values: - ky36 - ccc kubectl apply -f replicaset.yaml kubectl get pod -o wide
2.Pod亲和性
kubectl explain pods.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey yaml1 apiVersion: v1 kind: Pod metadata: name: pod-first labels: app2: myapp2 tier: frontend spec: containers: - name: myapp image: harbor.hiuiu.com/nginx/nginx:1.21.5 yaml2 apiVersion: v1 kind: Pod metadata: name: pod-second labels: app: backend tier: db spec: containers: - name: mysql image: harbor.hiuiu.com/nginx/nginx:1.21.5 imagePullPolicy: IfNotPresent affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app2 operator: In values: - myapp2 topologyKey: kubernetes.io/hostname
kubectl apply -f pod1.yaml
kubectl apply -f pod2.yaml
kubectl get pod -o wide
3.Pod 反亲和性
kubectl explain pods.spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey
九、Pod 拉取镜像策略
kubectl explain pod.spec.containers.imagePullPolicy ##imagePullPolicy (镜像拉取策略):: IfNotPresent:node节点没有此镜像就去指定的镜像仓库拉取,node有就使用node本地镜像。 Always:每次重建pod都会重新拉取镜像 Never:从不到镜像中心拉取镜像,只使用本地镜
十、Pod重启策略
kubectl explain pod.spec.restartPolicy
restartPolicy
Always:默认值。无论容器退出的状态如何,始终重启容器。适用于长期运行的服务。 Never:容器退出后不会重启。适用于一次性任务或需要手动干预的情况。 OnFailure:只有当容器退出状态码表示失败时(非零退出码),才会重启。适用于希望重启失败的任务但不需要重启成功完成的任务。
标签:kubectl,Kubernetes,容器,标签,基本操作,POD,Pod,pod From: https://www.cnblogs.com/hxqwe/p/18374239