whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

First Korean l10n work for release-1.19

Browse Source 
- Translate tasks/job/parallel-processing-expansion.md into Korean (#23544)
- Fix issue with ko/docs/concepts/workloads/controllers/job.md (#23720)
- Translate reference/scheduling/policies.md in Korean (#23690)
- Update outdated files in the dev-1.19-ko.1 branch (#23702)
- Modify translation access by Korean glossary (#23627)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: junghyeonsu <54893898+junghyeonsu@users.noreply.github.com>
Co-authored-by: coolguyhong <podolsmith@naver.com>
This commit is contained in:
June Yi
2020-09-11 23:21:22 +09:00
parent 94b2f857bb
commit 986be3462d
102 changed files with 1943 additions and 2452 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/services-networking/dns-pod-service.md
+19 -1
View File
@@ -163,6 +163,24 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac
또한 서비스에서 `publishNotReadyAddresses=True` 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다.
{{< /note >}}
### 파드의 setHostnameAsFQDN 필드 {# pod-sethostnameasfqdn-field}
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
**전제 조건**: `SetHostnameAsFQDN` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에
대해 활성화해야 한다.
파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우, 해당 호스트네임은 짧은 호스트네임이다. 예를 들어, 전체 주소 도메인 이름이 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` 인 파드가 있는 경우, 기본적으로 해당 파드 내부의 `hostname` 명령어는 `busybox-1` 을 반환하고 `hostname --fqdn` 명령은 FQDN을 반환한다.
파드 명세에서 `setHostnameAsFQDN: true` 를 설정하면, kubelet은 파드의 FQDN을 해당 파드 네임스페이스의 호스트네임에 기록한다. 이 경우, `hostname` 과 `hostname --fqdn` 은 모두 파드의 FQDN을 반환한다.
{{< note >}}
리눅스에서, 커널의 호스트네임 필드(`struct utsname` 의 `nodename` 필드)는 64자로 제한된다.
파드에서 이 기능을 사용하도록 설정하고 FQDN이 64자보다 길면, 시작되지 않는다. 파드는 파드 호스트네임과 클러스터 도메인에서 FQDN을 구성하지 못한다거나, FQDN `long-FDQN` 이 너무 길다(최대 64자, 70자 요청인 경우)와 같은 오류 이벤트를 생성하는 `Pending` 상태(`kubectl` 에서 표시하는 `ContainerCreating`)로 유지된다. 이 시나리오에서 사용자 경험을 개선하는 한 가지 방법은 사용자가 최상위 레벨을 오브젝트(예를 들어, 디플로이먼트)를 생성할 때 FQDN 크기를 제어하기 위해 [어드미션 웹훅 컨트롤러](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)를 생성하는 것이다.
{{< /note >}}
### 파드의 DNS 정책
DNS 정책은 파드별로 설정할 수 있다.
@@ -188,7 +206,7 @@ DNS 정책은 파드별로 설정할 수 있다.
{{< note >}}
"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면
“ClusterFirst”가 기본값으로 사용된다.
"ClusterFirst"가 기본값으로 사용된다.
{{< /note >}}
content/ko/docs/concepts/services-networking/endpoint-slices.md
+68 -45
View File
@@ -1,7 +1,7 @@
---
title: 엔드포인트슬라이스
content_type: concept
weight: 15
weight: 35
---
@@ -21,7 +21,9 @@ _엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워
엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
간단하고 직접적인 방법을 제공한다. 불행하게도 쿠버네티스 클러스터와
서비스가 점점 더 커짐에 따라, 이 API의 한계가 더욱 눈에 띄게 되었다.
{{< glossary_tooltip text="서비스" term_id="service" >}}가 점점 더
커짐에 따라, 이 API의 한계가 더욱 눈에 띄게
되었다.
특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에
어려움이 있었다.
@@ -34,16 +36,17 @@ _엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워
## 엔드포인트슬라이스 리소스 {#endpointslice-resource}
쿠버네티스에서 EndpointSlice는 일련의 네트워크 엔드 포인트에 대한
쿠버네티스에서 엔드포인트슬라이스는 일련의 네트워크 엔드포인트에 대한
참조를 포함한다. 쿠버네티스 서비스에 {{< glossary_tooltip text="셀렉터"
term_id="selector" >}} 가 지정되면 EndpointSlice
컨트롤러는 자동으로 엔드포인트슬라이스를 생성한다. 이 엔드포인트슬라이스는
term_id="selector" >}}가 지정되면 컨트롤 플레인은 자동으로
엔드포인트슬라이스를 생성한다. 이 엔드포인트슬라이스는
서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트슬라이스는
고유한 서비스와 포트 조합을 통해 네트워크 엔드포인트를 그룹화 한다.
EndpointSlice 오브젝트의 이름은 유효한
프로토콜, 포트 번호 및 서비스 이름의 고유한 조합을 통해 네트워크 엔드포인트를
그룹화한다.
엔드포인트슬라이스 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 EndpointSlice
예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 엔드포인트슬라이스
리소스 샘플이 있다.
```yaml
@@ -69,28 +72,30 @@ endpoints:
topology.kubernetes.io/zone: us-west2-a
```
기본적으로, EndpointSlice 컨트롤러가 관리하는 엔드포인트슬라이스에는
각각 100개 이하의 엔드포인트를 가지고 있다. 이 스케일 아래에서 엔드포인트슬라이스는
엔드포인트 및 서비스와 1:1로 매핑해야하며, 유사한 성능을 가져야 한다.
기본적으로, 컨트롤 플레인은 각각 100개 이하의 엔드포인트를
갖도록 엔드포인트슬라이스를 생성하고 관리한다. `--max-endpoints-per-slice`
{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
플래그를 사용하여, 최대 1000개까지 구성할 수 있다.
엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해 kube-proxy에
엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}에
신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는
서비스에 대해 성능 향상을 제공해야 한다.
### 주소 유형
EndpointSlice는 다음 주소 유형을 지원한다.
엔드포인트슬라이스는 다음 주소 유형을 지원한다.
* IPv4
* IPv6
* FQDN (Fully Qualified Domain Name)
* FQDN (전체 주소 도메인 이름)
### 토폴로지
### 토폴로지 정보 {#토폴로지}
엔드포인트슬라이스 내 각 엔드포인트는 연관된 토폴로지 정보를 포함할 수 있다.
이는 해당 노드, 영역 그리고 지역에 대한 정보가 포함된
엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면
다음의 토폴로지 레이블이 엔드포인트슬라이스 컨트롤러에 의해 설정된다.
엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면,
컨트롤 플레인은 엔드포인트슬라이스에 대해 다음의 토폴로지 레이블을 설정한다.
* `kubernetes.io/hostname` - 이 엔드포인트가 있는 노드의 이름.
* `topology.kubernetes.io/zone` - 이 엔드포인트가 있는 영역의 이름.
@@ -103,37 +108,48 @@ NodeName 필드 값을 나타낸다. 영역 및 지역 레이블은 해당
### 관리
기본적으로 엔드포인트슬라이스는 엔드포인트슬라이스 컨트롤러에의해
생성되고 관리된다. 서비스 메시 구현과 같은 다른 엔드포인트슬라이스
유스 케이스는 다른 엔터티나 컨트롤러가 추가 엔드포인트슬라이스
집합을 관리할 수 있게 할 수 있다. 여러 엔티티가 서로 간섭하지 않고
엔드포인트슬라이스를 관리할 수 있도록 엔드포인트슬라이스를 관리하는
엔티티를 나타내는데 `endpointslice.kubernetes.io/managed-by` 레이블이 사용된다.
엔드포인트슬라이스 컨트롤러는 관리하는 모든 엔드포인트
슬라이스에 레이블의 값으로 `endpointslice-controller.k8s.io` 를 설정한다.
엔드포인트슬라이스를 관리하는 다른 엔티티도 이 레이블에
고유한 값을 설정해야 한다.
대부분의 경우, 컨트롤 플레인(특히, 엔드포인트 슬라이스
{{< 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`
레이블로 표시된다.
대부분의 유스케이스에서, 엔드포인트 슬라이스 오브젝트가 엔드포인트를
추적하는 서비스가 엔드포인트슬라이스를 소유한다. 이 소유권은 각 엔드포인트슬라이스의 소유자
참조와 서비스에 속한 모든 엔드포인트슬라이스의 간단한 조회를 가능하게 하는
`kubernetes.io/service-name` 레이블로 표시된다.
## 엔드포인트슬라이스 컨트롤러
### 엔드포인트슬라이스 미러링
엔드포인트슬라이스 컨트롤러는 해당 엔드포인트슬라이스가 최신 상태인지
확인하기 위해 서비스와 파드를 감시한다. 컨트롤러가 셀렉터로 지정한 모든
서비스에 대해 엔드포인트슬라이스를 관리한다. 이는 서비스 셀렉터와
일치하는 파드의 IP를 나타내게 된다.
경우에 따라, 애플리케이션이 사용자 지정 엔드포인트 리소스를 생성한다. 이러한
애플리케이션이 엔드포인트와 엔드포인트슬라이스 리소스에 동시에 쓸 필요가 없도록
클러스터의 컨트롤 플레인은 대부분의 엔드포인트 리소스를
해당 엔드포인트슬라이스에 미러링한다.
### 엔드포인트슬라이스의 크기
컨트롤 플레인은 다음을 제외하고 엔드포인트 리소스를 미러링한다.
기본적으로 엔드포인트슬라이스는 각각 100개의 엔드포인트 크기로 제한된다.
최대 1000개까지 `--max-endpoints-per-slice` {{< glossary_tooltip
text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그를
사용해서 구성할 수 있다.
* 엔드포인트 리소스에는 `endpointslice.kubernetes.io/skip-mirror` 레이블이
`true` 로 설정되어 있다.
* 엔드포인트 리소스에는 `control-plane.alpha.kubernetes.io/leader`
어노테이션이 있다.
* 해당 서비스 리소스가 존재하지 않는다.
* 해당 서비스 리소스에 nil이 아닌 셀렉터가 있다.
개별 엔드포인트 리소스는 여러 엔드포인트슬라이스로 변환될 수 있다.
엔드포인트 리소스에 여러 하위 집합이 있거나 여러 IP 제품군(IPv4 및 IPv6)이 있는
엔드포인트가 포함된 경우 변환이 일어난다. 하위 집합 당 최대 1000개의 주소가
엔드포인트슬라이스에 미러링된다.
### 엔드포인트슬라이스의 배포
@@ -143,8 +159,8 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그
엔드포인트슬라이스가 필요하다. 이는 하위 집합이 엔드포인트와 그룹화하는
방식의 논리와 유사하다.
컨트롤러는 엔드포인트슬라이스를 최대한 채우려고 노력하지만,
적극적으로 재조정하지는 않는다. 컨트롤러의 동작은 매우 직관적이다.
컨트롤 플레인은 엔드포인트슬라이스를 최대한 채우려고 노력하지만,
적극적으로 재조정하지는 않는다. 로직은 매우 직관적이다.
1. 기존 엔드포인트슬라이스에 대해 반복적으로, 더 이상 필요하지 않는 엔드포인트를
제거하고 변경에 의해 일치하는 엔드포인트를 업데이트 한다.
@@ -173,10 +189,17 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그
교체되는 엔드포인트에 대해서 엔드포인트슬라이스를
자연스럽게 재포장한다.
### 중복 엔드포인트
엔드포인트슬라이스 변경의 특성으로 인해, 엔드포인트는 동시에 둘 이상의
엔드포인트슬라이스에 표시될 수 있다. 이는 다른 엔드포인트슬라이스 오브젝트에
대한 변경 사항이 다른 시간에서의 쿠버네티스 클라이언트 워치(watch)/캐시에
도착할 수 있기 때문에 자연스럽게 발생한다. 엔드포인트슬라이스를 사용하는 구현은
엔드포인트가 둘 이상의 슬라이스에 표시되도록 할 수 있어야 한다. 엔드포인트
중복 제거를 수행하는 방법에 대한 레퍼런스 구현은 `kube-proxy` 의
`EndpointSliceCache` 구현에서 찾을 수 있다.
## {{% heading "whatsnext" %}}
* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)
* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)에 대해 배우기
* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
content/ko/docs/concepts/services-networking/ingress.md
+127 -166
View File
@@ -5,7 +5,7 @@ weight: 40
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.1" state="beta" >}}
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
{{< glossary_definition term_id="ingress" length="all" >}}
@@ -23,7 +23,7 @@ weight: 40
## 인그레스란?
[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부
[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부
{{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.
@@ -59,23 +59,7 @@ weight: 40
최소한의 인그레스 리소스 예제:
```yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: test-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
paths:
- path: /testpath
pathType: Prefix
backend:
serviceName: test
servicePort: 80
```
{{< codenew file="service/networking/minimal-ingress.yaml" >}}
다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다.
인그레스 오브젝트의 이름은 유효한
@@ -98,44 +82,100 @@ spec:
* 선택적 호스트. 이 예시에서는, 호스트가 지정되지 않기에 지정된 IP 주소를 통해 모든 인바운드
HTTP 트래픽에 규칙이 적용 된다. 만약 호스트가 제공되면(예,
foo.bar.com), 규칙이 해당 호스트에 적용된다.
* 경로 목록 (예, `/testpath`)에는 각각 `serviceName` 과 `servicePort` 가 정의되어있는 관련
백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로 보내기 전에 호스트와 경로가
모두 수신 요청의 내용과 일치해야 한다.
* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/)에 설명된 바와 같이
* 경로 목록 (예, `/testpath`)에는 각각 `service.name` 과
`service.port.name` 또는 `service.port.number` 가 정의되어 있는 관련
백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로
보내기 전에 호스트와 경로가 모두 수신 요청의 내용과
일치해야 한다.
* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/) 또는 [사용자 정의 리소스 백엔드](#resource-backend)에 설명된 바와 같이
서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한
HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다.
기본 백엔드는 종종 사양의 경로와 일치하지 않는 서비스에 대한 모든 요청을 처리하도록 인그레스
`defaultBackend` 는 종종 사양의 경로와 일치하지 않는 서비스에 대한 모든 요청을 처리하도록 인그레스
컨트롤러에 구성되는 경우가 많다.
### 기본 벡엔드
### DefaultBackend {#default-backend}
규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. 기본
백엔드는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. `defaultBackend` 는 일반적으로
[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
기본 백엔드로 라우팅 된다.
### 경로(Path) 유형
### 리소스 백엔드 {#resource-backend}
인그레스의 각 경로에는 해당하는 경로 유형이 있다. 지원되는 세 가지의 경로
유형이 있다.
`Resource` 백엔드는 인그레스 오브젝트의 동일한 네임스페이스 내에 있는
다른 쿠버네티스 리소스에 대한 ObjectRef이다. `Resource` 는 서비스와
상호 배타적인 설정이며, 둘 다 지정하면 유효성 검사에 실패한다. `Resource`
백엔드의 일반적인 용도는 정적 자산이 있는 오브젝트 스토리지 백엔드로 데이터를
수신하는 것이다.
* _`ImplementationSpecific`_ (기본): 이 경로 유형의 일치 여부는 IngressClass에 따라
{{< codenew file="service/networking/ingress-resource-backend.yaml" >}}
위의 인그레스를 생성한 후, 다음의 명령으로 확인할 수 있다.
```bash
kubectl describe ingress ingress-resource-backend
```
```
Name: ingress-resource-backend
Namespace: default
Address:
Default backend: APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
Rules:
Host Path Backends
---- ---- --------
*
/icons APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
Annotations: <none>
Events: <none>
```
### 경로 유형
인그레스의 각 경로에는 해당 경로 유형이 있어야 한다. 명시적
`pathType` 을 포함하지 않는 경로는 유효성 검사에 실패한다. 지원되는
경로 유형은 세 가지이다.
* `ImplementationSpecific`: 이 경로 유형의 일치 여부는 IngressClass에 따라
달라진다. 이를 구현할 때 별도 `pathType` 으로 처리하거나, `Prefix` 또는 `Exact`
경로 유형과 같이 동일하게 처리할 수 있다.
* _`Exact`_: URL 경로의 대소문자를 엄격하게 일치시킨다.
* `Exact`: URL 경로의 대소문자를 엄격하게 일치시킨다.
* _`Prefix`_: URL 경로의 접두사를 `/` 를 기준으로 분리한 값과 일치시킨다.
* `Prefix`: URL 경로의 접두사를 `/` 를 기준으로 분리한 값과 일치시킨다.
일치는 대소문자를 구분하고,
요소별로 경로 요소에 대해 수행한다.
모든 _p_ 가 요청 경로의 요소별 접두사가 _p_ 인 경우
요청은 _p_ 경로에 일치한다.
{{< note >}}
경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다).
{{< /note >}}
{{< note >}} 경로의 마지막 요소가 요청 경로에 있는 마지막
요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와
`/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). {{< /note >}}
### 예제
| 종류 | 경로 | 요청 경로 | 일치 여부 |
|--------|---------------------------------|-------------------------------|------------------------------------|
| Prefix | `/` | (모든 경로) | 예 |
| Exact | `/foo` | `/foo` | 예 |
| Exact | `/foo` | `/bar` | 아니오 |
| Exact | `/foo` | `/foo/` | 아니오 |
| Exact | `/foo/` | `/foo` | 아니오 |
| Prefix | `/foo` | `/foo`, `/foo/` | 예 |
| Prefix | `/foo/` | `/foo`, `/foo/` | 예 |
| Prefix | `/aaa/bb` | `/aaa/bbb` | 아니오 |
| Prefix | `/aaa/bbb` | `/aaa/bbb` | 예 |
| Prefix | `/aaa/bbb/` | `/aaa/bbb` | 예, 마지막 슬래시 무시함 |
| Prefix | `/aaa/bbb` | `/aaa/bbb/` | 예, 마지막 슬래시 일치함 |
| Prefix | `/aaa/bbb` | `/aaa/bbb/ccc` | 예, 하위 경로 일치함 |
| Prefix | `/aaa/bbb` | `/aaa/bbbxyz` | 아니오, 문자열 접두사 일치하지 않음 |
| Prefix | `/`, `/aaa` | `/aaa/ccc` | 예, `/aaa` 접두사 일치함 |
| Prefix | `/`, `/aaa`, `/aaa/bbb` | `/aaa/bbb` | 예, `/aaa/bbb` 접두사 일치함 |
| Prefix | `/`, `/aaa`, `/aaa/bbb` | `/ccc` | 예, `/` 접두사 일치함 |
| Prefix | `/aaa` | `/ccc` | 아니오, 기본 백엔드 사용함 |
| Mixed | `/foo` (Prefix), `/foo` (Exact) | `/foo` | 예, Exact 선호함 |
#### 다중 일치
경우에 따라 인그레스의 여러 경로가 요청과 일치할 수 있다.
@@ -143,6 +183,20 @@ spec:
여전히 동일하게 일치하는 경우 접두사(prefix) 경로 유형보다
정확한(exact) 경로 유형을 가진 경로가 사용 된다.
## 호스트네임 와일드카드
호스트는 정확한 일치(예: "`foo.bar.com`") 또는 와일드카드(예:
"`* .foo.com`")일 수 있다. 정확한 일치를 위해서는 HTTP `host` 헤더가
`host` 필드와 일치해야 한다. 와일드카드 일치를 위해서는 HTTP `host` 헤더가
와일드카드 규칙의 접미사와 동일해야 한다.
| 호스트 | 호스트 헤더 | 일치 여부 |
| ----------- |-------------------| --------------------------------------------------|
| `*.foo.com` | `bar.foo.com` | 공유 접미사를 기반으로 일치함 |
| `*.foo.com` | `baz.bar.foo.com` | 일치하지 않음, 와일드카드는 단일 DNS 레이블만 포함함 |
| `*.foo.com` | `foo.com` | 일치하지 않음, 와일드카드는 단일 DNS 레이블만 포함함 |
{{< codenew file="service/networking/ingress-wildcard-host.yaml" >}}
## 인그레스 클래스
인그레스는 서로 다른 컨트롤러에 의해 구현될 수 있으며, 종종 다른 구성으로
@@ -150,18 +204,7 @@ spec:
이름을 포함하여 추가 구성이 포함된 IngressClass
리소스에 대한 참조 클래스를 지정해야 한다.
```yaml
apiVersion: networking.k8s.io/v1beta1
kind: IngressClass
metadata:
name: external-lb
spec:
controller: example.com/ingress-controller
parameters:
apiGroup: k8s.example.com/v1alpha
kind: IngressParameters
name: external-lb
```
{{< codenew file="service/networking/external-lb.yaml" >}}
IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한
추가 구성을 참조하는데 사용할 수 있다.
@@ -179,7 +222,7 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클
이 필드는 인그레스 컨트롤러의 이름을 포함하는 추가 인그레스 구성이
포함된 인그레스 클래스 리소스에 대한 참조이다.
### 기본 인그레스 클래스
### 기본 IngressClass {#default-ingress-class}
특정 IngressClass를 클러스터의 기본 값으로 표시할 수 있다. IngressClass
리소스에서 `ingressclass.kubernetes.io/is-default-class` 를 `true` 로
@@ -195,24 +238,24 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클
## 인그레스 유형들
### 단일 서비스 인그레스
### 단일 서비스로 지원되는 인그레스 {#single-service-ingress}
단일 서비스를 노출할 수 있는 기존 쿠버네티스 개념이 있다
([대안](#대안)을 본다). 인그레스에 규칙 없이 *기본 백엔드* 를 지정해서
이를 수행할 수 있다.
{{< codenew file="service/networking/ingress.yaml" >}}
{{< codenew file="service/networking/test-ingress.yaml" >}}
만약 `kubectl apply -f` 를 사용해서 생성한다면 방금 추가한 인그레스의
상태를 볼 수 있어야 한다.
```shell
```bash
kubectl get ingress test-ingress
```
```
NAME HOSTS ADDRESS PORTS AGE
test-ingress * 203.0.113.123 80 59s
NAME CLASS HOSTS ADDRESS PORTS AGE
test-ingress external-lb * 203.0.113.123 80 59s
```
여기서 `203.0.113.123` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해
@@ -229,34 +272,14 @@ test-ingress * 203.0.113.123 80 59s
트래픽을 라우팅 한다. 인그레스를 사용하면 로드 밸런서의 수를
최소로 유지할 수 있다. 예를 들어 다음과 같은 설정을 한다.
```none
```
foo.bar.com -> 178.91.123.132 -> / foo service1:4200
/ bar service2:8080
```
다음과 같은 인그레스가 필요하다.
```yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: simple-fanout-example
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: foo.bar.com
http:
paths:
- path: /foo
backend:
serviceName: service1
servicePort: 4200
- path: /bar
backend:
serviceName: service2
servicePort: 8080
```
{{< codenew file="service/networking/simple-fanout-example.yaml" >}}
`kubectl apply -f` 를 사용해서 인그레스를 생성 할 때 다음과 같다.
@@ -275,8 +298,6 @@ Rules:
foo.bar.com
/foo service1:4200 (10.8.0.90:4200)
/bar service2:8080 (10.8.0.91:8080)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
@@ -289,8 +310,8 @@ Events:
볼 수 있다.
{{< note >}}
사용중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)
에 따라 default-http-backend
사용 중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에
따라 default-http-backend
[서비스](/ko/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다.
{{< /note >}}
@@ -307,68 +328,26 @@ bar.foo.com --| |-> bar.foo.com service2:80
다음 인그레스는 [호스트 헤더](https://tools.ietf.org/html/rfc7230#section-5.4)에 기반한 요청을
라우팅 하기 위해 뒷단의 로드 밸런서를 알려준다.
```yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: name-virtual-host-ingress
spec:
rules:
- host: foo.bar.com
http:
paths:
- backend:
serviceName: service1
servicePort: 80
- host: bar.foo.com
http:
paths:
- backend:
serviceName: service2
servicePort: 80
```
{{< codenew file="service/networking/name-virtual-host-ingress.yaml" >}}
만약 규칙에 정의된 호스트 없이 인그레스 리소스를 생성하는 경우,
이름 기반 가상 호스트가 없어도 인그레스 컨트롤러의 IP 주소에 대한 웹
트래픽을 일치 시킬 수 있다.
예를 들어, 다음 인그레스 리소스는 `first.bar.com`에 요청된 트래픽을
예를 들어, 다음 인그레스는 `first.bar.com`에 요청된 트래픽을
`service1`로, `second.foo.com`는 `service2`로, 호스트 이름이 정의되지
않은(즉, 요청 헤더가 표시 되지 않는) IP 주소로의 모든
트래픽은 `service3`로 라우팅 한다.
```yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: name-virtual-host-ingress
spec:
rules:
- host: first.bar.com
http:
paths:
- backend:
serviceName: service1
servicePort: 80
- host: second.foo.com
http:
paths:
- backend:
serviceName: service2
servicePort: 80
- http:
paths:
- backend:
serviceName: service3
servicePort: 80
```
{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}}
### TLS
TLS 개인 키 및 인증서가 포함된 {{< glossary_tooltip term_id="secret" >}}
을 지정해서 인그레스를 보호할 수 있다. 현재 인그레스는
단일 TLS 포트인 443만 지원하며 TLS 종료를 가정한다. 만약 인그레스의 TLS
구성 섹션에서 다른 호스트를 지정하면, SNI TLS 확장을 통해
TLS 개인 키 및 인증서가 포함된 {{< glossary_tooltip term_id="secret" >}}을
지정해서 인그레스를 보호할 수 있다. 인그레스 리소스는
단일 TLS 포트인 443만 지원하고 인그레스 지점에서 TLS 종료를
가정한다(서비스 및 해당 파드에 대한 트래픽은 일반 텍스트임).
인그레스의 TLS 구성 섹션에서 다른 호스트를 지정하면, SNI TLS 확장을 통해
지정된 호스트이름에 따라 동일한 포트에서 멀티플렉싱
된다(인그레스 컨트롤러가 SNI를 지원하는 경우). TLS secret에는
`tls.crt` 와 `tls.key` 라는 이름의 키가 있어야 하고, 여기에는 TLS에 사용할 인증서와
@@ -391,25 +370,7 @@ type: kubernetes.io/tls
TLS 시크릿이 `sslexample.foo.com` 의 정규화 된 도메인 이름(FQDN)이라고
하는 일반 이름(CN)을 포함하는 인증서에서 온 것인지 확인해야 한다.
```yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: tls-example-ingress
spec:
tls:
- hosts:
- sslexample.foo.com
secretName: testsecret-tls
rules:
- host: sslexample.foo.com
http:
paths:
- path: /
backend:
serviceName: service1
servicePort: 80
```
{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
{{< note >}}
TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능
@@ -419,7 +380,7 @@ TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능
플랫폼의 특정 인그레스 컨트롤러에 대한 설명서를 참조한다.
{{< /note >}}
### 로드밸런싱
### 로드 밸런싱 {#load-balancing}
인그레스 컨트롤러는 로드 밸런싱 알고리즘, 백엔드 가중치 구성표 등
모든 인그레스에 적용되는 일부 로드 밸런싱
@@ -432,8 +393,8 @@ TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능
[준비 상태 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)와
같은 동일한 최종 결과를 얻을 수 있는 병렬 개념이
있다는 점도 주목할 가치가 있다. 컨트롤러 별
설명서를 검토하여 헬스 체크를 처리하는 방법을 확인한다(
[nginx](https://git.k8s.io/ingress-nginx/README.md),
설명서를 검토하여 헬스 체크를 처리하는 방법을 확인한다(예:
[nginx](https://git.k8s.io/ingress-nginx/README.md), 또는
[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)).
## 인그레스 업데이트
@@ -476,16 +437,22 @@ spec:
http:
paths:
- backend:
serviceName: service1
servicePort: 80
service:
name: service1
port:
number: 80
path: /foo
pathType: Prefix
- host: bar.baz.com
http:
paths:
- backend:
serviceName: service2
servicePort: 80
service:
name: service2
port:
number: 80
path: /foo
pathType: Prefix
..
```
@@ -523,15 +490,9 @@ Events:
## 가용성 영역에 전체에서의 실패
장애 도메인에 트래픽을 분산시키는 기술은 클라우드 공급자마다 다르다.
자세한 내용은 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. 페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)
를 참조할 수 있다.
## 앞으로의 할일
[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)
를 추적하여 인그레스와 진행중인 리소스의 발전에 대한 자세한 내용을 알아 본다. 다양한
인그레스 컨트롤러의 발전에 대한 자세한 내용은
[인그레스 리포지터리](https://github.com/kubernetes/ingress/tree/master)에서 추적할 수 있다.
자세한 내용은 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다.
페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)를
참조할 수 있다.
## 대안
@@ -546,4 +507,4 @@ Events:
* [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기
* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube)
* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube/)
content/ko/docs/concepts/services-networking/network-policies.md
+24 -5
View File
@@ -5,11 +5,18 @@ weight: 50
---
<!-- overview -->
네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다.
`네트워크폴리시(NetworkPolicy)` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.
IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. 네트워크폴리시는 {{< glossary_tooltip text="파드" term_id="pod" >}}가 네트워크 상의 다양한 네트워크 "엔티티"(여기서는 "엔티티"를 사용하여 쿠버네티스에서 특별한 의미로 사용되는 "엔드포인트" 및 "서비스"와 같은 일반적인 용어가 중의적으로 표현되는 것을 방지함)와 통신할 수 있도록 허용하는 방법을 지정할 수 있는 애플리케이션 중심 구조이다.
파드가 통신할 수 있는 엔티티는 다음 3개의 식별자 조합을 통해 식별된다.
1. 허용되는 다른 파드(예외: 파드는 자신에 대한 접근을 차단할 수 없음)
2. 허용되는 네임스페이스
3. IP 블록(예외: 파드 또는 노드의 IP 주소와 관계없이 파드가 실행 중인 노드와의 트래픽은 항상 허용됨)
pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 사용하여 셀렉터와 일치하는 파드와 주고받는 트래픽을 지정한다.
한편, IP 기반의 네트워크폴리시가 생성되면, IP 블록(CIDR 범위)을 기반으로 정책을 정의한다.
<!-- body -->
## 전제 조건
@@ -199,17 +206,29 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
## SCTP 지원
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다.
기능 게이트가 활셩화 되면, 네트워크폴리시의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.
베타 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
{{< note >}}
SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
{{< /note >}}
# 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)
쿠버네티스 1.20부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 가치가 있다. 이러한 사용자 스토리 중 일부(전부는 아님)가 네트워크폴리시 API의 향후 릴리스에서 활발히 논의되고 있다.
- 내부 클러스터 트래픽이 공통 게이트웨이를 통과하도록 강제한다(서비스 메시나 기타 프록시와 함께 제공하는 것이 가장 좋을 수 있음).
- TLS와 관련된 모든 것(이를 위해 서비스 메시나 인그레스 컨트롤러 사용).
- 노드별 정책(이에 대해 CIDR 표기법을 사용할 수 있지만, 특히 쿠버네티스 ID로 노드를 대상으로 지정할 수 없음).
- 이름으로 네임스페이스나 서비스를 타겟팅한다(그러나, {{< glossary_tooltip text="레이블" term_id="label" >}}로 파드나 네임스페이스를 타겟팅할 수 있으며, 이는 종종 실행할 수 있는 해결 방법임).
- 타사 공급사가 이행한 "정책 요청"의 생성 또는 관리.
- 모든 네임스페이스나 파드에 적용되는 기본 정책(이를 수행할 수 있는 타사 공급사의 쿠버네티스 배포본 및 프로젝트가 있음).
- 고급 정책 쿼리 및 도달 가능성 도구.
- 단일 정책 선언에서 포트 범위를 대상으로 하는 기능.
- 네트워크 보안 이벤트를 기록하는 기능(예: 차단되거나 수락된 연결).
- 명시적으로 정책을 거부하는 기능(현재 네트워크폴리시 모델은 기본적으로 거부하며, 허용 규칙을 추가하는 기능만 있음).
- 루프백 또는 들어오는 호스트 트래픽을 방지하는 기능(파드는 현재 로컬 호스트 접근을 차단할 수 없으며, 상주 노드의 접근을 차단할 수 있는 기능도 없음).
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/services-networking/service.md
+15 -13
View File
@@ -31,8 +31,8 @@ weight: 10
한 시점에 실행되는 파드 집합이
잠시 후 실행되는 해당 파드 집합과 다를 수 있다.
이는 다음과 같은 문제를 야기한다. (“백엔드”라 불리는) 일부 파드 집합이
클러스터의 (“프론트엔드”라 불리는) 다른 파드에 기능을 제공하는 경우,
이는 다음과 같은 문제를 야기한다. ("백엔드"라 불리는) 일부 파드 집합이
클러스터의 ("프론트엔드"라 불리는) 다른 파드에 기능을 제공하는 경우,
프론트엔드가 워크로드의 백엔드를 사용하기 위해,
프론트엔드가 어떻게 연결할 IP 주소를 찾아서 추적할 수 있는가?
@@ -89,7 +89,7 @@ spec:
targetPort: 9376
```
이 명세는 “my-service”라는 새로운 서비스 오브젝트를 생성하고,
이 명세는 "my-service"라는 새로운 서비스 오브젝트를 생성하고,
`app=MyApp` 레이블을 가진 파드의 TCP 9376 포트를 대상으로 한다.
쿠버네티스는 이 서비스에 서비스 프록시가 사용하는 IP 주소 ("cluster IP"라고도 함)
@@ -97,7 +97,7 @@ spec:
(이하 [가상 IP와 서비스 프록시](#가상-ip와-서비스-프록시) 참고)
서비스 셀렉터의 컨트롤러는 셀렉터와 일치하는 파드를 지속적으로 검색하고,
“my-service”라는 엔드포인트 오브젝트에 대한
"my-service"라는 엔드포인트 오브젝트에 대한
모든 업데이트를 POST한다.
{{< note >}}
@@ -200,14 +200,11 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만,
### 애플리케이션 프로토콜
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
AppProtocol 필드는 각 서비스 포트에 사용될 애플리케이션 프로토콜을
지정하는 방법을 제공한다.
알파 기능으로 이 필드는 기본적으로 활성화되어 있지 않다. 이 필드를 사용하려면,
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서
`ServiceAppProtocol` 을 활성화해야 한다.
지정하는 방법을 제공한다. 이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스에
의해 미러링된다.
## 가상 IP와 서비스 프록시
@@ -862,6 +859,7 @@ Classic ELB의 연결 드레이닝은
service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
# 개별 인스턴스의 상태 점검 사이의
# 대략적인 간격 (초 단위). 기본값은 10이며, 5와 300 사이여야 한다.
service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
# 헬스 체크 실패를 의미하는 무 응답의 총 시간 (초 단위)
# 이 값은 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval
@@ -869,6 +867,10 @@ Classic ELB의 연결 드레이닝은
service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
# ELB에 추가될 추가 보안 그룹(security group) 목록
service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
# 로드 밸런서의 대상 노드를 선택하는 데
# 사용되는 키-값 쌍의 쉼표로 구분된 목록
```
#### AWS의 네트워크 로드 밸런서 지원 {#aws-nlb-support}
@@ -1189,11 +1191,11 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
### SCTP
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
쿠버네티스는 서비스, 엔드포인트, 네트워크 정책 및 파드 정의에서 알파 기능으로 SCTP를 `프로토콜` 값으로 지원한다. 이 기능을 활성화하기 위해서는, 클러스터 관리자가 API 서버에서 `--feature-gates=SCTPSupport=true,…`처럼 `SCTPSupport` 기능 게이트를 활성화해야 한다.
쿠버네티스는 서비스, 엔드포인트, 엔드포인트슬라이스, 네트워크폴리시 및 파드 정의에서 SCTP를 `protocol` 값으로 지원한다. 이 기능은 베타 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에서 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
기능 게이트가 활성화되면, 서비스, 엔드포인트, 네트워크 정책 또는 파드의 `프로토콜` 필드를 `SCTP`로 설정할 수 있다. 쿠버네티스는 TCP 연결과 마찬가지로, SCTP 연결에 맞게 네트워크를 설정한다.
기능 게이트가 활성화되면, 서비스, 엔드포인트, 엔드포인트슬라이스, 네트워크폴리시 또는 파드의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. 쿠버네티스는 TCP 연결과 마찬가지로, SCTP 연결에 맞게 네트워크를 설정한다.
#### 경고 {#caveat-sctp-overview}