Merge pull request #28593 from jihoon-seo/210624_Update_links_in_ko

[ko] Update links

Author: k8s-ci-robot

content/ko/docs/concepts/architecture/controller.md

@@ -167,4 +167,3 @@ IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API 
 * 만약 자신만의 컨트롤러를 작성하기 원한다면, 
   쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/#익스텐션-패턴)을 
   본다.
-  

content/ko/docs/concepts/cluster-administration/system-logs.md

@@ -20,7 +20,7 @@ weight: 60
 klog는 쿠버네티스의 로깅 라이브러리다. [klog](https://github.com/kubernetes/klog)
 는 쿠버네티스 시스템 컴포넌트의 로그 메시지를 생성한다.
 
-klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/docs/reference/command-line-tools-reference/)을 참고한다.
+klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.
 
 klog 네이티브 형식 예 : 
 ```
@@ -61,7 +61,7 @@ I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod=
 
 {{<warning >}}
 
-JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/docs/reference/command-line-tools-reference/)을 참고한다.
+JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.
 
 모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우
 JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다.
@@ -143,6 +143,6 @@ systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은
 
 ## {{% heading "whatsnext" %}}
 
-* [쿠버네티스 로깅 아키텍처](/docs/concepts/cluster-administration/logging/) 알아보기
+* [쿠버네티스 로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/) 알아보기
 * [구조화된 로깅](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) 알아보기
 * [로깅 심각도(serverity) 규칙](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 알아보기

content/ko/docs/concepts/configuration/secret.md

@@ -31,7 +31,7 @@ weight: 30
 시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
 
 1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
-2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
+2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
 {{< /caution >}}
 
 <!-- body -->
@@ -48,7 +48,7 @@ weight: 30
 - 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
 
 시크릿 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를
 명시할 수 있다. 해당 `data` 와 `stringData` 필드는 선택적으로 명시할 수 있다.
 `data` 필드의 모든 키(key)에 해당하는 값(value)은 base64로 인코딩된 문자열이어야 한다.
@@ -1156,10 +1156,10 @@ HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음,
 
 ### 시크릿 API를 사용하는 클라이언트
 
-시크릿 API와 상호 작용하는 애플리케이션을 배포할 때, [RBAC](
-/docs/reference/access-authn-authz/rbac/)과 같은 [인가 정책](
-/docs/reference/access-authn-authz/authorization/)을
-사용하여 접근를 제한해야 한다.
+시크릿 API와 상호 작용하는 애플리케이션을 배포할 때, 
+[RBAC](/docs/reference/access-authn-authz/rbac/)과 같은 
+[인가 정책](/ko/docs/reference/access-authn-authz/authorization/)을
+사용하여 접근을 제한해야 한다.
 
 시크릿은 종종 다양한 중요도에 걸친 값을 보유하며, 이 중 많은 부분이
 쿠버네티스(예: 서비스 어카운트 토큰)와 외부 시스템으로 단계적으로

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

@@ -175,5 +175,5 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/ko/docs/referenc
 
 - [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
 - [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
-- [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기
+- [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 개념에 대해 읽기
 - [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)

content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md

@@ -128,7 +128,7 @@ CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입
 
 ## 커스텀리소스데피니션
 
-[커스텀리소스데피니션](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
+[커스텀리소스데피니션](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
 API 리소스를 사용하면 커스텀 리소스를 정의할 수 있다.
 CRD 오브젝트를 정의하면 지정한 이름과 스키마를 사용하여 새 커스텀 리소스가 만들어진다.
 쿠버네티스 API는 커스텀 리소스의 스토리지를 제공하고 처리한다.

content/ko/docs/concepts/overview/kubernetes-api.md

@@ -20,14 +20,14 @@ card:
 쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예:
 파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다.
 
-대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/)
+대부분의 작업은 [kubectl](/ko/docs/reference/kubectl/overview/)
 커맨드 라인 인터페이스 또는 API를 사용하는
 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/)과
 같은 다른 커맨드 라인 도구를 통해 수행할 수 있다.
 그러나, REST 호출을 사용하여 API에 직접 접근할 수도 있다.
 
 쿠버네티스 API를 사용하여 애플리케이션을 작성하는 경우
-[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이 좋다.
+[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이 좋다.
 
 <!-- body -->
 
@@ -130,7 +130,7 @@ API 리소스는 API 그룹, 리소스 유형, 네임스페이스
 {{< /note >}}
 
 API 버전 수준 정의에 대한 자세한 내용은
-[API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다.
+[API 버전 레퍼런스](/ko/docs/reference/using-api/#api-버전-규칙)를 참조한다.
 
 
 

content/ko/docs/concepts/policy/resource-quotas.md

@@ -197,7 +197,7 @@ CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스
 | `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 |
 | `BestEffort` | 최상의 서비스 품질을 제공하는 파드 |
 | `NotBestEffort` | 서비스 품질이 나쁜 파드 |
-| `PriorityClass` | 지정된 [프라이어리티 클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption)를 참조하여 일치하는 파드. |
+| `PriorityClass` | 지정된 [프라이어리티클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를 참조하여 일치하는 파드. |
 | `CrossNamespacePodAffinity` | 크로스-네임스페이스 파드 [(안티)어피니티 용어]가 있는 파드 |
 
 `BestEffort` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다.

content/ko/docs/concepts/scheduling-eviction/_index.md

@@ -32,6 +32,6 @@ no_list: true
 
 {{<glossary_definition term_id="pod-disruption" length="all">}}
 
-* [파드 우선순위와 선점](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
+* [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)
 * [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
-* [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)
+* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)

content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md

@@ -25,7 +25,7 @@ weight: 70
 관리자는 리소스쿼터를 사용하여 사용자가 우선순위가 높은 파드를 생성하지
 못하게 할 수 있다.
 
-자세한 내용은 [기본적으로 프라이어리티 클래스(Priority Class) 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을
+자세한 내용은 [기본적으로 프라이어리티클래스(Priority Class) 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을
 참고한다.
 {{< /warning >}}
 
@@ -50,7 +50,7 @@ weight: 70
 
 ## 프라이어리티클래스
 
-프라이어리티클래스는 프라이어리티 클래스 이름에서 우선순위의 정수 값으로의 매핑을
+프라이어리티클래스는 프라이어리티클래스 이름에서 우선순위의 정수 값으로의 매핑을
 정의하는 네임스페이스가 아닌(non-namespaced) 오브젝트이다. 이름은
 프라이어리티클래스 오브젝트의 메타데이터의 `name` 필드에 지정된다. 값은
 필수 `value` 필드에 지정되어 있다. 값이 클수록, 우선순위가
@@ -96,7 +96,7 @@ metadata:
   name: high-priority
 value: 1000000
 globalDefault: false
-description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사용해야 한다."
+description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사용해야 한다."
 ```
 
 ## 비-선점 프라이어리티클래스 {#non-preempting-priority-class}
@@ -142,15 +142,15 @@ metadata:
 value: 1000000
 preemptionPolicy: Never
 globalDefault: false
-description: "이 프라이어리티 클래스는 다른 파드를 축출하지 않는다."
+description: "이 프라이어리티클래스는 다른 파드를 축출하지 않는다."
 ```
 
 ## 파드 우선순위
 
 프라이어리티클래스가 하나 이상 있으면, 그것의 명세에서 이들 프라이어리티클래스 이름 중 하나를
 지정하는 파드를 생성할 수 있다. 우선순위 어드미션
 컨트롤러는 `priorityClassName` 필드를 사용하고 우선순위의 정수 값을
-채운다. 프라이어리티 클래스를 찾을 수 없으면, 파드가 거부된다.
+채운다. 프라이어리티클래스를 찾을 수 없으면, 파드가 거부된다.
 
 다음의 YAML은 이전 예제에서 생성된 프라이어리티클래스를
 사용하는 파드 구성의 예이다. 우선순위 어드미션 컨트롤러는
@@ -351,12 +351,12 @@ spec:
 축출 대상으로 고려한다.
 
 QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는
-[kubelet 리소스 부족 축출](/docs/tasks/administer-cluster/out-of-resource/)이다.
+[kubelet 리소스 부족 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)이다.
 kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라,
 파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해
 먼저 축출 대상 파드의 순위를 매긴다.
 더 자세한 내용은
-[엔드유저 파드 축출](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)을
+[엔드유저 파드 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/#evicting-end-user-pods)을
 참조한다.
 
 kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우
@@ -367,4 +367,4 @@ kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 
 
 ## {{% heading "whatsnext" %}}
 
-* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.
+* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.

content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -281,5 +281,5 @@ tolerations:
 
 ## {{% heading "whatsnext" %}}
 
-* [리소스 부족 다루기](/docs/tasks/administer-cluster/out-of-resource/)와 어떻게 구성하는지에 대해 알아보기
-* [파드 우선순위](/ko/docs/concepts/configuration/pod-priority-preemption/)에 대해 알아보기
+* [리소스 부족 다루기](/docs/concepts/scheduling-eviction/node-pressure-eviction/)와 어떻게 구성하는지에 대해 알아보기
+* [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아보기