Seventh Korean l10n Work For Release 1.17 (#19857)

- Translation error correction with k8s.io/ko/docs/concepts/overview/components.md (#19720) - Error correction with overview/working-with-objects/kubernetes-objects.md (#19735) - Fix issues with working-with-objects/namespaces.md (#19753) - Issue with working-with-objects/object-management.md (#19740) - Fix issue with working-with-objects/labels.md (#19763) - Translate training/_index.html in Korean. (#19718) - Update links to docs that reference new docs added in the dev-1.17-ko.6 branch. (#19724) - Fix Issues with working-with-objects/names.md (#19749) - Update to Outdated files in the dev-1.17-ko.7 branch (#19712) - Error correction with /concepts/overview/kubernetes-api.md (#19733) - Translation error correction in /concepts/overview/what-is-kubernetes.md (#19710) - Typo in /contribute/participating.md (#19683) - Correct the Korean word typo 맴버 to 멤버 (#19674) Co-Authored-by: Jerry Park <jaehwa@gmail.com> Co-Authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-by: June Yi <june.yi@samsung.com> Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
2020-03-26 23:12:27 +09:00
parent 7094fbb5ab
commit efbf9a9e6e
84 changed files with 806 additions and 682 deletions
@@ -3,7 +3,7 @@ title: 필드 셀렉터
 weight: 60
 ---

-_필드 셀렉터_ 는 한 개 이상의 리소스 필드 값에 따라 [쿠버네티스 리소스를 선택](/docs/concepts/overview/working-with-objects/kubernetes-objects)하기 위해 사용된다. 필드 셀렉터 쿼리의 예시는 다음과 같다.
+_필드 셀렉터_ 는 한 개 이상의 리소스 필드 값에 따라 [쿠버네티스 리소스를 선택](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)하기 위해 사용된다. 필드 셀렉터 쿼리의 예시는 다음과 같다.

 * `metadata.name=my-service`
 * `metadata.namespace!=default`
@@ -45,7 +45,7 @@ kubectl get services  --all-namespaces --field-selector metadata.namespace!=defa

 ## 연계되는 셀렉터

-[레이블](/docs/concepts/overview/working-with-objects/labels)을 비롯한 다른 셀렉터처럼, 쉼표로 구분되는 목록을 통해 필드 셀렉터를 연계해서 사용할 수 있다. 다음의 `kubectl` 커맨드는 `status.phase` 필드가 `Running` 이 아니고, `spec.restartPolicy` 필드가 `Always` 인 모든 파드를 선택한다.
+[레이블](/ko/docs/concepts/overview/working-with-objects/labels)을 비롯한 다른 셀렉터처럼, 쉼표로 구분되는 목록을 통해 필드 셀렉터를 연계해서 사용할 수 있다. 다음의 `kubectl` 커맨드는 `status.phase` 필드가 `Running` 이 아니고, `spec.restartPolicy` 필드가 `Always` 인 모든 파드를 선택한다.

 ```shell
 kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
@@ -20,29 +20,45 @@ card:
 * 그 애플리케이션이 이용할 수 있는 리소스
 * 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책

-쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드" 이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 *의도한 상태* 가 된다.
+쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드"이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 *의도한 상태* 가 된다.

 생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, `kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.

-### 오브젝트 스펙(spec)과 상태(status)
+### 오브젝트 명세(spec)와 상태(status)

-모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 *spec* 과 오브젝트 *status* 가 그것이다. 필히 제공되어야만 하는 *spec* 은, 여러분이 오브젝트가 가졌으면 하고 원하는 특징, 즉 의도한 상태를 기술한다. *status* 는 오브젝트의 *실제 상태* 를 기술하고, 쿠버네티스 시스템에 의해 제공되고 업데이트 된다. 주어진 임의의 시간에, 쿠버네티스 컨트롤 플레인은 오브젝트의 실제 상태를 여러분이 제시한 의도한 상태에 일치시키기 위해 능동적으로 관리한다.
+거의 모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는
+두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 *`spec`* 과 오브젝트 *`status`* 이다.
+`spec`을 가진 오브젝트는 오브젝트를 생성할 때 리소스에
+원하는 특징(_의도한 상태_)에 대한 설명을
+제공해서 설정한다.

+`status`는 오브젝트의 _현재 상태_ 를 기술하고, 쿠버네티스
+컴포넌트에 의해 제공되고 업데이트 된다. 쿠버네티스
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 모든 오브젝트의
+실제 상태를 사용자가 의도한 상태와 일치시키기 위해 끊임없이 그리고
+능동적으로 관리한다.

-예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을 표현해 줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트 spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 (상태 변경에) 실패가 난다면, 쿠버네티스 시스템은 보정을 통해, 이 경우에는 인스턴스 대체를 착수하여, spec과 status 간의 차이에 대응한다.
+예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을
+표현해줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트
+spec에 3개의 애플리케이션 레플리카가 동작되도록
+설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어
+spec에 일치되도록 상태를 업데이트하여 3개의 의도한
+애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가
+(상태 변경에) 실패한다면, 쿠버네티스 시스템은 보정(이 경우에는 대체 인스턴스를 시작하여)을 통해
+spec과 status 간의 차이에 대응한다.

-오브젝트 spec, staus, 그리고 metadata에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다.
+오브젝트 명세, 상태, 그리고 메타데이터에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다.

 ### 쿠버네티스 오브젝트 기술하기

-쿠버네티스에서 오브젝트를 생성할 때, (이름과 같은)오브젝트에 대한 기본적인 정보와 더불어, 의도한 상태를 기술한 오브젝트 spec을 제시해 줘야만 한다. 오브젝트를 생성하기 위해(직접이든 또는 `kubectl`을 통해서든) 쿠버네티스 API를 이용할 때, API 요청은 요청 내용 안에 JSON 형식으로 정보를 포함시켜 줘야만 한다. **가장 자주, .yaml 파일로 `kubectl`에 정보를 제공해준다.** `kubectl` 은 API 요청이 이루어질 때, JSON 형식으로 정보를 변환시켜 준다.
+쿠버네티스에서 오브젝트를 생성할 때, (이름과 같은)오브젝트에 대한 기본적인 정보와 더불어, 의도한 상태를 기술한 오브젝트 spec을 제시해 줘야만 한다. 오브젝트를 생성하기 위해(직접이든 또는 `kubectl`을 통해서든) 쿠버네티스 API를 이용할 때, API 요청은 요청 내용 안에 JSON 형식으로 정보를 포함시켜 줘야만 한다. **대부분의 경우 정보를 .yaml 파일로 `kubectl`에 제공한다.** `kubectl`은 API 요청이 이루어질 때, JSON 형식으로 정보를 변환시켜 준다.

 여기 쿠버네티스 디플로이먼트를 위한 요청 필드와 오브젝트 spec을 보여주는 `.yaml` 파일 예시가 있다.

 {{< codenew file="application/deployment.yaml" >}}

 위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는
-`kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네
+`kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일을 건네
 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다.

 ```shell
@@ -61,7 +77,7 @@ deployment.apps/nginx-deployment created

 * `apiVersion` - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
 * `kind` - 어떤 종류의 오브젝트를 생성하고자 하는지
-* `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스` 를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
+* `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스`를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
 * `spec` - 오브젝트에 대해 어떤 상태를 의도하는지

 오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다. 
@@ -78,4 +94,3 @@ deployment.apps/nginx-deployment created
 * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
 {{% /capture %}}

-
@@ -27,11 +27,11 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이

 {{% capture body %}}

-## 사용동기
+## 사용 동기

 레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.

-서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔터티들이다(예: 다중파티션 또는 배포, 다중 릴리즈 트랙, 다중 계층, 계층속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.
+서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔티티들이다(예: 다중 파티션 또는 배포, 다중 릴리즈 트랙, 다중 계층, 계층 속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.

 레이블 예시:

@@ -41,17 +41,17 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
   * `"partition" : "customerA"`, `"partition" : "customerB"`
   * `"track" : "daily"`, `"track" : "weekly"`

-레이블 예시는 일반적으로 사용하는 경우에 해당한다. 당신의 규약에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야한다는 것을 기억해야한다.
+레이블 예시는 일반적으로 사용하는 상황에 해당한다. 당신의 규약에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.

 ## 구문과 캐릭터 셋

-_레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(`/`)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야하며, 점(`.`)과, 전체 253자 이하, 슬래시(`/`)로 구분되는 DNS 레이블이다.
+_레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(`/`)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야 하며, 점(`.`)과 전체 253자 이하, 슬래시(`/`)로 구분되는 DNS 레이블이다.

-접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 구성 요소(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
+접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.

-`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 구성요소로 예약되어있다.
+`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.

-유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다. 
+유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.

 다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.

@@ -83,10 +83,10 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
 레이블 셀렉터는 쉼표로 구분된 다양한 _요구사항_ 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(`&&`) 연산자로 구분되는 역할을 하도록 해야 한다.

 비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다.
-셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화 해야 한다.
+셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화해야 한다.

 {{< note >}}
-레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충되는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
+레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
 {{< /note >}}

 {{< caution >}}
@@ -96,23 +96,21 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의

 ### _일치성 기준_ 요건

-_일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만 레이블의 명시된 제약 조건을 모두 만족해야 한다.
-`=`,`==`,`!=` 이 3가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 단순히 동의어일 뿐임), 나머지는 _불일치_를 의미한다. 예를 들면,
+_일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만, 레이블의 명시된 제약 조건을 모두 만족해야 한다.
+`=`,`==`,`!=` 이 3가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 단순히 동의어일 뿐임), 나머지는 _불일치_ 를 의미한다. 예를 들면,

 ```
 environment = production
 tier != frontend
 ```

-전자는 `environment`를 키로 가지는 것과 `production`를 값으로 가지는 모든 리소스를 선택한다.
+전자는 `environment`를 키로 가지는 것과 `production`을 값으로 가지는 모든 리소스를 선택한다.
 후자는 `tier`를 키로 가지고, 값을 `frontend`를 가지는 리소스를 제외한 모든 리소스를 선택하고, `tier`를 키로 가지며, 값을 공백으로 가지는 모든 리소스를 선택한다.
-`environment=production,tier!=frontend` 처럼 쉼표를 통해 한 문장으로 `frontend`를 제외한 `production`을 필터링할 수 있다. 
+`environment=production,tier!=frontend` 처럼 쉼표를 통해 한 문장으로 `frontend`를 제외한 `production`을 필터링할 수 있다.

 균등-기반 레이블의 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다.
 예를 들어, 아래 샘플 파드는 "`accelerator=nvidia-tesla-p100`" 레이블을 가진 노드를 선택한다.

-
-
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -141,11 +139,11 @@ partition
 ```

 첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다.
-두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와, 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
-세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`를 포함하는 모든 리소스를 선택한다.
-네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`를 포함하지 않는 모든 리소스를 선택한다.
+두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
+세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하는 모든 리소스를 선택한다.
+네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하지 않는 모든 리소스를 선택한다.
 마찬가지로 쉼표는 _AND_ 연산자로 작동한다. 따라서 `partition,environment notin (qa)`와 같이 사용하면 값과 상관없이 키가 `partition`인 것과 키가 `environment`이고 값이 `qa`와 다른 리소스를 필터링할 수 있다.
-_집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=production` 과 `environment in (production)`를 같은 것으로 본다. 유사하게는 `!=`과 `notin`을 같은 것으로 본다.
+_집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=production`과 `environment in (production)`을 같은 것으로 본다. 유사하게는 `!=`과 `notin`을 같은 것으로 본다.

 _집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할 수 있다. 예를 들어 `partition in (customerA, customerB),environment!=qa`

@@ -158,7 +156,7 @@ LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브
  * _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
  * _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`

-두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, `kubectl`로 `API 서버`를 대상으로 _불일치 기준_으로 하는 셀렉터를 다음과 같이 이용할 수 있다.
+두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, `kubectl`로 `apiserver`를 대상으로 _불일치 기준_ 으로 하는 셀렉터를 다음과 같이 이용할 수 있다.

 ```shell
 kubectl get pods -l environment=production,tier=frontend
@@ -184,11 +182,11 @@ kubectl get pods -l 'environment,environment notin (frontend)'

 ### API 오브젝트에서 참조 설정

-[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다.
+[`services`](/ko/docs/concepts/services-networking/service/) 와 [`replicationcontrollers`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [파드](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다.

 #### 서비스와 레플리케이션 컨트롤러

-`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `레플리케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
+`services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.

 서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.

@@ -209,7 +207,7 @@ selector:

 #### 세트-기반 요건을 지원하는 리소스

-[`잡`](/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
+[`Job`](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/), [`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.

 ```yaml
 selector:
@@ -220,7 +218,7 @@ selector:
    - {key: environment, operator: NotIn, values: [dev]}
 ```

-`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`과 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다.
+`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다.

 #### 노드 셋 선택

@@ -9,9 +9,9 @@ weight: 20
 클러스터의 각 오브젝트는 해당 유형의 리소스에 대하여 고유한 [_이름_](#names) 을 가지고 있다.
 또한, 모든 쿠버네티스 오브젝트는 전체 클러스터에 걸쳐 고유한 [_UID_](#uids) 를 가지고 있다.

-예를 들어, 이름이 `myapp-1234`인 파드는 동일한 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) 내에서 하나만 가질 수 있지만, 이름이 `myapp-1234`인 파드와 디플로이먼트는 각각 가질 수 있다.
+예를 들어, 이름이 `myapp-1234`인 파드는 동일한 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) 내에서 하나만 존재할 수 있지만, 이름이 `myapp-1234`인 파드와 디플로이먼트는 각각 존재할 수 있다.

-유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)과 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.
+유일하지 않은 사용자 제공 속성의 경우 쿠버네티스는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)과 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.

 {{% /capture %}}

@@ -22,9 +22,9 @@ weight: 20

 {{< glossary_definition term_id="name" length="all" >}}

-다음은 리소스에 일반적으로 사용되는 세가지 유형의 이름 제한 조건이다.
+다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.

-### DNS 서브도메인 이름들
+### DNS 서브도메인 이름

 대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로 
 DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
@@ -52,7 +52,7 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
 있어야 한다. 즉 이름이 "." 또는 ".."이 아닐 수 있으며 이름에는
 "/" 또는 "%"가 포함될 수 없다.

-여기 파드의 이름이 `nginx-demo`라는 매니페스트 예시가 있다.
+아래는 파드의 이름이 `nginx-demo`라는 매니페스트 예시이다.

 ```yaml
 apiVersion: v1
@@ -6,33 +6,33 @@ weight: 30

 {{% capture overview %}}

-쿠버네티스는 동일 물리 클러스터를 기반으로 하는 복수의 가상 클러스터를 지원한다.
-이들 가상 클러스터를 네임스페이스라고 한다.
+쿠버네티스는 동일한 물리 클러스터를 기반으로 하는 여러 가상 클러스터를 지원한다.
+이런 가상 클러스터를 네임스페이스라고 한다.

 {{% /capture %}}


 {{% capture body %}}

-## 복수의 네임스페이스를 사용하는 경우
+## 여러 개의 네임스페이스를 사용하는 경우

-네임스페이스는 복수의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록
-만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는,
-네임스페이스를 고려할 필요가 전혀 없다.
+네임스페이스는 여러 개의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록
+만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는
+네임스페이스를 전혀 고려할 필요가 없다.
 네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자.

-네임스페이스는 이름의 범위를 제공한다.
-리소스의 이름은 네임스페이스 내에서 유일해야하지만,
-네임스페이스를 통틀어서 유일할 필요는 없다.
+네임스페이스는 이름의 범위를 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야하지만,
+네임스페이스를 통틀어서 유일할 필요는 없다. 네임스페이스는 서로 중첩될 수 없으며,
+각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다.

-네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다.
+네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 여러 사용자 사이에서 나누는 방법이다.

-다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적으로 동일한 접근  제어 정책을 갖게 된다.
-네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다.
+이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로 
+동일한 접근 제어 정책을 갖게 된다.

-같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서
-복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를
-구분하기 위해서는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 사용한다.
+동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해
+여러 네임스페이스를 사용할 필요는 없다. 동일한 네임스페이스 내에서 리소스를
+구별하기 위해 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 사용한다.

 ## 네임스페이스 다루기

@@ -41,7 +41,7 @@ weight: 30

 ### 네임스페이스 조회

-사용중인 클러스터의 현재 네임스페이스를 나열할 수 있다.
+사용 중인 클러스터의 현재 네임스페이스를 나열할 수 있다.

 ```shell
 kubectl get namespace
@@ -61,7 +61,7 @@ kube-public   Active    1d

 ### 요청에 네임스페이스 설정하기

-네임스페이스를 현재 요청에 설정하기 위해서는, `--namespace` 플래그를 사용한다.
+현재 요청에 대한 네임스페이스를 설정하기 위해서 `--namespace` 플래그를 사용한다.

 예를 들면,

@@ -72,7 +72,7 @@ kubectl get pods --namespace=<insert-namespace-name-here>

 ### 선호하는 네임스페이스 설정하기

-이후 모든 kubectl 명령에서 사용될 네임스페이스를 컨텍스트에
+이후 모든 kubectl 명령에서 사용하는 네임스페이스를 컨텍스트에
 영구적으로 저장할 수 있다.

 ```shell
@@ -83,7 +83,7 @@ kubectl config view --minify | grep namespace:

 ## 네임스페이스와 DNS

-[서비스](/docs/user-guide/services)를 생성하면, 대응되는
+[서비스](/docs/user-guide/services)를 생성하면 해당
 [DNS 엔트리](/ko/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
 이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데,
 이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.
@@ -94,10 +94,10 @@ kubectl config view --minify | grep namespace:

 대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는
 네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다.
-그리고 [nodes](/ko/docs/concepts/architecture/nodes/)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
+그리고 [노드](/ko/docs/concepts/architecture/nodes/)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
 네임스페이스에도 속하지 않는다.

-네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하기 위해서는,
+다음은 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하는 방법이다.

 ```shell
 # 네임스페이스에 속하는 리소스
@@ -7,7 +7,7 @@ weight: 15
 {{% capture overview %}}
 `kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
 몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을
-제공한다. Kubectl으로 오브젝트 관리하기에 대한 자세한 설명은 
+제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은 
 [Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다.
 {{% /capture %}}

@@ -16,7 +16,7 @@ weight: 15
 ## 관리 기법

 {{< warning >}}
-쿠버네티스 오브젝트는 오직 하나의 기법을 사용하여 관리되어야 한다. 동일한 오브젝트에
+쿠버네티스 오브젝트는 하나의 기법만 사용하여 관리해야 한다. 동일한 오브젝트에
 대해 혼합하고 일치시키는 기법은 확실하지 않은 동작을 초래하게 된다.
 {{< /warning >}}

@@ -26,10 +26,10 @@ weight: 15
 | Imperative object configuration  | Individual files     | Production projects    | 1                  | Moderate       |
 | Declarative object configuration | Directories of files | Production projects    | 1+                 | Highest        |

-## 명령형 명령어
+## 명령형 커맨드

-명령형 명령어를 사용할 경우, 사용자는 클러스터 내 활성 오브젝트를 대상으로
-직접 동작시킨다. 사용자는 `kubectl` 명령어에 인수 또는 플래그로 작업을
+명령형 커맨드를 사용할 경우, 사용자는 클러스터 내 활성 오브젝트를 대상으로
+직접 동작시킨다. 사용자는 `kubectl` 커맨드에 인수 또는 플래그로 작업을
 제공한다.

 이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한
@@ -52,21 +52,21 @@ kubectl create deployment nginx --image nginx

 ### 트레이드 오프

-오브젝트 구성과 비교한 장점은
+오브젝트 구성에 비해 장점은 다음과 같다.

- 명령어가 익히기에 단순, 용이하고 기억하기 쉽다.
- 명령어가 클러스터에 변경을 주기 위해 오직 단일 과정만이 필요하다.
+- 커맨드는 간단해서 배우기 쉽고, 기억하기 쉽다.
+- 커맨드는 클러스터를 수정하기 위해 단 하나의 단계만을 필요로 한다.

-오브젝트 구성과 비교한 단점은
+오브젝트 구성에 비해 단점은 다음과 같다.

- 명령어가 변경 검토 프로세스와 통합되지 않는다.
- 명령어가 변경에 관한 감사 추적을 제공하지 않는다.
- 명렁어가 활성 동작 중인 경우를 제외하고는 레코드의 소스를 제공하지 않는다.
- 명령어가 새로운 오브젝트 생성을 위한 템플릿을 제공하지 않는다.
+- 커맨드는 변경 검토 프로세스와 통합되지 않는다.
+- 커맨드는 변경에 관한 감사 추적(audit trail)을 제공하지 않는다.
+- 커맨드는 활성 동작 중인 경우를 제외하고는 레코드의 소스를 제공하지 않는다.
+- 커맨드는 새로운 오브젝트 생성을 위한 템플릿을 제공하지 않는다.

 ## 명령형 오브젝트 구성

-명령형 오브젝트 구성에서, kubectl 명령은 작업 (생성, 대체 등),
+명령형 오브젝트 구성에서 kubectl 커맨드는 작업(생성, 교체 등),
 선택적 플래그, 그리고 최소 하나의 파일 이름을 정의한다.
 그 파일은 YAML 또는 JSON 형식으로 오브젝트의 완전한 정의를
 포함해야만 한다.
@@ -75,12 +75,12 @@ kubectl create deployment nginx --image nginx
 참고한다.

 {{< warning >}}
-명령형 `replace` 명령은 기존 spec을 새롭게 제공된 것으로 대체하며,
-구성 파일에서 누락된 오브젝트에 대한 모든 변경사항은 없어진다.
-이러한 접근은 구성 파일에 대해 독립적으로 spec이 업데이트되는
-형태의 리소스와 함께 사용하면 안된다.
-예를 들어, `LoadBalancer` 형태의 서비스는 `externalIPs` 필드를
-클러스터 구성과는 독립적으로 업데이트한다.
+명령형 `replace` 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고 
+구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다. 
+이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는 
+사용하지 말아야한다. 
+예를 들어 `LoadBalancer` 유형의 서비스는 클러스터의 구성과 별도로 
+`externalIPs` 필드가 업데이트된다.
 {{< /warning >}}

 ### 예시
@@ -97,7 +97,7 @@ kubectl create -f nginx.yaml
 kubectl delete -f nginx.yaml -f redis.yaml
 ```

-활성 동작하는 구성을 덮어씀으로서 구성 파일에 정의된 오브젝트를
+활성 동작하는 구성을 덮어씀으로써 구성 파일에 정의된 오브젝트를
 업데이트한다.

 ```sh
@@ -106,41 +106,42 @@ kubectl replace -f nginx.yaml

 ### 트레이드 오프

-명령형 명령과 비교한 장점은
+명령형 커맨드에 비해 장점은 다음과 같다.

- 오브젝트 구성이 Git과 같은 소스 컨트롤 시스템에 보관되어 질 수 있다.
+- 오브젝트 구성은 Git과 같은 소스 컨트롤 시스템에 보관할 수 있다.
 - 오브젝트 구성은 푸시와 감사 추적 전에 변경사항을 검토하는 것과 같은 프로세스들과 통합할 수 있다.
- 오브젝트 구성이 새로운 오브젝트 생성을 위한 템플릿을 제공한다.
+- 오브젝트 구성은 새로운 오브젝트 생성을 위한 템플릿을 제공한다.

-명령형 명령과 비교한 단점은
+명령형 커맨드에 비해 단점은 다음과 같다.

- 오브젝트 구성이 오브젝트 스키마에 대한 기본적인 이해를 필요로 한다.
- 오브젝트 구성이 YAML 파일을 기록하는 추가적인 과정을 필요로 한다.
+- 오브젝트 구성은 오브젝트 스키마에 대한 기본적인 이해를 필요로 한다.
+- 오브젝트 구성은 YAML 파일을 기록하는 추가적인 과정을 필요로 한다.

-선언형 오브젝트 구성과 비교한 장점은
+선언형 오브젝트 구성에 비해 장점은 다음과 같다.

- 명령형 오브젝트 구성의 작용은 보다 간결하고 이해하기에 용이하다.
- 쿠버네티스 버전 1.5 부터, 명령형 오브젝트 구성이 더욱 발달한다.
+- 명령형 오브젝트 구성의 동작은 보다 간결하고 이해하기 쉽다.
+- 쿠버네티스 버전 1.5 부터는 더 성숙한 명령형 오브젝트 구성을 제공한다.

-선언형 오브젝트 구성과 비교한 단점은
+선언형 오브젝트 구성에 비해 단점은 다음과 같다.

 - 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다.
- 활성 오브젝트에 대한 업데이트는 구성 파일 내 반영되어야만 한다. 그렇지 않으면 다음 대체가 이루어지는 동안 유실 될 것이다.
+- 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다.
+

 ## 선언형 오브젝트 구성

 선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트
 구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할
 작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은
-`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이것은 다른 오브젝트를 위해 필요할 수도 있는
-다른 작업에서, 디렉토리들을 대상으로 동작할 수 있도록 해준다.
+`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 
+다른 조작이 필요할 수 있는 디렉토리에서 작업할 수 있다.

 {{< note >}}
-선언형 오브젝트 구성은 비록 그 변경사항이 오브젝트 구성 파일로
-되돌려 병합될 수 없기는 하지만, 다른 작성자에 의해 이루어진 변경사항을 유지한다.
-이는 전체 오브젝트 구성을 대체하기 위해 `replace` API 작업을 이용하는 대신,
-오직 인지된 차이점을 기록하기 위한 `patch`
-API 작업을 이용함으로서 가능하다.
+선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에 
+다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다. 
+이것은 전체 오브젝트 구성 변경을 위한 `replace` API를
+사용하는 대신, `patch` API를 사용하여 인지되는 차이만 
+작성하기 때문에 가능하다.
 {{< /note >}}

 ### 예시
@@ -163,24 +164,24 @@ kubectl apply -R -f configs/

 ### 트레이드 오프

-명령형 오브젝트 구성과 비교한 장점은
+명령형 오브젝트 구성에 비해 장점은 다음과 같다.

- 구성 파일로 되돌려 병합될 수 없기는 하지만, 활성 오브젝트에 직접 이루어진 변경사항이 유지된다.
- 선언형 오브젝트 구성은 디렉토리에 관한 동작에 대해 더 나은 지원을 하고 자동으로 오브젝트 마다의 작업(생성, 패치, 삭제)을 감지한다.
+- 활성 오브젝트에 직접 작성된 변경 사항은 구성 파일로 다시 병합되지 않더라도 유지된다.
+- 선언형 오브젝트 구성은 디렉토리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다.

-명령형 오브젝트 구성과 비교한 단점은
+명령형 오브젝트 구성에 비해 단점은 다음과 같다.

- 선언형 오브젝트 구성은 예측이 불가할 경우 디버그 하기가 더 어렵고 결과를 이해하기가 더 어렵다.
- 차이점를 이용한 부분적 업데이트는 복잡한 병합과 패치 작업을 만들어 낸다.
+- 선언형 오브젝트 구성은 예상치 못한 결과를 디버깅하고 이해하기가 더 어렵다.
+- diff를 사용한 부분 업데이트는 복잡한 병합 및 패치 작업을 일으킨다.

 {{% /capture %}}

 {{% capture whatsnext %}}
 - [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
- [Kustomize를 사용한 쿠버네티스 오브젝트 관리하기 (선언형)](/docs/tasks/manage-kubernetes-objects/kustomization/)
- [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl-commands/)
+- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
+- [Kustomize를 사용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)
+- [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Kubectl 서적](https://kubectl.docs.kubernetes.io)
 - [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)