Merge pull request #31698 from jihoon-seo/220211_Outdated_M18-M24
[ko] Update outdated files in `dev-1.23-ko.2` (M18-M24)
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
587ddaf696
|
|
@ -5,8 +5,50 @@ description: >
|
|||
쿠버네티스의 네트워킹에 대한 개념과 리소스에 대해 설명한다.
|
||||
---
|
||||
|
||||
## 쿠버네티스 네트워크 모델
|
||||
|
||||
모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다.
|
||||
이는 즉 `파드`간 연결을 명시적으로 만들 필요가 없으며
|
||||
또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다.
|
||||
이로 인해 포트 할당, 네이밍, 서비스 디스커버리,
|
||||
[로드 밸런싱](/ko/docs/concepts/services-networking/ingress/#load-balancing),
|
||||
애플리케이션 구성, 마이그레이션 관점에서 `파드`를
|
||||
VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다.
|
||||
|
||||
쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다
|
||||
(이로 인해 모든 의도적인 네트워크 분할 정책이 방지된다)
|
||||
|
||||
* [노드](/ko/docs/concepts/architecture/nodes/) 상의 파드가 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
|
||||
* 노드 상의 에이전트(예: 시스템 데몬, kubelet)가 해당 노드의 모든
|
||||
파드와 통신할 수 있다
|
||||
|
||||
참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: 리눅스)에 대해서는
|
||||
다음의 요구사항도 존재한다.
|
||||
|
||||
* 한 노드의 호스트 네트워크에 있는 파드는
|
||||
NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
|
||||
|
||||
이 모델은 전반적으로 덜 복잡할 뿐만 아니라,
|
||||
무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다.
|
||||
작업을 기존에는 VM에서 실행했었다면, VM은 IP주소를 가지며 프로젝트 내의 다른 VM과 통신할 수 있었을 것이다.
|
||||
이는 동일한 기본 모델이다.
|
||||
|
||||
쿠버네티스 IP 주소는 `파드` 범주에 존재하며,
|
||||
`파드` 내의 컨테이너들은 IP 주소, MAC 주소를 포함하는 네트워크 네임스페이스를 공유한다.
|
||||
이는 곧 `파드` 내의 컨테이너들이 각자의 포트에 `localhost`로 접근할 수 있음을 의미한다.
|
||||
또한 `파드` 내의 컨테이너들이 포트 사용에 있어 서로 협조해야 하는데,
|
||||
이는 VM 내 프로세스 간에도 마찬가지이다.
|
||||
이러한 모델은 "파드 별 IP" 모델로 불린다.
|
||||
|
||||
이것이 어떻게 구현되는지는 사용하는 컨테이너 런타임의 상세사항이다.
|
||||
|
||||
`노드` 자체의 포트를 `파드`로 포워드하도록 요청하는 것도 가능하지만(호스트 포트라고 불림),
|
||||
이는 매우 비주류적인(niche) 동작이다.
|
||||
포워딩이 어떻게 구현되는지도 컨테이너 런타임의 상세사항이다.
|
||||
`파드` 자체는 호스트 포트 존재 유무를 인지할 수 없다.
|
||||
|
||||
쿠버네티스 네트워킹은 다음의 네 가지 문제를 해결한다.
|
||||
- 파드 내의 컨테이너는 루프백(loopback)을 통한 네트워킹을 사용하여 통신한다.
|
||||
- 파드 내의 컨테이너는 루프백(loopback)을 통한 [네트워킹을 사용하여 통신](/ko/docs/concepts/services-networking/dns-pod-service/)한다.
|
||||
- 클러스터 네트워킹은 서로 다른 파드 간의 통신을 제공한다.
|
||||
- 서비스 리소스를 사용하면 파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근할 수 있다.
|
||||
- 또한 서비스를 사용하여 클러스터 내부에서 사용할 수 있는 서비스만 게시할 수 있다.
|
||||
- [서비스 리소스](/ko/docs/concepts/services-networking/service/)를 사용하면 [파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근](/ko/docs/concepts/services-networking/connect-applications-service/)할 수 있다.
|
||||
- 또한 서비스를 사용하여 [서비스를 클러스터 내부에서만 사용할 수 있도록 게시](/ko/docs/concepts/services-networking/service-traffic-policy/)할 수 있다.
|
||||
|
|
|
|||
|
|
@ -13,11 +13,9 @@ weight: 30
|
|||
|
||||
## 컨테이너 연결을 위한 쿠버네티스 모델
|
||||
|
||||
지속적으로 실행중이고, 복제된 애플리케이션을 가지고 있다면 네트워크에 노출할 수 있다. 쿠버네티스의 네트워킹 접근 방식을 논의하기 전에, 도커와 함께 동작하는 "일반적인" 네트워킹 방법과 대조해볼 가치가 있다.
|
||||
지속적으로 실행중이고, 복제된 애플리케이션을 가지고 있다면 네트워크에 노출할 수 있다.
|
||||
|
||||
기본적으로 도커는 호스트-프라이빗 네트워킹을 사용하기에 컨테이너는 동일한 머신에 있는 경우에만 다른 컨테이너와 통신 할 수 있다. 도커 컨테이너가 노드를 통해 통신하려면 머신 포트에 IP 주소가 할당되어야 컨테이너에 전달되거나 프록시된다. 이것은 컨테이너가 사용하는 포트를 매우 신중하게 조정하거나 포트를 동적으로 할당해야 한다는 의미이다.
|
||||
|
||||
컨테이너를 제공하는 여러 개발자 또는 팀에서 포트를 조정하는 것은 규모면에서 매우 어려우며, 사용자가 제어할 수 없는 클러스터 수준의 문제에 노출된다. 쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑 할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
|
||||
쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트(localhost)에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
|
||||
|
||||
이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다.
|
||||
|
||||
|
|
@ -52,7 +50,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
|
|||
podIP: 10.244.2.5
|
||||
```
|
||||
|
||||
클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다.
|
||||
이제 클러스터의 모든 노드로 ssh 접속하거나 `curl`과 같은 도구를 사용하여 두 IP 주소에 질의를 전송할 수 있을 것이다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 `containerPort`를 사용하여 동일한 노드에서 여러 nginx 파드를 실행하는 것이 가능하고, 또한 서비스에 할당된 IP 주소를 사용하여 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 호스트 노드의 특정 포트를 배후(backing) 파드로 포워드하고 싶다면, 가능은 하지만 네트워킹 모델을 사용하면 그렇게 할 필요가 없어야 한다.
|
||||
|
||||
만약 궁금하다면 [쿠버네티스 네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)을 자세히 읽어본다.
|
||||
|
||||
|
|
|
|||
|
|
@ -106,10 +106,9 @@ SRV 레코드는 노멀 서비스 또는
|
|||
|
||||
`172-17-0-3.default.pod.cluster.local`.
|
||||
|
||||
서비스에 의해 노출된 디플로이먼트(Deployment)나 데몬셋(DaemonSet)에 의해 생성된
|
||||
모든 파드는 다음과 같은 DNS 주소를 갖는다.
|
||||
서비스에 의해 노출된 모든 파드는 다음과 같은 DNS 주소를 갖는다.
|
||||
|
||||
`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`.
|
||||
`pod-ip-address.service-name.my-namespace.svc.cluster-domain.example`.
|
||||
|
||||
### 파드의 hostname 및 subdomain 필드
|
||||
|
||||
|
|
|
|||
|
|
@ -57,6 +57,14 @@ IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워
|
|||
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
|
||||
* kube-proxy:
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* kubelet:
|
||||
* `--cloud-provider`가 명시되지 않았다면
|
||||
관리자는 해당 노드에 듀얼 스택 `.status.addresses`를 수동으로 설정하기 위해
|
||||
쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다.
|
||||
해당 노드의 파드가 HostNetwork 모드로 실행된다면,
|
||||
파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다.
|
||||
노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된
|
||||
IP 패밀리 선호사항을 만족한다.
|
||||
|
||||
{{< note >}}
|
||||
IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도)
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ weight: 40
|
|||
Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
|
||||
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
|
||||
* [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
|
||||
* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md)는 인그레스 컨트롤러로 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
|
||||
* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/reference/ingresscontroller.md)는 인그레스 컨트롤러로서 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
|
||||
* F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
|
||||
이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
|
||||
* [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ graph LR;
|
|||
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
|
||||
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
|
||||
그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
|
||||
다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
|
||||
서로 다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 서로 다른 어노테이션을 지원한다.
|
||||
지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.
|
||||
|
||||
인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
|
||||
|
|
@ -88,6 +88,15 @@ graph LR;
|
|||
들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP(S) 트래픽을
|
||||
지시하는 규칙만 지원한다.
|
||||
|
||||
`ingressClassName`을 생략하려면, [기본 인그레스 클래스](#default-ingress-class)가
|
||||
정의되어 있어야 한다.
|
||||
|
||||
몇몇 인그레스 컨트롤러는 기본 `IngressClass`가 정의되어 있지 않아도 동작한다.
|
||||
예를 들어, Ingress-NGINX 컨트롤러는 `--watch-ingress-without-class`
|
||||
[플래그](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class)를 이용하여 구성될 수 있다.
|
||||
하지만 [아래](#default-ingress-class)에 나와 있는 것과 같이 기본 `IngressClass`를 명시하는 것을
|
||||
[권장](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do)한다.
|
||||
|
||||
### 인그레스 규칙
|
||||
|
||||
각 HTTP 규칙에는 다음의 정보가 포함된다.
|
||||
|
|
@ -339,6 +348,14 @@ spec:
|
|||
기본값으로 표시하도록 해서 이 문제를 해결할 수 있다.
|
||||
{{< /caution >}}
|
||||
|
||||
몇몇 인그레스 컨트롤러는 기본 `IngressClass`가 정의되어 있지 않아도 동작한다.
|
||||
예를 들어, Ingress-NGINX 컨트롤러는 `--watch-ingress-without-class`
|
||||
[플래그](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class)를 이용하여 구성될 수 있다.
|
||||
하지만 다음과 같이 기본 `IngressClass`를 명시하는 것을
|
||||
[권장](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do)한다.
|
||||
|
||||
{{< codenew file="service/networking/default-ingressclass.yaml" >}}
|
||||
|
||||
## 인그레스 유형들
|
||||
|
||||
### 단일 서비스로 지원되는 인그레스 {#single-service-ingress}
|
||||
|
|
@ -468,9 +485,7 @@ graph LR;
|
|||
트래픽을 일치 시킬 수 있다.
|
||||
|
||||
예를 들어, 다음 인그레스는 `first.bar.com`에 요청된 트래픽을
|
||||
`service1`로, `second.bar.com`는 `service2`로, 호스트 이름이 정의되지
|
||||
않은(즉, 요청 헤더가 표시 되지 않는) IP 주소로의 모든
|
||||
트래픽은 `service3`로 라우팅 한다.
|
||||
`service1`로, `second.bar.com`는 `service2`로, 그리고 요청 헤더가 `first.bar.com` 또는 `second.bar.com`에 해당되지 않는 모든 트래픽을 `service3`로 라우팅한다.
|
||||
|
||||
{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ weight: 50
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. 네트워크폴리시는 {{< glossary_tooltip text="파드" term_id="pod" >}}가 네트워크 상의 다양한 네트워크 "엔티티"(여기서는 "엔티티"를 사용하여 쿠버네티스에서 특별한 의미로 사용되는 "엔드포인트" 및 "서비스"와 같은 일반적인 용어가 중의적으로 표현되는 것을 방지함)와 통신할 수 있도록 허용하는 방법을 지정할 수 있는 애플리케이션 중심 구조이다.
|
||||
IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. 네트워크폴리시는 {{< glossary_tooltip text="파드" term_id="pod" >}}가 네트워크 상의 다양한 네트워크 "엔티티"(여기서는 "엔티티"를 사용하여 쿠버네티스에서 특별한 의미로 사용되는 "엔드포인트" 및 "서비스"와 같은 일반적인 용어가 중의적으로 표현되는 것을 방지함)와 통신할 수 있도록 허용하는 방법을 지정할 수 있는 애플리케이션 중심 구조이다. 네트워크폴리시는 한쪽 또는 양쪽 종단이 파드인 연결에만 적용되며, 다른 연결에는 관여하지 않는다.
|
||||
|
||||
파드가 통신할 수 있는 엔티티는 다음 3개의 식별자 조합을 통해 식별된다.
|
||||
|
||||
|
|
@ -27,15 +27,17 @@ pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glo
|
|||
|
||||
네트워크 정책은 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 네트워크폴리시를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 네트워크폴리시 리소스를 생성해도 아무런 효과가 없기 때문이다.
|
||||
|
||||
## 격리 및 격리되지 않은 파드
|
||||
## 파드 격리의 두 가지 종류
|
||||
|
||||
기본적으로, 파드는 격리되지 않는다. 이들은 모든 소스에서 오는 트래픽을 받아들인다.
|
||||
파드 격리에는 이그레스에 대한 격리와 인그레스에 대한 격리의 두 가지 종류가 있다. 이들은 어떤 연결이 성립될지에 대해 관여한다. 여기서 "격리"는 절대적인 것이 아니라, "일부 제한이 적용됨"을 의미한다. 반대말인 "이그레스/인그레스에 대한 비격리"는 각 방향에 대해 제한이 적용되지 않음을 의미한다. 두 종류의 격리(또는 비격리)는 독립적으로 선언되며, 두 종류 모두 파드 간 연결과 연관된다.
|
||||
|
||||
파드는 파드를 선택한 네트워크폴리시에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 네트워크폴리시가 있으면 해당 파드는 네트워크폴리시에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 네트워크폴리시에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.)
|
||||
기본적으로, 파드는 이그레스에 대해 비격리되어 있다. 즉, 모든 아웃바운드 연결이 허용된다. 해당 파드에 적용되면서 `policyTypes`에 "Egress"가 있는 NetworkPolicy가 존재하는 경우, 파드가 이그레스에 대해 격리된다. 이러한 정책은 파드의 이그레스에 적용된다고 말한다. 파드가 이그레스에 대해 격리되면, 파드에서 나가는 연결 중에서 파드의 이그레스에 적용된 NetworkPolicy의 `egress` 리스트에 허용된 연결만이 허용된다. `egress` 리스트 각 항목의 효과는 합산되어 적용된다.
|
||||
|
||||
네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다.
|
||||
기본적으로, 파드는 인그레스에 대해 비격리되어 있다. 즉, 모든 인바운드 연결이 허용된다. 해당 파드에 적용되면서 `policyTypes`에 "Ingress"가 있는 NetworkPolicy가 존재하는 경우, 파드가 인그레스에 대해 격리된다. 이러한 정책은 파드의 인그레스에 적용된다고 말한다. 파드가 인그레스에 대해 격리되면, 파드로 들어오는 연결 중에서 파드의 인그레스에 적용된 NetworkPolicy의 `ingress` 리스트에 허용된 연결만이 허용된다. `ingress` 리스트 각 항목의 효과는 합산되어 적용된다.
|
||||
|
||||
두 파드간 네트워크 흐름을 허용하기 위해서는, 소스 파드의 이그레스 정책과 목적지 파드의 인그레스 정책 모두가 해당 트래픽을 허용해야 한다. 만약 소스의 이그레스 정책이나 목적지의 인그레스 정책 중 한쪽이라도 트래픽을 거절하게 되어 있다면, 해당 트래픽은 거절될 것이다.
|
||||
네트워크 폴리시가 충돌하는 경우는 없다. 네트워크 폴리시는 합산되어 적용된다. 특정 파드의 특정 방향에 대해 하나 또는 여러 개의 폴리시가 적용되면, 해당 파드의 해당 방향에 대해 허용된 연결은 모든 폴리시가 허용하는 연결의 합집합이다. 따라서, 판별 순서는 폴리시 결과에 영향을 미치지 않는다.
|
||||
|
||||
송신 파드에서 수신 파드로의 연결이 허용되기 위해서는, 송신 파드의 이그레스 폴리시와 수신 파드의 인그레스 폴리시가 해당 연결을 허용해야 한다. 만약 어느 한 쪽이라도 해당 연결을 허용하지 않으면, 연결이 되지 않을 것이다.
|
||||
|
||||
## 네트워크폴리시 리소스 {#networkpolicy-resource}
|
||||
|
||||
|
|
@ -176,18 +178,20 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
|
|||
|
||||
### 기본적으로 모든 인그레스 트래픽 거부
|
||||
|
||||
모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다.
|
||||
모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 인그레스 격리 정책을 생성할 수 있다.
|
||||
|
||||
{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
|
||||
|
||||
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다.
|
||||
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 인그레스에 대해 여전히 격리된다. 이 정책은 다른 파드로부터의 이그레스 격리에는 영향을 미치지 않는다.
|
||||
|
||||
### 기본적으로 모든 인그레스 트래픽 허용
|
||||
### 모든 인그레스 트래픽 허용
|
||||
|
||||
만약 네임스페이스의 모든 파드에 대한 모든 트래픽을 허용하려는 경우(일부 파드가 "격리 된" 것으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스의 모든 트래픽을 명시적으로 허용하는 정책을 만들 수 있다.
|
||||
한 네임스페이스의 모든 파드로의 인입(incoming) 연결을 허용하려면, 이를 명시적으로 허용하는 정책을 만들 수 있다.
|
||||
|
||||
{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
|
||||
|
||||
이 정책이 존재하면, 해당 파드로의 인입 연결을 막는 다른 정책은 효력이 없다. 이 정책은 모든 파드로부터의 이그레스 격리에는 영향을 미치지 않는다.
|
||||
|
||||
### 기본적으로 모든 이그레스 트래픽 거부
|
||||
|
||||
모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다.
|
||||
|
|
@ -195,14 +199,16 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
|
|||
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
|
||||
|
||||
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은
|
||||
기본 인그레스 격리 정책을 변경하지 않는다.
|
||||
모든 파드의 인그레스 격리 정책을 변경하지 않는다.
|
||||
|
||||
### 기본적으로 모든 이그레스 트래픽 허용
|
||||
### 모든 이그레스 트래픽 허용
|
||||
|
||||
만약 네임스페이스의 모든 파드의 모든 트래픽을 허용하려면 (일부 파드가 "격리 된"으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스에서 모든 이그레스 트래픽을 명시적으로 허용하는 정책을 생성할 수 있다.
|
||||
한 네임스페이스의 모든 파드로부터의 모든 연결을 허용하려면, 해당 네임스페이스의 파드로부터 나가는(outgoing) 모든 연결을 명시적으로 허용하는 정책을 생성할 수 있다.
|
||||
|
||||
{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
|
||||
|
||||
이 정책이 존재하면, 해당 파드에서 나가는 연결을 막는 다른 정책은 효력이 없다. 이 정책은 모든 파드로의 인그레스 격리에는 영향을 미치지 않는다.
|
||||
|
||||
### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부
|
||||
|
||||
해당 네임스페이스에 아래의 네트워크폴리시를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,10 @@
|
|||
apiVersion: networking.k8s.io/v1
|
||||
kind: IngressClass
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/component: controller
|
||||
name: nginx-example
|
||||
annotations:
|
||||
ingressclass.kubernetes.io/is-default-class: "true"
|
||||
spec:
|
||||
controller: k8s.io/ingress-nginx
|
||||
Loading…
Reference in New Issue