diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md
index db45ca2d2cbc7..d818aeae0b143 100644
--- a/content/ko/docs/concepts/configuration/overview.md
+++ b/content/ko/docs/concepts/configuration/overview.md
@@ -28,16 +28,16 @@ weight: 10
 - 더 나은 인트로스펙션(introspection)을 위해서, 어노테이션에 오브젝트의 설명을 넣는다.
 
 
-## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡 {#naked-pods-vs-replicasets-deployments-and-jobs}
+## "단독(Naked)" 파드 vs 레플리카셋(ReplicaSet), 디플로이먼트(Deployment), 그리고 잡(Job) {#naked-pods-vs-replicasets-deployments-and-jobs}
 
-- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
+- 가능하다면 단독 파드(즉, [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
 
-  명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
+  명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
 
 
 ## 서비스
 
-- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다.
+- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다.
 
   ```shell
   FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
@@ -67,7 +67,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
 
 오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다.
 
-- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카 셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다.
+- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다.
 
 ## 컨테이너 이미지
 
diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md
index e06daff9295e3..ed896ce0050d3 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md
@@ -87,7 +87,7 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
 문서화해야 한다.
 
 {{< note >}}
-레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
+레플리카셋(ReplicaSet)과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
 {{< /note >}}
 
 {{< caution >}}
diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md
index 269d72f51061e..609759906c146 100644
--- a/content/ko/docs/concepts/workloads/controllers/deployment.md
+++ b/content/ko/docs/concepts/workloads/controllers/deployment.md
@@ -316,7 +316,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이
 의도한 파드를 생성하고 띄우는 것을 주시한다. 만약 디플로이먼트가 업데이트되면, 기존 레플리카셋에서
 `.spec.selector` 레이블과 일치하는 파드를 컨트롤 하지만, 템플릿과 `.spec.template` 이 불일치하면 스케일 다운이 된다.
-결국 새로운 레플리카셋은 `.spec.replicas` 로 스케일되고, 모든 기존 레플리카 셋은 0개로 스케일된다.
+결국 새로운 레플리카셋은 `.spec.replicas` 로 스케일되고, 모든 기존 레플리카셋은 0개로 스케일된다.
 
 만약 기존 롤아웃이 진행되는 중에 디플로이먼트를 업데이트하는 경우 디플로이먼트가 업데이트에 따라 새 레플리카셋을 생성하고,
 스케일 업하기 시작한다. 그리고 이전에 스케일 업 하던 레플리카셋에 롤오버 한다.
@@ -671,7 +671,7 @@ deployment.apps/nginx-deployment scaled
 디플로이먼트 컨트롤러는 새로운 5개의 레플리카의 추가를 위한 위치를 결정해야 한다.
 만약 비례적 스케일링을 사용하지 않으면 5개 모두 새 레플리카셋에 추가된다.
 비례적 스케일링으로 추가 레플리카를 모든 레플리카셋에 걸쳐 분산할 수 있다.
-비율이 높을수록 가장 많은 레플리카가 있는 레플리카셋으로 이동하고, 비율이 낮을 수록 적은 레플리카가 있는 레플리카 셋으로 이동한다.
+비율이 높을수록 가장 많은 레플리카가 있는 레플리카셋으로 이동하고, 비율이 낮을 수록 적은 레플리카가 있는 레플리카셋으로 이동한다.
 남은 것들은 대부분의 레플리카가 있는 레플리카셋에 추가된다. 0개의 레플리카가 있는 레플리카셋은 스케일 업 되지 않는다.
 
 위의 예시에서 기존 레플리카셋에 3개의 레플리카가 추가되고, 2개의 레플리카는 새 레플리카에 추가된다.
diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md
index e99bb4f7c584a..bdaf8f27e3463 100644
--- a/content/ko/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md
@@ -250,7 +250,7 @@ matchLabels:
 그렇지 않으면 API에 의해 거부된다.
 
 {{< note >}}
-2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른 `.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카 셋은 다른 레플리카 셋이 생성한 파드를 무시한다.
+2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른 `.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카셋은 다른 레플리카셋이 생성한 파드를 무시한다.
 {{< /note >}}
 
 ### 레플리카
@@ -307,7 +307,7 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 
 ### 레플리카셋을 Horizontal Pod Autoscaler 대상으로 설정
 
-레플리카 셋은
+레플리카셋은
 [Horizontal Pod Autoscalers (HPA)](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)의 대상이 될 수 있다.
 즉, 레플리카셋은 HPA에 의해 오토스케일될 수 있다.
 다음은 이전에 만든 예시에서 만든 레플리카셋을 대상으로 하는 HPA 예시이다.
@@ -316,7 +316,7 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 
 이 매니페스트를 `hpa-rs.yaml`로 저장한 다음 쿠버네티스
 클러스터에 적용하면 CPU 사용량에 따라 파드가 복제되는
-오토스케일 레플리카 셋 HPA가 생성된다.
+오토스케일 레플리카셋 HPA가 생성된다.
 
 ```shell
 kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
index 7f78c8d6f0aec..420d45bb58409 100644
--- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -255,7 +255,7 @@ API 오브젝트에 대한 더 자세한 것은
 
 [`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
 이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
-사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카 셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
+사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
 
 
 ### 디플로이먼트 (권장되는)
diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md
index 39836fd7a152b..06cdbdc5e3c0b 100644
--- a/content/ko/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md
@@ -25,7 +25,7 @@ weight: 40
 
 위의 안정은 파드의 (재)스케줄링 전반에 걸친 지속성과 같은 의미이다.
 만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포,
-삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카 셋을
+삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카셋(ReplicaSet)을
 제공하는 워크로드 오브젝트를 사용해서 애플리케이션을 배포해야 한다.
 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 또는
 [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)과 같은 컨트롤러가 스테이트리스 요구에 더 적합할 수 있다.
diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index f1f586f5d8405..8a81e708dd1f1 100644
--- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -198,7 +198,7 @@ spec:
 `PodTopologySpread` 플러그인의 일부로 설정할 수 있다.
 제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로
 제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러,
-레플리카 셋 또는 스테이트풀셋에서 계산한다.
+레플리카셋 또는 스테이트풀셋에서 계산한다.
 
 예시 구성은 다음과 같다.
 
diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md
index bcf654b0bd597..5d4855386a952 100644
--- a/content/ko/docs/reference/kubectl/cheatsheet.md
+++ b/content/ko/docs/reference/kubectl/cheatsheet.md
@@ -255,7 +255,7 @@ KUBE_EDITOR="nano" kubectl edit svc/docker-registry   # 다른 편집기 사용
 ## 리소스 스케일링
 
 ```bash
-kubectl scale --replicas=3 rs/foo                                 # 'foo'라는 레플리카 셋을 3으로 스케일
+kubectl scale --replicas=3 rs/foo                                 # 'foo'라는 레플리카셋을 3으로 스케일
 kubectl scale --replicas=3 -f foo.yaml                            # "foo.yaml"에 지정된 리소스의 크기를 3으로 스케일
 kubectl scale --current-replicas=2 --replicas=3 deployment/mysql  # mysql이라는 디플로이먼트의 현재 크기가 2인 경우, mysql을 3으로 스케일
 kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # 여러 개의 레플리케이션 컨트롤러 스케일
diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
index 75bfb61a76c5d..033561555e1de 100644
--- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -144,9 +144,9 @@ track=stable
 클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
 
 #### 워크로드
-선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
+선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
 
-워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카 셋으로 관리하는 파드들 또는 새로운 레플리카 셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
+워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
 
 #### 서비스
 외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
diff --git a/content/ko/docs/tasks/administer-cluster/cluster-management.md b/content/ko/docs/tasks/administer-cluster/cluster-management.md
index b84b42b7e1a2f..34e5f3e818050 100644
--- a/content/ko/docs/tasks/administer-cluster/cluster-management.md
+++ b/content/ko/docs/tasks/administer-cluster/cluster-management.md
@@ -5,9 +5,9 @@ content_type: concept
 
 <!-- overview -->
 
-이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성, 
-클러스터의 마스터와 워커 노드들의 업그레이드, 
-노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의 
+이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성,
+클러스터의 마스터와 워커 노드들의 업그레이드,
+노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의
 쿠버네티스 API 버전 업그레이드.
 
 
@@ -25,17 +25,17 @@ content_type: concept
 
 ### Azure Kubernetes Service (AKS) 클러스터 업그레이드
 
-Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는 
+Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는
 현재 사용자가 직접 시작하는 방식이며 [Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)에 설명되어 있다.
 
 ### Google Compute Engine 클러스터 업그레이드
 
-Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고 
-재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해 
+Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고
+재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해
 동일한 Persistent Disk(PD)를 유지한다.
 
-GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는 
-순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은 
+GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는
+순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은
 레플리케이션 컨트롤러에 의해서 제어되거나, 롤 아웃 후에 수작업으로 재생성되어야 한다.
 
 open source Google Compute Engine(GCE) 클러스터 업그레이드는 `cluster/gce/upgrade.sh` 스크립트로 제어한다.
@@ -81,7 +81,7 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레
 
 ## 클러스터 크기 재조정
 
-[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다. 
+[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다.
 [Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면 `Compute > Compute Engine > Instance groups > your group > Edit group`에서 인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다.
 
 ```shell
@@ -99,23 +99,23 @@ Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터
 
 ### 클러스터 오토스케일링
 
-GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로 
+GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로
 재조정하도록 클러스터를 구성할 수 있다.
 
-[컴퓨트 리소스](/docs/concepts/configuration/manage-compute-resources-container/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다. 
-이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다. 
-여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는 
+[컴퓨트 리소스](/docs/concepts/configuration/manage-compute-resources-container/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다.
+이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다.
+여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는
 다른 파드들이 종료될 때까지 기다리거나 신규 노드가 추가될 때까지 기다린다.
 
-Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를 
+Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를
 추가하는 것이 도움이 되는지를 체크한다. 만약 도움이 된다면 대기중인 파드들을 수용하기 위해 클러스터의 크기를 재조정한다.
 
-Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안 
+Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안
 더 이상 필요하지 않다는 것을 확인했을 때 클러스터를 스케일 다운하기도 한다.
 
 Cluster autoscaler는 인스턴스 그룹(GCE)이나 노드 풀(Google Kubernetes Engine) 단위로 구성된다.
 
-GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다. 
+GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다.
 cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설정해야 한다.
 
 * `KUBE_ENABLE_CLUSTER_AUTOSCALER` - true로 설정되면 cluster autoscaler를 활성화한다.
@@ -128,8 +128,8 @@ cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설
 KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
 ```
 
-Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의 
-생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을 
+Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의
+생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을
 전달하여 cluster autoscaler를 구성할 수 있다.
 
 예제:
@@ -144,17 +144,17 @@ gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=
 
 **Cluster autoscaler는 노드가 수작업으로 변경(예. kubectl을 통해 레이블을 추가)되는 경우를 예상하지 않는데, 동일한 인스턴스 그룹 내의 신규 노드들에 이 속성들이 전파되지 않을 것이기 때문이다.**
 
-cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은 
-autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) 
+cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은
+autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
 문서를 참조하기를 바란다.
 
 ## 노드 유지보수
 
-(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면, 
-Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면 
-(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.) 
-노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는 
-레플리카 셋 (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이 
+(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면,
+Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면
+(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.)
+노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는
+레플리카셋(ReplicaSet) (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이
 복제된 상황에서 모든 노드들이 동시에 다운되지 않는다고 가정했을 때, 별다른 조작없이 업데이트를 진행할 수 있다.
 
 만약 업그레이드 과정을 상세하게 통제하기를 원한다면, 다음 워크플로우를 사용할 수 있다.
@@ -167,9 +167,9 @@ kubectl drain $NODENAME
 
 이렇게하면 파드가 종료되는 동안 신규 파드들이 해당 노드에 스케줄되는 것을 방지한다.
 
-레플리카 셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다.
+레플리카셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다.
 
-레플리카 셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다.
+레플리카셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다.
 
 해당 노드에 유지보수 작업을 수행한다.
 
@@ -179,8 +179,8 @@ kubectl drain $NODENAME
 kubectl uncordon $NODENAME
 ```
 
-해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가 
-자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면; 
+해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가
+자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면;
 이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라.
 
 ## 고급 주제들
@@ -199,15 +199,15 @@ kubectl uncordon $NODENAME
 
 ### 클러스터에서 API 버전을 ON/OFF 하기
 
-특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를 
-전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다. 
-예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다. 
+특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를
+전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다.
+예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다.
 이 플래그들을 위해 레거시 API들은 명확하게 사용중단된 API들이다.(예. `v1beta3`)
 
 ### 클러스터에서 스토리지 API 버전을 변경
 
 클러스터 내에서 활성화된 쿠버네티스 리소스들의 클러스터의 내부 표현을 위해 디스크에 저장된 객체들은 특정 버전의 API를 사용하여 작성된다.
-지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이 
+지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이
 쿠버네티스 API 서버에서 더 이상 해독되거나 사용할 수 없게 될 것이다.
 
 ### 구성 파일을 신규 API 버전으로 변경
diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 6b294b78509e2..ee5db9d3f2288 100644
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -8,7 +8,7 @@ weight: 100
 
 Horizontal Pod Autoscaler는
 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여
-레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다.
+레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다.
 
 이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다.
 
diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
index 2362c7f47519f..bfc602734a7cf 100644
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -199,9 +199,9 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`
 
 ## 롤링 업데이트 중 오토스케일링
 
-현재 쿠버네티스에서는 기본 레플리카 셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다.
+현재 쿠버네티스에서는 기본 레플리카셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다.
 Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고,
-디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카 셋의 크기를 결정한다.
+디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카셋의 크기를 결정한다.
 
 Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다.
 즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : `kubectl rolling-update`)
@@ -229,7 +229,7 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대
 이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야
 한다. 지연(쿨-다운) 값이 너무 길면, Horizontal Pod Autoscaler가
 워크로드 변경에 반응하지 않는다는 불만이 있을 수 있다. 그러나 지연 값을
-너무 짧게 설정하면, 레플리카 셋의 크기가 평소와 같이 계속 스래싱될 수
+너무 짧게 설정하면, 레플리카셋의 크기가 평소와 같이 계속 스래싱될 수
 있다.
 {{< /note >}}
 
diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html
index aed0258cf697e..6726fdd6e0d44 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html
@@ -28,7 +28,7 @@ <h3>목표</h3>
 			<div class="col-md-8">
 			<h3>쿠버네티스 서비스들에 대한 개요</h3>
 
-			<p>쿠버네티스 <a href="/ko/docs/concepts/workloads/pods/pod-overview/">파드들</a> 은 언젠가는 죽게된다. 실제 파드들은  <a href="/ko/docs/concepts/workloads/pods/pod-lifecycle/">생명주기</a>를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. <a href="/ko/docs/concepts/workloads/controllers/replicaset/">레플리카 셋</a>은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.</p>
+			<p>쿠버네티스 <a href="/ko/docs/concepts/workloads/pods/pod-overview/">파드들</a> 은 언젠가는 죽게된다. 실제 파드들은  <a href="/ko/docs/concepts/workloads/pods/pod-lifecycle/">생명주기</a>를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. <a href="/ko/docs/concepts/workloads/controllers/replicaset/">레플리카셋(ReplicaSet)</a>은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.</p>
 
 			<p>쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML <a href="/ko/docs/concepts/configuration/overview/#일반적인-구성-팁">(보다 선호하는)</a> 또는 JSON을 이용하여 정의된다. 서비스가 대상으로 하는 파드 셋은 보통 <i>LabelSelector</i>에 의해 결정된다 (여러분이 왜 스펙에 <code>selector</code>가 포함되지 않은 서비스를 필요로 하게 될 수도 있는지에 대해 아래에서 확인해 보자).</p>
 
@@ -80,7 +80,7 @@ <h3>서비스와 레이블</h3>
 					<li>태그들을 이용하는 객체들에 대한 분류</li>
 				</ul>
 			</div>
-			
+
 		</div>
 
 		<br>
diff --git a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md
index 291cceba264bb..f51a031290f2f 100644
--- a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md
+++ b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md
@@ -52,10 +52,10 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
 
 
 위의 명령어는
-    [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
+    [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)
     오브젝트와 관련된
-    [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)
-    오브젝트를 생성한다. 레플리카 셋은 다섯 개의
+    [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
+    오브젝트를 생성한다. 레플리카셋은 다섯 개의
     [파드](/ko/docs/concepts/workloads/pods/pod/)가 있으며,
     각 파드는 Hello World 애플리케이션을 실행한다.
 
@@ -64,7 +64,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
         kubectl get deployments hello-world
         kubectl describe deployments hello-world
 
-1. 레플리카 셋 오브젝트에 대한 정보를 확인한다.
+1. 레플리카셋 오브젝트에 대한 정보를 확인한다.
 
         kubectl get replicasets
         kubectl describe replicasets
@@ -160,7 +160,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
 
     kubectl delete services my-service
 
-Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카 셋, 파드를 삭제하려면,
+Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카셋, 파드를 삭제하려면,
 아래의 명령어를 입력한다.
 
     kubectl delete deployment hello-world