POD基本操作
1.Pod生命周期
在Kubernetes中，Pod的生命周期经历了几个重要的阶段。下面是Pod生命周期的详细介绍：
-
Pending（待处理）:
- 调度: Pod被创建后，首先进入“Pending”状态。此时，Kubernetes的调度器（Scheduler）会选择一个合适的节点来运行Pod。
- 资源分配: 在调度器选择了节点后，Pod仍在“Pending”状态，直到所有容器的镜像都被拉取下来，并且资源需求得到了满足。
-
Running（运行中）:
- 初始化容器: 如果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），以确保容器正常运行并能够接受流量。
-
Succeeded（成功）:
- 完成任务: 如果Pod中的所有容器成功完成任务并退出（对于短生命周期的Pod，如Batch Job中的Pod），Pod会转变为“Succeeded”状态。
-
Failed（失败）:
- 任务失败: 如果Pod中的容器因故障或错误而退出，Pod将转变为“Failed”状态。这通常表示容器没有成功完成其任务。
-
Unknown（未知）:
- 状态不确定: 如果Kubernetes无法从节点获取Pod的状态，Pod会处于“Unknown”状态。这可能是由于节点不可达或其他通信问题引起的。
-
Terminating（终止中）:
- 终止: 当Pod被删除或终止时，Pod进入“Terminating”状态。在此状态下，Kubernetes会逐步停止Pod中的所有容器，并进行必要的清理工作。
- Grace Period: Kubernetes会尊重Pod的终止宽限期（Grace Period），允许容器在关闭前完成它们的清理工作。终止宽限期可以通过Pod的
terminationGracePeriodSeconds字段配置。
了解这些状态对于管理和调试Kubernetes中的应用非常重要。每个阶段和状态都有其特定的含义和影响，掌握它们可以帮助你更好地理解和控制Pod的行为。
2.Pod的探针
Kubernetes中的Pod探针用于检测容器的健康状态和就绪状态。主要有三种探针：
- Liveness Probe（存活探针）: 检查容器是否正常运行。如果探针失败，Kubernetes会重启容器。适用于检测容器是否陷入了死循环或挂起状态。
- Readiness Probe（就绪探针）: 确定容器是否准备好接受流量。探针失败会导致Pod从服务的负载均衡池中移除，直到容器恢复就绪状态。
- Startup Probe（启动探针）: 检测容器是否已启动。用于处理启动时需要较长时间的应用，避免在启动阶段被误判为不健康。
探针通常通过HTTP请求、TCP连接或执行命令来进行检查。
3.Pod的两个钩子
在Kubernetes中，Pod的两个钩子是：
-
生命周期钩子（Lifecycle Hooks）:
postStart: 在容器启动后立即执行的钩子。适用于需要在容器启动后执行某些任务的场景，例如初始化配置或启动一些后台进程。preStop: 在容器停止之前执行的钩子。适用于在容器停止之前进行清理操作或保存状态等操作。
生命周期钩子允许在容器的生命周期中特定的时间点执行自定义的脚本或命令。它们帮助开发者在容器的启动或停止时执行必要的操作。
-
终止钩子（Termination Hooks）:
- 终止钩子是一个与生命周期钩子相似的概念，但在Kubernetes中并没有明确标记为“终止钩子”。而是在
preStop钩子中定义了在容器停止之前要执行的操作，这也可以视为终止钩子的一部分。
- 终止钩子是一个与生命周期钩子相似的概念，但在Kubernetes中并没有明确标记为“终止钩子”。而是在
3.1 配置示例
以下是如何在Pod的定义中配置postStart和preStop钩子的示例：
apiVersion: v1
kind: Pod
metadata:name: example-pod
spec:containers:- name: example-containerimage: example-imagelifecycle: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.2 钩子的作用
postStart钩子: 用于在容器启动后执行操作，比如配置、启动服务、或者进行一些初始化工作。需要注意的是，postStart钩子是异步执行的，并不会等待操作完成后才继续执行容器中的主应用程序。preStop钩子: 用于在容器停止之前执行清理任务，比如关闭连接、清理缓存或保存数据。preStop钩子是同步的，Kubernetes会等待钩子完成后才会真正停止容器。
这些钩子提供了一种在容器生命周期特定阶段执行自定义操作的方式，有助于确保容器的状态管理和资源清理。
4.Pod删除过程
Pod的删除过程在Kubernetes中涉及几个关键步骤。了解这些步骤有助于更好地管理Pod的生命周期和确保应用的平稳运行。以下是Pod删除的基本流程：
Pod running–Terminating–prestop hook–SIGTRM–terminationGracePeriodSeconds–SIGKILL–Deleted
1. 发起删除请求
当你通过kubectl delete pod <pod-name>命令或通过API请求删除Pod时，Kubernetes会开始删除过程。
2. 标记Pod为终止状态
Kubernetes将Pod的状态标记为Terminating。此时，Pod仍然存在，但已经不再接受新的流量或请求。
3. 执行preStop钩子（如果有）
如果Pod配置了preStop生命周期钩子，Kubernetes会在停止容器之前执行这个钩子。preStop钩子是同步的，Kubernetes会等待钩子完成后才会继续删除容器。
4. 停止容器
一旦preStop钩子（如果有）完成，Kubernetes会向容器发送终止信号（通常是SIGTERM）。容器接收到信号后应该开始优雅地关闭。
5. 等待容器关闭
Kubernetes会等待容器在设定的terminationGracePeriodSeconds（默认30秒）内完成关闭过程。这个时间可以通过Pod的spec配置项进行调整。如果容器在规定时间内没有优雅地关闭，Kubernetes会发送强制终止信号（SIGKILL）来强制关闭容器。
6. 删除Pod
容器关闭后，Kubernetes会从集群中删除Pod对象，包括相关的所有资源（例如日志、事件记录等）。Pod的终止状态也会被更新到Terminated。
7. 更新ReplicaSet或Deployment
如果Pod是由ReplicaSet或Deployment管理的，ReplicaSet或Deployment控制器会检测到Pod的删除，并根据策略创建新的Pod以维持期望的副本数。
8. 清理
如果Pod在删除之前进行了任何网络连接、挂载卷或存储的操作，Kubernetes会在Pod删除过程中清理这些资源，确保系统资源得到释放和回收。
示例
以下是一个Pod的配置示例，展示了preStop钩子的使用：
apiVersion: v1
kind: Pod
metadata:name: example-pod
spec:containers:- name: example-containerimage: example-imagelifecycle:preStop:exec:command: ["/bin/sh", "-c", "echo 'Cleaning up before shutdown' > /var/log/shutdown.log"]
总结
Pod删除的过程确保了应用的优雅关闭和资源的正确管理。通过了解这些步骤，你可以更好地设计和管理你的Kubernetes集群，确保高效和可靠的服务运行。
5.ReplicaSet
ReplicaSet 是 Kubernetes 中的一个控制器，用于确保指定数量的 Pod 实例始终在运行。以下是 ReplicaSet 资源的字段介绍，包括 metadata、spec 和 status 部分的详细说明：
5.1 metadata
name: (string) ReplicaSet 的名字。namespace: (string) ReplicaSet 所在的命名空间。labels: (map[string]string) 一组标签，用于标识和选择对象。annotations: (map[string]string) 由用户定义的附加信息，用于存储任意的元数据。creationTimestamp: (string) ReplicaSet 的创建时间。
5.2 spec
spec 部分定义了 ReplicaSet 的行为和期望状态。
-
replicas: (int32) 要维持的 Pod 副本数量。这个字段是可选的，如果未指定，默认值为 1。 -
- (LabelSelector) 选择器，用于指定要管理的 Pod。这个字段定义了一个标签选择器，用于选择 ReplicaSet 要管理的 Pod。
selectormatchLabels: (map[string]string) 一组标签键值对，用于匹配 Pod。matchExpressions: ([]LabelSelectorRequirement) 用于选择 Pod 的表达式。
-
- (PodTemplateSpec) Pod 模板，用于创建管理的 Pod。包含以下字段：
template-
metadata: (ObjectMeta) Pod 的元数据，通常包含标签和注释。 -
- (PodSpec) Pod 的规范，定义了容器、卷、网络等。
speccontainers: ([]Container) Pod 中的容器列表，每个容器定义了镜像、端口等。volumes: ([]Volume) Pod 中的卷定义，用于存储数据。
5.3 status
status 部分描述了 ReplicaSet 的当前状态。
replicas: (int32) 当前 Pod 副本的数量。fullyLabeledReplicas: (int32) 完全符合选择器的 Pod 数量。readyReplicas: (int32) 准备就绪的 Pod 数量。availableReplicas: (int32) 可用的 Pod 数量。observedGeneration: (int64) 观察到的 ReplicaSet 的版本号。用于检测状态的更新。
示例输出
假设你运行 kubectl explain replicasets 命令，输出可能如下：
KINDReplicaSetVERSIONv1DESCRIPTIONReplicaSets are a set of Pods that are meant to be maintained at aspecified number of replicas. They ensure that a given number of podsare running at any one time. They are the primary mechanism for scalingapplications in Kubernetes.FIELDSapiVersion string `json:"apiVersion,omitempty" yaml:"apiVersion,omitempty"`kind string `json:"kind,omitempty" yaml:"kind,omitempty"`metadata ObjectMeta `json:"metadata,omitempty" yaml:"metadata,omitempty"`spec ReplicaSetSpec `json:"spec,omitempty" yaml:"spec,omitempty"`status ReplicaSetStatus `json:"status,omitempty" yaml:"status,omitempty"`
要查看 ReplicaSet 资源的具体字段和详细说明，你可以运行以下命令：
-
查看
spec部分:kubectl explain replicasets.spec -
查看
spec.template部分:kubectl explain replicasets.spec.template -
查看
status部分:kubectl explain replicasets.status
通过这些命令，你可以获取 ReplicaSet 资源各个字段的详细说明和用法，帮助你更好地理解和使用 Kubernetes 的 ReplicaSet 资源。
6.Pod节点选择
在 Kubernetes 中，Pod 节点选择器（Node Selector）是一种用于指定 Pod 应该调度到哪个节点的机制。通过节点选择器，您可以控制 Pod 在集群中运行的节点，确保它们在符合特定条件的节点上运行。
如何使用节点选择器
-
标记节点： 首先，您需要为节点添加标签。标签是由键值对组成的，例如
role=frontend。kubectl label nodes <node-name> role=frontend -
使用节点选择器： 在 Pod 的定义文件中，您可以使用
nodeSelector来指定 Pod 应该调度到哪些节点。例如，如果您想让 Pod 只调度到标签为role=frontend的节点上，可以在 Pod 的 YAML 文件中指定节点选择器。apiVersion: v1 kind: Pod metadata:name: my-pod spec:containers:- name: my-containerimage: my-imagenodeSelector:role: frontend
示例
以下是一个完整的 Pod 定义文件示例，其中包含节点选择器：
apiVersion: v1
kind: Pod
metadata:name: example-pod
spec:containers:- name: example-containerimage: nginxnodeSelector:disktype: ssd
在这个例子中，Pod 将只会调度到具有 disktype=ssd 标签的节点上。
注意事项
- 节点选择器的限制：节点选择器只能基于节点的标签来做选择，比较简单。如果需要更复杂的调度策略，可以使用
affinity或taints and tolerations。 - 节点标签：确保节点已经正确地标记了标签，否则 Pod 可能会因为找不到符合条件的节点而无法调度。
- 多重标签匹配：如果节点有多个标签，节点选择器会匹配所有指定的标签条件。
通过合理配置节点选择器，您可以优化资源分配，提高 Pod 的性能和稳定性。
7.Pod制作查看删除标签
在 Kubernetes 中，给 Pod 打标签和删除标签的命令分别是：
7.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
要查看 Kubernetes 中 Pod 和 Node 的标签，可以使用 kubectl 命令。以下是分别查看 Pod 和 Node 标签的命令示例：
7.2 查看 Pod 标签
查看所有 Pods 的标签
kubectl get pods --show-labels
这会列出所有 Pods 及其标签。
查看特定 Pod 的标签
kubectl describe pod <pod-name>
在输出的详细信息中，找到 “Labels” 部分以查看 Pod 的标签。
只显示特定 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
7.3 查看 Node 标签
-
查看所有 Nodes 的标签
kubectl get nodes --show-labels这会列出所有 Nodes 及其标签。
-
查看特定 Node 的标签
kubectl describe node <node-name>在输出的详细信息中，找到 “Labels” 部分以查看 Node 的标签。
-
只显示特定 Node 的标签
kubectl get node <node-name> --template '{{range $k, $v := .metadata.labels}}{{$k}}: {{$v}}{{"\n"}}{{end}}'这条命令只显示指定 Node 的标签，以键值对的形式。
示例
假设你有一个名为 my-pod 的 Pod 和一个名为 my-node 的 Node：
查看所有 Pods 的标签
kubectl get pods --show-labels
查看名为 my-pod 的 Pod 的标签
kubectl describe pod my-pod
查看所有 Nodes 的标签
kubectl get nodes --show-labels
查看名为 my-node 的 Node 的标签
kubectl describe node my-node
这些命令可以帮助你快速查看 Kubernetes 中的 Pods 和 Nodes 的标签。
查看指定标签名的node信息
kubectl get node -l nodemaster=yes
kubectl get nodes -L project
7.4 删除标签
要删除 Pod 的标签，可以使用 kubectl label 命令并将标签值设置为空。以下是语法和示例：
kubectl label pod <pod-name> <key>-
<pod-name>：Pod 的名称。<key>：要删除的标签的键。
例如，删除名为 my-pod 的 Pod 上的 env 标签：
kubectl label pod my-pod env-
示例
假设你有一个名为 web-server 的 Pod：
-
打标签：
kubectl label pod web-server app=frontend -
删除标签：
kubectl label pod web-server app-
执行这些命令后，Pod 的标签会根据你所指定的操作被更新或删除。
示例
指定节点
方法一：通过nodeName方式
指定调度节点
kubectl explain rs.spec.template.spec.nodeNameapiVersion: apps/v1
kind: ReplicaSet
metadata:name: my-replicaset
spec:replicas: 4selector:matchLabels:app: myapptemplate:metadata:labels:app: myappspec:nodeName: node1containers:- name: mycontainerimage: harbor.hiuiu.com/nginx/nginx:1.21.5imagePullPolicy: Neverports:- containerPort: 80kubectl delete -f replicaset.yamlkubectl get pod -o wide
方法二：通过nodeSelector方式
kubectl explain rs.spec.template.spec.nodeSelectorapiVersion: apps/v1
kind: ReplicaSet
metadata:name: my-replicaset
spec:replicas: 4selector:matchLabels:app: myapptemplate:metadata:labels:app: myappspec:nodeSelector:nodemaster: "yes"containers:- name: mycontainerimage: harbor.hiuiu.com/nginx/nginx:1.21.5imagePullPolicy: Neverports:- containerPort: 80
kubectl apply -f replicaset.yaml
kubectl get pod -o wide
追加标签
kubectl label node node1 nodemaster=yes
#给node节点node1追加node标签
删除追加标签
kubectl label node node1 nodemaster-
node/node1 unlabeled
kubectl get node --show-labels
8.node亲和性
8.1 node亲和性
Kubernetes 的节点亲和性（Node Affinity）是一种调度机制，用于控制 Pod 被调度到哪些节点上。它允许你指定 Pod 应该运行在哪些特定的节点上，基于节点的标签。
节点亲和性是节点选择的扩展，它的配置方式类似于 Pod 的调度策略，通过在 Pod 的 spec.affinity.nodeAffinity 部分进行定义。下面是一些常见的节点亲和性用法和示例：
节点亲和性的基本概念
节点亲和性定义了 Pod 对节点的选择规则。它可以是：
- 必需亲和性（RequiredDuringSchedulingIgnoredDuringExecution）：这些规则必须满足，否则 Pod 将不会被调度到节点上。它是强制性的。
- 优先亲和性（PreferredDuringSchedulingIgnoredDuringExecution）：这些规则是优先考虑的，但不是强制性的。Kubernetes 将尽量满足这些规则，但如果无法满足，也不会阻止 Pod 调度。
affinity的缩进问题： `affinity` 应该在 `spec` 下的正确位置，与 `containers` 同级。podAffinity 的缩进问题： `podAffinity` 需要缩进正确，与 `requiredDuringSchedulingIgnoredDuringExecution` 同级。matchExpressions 的缩进问题： `matchExpressions` 应该是 `labelSelector` 的一部分。topologyKey 的位置： `topologyKey` 应该在 `requiredDuringSchedulingIgnoredDuringExecution` 的同级。image配置： `image` 使用的是 Nginx 镜像，但容器名为 `mysql`，这可能是一个错误，如果这是故意的，那没有问题，但一般来说容器名应与镜像一致。
配置实列
必需亲和性
kubectl explain pods.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution#调度器将倾向于将pods调度到满足该字段指定的亲和性表达式的节点上，但它也可能选择违背一个或多个表达式的节点。最受青睐的节点是具有最大权重和的节点，即对于每个满足所有调度要求(资源请求、调度期间的亲和性表达式等)的节点，通过迭代该字段的元素计算和，如果节点匹配相应的匹配表达式，则为和添加“权重”，具有最高权重的节点是最受青睐的。---- 是软性偏好，表示调度器会尽量但不强求将Pod调度到满足特定条件的节点上
kubectl explain pods.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution
apiVersion: v1
kind: Pod
metadata:name: pod-node-affinity-demonamespace: defaultlabels:app: myapp
spec:containers:- name: myappimage: harbor.hiuiu.com/nginx/nginx:1.21.5affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: zoneoperator: Invalues:- ky36- ccc
kubectl apply -f replicaset.yaml
kubectl get pod -o wide
优先亲和性
kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution#如果调度时不满足该字段指定的亲和性要求，pod将不会被调度到该节点上。如果该字段指定的亲和性需求在pod执行期间的某个点停止满足(例如由于更新)，系统可能会也可能不会尝试最终将pod从其节点中移除。---- 是硬性要求，表示Pod必须被调度到满足特定条件的节点上
kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution
apiVersion: v1
kind: Pod
metadata:name: pod-node-affinity-demonamespace: defaultlabels:app: myapp
spec:containers:- name: myappimage: harbor.hiuiu.com/nginx/nginx:1.21.5affinity:nodeAffinity:preferredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: zoneoperator: Invalues:- ky36- ccc
root@master:/opt/zxy# kubectl apply -f replicaset.yaml
replicaset.apps/my-replicaset created
root@master:/opt/zxy# kubectl get pod -o wide
亲和性类型解释
- matchExpressions：指定节点标签的匹配规则。
key是标签的键，operator是匹配操作（如In,NotIn,Exists,DoesNotExist），values是匹配的值列表。 - matchFields：指定节点字段的匹配规则。类似于
matchExpressions，但用于匹配节点字段。
常见用法
- 限制 Pod 只能运行在某些特定类型的节点上：例如，确保高性能的计算任务仅在具有 SSD 的节点上运行。
- 将应用程序 Pod 调度到特定区域或数据中心：例如，确保某些服务在特定的地理区域运行以满足法规或延迟要求。
通过正确配置节点亲和性，可以有效地控制 Pod 的调度策略，从而优化资源的使用和提高集群的稳定性。
8.2 Pod亲和性
Pod亲和性用于确保Pod被调度到与其它Pod在同一个节点或相邻节点上，从而支持同一应用的Pod之间的协作
示例：
将Pod调度到与具有特定标签的Pod相同的节点上：
topologyKey：（ 获取topologyKey : kubectl get nodes --show-labels )
#topologyKey是节点标签（Node Label）的键，用于标识节点在集群中的拓扑位置。通过在Pod的亲和性（Affinity）、反亲和性（Anti-Affinity）或拓扑分布约束（Topology Spread Constraints）中指定topologyKey，可以精确地控制Pod的调度位置，以满足特定的硬件或软件要求。
Pod亲和性
kubectl explain pods.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey
yaml1
apiVersion: v1
kind: Pod
metadata:name: pod-firstlabels:app2: myapp2tier: frontend
spec:containers:- name: myappimage: harbor.hiuiu.com/nginx/nginx:1.21.5yaml2
apiVersion: v1
kind: Pod
metadata:name: pod-secondlabels:app: backendtier: db
spec:containers:- name: mysqlimage: harbor.hiuiu.com/nginx/nginx:1.21.5imagePullPolicy: IfNotPresentaffinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: app2operator: Invalues:- myapp2topologyKey: kubernetes.io/hostnameroot@master:/opt/zxy# kubectl apply -f pod1.yaml
pod/pod-first created
root@master:/opt/zxy# kubectl apply -f pod2.yaml
pod/pod-second created
root@master:/opt/zxy# kubectl get pod -o wide
Pod 反亲和性
kubectl explain pods.spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey# 他的pod应该与指定的命名空间中与labelSelector匹配的pod同处(affinity)或非同处(anti-affinity)，其中co-located定义为运行在一个节点上，其标签的键topologyKey的值与所选pod运行的任何节点的值相匹配。不允许为空的拓扑键。
9.Pod 拉取镜像策略
kubectl explain pod.spec.containers.imagePullPolicy##imagePullPolicy (镜像拉取策略)：:IfNotPresent：node节点没有此镜像就去指定的镜像仓库拉取，node有就使用node本地镜像。Always：每次重建pod都会重新拉取镜像Never：从不到镜像中心拉取镜像，只使用本地镜
10.Pod重启策略
kubectl explain pod.spec.restartPolicyrestartPolicy- `"Always"` - `"Never"` - `"OnFailure"`
