Fix additional broken links

content/ko/docs/concepts/containers/runtime-class.md

@@ -97,7 +97,7 @@ spec:
 
 이것은 Kubelet이 지명된 런타임클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다.
 만약 지명된 런타임클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는
-`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)로 들어간다.
+`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase)로 들어간다.
 에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를
 확인한다.
 

content/ko/docs/concepts/overview/working-with-objects/field-selectors.md

@@ -9,7 +9,7 @@ _필드 셀렉터_ 는 한 개 이상의 리소스 필드 값에 따라 [쿠버
 * `metadata.namespace!=default`
 * `status.phase=Pending`
 
-다음의 `kubectl` 커맨드는 [`status.phase`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) 필드의 값이 `Running` 인 모든 파드를 선택한다.
+다음의 `kubectl` 커맨드는 [`status.phase`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 필드의 값이 `Running` 인 모든 파드를 선택한다.
 
 ```shell
 kubectl get pods --field-selector status.phase=Running

content/ko/docs/concepts/services-networking/service.md

@@ -272,7 +272,7 @@ kube-proxy가 iptables 모드에서 실행 중이고 선택된 첫 번째 파드
 다르다. 해당 시나리오에서는, kube-proxy는 첫 번째
 파드에 대한 연결이 실패했음을 감지하고 다른 백엔드 파드로 자동으로 재시도한다.
 
-파드 [준비성 프로브(readiness probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 사용하여
+파드 [준비성 프로브(readiness probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 사용하여
 백엔드 파드가 제대로 작동하는지 확인할 수 있으므로, iptables 모드의 kube-proxy는
 정상으로 테스트된 백엔드만 볼 수 있다. 이렇게 하면 트래픽이 kube-proxy를 통해
 실패한 것으로 알려진 파드로 전송되는 것을 막을 수 있다.

content/ko/docs/concepts/storage/storage-classes.md

@@ -34,9 +34,9 @@ weight: 30
 처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하며,
 일단 생성된 오브젝트는 업데이트할 수 없다.
 
-관리자는 특정 클래스에 바인딩을 요청하지 않는 PVC에 대해서만 기본 
+관리자는 특정 클래스에 바인딩을 요청하지 않는 PVC에 대해서만 기본
 스토리지클래스를 지정할 수 있다. 자세한 내용은
-[퍼시스턴트볼륨클레임 섹션](/ko/docs/concepts/storage/persistent-volumes/#클래스-1)을
+[퍼시스턴트볼륨클레임 섹션](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)을
 본다.
 
 ```yaml
@@ -251,11 +251,11 @@ parameters:
 * `iopsPerGB`: `io1` 볼륨 전용이다. 1초당 GiB에 대한 I/O 작업 수이다. AWS
   볼륨 플러그인은 요청된 볼륨 크기에 곱셈하여 볼륨의 IOPS를
   계산하고 이를 20,000 IOPS로 제한한다(AWS에서 지원하는 최대값으로,
-  [AWS 문서](https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-volume-types.html)를 본다). 
+  [AWS 문서](https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-volume-types.html)를 본다).
   여기에는 문자열, 즉 `10` 이 아닌, `"10"` 이 필요하다.
 * `fsType`: fsType은 쿠버네티스에서 지원된다. 기본값: `"ext4"`.
 * `encrypted`: EBS 볼륨의 암호화 여부를 나타낸다.
-  유효한 값은 `"ture"` 또는 `"false"` 이다. 여기에는 문자열, 
+  유효한 값은 `"ture"` 또는 `"false"` 이다. 여기에는 문자열,
   즉 `true` 가 아닌, `"true"` 가 필요하다.
 * `kmsKeyId`: 선택 사항. 볼륨을 암호화할 때 사용할 키의 전체 Amazon
   리소스 이름이다. 아무것도 제공되지 않지만, `encrypted` 가 true라면
@@ -348,7 +348,7 @@ parameters:
 * `secretNamespace`, `secretName` : Gluster REST 서비스와 통신할 때 사용할
   사용자 암호가 포함된 시크릿 인스턴스를 식별한다. 이 파라미터는
   선택 사항으로 `secretNamespace` 와 `secretName` 을 모두 생략하면
-  빈 암호가 사용된다. 제공된 시크릿은 `"kubernetes.io/glusterfs"` 유형이어야 
+  빈 암호가 사용된다. 제공된 시크릿은 `"kubernetes.io/glusterfs"` 유형이어야
   하며, 예를 들어 다음과 같이 생성한다.
 
     ```
@@ -664,7 +664,7 @@ parameters:
 [RBAC](/docs/reference/access-authn-authz/rbac/)과
 [컨트롤러의 롤(role)들](/docs/reference/access-authn-authz/rbac/#controller-roles)을
 모두 활성화한 경우, clusterrole `system:controller:persistent-volume-binder`
-에 대한 `secret` 리소스에 `create` 권한을 추가한다. 
+에 대한 `secret` 리소스에 `create` 권한을 추가한다.
 
 다중 테넌시 컨텍스트에서 `secretNamespace` 의 값을 명시적으로 설정하는
 것을 권장하며, 그렇지 않으면 다른 사용자가 스토리지 계정 자격증명을
@@ -688,16 +688,16 @@ parameters:
 * `fs`: 배치할 파일 시스템: `none/xfs/ext4` (기본값: `ext4`)
 * `block_size`: Kbytes 단위의 블록 크기(기본값: `32`).
 * `repl`: 레플리케이션 팩터 `1..3` (기본값: `1`)의 형태로 제공될
-  동기 레플리카의 수. 여기에는 문자열, 
+  동기 레플리카의 수. 여기에는 문자열,
   즉 `0` 이 아닌, `"0"` 이 필요하다.
 * `io_priority`: 볼륨이 고성능 또는 우선 순위가 낮은 스토리지에서
   생성될 것인지를 결정한다 `high/medium/low` (기본값: `low`).
 * `snap_interval`: 스냅샷을 트리거할 때의 시각/시간 간격(분).
   스냅샷은 이전 스냅샷과의 차이에 따라 증분되며, 0은 스냅을
-  비활성화 한다(기본값: `0`). 여기에는 문자열, 
+  비활성화 한다(기본값: `0`). 여기에는 문자열,
   즉 `70` 이 아닌, `"70"` 이 필요하다.
 * `aggregation_level`: 볼륨이 분배될 청크 수를 지정하며, 0은 집계되지 않은
-  볼륨을 나타낸다(기본값: `0`). 여기에는 문자열, 
+  볼륨을 나타낸다(기본값: `0`). 여기에는 문자열,
   즉 `0` 이 아닌, `"0"` 이 필요하다.
 * `ephemeral`: 마운트 해제 후 볼륨을 정리해야 하는지 혹은 지속적이어야
   하는지를 지정한다. `emptyDir` 에 대한 유스케이스는 이 값을 true로
@@ -815,4 +815,3 @@ volumeBindingMode: WaitForFirstConsumer
 볼륨 바인딩을 지연시키면 스케줄러가 퍼시스턴트볼륨클레임에
 적절한 퍼시스턴트볼륨을 선택할 때 파드의 모든 스케줄링
 제약 조건을 고려할 수 있다.
-

content/ko/docs/concepts/workloads/controllers/daemonset.md

@@ -54,7 +54,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 
 `.spec.template` 는 `.spec` 의 필수 필드 중 하나이다.
 
-`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다.
+`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다.
 
 데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야
 한다([파드 셀렉터](#파드-셀렉터)를 본다).

content/ko/docs/concepts/workloads/controllers/replicaset.md

@@ -233,7 +233,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
 우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다.
 이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.
 
-템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 필드인
+템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 필드인
 `.spec.template.spec.restartPolicy`는 기본값인 `Always`만 허용된다.
 
 ### 파드 셀렉터

content/ko/docs/concepts/workloads/controllers/replicationcontroller.md

@@ -123,7 +123,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 
 `.spec.template` 는 오직 `.spec` 필드에서 요구되는 것이다.
 
-`.spec.template` 는 [파드 개요](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다.
+`.spec.template` 는 [파드 개요](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다.
 
 파드에 필요한 필드 외에도 레플리케이션 컨트롤러의 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 지정해야 한다. 레이블의 경우 다른 컨트롤러와
 중첩되지 않도록 하라. [파드 셀렉터](#파드-셀렉터)를 참조하라.

content/ko/docs/reference/kubectl/cheatsheet.md

@@ -310,7 +310,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
 
 ### 리소스 타입
 
-단축명, [API 그룹](/ko/docs/concepts/overview/kubernetes-api/#api-groups)과 함께 지원되는 모든 리소스 유형들, 그것들의 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces)와 [종류(Kind)](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects)를 나열:
+단축명, [API 그룹](/ko/docs/concepts/overview/kubernetes-api/#api-그룹)과 함께 지원되는 모든 리소스 유형들, 그것들의 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces)와 [종류(Kind)](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects)를 나열:
 
 ```bash
 kubectl api-resources
@@ -385,5 +385,3 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그
 * 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/docs/reference/kubectl/conventions/)을 참고한다.
 
 * 더 많은 [kubectl 치트 시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4) 커뮤니티 확인
-
-

content/ko/docs/tasks/administer-cluster/change-default-storage-class.md

@@ -4,7 +4,7 @@ content_type: task
 ---
 
 <!-- overview -->
-이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝 
+이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝
 하는데 사용되는 기본 스토리지 클래스를 변경하는 방법을 보여준다.
 
 
@@ -20,21 +20,21 @@ content_type: task
 
 ## 왜 기본 스토리지 클래스를 변경하는가?
 
-설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존 
-스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정 
-스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를 
+설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존
+스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정
+스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를
 동적으로 프로비저닝 하기 위해 사용된다.
-더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#class-1)를
+더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)를
 보자.
 
-미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지 
-않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할 
-수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화 
+미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지
+않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할
+수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화
 하여 스토리지의 동적 프로비저닝을 방지할 수 있다.
 
-단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인 
-애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자 
-및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자. 
+단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인
+애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자
+및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자.
 
 ## 기본 스토리지클래스 변경하기
 
@@ -56,7 +56,7 @@ content_type: task
 
 1. 기본 스토리지클래스를 기본값이 아닌 것으로 표시한다.
 
-      기본 스토리지클래스에는 
+      기본 스토리지클래스에는
       `storageclass.kubernetes.io/is-default-class` 의 값이 `true` 로 설정되어 있다.
       다른 값이거나 어노테이션이 없을 경우 `false` 로 처리된다.
 

content/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md

@@ -117,6 +117,5 @@ weight: 120
 
 ## {{% heading "whatsnext" %}}
 
-[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)에
+[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)에
 대해 더 알아보기.
-