diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 576e241d8c..e855d96b35 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -306,7 +306,7 @@ spec: 컨테이너 `test`의 `/etc/resolv.conf` 파일에는 다음과 같은 내용이 추가된다. ``` -nameserver 1.2.3.4 +nameserver 192.0.2.1 search ns1.svc.cluster-domain.example my.dns.search.suffix options ndots:2 edns0 ``` diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index c712da90fd..d38ab8c33f 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -79,6 +79,13 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 주소는 아니다. [RFC 4193](https://tools.ietf.org/html/rfc4193)을 확인한다.) {{< /note >}} +{{< feature-state for_k8s_version="v1.27" state="alpha" >}} + +외부 클라우드 서비스 제공자를 사용하는 경우, +kubelet과 외부 클라우드 서비스 제공자 모두에서 `CloudDualStackNodeIPs` 기능 게이트를 활성화하면 +듀얼 스택 `--node-ip` 값을 kubelet에 전달할 수 있다. +이는 듀얼 스택 클러스터를 지원하는 클라우드 서비스 공급자에 대해서만 지원된다. + ## 서비스 IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 생성할 수 있다. diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index bc30106ef7..3062220c05 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -82,25 +82,25 @@ IPv4와 IPv6를 사용할 수 있는 서비스가 있을 경우, ### 컨디션 -엔드포인트슬라이스 API는 컨슈머에게 유용한 엔드포인트에 대한 조건을 저장한다. -조건은 `ready`, `serving` 및 `Terminating` 세 가지가 있다. +엔드포인트슬라이스 API는 컨슈머에게 유용한 엔드포인트에 대한 컨디션을 저장한다. +컨디션은 `ready`, `serving` 및 `Terminating` 세 가지가 있다. #### Ready -`ready`는 파드의 `Ready` 조건에 매핑되는 조건이다. `Ready` 조건이 `True`로 설정된 실행 중인 파드는 -이 엔드포인트슬라이스 조건도 `true`로 설정되어야 한다. 호환성의 -이유로, 파드가 종료될 때 `ready`는 절대 `true`가 되면 안 된다. 컨슈머는 `serving` 조건을 참조하여 +`ready`는 파드의 `Ready` 컨디션에 매핑되는 컨디션이다. `Ready` 컨디션이 `True`로 설정된 실행 중인 파드는 +이 엔드포인트슬라이스 컨디션도 `true`로 설정되어야 한다. 호환성의 +이유로, 파드가 종료될 때 `ready`는 절대 `true`가 되면 안 된다. 컨슈머는 `serving` 컨디션을 참조하여 파드 종료 준비 상태(readiness)를 검사해야 한다. 이 규칙의 유일한 예외는 `spec.publishNotReadyAddresses`가 `true`로 설정된 서비스이다. -이러한 서비스의 엔드 포인트는 항상 `ready`조건이 `true`로 설정된다. +이러한 서비스의 엔드 포인트는 항상 `ready` 컨디션이 `true`로 설정된다. #### Serving -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +{{< feature-state for_k8s_version="v1.26" state="stable" >}} -`serving`은 종료 상태를 고려하지 않는다는 점을 제외하면 `ready` 조건과 동일하다. -엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면 -이 조건을 확인해야 한다. +`serving` 컨디션은 `ready` 컨디션과 거의 동일하다. +차이점은 엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면 +`serving` 컨디션을 확인해야 한다는 점이다. {{< note >}} @@ -109,7 +109,7 @@ IPv4와 IPv6를 사용할 수 있는 서비스가 있을 경우, 역사적으로 종료된 엔드포인트는 처음부터 엔드포인트 또는 엔드포인트슬라이스 API에 포함되지 않았기 때문이다. 이러한 이유로 `ready`는 엔드포인트 종료를 위해 _always_ `false`이며, 클라이언트가 `ready`에 대한 기존 의미와 관계없이 파드 종료 준비 상태를 -추적 할 수 있도록 v1.20에 새로운 조건 `serving`이 추가되었다. +추적 할 수 있도록 v1.20에 새로운 컨디션 `serving`이 추가되었다. {{< /note >}} @@ -117,7 +117,7 @@ IPv4와 IPv6를 사용할 수 있는 서비스가 있을 경우, {{< feature-state for_k8s_version="v1.22" state="beta" >}} -`종료(Terminating)`는 엔드포인트가 종료되는지 여부를 나타내는 조건이다. +`종료(Terminating)`는 엔드포인트가 종료되는지 여부를 나타내는 컨디션이다. 파드의 경우 삭제 타임 스탬프가 설정된 모든 파드이다. ### 토폴로지 정보 {#topology} @@ -274,4 +274,5 @@ v1 API의 `zone` 필드로 접근할 수 있다. * [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/) 튜토리얼을 따라하기 * [엔드포인트슬라이스 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) 를 읽어보기 -* [엔드포인트 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) 를 읽어보기 \ No newline at end of file +* [엔드포인트 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) 를 읽어보기 + diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 1d94d88109..1a0bea92b7 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -33,6 +33,7 @@ weight: 50 * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다. * [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다. * [BFE Ingress Controller](https://github.com/bfenetworks/ingress-bfe)는 [BFE](https://www.bfe-networks.net) 기반 인그레스 컨트롤러다. +* [Cilium 인그레스 컨트롤러](https://docs.cilium.io/en/stable/network/servicemesh/ingress/)는 [Cilium](https://cilium.io/)에서 제공하는 인그레스 컨트롤러이다. * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는 Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다. * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다. @@ -40,6 +41,7 @@ weight: 50 * [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 가상 서버를 구성할 수 있다. +* [FortiADC 인그레스 컨트롤러](https://docs.fortinet.com/document/fortiadc/7.0.0/fortiadc-ingress-controller-1-0/742835/fortiadc-ingress-controller-overview)는 쿠버네티스 인그레스 리소스를 지원하며, 쿠버네티스에서 FortiADC 객체를 관리할 수 있다. * [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈소스 인그레스 컨트롤러다. * [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](https://www.haproxy.org/#desc)의 @@ -53,6 +55,7 @@ weight: 50 * [Kusk 게이트웨이](https://kusk.kubeshop.io/)는 OpenAPI 중심의 [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다. * [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx-ingress-controller/)는 [NGINX](https://www.nginx.com/resources/glossary/nginx/) 웹서버(프록시로 사용)와 함께 작동한다. +* [ngrok 쿠버네티스 인그레스 컨트롤러](https://github.com/ngrok/kubernetes-ingress-controller)는 [ngrok 플랫폼](https://ngrok.com)을 사용하여 K8s 서비스에 안전한 퍼블릭 액세스를 추가하기 위한 오픈소스 컨트롤러이다. * [Pomerium 인그레스 컨트롤러](https://www.pomerium.com/docs/k8s/ingress.html)는 [Pomerium](https://pomerium.com/) 기반 인그레스 컨트롤러이며, 상황 인지 접근 정책을 제공한다. * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다. * [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는 @@ -60,6 +63,7 @@ weight: 50 * [Tyk 오퍼레이터](https://github.com/TykTechnologies/tyk-operator)는 사용자 지정 리소스로 인그레스를 확장하여 API 관리 기능을 인그레스로 가져온다. Tyk 오퍼레이터는 오픈 소스 Tyk 게이트웨이 및 Tyk 클라우드 컨트롤 플레인과 함께 작동한다. * [Voyager](https://appscode.com/products/voyager)는 [HAProxy](https://www.haproxy.org/#desc)의 인그레스 컨트롤러다. +* [Wallarm 인그레스 컨트롤러](https://www.wallarm.com/solutions/waf-for-kubernetes)는 WAAP(WAF) 및 API 보안 기능을 제공하는 인그레스 컨트롤러이다. ## 여러 인그레스 컨트롤러 사용 diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 48b59f6a93..0d6db466f6 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -15,7 +15,6 @@ weight: 30 {{< feature-state for_k8s_version="v1.19" state="stable" >}} {{< glossary_definition term_id="ingress" length="all" >}} - ## 용어 @@ -23,14 +22,21 @@ weight: 30 이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다. * 노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. -* 클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. -* 에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. -* 클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. -* 서비스: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. +* 클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. + 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 + 퍼블릭 인터넷의 일부가 아니다. +* 에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. + 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. +* 클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)에 따라 + 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. +* 서비스: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용하여 + 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}. + 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. ## 인그레스란? -[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부 +[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)는 +클러스터 외부에서 클러스터 내부 {{< link text="서비스" url="/ko/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다. 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다. @@ -38,7 +44,11 @@ weight: 30 {{< figure src="/ko/docs/images/ingress.svg" alt="ingress-diagram" class="diagram-large" caption="그림. 인그레스" link="https://mermaid.live/edit#pako:eNqNksFK7DAUhl8lZDYKrYzjVSQjs9KdK11OZ5E2p06w05Yk1XtR4QojiM5OuHBlBhUENy5mIVjBJzLtO5ja6kxx4yY55PznO39OcoS9iAEmeE_QuI-2d9pOiJAXcAjVQjc_fdKT12zylP1L84u0t2gvoWySvj2n-vY8u7i39cO9vjzPHv7qqzHacEUH6btxEetpqm-m2XCMluwOD_cESNmdL-19NKoytt05LhpdT_PRGXp7Hmcv_48liAPuQddA9Mvwq0Qmbum1MHfzaM7z4XSOVYrKWsONI7bczUcjY6r3PdWqpSBk5e2plJvgozigPEQ-DwLSYIxZUoloH0jD9_0qtg85U33yK_5teVEQCdJoNpvtGmR_XVaIldaaB6s_ophcneIFiVQgKtKslDRc161jWjNM2XFG-pyRVQ3BKqZTLK3C5pyu_ADlAGrHpYtqb2MLD0AMKGfmBx0VOgerPgzAwcSEDHyaBMrBTnhipEnMqIItxlUkMPFpIMHCNFHR7p_Qw0SJBD5Fm5yaRx5UqpN3zjkTIA" >}} -인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다. +인그레스는 외부에서 서비스로 접속이 가능한 URL, +로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. +[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 +일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, +트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다. 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통 [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 또는 @@ -46,10 +56,11 @@ weight: 30 ## 전제 조건들 -[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다. +[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)가 +있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다. -[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)와 같은 인그레스 컨트롤러를 배포해야 할 수도 있다. 여러 -[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 중에서 선택할 수도 있다. +[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)와 같은 인그레스 컨트롤러를 배포해야 할 수도 있다. +여러 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 중에서 선택할 수도 있다. 이상적으로, 모든 인그레스 컨트롤러는 참조 사양이 맞아야 한다. 실제로, 다양한 인그레스 컨트롤러는 조금 다르게 작동한다. @@ -68,10 +79,10 @@ weight: 30 인그레스 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/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)이다. +인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데, 그 예시는 +[재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/main/docs/examples/rewrite/README.md)이다. 서로 다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 서로 다른 어노테이션을 지원한다. - 지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다. +지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다. 인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 에는 로드 밸런서 또는 프록시 서버를 구성하는데 필요한 모든 정보가 있다. 가장 중요한 것은, @@ -99,7 +110,8 @@ weight: 30 백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로 보내기 전에 호스트와 경로가 모두 수신 요청의 내용과 일치해야 한다. -* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/) 또는 [사용자 정의 리소스 백엔드](#resource-backend)에 설명된 바와 같이 +* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/) + 또는 [사용자 정의 리소스 백엔드](#resource-backend)에 설명된 바와 같이 서비스와 포트 이름의 조합이다. 규칙의 호스트와 경로가 일치하는 인그레스에 대한 HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다. @@ -168,9 +180,11 @@ Events: 모든 _p_ 가 요청 경로의 요소별 접두사가 _p_ 인 경우 요청은 _p_ 경로에 일치한다. - {{< note >}} 경로의 마지막 요소가 요청 경로에 있는 마지막 + {{< note >}} + 경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 는 - `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 와는 일치하지 않는다). {{< /note >}} + `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 와는 일치하지 않는다). + {{< /note >}} ### 예제 @@ -196,12 +210,14 @@ Events: | Mixed | `/foo` (Prefix), `/foo` (Exact) | `/foo` | 예, Exact 선호함 | #### 다중 일치 + 경우에 따라 인그레스의 여러 경로가 요청과 일치할 수 있다. 이 경우 가장 긴 일치하는 경로가 우선하게 된다. 두 개의 경로가 여전히 동일하게 일치하는 경우 접두사(prefix) 경로 유형보다 정확한(exact) 경로 유형을 가진 경로가 사용 된다. ## 호스트네임 와일드카드 + 호스트는 정확한 일치(예: "`foo.bar.com`") 또는 와일드카드(예: "`* .foo.com`")일 수 있다. 정확한 일치를 위해서는 HTTP `host` 헤더가 `host` 필드와 일치해야 한다. 와일드카드 일치를 위해서는 HTTP `host` 헤더가 @@ -248,6 +264,7 @@ Events: 해당 API에 대한 특정 클러스터 범위 리소스를 가리킨다. 예시는 다음과 같다. + ```yaml --- apiVersion: networking.k8s.io/v1 @@ -266,6 +283,7 @@ spec: kind: ClusterIngressParameter name: external-config-1 ``` + {{% /tab %}} {{% tab name="네임스페이스" %}} {{< feature-state for_k8s_version="v1.23" state="stable" >}} @@ -391,7 +409,7 @@ test-ingress external-lb * 203.0.113.123 80 59s {{< figure src="/ko/docs/images/ingressFanOut.svg" alt="ingress-fanout-diagram" class="diagram-large" caption="그림. 인그레스 팬아웃" link="https://mermaid.live/edit#pako:eNqNUk1r2zAY_itCuXRgu7acrak6cupuO23HOAfZkhtRRzaSvA_awgY5lK63wk4J3aDQSw85FOZBf9Hs_IfJtd2k6wa7SC96Pl69D-8RjFLKIIYHkmQT8PrNXiCihDOht0arz7fl4q5a3FZfi9VZMX5mO6BaFL9-FOW30-rsyi6vr8ovp9X1p_Ji_jKUw_L73FSgXBbl5bKazYFjD7k4kEyp0abQAt7OwNn1HA_5juejsWna8mx7eLwdp-mxYvIdj5g3Mj7lz5lRge4J95Hr_qkJiew06KkG4YE7MBoQCJWHzaz1eJc3hrSaLcGD2T2lbWSMs5R6o9X5uZlr_BRCf4FQA_n_hvqbEBMU1JETpfZZDLKEcAFiniS4Rym1lJbpIcO9OI7b2n7PqZ7gfvbBitIklbjnuu7epsfhQLUOPnoRsef_ZWKwRyZRkivNZGu0VuJeGIaPXdDapWn4YATaUK0utq5AVh1sfdxXfn3064-vpc0WNoFsvjbfam-zBIGAFpwyOSWcmj0-CgQAAdQTNmUBxKakLCZ5ogMYiBNDzTNKNHtFuU4lxDFJFLMgyXX69qOIINYyZx1pnxOzKtOWdfIbg1JDXw" >}} -다음과 같은 인그레스가 필요하다. +이는 다음과 같은 인그레스가 필요하다. {{% codenew file="service/networking/simple-fanout-example.yaml" %}} @@ -435,7 +453,6 @@ Events: {{< figure src="/ko/docs/images/ingressNameBased.svg" alt="ingress-namebase-diagram" class="diagram-large" caption="그림. 이름 기반의 가상 호스팅 인그레스" link="https://mermaid.live/edit#pako:eNqNks9r2zAUx_8VoVw2sE1sZ1umjJy6207bMc5BtuTG1JaMJO8HbWGDHErX22DskNANCr3skENhHuwvmpz_YXJsLy7tYBf5oe_3fd7T8zuGEScUIngocL4AL15OQMCiNKFMPZhtP9zo9a9qfVN9Lrfn5fyh7YBqXf7-UeqvZ9X5la2vr_THs-r6vf60ehaKqf62MhHQm1JfbqrlCjj2NGGHgko56ydawH0ydp66juv5jut780nAWp9tT0-2X0pjMhURiDl3QiyciGcnkorXSUTdmSHrn0tjAd0VGg_ndef3Q2pADepBvLsQr4PIImymUb__8ntNWW728J2lrWsK5Zy4s-3FhXn4_K7k3SN5jeT_Wxr1JcrI7p9gKQ9oDPIUJwzESZqiASHEkkrwI4oGcRy3sf0mIWqBRvlbK-IpF2gwHA4nfcbRWLYE33sc0Uf_BTHaLUiUFlJR0YL2mWgQhuFtirenNAX_gkA7VKsbWxd4Vj3Y-thFfn2M6sb3qc2aNgPp3zZttd8JtGBGRYYTYrb8OGAABFAtaEYDiExIaIyLVAUwYKfGWuQEK_qcJIoLiGKcSmpBXCj-6h2LIFKioJ3pIMFmTbLWdfoHV6NUVg" >}} - 다음 인그레스는 [호스트 헤더](https://tools.ietf.org/html/rfc7230#section-5.4)에 기반한 요청을 라우팅 하기 위해 뒷단의 로드 밸런서를 알려준다. @@ -446,7 +463,9 @@ Events: 트래픽을 일치 시킬 수 있다. 예를 들어, 다음 인그레스는 `first.bar.com`에 요청된 트래픽을 -`service1`로, `second.bar.com`는 `service2`로, 그리고 요청 헤더가 `first.bar.com` 또는 `second.bar.com`에 해당되지 않는 모든 트래픽을 `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" %}} @@ -615,8 +634,6 @@ Events: * [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 사용. * [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 사용. - - ## {{% heading "whatsnext" %}} * [인그레스](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API에 대해 배우기