Sixth Korean l10n work for release 1.18
- Update outdated files in dev-1.18-ko.6 partly (#21714) - Translate StorageClass to Korean word (#21805) - Translate StatefulSet to Korean word in pods.md (#21794) - Translate tasks/run-application/delete-stateful-set/ in Korean (#21686) - Translate tasks/administer-cluster/change-default-storage-class in Korean (#21801) - update outdated docs (#21940) - Modify spacing term StatefulSet in Korean (#21871) - Translate /tasks/administer-cluster/coredns in Korean (#21876) - Fix typo in k8s.io/ko/docs/contribute/new-content/new-content/ (#21975) - Translation error correction in /concepts/containers/runtime-class.md (#21868) - Translate tasks/tls/certificate-rotation/ in Korean (#21838) - Translate /tasks/configure-pod-container/static-pod in Korean (#21798) - Update to Outdated files in the dev-1.18-ko.6 branch - (1/4) (#21911) - Fix English bugs in Korean documentation (#21994) - Update outdated dev-1.18-ko.6 partly (#22067) Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: PyungHo Yoon <learder@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Jordy Ruiter <jordy.ruiter@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com> Co-authored-by: Dajin Gwon <d.gweon@samsung.com> Co-authored-by: Hyungseok Lee <hs0426.lee@samsung.com> Co-authored-by: Jihoon Seo <jihoon.seo@etri.re.kr> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com>
This commit is contained in:
June Yi
+11
-14
@@ -54,16 +54,15 @@ fe00::2 ip6-allrouters
|
||||
10.200.0.4 nginx
|
||||
```
|
||||
|
||||
기본적으로, `hosts` 파일은 `localhost`와 자기 자신의 호스트네임과 같은 IPv4와 IPv6
|
||||
기본적으로, `hosts` 파일은 `localhost`와 자기 자신의 호스트네임과 같은 IPv4와 IPv6
|
||||
상용구들만 포함하고 있다.
|
||||
|
||||
## HostAliases를 사용하여 추가 항목들 추가하기
|
||||
|
||||
기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로, `foo.remote`,
|
||||
`bar.remote`가 `10.1.2.3`로 해석될 수 있도록 추가 항목들을 `hosts` 파일에 추가할 수 있으며,
|
||||
이는 `.spec.hostAliases` 항목에서 정의하여
|
||||
파드에 HostAliases를 추가하면 가능하다.
|
||||
|
||||
기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로,
|
||||
`foo.remote`, `bar.remote`가 `10.1.2.3`로 해석될 수 있도록
|
||||
추가 항목들을 `hosts` 파일에 추가할 수 있으며,
|
||||
이는 `.spec.hostAliases` 항목에서 정의하여 파드에 HostAliases를 추가하면 가능하다.
|
||||
|
||||
{{< codenew file="service/networking/hostaliases-pod.yaml" >}}
|
||||
|
||||
@@ -113,14 +112,12 @@ fe00::2 ip6-allrouters
|
||||
|
||||
## 왜 Kubelet이 호스트 파일을 관리하는가?
|
||||
|
||||
컨테이너가 이미 시작되고 난 후 Docker가 파일을 [수정](https://github.com/moby/moby/issues/17190)
|
||||
하는 것을 방지하기 위해 Kubelet은 파드의 각 컨테이너의 `hosts` 파일을
|
||||
[관리](https://github.com/kubernetes/kubernetes/issues/14633)
|
||||
한다.
|
||||
컨테이너가 이미 시작되고 난 후 도커가 파일을
|
||||
[수정](https://github.com/moby/moby/issues/17190)하는 것을 방지하기 위해
|
||||
Kubelet은 파드의 각 컨테이너의 `hosts` 파일을
|
||||
[관리](https://github.com/kubernetes/kubernetes/issues/14633)한다.
|
||||
|
||||
호스트 파일이 관리된다는 특성으로 인해, 컨테이너 재시작이나 파드 리스케줄 이벤트로
|
||||
호스트 파일이 관리된다는 특성으로 인해, 컨테이너 재시작이나 파드 리스케줄 이벤트로
|
||||
`hosts` 파일이 Kubelet에 의해 다시 마운트될 때마다 사용자가 작성한 모든 내용이
|
||||
덮어쓰여진다. 따라서, 호스트 파일의 내용을
|
||||
덮어 쓰인다. 따라서, 호스트 파일의 내용을
|
||||
직접 바꾸는 것은 권장하지 않는다.
|
||||
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@ service/my-nginx exposed
|
||||
|
||||
이 사양은 `run: my-nginx` 레이블이 부착된 모든 파드에 TCP 포트 80을
|
||||
대상으로 하는 서비스를 만들고 추상화된 서비스 포트에 노출시킨다
|
||||
(`targetPort` 는 컨테이너가 트래픽을 수신하는 포트, `port` 는
|
||||
(`targetPort` 는 컨테이너가 트래픽을 수신하는 포트, `port` 는
|
||||
추상화된 서비스 포트로 다른 파드들이 서비스에 접속하기위해 사용하는
|
||||
모든 포트일 수 있다).
|
||||
[서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)의
|
||||
@@ -390,8 +390,8 @@ kubectl edit svc my-nginx
|
||||
kubectl get svc my-nginx
|
||||
```
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s
|
||||
```
|
||||
```
|
||||
curl https://<EXTERNAL-IP> -k
|
||||
|
||||
@@ -3,9 +3,6 @@ title: 서비스 및 파드용 DNS
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
이 페이지는 쿠버네티스의 DNS 지원에 대한 개요를 설명한다.
|
||||
|
||||
@@ -14,26 +11,26 @@ weight: 20
|
||||
|
||||
## 소개
|
||||
|
||||
쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며,
|
||||
개별 컨테이너들이 DNS 네임을 해석할 때
|
||||
쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며,
|
||||
개별 컨테이너들이 DNS 네임을 해석할 때
|
||||
DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.
|
||||
|
||||
### DNS 네임이 할당되는 것들
|
||||
|
||||
클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다.
|
||||
기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와
|
||||
클러스터의 기본 도메인을 포함한다.
|
||||
클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다.
|
||||
기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와
|
||||
클러스터의 기본 도메인을 포함한다.
|
||||
이 예시는 다음과 같다.
|
||||
|
||||
쿠버네티스 네임스페이스 `bar`에 `foo`라는 서비스가 있다. 네임스페이스 `bar`에서 running 상태인 파드는
|
||||
단순하게 `foo`를 조회하는 DNS 쿼리를 통해서 서비스 `foo`를 찾을 수 있다.
|
||||
네임스페이스 `quux`에서 실행 중인 파드는
|
||||
쿠버네티스 네임스페이스 `bar`에 `foo`라는 서비스가 있다. 네임스페이스 `bar`에서 running 상태인 파드는
|
||||
단순하게 `foo`를 조회하는 DNS 쿼리를 통해서 서비스 `foo`를 찾을 수 있다.
|
||||
네임스페이스 `quux`에서 실행 중인 파드는
|
||||
`foo.bar`를 조회하는 DNS 쿼리를 통해서 이 서비스를 찾을 수 있다.
|
||||
|
||||
다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다.
|
||||
이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며 경고 없이 변경될 수 있다.
|
||||
다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다.
|
||||
이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며
|
||||
경고 없이 변경될 수 있다.
|
||||
최신 업데이트에 대한 자세한 설명은 다음 링크를 통해 참조할 수 있다.
|
||||
|
||||
[쿠버네티스 DNS 기반 서비스 디스커버리](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
|
||||
|
||||
## 서비스
|
||||
@@ -41,43 +38,50 @@ DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.
|
||||
### A/AAAA 레코드
|
||||
|
||||
"노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라
|
||||
`my-svc.my-namespace.svc.cluster-domain.example`
|
||||
`my-svc.my-namespace.svc.cluster-domain.example`
|
||||
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터
|
||||
IP로 해석된다.
|
||||
|
||||
"헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라
|
||||
`my-svc.my-namespace.svc.cluster-domain.example`
|
||||
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다.
|
||||
노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다.
|
||||
`my-svc.my-namespace.svc.cluster-domain.example`
|
||||
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다.
|
||||
노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다.
|
||||
클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을
|
||||
통해 선택할 수 있다.
|
||||
|
||||
### SRV 레코드
|
||||
|
||||
SRV 레코드는 노멀 서비스 또는
|
||||
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에
|
||||
속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다.
|
||||
SRV 레코드는 노멀 서비스 또는
|
||||
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에
|
||||
속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다.
|
||||
`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
|
||||
정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다.
|
||||
정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다.
|
||||
`my-svc.my-namespace.svc.cluster-domain.example`.
|
||||
헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의
|
||||
포트 번호와 도메인 이름을 포함한다.
|
||||
헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의
|
||||
포트 번호와 도메인 이름을 포함한다.
|
||||
`auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`.
|
||||
|
||||
## 파드
|
||||
|
||||
### A/AAAA 레코드
|
||||
|
||||
디플로이먼트나 데몬셋으로 생성되는 파드는 다음과 같은
|
||||
DNS 주소를 갖게 된다.
|
||||
|
||||
`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.`
|
||||
|
||||
### 파드의 hostname 및 subdomain 필드
|
||||
|
||||
파드가 생성되면 hostname은 해당 파드의 `metadata.name` 값이 된다.
|
||||
|
||||
파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다.
|
||||
이 필드는 파드의 호스트네임을 지정할 수 있다.
|
||||
`hostname` 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다.
|
||||
파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다.
|
||||
이 필드는 파드의 호스트네임을 지정할 수 있다.
|
||||
`hostname` 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다.
|
||||
예를 들어 `hostname` 필드가 "`my-host`"로 설정된 파드는 호스트네임이 "`my-host`"로 설정된다.
|
||||
|
||||
또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 서브도메인을 지정할 수 있다.
|
||||
예를 들어 "`my-namespace`" 네임스페이스에서, `hostname` 필드가 "`foo`"로 설정되고,
|
||||
`subdomain` 필드가 "`bar`"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다.
|
||||
또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 서브도메인을 지정할 수 있다.
|
||||
예를 들어 "`my-namespace`" 네임스페이스에서, `hostname` 필드가 "`foo`"로 설정되고,
|
||||
`subdomain` 필드가 "`bar`"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다.
|
||||
"`foo.bar.my-namespace.svc.cluster-domain.example`".
|
||||
|
||||
예시:
|
||||
@@ -129,59 +133,58 @@ spec:
|
||||
name: busybox
|
||||
```
|
||||
|
||||
파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면,
|
||||
파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면,
|
||||
클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다.
|
||||
예를 들어 호스트네임이 "`busybox-1`"이고,
|
||||
서브도메인이 "`default-subdomain`"이고,
|
||||
같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면,
|
||||
파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다.
|
||||
예를 들어 호스트네임이 "`busybox-1`"이고,
|
||||
서브도메인이 "`default-subdomain`"이고,
|
||||
같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면,
|
||||
파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다.
|
||||
"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`".
|
||||
DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다.
|
||||
DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다.
|
||||
"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다.
|
||||
|
||||
엔드포인트 객체는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다.
|
||||
엔드포인트 객체는 `hostname` 필드를
|
||||
임의의 엔드포인트 IP 주소로 지정할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에
|
||||
파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다.
|
||||
`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의
|
||||
A 또는 AAAA 레코드만 생성할 수 있다.
|
||||
(`default-subdomain.my-namespace.svc.cluster-domain.example`)
|
||||
또한 레코드를 가지기 위해서는 파드가 준비되어야 한다.
|
||||
그렇지 않은 경우, 서비스에서 `publishNotReadyAddresses=True`가 활성화된다.
|
||||
A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에
|
||||
파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다.
|
||||
`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의
|
||||
A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespace.svc.cluster-domain.example`)
|
||||
또한 서비스에서 `publishNotReadyAddresses=True` 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
### 파드의 DNS 정책
|
||||
|
||||
DNS 정책은 파드별로 설정할 수 있다. 현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다.
|
||||
DNS 정책은 파드별로 설정할 수 있다.
|
||||
현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다.
|
||||
이 정책들은 파드 스펙의 `dnsPolicy` 필드에서 지정할 수 있다.
|
||||
|
||||
- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다.
|
||||
자세한 내용은
|
||||
[관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)
|
||||
에서 확인할 수 있다.
|
||||
- "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과
|
||||
일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다.
|
||||
클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다.
|
||||
그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은
|
||||
[관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)
|
||||
에서 확인할 수 있다.
|
||||
- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
|
||||
- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다.
|
||||
자세한 내용은
|
||||
[관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)에서
|
||||
확인할 수 있다.
|
||||
- "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과
|
||||
일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다.
|
||||
클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다.
|
||||
그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은
|
||||
[관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)에서
|
||||
확인할 수 있다.
|
||||
- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
|
||||
"`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다.
|
||||
- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다.
|
||||
- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다.
|
||||
모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다.
|
||||
아래 절인
|
||||
[파드의 DNS 설정](#pod-dns-config)
|
||||
에서 자세한 내용을 확인할 수 있다.
|
||||
아래 절인 [파드의 DNS 설정](#pod-dns-config)에서
|
||||
자세한 내용을 확인할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면
|
||||
"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면
|
||||
“ClusterFirst”가 기본값으로 사용된다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
아래 예시는 `hostNetwork`필드가 `true`로 설정되어 있어서
|
||||
DNS 정책이 "`ClusterFirstWithHostNet`"으로 설정된 파드를 보여준다.
|
||||
아래 예시는 `hostNetwork`필드가 `true`로 설정되어 있어서
|
||||
DNS 정책이 "`ClusterFirstWithHostNet`"으로 설정된 파드를 보여준다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -206,30 +209,33 @@ spec:
|
||||
|
||||
사용자들은 파드의 DNS 설정을 통해서 직접 파드의 DNS를 세팅할 수 있다.
|
||||
|
||||
`dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다.
|
||||
이때, 파드의 `dnsPolicy`의 값이 "`None`"으로 설정되어 있어야 `dnsConfig` 필드를 지정할 수 있다.
|
||||
`dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다.
|
||||
이때, 파드의 `dnsPolicy`의 값이 "`None`"으로 설정되어 있어야
|
||||
`dnsConfig` 필드를 지정할 수 있다.
|
||||
|
||||
사용자는 `dnsConfig` 필드에서 다음과 같은 속성들을 지정할 수 있다.
|
||||
|
||||
- `nameservers`: 파드의 DNS 서버가 사용할 IP 주소들의 목록이다.
|
||||
파드의 `dnsPolicy`가 "`None`" 으로 설정된 경우에는
|
||||
적어도 하나의 IP 주소가 포함되어야 하며,
|
||||
- `nameservers`: 파드의 DNS 서버가 사용할 IP 주소들의 목록이다.
|
||||
파드의 `dnsPolicy`가 "`None`" 으로 설정된 경우에는
|
||||
적어도 하나의 IP 주소가 포함되어야 하며,
|
||||
그렇지 않으면 이 속성은 생략할 수 있다.
|
||||
`nameservers`에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며 중복되는 주소는 제거된다.
|
||||
- `searches`: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다.
|
||||
이 속성은 생략이 가능하며,
|
||||
값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다.
|
||||
병합 시 중복되는 도메인은 제거되며, 쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다.
|
||||
- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다.
|
||||
이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다.
|
||||
이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며,
|
||||
`nameservers`에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며
|
||||
중복되는 주소는 제거된다.
|
||||
- `searches`: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다.
|
||||
이 속성은 생략이 가능하며,
|
||||
값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다.
|
||||
병합 시 중복되는 도메인은 제거되며,
|
||||
쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다.
|
||||
- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다.
|
||||
이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다.
|
||||
이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며,
|
||||
병합 시 중복되는 항목은 제거된다.
|
||||
|
||||
|
||||
다음은 커스텀 DNS 세팅을 한 파드의 예시이다.
|
||||
|
||||
{{< codenew file="service/networking/custom-dns.yaml" >}}
|
||||
|
||||
위에서 파드가 생성되면,
|
||||
위에서 파드가 생성되면,
|
||||
컨테이너 `test`의 `/etc/resolv.conf` 파일에는 다음과 같은 내용이 추가된다.
|
||||
|
||||
```
|
||||
@@ -243,9 +249,7 @@ IPv6 셋업을 위해서 검색 경로와 네임 서버 셋업은 다음과 같
|
||||
```shell
|
||||
kubectl exec -it dns-example -- cat /etc/resolv.conf
|
||||
```
|
||||
|
||||
출력은 다음과 같은 형식일 것이다.
|
||||
|
||||
```shell
|
||||
nameserver fd00:79:30::a
|
||||
search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
|
||||
@@ -267,9 +271,5 @@ options ndots:5
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
DNS 구성 관리에 대한 지침은
|
||||
[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/)
|
||||
에서 확인 할 수 있다.
|
||||
|
||||
|
||||
|
||||
DNS 구성 관리에 대한 지침은
|
||||
[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다.
|
||||
|
||||
@@ -47,7 +47,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요
|
||||
* `--feature-gates="IPv6DualStack=true"`
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64이다.
|
||||
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
|
||||
* kubelet:
|
||||
* `--feature-gates="IPv6DualStack=true"`
|
||||
* kube-proxy:
|
||||
|
||||
@@ -152,7 +152,7 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그
|
||||
필요한 새 엔드포인트로 채운다.
|
||||
3. 추가할 새 엔드포인트가 여전히 남아있으면, 이전에 변경되지 않은
|
||||
슬라이스에 엔드포인트를 맞추거나 새로운 것을 생성한다.
|
||||
|
||||
|
||||
중요한 것은, 세 번째 단계는 엔드포인트슬라이스를 완벽하게 전부 배포하는 것보다
|
||||
엔드포인트슬라이스 업데이트 제한을 우선시한다. 예를 들어, 추가할 새 엔드포인트가
|
||||
10개이고 각각 5개의 공간을 사용할 수 있는 엔드포인트 공간이 있는 2개의
|
||||
@@ -161,7 +161,7 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그
|
||||
엔드포인트슬라이스를 생성하는 것이 여러 엔드포인트슬라이스를 업데이트하는 것 보다 더 선호된다.
|
||||
|
||||
각 노드에서 kube-proxy를 실행하고 엔드포인트슬라이스를 관찰하면,
|
||||
엔드포인트슬라이스에 대한 모든 변경 사항이 클러스터의 모든 노드로 전송되기
|
||||
엔드포인트슬라이스에 대한 모든 변경 사항이 클러스터의 모든 노드로 전송되기
|
||||
때문에 상대적으로 비용이 많이 소요된다. 이 방법은 여러 엔드포인트슬라이스가
|
||||
가득 차지 않은 결과가 발생할지라도, 모든 노드에 전송해야 하는
|
||||
변경 횟수를 의도적으로 제한하기 위한 것이다.
|
||||
@@ -179,6 +179,5 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그
|
||||
|
||||
|
||||
* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)
|
||||
* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 를 읽는다.
|
||||
|
||||
* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
|
||||
|
||||
|
||||
@@ -9,12 +9,13 @@ weight: 40
|
||||
|
||||
인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다.
|
||||
|
||||
kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는 클러스터와 함께 자동으로 실행되지 않는다.
|
||||
kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는
|
||||
클러스터와 함께 자동으로 실행되지 않는다.
|
||||
클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.
|
||||
|
||||
프로젝트로써 쿠버네티스는 현재 [GCE](https://git.k8s.io/ingress-gce/README.md) 와
|
||||
[nginx](https://git.k8s.io/ingress-nginx/README.md) 컨트롤러를 지원하고 유지한다.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
@@ -22,31 +23,42 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
|
||||
## 추가 컨트롤러
|
||||
|
||||
* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
|
||||
* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의
|
||||
[커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는
|
||||
* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의
|
||||
[커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는
|
||||
[Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다.
|
||||
* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](http://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다.
|
||||
* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](http://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다.
|
||||
* [AWS ALB 인그레스 컨트롤러](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)는 [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)를 사용하여 인그레스를 활성화한다.
|
||||
* [Contour](https://projectcontour.io/)는 VMware에서 제공하고 지원하는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
|
||||
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로
|
||||
VMware에서 제공하고 지원한다.
|
||||
* Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다.
|
||||
* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨트롤러](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한 [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다.
|
||||
* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨트롤러](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한
|
||||
[지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다.
|
||||
* [Gloo](https://gloo.solo.io)는 [solo.io](https://www.solo.io)의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈 소스 인그레스 컨트롤러다.
|
||||
* [HAProxy 인그레스](https://haproxy-ingress.github.io)는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다.
|
||||
* [HAProxy Technologies](https://www.haproxy.com/)는 [쿠버네티스를 위한 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress)를 지원하고 유지 보수한다. [공식 문서](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)를 통해 확인할 수 있다.
|
||||
* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로
|
||||
[인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/).
|
||||
* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한 [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는 [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다.
|
||||
* [NGINX, Inc.](https://www.nginx.com/) 는 [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다.
|
||||
* 쿠버네티스 인그레스와 같이 사용 사례를 포함하는 서비스 구성을 위한 [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다.
|
||||
* [Traefik](https://github.com/containous/traefik)은 완벽한 기능([암호화](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로, [Containous](https://containo.us/services)에서 상업적인 지원을 제공한다.
|
||||
* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로
|
||||
[인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/).
|
||||
* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한
|
||||
[커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는
|
||||
[상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다.
|
||||
* [NGINX, Inc.](https://www.nginx.com/)는
|
||||
[쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다.
|
||||
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다.
|
||||
* [Traefik](https://github.com/containous/traefik)은
|
||||
모든 기능([Let's Encrypt](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로,
|
||||
[Containous](https://containo.us/services)에서 상업적인 지원을 제공한다.
|
||||
|
||||
## 여러 인그레스 컨트롤러 사용
|
||||
|
||||
하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다. 인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우 어떤 인그레스 컨트롤러를 사용해야하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 어노테이션을 각각의 인그레스에 달아야 한다.
|
||||
하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다.
|
||||
인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우
|
||||
어떤 인그레스 컨트롤러를 사용해야 하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
|
||||
어노테이션을 각각의 인그레스에 달아야 한다.
|
||||
|
||||
만약 클래스를 정의하지 않으면, 클라우드 제공자는 기본 인그레스 컨트롤러를 사용할 수 있다.
|
||||
|
||||
이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야하지만, 다양한 인그레스 컨트롤러는 약간 다르게 작동한다.
|
||||
이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야 하지만,
|
||||
다양한 인그레스 컨트롤러는 약간 다르게 작동한다.
|
||||
|
||||
{{< note >}}
|
||||
인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야한다.
|
||||
@@ -58,6 +70,4 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
|
||||
|
||||
|
||||
* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
|
||||
* [NGINX 컨트롤러로 Minikube에서 Ingress를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
|
||||
|
||||
|
||||
* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 인그레스
|
||||
title: 인그레스(Ingress)
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
@@ -15,11 +15,11 @@ 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/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
|
||||
* 서비스: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.
|
||||
|
||||
## 인그레스란?
|
||||
|
||||
@@ -134,8 +134,7 @@ spec:
|
||||
요청은 _p_ 경로에 일치한다.
|
||||
|
||||
{{< note >}}
|
||||
경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시:
|
||||
`/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다).
|
||||
경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다).
|
||||
{{< /note >}}
|
||||
|
||||
#### 다중 일치
|
||||
@@ -216,7 +215,7 @@ NAME HOSTS ADDRESS PORTS AGE
|
||||
test-ingress * 203.0.113.123 80 59s
|
||||
```
|
||||
|
||||
여기서 `203.0.113.123` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해
|
||||
여기서 `203.0.113.123` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해
|
||||
할당한 IP 이다.
|
||||
|
||||
{{< note >}}
|
||||
|
||||
@@ -9,28 +9,28 @@ weight: 50
|
||||
<!-- overview -->
|
||||
네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다.
|
||||
|
||||
`NetworkPolicy` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.
|
||||
`네트워크폴리시(NetworkPolicy)` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## 전제 조건
|
||||
|
||||
네트워크 정책은 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 NetworkPolicy를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 NetworkPolicy 리소스를 생성해도 아무런 효과가 없기 때문이다.
|
||||
네트워크 정책은 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 네트워크폴리시를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 네트워크폴리시 리소스를 생성해도 아무런 효과가 없기 때문이다.
|
||||
|
||||
## 격리 및 격리되지 않은 파드
|
||||
|
||||
기본적으로, 파드는 격리되지 않는다. 이들은 모든 소스에서 오는 트래픽을 받아들인다.
|
||||
|
||||
파드는 파드를 선택한 NetworkPolicy에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 NetworkPolicy가 있으면 해당 파드는 NetworkPolicy에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 NetworkPolicy에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.)
|
||||
파드는 파드를 선택한 네트워크폴리시에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 네트워크폴리시가 있으면 해당 파드는 네트워크폴리시에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 네트워크폴리시에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.)
|
||||
|
||||
네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다.
|
||||
|
||||
## NetworkPolicy 리소스 {#networkpolicy-resource}
|
||||
## 네트워크폴리시 리소스 {#networkpolicy-resource}
|
||||
|
||||
리소스에 대한 전체 정의에 대한 참조는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다.
|
||||
리소스에 대한 전체 정의에 대한 참조는 [네트워크폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다.
|
||||
|
||||
NetworkPolicy 의 예시는 다음과 같다.
|
||||
네트워크폴리시 의 예시는 다음과 같다.
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
@@ -73,23 +73,23 @@ spec:
|
||||
선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다.
|
||||
{{< /note >}}
|
||||
|
||||
__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 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__: 네트워크폴리시 [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.
|
||||
|
||||
__podSelector__: 각 NetworkPolicy 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.
|
||||
__podSelector__: 각 네트워크폴리시에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.
|
||||
|
||||
__policyTypes__: 각 NetworkPolicy 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
|
||||
__policyTypes__: 각 네트워크폴리시에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 네트워크폴리시에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, 네트워크폴리시에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
|
||||
|
||||
__ingress__: 각 NetworkPolicy 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
|
||||
__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
|
||||
|
||||
__egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
|
||||
__egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
|
||||
|
||||
따라서 예시의 NetworkPolicy는 다음과 같이 동작한다.
|
||||
따라서 예시의 네트워크폴리시는 다음과 같이 동작한다.
|
||||
|
||||
1. 인그레스 및 이그레스 트래픽에 대해 "default" 네임스페이스에서 "role=db"인 파드를 격리한다(아직 격리되지 않은 경우).
|
||||
2. (인그레스 규칙)은 "role=db" 레이블을 사용하는 "default" 네임스페이스의 모든 파드에 대해서 TCP 포트 6397로의 연결을 허용한다. 인그레스을 허용 할 대상은 다음과 같다.
|
||||
@@ -105,7 +105,7 @@ __egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포
|
||||
|
||||
`ingress` `from` 부분 또는 `egress` `to` 부분에 지정할 수 있는 네 종류의 셀렉터가 있다.
|
||||
|
||||
__podSelector__: NetworkPolicy 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다.
|
||||
__podSelector__: 네트워크폴리시를 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다.
|
||||
|
||||
__namespaceSelector__: 모든 파드가 인그레스 소스 또는 이그레스를 대상으로 허용되어야 하는 특정 네임스페이스를 선택한다.
|
||||
|
||||
@@ -146,15 +146,15 @@ __namespaceSelector__ *와* __podSelector__: `namespaceSelector` 와 `podSelecto
|
||||
__ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP CIDR 범위를 선택한다. 파드 IP는 임시적이고 예측할 수 없기에 클러스터 외부 IP이어야 한다.
|
||||
|
||||
클러스터 인그레스 및 이그레스 매커니즘은 종종 패킷의 소스 또는 대상 IP의 재작성을
|
||||
필요로 한다. 이러한 상황이 발생하는 경우, NetworkPolicy의 처리 전 또는 후에
|
||||
필요로 한다. 이러한 상황이 발생하는 경우, 네트워크폴리시의 처리 전 또는 후에
|
||||
발생한 것인지 정의되지 않으며, 네트워크 플러그인, 클라우드 공급자,
|
||||
`서비스` 구현 등의 조합에 따라 동작이 다를 수 있다.
|
||||
|
||||
인그레스 사례에서의 의미는 실제 원본 소스 IP를 기준으로 들어오는 패킷을
|
||||
필터링할 수 있는 반면에 다른 경우에는 NetworkPolicy가 작동하는
|
||||
인그레스 사례에서의 의미는 실제 원본 소스 IP를 기준으로 들어오는 패킷을
|
||||
필터링할 수 있는 반면에 다른 경우에는 네트워크폴리시가 작동하는
|
||||
"소스 IP"는 `LoadBalancer` 또는 파드가 속한 노드 등의 IP일 수 있다.
|
||||
|
||||
이그레스의 경우 파드에서 클러스터 외부 IP로 다시 작성된 `서비스` IP로의 연결은
|
||||
이그레스의 경우 파드에서 클러스터 외부 IP로 다시 작성된 `서비스` IP로의 연결은
|
||||
`ipBlock` 기반의 정책의 적용을 받거나 받지 않을 수 있다는 것을 의미한다.
|
||||
|
||||
## 기본 정책
|
||||
@@ -164,11 +164,11 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
|
||||
|
||||
### 기본적으로 모든 인그레스 트래픽 거부
|
||||
|
||||
모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다.
|
||||
모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다.
|
||||
|
||||
{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
|
||||
|
||||
이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다.
|
||||
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다.
|
||||
|
||||
### 기본적으로 모든 인그레스 트래픽 허용
|
||||
|
||||
@@ -178,11 +178,11 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
|
||||
|
||||
### 기본적으로 모든 이그레스 트래픽 거부
|
||||
|
||||
모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다.
|
||||
모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다.
|
||||
|
||||
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
|
||||
|
||||
이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은
|
||||
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은
|
||||
기본 인그레스 격리 정책을 변경하지 않는다.
|
||||
|
||||
### 기본적으로 모든 이그레스 트래픽 허용
|
||||
@@ -193,21 +193,21 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
|
||||
|
||||
### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부
|
||||
|
||||
해당 네임스페이스에 아래의 NetworkPolicy를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다.
|
||||
해당 네임스페이스에 아래의 네트워크폴리시를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다.
|
||||
|
||||
{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
|
||||
|
||||
이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다.
|
||||
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다.
|
||||
|
||||
## SCTP 지원
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
|
||||
이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다.
|
||||
기능 게이트가 활셩화 되면, NetworkPolicy의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.
|
||||
기능 게이트가 활셩화 되면, 네트워크폴리시의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
|
||||
SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -218,6 +218,4 @@ SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI"
|
||||
|
||||
- 자세한 설명과 추가 예시는
|
||||
[네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다.
|
||||
- NetworkPolicy 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다.
|
||||
|
||||
|
||||
- 네트워크폴리시 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다.
|
||||
|
||||
@@ -194,7 +194,7 @@ spec:
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽는다.
|
||||
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽는다.
|
||||
* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽어보기.
|
||||
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기.
|
||||
|
||||
|
||||
|
||||
@@ -10,8 +10,6 @@ weight: 10
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< glossary_definition term_id="service" length="short" >}}
|
||||
@@ -242,7 +240,8 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
|
||||
추가와 제거를 감시한다. 각 서비스는 로컬 노드에서
|
||||
포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든
|
||||
연결은 (엔드포인트를 통해 보고된대로) 서비스의 백엔드 파드 중 하나로
|
||||
프록시된다. kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의
|
||||
프록시된다.
|
||||
kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의
|
||||
`SessionAffinity` 설정을 고려한다.
|
||||
|
||||
마지막으로, 유저-스페이스 프록시는 서비스의
|
||||
@@ -497,15 +496,15 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
|
||||
서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는
|
||||
`NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다.
|
||||
* [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를
|
||||
`externalName` 필드의 컨텐츠 (예:`foo.bar.example.com`)에
|
||||
맵핑한다. 어떤 종류의 프록시도 설정되어 있지 않다.
|
||||
`externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에
|
||||
매핑한다.
|
||||
어떤 종류의 프록시도 설정되어 있지 않다.
|
||||
{{< note >}}
|
||||
`ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는 CoreDNS 버전 1.7 이상이 필요하다.
|
||||
{{< /note >}}
|
||||
|
||||
[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
|
||||
|
||||
|
||||
### NodePort 유형 {#nodeport}
|
||||
|
||||
`type` 필드를 `NodePort`로 설정하면, 쿠버네티스 컨트롤 플레인은
|
||||
@@ -686,7 +685,7 @@ metadata:
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
annotations:
|
||||
annotations:
|
||||
service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
|
||||
[...]
|
||||
```
|
||||
@@ -1234,5 +1233,3 @@ kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지
|
||||
* [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기
|
||||
* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기
|
||||
* [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user