후기

장소는 구글코리아 본사에서 진행하였습니다. 맛있는 도시락도 같이 준비해 주셔서 저녁식사도 맛있게 했습니다. (도시락 이름이 쿠벤이던데…쿠버네티스 벤또..?)

세미나는 두챕터로 나뉘어져있었습니다. 1부는 F5 NGINX 김재홍님의 “새로운 Kubernetes Gateway API 로 미래의 네트워킹을 열다” 그리고 2부에서는 스마일게이트의 유지연님의 “Admission webhook 직접 개발하지 마세요, kyverno에 양보하세요” 를 준비해 주셨습니다.

들으면서 두분이 준비해주신 내용의 질도 너무 좋았고 자칫 어려울만한 내용도 적절한 비유와 함께 설명해주시니 즐겁고 도움이 많이되는 시간이었습니다.

간략하게 Kubernetes Gateway API 에 대해서 설명 드리고, kyverno, Admission webhook 에 대해서는 추후 따로 포스팅하도록 하겠습니다.

Kubernetes Gateway API 란 무엇인가요?

Ingress 리소스 보다 좋은점은?

기존의 인그레스(Ingress) 리소스는 단순한 라우팅에는 충분했지만, 복잡한 트래픽 관리에는 한계가 있었습니다. 예를 들어, 다양한 프로토콜(HTTP, TCP 등)을 처리하거나, 조건에 따라 라우팅을 변경하는 것 등이 어렵습니다. 또한 기존의 Ingress 의 부족한점을 매꾸기위해 Nginx Ingress 가 등장했지만, 이는 Kubernetes 클러스터에 국한되기 때문에 다른 환경에 소스배포시 의존성 문제가 발생하기 마련이었습니다. 이 문제를 해결하기 위해 Gateway API가 등장했습니다.

주요 기능

아래 내용은 Kubernetes Document 에서 소개하는 주요 기능들을 간략하게 정리하였습니다.

• 포괄적인 라우팅 : HTTP, HTTPS, TCP, TLS, UDP 등의 다양한 프로토콜을 지원하여 트래픽을 유연하게 라우팅할 수 있습니다.

• 정교한 매칭 조건 : 경로, 헤더, 쿠키, 메소드 등 다양한 매칭 조건을 사용하여 트래픽을 정교하게 제어할 수 있습니다.

• 확장성 및 플러그인: 여러 Gateway와 Route를 동시에 사용할 수 있으며, 플러그인을 통해 기능을 확장할 수 있습니다. 또한  다양한 서드파티 제공자와의 호환성을 높여, 클러스터에 적합한 네트워크 솔루션을 선택할 수 있습니다.

• 포트 및 프로토콜 관리 : 단일 Gateway에서 여러 포트와 프로토콜을 관리하여 복잡한 네트워크 트래픽 시나리오를 처리할 수 있습니다.

• 정책 기반 트래픽 제어 : RBAC(역할 기반 접근 제어)와 같은 정책을 통해 트래픽 제어 권한을 세밀하게 관리할 수 있습니다.

• 유연한 트래픽 분산 및 리다이렉션 : 트래픽을 여러 백엔드 서비스로 분산하거나 특정 조건에 따라 리다이렉션할 수 있습니다.

간단한 예시 – 쇼핑몰 웹사이트

Gateway API를 사용하여 쇼핑몰 웹사이트를 운영한다면 어떤 식으로 구성하게 되는지 간단한 예시를 통해 설명드리겠습니다. 이 시나리오에서는 3가지 기능을 구현할 예정입니다.

1. 트래픽 라우팅:

   • 웹사이트의 모든 HTTP 요청은 웹서버로 라우팅.
   • 결제와 관련된 모든 요청은 결제 서버로 라우팅.

2. 트래픽 우회:

   • 특정 시간대(예: 밤 12시~새벽 2시)에는 트래픽을 유지 보수 서버로 우회.

3. 위치 기반 라우팅:

   • 사용자 위치에 따라 가장 가까운 데이터 센터로 트래픽 라우팅.

(완벽하게 구성하기 위해서는 다른 리소스들도 추가하여야 하지만, 그렇게하면 너무 어려워지고 본문에 집중하기 힘들어지므로 해당부분은 생략합니다. 이러한 기능도 있다는 느낌으로 봐주시기 바랍니다. 추후에 쿠버네티스 관련 포스팅을 추가로 하도록 하겠습니다.)

1. 트래픽 라우팅

Gateway와 HTTPRoute 리소스를 사용하여, 웹사이트와 결제 시스템의 요청을 각각의 서버로 트래픽 라우팅하기 위한 설정입니다.

# 기본 Gateway 리소스 정의
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
  name: shopping-gateway  # Gateway의 이름
spec:
  gatewayClassName: my-gateway-class  # 사용할 GatewayClass의 이름
  listeners:  # 트래픽을 수신할 리스너 설정
    - protocol: HTTP  # 리스너의 프로토콜 (HTTP)
      port: 80  # 리스너의 포트 (80)
      routes:  # 연결할 Route 설정
        kind: HTTPRoute  # Route의 종류 (HTTPRoute)
        selector:
          matchLabels:
            gateway: shopping-gateway  # 연결할 HTTPRoute의 라벨 셀렉터

---
# 웹 트래픽 라우팅을 위한 HTTPRoute 정의
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: web-route  # HTTPRoute의 이름
spec:
  hostnames:
    - "shop.example.com"  # 이 Route가 적용될 호스트 이름
  rules:
    - matches:
        - path:
            type: Prefix  # 경로 매칭 유형 (Prefix)
            value: /  # 모든 경로에 대해 매칭
      forwardTo:
        - serviceName: web-service  # 트래픽을 보낼 서비스 이름 (web-service)
          port: 80  # 서비스의 포트

---
# 결제 트래픽 라우팅을 위한 HTTPRoute 정의
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: payment-route  # HTTPRoute의 이름
spec:
  hostnames:
    - "shop.example.com"  # 이 Route가 적용될 호스트 이름
  rules:
    - matches:
        - path:
            type: Prefix  # 경로 매칭 유형 (Prefix)
            value: /payment  # /payment 경로에 대해 매칭
      forwardTo:
        - serviceName: payment-service  # 트래픽을 보낼 서비스 이름 (payment-service)
          port: 443  # 서비스의 포트 (HTTPS 사용)

2. 트래픽 우회

HTTPRoute의 matches와 filter 기능을 사용하여, 특정 시간대에는 트래픽을 유지 보수 서버로 우회시킬 수 있습니다.

(아래 설정에는 시간값은 없지만 Cronjob 과 함께 사용한다면 특정시간대에 트래픽 우회가 가능합니다)

# 유지 보수 시간대에 트래픽 우회를 위한 HTTPRoute 정의
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: maintenance-route  # HTTPRoute의 이름
spec:
  hostnames:
    - "shop.example.com"  # 이 Route가 적용될 호스트 이름
  rules:
    - matches:
        - path:
            type: Prefix  # 경로 매칭 유형 (Prefix)
            value: /  # 모든 경로에 대해 매칭
      filters:
        - type: RequestHeaderModifier  # 요청 헤더 수정 필터
          requestHeaderModifier:
            add:
              X-Maintenance-Mode: "true"  # 유지 보수 모드 헤더 추가
      forwardTo:
        - serviceName: maintenance-service  # 트래픽을 보낼 서비스 이름 (maintenance-service)
          port: 80  # 서비스의 포트
      conditions:
        - type: Header  # 조건 유형 (헤더)
          header:
            name: X-Maintenance-Mode  # 조건으로 사용할 헤더 이름
            value: "true"  # 헤더 값이 "true"일 때 매칭

3. 위치 기반 라우팅

HTTPRoute의 matches와 filter 기능을 사용하여, 사용자 위치에 따라 트래픽을 라우팅할 수 있습니다. 아래 예시는 GeoIP 정보를 기반으로 합니다.

# 위치 기반 트래픽 라우팅을 위한 HTTPRoute 정의
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: geo-routing  # HTTPRoute의 이름
spec:
  hostnames:
    - "shop.example.com"  # 이 Route가 적용될 호스트 이름
  rules:
    - matches:
        - headers:
            - name: X-Geo-Region  # 매칭할 헤더 이름
              value: "us-west"  # 헤더 값이 "us-west"일 때 매칭
      forwardTo:
        - serviceName: us-west-service  # 트래픽을 보낼 서비스 이름 (us-west-service)
          port: 80  # 서비스의 포트
    - matches:
        - headers:
            - name: X-Geo-Region  # 매칭할 헤더 이름
              value: "us-east"  # 헤더 값이 "us-east"일 때 매칭
      forwardTo:
        - serviceName: us-east-service  # 트래픽을 보낼 서비스 이름 (us-east-service)
          port: 80  # 서비스의 포트

위 예시와 같이  Gateway와 HTTPRoute 리소스를 사용하여 트래픽을 웹서버와 결제 서버로 라우팅하고,  HTTPRoute의 filters를 사용하여 특정 시간대에 트래픽을 유지 보수 서버로 우회시키며, HTTPRoute의 matches와 headers를 사용하여 사용자 위치에 따라 트래픽을 가장 가까운 서버로 라우팅할 수 있습니다.

기존의 ingress 로는 어려웠던 세부적인 네트워크 트래픽관리를 위 예시와 같이 컨트롤 할 수 있습니다.

Kubernetes 10 주년

끝나고 나오니 이쁜케이크와 맛있는 떡이 준비되어 있더군요, 정성을 많이들인듯 했습니다.

Kubernetes가 등장한 지 10년이 지났지만, 여전히 매년 새로운 유입이 있을 정도로 뜨거운 기술입니다.

이번 행사 역시 정해진 참여 인원이 빠르게 마감될 정도로 많은 관심을 받았습니다. 많은 사람들이 주목하는 기술이니만큼 저도 더욱 관심을 가져야겠다고 생각했습니다.

다양한 업계 전문가들이 참석하여 실무에서의 활용 사례와 앞으로의 방향에 대해 이야기하는 시간이 매우 유익했으며, 추후 행사에도 꼭 참여해야겠다는 생각이 많이 들었습니다.

kyverno 에 대해서 포스팅할 때 다시 찾아뵙겠습니다.