Merge pull request #22155 from pjhwa/fix-21731

Fix incorrect notation of 'directory' into Korean

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

@@ -51,13 +51,13 @@ weight: 50
 * 경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트
 
 * 책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은
-  해당 정보를 찾을 수 있는 디렉토리 진입점.
+  해당 정보를 찾을 수 있는 디렉터리 진입점.
 
 * 행동을 수정하거나 비표준 기능을 수행하기 위한
   최종 사용자의 지시 사항.
 
 어노테이션을 사용하는 대신, 이 유형의 정보를
-외부 데이터베이스 또는 디렉토리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한
+외부 데이터베이스 또는 디렉터리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한
 공유 클라이언트 라이브러리와 도구 생성을
 훨씬 더 어렵게 만들 수 있다.
 

content/ko/docs/concepts/overview/working-with-objects/object-management.md

@@ -118,16 +118,16 @@ kubectl replace -f nginx.yaml
 
 선언형 오브젝트 구성에 비해 단점은 다음과 같다.
 
-- 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다.
+- 명령형 오브젝트 구성은 디렉터리가 아닌, 파일에 대해 가장 효과가 있다.
 - 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다.
 
 ## 선언형 오브젝트 구성
 
 선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트
 구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할
 작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은
-`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해
-다른 조작이 필요할 수 있는 디렉토리에서 작업할 수 있다.
+`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 
+다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다.
 
 {{< note >}}
 선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에
@@ -139,7 +139,7 @@ kubectl replace -f nginx.yaml
 
 ### 예시
 
-`configs` 디렉토리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를
+`configs` 디렉터리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를
 생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 `diff`
 하고 나서 적용할 수 있다.
 
@@ -148,7 +148,7 @@ kubectl diff -f configs/
 kubectl apply -f configs/
 ```
 
-재귀적으로 디렉토리를 처리한다.
+재귀적으로 디렉터리를 처리한다.
 
 ```sh
 kubectl diff -R -f configs/
@@ -160,7 +160,7 @@ kubectl apply -R -f configs/
 명령형 오브젝트 구성에 비해 장점은 다음과 같다.
 
 - 활성 오브젝트에 직접 작성된 변경 사항은 구성 파일로 다시 병합되지 않더라도 유지된다.
-- 선언형 오브젝트 구성은 디렉토리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다.
+- 선언형 오브젝트 구성은 디렉터리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다.
 
 명령형 오브젝트 구성에 비해 단점은 다음과 같다.
 

content/ko/docs/concepts/policy/pod-security-policy.md

@@ -455,7 +455,7 @@ allowedHostPaths:
 (다른 컨테이너들에 있는 데이터를 읽고, 시스템 서비스의 자격 증명을 어뷰징(abusing)하는 등)할
 수 있도록 만드는 다양한 방법이 있다. 예를 들면, Kubelet과 같다.
 
-쓰기 가능한 hostPath 디렉토리 볼륨을 사용하면, 컨테이너가 `pathPrefix` 외부의
+쓰기 가능한 hostPath 디렉터리 볼륨을 사용하면, 컨테이너가 `pathPrefix` 외부의
 호스트 파일시스템에 대한 통행을 허용하는 방식으로 컨테이너의 파일시스템 쓰기(write)를 허용한다.
 쿠버네티스 1.11 이상 버전에서 사용 가능한 `readOnly: true`는 지정된 `pathPrefix`에 대한
 접근을 효과적으로 제한하기 위해 **모든** `allowedHostPaths`에서 사용해야 한다.

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

@@ -206,7 +206,7 @@ nodeAffinity:
 
 ### 스태틱(static) 파드
 
-Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를 생성할 수 있다. 이것을
+Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를 생성할 수 있다. 이것을
 [스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 부른다.
 데몬셋과는 다르게 스태틱 파드는 kubectl
 또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다.  스태틱 파드는 API 서버에 의존하지

content/ko/docs/contribute/style/write-new-topic.md

@@ -55,30 +55,30 @@ YAML 블록이다. 여기 예시가 있다.
     title: HTTP 프록시를 사용하여 쿠버네티스 API에 접근
     ---
 
-## 디렉토리 선택
+## 디렉터리 선택
 
-페이지 타입에 따라 새로운 파일을 다음 중 하나의 하위 디렉토리에 넣자.
+페이지 타입에 따라 새로운 파일을 다음 중 하나의 하위 디렉터리에 넣자.
 
 * /content/en/docs/tasks/
 * /content/en/docs/tutorials/
 * /content/en/docs/concepts/
 
-파일을 기존 하위 디렉토리에 넣거나 새 하위 디렉토리에
+파일을 기존 하위 디렉터리에 넣거나 새 하위 디렉터리에
 넣을 수 있다.
 
 ## 목차에 항목 배치
 
-목차는 문서 소스의 디렉토리 구조를 사용하여
-동적으로 작성된다. `/content/en/docs/` 아래의 최상위 디렉토리는 최상위 레벨 탐색 기능을
-생성하고, 하위 디렉토리는 각각 목차에 항목을
+목차는 문서 소스의 디렉터리 구조를 사용하여
+동적으로 작성된다. `/content/en/docs/` 아래의 최상위 디렉터리는 최상위 레벨 탐색 기능을
+생성하고, 하위 디렉터리는 각각 목차에 항목을
 갖는다.
 
-각 하위 디렉토리에는 `_index.md` 파일이 있으며 이는 해당 하위 디렉토리의 컨텐츠에 대한
+각 하위 디렉터리에는 `_index.md` 파일이 있으며 이는 해당 하위 디렉터리의 컨텐츠에 대한
 "홈" 페이지를 나타낸다. `_index.md`에는 템플릿이 필요없다. 그것은
-하위 디렉토리의 항목에 대한 개요 내용을 포함할 수 있다.
+하위 디렉터리의 항목에 대한 개요 내용을 포함할 수 있다.
 
-디렉토리의 다른 파일들은 기본적으로 알파벳순으로 정렬된다. 이것은 거의
-최적의 순서가 아니다. 하위 디렉토리에서 항목의 상대적 정렬을 제어하려면
+디렉터리의 다른 파일들은 기본적으로 알파벳순으로 정렬된다. 이것은 거의
+최적의 순서가 아니다. 하위 디렉터리에서 항목의 상대적 정렬을 제어하려면
 `가중치:` 전문의 키를 정수로 설정하자. 일반적으로 우리는
 나중에 항목을 추가하기 위해 10의 배수를 사용한다. 예를 들어 가중치가
 `10`인 항목은 가중치가 `20`인 항목보다 우선한다.
@@ -112,13 +112,13 @@ YAML 블록이다. 여기 예시가 있다.
 샘플 YAML 파일을 포함시키려면 이 방법을 사용하자.
 
 YAML 파일과 같은 새로운 독립형 샘플 파일을 추가할 때
-`<LANG>/examples/` 의 하위 디렉토리 중 하나에 코드를 배치하자. 여기서 `<LANG>`은
+`<LANG>/examples/` 의 하위 디렉터리 중 하나에 코드를 배치하자. 여기서 `<LANG>`은
 주제에 관한 언어이다. 문서 파일에서 `codenew` 단축 코드(shortcode)를 사용하자.
 
 ```none
 {{</* codenew file="<RELPATH>/my-example-yaml>" */>}}
 ```
-여기서 `<RELPATH>` 는 `examples` 디렉토리와 관련하여 포함될
+여기서 `<RELPATH>` 는 `examples` 디렉터리와 관련하여 포함될
 파일의 경로이다. 다음 Hugo 단축 코드(shortcode)는 `/content/en/examples/pods/storage/gce-volume.yaml`
 에 있는 YAML 파일을 참조한다.
 
@@ -135,7 +135,7 @@ YAML 파일과 같은 새로운 독립형 샘플 파일을 추가할 때
 ## 구성 파일에서 API 오브젝트를 작성하는 방법 표시
 
 구성 파일을 기반으로 API 오브젝트를 생성하는 방법을 보여주려면
-`<LANG>/examples` 아래의 하위 디렉토리 중 하나에
+`<LANG>/examples` 아래의 하위 디렉터리 중 하나에
 구성 파일을 배치하자.
 
 문서에서 이 명령을 띄워보자.
@@ -145,7 +145,7 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml
 ```
 
 {{< note >}}
-`<LANG>/examples` 디렉토리에 새 YAMl 파일을 추가할 때 파일이
+`<LANG>/examples` 디렉터리에 새 YAMl 파일을 추가할 때 파일이
 `<LANG>/examples_test.go` 파일에도 포함되어 있는지 확인하자.
 웹 사이트의 Travis CI 는 PR이 제출될 때 이 예제를 자동으로
 실행하여 모든 예제가 테스트를 통과하도록 한다.
@@ -156,7 +156,7 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml
 
 ## 문서에 이미지 추가
 
-이미지 파일을 `/images` 디렉토리에 넣는다. 기본
+이미지 파일을 `/images` 디렉터리에 넣는다. 기본
 이미지 형식은 SVG 이다.
 
 

content/ko/docs/reference/glossary/volume.md

@@ -4,14 +4,14 @@ id: volume
 date: 2018-04-12
 full_link: /ko/docs/concepts/storage/volumes/
 short_description: >
-  데이터를 포함하고 있는 디렉토리이며, 파드의 컨테이너에서 접근 가능하다.
+  데이터를 포함하고 있는 디렉터리이며, 파드의 컨테이너에서 접근 가능하다.
 
 aka: 
 tags:
 - core-object
 - fundamental
 ---
- 데이터를 포함하고 있는 디렉토리이며, {{< glossary_tooltip text="파드" term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다.
+ 데이터를 포함하고 있는 디렉터리이며, {{< glossary_tooltip text="파드" term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다.
 
 <!--more--> 
 

content/ko/docs/setup/best-practices/certificates.md

@@ -36,7 +36,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
 
 ## 인증서를 저장하는 위치
 
-만약 쿠버네티스를 kubeadm으로 설치했다면 인증서는 `/etc/kubernets/pki`에 저장된다. 이 문서에 언급된 모든 파일 경로는 그 디렉토리에 상대적이다.
+만약 쿠버네티스를 kubeadm으로 설치했다면 인증서는 `/etc/kubernets/pki`에 저장된다. 이 문서에 언급된 모든 파일 경로는 그 디렉터리에 상대적이다.
 
 ## 인증서 수동 설정
 

content/ko/docs/tasks/access-application-cluster/access-cluster.md

@@ -145,7 +145,7 @@ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
 위 예제에서는 `--insecure` flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로 
 두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을 
 서버 접속에 사용한다.
-(이들은 `~/.kube` 디렉토리에 설치된다.) 
+(이들은 `~/.kube` 디렉터리에 설치된다.) 
 일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가 
 root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다.
 

content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md

@@ -46,7 +46,7 @@ card:
 네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고,
 scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인증을 해야 한다.
 
-`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에
+`config-exercise`라는 디렉터리를 생성한다. `config-exercise` 디렉터리에
 다음 내용을 가진 `config-demo`라는 파일을 생성한다.
 
 ```shell
@@ -76,7 +76,7 @@ contexts:
 구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과
 두 사용자들, 세 컨텍스트들을 기술하기 위한 프레임워크를 가진다.
 
-`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의
+`config-exercise` 디렉터리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의
 세부사항들을 추가한다.
 
 ```shell
@@ -245,7 +245,7 @@ kubectl config --kubeconfig=config-demo view --minify
 
 ## 두 번째 구성 파일 생성
 
-`config-exercise` 디렉토리에서 다음 내용으로 `config-demo-2`라는 파일을 생성한다.
+`config-exercise` 디렉터리에서 다음 내용으로 `config-demo-2`라는 파일을 생성한다.
 
 ```shell
 apiVersion: v1
@@ -292,7 +292,7 @@ export  KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
 $Env:KUBECONFIG=("config-demo;config-demo-2")
 ```
 
-`config-exercise` 디렉토리에서 다음 커맨드를 입력한다.
+`config-exercise` 디렉터리에서 다음 커맨드를 입력한다.
 
 ```shell
 kubectl config view
@@ -330,14 +330,14 @@ contexts:
 kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
 [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)를 참조한다.
 
-## $HOME/.kube 디렉토리 탐색
+## $HOME/.kube 디렉터리 탐색
 
 만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여
-해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는
+해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉터리에 `config`라는
 파일을 가지고 있을 것이다.
 
 `$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자.
-보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다.
+보통 `config`라는 파일이 존재할 것이다. 해당 디렉터리 내에는 다른 구성 파일들도 있을 수 있다.
 간단하게 말하자면 당신은 이 파일들의 컨텐츠에 익숙해져야 한다.
 
 ## $HOME/.kube/config를 KUBECONFIG 환경 변수에 추가
@@ -356,7 +356,7 @@ export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
 ```
 
 이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자.
-config-exercise 디렉토리에서 다음 커맨드를 실행한다.
+config-exercise 디렉터리에서 다음 커맨드를 실행한다.
 
 ```shell
 kubectl config view

content/ko/docs/tasks/configure-pod-container/static-pod.md

@@ -53,8 +53,8 @@ API 서버에서 제어될 수는 없다.
 
 ### 파일시스템이 호스팅 하는 스태틱 파드 매니페스트 {#configuration-files}
 
-매니페스트는 특정 디렉토리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: <the directory>` 필드를 사용하자. 이 디렉토리를 정기적으로 스캔하여, 디렉토리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다.
-Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자.
+매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: <the directory>` 필드를 사용하자. 이 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다.
+Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자.
 
 예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다.
 
@@ -64,7 +64,7 @@ Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단
     ssh my-node1
     ```
 
-2. `/etc/kubelet.d` 와 같은 디렉토리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어 `/etc/kubelet.d/static-web.yaml` 에 배치한다.  
+2. `/etc/kubelet.d` 와 같은 디렉터리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어 `/etc/kubelet.d/static-web.yaml` 에 배치한다.  
 
     ```shell
 	  # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
@@ -87,7 +87,7 @@ Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단
     EOF
     ```
 
-3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉토리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다.
+3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉터리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다.
 
     ```
     KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
@@ -218,7 +218,7 @@ CONTAINER ID        IMAGE         COMMAND                CREATED       ...
 
 ## 스태틱 파드의 동적 추가 및 제거
 
-실행 중인 kubelet 은 주기적으로, 설정된 디렉토리(예제에서는 `/etc/kubelet.d`)에서 변경 사항을 스캔하고, 이 디렉토리에 새로운 파일이 생성되거나 삭제될 경우, 파드를 생성/삭제 한다.
+실행 중인 kubelet 은 주기적으로, 설정된 디렉터리(예제에서는 `/etc/kubelet.d`)에서 변경 사항을 스캔하고, 이 디렉터리에 새로운 파일이 생성되거나 삭제될 경우, 파드를 생성/삭제 한다.
 
 ```shell
 # 예제를 수행하는 사용자가 파일시스템이 호스팅하는 스태틱 파드 설정을 사용한다고 가정한다.

content/ko/docs/tasks/tools/install-kubectl.md

@@ -257,7 +257,7 @@ Windows에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지
    kubectl version --client
    ```
 
-3. 홈 디렉토리로 이동한다.
+3. 홈 디렉터리로 이동한다.
 
    ```powershell
    # cmd.exe를 사용한다면, 다음을 실행한다. cd %USERPROFILE%

content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md

@@ -15,7 +15,7 @@ content_type: tutorial
 * 다음을 포함하는 `kustomization.yaml` 파일을 생성한다.
   * 컨피그 맵 생성자
   * 컨피그 맵을 사용하는 파드 리소스
-* `kubectl apply -k ./`를 실행하여 작업한 디렉토리를 적용한다.
+* `kubectl apply -k ./`를 실행하여 작업한 디렉터리를 적용한다.
 * 구성이 잘 적용되었는지 확인한다.
 
 
@@ -65,7 +65,7 @@ resources:
 EOF
 ```
 
-컨피그 맵과 파드 개체를 생성하도록 kustomization 디렉토리를 적용한다.
+컨피그 맵과 파드 개체를 생성하도록 kustomization 디렉터리를 적용한다.
 
 ```shell
 kubectl apply -k .

content/ko/docs/tutorials/stateless-application/guestbook.md

@@ -47,7 +47,7 @@ card:
 
 {{< codenew file="application/guestbook/redis-master-deployment.yaml" >}}
 
-1. 매니페스트 파일을 다운로드한 디렉토리에서 터미널 창을 시작한다.
+1. 매니페스트 파일을 다운로드한 디렉터리에서 터미널 창을 시작한다.
 1. `redis-master-deployment.yaml` 파일을 통해 Redis 마스터의 디플로이먼트에 적용한다.
 
       ```shell