在Kubernetes中，你可以使用节点亲和性（Node Affinity）来控制Pod部署在哪些节点上。通过配置节点亲和性，你可以指定一些规则，以确保多个服务不会被调度到同一个节点上。
两种策略
-
requiredDuringSchedulingIgnoredDuringExecution：通过
requiredDuringSchedulingIgnoredDuringExecution，可以定义在调度期间必须满足的 Affinity 规则。这意味着规则在调度期间必须满足，但如果在运行时不满足，则不会强制执行。 -
preferredDuringSchedulingIgnoredDuringExecution：使用
preferredDuringSchedulingIgnoredDuringExecution，可以定义首选的 Affinity 规则。这意味着规则是首选的，但不是强制的，如果无法满足则可以继续调度。
节点亲和性实现
以下是一些在部署Deployment时避免多个服务部署到同一节点的常用方法：
- 使用节点亲和性标签（Node Affinity）：你可以给每个服务定义一个独特的节点亲和性标签，然后通过
affinity字段将这些标签添加到对应的PodSpec中。例如，给服务A定义service=a的标签，给服务B定义service=b的标签。然后，在Deployment的PodSpec中使用nodeAffinity字段来指定节点亲和性规则，确保两个服务不会调度到同一个节点上。
- 使用requiredDuringSchedulingIgnoredDuringExecution强制策略，如果不满足，你的pod将不能被调度
- 节点A上添加标签type=product,service-a将被调度到这个节点
- 节点B上添加标签type=order,service-b将被调度到这个节点
- service-a.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: service-a
spec:
replicas: 1
selector:
matchLabels:
app: service-a
template:
metadata:
labels:
app: service-a
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: type
operator: In
values:
- product
containers:
- name: service-a
image: nginx:stable-alpine
- service-b.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: service-b
spec:
replicas: 1
selector:
matchLabels:
app: service-b
template:
metadata:
labels:
app: service-b
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: type
operator: In
values:
- order
containers:
- name: service-b
image: nginx:stable-alpine
上面使用正则表达式matchExpressions来确定目标，也可以使用标签matchLabels的方式，更简洁，如下：
# 亲和性
affinity:
# Pod亲和性规则
podAffinity:
# 强制性的调度规则, 但不会影响已在节点上运行的Pod
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: kubernetes.io/hostname
# 标签选择器
labelSelector:
matchLabels:
app: service-a
- 使用非强制策略，配置weight权重一起使用
apiVersion: apps/v1
kind: Deployment
metadata:
name: service-a-order
spec:
# Pod副本数量
replicas: 4
selector:
matchLabels:
app: service-a-order
# Pod模板
template:
metadata:
# 标签信息: 应用的后端服务
labels:
app: service-a-order
spec:
# 亲和性
affinity:
# Pod亲和性规则
podAntiAffinity:
# 强制性的调度规则, 但不会影响已在节点上运行的Pod
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
topologyKey: kubernetes.io/hostname
# 标签选择器
labelSelector:
matchExpressions: # 也需要matchLabels
- key: app
operator: In
values:
- service-a-order
# 容器信息
containers:
- name: service-a-order
image: nginx:stable-alpine
扩展阅读
app.kubernetes.io/instance Kubernetes的应用标识
在Kubernetes中，app.kubernetes.io/instance是一个标签（Label），用于标识应用程序实例的实例ID或名称。
标签是键值对的形式，用于为资源对象（如Pod、Deployment、Service等）添加元数据信息。app.kubernetes.io/instance是一个预定义的标签键，用于表示应用程序实例的唯一标识符。
通常，当您使用Kubernetes部署多个相同类型的应用程序实例时，每个实例都会被分配一个唯一的实例ID或名称。您可以使用app.kubernetes.io/instance标签来标识和区分这些应用程序实例。
例如，假设您使用Kubernetes部署了一个名为"my-app"的应用程序，并在该应用程序的多个副本之间进行了扩展。每个副本都会被分配一个唯一的实例ID或名称。通过为每个副本设置app.kubernetes.io/instance标签，您可以区分和识别每个应用程序实例。
标签可以通过Kubernetes API或命令行工具（如kubectl）进行管理和查询。您可以使用kubectl get pods --show-labels命令来查看资源对象的标签信息，包括app.kubernetes.io/instance标签和对应的实例ID或名称值。
kubernetes.io/hostname 节点的主机名
在Kubernetes中，kubernetes.io/hostname是一个节点标签（Node Label），用于标识节点的主机名（Hostname）。
节点标签是一种键值对的形式，用于为节点添加自定义的元数据信息。通过为节点添加标签，您可以根据标签进行节点选择和调度。kubernetes.io/hostname是一个预定义的标签键，用于表示节点的主机名。
节点的主机名是节点所在主机的唯一标识符。Kubernetes使用主机名来识别和管理节点，并在集群中唯一标识每个节点。kubernetes.io/hostname标签的值将设置为节点的实际主机名。
例如，假设您在Kubernetes集群中有多个节点，并且每个节点都有不同的主机名。通过查看节点的kubernetes.io/hostname标签，您可以了解到每个节点的实际主机名，并在进行节点选择或调度时使用这些信息。
节点标签可以通过Kubernetes API或命令行工具（如kubectl）进行管理和查询。您可以使用kubectl get nodes --show-labels命令来查看节点标签信息，包括kubernetes.io/hostname标签和对应的主机名值。