diff --git a/content/cn/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/cn/docs/tasks/access-application-cluster/connecting-frontend-backend.md
index 0c12f2410d..74ba22eaa4 100644
--- a/content/cn/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+++ b/content/cn/docs/tasks/access-application-cluster/connecting-frontend-backend.md
@@ -34,7 +34,7 @@ content_template: templates/tutorial
 
 * 本任务使用 [外部负载均衡服务](/docs/tasks/access-application-cluster/create-external-load-balancer/)，
   所以需要对应的可支持此功能的环境。如果你的环境不能支持，你可以使用
-  [NodePort](/docs/user-guide/services/#type-nodeport) 类型的服务代替。
+  [NodePort](/docs/user-guide/services/#nodeport) 类型的服务代替。
 
 {{% /capture %}}
 
diff --git a/content/cn/docs/tutorials/services/source-ip.md b/content/cn/docs/tutorials/services/source-ip.md
index 77da6af9d0..c4b4bd34e9 100644
--- a/content/cn/docs/tutorials/services/source-ip.md
+++ b/content/cn/docs/tutorials/services/source-ip.md
@@ -116,7 +116,7 @@ command=GET
 ## Type=NodePort 类型 Services 的 Source IP
 
 
-对于 Kubernetes 1.5，发送给类型为 [Type=NodePort](/docs/user-guide/services/#type-nodeport) Services 的数据包默认进行源地址 NAT。你可以创建一个 `NodePort` Service 来进行测试：
+对于 Kubernetes 1.5，发送给类型为 [Type=NodePort](/docs/user-guide/services/#nodeport) Services 的数据包默认进行源地址 NAT。你可以创建一个 `NodePort` Service 来进行测试：
 
 ```console
 $ kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
@@ -210,7 +210,7 @@ client_address=104.132.1.79
 ## Type=LoadBalancer 类型 Services 的 Source IP
 
 
-对于 Kubernetes 1.5，发送给类型为 [Type=LoadBalancer](/docs/user-guide/services/#type-nodeport) Services 的数据包默认进行源地址 NAT，这是由于所有处于 `Ready` 状态的 Kubernetes 节点对于负载均衡的流量都是符合条件的。所以如果数据包到达一个没有 endpoint 的节点，系统将把这个包代理到*有* endpoint 的节点，并替换数据包的源 IP 为节点的 IP（如前面章节所述）。
+对于 Kubernetes 1.5，发送给类型为 [Type=LoadBalancer](/docs/user-guide/services/#nodeport) Services 的数据包默认进行源地址 NAT，这是由于所有处于 `Ready` 状态的 Kubernetes 节点对于负载均衡的流量都是符合条件的。所以如果数据包到达一个没有 endpoint 的节点，系统将把这个包代理到*有* endpoint 的节点，并替换数据包的源 IP 为节点的 IP（如前面章节所述）。
 
 
 你可以通过在一个 loadbalancer 上暴露这个 source-ip-app 来进行测试。
diff --git a/content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
index 030d2c24e5..5d521f02c7 100644
--- a/content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
+++ b/content/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
@@ -15,7 +15,7 @@ approvers:
 
 * [Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) 定义持久化磁盘（磁盘生命周期不和 Pods 绑定）。
 * [Services](https://kubernetes.io/docs/concepts/services-networking/service/) 使得 Pods 能够找到其它 Pods。
-* [External Load Balancers](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer) 对外暴露 Services。
+* [External Load Balancers](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer) 对外暴露 Services。
 * [Deployments](http://kubernetes.io/docs/user-guide/deployments/) 确保 Pods 持续运行。
 * [Secrets](http://kubernetes.io/docs/user-guide/secrets/) 保存敏感密码信息。
 
@@ -66,7 +66,7 @@ kubectl create -f https://raw.githubusercontent.com/kubernetes/examples/master/m
 Kubernetes本质是模块化的，可以在各种环境中运行。但并不是所有集群都相同。此处是本示例的一些要求：
 * 需要 1.2 版本以上的 Kubernetes，以使用更新的特性，例如 PV Claims 和 Deployments。运行 `kubectl version` 来查看你的集群版本。
 * [Cluster DNS](https://github.com/kubernetes/dns) 将被用于服务发现。
-* 一个 [external load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer) 将被用于接入 WordPress。
+* 一个 [external load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer) 将被用于接入 WordPress。
 * 使用了 [Persistent Volume Claims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。你必须创建集群中需要的 Persistent Volumes。本示例将展示两种类型的 volume 的创建方法，但是任何类型的 volume 都是足够使用的。
 
 
diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md
index bf8269dc56..17926fa5f3 100644
--- a/content/en/docs/concepts/configuration/overview.md
+++ b/content/en/docs/concepts/configuration/overview.md
@@ -52,7 +52,7 @@ This is a living document. If you think of something that is not on this list bu
 
   If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
 
-  If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#type-nodeport) Service before resorting to `hostPort`.
+  If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#nodeport) Service before resorting to `hostPort`.
 
 - Avoid using `hostNetwork`, for the same reasons as `hostPort`.
 
diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md
index 0300f8ec68..5a2477b23b 100644
--- a/content/en/docs/concepts/services-networking/ingress.md
+++ b/content/en/docs/concepts/services-networking/ingress.md
@@ -275,7 +275,7 @@ that it applies to all Ingress, such as the load balancing algorithm, backend
 weight scheme, and others. More advanced load balancing concepts
 (e.g. persistent sessions, dynamic weights) are not yet exposed through the
 Ingress. You can still get these features through the
-[service loadbalancer](https://github.com/kubernetes/ingress-nginx/blob/master/docs/ingress-controller-catalog.md).
+[service loadbalancer](https://github.com/kubernetes/ingress-nginx).
  With time, we plan to distill load balancing patterns that are applicable
 cross platform into the Ingress resource.
 
@@ -353,8 +353,8 @@ Please track the [L7 and Ingress proposal](https://github.com/kubernetes/kuberne
 
 You can expose a Service in multiple ways that don't directly involve the Ingress resource:
 
-* Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#type-loadbalancer)
-* Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#type-nodeport)
+* Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
+* Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
 * Use a [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service)
 {{% /capture %}}
 
diff --git a/content/en/docs/reference/federation/v1/definitions.html b/content/en/docs/reference/federation/v1/definitions.html
index 82a8434e74..05b55bda6f 100755
--- a/content/en/docs/reference/federation/v1/definitions.html
+++ b/content/en/docs/reference/federation/v1/definitions.html
@@ -1871,7 +1871,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }
 </tr>
 <tr>
 <td class="tableblock halign-left valign-top"><p class="tableblock">nodePort</p></td>
-<td class="tableblock halign-left valign-top"><p class="tableblock">The port on each node on which this service is exposed when type=NodePort or LoadBalancer. Usually assigned by the system. If specified, it will be allocated to the service if unused or else creation of the service will fail. Default is to auto-allocate a port if the ServiceType of this Service requires one. More info: <a href="https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport">https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The port on each node on which this service is exposed when type=NodePort or LoadBalancer. Usually assigned by the system. If specified, it will be allocated to the service if unused or else creation of the service will fail. Default is to auto-allocate a port if the ServiceType of this Service requires one. More info: <a href="https://kubernetes.io/docs/concepts/services-networking/service/#nodeport">https://kubernetes.io/docs/concepts/services-networking/service/#nodeport</a></p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">integer (int32)</p></td>
 <td class="tableblock halign-left valign-top"></td>
diff --git a/content/en/docs/setup/independent/troubleshooting-kubeadm.md b/content/en/docs/setup/independent/troubleshooting-kubeadm.md
index 63effc4670..4ba8688e6c 100644
--- a/content/en/docs/setup/independent/troubleshooting-kubeadm.md
+++ b/content/en/docs/setup/independent/troubleshooting-kubeadm.md
@@ -123,7 +123,7 @@ Calico, Canal, and Flannel CNI providers are verified to support HostPort.
 For more information, see the [CNI portmap documentation](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md).
 
 If your network provider does not support the portmap CNI plugin, you may need to use the [NodePort feature of
-services](/docs/concepts/services-networking/service/#type-nodeport) or use `HostNetwork=true`.
+services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetwork=true`.
 
 ## Pods are not accessible via their Service IP
 
diff --git a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md
index 2329fbaad5..f91ce1b72a 100644
--- a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+++ b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md
@@ -31,7 +31,7 @@ frontend and backend are connected using a Kubernetes Service object.
   [Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which
   require a supported environment. If your environment does not
   support this, you can use a Service of type
-  [NodePort](/docs/concepts/services-networking/service/#type-nodeport) instead.
+  [NodePort](/docs/concepts/services-networking/service/#nodeport) instead.
 
 {{% /capture %}}
 
diff --git a/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
index 4d631b302f..ae747d0716 100644
--- a/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
+++ b/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
@@ -33,7 +33,7 @@ documentation.
 ## Configuration file
 
 To create an external load balancer, add the following line to your
-[service configuration file](/docs/concepts/services-networking/service/#type-loadbalancer):
+[service configuration file](/docs/concepts/services-networking/service/#loadbalancer):
 
 ```json
     "type": "LoadBalancer"
diff --git a/content/en/docs/tasks/federation/federation-service-discovery.md b/content/en/docs/tasks/federation/federation-service-discovery.md
index 530fe86157..6992a54bd4 100644
--- a/content/en/docs/tasks/federation/federation-service-discovery.md
+++ b/content/en/docs/tasks/federation/federation-service-discovery.md
@@ -138,7 +138,7 @@ underlying Kubernetes services (once these have been allocated - this
 may take a few seconds). For inter-cluster and inter-cloud-provider
 networking between service shards to work correctly, your services
 need to have an externally visible IP address. [Service Type:
-Loadbalancer](/docs/concepts/services-networking/service/#type-loadbalancer)
+Loadbalancer](/docs/concepts/services-networking/service/#loadbalancer)
 is typically used for this, although other options
 (e.g. [External IP's](/docs/concepts/services-networking/service/#external-ips)) exist.
 
diff --git a/content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md b/content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md
index 3b9be17f39..abf9388aed 100644
--- a/content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md
+++ b/content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md
@@ -279,11 +279,11 @@ kubefed init fellowship \
 `kubefed init` exposes the federation API server as a Kubernetes
 [service](/docs/concepts/services-networking/service/) on the host cluster. By default,
 this service is exposed as a
-[load balanced service](/docs/concepts/services-networking/service/#type-loadbalancer).
+[load balanced service](/docs/concepts/services-networking/service/#loadbalancer).
 Most on-premises and bare-metal environments, and some cloud
 environments lack support for load balanced services. `kubefed init`
 allows exposing the federation API server as a
-[`NodePort` service](/docs/concepts/services-networking/service/#type-nodeport) on
+[`NodePort` service](/docs/concepts/services-networking/service/#nodeport) on
 such environments. This can be accomplished by passing
 the `--api-server-service-type=NodePort` flag. You can also specify
 the preferred address to advertise the federation API server by
diff --git a/content/en/docs/tutorials/services/source-ip.md b/content/en/docs/tutorials/services/source-ip.md
index 01cc9d5dba..b436fd617d 100644
--- a/content/en/docs/tutorials/services/source-ip.md
+++ b/content/en/docs/tutorials/services/source-ip.md
@@ -111,7 +111,7 @@ If the client pod and server pod are in the same node, the client_address is the
 
 ## Source IP for Services with Type=NodePort
 
-As of Kubernetes 1.5, packets sent to Services with [Type=NodePort](/docs/concepts/services-networking/service/#type-nodeport)
+As of Kubernetes 1.5, packets sent to Services with [Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
 are source NAT'd by default. You can test this by creating a `NodePort` Service:
 
 ```console
@@ -209,7 +209,7 @@ Visually:
 
 ## Source IP for Services with Type=LoadBalancer
 
-As of Kubernetes 1.5, packets sent to Services with [Type=LoadBalancer](/docs/concepts/services-networking/service/#type-loadbalancer) are
+As of Kubernetes 1.5, packets sent to Services with [Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) are
 source NAT'd by default, because all schedulable Kubernetes nodes in the
 `Ready` state are eligible for loadbalanced traffic. So if packets arrive
 at a node without an endpoint, the system proxies it to a node *with* an