Kubernetes 节点标签与调度配置详解
一、Kubernetes 节点标签(Label)
(一)核心概念
在 Kubernetes 集群中,节点(Node)作为承载工作负载的基础设施单元,可以是物理机或虚拟机。标签(Label)是一种键值对形式的标识符,能够附加到节点上。它为节点提供了灵活的分类与选择机制,便于根据业务需求对节点进行组织和管理。
(二)操作方法
-
添加与更新标签
- 使用命令
kubectl label nodes <node-name> <key>=<value>
为节点添加标签。例如,为节点node-1
添加标签region=east
,命令如下:kubectl label nodes node-1 region=east
- 若需更新已存在的标签值,可使用相同命令并附加
--overwrite
选项。如将node-1
的region
标签值更新为west
:kubectl label nodes node-1 region=west --overwrite
- 使用命令
-
查看节点标签
- 执行
kubectl describe node <node-name>
查看节点详细信息,其中包含标签。例如:kubectl describe node node-1
- 使用
kubectl get nodes --show-labels
查看所有节点及其标签。输出示例:
这里node-1 <none> node-2 disktype=ssd,region=west
<none>
表示节点无标签,其他则显示对应标签。
- 执行
二、基于标签的节点选择(NodeSelector)
(一)基本概念
nodeSelector
是 Kubernetes 提供的一种简单调度方式,允许在创建 Pod 时指定一个或多个标签。调度器会根据这些标签,将 Pod 调度到具有匹配标签的节点上。
(二)配置方法
在 Pod 的 YAML 配置文件中,通过 nodeSelector
字段指定标签。示例:
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
nodeSelector:
disktype: ssd
region: west
此示例中,调度器将寻找同时具有 disktype=ssd
和 region=west
标签的节点来部署 Pod。
(三)适用场景与局限
适用于简单场景下基于等值匹配的节点选择。但仅支持相等匹配关系,对于更复杂的标签选择逻辑(如不等于、存在等),需要使用 nodeAffinity
。
三、在控制器中配置节点选择
(一)DaemonSet 配置示例
DaemonSet 确保指定节点上运行一个 Pod 副本。通过 nodeSelector
指定其 Pod 部署的节点:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: example-daemonset
spec:
selector:
matchLabels:
name: example-daemonset-pod
template:
metadata:
labels:
name: example-daemonset-pod
spec:
containers:
- name: example-container
image: nginx:latest
nodeSelector:
disktype: ssd
region: west
(二)Deployment 配置示例
Deployment 管理 Pod 副本集。通过 nodeSelector
控制其创建的 Pod 的部署节点:
apiVersion: apps/v1
kind: Deployment
metadata:
name: example-deployment
spec:
replicas: 3
selector:
matchLabels:
app: example-app
template:
metadata:
labels:
app: example-app
spec:
containers:
- name: example-container
image: nginx:latest
nodeSelector:
disktype: ssd
四、高级节点选择机制:NodeAffinity
(一)功能特点
nodeAffinity
提供更强大的节点选择能力,支持以下两种规则:
- requiredDuringSchedulingIgnoredDuringExecution:硬规则,Pod 只能调度到满足条件的节点。
- preferredDuringSchedulingIgnoredDuringExecution:软规则,优先选择满足条件的节点,但非强制。
(二)配置示例
apiVersion: apps/v1
kind: Deployment
metadata:
name: example-deployment
spec:
replicas: 3
selector:
matchLabels:
app: example-app
template:
metadata:
labels:
app: example-app
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: region
operator: In
values:
- west
- key: disktype
operator: NotIn
values:
- hdd
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: disktype
operator: In
values:
- ssd
containers:
- name: example-container
image: nginx:latest
五、配置注意事项
- 标签管理:确保在使用
nodeSelector
或nodeAffinity
前,已为节点正确配置标签。 - 规则兼容性:
nodeSelector
和nodeAffinity
可同时使用,但需确保规则不冲突。 - 默认调度行为:若未指定节点选择配置,Kubernetes 将根据默认调度算法自动选择节点。
通过合理配置节点标签与调度策略,可以实现对 Pod 在集群中部署位置的精细控制,满足性能优化、资源隔离等业务需求。
举例
以下是完善后的操作步骤,包含查看标签、备份配置文件等操作,确保操作的完整性与可追溯性:
步骤 1:查看节点标签(确认初始状态)
执行以下命令查看所有节点的标签,确认 rds4
和 rds5
节点标签是否符合预期:
kubectl get nodes --show-labels
步骤 2:备份 metallb-speaker
配置文件(防止配置丢失)
将 metallb-speaker
守护进程集的当前配置导出并保存为备份文件:
kubectl get ds metallb-speaker -oyaml > original_metallb-speaker.yaml
步骤 3:为节点打标签
为节点 rds4
和 rds5
打上标签 qfusion/metallb
(值为空),执行命令:
kubectl label nodes rds4 qfusion/metallb=
kubectl label nodes rds5 qfusion/metallb=
步骤 4:编辑 metallb-speaker
守护进程集(DaemonSet)
通过命令编辑 metallb-speaker
的 YAML 配置:
kq edit ds metallb-speaker -oyaml
在打开的 YAML 编辑器中,进行以下修改:
- 添加节点选择器(
nodeSelector
):nodeSelector: qfusion/metallb: ""
- 添加注解(Annotation):
在合适位置(如metadata.annotations
下)添加:installer.woqutech.com/managed-by-nochange: qfusion-installer-operator
步骤 5:验证配置修改(可选)
修改保存后,可再次执行以下命令,确认配置是否更新:
kubectl get ds metallb-speaker -oyaml | grep -E 'nodeSelector|installer.woqutech.com'
此命令将过滤出与修改相关的配置内容,确保 nodeSelector
和注解已正确应用。
通过以上步骤,不仅完成了节点标签设置与配置编辑,还增加了标签查看、配置备份及修改验证环节,提升了操作的规范性和可维护性。