Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

2.13. OpenShift Container Platform 네트워킹을 사용한 게이트웨이 API

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

중요

게이트웨이 API는 UDN(사용자 정의 네트워크)을 지원하지 않습니다.

2.13.1. 게이트웨이 API 개요
링크 복사

게이트웨이 API는 커뮤니티에서 관리하는 오픈 소스 Kubernetes 네트워킹 메커니즘입니다. 클러스터의 경우 전송 계층 L4 및 애플리케이션 계층 L7 내의 라우팅에 중점을 둡니다. 다양한 벤더가 게이트웨이 API의 여러 구현을 제공합니다.

이 프로젝트는 광범위한 커뮤니티 지원이 포함된 이식 가능한 API를 사용하여 표준화된 에코시스템을 제공하기 위한 노력입니다. Gateway API 기능을 Ingress Operator에 통합하면 기존 커뮤니티 및 업스트림 개발 작업과 일치하는 네트워킹 솔루션을 사용할 수 있습니다.

게이트웨이 API는 Ingress Operator의 기능을 확장하여 더 세분화된 클러스터 트래픽 및 라우팅 구성을 처리합니다. 이러한 기능을 사용하면 게이트웨이 API CRD(사용자 정의 리소스 정의) 인스턴스를 생성할 수 있습니다. OpenShift Container Platform 클러스터의 경우 Ingress Operator는 다음 리소스를 생성합니다.

게이트웨이
이 리소스는 트래픽을 클러스터 내의 서비스로 변환하는 방법을 설명합니다. 예를 들어 특정 로드 밸런서 구성입니다.
GatewayClass
이 리소스는 공통 구성 및 동작을 공유하는 Gateway 오브젝트 세트를 정의합니다. 예를 들어 퍼블릭 또는 프라이빗 애플리케이션에 사용되는 게이트웨이 리소스 세트를 구분하기 위해 두 개의 별도 Gateway Class 오브젝트를 생성할 수 있습니다.
HTTPRoute
이 리소스는 게이트웨이에서 서비스로의 HTTP 요청의 라우팅 동작을 지정하며 HTTP 연결 또는 종료된 HTTPS 연결을 멀티플렉싱하는 데 특히 유용합니다.
GRPCRoute
이 리소스는 gRPC 요청의 라우팅 동작을 지정합니다.
ReferenceGrant
이 리소스는 네임스페이스 간 참조를 활성화합니다. 예를 들어, 경로가 다른 네임스페이스에 있는 백엔드로 트래픽을 전달할 수 있습니다.

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

2.13.1.1. 게이트웨이 API의 이점
링크 복사

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

  • 이식성: OpenShift Container Platform은 HAProxy를 사용하여 Ingress 성능을 개선하지만 게이트웨이 API는 특정 동작을 제공하기 위해 벤더별 주석을 사용하지 않습니다. HAProxy와 유사한 성능을 얻으려면 게이트웨이 오브젝트를 수평으로 확장하거나 관련 노드를 수직으로 확장해야 합니다.
  • 문제 분리: 게이트웨이 API는 리소스에 대한 역할 기반 접근 방식을 사용하며 대규모 조직이 역할과 팀을 구성하는 방법에 보다 깔끔하게 적합합니다. 플랫폼 엔지니어는 GatewayClass 리소스에 중점을 둘 수 있으며 클러스터 관리자는 게이트웨이 리소스 구성에 중점을 둘 수 있으며 애플리케이션 개발자는 HTTPRoute 리소스를 사용하여 서비스를 라우팅하는 데 중점을 둘 수 있습니다.
  • 확장성: 추가 기능은 표준화된 CRD로 개발됩니다.

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

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

  • 버전 비호환성: 게이트웨이 API 에코시스템이 빠르게 변경되고 일부 구현은 게이트웨이 API의 다른 버전을 기반으로 하므로 다른 구현에서는 작동하지 않습니다.
  • 리소스 오버헤드: 더 유연하지만 Gateway API는 여러 리소스 유형을 사용하여 결과를 얻습니다. 소규모 애플리케이션의 경우 기존 Ingress의 단순성이 더 적합할 수 있습니다.

2.13.2. OpenShift Container Platform용 게이트웨이 API 구현
링크 복사

Ingress Operator는 다른 벤더 구현에서 OpenShift Container Platform 클러스터에 정의된 CRD를 사용할 수 있는 방식으로 게이트웨이 API CRD의 라이프사이클을 관리합니다.

경우에 따라 Gateway API는 벤더 구현이 지원하지 않는 필드를 하나 이상 제공하지만 해당 구현은 스키마에서 나머지 필드와 호환되지 않습니다. 이러한 "드라이드 필드"로 인해 Ingress 워크로드, 잘못 프로비저닝된 애플리케이션 및 서비스, 보안 관련 문제가 발생할 수 있습니다. OpenShift Container Platform은 특정 버전의 Gateway API CRD를 사용하므로 게이트웨이 API의 타사 구현을 사용하려면 모든 필드가 예상대로 작동하도록 OpenShift Container Platform 구현을 준수해야 합니다.

OpenShift Container Platform 4.20 클러스터 내에서 생성된 모든 CRD는 Ingress Operator에 의해 버전화되고 유지 관리됩니다. CRD가 이미 있지만 Ingress Operator에서 이전에 관리하지 않은 경우 Ingress Operator는 이러한 구성이 OpenShift Container Platform에서 지원하는 Gateway API 버전과 호환되는지 여부를 확인하고 CRD 연속 승인이 필요한 admin-gate를 생성합니다.

중요

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

2.13.3. Ingress Operator의 Gateway API 시작하기
링크 복사

첫 번째 단계에 표시된 대로 GatewayClass를 생성할 때 클러스터에서 사용할 게이트웨이 API를 구성합니다.

프로세스

  1. 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
      컨트롤러 이름입니다.
      중요

      컨트롤러 이름은 Ingress Operator에서 관리할 수 있도록 정확히 표시되어야 합니다. 이 필드를 다른 것으로 설정하면 Ingress Operator는 Gateway Class 오브젝트 및 연결된 모든 게이트웨이 ,GRPCRoute 및 HTTPRoute 오브젝트를 무시합니다. 컨트롤러 이름은 OpenShift Container Platform에서 게이트웨이 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

  2. 다음 명령을 실행하여 보안을 생성합니다. 

    $ oc -n openshift-ingress create secret tls gwapi-wildcard --cert=wildcard.crt --key=wildcard.key
    Copy to Clipboard Toggle word wrap

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

    $ DOMAIN=$(oc get ingresses.config/cluster -o jsonpath={.spec.domain})
    Copy to Clipboard Toggle word wrap

  4. Gateway 오브젝트를 만듭니다.

    1. 다음 정보가 포함된 YAML 파일 example-gateway.yaml 을 만듭니다.

      게이트웨이 CR 예

      apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
  namespace: openshift-ingress
      1 
      
spec:
  gatewayClassName: openshift-default
      2 
      
  listeners:
  - name: https
      3 
      
    hostname: "*.gwapi.${DOMAIN}"
      4 
      
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: gwapi-wildcard
      5 
      
    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
      이전에 생성한 보안의 이름입니다.

    2. 다음 명령을 실행하여 리소스를 적용합니다. 

      $ oc apply -f example-gateway.yaml
      Copy to Clipboard Toggle word wrap

    3. 선택 사항: 게이트웨이 오브젝트를 생성할 때 Red Hat OpenShift Service Mesh는 동일한 이름으로 배포 및 서비스를 자동으로 프로비저닝합니다. 다음 명령을 실행하여 확인합니다.

      • 배포를 확인하려면 다음 명령을 실행합니다. 

        $ 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
        Copy to Clipboard Toggle word wrap

      • 서비스를 확인하려면 다음 명령을 실행합니다. 

        $ 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
        Copy to Clipboard Toggle word wrap

    4. 선택 사항: 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
      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: ...
      Copy to Clipboard Toggle word wrap

  5. 이미 생성된 네임스페이스 및 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

검증

  1. 다음 명령을 실행하여 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
    Copy to Clipboard Toggle word wrap

  2. 구성된 HTTPRoute 오브젝트 호스트 이름으로 요청을 보냅니다. 

    $ 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에서 게이트웨이 API 리소스를 배포할 때 기본 토폴로지입니다.
공유 게이트웨이
경로는 여러 네임스페이스에서 제공되거나 여러 호스트 이름으로 제공됩니다. Gateway 오브젝트 필터는 spec.listeners.allowedRoutes.namespaces 필드를 사용하여 애플리케이션 네임스페이스의 경로를 허용합니다.

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

다음 예제에서는 전용 게이트웨이 리소스인 fin-gateway 를 보여줍니다.

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

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

  - name: http
    protocol: HTTP
    port: 8080
    hostname: "example.com"
Copy to Clipboard Toggle word wrap

1
spec.listeners[].allowedRoutes 를 설정하지 않고 Gateway 리소스를 생성하면 암시적으로 namespaces.from 필드가 Same 값을 갖도록 설정됩니다.

다음 예제에서는 전용 게이트웨이 오브젝트에 연결하는 연결된 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
Copy to Clipboard Toggle word wrap

HTTPRoute 리소스에는 게이트웨이에 연결하기 위해 parentRefs 필드의 값으로 Gateway 오브젝트의 이름이 있어야 합니다. 암시적으로 경로는 Gateway 오브젝트와 동일한 네임스페이스에 있는 것으로 간주됩니다.

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

다음 예제에서는 shared -gateway- access: "true" 를 포함하는 모든 네임스페이스와 일치하도록 spec.listeners.allowedRoutes.namespaces 레이블 선택기가 설정된 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"
Copy to Clipboard Toggle word wrap

다음 예제에서는 Cryostat -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"
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
Copy to Clipboard Toggle word wrap

공유 게이트웨이 토폴로지를 사용하면 경로가 연결할 게이트웨이 오브젝트의 네임스페이스를 지정해야 합니다. 여러 Gateway 오브젝트를 네임스페이스에서 배포하고 공유할 수 있습니다. 공유 게이트웨이가 여러 개인 경우 이 토폴로지는 Ingress 컨트롤러 샤딩과 개념적으로 유사합니다.

추가 리소스

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat