reflection with ysyukr's reviews

content/ko/docs/concepts/services-networking/service.md

@@ -117,7 +117,7 @@ spec:
 버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
 
 서비스의 기본 프로토콜은 TCP이다. 다른
-[지원 프로토콜](#지원-프로토콜)을 사용할 수도 있다.
+[지원되는 프로토콜](#protocol-support)을 사용할 수도 있다.
 
 많은 서비스가 하나 이상의 포트를 노출해야 하기 때문에, 쿠버네티스는 서비스 오브젝트에서 다중
 포트 정의를 지원한다.
@@ -168,7 +168,7 @@ subsets:
 ```
 
 {{< note >}}
-엔드포인트 IP는 루프백 (IPv4의 경우 127.0.0.0/8, IPv6의 경우 ::1/128), 또는
+엔드포인트 IP는 루프백(loopback) (IPv4의 경우 127.0.0.0/8, IPv6의 경우 ::1/128), 또는
 링크-로컬 (IPv4의 경우 169.254.0.0/16와 224.0.0.0/24, IPv6의 경우 fe80::/64)이 _되어서는 안된다_.
 
 엔드포인트 IP 주소는 다른 쿠버네티스 서비스의 클러스터 IP일 수 없는데,
@@ -194,7 +194,7 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만,
 추가 엔드포인트를 저장하기 위해서는 추가 엔드포인트 슬라이스가
 생성된다.
 
-엔드포인트 슬라이스는 [엔드포인트 슬라이스](/docs/concepts/services-networking/endpoint-slices/)에서
+엔드포인트 슬라이스는 [엔드포인트 슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에서
 자세하게 설명된 추가적인 속성 및 기능을 제공한다.
 
 ## 가상 IP와 서비스 프록시
@@ -242,7 +242,7 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
 이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스, 엔드포인트 객체의
 추가와 제거를 감시한다. 각 서비스에 대해, 서비스의
 `clusterIP` 및 `port`에 대한 트래픽을 캡처하고 해당 트래픽을 서비스의
-백엔드 세트 중 하나로 리다이렉트하는
+백엔드 세트 중 하나로 리다이렉트(redirect)하는
 iptables 규칙을 설치한다. 각 엔드포인트 오브젝트에 대해,
 백엔드 파드를 선택하는 iptables 규칙을 설치한다.
 
@@ -257,7 +257,7 @@ kube-proxy가 iptables 모드에서 실행 중이고 선택된 첫 번째 파드
 다르다: 해당 시나리오에서는, kube-proxy는 첫 번째
 파드에 대한 연결이 실패했음을 감지하고 다른 백엔드 파드로 자동으로 재시도한다.
 
-파드 [준비상태 프로브](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 사용하여
+파드 [준비성 프로브(readiness probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 사용하여
 백엔드 파드가 제대로 작동하는지 확인할 수 있으므로, iptables 모드의 kube-proxy는
 정상으로 테스트된 백엔드만 볼 수 있다. 이렇게 하면 트래픽이 kube-proxy를 통해
 실패한 것으로 알려진 파드로 전송되는 것을 막을 수 있다.
@@ -426,7 +426,7 @@ IP 주소와 `"http"`에 대한 포트 번호를 검색하기 위해 `_http._tcp
 DNS SRV 쿼리를 수행할 수 있다.
 
 쿠버네티스 DNS 서버는 `ExternalName` 서비스에 접근할 수 있는 유일한 방법이다.
-[DNS 파드와 서비스](/docs/concepts/services-networking/dns-pod-service/)에서
+[DNS 파드와 서비스](/ko/docs/concepts/services-networking/dns-pod-service/)에서
 `ExternalName` 검색에 대한 자세한 정보를 찾을 수 있다.
 
 ## 헤드리스(Headless) 서비스
@@ -488,7 +488,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
      `ExternalName` 유형을 사용하려면 CoreDNS 버전 1.7 이상이 필요하다.
      {{< /note >}}
 
-[인그레스](/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
+[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
 
 ### NodePort 유형 {#nodeport}
 
@@ -501,7 +501,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 포트를 프록시하기 위해 특정 IP를 지정하려면 kube-proxy의 `--nodeport-addresses` 플래그를 특정 IP 블록으로 설정할 수 있다. 이것은 쿠버네티스 v1.10.부터 지원된다.
 이 플래그는 쉼표로 구분된 IP 블록 목록 (예: 10.0.0.0/8, 192.0.2.0/25)을 사용하여 kube-proxy가 로컬 노드로 고려해야하는 IP 주소 범위를 지정한다.
 
-예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백 인터페이스만 선택한다. `--nodeport-addresses`의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).
+예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다. `--nodeport-addresses`의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).
 
 특정 포트 번호를 원한다면, `nodePort` 필드에 값을 지정할 수
 있다. 컨트롤 플레인은 해당 포트를 할당하거나 API 트랜잭션이
@@ -821,7 +821,7 @@ Classic ELB의 연결 드레이닝은
 
 {{< feature-state for_k8s_version="v1.15" state="beta" >}}
 
-AWS에서 Network Load Balancer를 사용하려면, `nlb` 값이 설정된 `service.beta.kubernetes.io/aws-load-balancer-type` 어노테이션을 사용한다.
+AWS에서 네트워크 로드 밸런서를 사용하려면, `nlb` 값이 설정된 `service.beta.kubernetes.io/aws-load-balancer-type` 어노테이션을 사용한다.
 
 ```yaml
     metadata:
@@ -850,7 +850,7 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스
 [파드 anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)
 를 지정하여 동일한 노드에 위치하지 않도록 한다.
 
-[내부 로드 밸런서](/docs/concepts/services-networking/service/#internal-load-balancer) 어노테이션과 함께 NLB 서비스를
+[내부 로드 밸런서](/ko/docs/concepts/services-networking/service/#internal-load-balancer) 어노테이션과 함께 NLB 서비스를
 사용할 수도 있다.
 
 클라이언트 트래픽이 NLB 뒤의 인스턴스에 도달하기 위해, 노드 보안
@@ -879,7 +879,7 @@ spec:
 
 {{< /note >}}
 
-#### Other CLB annotations on Tencent Kubernetes Engine (TKE)
+#### Tencent Kubernetes Engine (TKE)의 다른 CLB 어노테이션
 
 아래 표시된 것처럼 TKE에서 클라우드 로드 밸런서를 관리하기 위한 다른 어노테이션이 있다.
 
@@ -936,7 +936,7 @@ spec:
 {{< note >}}
 ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다. Pv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은
 정식(canonical) DNS 이름을 지정하기 때문이다. IP 주소를 하드 코딩하려면,
-[headless Services](#headless-services) 사용을 고려한다.
+[헤드리스(headless) 서비스](#헤드리스-headless-서비스) 사용을 고려한다.
 {{< /note >}}
 
 `my-service.prod.svc.cluster.local` 호스트를 검색하면, 클러스터 DNS 서비스는
@@ -1001,8 +1001,8 @@ VIP용으로 유저스페이스 프록시를 사용하면, 중소 급 스케일
 
 `Type` 필드는 중첩된 기능으로 설계되었다. - 각 레벨은 이전 레벨에
 추가된다. 이는 모든 클라우드 공급자에 반드시 필요한 것은 아니지만, (예: Google Compute Engine는
-  `LoadBalancer`를 작동시키기 위해 `NodePort`를 할당할 필요는 없지만, AWS는 필요하다),
-  현재 API에는 필여하다.
+  `LoadBalancer`를 작동시키기 위해 `NodePort`를 할당할 필요는 없지만, AWS는 필요하다)
+  현재 API에는 필요하다.
 
 ## 가상 IP 구현 {#the-gory-details-of-virtual-ips}
 
@@ -1047,7 +1047,7 @@ iptables (Linux의 패킷 처리 로직)를 사용하여 필요에 따라
 kube-proxy는 조금씩 다르게 작동하는 세 가지 프록시 모드&mdash;유저스페이스, iptables and IPVS&mdash;를
 지원한다.
 
-#### 유저스페이스
+#### 유저스페이스 (userspace)
 
 예를 들어, 위에서 설명한 이미지 처리 애플리케이션을 고려한다.
 백엔드 서비스가 생성되면, 쿠버네티스 마스터는 가상
@@ -1094,7 +1094,7 @@ IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이
 ## API 오브젝트
 
 서비스는 쿠버네티스 REST API의 최상위 리소스이다. API 오브젝트에 대한
-자세한 내용은 다음을 참고한다. [Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)
+자세한 내용은 다음을 참고한다. [서비스 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)
 
 ## 지원되는 프로토콜 {#protocol-support}