Gateway API, AWS Gateway API Controller

안녕하세요?
AEWS 12주차 마지막 과제로 Gateway API, AWS Gateway API Controller에 대해서 정리해보겠습니다.

 

Gateway API 와 Ingress의 차이

아래 그림으로 Ingress와 Gateway API의 구조 차이를 간단하게 살펴볼 수 있습니다.

출처 : https://medium.com/google-cloud/kubernetes-ingress-vs-gateway-api-647ee233693d

 

Gateway API 와 AWS VPC Lattice 와의 관계

아래 그림으로 Gateway API와 AWS VPC Lattice와의 관계를 간단하게 살펴볼 수 있습니다.

출처 : https://aws.amazon.com/ko/blogs/containers/introducing-aws-gateway-api-controller-for-amazon-vpc-lattice-an-implementation-of-kubernetes-gateway-api/

출처: https://whchoi98.gitbook.io/amazon-vpc-lattice/05.gateway-api-controller/aws-gateway-api-controller

 

Kubernetes Gateway API 에 대하여

Kubernetes Gateway API 의 필요성

 

기존 Kubernetes 의 네트워크 방식들은 각자 한계점을 안고 있었습니다.

 

Ingress의 한계

• HTTP, HTTPS와 같은 L7 트래픽에 최적화 되어있어 gRPC 및 TPC, UDP와 같은 비 L7 프로토콜에 대한 라우팅 기능이 제한적이었습니다.
• 고급 기능(인증, 속도 제한 정책, 고급 트래픽 관리 등)을 사용하려면 벤더별(AWS, NGINX, HAProxy 등) 사용자 정의 어노테이션이 필요하여 이식성과 표준화에 한계가 존재했습니다.

Istio와 같은 Service Mesh의 한계

• 주로 동-서 트래픽(서비스 간 내부 통신)에 초점을 맞추어 설계되어 북-남 트래픽(외부-내부 통신)에 대한 기능이 제한적이였습니다.
  • Amazon EKS의 경우, VPC Peering 및 TGW가 필요 → 점점 늘어나는 설정들과 네트워크 리소스들
  • 여러 AWS 계정을 사용할 경우, 각각 교차 계정 액세스 설정이 필요 → 권한 관리의 어려움
• 사이드카 프록시 배포가 필수적이며, 멀티 VPC 클라우드 환경에서 네트워크 복잡도가 증가하였습니다. (멀티 클러스터, 멀티 메시의 수많은 프록시 운영 및 관리의 어려움)

또한, 클라우드 환경에서 점차 마이크로 서비스가 확장되고 인프라 구성이 복잡해짐에 따라 아래와 같은 요구사항도 생겨났습니다.

• 다양한 팀 간의 책임 분리(인프라 담당자, 애플리케이션 개발자, DevOps 엔지니어 등)가 필요해졌습니다.
• 여러 VPC 또는 멀티 클러스터 환경에 걸친 리소스들을 일관되게 관리해야 했습니다.
• 다양한 컴퓨팅 형태(인스턴스, 컨테이너, 서버리스 등)를 통합적으로 관리할 수 있는 네트워킹 레이어가 필요했습니다.

 

Kubernetes Gateway API 란?

 

이런 여러가지 문제점들을 해결하기 위해서 Gateway API가 생겼습니다.

• 역할 기반 설계: 인프라 관리자, 클러스터 운영자, 애플리케이션 개발자 각각의 요구사항을 반영할 수 있도록 설계되었습니다.
• 범용성: HTTP, HTTPS, gRPC 등 다양한 프로토콜을 지원하고 확장성 있게 설계되었습니다.
• 표준화: Kubernetes Ingress와 같이 포터블한 표준 API가 되도록 설계되었습니다.
• 확장성: 멀티 클러스터 환경 및 다양한 VPC 간의 원활한 네트워크 통합이 가능하도록 설계되었습니다.

Gateway API의 주요 구성요소

아래 그림이 Gateway API의 리소스들을 보여줍니다.
위에서 얘기한대로 역할 기반 설계가 되어 있습니다. 리소스별 담당자 Infrastructure Provider, Cluster Operator, Application Developer의 역할 분배를 의도 했음이 보입니다.

출처: https://gateway-api.sigs.k8s.io/api-types/httproute/

 

 

GatewayClass

인프라 제공자가 정의하는 클러스터 범위의 리소스입니다.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  name: istio-gateway 
spec:
  controllerName: "istio.io/gateway-controller" 

 

 

Gateway

• 외부 트래픽을 수신하고 내부 서비스로 라우팅하는 진입점을 정의합니다.
• 하나 이상의 Route 리소스와 연결될 수 있습니다.

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: Gateway
  metadata:
  name: mygateway # HTTPRoute resource에서 사용할 이름
  namespace: mysystem
  spec:
  gatewayClassName: istio-gateway # GatewayClass resource의 name 참조
  listeners:
  - name: http-a # 80 port의 HTTP로 a.example.com의 host traffic을 수신
    hostname: "a.example.com"
    port: 80
    protocol: HTTP
  - name: https-b # 443 port의 HTTPS로 b.example.com의 host traffic을 수신
    hostname: "b.example.com"
    port: 443
    protocol: HTTPS
    tls: # mygateway-credential secret에 저장된 certificate 적용
      mode: Terminate
      certificateRefs:
      - name: mygateway-credential

Routes

• 트래픽을 특정 서비스로 매핑하는 프로토콜 별 규칙을 정의합니다.
• HTTPRoute, TLSRoute, TCPRoute, UDPRoute, GRPCRoute 등이 있습니다.
• Gateway 리소스에 연결되어 트래픽을 대상 서비스로 전달합니다.

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
  name: httpbin
  spec:
  parentRefs:
  - name: mygateway # Gateway resource의 name 참조
    namespace: mysystem
  hostnames: 
    - "a.example.com" # rule 적용 대상 incoming host
  rules:
  - matches:
    - path: # /status path를 prefix로 하는 traffic에 대해 적용
        type: PathPrefix
        value: /status 
    - path: # /delay path를 prefix로 하는 traffic에 대해 적용
        type: PathPrefix
        value: /delay
    backendRefs: # httpbin service의 8000 port로 traffic을 routing
    - name: httpbin
      port: 8000

 

Amazon VPC Lattice에 대하여

Amazon VPC Lattice란?

Amazon VPC Lattice는 애플리케이션의 서비스 및 리소스를 연결, 보호 및 모니터링하는 데 사용하는 완전관리형 애플리케이션 네트워킹 서비스입니다. VPC Lattice는 단일 Virtual Private Cloud(VPC)와 함께 사용하거나 계정 하나 이상의 여러 VPC에서 사용할 수 있습니다.
https://docs.aws.amazon.com/ko_kr/vpc-lattice/latest/ug/what-is-vpc-lattice.html

Amazon VPC Lattice의 구성요소

Amazon VPC Lattice는 Service, Service Network, Auth Policy, Service Directory의 네 가지 핵심 구성 요소로 이루어져 있습니다.

Service

Service는 특정 작업이나 기능을 수행하는 독립적으로 배포가능한 소프트웨어 단위입니다. 이는 어떤 Amazon Virtual Private Cloud(VPC)나 계정에도 존재할 수 있으며, 다양한 유형의 컴퓨팅 환경(가상머신, 컨테이너, 서버리스 함수)에서 실행할 수 있습니다. 서비스 구성은 다음과 같은 요소로 이루어집니다.

• 리스너 : 리스너에서는 Service가 트래픽을 받아들일 포트와 프로포콜을 정의합니다. 지원되는 프로토콜은 HTTP/1.1, HTTP/2, gRPC이며, TLS가 활성화된 Service의 경우 HTTPS도 포함됩니다.
• 규칙 : 리스너의 기본 구성 요소로, 요청을 대상 그룹의 대상들로 전달합니다. 각 규칙은 우선 순위, 하나 이상의 작업, 그리고 리스너가 클라이언트 요청을 라우팅하는 기준이 되는 하나 이상의 조건으로 구성됩니다.
• 대상 그룹 : 애플리케이션이나 서비스를 실행하는 리소스들의 집합으로, 이를 대상 이라고도 합니다. 대상은 EC2 인스턴스, IP주소, Lambda 함수, 또는 Kubernetes Pod가 될 수 있습니다.

 

Service는 다음과 같은 특징을 갖습니다.

• 고유한 VPC Lattice 도메인 네임 제공
• 리스너를 통해 들어오는 연결 처리
• 특정 경로나 헤더 값에 기반한 라우팅 규칙 정의
• EC2, ECS, Lambda 등 다양한 AWS 컴퓨팅 서비스를 대상으로 설정 가능
• 상태 확인을 통한 트래픽 안정성 보장

Service Network

Service Network는 VPC Lattice의 핵심 구성 요소로, 여러 서비스를 논리적으로 그룹화하고 이들 간의 통신을 관리합니다. 하나 이상의 VPC를 Service Network에 연결하여 해당 네트워크 내의 서비스 간 통신을 가능하게 합니다.

Service Network의 주요 특징은 다음과 같습니다.

• 여러 VPC와 서비스를 단일 네트워크로 통합
• 계정 간, 리전 간 서비스 연결 지원
• 중앙 집중식 액세스 제어 및 모니터링 제공
• VPC 연결을 통한 Service Network 내 서비스에 대한 접근 관리

Auth Policy

Auth Policy는 VPC Lattice 서비스에 대한 액세스를 제어하는 IAM 기반 정책입니다. 이를 통해 특정 IAM 보안 주체나 역할이 서비스에 접근할 수 있는지 여부를 세밀하게 제어할 수 있습니다.

Auth Policy의 주요 기능은 다음과 같습니다.

• IAM 기반의 세분화된 접근 제어
• 서비스 레벨 또는 서비스 네트워크 레벨에서 적용 가능
• HTTP 메소드, 경로, 헤더 등을 기준으로 조건부 액세스 규칙 설정
• AWS 리소스 간의 안전한 통신 보장

Service Directory

Service Directory는 모든 VPC Lattice 서비스를 중앙에서 검색하고 관리할 수 있는 카탈로그입니다. 개발자와 운영팀이 사용 가능한 서비스를 쉽게 찾고 접근할 수 있도록 지원합니다.

Service Directory의 핵심 기능은 다음과 같습니다.

• 사용 가능한 모든 서비스의 중앙 집중식 카탈로그 제공
• 서비스 메타데이터 및 설명 관리
• 서비스 검색 및 필터링 기능
• 접근 가능한 서비스에 대한 가시성 제공

Amazon VPC Lattice의 장점

• 여러 VPC, EC2 인스턴스, 컨테이너, 서버리스로 구성한 애플리케이션의 네트워크 구성을 중앙 집중화 할 수 있습니다.
• 별도의 사이드카 프록시를 구성할 필요가 없습니다. (+ 완전 관리형 서비스)
• 복잡한 네트워크 구성을 단순화 해서 쉽게 사용할 수 있습니다.
• IAM 및 SigV4를 통해 각 애플리케이션으로의 보안 구성을 손쉽게 적용 할 수 있습니다.
• CloudWatch, S3, Kinesis Data Firehose를 통해 쉽게 로깅, 트래픽 패턴 분석 등을 수행할 수 있습니다.

사용 사례 #1 : 단일 리전의 애플리케이션 간 연결

사용 사례 #2 : 온프레미스에서 AWS에 배포된 애플리케이션으로 접근하는 경우

사용 사례 #3 : 여러 AWS 리전에 걸친 애플리케이션 간의 연결

AWS Gateway API Controller

AWS Gateway API Controller는 Gateway API에 의해 정의된 사용자 지정 리소스를 확장하여 Kubernetes API를 사용하여 VPC Lattice 리소스를 생성합니다.

 

이 Controller가 클러스터에 설치되면 Controller는 Gateway API의 리소스(Gateway 및 Route)의 생성을 감시하고 적절한 Amazon VPC Lattice 오브젝트를 프로비저닝 합니다.

 

이를 통해 사용자는 커스텀 코드를 작성하거나 사이드카 프록시를 관리할 필요 없이 Kubernetes API를 사용하여 VPC Lattice Service, VPC Lattice Service Network 및 Target Group을 구성할 수 있습니다.

 

Gateway API 와 AWS Lattice의 관계

쿠버네티스 사용자는 VPC Lattice API를 사용하여 쿠버네티스 네이티브 환경을 경험할 수 있습니다. 다음 그림은 VPC Lattice 객체가 쿠버네티스 게이트웨이 API 객체에 연결되는 방식을 보여줍니다.

 

그림에서 볼 수 있듯이 VPC Lattice에는 다양한 제어 수준과 연관된 여러 페르소나가 있습니다. 게이트웨이, HTTPRoute 및 서비스를 생성하는 데는 Kubernetes Gateway API 구문이 사용되지만, Kubernetes는 VPC Lattice에서 해당 항목의 세부 정보를 가져옵니다.

• 인프라 공급자GatewayClass : VPC Lattice를 GatewayClass로 식별하기 위해 Kubernetes를 생성합니다 .
• 클러스터 운영자Gateway : VPC Lattice에서 서비스 게이트웨이 및 서비스 네트워크와 관련된 정보와 관련 서비스 정책을 가져오는 Kubernetes를 생성합니다 .
• 애플리케이션 개발자 : HTTPRouteKubernetes 서비스를 가리키는 객체를 생성하는데, 이 객체는 이 경우 특정 Pod로 연결됩니다.

서비스

특정 작업이나 기능을 제공하는 독립적으로 배포 가능한 소프트웨어 단위입니다. 서비스는 EC2 인스턴스 또는 ECS 컨테이너에서 실행되거나, 계정 또는 가상 사설 클라우드(VPC) 내에서 Lambda 함수로 실행될 수 있습니다.

서비스 네트워크

서비스 집합에 대한 논리적 경계입니다. 클라이언트는 서비스 네트워크와 연결된 VPC에 배포된 모든 리소스를 의미합니다. 동일한 서비스 네트워크에 연결된 클라이언트와 서비스는 권한이 부여된 경우 서로 통신할 수 있습니다.

위 그림에서 클라이언트는 두 서비스 모두와 통신할 수 있습니다. VPC와 서비스가 동일한 서비스 네트워크에 연결되어 있기 때문입니다.