我们有3个ESXi主机,每个主机2个Kubernetes工人。所有节点都标记有“ esxhost:esxN”,我想在这些主机上散布副本。它很容易将副本散布在工作线程上,在一台主机上没有相同的服务,但是我想散布在ESXi主机上,即使两名工作人员死亡,也要拥有HA,因为ESXi主机死了。
我该如何管理?尝试了一些选择,但没有成功。
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo
namespace: someNS
spec:
replicas: 2
selector:
matchLabels:
app: demo
template:
metadata:
labels:
app: demo
spec:
containers:
- name: demo-mos-node
image: registry.docker.dev...../demo:2.1.2
ports:
- containerPort: 80
env:
- name: CONFIG
value: "https://config.git.dev....."
答案 0 :(得分:0)
您可以定义反亲和力规则。这些用于使豆荚彼此远离。有2种变体:
soft(preferredDuringSchedulingIgnoredDuringExecution)
硬(必需DuringSchedulingIgnoredDuringExecution)
如果您指定hard变体,则如果该节点上已经有一个Pod,则该Pod将不会调度到该节点。
如果您指定软变量,则如果该节点已在运行带有标签为“ app”和值为“ demo”的标签的Pod,则该Pod最好不要安排在该节点上
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- demo
topologyKey: "kubernetes.io/hostname"
此外,如果要在主节点上计划Pod,则必须删除主节点的默认污点:
kubectl get nodes
kubectl describe node master_node_name
kubectl taint nodes master_node_name key:NoSchedule-
https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
答案 1 :(得分:0)
正如@iliefa所说,您应该使用pod反亲和力,但是必须定义2个亲和力术语。第一个将防止(软或硬)pod在同一节点上的分发,第二个将防止(软或硬)pod在相同可用性区域中的分发(您将其称为ESXi主机)。也许您可以使用built in labes,或更具体地说-failure-domain.beta.kubernetes.io/zone
。另一个选择是根据可用区域为节点添加标签。这是我的意思的示例:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: <define-importance-here>
podAffinityTerm:
topologyKey: kubernetes.io/hostname
labelSelector:
matchLabels:
<insert-your-pod-labels-here>
- weight: <define-importance-here>
podAffinityTerm:
topologyKey: failure-domain.beta.kubernetes.io/zone
labelSelector:
matchLabels:
<insert-your-pod-labels-here>
您施加的权重将定义每个反亲和力规则与另一个规则相比的重要性。