1장. 게이트웨이 정보


게이트웨이는 독립 실행형 Envoy 프록시 배포이며 서비스 메시의 에지에서 작동하는 관련 Kubernetes 서비스입니다. 메시를 입력하거나 떠나는 트래픽을 세밀하게 제어하도록 게이트웨이를 구성할 수 있습니다. Red Hat OpenShift Service Mesh에서는 게이트웨이 삽입을 사용하여 게이트웨이를 설치합니다.

1.1. 게이트웨이 삽입 정보

게이트웨이 삽입은 사이드카 삽입과 동일한 메커니즘을 사용하여 Envoy 프록시를 게이트웨이 포드에 삽입합니다. 게이트웨이 삽입을 사용하여 게이트웨이를 설치하려면 Istio 컨트롤 플레인에 표시되는 네임스페이스에 Kubernetes Deployment 오브젝트 및 관련 Kubernetes Service 오브젝트를 생성합니다. Istio 컨트롤 플레인에서 프록시를 삽입하고 프록시가 게이트웨이로 구성되도록 Deployment 오브젝트를 생성하고 주석을 답니다. 게이트웨이를 설치한 후 Istio GatewayVirtualService 리소스를 사용하여 수신 및 송신 트래픽을 제어하도록 게이트웨이를 구성합니다.

1.1.1. 게이트웨이 삽입을 사용하여 게이트웨이 설치

다음 절차에서는 게이트웨이 삽입을 사용하여 게이트웨이를 설치하는 방법을 설명합니다.

참고

이 절차를 사용하여 수신 또는 송신 게이트웨이를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift Service Mesh Operator 버전 3.0 이상을 설치했습니다.
  • Istio 컨트롤 플레인을 생성했습니다.
  • IstioCNI 리소스를 생성했습니다.

프로세스

  1. 게이트웨이를 설치하는 데 사용할 네임스페이스를 만듭니다.

    $ oc create namespace <gateway_namespace>
    Copy to Clipboard Toggle word wrap
    참고

    다른 네임스페이스에 게이트웨이 및 Istio 컨트롤 플레인을 설치합니다.

    전용 게이트웨이 네임스페이스에 게이트웨이를 설치할 수 있습니다. 이 방법을 사용하면 다른 네임스페이스에서 작동하는 많은 애플리케이션에서 게이트웨이를 공유할 수 있습니다. 또는 애플리케이션 네임스페이스에 게이트웨이를 설치할 수 있습니다. 이 방식에서 게이트웨이는 해당 네임스페이스에서 애플리케이션의 전용 게이트웨이 역할을 합니다.

  2. 게이트웨이 배포에 대한 서비스 계정, 역할, 역할 바인딩을 정의하는 secret-reader.yml 이라는 YAML 파일을 생성합니다. 이러한 설정을 사용하면 게이트웨이에서 TLS 인증 정보를 가져오는 데 필요한 시크릿을 읽을 수 있습니다.

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: secret-reader
      namespace: <gateway_namespace>
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: secret-reader
      namespace: <gateway_namespace>
    rules:
      - apiGroups: [""]
        resources: ["secrets"]
        verbs: ["get", "watch", "list"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name:  secret-reader
      namespace: <gateway_namespace>
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: secret-reader
    subjects:
      - kind: ServiceAccount
        name:  secret-reader
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 YAML 파일을 적용합니다.

    $ oc apply -f secret-reader.yml
    Copy to Clipboard Toggle word wrap
  4. 게이트웨이의 Kubernetes Deployment 오브젝트를 정의하는 gateway-deployment.yml 이라는 YAML 파일을 만듭니다.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: <gateway_name>
      namespace: <gateway_namespace>
    spec:
      selector:
        matchLabels:
          istio: <gateway_name>
      template:
        metadata:
          annotations:
            inject.istio.io/templates: gateway 
    1
    
          labels:
            istio: <gateway_name> 
    2
    
            sidecar.istio.io/inject: "true" 
    3
    
        spec:
          containers:
            - name: istio-proxy
              image: auto 
    4
    
              securityContext:
                capabilities:
                  drop:
                  - ALL
                allowPrivilegeEscalation: false
                privileged: false
                readOnlyRootFilesystem: true
                runAsNonRoot: true
              ports:
              - containerPort: 15090
                protocol: TCP
                name: http-envoy-prom
              resources:
                limits:
                  cpu: 2000m
                  memory: 1024Mi
                requests:
                  cpu: 100m
                  memory: 128Mi
          securityContext:
            sysctls:
            - name: net.ipv4.ip_unprivileged_port_start
              value: "0"
          serviceAccountName: secret-reader 
    5
    Copy to Clipboard Toggle word wrap
    1
    Istio 컨트롤 플레인이 기본 사이드카 템플릿 대신 게이트웨이 삽입 템플릿을 사용함을 나타냅니다.
    2
    게이트웨이 배포에 고유한 레이블이 설정되어 있는지 확인합니다. Istio Gateway 리소스에서 게이트웨이 워크로드를 선택할 수 있도록 고유한 레이블이 필요합니다.
    3
    sidecar.istio.io/inject 레이블을 true 로 설정하여 게이트웨이 삽입을 활성화합니다. Istio 리소스의 이름이 기본값이 아닌 경우 대신 istio.io/rev: <istio_revision > 레이블을 사용해야 합니다. 여기서 리버전은 Istio 리소스의 활성 버전을 나타냅니다.
    4
    Pod가 시작될 때마다 이미지가 자동으로 업데이트되도록 image 필드를 auto 로 설정합니다.
    5
    serviceAccountName 을 이전에 생성한 ServiceAccount 의 이름으로 설정합니다.
  5. 다음 명령을 실행하여 YAML 파일을 적용합니다.

    $ oc apply -f gateway-deployment.yml
    Copy to Clipboard Toggle word wrap
  6. 다음 명령을 실행하여 게이트웨이 배포 롤아웃이 성공했는지 확인합니다.

    $ oc rollout status deployment/<gateway_name> -n <gateway_namespace>
    Copy to Clipboard Toggle word wrap

    출력은 다음과 유사합니다.

    출력 예

    Waiting for deployment "<gateway_name>" rollout to finish: 0 of 1 updated replicas are available...
    deployment "<gateway_name>" successfully rolled out
    Copy to Clipboard Toggle word wrap

  7. 게이트웨이의 Kubernetes Service 오브젝트가 포함된 gateway-service.yml 이라는 YAML 파일을 만듭니다.

    apiVersion: v1
    kind: Service
    metadata:
      name: <gateway_name>
      namespace: <gateway_namespace>
    spec:
      type: ClusterIP 
    1
    
      selector:
        istio: <gateway_name> 
    2
    
      ports:
        - name: status-port
          port: 15021
          protocol: TCP
          targetPort: 15021
        - name: http2
          port: 80
          protocol: TCP
          targetPort: 80
        - name: https
          port: 443
          protocol: TCP
          targetPort: 443
    Copy to Clipboard Toggle word wrap
    1
    spec.typeClusterIP 로 설정하면 게이트웨이 서비스 오브젝트에 클러스터 내에서만 액세스할 수 있습니다. 게이트웨이가 클러스터 외부에서 수신 트래픽을 처리해야 하는 경우 spec.typeLoadBalancer 로 설정합니다. 또는 OpenShift 경로를 사용할 수 있습니다.
    2
    선택기 를 이전에 생성한 게이트웨이 배포의 Pod 템플릿에 지정된 고유한 레이블 또는 일련의 레이블로 설정합니다.
  8. 다음 명령을 실행하여 YAML 파일을 적용합니다.

    $ oc apply -f gateway-service.yml
    Copy to Clipboard Toggle word wrap
  9. 다음 명령을 실행하여 게이트웨이 서비스가 게이트웨이 Pod의 끝점을 대상으로 하는지 확인합니다.

    $ oc get endpoints <gateway_name> -n <gateway_namespace>
    Copy to Clipboard Toggle word wrap

    다음 예와 유사한 출력이 표시됩니다.

    출력 예

    NAME              ENDPOINTS                             AGE
    <gateway_name>    10.131.0.181:8080,10.131.0.181:8443   1m
    Copy to Clipboard Toggle word wrap

  10. 선택 사항: 게이트웨이의 수평 Pod 자동 스케일러를 정의하는 gateway-hpa.yml 이라는 YAML 파일을 만듭니다. 다음 예제에서는 최소 복제본을 2 로 설정하고 최대 복제본을 5 로 설정하고 평균 CPU 사용률이 CPU 리소스 제한의 80%를 초과하면 복제본을 확장합니다. 이 제한은 게이트웨이의 배포 Pod 템플릿에 지정됩니다.

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      name: <gateway_name>
      namespace: <gateway_namespace>
    spec:
      minReplicas: 2
      maxReplicas: 5
      metrics:
      - resource:
          name: cpu
          target:
            averageUtilization: 80
            type: Utilization
        type: Resource
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <gateway_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    spec.scaleTargetRef.name 을 이전에 생성한 게이트웨이 배포 이름으로 설정합니다.
  11. 선택 사항: 다음 명령을 실행하여 YAML 파일을 적용합니다.

    $ oc apply -f gateway-hpa.yml
    Copy to Clipboard Toggle word wrap
  12. 선택 사항: 게이트웨이의 Pod 중단 예산을 정의하는 gateway-pdb.yml 이라는 YAML 파일을 만듭니다. 다음 예제에서는 제거 후 최소 1개의 정상 게이트웨이 Pod가 클러스터에 남아 있는 경우에만 게이트웨이 Pod를 제거할 수 있습니다.

    apiVersion: policy/v1
    kind: PodDisruptionBudget
    metadata:
      name: <gateway_name>
      namespace: <gateway_namespace>
    spec:
      minAvailable: 1
      selector:
        matchLabels:
          istio: <gateway_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    spec.selector.matchLabels 를 이전에 생성한 게이트웨이 배포의 Pod 템플릿에 지정된 고유한 라벨 또는 세트로 설정합니다.
  13. 선택 사항: 다음 명령을 실행하여 YAML 파일을 적용합니다.

    $ oc apply -f gateway-pdb.yml
    Copy to Clipboard Toggle word wrap
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat