diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 22612166de0bf..bde2e4fcec228 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/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는 조금씩 다르게 작동하는 세 가지 프록시 모드—유저스페이스, iptables and IPVS—를 지원한다. -#### 유저스페이스 +#### 유저스페이스 (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}