[ko] Update links

2021-06-24 14:06:02 +09:00
parent dbda7491c2
commit 2d0363fdaa
42 changed files with 79 additions and 80 deletions
@@ -167,4 +167,3 @@ IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API
 * 만약 자신만의 컨트롤러를 작성하기 원한다면, 
  쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/#익스텐션-패턴)을 
  본다.
-  
@@ -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) 알아보기
@@ -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/)을
+사용하여 접근을 제한해야 한다.

 시크릿은 종종 다양한 중요도에 걸친 값을 보유하며, 이 중 많은 부분이
 쿠버네티스(예: 서비스 어카운트 토큰)와 외부 시스템으로 단계적으로
@@ -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)
@@ -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는 커스텀 리소스의 스토리지를 제공하고 처리한다.
@@ -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-버전-규칙)를 참조한다.



@@ -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` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다.
@@ -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/)
@@ -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,7 +142,7 @@ metadata:
 value: 1000000
 preemptionPolicy: Never
 globalDefault: false
-description: "이 프라이어리티 클래스는 다른 파드를 축출하지 않는다."
+description: "이 프라이어리티클래스는 다른 파드를 축출하지 않는다."
 ```

 ## 파드 우선순위
@@ -150,7 +150,7 @@ 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/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.
@@ -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/)에 대해 알아보기
@@ -149,7 +149,7 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리
 * [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/)
 * [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access)
 * [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)
-* 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/)
+* 컨트롤 플레인을 위한 [전송 데이터 암호화](/ko/docs/tasks/tls/managing-tls-in-a-cluster/)
 * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/)
 * [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
 * [런타임 클래스](/ko/docs/concepts/containers/runtime-class)
@@ -154,7 +154,7 @@ v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`

 ### 관리

-대부분의 경우, 컨트롤 플레인(특히, 엔드포인트 슬라이스
+대부분의 경우, 컨트롤 플레인(특히, 엔드포인트슬라이스
 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}})는
 엔드포인트슬라이스 오브젝트를 생성하고 관리한다. 다른 엔티티나 컨트롤러가 추가
 엔드포인트슬라이스 집합을 관리하게 할 수 있는 서비스 메시 구현과 같이
@@ -165,13 +165,13 @@ v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`
 엔티티를 나타내는 `endpointslice.kubernetes.io/managed-by`
 {{< glossary_tooltip term_id="label" text="레이블" >}}을
 정의한다.
-엔드포인트 슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로
+엔드포인트슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로
 `endpointslice-controller.k8s.io` 를 설정한다. 엔드포인트슬라이스를
 관리하는 다른 엔티티도 이 레이블에 고유한 값을 설정해야 한다.

 ### 소유권

-대부분의 유스케이스에서, 엔드포인트 슬라이스 오브젝트가 엔드포인트를
+대부분의 유스케이스에서, 엔드포인트슬라이스 오브젝트가 엔드포인트를
 추적하는 서비스가 엔드포인트슬라이스를 소유한다. 이 소유권은 각 엔드포인트슬라이스의 소유자
 참조와 서비스에 속한 모든 엔드포인트슬라이스의 간단한 조회를 가능하게 하는
 `kubernetes.io/service-name` 레이블로 표시된다.
@@ -247,4 +247,4 @@ v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`

 ## {{% heading "whatsnext" %}}

-* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
+* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
@@ -21,7 +21,7 @@ _서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이
 ## 서비스 내부 트래픽 정책 사용


-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)에서 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서 
 `ServiceInternalTrafficPolicy`를 활성화한 후에 
 {{< glossary_tooltip text="서비스" term_id="service" >}}의 
 `.spec.internalTrafficPolicy`를 `Local`로 설정하여 내부 전용 트래픽 정책을 활성화 할 수 있다.
@@ -57,7 +57,7 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
 엔드포인트를 필터링한다. 
 이것을 `Local`로 설정하면, 노드 내부 엔드포인트만 고려한다. 
 이 설정이 `Cluster`이거나 누락되었다면 모든 엔드포인트를 고려한다.
-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의 
 `ServiceInternalTrafficPolicy`를 활성화한다면, `spec.internalTrafficPolicy`는 기본값 "Cluster"로 설정된다.

 ## 제약조건
@@ -914,7 +914,7 @@ projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마

 ### quobyte

-`quobyte` 볼륨을 사용하면 기존 [Quobyte](http://www.quobyte.com) 볼륨을
+`quobyte` 볼륨을 사용하면 기존 [Quobyte](https://www.quobyte.com) 볼륨을
 파드에 마운트할 수 있다.

 {{< note >}}
@@ -31,7 +31,7 @@ weight: 60
 - 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애
 - 커널 패닉
 - 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐
- 노드의 [리소스 부족](/docs/tasks/administer-cluster/out-of-resource/)으로 파드가 축출됨
+- 노드의 [리소스 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨

 리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
 왜냐하면
@@ -76,7 +76,7 @@ weight: 60
 - 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체
  ([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용)
  또는 영역 간
-  ([다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다면)에
+  ([다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다면)에
  애플리케이션을 분산해야 한다.

 자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자동화된 자발적 중단은 발생하지 않는다(사용자가 지시한 자발적 중단만 발생한다).