Fix a broken anchor (kubernetes#12215)

The title of this section has been changed so since the anchor is
automatically computed, links were broken.

Stems from da9722a.

Author: robin850

content/en/docs/reference/kubectl/overview.md

@@ -49,7 +49,7 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
 
    * To specify resources with one or more files:  `-f file1 -f file2 -f file<#>`
 
-      * [Use YAML rather than JSON](/docs/concepts/configuration/overview/#general-config-tips) since YAML tends to be more user-friendly, especially for configuration files.<br/>
+      * [Use YAML rather than JSON](/docs/concepts/configuration/overview/#general-configuration-tips) since YAML tends to be more user-friendly, especially for configuration files.<br/>
      Example: `$ kubectl get pod -f ./pod.yaml`
 
 * `flags`: Specifies optional flags. For example, you can use the `-s` or `--server` flags to specify the address and port of the Kubernetes API server.<br/>

content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html

@@ -29,8 +29,8 @@ <h3>Objectives</h3>
 			<h3>Overview of Kubernetes Services</h3>
 
 			<p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>
-			
-			<p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-config-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>
+
+			<p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>
 
 			<p>Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p>
 			<ul>

content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html

@@ -30,7 +30,7 @@ <h3>쿠버네티스 서비스들에 대한 개요</h3>
 
 			<p>쿠버네티스 <a href="/docs/concepts/workloads/pods/pod-overview/">파드들</a> 은 언젠가는 죽게된다. 실제 파드들은  <a href="/docs/concepts/workloads/pods/pod-lifecycle/">생명주기</a>를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. <a href="/docs/user-guide/replication-controller/#what-is-a-replicationcontroller">레플리케이션 컨트롤러</a>는 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 대체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.</p>
 
-			<p>쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML <a href="/docs/concepts/configuration/overview/#general-config-tips">(보다 선호하는)</a> 또는 JSON을 이용하여 정의된다. 서비스가 대상으로 하는 파드 셋은 보통 <i>LabelSelector</i>에 의해 결정된다 (여러분이 왜 스펙에 <code>selector</code>가 포함되지 않은 서비스를 필요로 하게 될 수도 있는지에 대해 아래에서 확인해 보자).</p>
+			<p>쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(보다 선호하는)</a> 또는 JSON을 이용하여 정의된다. 서비스가 대상으로 하는 파드 셋은 보통 <i>LabelSelector</i>에 의해 결정된다 (여러분이 왜 스펙에 <code>selector</code>가 포함되지 않은 서비스를 필요로 하게 될 수도 있는지에 대해 아래에서 확인해 보자).</p>
 
 			<p>비록 각 파드들이 고유의 IP를 갖고 있기는 하지만, 그 IP들은 서비스의 도움없이 클러스터 외부로 노출되어질 수 없다. 서비스들은 여러분의 애플리케이션들에게 트래픽이 실릴 수 있도록 허용해준다. 서비스들은 ServiceSpec에서 <code>type</code>을 지정함으로써 다양한 방식들로 노출시킬 수 있다:</p>
 			<ul>

content/zh/docs/user-guide/kubectl-overview.md

@@ -35,7 +35,7 @@ kubectl [command] [TYPE] [NAME] [flags]
         * 要分别指定多种资源类型:  `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`.<br/>
         例: `$ kubectl get pod/example-pod1 replicationcontroller/example-rc1`
 
-     使用一个或多个文件指定资源： `-f file1 -f file2 -f file<#>` 使用[YAML而不是JSON](/docs/concepts/configuration/overview/#general-config-tips)，因为YAML往往更加用户友好，特别是对于配置文件。<br/>
+     使用一个或多个文件指定资源： `-f file1 -f file2 -f file<#>` 使用[YAML而不是JSON](/docs/concepts/configuration/overview/#general-configuration-tips)，因为YAML往往更加用户友好，特别是对于配置文件。<br/>
      例：$ kubectl get pod -f ./pod.yaml
 
 * flags：指定可选标志。例如，您可以使用`-s`或`--serverflags`来指定Kubernetes API服务器的地址和端口。