K8s daemonset 高可用
K8s deamon set high avialibality
我们有一个 deamonset 并且我们想让它成为 HA（不是我们的 deamonset），以下是否也适用于 deamon set 的 HA？
- 亲和（反亲和）
- 容忍度
- pdb
我们在每个集群上有 3 个工作节点
我过去曾为部署而做过，但不确定什么也适用于 deamonset，这 不是我们的应用程序 但我们需要确保它是 HA，因为它是关键应用程序
更新
将以下内容添加到 deamonset 是否有意义，假设我有 3 个工作节点并且我希望它仅在 foo 个工作节点中安排？
spec:
tolerations:
- effect: NoSchedule
key: WorkGroup
operator: Equal
value: foo
- effect: NoExecute
key: WorkGroup
operator: Equal
value: foo
nodeSelector:
workpcloud.io/group: foo
您无法控制 DaemonSet 中的副本，因为 DaemonSet 每个节点将有一个 pod。
您需要将对象更改为 Deployment 或 Statefulset 以管理副本计数并使用 nodeSelector 将其部署到所有节点中。
您问了两个不太相关的问题。
does the following is applicable for HA for deamaon set also?
- affinity (anti affinity)
- toleration's
- pdb
A daemonset（通常）运行s 在“每个节点一个 pod”的策略上——你 不能 使其高可用性（例如，通过使用自动缩放），你将（假设你使用默认值）拥有与节点一样多的守护进程副本，除非你明确指定你想要哪些节点 运行 守护进程 pods，使用 nodeSelector and/or tolerations 之类的东西，在这种情况下，您的 pods 会更少。上面链接的文档页面提供了更多详细信息和一些示例
this is not our app but we need to make sure it is HA as it's critical app
您是在问如何让您的关键应用高可用吗？我假设你是。
如果应用像您所说的那样重要，那么一些入门建议：
- 确保您至少有 3 个副本（4 个是一个很好的起始数字）
- 如果您必须将这些 pods 安排在有污点的节点池上，请添加容忍度
- 根据需要使用节点选择器（例如，对于区域或区域，但仅在必要时才对这些区域中存在的磁盘进行处理）
- 使用亲和力来分组或传播您的副本。绝对会推荐使用 spread，这样如果一个节点出现故障，其他副本仍在运行
- 使用 pod priority 向集群表明您的 pods 比其他 pods 更重要（请注意，如果您将其设置得太高可能会导致问题）
- 为 PagerDuty、OpsGenie 等设置通知，以便您（或您的运营团队）在应用程序出现故障时收到通知。如果应用程序很关键，那么您会想尽快知道它已关闭。
- 设置 pod disruption budgets, and horizontal pod autoscalers 以确保约定数量的 pods 始终可用。
我们有一个 deamonset 并且我们想让它成为 HA（不是我们的 deamonset），以下是否也适用于 deamon set 的 HA？
- 亲和（反亲和）
- 容忍度
- pdb
我们在每个集群上有 3 个工作节点 我过去曾为部署而做过，但不确定什么也适用于 deamonset，这 不是我们的应用程序 但我们需要确保它是 HA，因为它是关键应用程序
更新
将以下内容添加到 deamonset 是否有意义，假设我有 3 个工作节点并且我希望它仅在 foo 个工作节点中安排？
spec:
tolerations:
- effect: NoSchedule
key: WorkGroup
operator: Equal
value: foo
- effect: NoExecute
key: WorkGroup
operator: Equal
value: foo
nodeSelector:
workpcloud.io/group: foo
您无法控制 DaemonSet 中的副本，因为 DaemonSet 每个节点将有一个 pod。
您需要将对象更改为 Deployment 或 Statefulset 以管理副本计数并使用 nodeSelector 将其部署到所有节点中。
您问了两个不太相关的问题。
does the following is applicable for HA for deamaon set also?
- affinity (anti affinity)
- toleration's
- pdb
A daemonset（通常）运行s 在“每个节点一个 pod”的策略上——你 不能 使其高可用性（例如，通过使用自动缩放），你将（假设你使用默认值）拥有与节点一样多的守护进程副本，除非你明确指定你想要哪些节点 运行 守护进程 pods，使用 nodeSelector and/or tolerations 之类的东西，在这种情况下，您的 pods 会更少。上面链接的文档页面提供了更多详细信息和一些示例
this is not our app but we need to make sure it is HA as it's critical app
您是在问如何让您的关键应用高可用吗？我假设你是。
如果应用像您所说的那样重要，那么一些入门建议：
- 确保您至少有 3 个副本（4 个是一个很好的起始数字）
- 如果您必须将这些 pods 安排在有污点的节点池上，请添加容忍度
- 根据需要使用节点选择器（例如，对于区域或区域，但仅在必要时才对这些区域中存在的磁盘进行处理）
- 使用亲和力来分组或传播您的副本。绝对会推荐使用 spread，这样如果一个节点出现故障，其他副本仍在运行
- 使用 pod priority 向集群表明您的 pods 比其他 pods 更重要（请注意，如果您将其设置得太高可能会导致问题）
- 为 PagerDuty、OpsGenie 等设置通知，以便您（或您的运营团队）在应用程序出现故障时收到通知。如果应用程序很关键，那么您会想尽快知道它已关闭。
- 设置 pod disruption budgets, and horizontal pod autoscalers 以确保约定数量的 pods 始终可用。