From e86d7e2f70fbcceda0cd16e03a7e348e5b90bd4d Mon Sep 17 00:00:00 2001
From: Caitin <34535727+CaitinChen@users.noreply.github.com>
Date: Fri, 15 May 2020 20:51:53 +0800
Subject: [PATCH] zh: fix a broken link (#286)

---
 zh/configure-a-tidb-cluster.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/configure-a-tidb-cluster.md b/zh/configure-a-tidb-cluster.md
index fe65c068fd..9b822e93ff 100644
--- a/zh/configure-a-tidb-cluster.md
+++ b/zh/configure-a-tidb-cluster.md
@@ -26,7 +26,7 @@ TiDB 是分布式数据库，它的容灾需要做到在任一个物理拓扑节
 
 TiDB 服务容灾本质上基于 Kubernetes 的调度功能来实现的，为了优化调度，TiDB Operator 提供了自定义的调度器，该调度器通过指定的调度算法能在 host 层面，保证 TiDB 服务的容灾，而且目前 TiDB Cluster 使用该调度器作为默认调度器，设置项是上述列表中的 `schedulerName` 配置项。
 
-其它层面的容灾（例如 rack，zone，region）是通过 Affinity 的 `PodAntiAffinity` 来保证，通过 `PodAntiAffinity` 能尽量避免同一组件的不同实例部署到同一个物理拓扑节点上，从而达到容灾的目的，Affinity 的使用参考：[Affinity & AntiAffinity](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#affinity-and-anti-affinity)。
+其它层面的容灾（例如 rack，zone，region）是通过 Affinity 的 `PodAntiAffinity` 来保证，通过 `PodAntiAffinity` 能尽量避免同一组件的不同实例部署到同一个物理拓扑节点上，从而达到容灾的目的，Affinity 的使用参考：[Affinity & AntiAffinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)。
 
 下面是一个典型的容灾设置例子：