Kubernetes Service API 첫 번째 살펴보기

API7.ai

December 18, 2020

Technology

서문

Kubernetes는 클러스터 내부의 서비스를 외부로 노출시키기 위한 여러 솔루션을 가지고 있으며, 그 중에서도 Ingress는 외부로 서비스를 노출시키는 표준으로, 여러 제3자 구현체가 있으며 각각의 기술 스택과 서로 호환되지 않는 게이트웨이에 대한 의존성을 가지고 있습니다.

다양한 Ingress 구현을 통일하고 Kubernetes에서의 일관된 관리를 용이하게 하기 위해, SIG-NETWORK 커뮤니티는 Kubernetes Service APIs를 발표했습니다. 이는 두 번째 세대의 Ingress라고 불리는 표준 구현체입니다.

주제 설명

이 글은 Kubernetes Service APIs의 기본 개념을 소개하며, 몇 가지 질문으로 시작합니다.

소개

Kubernetes Service APIs는 두 번째 세대 Ingress 기술이라고 불리는데, 첫 번째 세대보다 어떤 점에서 더 나은가

Kubernetes Service APIs는 Ingress에 국한되지 않고, 서비스 네트워킹을 강화하기 위해 설계되었으며, 표현력, 확장성, RBAC에 중점을 두고 있습니다.

  1. 더 많은 기능, 예를 들어 헤더, 가중치를 기반으로 트래픽을 관리합니다.
kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
---
matches:
  - path:
      value: "/foo"
    headers:
      values:
        version: "2"
  - path:
      value: "/v2/foo"
  1. 확장성 강화, Service APIs는 다층 API 개념을 도입하여 각 계층이 자체 인터페이스를 노출시키고, 다른 사용자 정의 리소스가 API와 인터페이스하여 더 세밀한(API 수준의) 제어를 가능하게 합니다.

api-model

  1. 역할 기반 RBAC: 다층 API의 구현은 사용자 관점에서 리소스 객체를 설계하는 아이디어 중 하나입니다. 이러한 리소스는 결국 Kubernetes에서 애플리케이션을 실행하는 일반적인 역할과 매핑됩니다.

Kubernetes Service APIs가 추상화한 리소스 객체는 무엇인가

사용자 역할에 기반하여, Kubernetes Service APIs는 다음과 같은 리소스를 정의합니다:

GatewayClass, Gateway, Route

  1. GatewayClass는 공통 구성과 동작을 가진 게이트웨이 유형의 집합을 정의합니다:
  • Gateway와의 관계는 ingress에서의 ingess.class 어노테이션과 유사합니다;
  • GatewayClass는 동일한 구성과 동작을 공유하는 게이트웨이 그룹을 정의합니다. 각 GatewayClass는 단일 컨트롤러에 의해 처리되며, 컨트롤러는 GatewayClass와 일대다 관계를 가집니다;
  • GatewayClass는 클러스터 리소스입니다. 기능적인 게이트웨이를 갖기 위해서는 최소한 하나의 GatewayClass가 정의되어야 합니다.
  1. Gateway는 클러스터 내부의 서비스로 트래픽을 전환할 수 있는 지점을 요청합니다:
  • 역할: 클러스터 외부에서 클러스터 내부로 트래픽을 가져옵니다. 이는 실제 ingress 엔티티입니다;
  • 특정 LB 구성을 요청하며, 이는 GatewayClass의 구성과 동작의 구현이기도 합니다;
  • Gateway 리소스는 운영자에 의해 직접 생성되거나, GatewayClass를 처리하는 컨트롤러에 의해 생성될 수 있습니다;
  • Gateway와 Route는 다대다 관계입니다.
  1. Route는 게이트웨이를 통과하는 트래픽이 서비스에 어떻게 매핑되는지 설명합니다.

schema-uml

또한, Kubernetes Service APIs는 백엔드 서비스의 유연한 구성을 가능하게 하기 위해 BackendPolicy 리소스 객체를 정의합니다.

BackendPolicy 객체를 통해 TLS, 헬스 체크를 구성하고, 서비스 또는 포드와 같은 백엔드 서비스 유형을 지정할 수 있습니다.

Kubernetes Service APIs의 도입이 가져올 변화는 무엇인가

Kubernetes Service APIs는 구현 표준으로서 다음과 같은 변화를 가져옵니다.

  1. 일반성: ingress의 여러 구현체가 있는 것처럼, 여러 구현이 가능합니다. ingress 컨트롤러는 게이트웨이의 특성에 따라 사용자 정의될 수 있지만, 모두 일관된 구성 구조를 가집니다. 하나의 데이터 구조로 여러 ingress 컨트롤러를 구성할 수 있습니다.
  2. 클래스 개념: GatewayClasses는 다양한 유형의 로드 밸런싱 구현을 구성할 수 있습니다. 이러한 클래스는 사용자가 리소스 모델 자체로 사용할 수 있는 기능을 쉽고 명확하게 이해할 수 있게 합니다.
  3. 공유 게이트웨이: 독립적인 라우팅 리소스 HTTPRoute가 동일한 GatewayClass에 바인딩될 수 있도록 함으로써, 로드 밸런서와 VIP를 공유할 수 있습니다. 사용자별로 계층화되어, 팀이 하위 계층 Gateway의 구체적인 구현을 신경 쓰지 않고도 안전하게 인프라를 공유할 수 있습니다.
  4. 유형이 있는 백엔드 참조: 유형이 있는 백엔드 참조를 통해, 라우트는 Kubernetes 서비스나 포드, DB와 같은 상태 저장 세트, 또는 클러스터 외부의 접근 가능한 리소스와 같은 Kubernetes 리소스를 참조할 수 있습니다.
  5. 네임스페이스 간 참조: 다른 네임스페이스의 라우트가 Gateway에 바인딩될 수 있어, 네임스페이스 간 상호 접근이 가능합니다. 또한, Gateway 하위의 라우트가 접근할 수 있는 네임스페이스 범위를 제한할 수도 있습니다.

현재 Kubernetes Service APIs를 지원하는 ingress 구현체는 무엇인가

코드 수준에서 Kubernetes Service APIs 리소스 객체를 지원하는 것으로 알려진 Ingress는 Contour, ingress-gce입니다.

Kubernetes Service APIs는 리소스 읽기 및 쓰기 권한을 어떻게 관리하는가

Kubernetes Service APIs는 사용자 차원에서 3가지 역할로 나뉩니다:

  1. 인프라 제공자 GatewayClass;
  2. 클러스터 운영자 Gateway;
  3. 애플리케이션 개발자 Route.

RBAC(Role Based Access Control)는 Kubernetes 권한 부여에 사용되는 표준입니다. 이를 통해 특정 범위의 리소스에 대해 누가 작업을 수행할 수 있는지 구성할 수 있습니다. RBAC는 위에서 정의한 각 역할을 활성화하는 데 사용될 수 있습니다.

대부분의 경우, 모든 역할이 모든 리소스를 읽을 수 있을 것으로 예상됩니다.

세 계층 모델은 다음과 같은 쓰기 권한을 가집니다.

GatewayClassGatewayRoute
인프라 제공자예예예
클러스터 운영자아니오예예
애플리케이션 개발자아니오아니오예

Kubernetes Service APIs의 확장 포인트는 무엇인가

게이트웨이에 대한 요구사항은 매우 다양하며, 동일한 시나리오를 구현하는 방법도 여러 가지가 있으며 각각 장단점이 있습니다. Kubernetes Service APIs는 다층 리소스 객체를 추출했으며, 일부 확장 포인트도 예약해 두었습니다.

Kubernetes Service APIs는 현재 Route에 초점을 맞추고 있습니다:

  • RouteMatch는 Route 매칭 규칙을 확장합니다.
  • 특정 백엔드 서비스 유형을 지정하여, 위에서 언급한 Kubernetes 리소스 외에도 파일 시스템, 함수 표현식 등을 지원합니다.
  • Route 필터는 요청/응답을 처리하기 위해 Route 생명주기에 확장을 추가합니다.
  • 위의 확장 중 어느 것도 만족시킬 수 없는 경우, 완전히 사용자 정의된 Route를 만들 수 있습니다.

요약

이 글은 질문을 통해 Kubernetes Service APIs에 대한 기본적인 소개를 제공했습니다. 전체적으로, Kubernetes Service APIs는 ingress의 많은 모범 사례를 정제했습니다. 예를 들어, 표현력 강화는 실제로 Route의 기능을 확장하며, BackendPolicy 객체는 거의 모든 Kubernetes 백엔드 리소스를 업스트림으로 지정할 수 있습니다. Kubernetes Service APIs는 현재 리소스 객체를 광범위하게 지정하고 있지만, 리소스 객체 내부의 많은 세부 사항이 논의되어야 하며, 가능한 충돌 시나리오를 방지하기 위해 정의되어야 하며, 구조 내에 일부 변수가 있습니다.

Tags:
Kubernetes
API Gateway Concept
Comparison to Competitors