홈
제품
OpenShift Container Platform
4.19
수신 및 부하 분산
2.13. OpenShift 컨테이너 플랫폼 네트워킹을 통한 게이트웨이 API

2.13. OpenShift 컨테이너 플랫폼 네트워킹을 통한 게이트웨이 API

OpenShift Container Platform은 Ingress Operator와 함께 Gateway API를 사용하여 네트워크 트래픽을 구성하는 추가적인 방법을 제공합니다.

중요

Gateway API는 사용자 정의 네트워크(UDN)를 지원하지 않습니다.

2.13.1. Gateway API 개요
링크 복사

Gateway API는 오픈 소스이고 커뮤니티에서 관리하는 Kubernetes 네트워킹 메커니즘입니다. 이는 클러스터의 전송 계층 L4와 애플리케이션 계층 L7 내에서의 라우팅에 초점을 맞춥니다. 다양한 공급업체가 Gateway API의 다양한 구현을 제공합니다.

이 프로젝트는 폭넓은 커뮤니티 지원을 바탕으로 이식 가능한 API를 사용하여 표준화된 생태계를 제공하기 위한 노력입니다. Gateway API 기능을 Ingress Operator에 통합함으로써 기존 커뮤니티와 업스트림 개발 노력에 부합하는 네트워킹 솔루션을 구축할 수 있습니다.

Gateway API는 Ingress Operator의 기능을 확장하여 더욱 세부적인 클러스터 트래픽과 라우팅 구성을 처리합니다. 이러한 기능을 사용하면 Gateway API 사용자 정의 리소스 정의(CRD) 인스턴스를 만들 수 있습니다. OpenShift Container Platform 클러스터의 경우 Ingress Operator는 다음 리소스를 생성합니다.

게이트웨이: 이 리소스는 트래픽이 클러스터 내의 서비스로 어떻게 변환될 수 있는지 설명합니다. 예를 들어, 특정 로드 밸런서 구성.
GatewayClass: 이 리소스는 공통 구성과 동작을 공유하는 Gateway 객체 세트를 정의합니다. 예를 들어, 공개 또는 비공개 애플리케이션에 사용되는 Gateway 리소스 세트를 구별하기 위해 두 개의 별도 GatewayClass 객체를 생성할 수 있습니다.
HTTP 경로: 이 리소스는 게이트웨이에서 서비스로 가는 HTTP 요청의 라우팅 동작을 지정하며, 특히 HTTP 또는 종료된 HTTPS 연결을 다중화하는 데 유용합니다.
GRPCRoute: 이 리소스는 gRPC 요청의 라우팅 동작을 지정합니다.
ReferenceGrant: 이 리소스는 네임스페이스 간 참조를 활성화합니다. 예를 들어, 다른 네임스페이스에 있는 백엔드로 트래픽을 전달하는 경로를 활성화합니다.

OpenShift Container Platform에서 Gateway API 구현은 gateway.networking.k8s.io/v1을 기반으로 하며, 이 버전의 모든 필드가 지원됩니다.

2.13.1.1. Gateway API의 이점
링크 복사

Gateway API는 다음과 같은 이점을 제공합니다.

이식성: OpenShift Container Platform은 Ingress 성능을 개선하기 위해 HAProxy를 사용하는 반면, Gateway API는 특정 동작을 제공하기 위해 공급업체별 주석에 의존하지 않습니다. HAProxy와 비슷한 성능을 얻으려면 Gateway 객체를 수평적으로 확장하거나 연관된 노드를 수직적으로 확장해야 합니다.
관심사 분리: Gateway API는 리소스에 대한 역할 기반 접근 방식을 사용하며 대규모 조직이 책임과 팀을 구성하는 방식에 더 잘 맞습니다. 플랫폼 엔지니어는 GatewayClass 리소스에 집중할 수 있고, 클러스터 관리자는 Gateway 리소스 구성에 집중할 수 있으며, 애플리케이션 개발자는 HTTPRoute 리소스를 사용하여 서비스를 라우팅하는 데 집중할 수 있습니다.
확장성: 추가 기능은 표준화된 CRD로 개발됩니다.

2.13.1.2. 게이트웨이 API의 한계
링크 복사

Gateway API에는 다음과 같은 제한 사항이 있습니다.

버전 비호환성: Gateway API 생태계는 빠르게 변화하며, 일부 구현은 다른 구현과 호환되지 않습니다. 이는 해당 기능 세트가 Gateway API의 서로 다른 버전을 기반으로 하기 때문입니다.
리소스 오버헤드: Gateway API는 더 유연하지만 여러 리소스 유형을 사용하여 결과를 얻습니다. 규모가 작은 애플리케이션의 경우 기존 Ingress의 단순성이 더 적합할 수 있습니다.

2.13.2. OpenShift 컨테이너 플랫폼을 위한 게이트웨이 API 구현
링크 복사

Ingress Operator는 다른 공급업체 구현이 OpenShift Container Platform 클러스터에 정의된 CRD를 활용할 수 있도록 Gateway API CRD의 수명 주기를 관리합니다.

어떤 상황에서는 Gateway API가 공급업체 구현에서 지원하지 않는 하나 이상의 필드를 제공하지만, 해당 구현은 스키마상 나머지 필드와 호환됩니다. 이러한 "데드 필드"로 인해 Ingress 워크로드가 중단되고, 애플리케이션과 서비스가 부적절하게 프로비저닝되고, 보안 관련 문제가 발생할 수 있습니다. OpenShift Container Platform은 특정 버전의 Gateway API CRD를 사용하므로 Gateway API의 타사 구현을 사용하려면 모든 필드가 예상대로 작동하도록 OpenShift Container Platform 구현을 준수해야 합니다.

OpenShift Container Platform 4.19 클러스터 내에서 생성된 모든 CRD는 Ingress Operator에 의해 호환 가능한 버전이 지정되고 유지 관리됩니다. CRD가 이미 존재하지만 이전에 Ingress Operator에서 관리하지 않은 경우, Ingress Operator는 이러한 구성이 OpenShift Container Platform에서 지원하는 Gateway API 버전과 호환되는지 확인하고 CRD 계승에 대한 승인을 요구하는 관리 게이트를 만듭니다.

중요

Gateway API CRD가 포함된 이전 OpenShift Container Platform 버전에서 클러스터를 업데이트하는 경우 해당 리소스를 OpenShift Container Platform에서 지원하는 버전과 정확히 일치하도록 변경합니다. 그렇지 않으면 해당 CRD가 OpenShift Container Platform에서 관리되지 않고 Red Hat에서 지원하지 않는 기능을 포함할 수 있으므로 클러스터를 업데이트할 수 없습니다.

2.13.3. Ingress Operator를 위한 Gateway API 시작하기
링크 복사

첫 번째 단계에서 보여준 것처럼 GatewayClass를 생성하면 클러스터에서 사용할 Gateway API가 구성됩니다.

프로세스

GatewayClass 객체를 생성합니다.
1. 다음 정보를 포함하는 YAML 파일 openshift-default.yaml 을 만듭니다.
  예제 GatewayClass CR
  apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: openshift-default spec: controllerName: openshift.io/gateway-controller/v1
  1
  
  Copy to Clipboard Toggle word wrap
  1 1
  컨트롤러 이름.
  중요
  Ingress Operator가 관리할 수 있도록 컨트롤러 이름은 표시된 대로 정확히 지정되어야 합니다. 이 필드를 다른 값으로 설정하면 Ingress Operator는 GatewayClass 개체와 관련된 모든 Gateway , GRPCRoute , HTTPRoute 개체를 무시합니다. 컨트롤러 이름은 OpenShift Container Platform의 Gateway API 구현과 연결되어 있으며, 허용되는 컨트롤러 이름은 openshift.io/gateway-controller/v1 뿐입니다.
2. 다음 명령을 실행하여 GatewayClass 리소스를 만듭니다.
  $ oc create -f openshift-default.yaml
  Copy to Clipboard Toggle word wrap
  출력 예
  gatewayclass.gateway.networking.k8s.io/openshift-default created
  
  Copy to Clipboard Toggle word wrap
  GatewayClass 리소스를 생성하는 동안 Ingress Operator는 Red Hat OpenShift Service Mesh의 경량 버전, Istio 사용자 정의 리소스 및 openshift-ingress 네임스페이스에 새 배포를 설치합니다.
3. 선택 사항: 새로운 배포인 istiod-openshift-gateway가 준비되고 사용 가능한지 확인하세요.
  $ oc get deployment -n openshift-ingress
  Copy to Clipboard Toggle word wrap
  출력 예
  NAME READY UP-TO-DATE AVAILABLE AGE istiod-openshift-gateway 1/1 1 1 55s router-default 2/2 2 2 6h4m
  
  Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 비밀을 생성합니다.

oc -n openshift-ingress create secret tls gwapi-wildcard --cert=wildcard.crt --key=wildcard.key

$ oc -n openshift-ingress create secret tls gwapi-wildcard --cert=wildcard.crt --key=wildcard.key

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 Ingress Operator의 도메인을 가져옵니다.

DOMAIN=$(oc get ingresses.config/cluster -o jsonpath={.spec.domain})

$ DOMAIN=$(oc get ingresses.config/cluster -o jsonpath={.spec.domain})

Copy to Clipboard

Toggle word wrap

Gateway 객체를 생성합니다.

다음 정보를 포함하는 YAML 파일 example-gateway.yaml 을 만듭니다.

게이트웨이 CR 예시

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
  namespace: openshift-ingress 
spec:
  gatewayClassName: openshift-default 
  listeners:
  - name: https 
    hostname: "*.gwapi.${DOMAIN}" 
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: gwapi-wildcard 
    allowedRoutes:
      namespaces:
        from: All

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
  namespace: openshift-ingress


spec:
  gatewayClassName: openshift-default


  listeners:
  - name: https


    hostname: "*.gwapi.${DOMAIN}"


    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: gwapi-wildcard


    allowedRoutes:
      namespaces:
        from: All

Copy to Clipboard

Toggle word wrap

1: Gateway 객체는 openshift-ingress 네임스페이스에 생성되어야 합니다.
2: Gateway 객체는 이전에 생성된 GatewayClass 객체의 이름을 참조해야 합니다.
3: HTTPS 리스너는 클러스터 도메인의 하위 도메인과 일치하는 HTTPS 요청을 수신합니다. 이 리스너를 사용하면 Gateway API HTTPRoute 리소스를 사용하여 애플리케이션에 대한 수신을 구성할 수 있습니다.
4: 호스트 이름은 Ingress Operator 도메인의 하위 도메인이어야 합니다. 도메인을 사용하는 경우 리스너는 해당 도메인의 모든 트래픽을 처리하려고 시도합니다.
5: 이전에 생성된 비밀의 이름입니다.

다음 명령을 실행하여 리소스를 적용합니다.
```
oc apply -f example-gateway.yaml
```
```
$ oc apply -f example-gateway.yaml
```
Copy to Clipboard Toggle word wrap

선택 사항: Gateway 객체를 생성하면 Red Hat OpenShift Service Mesh가 동일한 이름으로 배포 및 서비스를 자동으로 프로비저닝합니다. 다음 명령을 실행하여 이를 확인하세요.

배포를 확인하려면 다음 명령을 실행하세요.

oc get deployment -n openshift-ingress example-gateway-openshift-default

$ oc get deployment -n openshift-ingress example-gateway-openshift-default

Copy to Clipboard

Toggle word wrap

출력 예

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
example-gateway-openshift-default    1/1     1            1           25s

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
example-gateway-openshift-default    1/1     1            1           25s

Copy to Clipboard

Toggle word wrap

서비스를 확인하려면 다음 명령을 실행하세요.

oc get service -n openshift-ingress example-gateway-openshift-default

$ oc get service -n openshift-ingress example-gateway-openshift-default

Copy to Clipboard

Toggle word wrap

출력 예

NAME                                TYPE           CLUSTER-IP   EXTERNAL-IP         PORT(S)      AGE
example-gateway-openshift-default   LoadBalancer   10.1.2.3     <external_ipname>   <port_info>  47s

NAME                                TYPE           CLUSTER-IP   EXTERNAL-IP         PORT(S)      AGE
example-gateway-openshift-default   LoadBalancer   10.1.2.3     <external_ipname>   <port_info>  47s

Copy to Clipboard

Toggle word wrap

선택 사항: Ingress Operator는 리스너의 호스트 이름을 사용하여 DNSRecord CR을 자동으로 생성하고, gateway.networking.k8s.io/gateway-name=example-gateway 레이블을 추가합니다. 다음 명령을 실행하여 DNS 레코드 상태를 확인하세요.

oc -n openshift-ingress get dnsrecord -l gateway.networking.k8s.io/gateway-name=example-gateway -o yaml

$ oc -n openshift-ingress get dnsrecord -l gateway.networking.k8s.io/gateway-name=example-gateway -o yaml

Copy to Clipboard

Toggle word wrap

출력 예

kind: DNSRecord
  ...
status:
  ...
  zones:
  - conditions:
    - message: The DNS provider succeeded in ensuring the record
      reason: ProviderSuccess
      status: "True"
      type: Published
    dnsZone:
      tags:
        ...
  - conditions:
    - message: The DNS provider succeeded in ensuring the record
      reason: ProviderSuccess
      status: "True"
      type: Published
    dnsZone:
      id: ...

kind: DNSRecord
  ...
status:
  ...
  zones:
  - conditions:
    - message: The DNS provider succeeded in ensuring the record
      reason: ProviderSuccess
      status: "True"
      type: Published
    dnsZone:
      tags:
        ...
  - conditions:
    - message: The DNS provider succeeded in ensuring the record
      reason: ProviderSuccess
      status: "True"
      type: Published
    dnsZone:
      id: ...

Copy to Clipboard

Toggle word wrap

이미 생성된 네임스페이스와 example-app/example-app 이라는 애플리케이션으로 요청을 전달하는 HTTPRoute 리소스를 만듭니다.
1. 다음 정보를 포함하는 YAML 파일 example-route.yaml 을 만듭니다.
  예제 HTTPRoute CR
  apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: example-route namespace: example-app-ns
  1
  spec: parentRefs:
  2
  - name: example-gateway namespace: openshift-ingress hostnames: ["example.gwapi.${DOMAIN}"]
  3
  rules: - backendRefs:
  4
  - name: example-app
  5
  port: 8443
  
  Copy to Clipboard Toggle word wrap
  1
  애플리케이션을 배포하는 네임스페이스입니다.
  2
  이 필드는 이전에 구성한 Gateway 객체를 가리켜야 합니다.
  3
  호스트 이름은 Gateway 개체에 지정된 호스트 이름과 일치해야 합니다. 이 경우, 리스너는 와일드카드 호스트 이름을 사용합니다.
  4
  이 필드는 서비스를 가리키는 백엔드 참조를 지정합니다.
  5
  애플리케이션에 대한 서비스 의 이름입니다.
2. 다음 명령을 실행하여 리소스를 적용합니다.
  $ oc apply -f example-route.yaml
  Copy to Clipboard Toggle word wrap
  출력 예
  httproute.gateway.networking.k8s.io/example-route created
  
  Copy to Clipboard Toggle word wrap

검증

다음 명령을 실행하여 Gateway 개체가 배포되었고 조건이 Programmed 인지 확인하세요.

oc wait -n openshift-ingress --for=condition=Programmed gateways.gateway.networking.k8s.io example-gateway

$ oc wait -n openshift-ingress --for=condition=Programmed gateways.gateway.networking.k8s.io example-gateway

Copy to Clipboard

Toggle word wrap

출력 예

gateway.gateway.networking.k8s.io/example-gateway condition met

gateway.gateway.networking.k8s.io/example-gateway condition met

Copy to Clipboard

Toggle word wrap

구성된 HTTPRoute 객체 호스트 이름으로 요청을 보냅니다.

curl -I --cacert <local cert file> https://example.gwapi.${DOMAIN}:443

$ curl -I --cacert <local cert file> https://example.gwapi.${DOMAIN}:443

Copy to Clipboard

Toggle word wrap

2.13.4. 게이트웨이 API 배포 토폴로지
링크 복사

게이트웨이 API는 공유 게이트웨이 또는 전용 게이트웨이라는 두 가지 토폴로지를 수용하도록 설계되었습니다. 각 토폴로지마다 장점이 다르고 보안에 미치는 영향도 다릅니다.

전용 게이트웨이: 경로와 모든 로드 밸런서 또는 프록시는 동일한 네임스페이스에서 제공됩니다. Gateway 객체는 특정 애플리케이션 네임스페이스에 대한 경로를 제한합니다. 이는 OpenShift Container Platform에서 Gateway API 리소스를 배포할 때의 기본 토폴로지입니다.
공유 게이트웨이: 경로는 여러 네임스페이스 또는 여러 호스트 이름으로 제공됩니다. Gateway 객체 필터는 spec.listeners.allowedRoutes.namespaces 필드를 사용하여 애플리케이션 네임스페이스의 경로를 허용합니다.

2.13.4.1. 전용 게이트웨이 예
링크 복사

다음 예에서는 전용 Gateway 리소스인 fin-gateway를 보여줍니다.

전용 게이트웨이 리소스 예시

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: fin-gateway
  namespace: openshift-ingress
spec:
  listeners: 
  - name: http
    protocol: HTTP
    port: 8080
    hostname: "example.com"

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: fin-gateway
  namespace: openshift-ingress
spec:
  listeners:


  - name: http
    protocol: HTTP
    port: 8080
    hostname: "example.com"

Copy to Clipboard

Toggle word wrap

1: spec.listeners[].allowedRoutes를 설정하지 않고 Gateway 리소스를 생성하면 namespaces.from 필드의 값이 Same 으로 암묵적으로 설정됩니다.

다음 예제에서는 전용 Gateway 개체에 연결되는 연관된 HTTPRoute 리소스인 sales-db 를 보여줍니다.

HTTPRoute 리소스 예시

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: sales-db
  namespace: openshift-ingress
spec:
  parentRefs:
  - name: fin-gateway
  hostnames:
  - sales-db.example.com
  rules:
    - backendRefs:
        - name: sales-db
        ¦ port: 8080

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: sales-db
  namespace: openshift-ingress
spec:
  parentRefs:
  - name: fin-gateway
  hostnames:
  - sales-db.example.com
  rules:
    - backendRefs:
        - name: sales-db
        ¦ port: 8080

Copy to Clipboard

Toggle word wrap

HTTPRoute 리소스는 게이트웨이에 연결하기 위해 parentRefs 필드의 값으로 Gateway 개체의 이름을 가져야 합니다. 암묵적으로 해당 경로는 Gateway 개체와 같은 네임스페이스에 있다고 가정합니다.

2.13.4.2. 공유 게이트웨이 예
링크 복사

다음 예제에서는 shared-gateway-access: "true"를 포함하는 모든 네임스페이스와 일치하도록 spec.listeners.allowedRoutes.namespaces 레이블 선택기가 설정된 devops-gateway 라는 Gateway 리소스를 보여줍니다.

공유 게이트웨이 리소스 예시

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: devops-gateway
  namespace: openshift-ingress
listeners:
  - name: https
    protocol: HTTPS
    hostname: "example.com"
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
        ¦ matchLabels:
        ¦   shared-gateway-access: "true"

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: devops-gateway
  namespace: openshift-ingress
listeners:
  - name: https
    protocol: HTTPS
    hostname: "example.com"
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
        ¦ matchLabels:
        ¦   shared-gateway-access: "true"

Copy to Clipboard

Toggle word wrap

다음 예에서는 devops-gateway 리소스에 허용되는 네임스페이스를 보여줍니다.

예제 네임스페이스 리소스

apiVersion: v1
kind: Namespace
metadata:
  name: dev
  labels:
    shared-gateway-access: "true"
---
apiVersion: v1
kind: Namespace
metadata:
  name: ops
  labels:
    shared-gateway-access: "true"

apiVersion: v1
kind: Namespace
metadata:
  name: dev
  labels:
    shared-gateway-access: "true"
---
apiVersion: v1
kind: Namespace
metadata:
  name: ops
  labels:
    shared-gateway-access: "true"

Copy to Clipboard

Toggle word wrap

이 예에서 두 개의 HTTPRoute 리소스인 dev-portal 과 ops-home 은 서로 다른 네임스페이스에 있지만 공유 게이트웨이에 연결되어 있습니다.

apiVersion: v1
kind: HTTPRoute
metadata:
  name: dev-portal
  namespace: dev
spec:
  parentRefs:
  - name: devops-gateway
    namespace: openshift-ingress
  rules:
  - backendRefs:
    - name: dev-portal
      port: 8080
---
apiVersion: v1
kind: HTTPRoute
metadata:
  name: ops-home
  namespace: ops
spec:
  parentRefs:
  - name: devops-gateway
    namespace: openshift-ingress
  rules:
  - backendRefs:
    - name: ops-home
      port: 8080

apiVersion: v1
kind: HTTPRoute
metadata:
  name: dev-portal
  namespace: dev
spec:
  parentRefs:
  - name: devops-gateway
    namespace: openshift-ingress
  rules:
  - backendRefs:
    - name: dev-portal
      port: 8080
---
apiVersion: v1
kind: HTTPRoute
metadata:
  name: ops-home
  namespace: ops
spec:
  parentRefs:
  - name: devops-gateway
    namespace: openshift-ingress
  rules:
  - backendRefs:
    - name: ops-home
      port: 8080

Copy to Clipboard

Toggle word wrap

공유 게이트웨이 토폴로지를 사용하는 경우 경로는 연결하려는 게이트웨이 개체의 네임스페이스를 지정해야 합니다. 여러 Gateway 객체를 배포하여 네임스페이스 전체에 공유할 수 있습니다. 공유 게이트웨이가 여러 개 있는 경우 이 토폴로지는 개념적으로 Ingress Controller 샤딩과 유사해집니다.

추가 리소스

Ingress 컨트롤러 분할 .

맨 위로 이동

2.13. OpenShift 컨테이너 플랫폼 네트워킹을 통한 게이트웨이 API

2.13.1. Gateway API 개요
링크 복사

2.13.1.1. Gateway API의 이점
링크 복사

2.13.1.2. 게이트웨이 API의 한계
링크 복사

2.13.2. OpenShift 컨테이너 플랫폼을 위한 게이트웨이 API 구현
링크 복사

2.13.3. Ingress Operator를 위한 Gateway API 시작하기
링크 복사

2.13.4. 게이트웨이 API 배포 토폴로지
링크 복사

2.13.4.1. 전용 게이트웨이 예
링크 복사

2.13.4.2. 공유 게이트웨이 예
링크 복사

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

2.13. OpenShift 컨테이너 플랫폼 네트워킹을 통한 게이트웨이 API

2.13.1. Gateway API 개요링크 복사링크가 클립보드에 복사되었습니다!

2.13.1.1. Gateway API의 이점링크 복사링크가 클립보드에 복사되었습니다!

2.13.1.2. 게이트웨이 API의 한계링크 복사링크가 클립보드에 복사되었습니다!

2.13.2. OpenShift 컨테이너 플랫폼을 위한 게이트웨이 API 구현링크 복사링크가 클립보드에 복사되었습니다!

2.13.3. Ingress Operator를 위한 Gateway API 시작하기링크 복사링크가 클립보드에 복사되었습니다!

2.13.4. 게이트웨이 API 배포 토폴로지링크 복사링크가 클립보드에 복사되었습니다!

2.13.4.1. 전용 게이트웨이 예링크 복사링크가 클립보드에 복사되었습니다!

2.13.4.2. 공유 게이트웨이 예링크 복사링크가 클립보드에 복사되었습니다!

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

2.13.1. Gateway API 개요
링크 복사

2.13.1.1. Gateway API의 이점
링크 복사

2.13.1.2. 게이트웨이 API의 한계
링크 복사

2.13.2. OpenShift 컨테이너 플랫폼을 위한 게이트웨이 API 구현
링크 복사

2.13.3. Ingress Operator를 위한 Gateway API 시작하기
링크 복사

2.13.4. 게이트웨이 API 배포 토폴로지
링크 복사

2.13.4.1. 전용 게이트웨이 예
링크 복사

2.13.4.2. 공유 게이트웨이 예
링크 복사