Apply suggestions from code review.

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

@@ -32,7 +32,7 @@ weight: 40
 
 ## 제한사항
 
-* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스던트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
+* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
 * 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. 
 * 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
 * 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
@@ -103,9 +103,9 @@ spec:
 스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
 
 ## 파드 신원
-스테이트풀셋 파드는 안정적인 네트워크 신원과 안정적인 
-스토리지의 순서로 구성되는 고유한 신원을 가진다. 신원은 노드의 
-스케줄 또는 재스캐줄에 상관없이 파드에 붙어 있다.
+스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 그리고
+안정적인 스토리지로 구성되는 고유한 신원을 가진다. 신원은 
+파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다.
 
 ### 순서 색인
 
@@ -150,8 +150,8 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 
 1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게된다. 만약 스토리지 클래스가 
 명시되지 않은 경우 기본 스토리지 클래스를 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이되면 
-파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스던트 볼륨이 마운트 된다.
-참고로, 파드 퍼시스던트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은 
+파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
+참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은 
 파드 또는 스테이트풀셋이 삭제되더라도 삭제되지 않는다.
 이것은 반드시 수동으로 해야한다.
 
@@ -208,30 +208,30 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 
 ### 삭제 시(On Delete)
 
-`OnDelete` 업데이트는 레거시(1.6과 이전) 동작의 계획을 실행한다.  이때 스테이트풀셋의 
+`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의 
 `.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는 
 스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의 
 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.
 
 ### 롤링 업데이트
 
-`롤링 업데이트` 의 업데이트 계획은 스테이트풀셋의 파드에 대한 롤링 업데이트를 
-실행한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 계획이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 
+`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 
+구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 
 스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이 
 순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지), 
 각 파드의 업데이트는 한번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될 
 때까지 기다린다.
 
 #### 파티션(Partition)
 
-`롤링 업데이트` 의 업데이트 계획은 `.spec.updateStrategy.rollingUpdate.partition` 
-를 명시해서 분할 할 수 있다. 만약 분할을 명시하면 스테이트풀셋의 `.spec.template` 가 
-업데이트 될 때 부여된 수가 분할보다 크거나 같은 모든 파드가 업데이트 된다.
-분할보다 작은 수를 가진 모든 파드는 업데이트 되지 않으며, 
+`롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition` 
+를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가 
+업데이트 될 때 부여된 수가 파티션보다 크거나 같은 모든 파드가 업데이트 된다.
+파티션보다 작은 수를 가진 모든 파드는 업데이트 되지 않으며, 
 삭제 된 경우라도 이전 버전에서 재생성된다.
 만약 스테이트풀셋의 `.spec.updateStrategy.rollingUpdate.partition` 이 
 `.spec.replicas` 보다 큰 경우 `.spec.template` 의 업데이트는 해당 파드에 전달하지 않는다.
-대부분의 케이스는 분할을 사용할 필요가 없지만 업데이트를 준비하거나, 
+대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나, 
 카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다.
 
 #### 강제 롤백