Merge pull request #40863 from yujinchoi-94/230404_update_outdated_M61

[ko] Update outdated files in `dev-1.26-ko.1` (M61)

content/ko/docs/concepts/services-networking/endpoint-slices.md

@@ -3,7 +3,11 @@
 # - freehan
 title: 엔드포인트슬라이스
 content_type: concept
-weight: 45
+weight: 60
+description: >-
+  엔드포인트슬라이스 API는 서비스가 대규모 백엔드를 처리할 수 있도록 확장할 수 있게 해주고,
+  클러스터가 정상적인 백엔드의 리스트를 효율적으로 업데이트 할 수 있도록
+  쿠버네티스가 사용하는 메커니즘이다.
 ---
 
 
@@ -11,32 +15,13 @@ weight: 45
 
 {{< feature-state for_k8s_version="v1.21" state="stable" >}}
 
-_엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
-추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한
+쿠버네티스의 _엔드포인트슬라이스_ API 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
+추적하는 방법을 제공한다. 엔드포인트슬라이스는 [엔드포인트](/ko/docs/concepts/services-networking/service/#endpoints)보다 더 유동적이고, 확장 가능한
 대안을 제안한다.
 
-
-
 <!-- body -->
 
-## 사용동기
-
-엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
-간단하고 직접적인 방법을 제공한다. 불행하게도 쿠버네티스 클러스터와
-{{< glossary_tooltip text="서비스" term_id="service" >}}가 더 많은 수의 백엔드 파드로
-더 많은 트래픽을 처리하고 전송하는 방향으로 성장함에 따라, 이 API의 한계가 더욱 눈에 띄게
-되었다.
-특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에
-어려움이 있었다.
-
-이후로 서비스에 대한 모든 네트워크 엔드포인트가 단일 엔드포인트
-리소스에 저장되기 때문에 엔드포인트 리소스가 상당히 커질 수 있다. 이것은 쿠버네티스
-구성요소 (특히 마스터 컨트롤 플레인)의 성능에 영향을 미쳤고
-엔드포인트가 변경될 때 상당한 양의 네트워크 트래픽과 처리를 초래했다.
-엔드포인트슬라이스는 이러한 문제를 완화하고 토폴로지 라우팅과
-같은 추가 기능을 위한 확장 가능한 플랫폼을 제공한다.
-
-## 엔드포인트슬라이스 리소스 {#endpointslice-resource}
+## 엔드포인트슬라이스 API {#endpointslice-resource}
 
 쿠버네티스에서 엔드포인트슬라이스는 일련의 네트워크 엔드포인트에 대한
 참조를 포함한다. 쿠버네티스 서비스에 {{< glossary_tooltip text="셀렉터"
@@ -48,8 +33,8 @@ term_id="selector" >}}가 지정되면 컨트롤 플레인은 자동으로
 엔드포인트슬라이스 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
-예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 엔드포인트슬라이스
-리소스 샘플이 있다.
+예를 들어, 여기에 `example` 쿠버네티스 서비스가 소유하는 엔드포인트슬라이스
+객체 샘플이 있다.
 
 ```yaml
 apiVersion: discovery.k8s.io/v1
@@ -81,8 +66,7 @@ endpoints:
 
 엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해
 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}에
-신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는
-서비스에 대해 성능 향상을 제공해야 한다.
+신뢰할 수 있는 소스로 역할을 할 수 있다.
 
 ### 주소 유형
 
@@ -92,12 +76,16 @@ endpoints:
 * IPv6
 * FQDN (전체 주소 도메인 이름)
 
-### 조건
+각 엔드포인트슬라이스 객체는 특정한 IP 주소 유형을 나타낸다.
+IPv4와 IPv6를 사용할 수 있는 서비스가 있을 경우,
+최소 두개의 엔드포인트슬라이스 객체가 존재한다(IPv4를 위해 하나, IPv6를 위해 하나).
+
+### 컨디션
 
 엔드포인트슬라이스 API는 컨슈머에게 유용한 엔드포인트에 대한 조건을 저장한다.
-조건은 `준비`, `제공` 및 `종료` 세 가지가 있다.
+조건은 `ready`, `serving` 및 `Terminating` 세 가지가 있다.
 
-#### 준비
+#### Ready
 
 `ready`는 파드의 `Ready` 조건에 매핑되는 조건이다. `Ready` 조건이 `True`로 설정된 실행 중인 파드는
 이 엔드포인트슬라이스 조건도 `true`로 설정되어야 한다. 호환성의
@@ -106,7 +94,7 @@ endpoints:
 이 규칙의 유일한 예외는 `spec.publishNotReadyAddresses`가 `true`로 설정된 서비스이다.
 이러한 서비스의 엔드 포인트는 항상 `ready`조건이 `true`로 설정된다.
 
-#### 제공(Serving)
+#### Serving
 
 {{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
@@ -125,14 +113,14 @@ endpoints:
 
 {{< /note >}}
 
-#### 종료(Terminating)
+#### Terminating
 
 {{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 `종료(Terminating)`는 엔드포인트가 종료되는지 여부를 나타내는 조건이다.
 파드의 경우 삭제 타임 스탬프가 설정된 모든 파드이다.
 
-### 토폴로지 정보 {#토폴로지}
+### 토폴로지 정보 {#topology}
 
 엔드포인트슬라이스 내의 각 엔드 포인트는 관련 토폴로지 정보를 포함할 수 있다.
 토폴로지 정보에는 엔드 포인트의 위치와 해당 노드 및
@@ -242,11 +230,48 @@ v1 API의 `zone` 필드로 접근할 수 있다.
 엔드포인트슬라이스 변경의 특성으로 인해, 엔드포인트는 동시에 둘 이상의
 엔드포인트슬라이스에 표시될 수 있다. 이는 다른 엔드포인트슬라이스 오브젝트에
 대한 변경 사항이 다른 시간에서의 쿠버네티스 클라이언트 워치(watch)/캐시에
-도착할 수 있기 때문에 자연스럽게 발생한다. 엔드포인트슬라이스를 사용하는 구현은
-엔드포인트가 둘 이상의 슬라이스에 표시되도록 할 수 있어야 한다. 엔드포인트
-중복 제거를 수행하는 방법에 대한 레퍼런스 구현은 `kube-proxy` 의
+도착할 수 있기 때문에 자연스럽게 발생한다.
+
+{{< note >}}
+엔드포인트슬라이스 API의 클라이언트는 반드시 서비스에 연관된 모든 존재하는 엔드포인트슬라이스에 대해
+반복하고, 고유한 각 네트워크 엔드포인트들의 완전한 리스트를 구성해야 한다. 엔드포인트는 다른
+엔드포인트슬라이스에서 중복될 수 있음에 유의한다.
+
+엔드포인트 집계와 중복 제거 방법에 대한 레퍼런스 구현은 `kube-proxy` 의
 `EndpointSliceCache` 구현에서 찾을 수 있다.
+{{< /note >}}
+
+## 엔드포인트와 비교 {#motivation}
+
+기존 엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
+간단하고 직접적인 방법을 제공했다. 쿠버네티스 클러스터와
+{{< glossary_tooltip text="서비스" term_id="service" >}}가 더 많은 수의 백엔드 파드로
+더 많은 트래픽을 처리하고 전송하는 방향으로 성장함에 따라, 이 API의 한계가 더욱 눈에 띄게
+되었다.
+특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에
+어려움이 있었다.
+
+서비스에 대한 모든 네트워크 엔드포인트가 단일 엔드포인트
+객체에 저장되기 때문에 이러한 엔드포인트 객체들이 상당히 커지는 경우도 있었다. 안정적인
+서비스(오랜 기간 동안 같은 엔드포인트 세트)의 경우 영향은
+비교적 덜 눈에 띄지만, 여전히 쿠버네티스의 일부 사용 사례들은 잘 처리되지 않았다.
+
+서비스가 많은 백엔드 엔드포인트를 가지고
+워크로드가 자주 증가하거나, 새로운 변경사항이 자주 롤 아웃 될 경우,
+해당 서비스의 단일 엔드포인트 객체에 대한 각 업데이트는
+쿠버네티스 클러스터 컴포넌트 사이(컨트롤 플레인 내, 그리고 노드와 API 서버 사이)에
+상당한 네트워크 트래픽이 발생할 것임을 의미했다.
+이러한 추가 트래픽은 또한 CPU 사용 관점에서도 굉장한 비용을 발생시켰다.
+
+엔드포인트슬라이스 사용 시, 단일 파드를 추가하거나 삭제하는 작업은 (다수의 파드를 추가/삭제하는 작업과 비교했을 때)
+해당 변경을 감시하고 있는 클라이언트에 동일한 _수_의 업데이트를 트리거한다.
+하지만, 파드 대규모 추가/삭제의 경우 업데이트 메시지의 크기는 훨씬 작다.
+
+엔드포인트슬라이스는 듀얼 스택 네트워킹과 토폴로지 인식 라우팅과 같은
+새로운 기능에 대한 혁신을 가능하게 했다.
 
 ## {{% heading "whatsnext" %}}
 
-* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
+* [서비스와 애플리케이션 연결하기](/docs/concepts/services-networking/connect-applications-service/) 튜토리얼을 따라하기
+* [엔드포인트슬라이스 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) 를 읽어보기
+* [엔드포인트 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) 를 읽어보기