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

Fifth Korean l10n work for release 1.17 (#19335)

Browse Source 
* Update to Outdated files in dev-1.17-ko.5 branch. (#19145)
* Translate apiserver-aggregation into Korean (#19168)
* Translate storage/volumes.md in Korean. (#18594)
* Reflect new docs reference links since dev-1.17-ko.1 (#19159)

Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Yoon <learder@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>

Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Yoon <learder@gmail.com>
Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
This commit is contained in:
June Yi
2020-02-28 11:56:38 +09:00
committed by GitHub
parent 66a8d34a4d
commit f9a9884c0c
58 changed files with 2014 additions and 570 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/services-networking/connect-applications-service.md
+1 -1
View File
@@ -123,7 +123,7 @@ my-nginx 10.244.2.5:80,10.244.3.4:80 1m
이제 클러스터의 모든 노드에서 `<CLUSTER-IP>:<PORT>` 로 nginx 서비스를
curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외부에서는 절대로 연결되지
않음에 참고한다. 만약 이것이 어떻게 작동하는지 궁금하다면
[서비스 프록시](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)에 대해 더 읽어본다.
[서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)에 대해 더 읽어본다.
## 서비스에 접근하기
content/ko/docs/concepts/services-networking/dns-pod-service.md
+15 -13
View File
@@ -38,22 +38,24 @@ DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.
## 서비스
### A 레코드
### A/AAAA 레코드
"노멀"(헤드리스가 아닌) 서비스는
"노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라
`my-svc.my-namespace.svc.cluster-domain.example`
형식의 이름을 가진 DNS A 레코드가 할당된다. 이는 서비스의 클러스터 IP로 해석된다.
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터
IP로 해석된다.
"헤드리스"(클러스터 IP가 없는) 서비스 또한
"헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라
`my-svc.my-namespace.svc.cluster-domain.example`
형식의 이름을 가진 DNS A 레코드가 할당된다.
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다.
노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다.
클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 통해 선택할 수 있다.
클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을
통해 선택할 수 있다.
### SRV 레코드
SRV 레코드는 노멀 서비스 또는
[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)에
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에
속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다.
`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다.
@@ -128,22 +130,22 @@ spec:
```
파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면,
클러스터의 KubeDNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 레코드를 반환한다.
클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다.
예를 들어 호스트네임이 "`busybox-1`"이고,
서브도메인이 "`default-subdomain`"이고,
같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면,
파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다.
"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`".
DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 레코드를 제공한다.
"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 레코드를 가지고 있다.
DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다.
"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다.
엔드포인트 객체는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다.
{{< note >}}
A 레코드는 파드의 이름으로 생성되지 않기 때문에
파드의 A 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다.
A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에
파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다.
`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의
A 레코드만 생성할 수 있다.
A 또는 AAAA 레코드만 생성할 수 있다.
(`default-subdomain.my-namespace.svc.cluster-domain.example`)
또한 레코드를 가지기 위해서는 파드가 준비되어야 한다.
그렇지 않은 경우, 서비스에서 `publishNotReadyAddresses=True`가 활성화된다.
content/ko/docs/concepts/services-networking/dual-stack.md
+2 -3
View File
@@ -27,7 +27,6 @@ weight: 70
* 이중 스택 파드 네트워킹(파드 당 단일 IPv4와 IPv6 주소 할당)
* IPv4와 IPv6 지원 서비스(각 서비스는 단일 주소 패밀리이어야 한다.)
* Kubenet 다중 주소 패밀리 지원(IPv4와 IPv6)
* IPv4와 IPv6 인터페이스를 통한 파드 오프(off) 클러스터 이그레스 라우팅(예: 인터넷)
## 필수 구성 요소
@@ -36,7 +35,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음
* 쿠버네티스 1.16 또는 이후 버전
* 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
* Kubenet 네트워크 플러그인
* 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
* IPVS 모드에서 구동 중인 Kube-Proxy
## IPv4/IPv6 이중 스택 활성화
@@ -52,7 +51,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요
* `--feature-gates="IPv6DualStack=true"`
* kube-proxy:
* `--proxy-mode=ipvs`
* `--cluster-cidrs=<IPv4 CIDR>,<IPv6 CIDR>`
* `--cluster-cidrs=<IPv4 CIDR>,<IPv6 CIDR>`
* `--feature-gates="IPv6DualStack=true"`
{{< caution >}}
content/ko/docs/concepts/services-networking/ingress.md
+13 -21
View File
@@ -15,24 +15,15 @@ weight: 40
이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다.
노드(Node)
: 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신.
클러스터(Cluster)
: 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다.
에지 라우터(Edge router)
: 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.
클러스터 네트워크(Cluster network)
: 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
서비스(Service)
: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.
노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신.
클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다.
에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.
클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
서비스(Service): {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.
## 인그레스란?
인그레스는 클러스터 외부에서 클러스터 내부
[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부
{{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.
@@ -47,8 +38,8 @@ weight: 40
인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 또는
[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다.
[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는
[Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다.
## 전제 조건들
@@ -107,7 +98,7 @@ spec:
* 경로 목록 (예, `/testpath`)에는 각각 `serviceName` 과 `servicePort` 가 정의되어있는 관련
백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로 보내기 전에 호스트와 경로가
모두 수신 요청의 내용과 일치해야 한다.
* 백엔드는 [서비스 문서](/docs/concepts/services-networking/service/)에 설명된 바와 같이
* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/)에 설명된 바와 같이
서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한
HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다.
@@ -220,7 +211,7 @@ Events:
{{< note >}}
사용중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)
에 따라 default-http-backend
[서비스](/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다.
[서비스](/ko/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다.
{{< /note >}}
### 이름 기반의 가상 호스팅
@@ -466,12 +457,13 @@ Events:
사용자는 인그레스 리소스를 직접적으로 포함하지 않는 여러가지 방법으로 서비스를 노출할 수 있다.
* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 사용.
* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 사용.
* [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 사용.
* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 사용.
{{% /capture %}}
{{% capture whatsnext %}}
* [인그레스] 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)
{{% /capture %}}
content/ko/docs/concepts/services-networking/network-policies.md
+26 -71
View File
@@ -7,16 +7,16 @@ weight: 50
{{< toc >}}
{{% capture overview %}}
네트워크 정책은 파드 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다.
네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다.
`NetworkPolicy` 리소스는 레이블을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.
`NetworkPolicy` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.
{{% /capture %}}
{{% capture body %}}
## 전제 조건
네트워크 정책은 네트워크 플러그인으로 구현되므로 `NetworkPolicy` 를 지원하는 네트워킹 솔루션을 사용해야 한다. - 컨트롤러가 없이 단순하게 리소스를 생성하게 되면 아무런 효과가 없기 때문이다.
네트워크 정책은 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 NetworkPolicy를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 NetworkPolicy 리소스를 생성해도 아무런 효과가 없기 때문이다.
## 격리 및 격리되지 않은 파드
@@ -26,11 +26,11 @@ weight: 50
네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다.
## `NetworkPolicy` 리소스
## NetworkPolicy 리소스 {#networkpolicy-resource}
리소스에 대한 전체 정의는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다.
리소스에 대한 전체 정의에 대한 참조는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다.
`NetworkPolicy` 의 예시는 다음과 같다.
NetworkPolicy 의 예시는 다음과 같다.
```yaml
apiVersion: networking.k8s.io/v1
@@ -69,23 +69,25 @@ spec:
port: 5978
```
*선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 API 서버에 이를 POST 하더라도 효과가 없다.*
{{< note >}}
선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다.
{{< /note >}}
__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 `NetworkPolicy` 에는
__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 NetworkPolicy 에는
`apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 구성 파일
작업에 대한 일반적인 정보는
[컨피그 맵을 사용해서 컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/),
그리고 [오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management) 를 본다.
__spec__: `NetworkPolicy` [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.
__spec__: NetworkPolicy [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.
__podSelector__: 각 `NetworkPolicy` 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.
__podSelector__: 각 NetworkPolicy 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.
__policyTypes__: 각 `NetworkPolicy` 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
__policyTypes__: 각 NetworkPolicy 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
__ingress__: 각 `NetworkPolicy` 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
__ingress__: 각 NetworkPolicy 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
__egress__: 각 `NetworkPolicy` 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
__egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
따라서 예시의 NetworkPolicy는 다음과 같이 동작한다.
@@ -103,7 +105,7 @@ __egress__: 각 `NetworkPolicy` 에는 화이트리스트 `egress` 규칙이 포
`ingress` `from` 부분 또는 `egress` `to` 부분에 지정할 수 있는 네 종류의 셀렉터가 있다.
__podSelector__: `NetworkPolicy` 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다.
__podSelector__: NetworkPolicy 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다.
__namespaceSelector__: 모든 파드가 인그레스 소스 또는 이그레스를 대상으로 허용되어야 하는 특정 네임스페이스를 선택한다.
@@ -164,16 +166,7 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: {}
policyTypes:
- Ingress
```
{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다.
@@ -181,33 +174,13 @@ spec:
만약 네임스페이스의 모든 파드에 대한 모든 트래픽을 허용하려는 경우(일부 파드가 "격리 된" 것으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스의 모든 트래픽을 명시적으로 허용하는 정책을 만들 수 있다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all
spec:
podSelector: {}
ingress:
- {}
policyTypes:
- Ingress
```
{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
### 기본적으로 모든 이그레스 트래픽 거부
모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: {}
policyTypes:
- Egress
```
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은
기본 인그레스 격리 정책을 변경하지 않는다.
@@ -216,34 +189,13 @@ spec:
만약 네임스페이스의 모든 파드의 모든 트래픽을 허용하려면 (일부 파드가 "격리 된"으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스에서 모든 이그레스 트래픽을 명시적으로 허용하는 정책을 생성할 수 있다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all
spec:
podSelector: {}
egress:
- {}
policyTypes:
- Egress
```
{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부
해당 네임스페이스에 아래의 NetworkPolicy를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
```
{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다.
@@ -251,9 +203,12 @@ spec:
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
쿠버네티스는 `NetworkPolicy` 정의에서 `protocol` 값으로 SCTP를 알파 기능으로 지원한다. 이 기능을 활성화하려면 클러스터 관리자가 apiserver 에서 `SCTPSupport` 기능 게이트를 활성화 할 필요가 있다. 예를 들면, `“--feature-gates=SCTPSupport=true,...”` . 기능 게이트가 활성화 되면 `NetworkPolicy` 의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.
이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다.
기능 게이트가 활셩화 되면, NetworkPolicy의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.
CNI 플러그인은 SCTP를 `NetworkPolicy` 에서 `protocol` 값으로 지원해야 한다.
{{< note >}}
SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
{{< /note >}}
{{% /capture %}}
content/ko/docs/concepts/services-networking/service-topology.md
+92 -17
View File
@@ -43,23 +43,6 @@ _서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수
트래픽을 라우팅 하거나, 대기시간을 최소화하기 위해 동일한 랙 상단(top-of-rack) 스위치에
연결된 노드로 트래픽을 유지하는 것이 있다.
## 전제 조건
서비스 라우팅을 인식하는 토폴로지를 활성화 하려면 다음과 같은 전제 조건이
필요하다.
* 쿠버네티스 1.17 또는 이후 버전
* Kube-proxy 가 iptables 모드 또는 IPVS 모드에서 실행 중
* [엔드포인트 슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)의 활성화
## 서비스 토폴로지 활성화하기
서비스 토폴로지를 활성화하려면 kube-apiserver 와 kube-proxy의
기능 게이트에서 `ServiceTopology` 를 활성화 한다.
```
--feature-gates="ServiceTopology=true"
```
## 서비스 토폴로지 사용하기
@@ -114,6 +97,98 @@ _서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수
한다.
## 예시들
다음은 서비스 토폴로지 기능을 사용하는 일반적인 예시이다.
### 노드 로컬 엔드포인트만
노드 로컬 엔드포인트로만 라우팅하는 서비스이다. 만약 노드에 엔드포인트가 없으면 트레픽이 드롭된다.
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 9376
topologyKeys:
- "kubernetes.io/hostname"
```
### 노드 로컬 엔드포인트 선호
노드 로컬 엔드포인트를 선호하지만, 노드 로컬 엔드포인트가 없는 경우 클러스터 전체 엔드포인트로 폴백 하는 서비스이다.
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 9376
topologyKeys:
- "kubernetes.io/hostname"
- "*"
```
### 영역 또는 지리적 엔드포인트만
영역보다는 지리적 엔드포인트를 선호하는 서비스이다. 만약 엔드포인트가 없다면, 트래픽은 드롭된다.
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 9376
topologyKeys:
- "topology.kubernetes.io/zone"
- "topology.kubernetes.io/region"
```
### 노드 로컬, 영역 및 지역 엔드포인트 선호
노드 로컬, 영역 및 지역 엔드포인트를 선호하지만, 클러스터 전체 엔드포인트로 폴백하는 서비스이다.
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 9376
topologyKeys:
- "kubernetes.io/hostname"
- "topology.kubernetes.io/zone"
- "topology.kubernetes.io/region"
- "*"
```
{{% /capture %}}
{{% capture whatsnext %}}
content/ko/docs/concepts/services-networking/service.md
+2 -2
View File
@@ -850,7 +850,7 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스
헬스 체크에 실패하고 트래픽을 수신하지 못하게 된다.
트래픽을 균일하게 하려면, DaemonSet을 사용하거나,
[파드 안티어피니티(pod anti-affinity)](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)
[파드 안티어피니티(pod anti-affinity)](/ko/docs/concepts/configuration/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
를 지정하여 동일한 노드에 위치하지 않도록 한다.
[내부 로드 밸런서](/ko/docs/concepts/services-networking/service/#internal-load-balancer) 어노테이션과 함께 NLB 서비스를
@@ -939,7 +939,7 @@ spec:
{{< note >}}
ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다. IPv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은
정식(canonical) DNS 이름을 지정하기 때문이다. IP 주소를 하드 코딩하려면,
[헤드리스(headless) 서비스](#headless-services) 사용을 고려한다.
[헤드리스(headless) 서비스](#헤드리스-headless-서비스) 사용을 고려한다.
{{< /note >}}
`my-service.prod.svc.cluster.local` 호스트를 검색하면, 클러스터 DNS 서비스는