206 lines
11 KiB
Markdown
206 lines
11 KiB
Markdown
---
|
|
title: 엔드포인트슬라이스
|
|
content_type: concept
|
|
weight: 35
|
|
---
|
|
|
|
|
|
<!-- overview -->
|
|
|
|
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
|
|
|
_엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
|
|
추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한
|
|
대안을 제안한다.
|
|
|
|
|
|
|
|
<!-- body -->
|
|
|
|
## 사용동기
|
|
|
|
엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
|
|
간단하고 직접적인 방법을 제공한다. 불행하게도 쿠버네티스 클러스터와
|
|
{{< glossary_tooltip text="서비스" term_id="service" >}}가 더 많은 수의 백엔드 파드로
|
|
더 많은 트래픽을 처리하고 전송하는 방향으로 성장함에 따라, 이 API의 한계가 더욱 눈에 띄게
|
|
되었다.
|
|
특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에
|
|
어려움이 있었다.
|
|
|
|
이후로 서비스에 대한 모든 네트워크 엔드포인트가 단일 엔드포인트
|
|
리소스에 저장되기 때문에 엔드포인트 리소스가 상당히 커질 수 있다. 이것은 쿠버네티스
|
|
구성요소 (특히 마스터 컨트롤 플레인)의 성능에 영향을 미쳤고
|
|
엔드포인트가 변경될 때 상당한 양의 네트워크 트래픽과 처리를 초래했다.
|
|
엔드포인트슬라이스는 이러한 문제를 완화하고 토폴로지 라우팅과
|
|
같은 추가 기능을 위한 확장 가능한 플랫폼을 제공한다.
|
|
|
|
## 엔드포인트슬라이스 리소스 {#endpointslice-resource}
|
|
|
|
쿠버네티스에서 엔드포인트슬라이스는 일련의 네트워크 엔드포인트에 대한
|
|
참조를 포함한다. 쿠버네티스 서비스에 {{< glossary_tooltip text="셀렉터"
|
|
term_id="selector" >}}가 지정되면 컨트롤 플레인은 자동으로
|
|
엔드포인트슬라이스를 생성한다. 이 엔드포인트슬라이스는
|
|
서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트슬라이스는
|
|
프로토콜, 포트 번호 및 서비스 이름의 고유한 조합을 통해 네트워크 엔드포인트를
|
|
그룹화한다.
|
|
엔드포인트슬라이스 오브젝트의 이름은 유효한
|
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
|
|
|
|
예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 엔드포인트슬라이스
|
|
리소스 샘플이 있다.
|
|
|
|
```yaml
|
|
apiVersion: discovery.k8s.io/v1beta1
|
|
kind: EndpointSlice
|
|
metadata:
|
|
name: example-abc
|
|
labels:
|
|
kubernetes.io/service-name: example
|
|
addressType: IPv4
|
|
ports:
|
|
- name: http
|
|
protocol: TCP
|
|
port: 80
|
|
endpoints:
|
|
- addresses:
|
|
- "10.1.2.3"
|
|
conditions:
|
|
ready: true
|
|
hostname: pod-1
|
|
topology:
|
|
kubernetes.io/hostname: node-1
|
|
topology.kubernetes.io/zone: us-west2-a
|
|
```
|
|
|
|
기본적으로, 컨트롤 플레인은 각각 100개 이하의 엔드포인트를
|
|
갖도록 엔드포인트슬라이스를 생성하고 관리한다. `--max-endpoints-per-slice`
|
|
{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
|
|
플래그를 사용하여, 최대 1000개까지 구성할 수 있다.
|
|
|
|
엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해
|
|
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}에
|
|
신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는
|
|
서비스에 대해 성능 향상을 제공해야 한다.
|
|
|
|
### 주소 유형
|
|
|
|
엔드포인트슬라이스는 다음 주소 유형을 지원한다.
|
|
|
|
* IPv4
|
|
* IPv6
|
|
* FQDN (전체 주소 도메인 이름)
|
|
|
|
### 토폴로지 정보 {#토폴로지}
|
|
|
|
엔드포인트슬라이스 내 각 엔드포인트는 연관된 토폴로지 정보를 포함할 수 있다.
|
|
이는 해당 노드, 영역 그리고 지역에 대한 정보가 포함된
|
|
엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면,
|
|
컨트롤 플레인은 엔드포인트슬라이스에 대해 다음의 토폴로지 레이블을 설정한다.
|
|
|
|
* `kubernetes.io/hostname` - 이 엔드포인트가 있는 노드의 이름.
|
|
* `topology.kubernetes.io/zone` - 이 엔드포인트가 있는 영역의 이름.
|
|
* `topology.kubernetes.io/region` - 이 엔드포인트가 있는 지역의 이름.
|
|
|
|
이런 레이블 값은 슬라이스의 각 엔드포인트와 연관된 리소스에서
|
|
파생된다. 호스트 이름 레이블은 해당 파드의
|
|
NodeName 필드 값을 나타낸다. 영역 및 지역 레이블은 해당
|
|
노드에서 이름이 같은 값을 나타낸다.
|
|
|
|
### 관리
|
|
|
|
대부분의 경우, 컨트롤 플레인(특히, 엔드포인트 슬라이스
|
|
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}})는
|
|
엔드포인트슬라이스 오브젝트를 생성하고 관리한다. 다른 엔티티나 컨트롤러가 추가
|
|
엔드포인트슬라이스 집합을 관리하게 할 수 있는 서비스 메시 구현과 같이
|
|
엔드포인트슬라이스에 대한 다양한 다른 유스케이스가 있다.
|
|
|
|
여러 엔티티가 서로 간섭하지 않고 엔드포인트슬라이스를
|
|
관리할 수 있도록 쿠버네티스는 엔드포인트슬라이스를 관리하는
|
|
엔티티를 나타내는 `endpointslice.kubernetes.io/managed-by`
|
|
{{< glossary_tooltip term_id="label" text="레이블" >}}을
|
|
정의한다.
|
|
엔드포인트 슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로
|
|
`endpointslice-controller.k8s.io` 를 설정한다. 엔드포인트슬라이스를
|
|
관리하는 다른 엔티티도 이 레이블에 고유한 값을 설정해야 한다.
|
|
|
|
### 소유권
|
|
|
|
대부분의 유스케이스에서, 엔드포인트 슬라이스 오브젝트가 엔드포인트를
|
|
추적하는 서비스가 엔드포인트슬라이스를 소유한다. 이 소유권은 각 엔드포인트슬라이스의 소유자
|
|
참조와 서비스에 속한 모든 엔드포인트슬라이스의 간단한 조회를 가능하게 하는
|
|
`kubernetes.io/service-name` 레이블로 표시된다.
|
|
|
|
### 엔드포인트슬라이스 미러링
|
|
|
|
경우에 따라, 애플리케이션이 사용자 지정 엔드포인트 리소스를 생성한다. 이러한
|
|
애플리케이션이 엔드포인트와 엔드포인트슬라이스 리소스에 동시에 쓸 필요가 없도록
|
|
클러스터의 컨트롤 플레인은 대부분의 엔드포인트 리소스를
|
|
해당 엔드포인트슬라이스에 미러링한다.
|
|
|
|
컨트롤 플레인은 다음을 제외하고 엔드포인트 리소스를 미러링한다.
|
|
|
|
* 엔드포인트 리소스에는 `endpointslice.kubernetes.io/skip-mirror` 레이블이
|
|
`true` 로 설정되어 있다.
|
|
* 엔드포인트 리소스에는 `control-plane.alpha.kubernetes.io/leader`
|
|
어노테이션이 있다.
|
|
* 해당 서비스 리소스가 존재하지 않는다.
|
|
* 해당 서비스 리소스에 nil이 아닌 셀렉터가 있다.
|
|
|
|
개별 엔드포인트 리소스는 여러 엔드포인트슬라이스로 변환될 수 있다.
|
|
엔드포인트 리소스에 여러 하위 집합이 있거나 여러 IP 제품군(IPv4 및 IPv6)이 있는
|
|
엔드포인트가 포함된 경우 변환이 일어난다. 하위 집합 당 최대 1000개의 주소가
|
|
엔드포인트슬라이스에 미러링된다.
|
|
|
|
### 엔드포인트슬라이스의 배포
|
|
|
|
각 엔드포인트슬라이스에는 리소스 내에 모든 엔드포인트가 적용되는
|
|
포트 집합이 있다. 서비스에 알려진 포트를 사용하는 경우 파드는
|
|
동일하게 알려진 포트에 대해 다른 대상 포트 번호로 끝날 수 있으며 다른
|
|
엔드포인트슬라이스가 필요하다. 이는 하위 집합이 엔드포인트와 그룹화하는
|
|
방식의 논리와 유사하다.
|
|
|
|
컨트롤 플레인은 엔드포인트슬라이스를 최대한 채우려고 노력하지만,
|
|
적극적으로 재조정하지는 않는다. 로직은 매우 직관적이다.
|
|
|
|
1. 기존 엔드포인트슬라이스에 대해 반복적으로, 더 이상 필요하지 않는 엔드포인트를
|
|
제거하고 변경에 의해 일치하는 엔드포인트를 업데이트 한다.
|
|
2. 첫 번째 단계에서 수정된 엔드포인트슬라이스를 반복해서
|
|
필요한 새 엔드포인트로 채운다.
|
|
3. 추가할 새 엔드포인트가 여전히 남아있으면, 이전에 변경되지 않은
|
|
슬라이스에 엔드포인트를 맞추거나 새로운 것을 생성한다.
|
|
|
|
중요한 것은, 세 번째 단계는 엔드포인트슬라이스를 완벽하게 전부 배포하는 것보다
|
|
엔드포인트슬라이스 업데이트 제한을 우선시한다. 예를 들어, 추가할 새 엔드포인트가
|
|
10개이고 각각 5개의 공간을 사용할 수 있는 엔드포인트 공간이 있는 2개의
|
|
엔드포인트슬라이스가 있는 경우, 이 방법은 기존 엔드포인트슬라이스
|
|
2개를 채우는 대신에 새 엔드포인트슬라이스를 생성한다. 다른 말로, 단일
|
|
엔드포인트슬라이스를 생성하는 것이 여러 엔드포인트슬라이스를 업데이트하는 것 보다 더 선호된다.
|
|
|
|
각 노드에서 kube-proxy를 실행하고 엔드포인트슬라이스를 관찰하면,
|
|
엔드포인트슬라이스에 대한 모든 변경 사항이 클러스터의 모든 노드로 전송되기
|
|
때문에 상대적으로 비용이 많이 소요된다. 이 방법은 여러 엔드포인트슬라이스가
|
|
가득 차지 않은 결과가 발생할지라도, 모든 노드에 전송해야 하는
|
|
변경 횟수를 의도적으로 제한하기 위한 것이다.
|
|
|
|
실제로는, 이러한 이상적이지 않은 분배는 드물 것이다. 엔드포인트슬라이스
|
|
컨트롤러에서 처리하는 대부분의 변경 내용은 기존 엔드포인트슬라이스에
|
|
적합할 정도로 적고, 그렇지 않은 경우 새 엔드포인트슬라이스가
|
|
필요할 수 있다. 디플로이먼트의 롤링 업데이트도 모든 파드와 해당
|
|
교체되는 엔드포인트에 대해서 엔드포인트슬라이스를
|
|
자연스럽게 재포장한다.
|
|
|
|
### 중복 엔드포인트
|
|
|
|
엔드포인트슬라이스 변경의 특성으로 인해, 엔드포인트는 동시에 둘 이상의
|
|
엔드포인트슬라이스에 표시될 수 있다. 이는 다른 엔드포인트슬라이스 오브젝트에
|
|
대한 변경 사항이 다른 시간에서의 쿠버네티스 클라이언트 워치(watch)/캐시에
|
|
도착할 수 있기 때문에 자연스럽게 발생한다. 엔드포인트슬라이스를 사용하는 구현은
|
|
엔드포인트가 둘 이상의 슬라이스에 표시되도록 할 수 있어야 한다. 엔드포인트
|
|
중복 제거를 수행하는 방법에 대한 레퍼런스 구현은 `kube-proxy` 의
|
|
`EndpointSliceCache` 구현에서 찾을 수 있다.
|
|
|
|
## {{% heading "whatsnext" %}}
|
|
|
|
* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)에 대해 배우기
|
|
* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
|