diff --git a/concepts/pod.md b/concepts/pod.md
index ce1a46d9b..7e399b149 100644
--- a/concepts/pod.md
+++ b/concepts/pod.md
@@ -54,7 +54,7 @@ Pod也可以用于垂直应用栈（例如LAMP），这样使用的主要动机
 
 通常单个pod中不会同时运行一个应用的多个实例。
 
-详细说明请看： [The Distributed System ToolKit: Patterns for Composite Containers](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html).
+详细说明请看： [The Distributed System ToolKit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/).
 
 ## 其他替代选择
 
@@ -115,7 +115,7 @@ Pod的强制删除是通过在集群和etcd中将其定义为删除状态。当
 
 ## Pod中容器的特权模式
 
-从Kubernetes1.1版本开始，pod中的容器就可以开启previleged模式，在容器定义文件的 `SecurityContext` 下使用 `privileged` flag。 这在使用Linux的网络操作和访问设备的能力时是很有用的。容器内进程可获得近乎等同于容器外进程的权限。在不需要修改和重新编译kubelet的情况下就可以使用pod来开发节点的网络和存储插件。
+从Kubernetes1.1版本开始，pod中的容器就可以开启privileged模式，在容器定义文件的 `SecurityContext` 下使用 `privileged` flag。 这在使用Linux的网络操作和访问设备的能力时是很有用的。容器内进程可获得近乎等同于容器外进程的权限。在不需要修改和重新编译kubelet的情况下就可以使用pod来开发节点的网络和存储插件。
 
 如果master节点运行的是kuberentes1.1或更高版本，而node节点的版本低于1.1版本，则API server将也可以接受新的特权模式的pod，但是无法启动，pod将处于pending状态。
 
diff --git a/concepts/scheduling.md b/concepts/scheduling.md
index 90d475eb9..9d376bc20 100644
--- a/concepts/scheduling.md
+++ b/concepts/scheduling.md
@@ -8,5 +8,5 @@ Kubernetes中的众多资源类型，例如Deployment、DaemonSet、StatefulSet
 
 考虑以下两种情况：
 
-- 集群中有新增节点，想要让集群中的节点的资源利用率比较均衡一些，想要将一些高负载的节点上的pod驱逐到新增节点上，这是kuberentes的scheduer所不支持的，需要使用如[rescheduler](https://github.com/kubernetes-incubator/descheduler)这样的插件来实现。
-- 想要运行一些大数据应用，设计到资源分片，pod需要与数据分布达到一致均衡，避免个别节点处理大量数据，而其它节点闲置导致整个作业延迟，这时候可以考虑使用[kube-arbitritor](https://github.com/kubernetes-incubator/kube-arbitrator)。
\ No newline at end of file
+- 集群中有新增节点，想要让集群中的节点的资源利用率比较均衡一些，想要将一些高负载的节点上的pod驱逐到新增节点上，这是kuberentes的scheduler所不支持的，需要使用如[descheduler](https://github.com/kubernetes-incubator/descheduler)这样的插件来实现。
+- 想要运行一些大数据应用，设计到资源分片，pod需要与数据分布达到一致均衡，避免个别节点处理大量数据，而其它节点闲置导致整个作业延迟，这时候可以考虑使用[kube-batch](https://github.com/kubernetes-incubator/kube-batch)。
\ No newline at end of file