GatewayClass: kontrakt z implementacją

Minimalny model

Relacja wygląda tak:

GatewayClass
  |
  v
Gateway
  |
  v
HTTPRoute

HTTPRoute podpina się do Gateway.

Gateway wskazuje GatewayClass.

GatewayClass wskazuje implementację przez controllerName.

Przykład:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: public
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller

To nie tworzy jeszcze wejścia ruchu.

To mówi:

Gateway z gatewayClassName: public
obsługuje kontroler Envoy Gateway

GatewayClass jest dla platformy

Zespół aplikacyjny zwykle nie powinien tworzyć własnych GatewayClass.

To jest decyzja platformowa:

jakie implementacje dopuszczamy?
które są publiczne?
które są prywatne?
które mają dostęp do Internetu?
które są tylko internal?
które mają wspólne polityki bezpieczeństwa?

W małym klastrze może istnieć jedna klasa:

public

W większym środowisku mogą istnieć osobne klasy:

public
internal
mesh
edge
regional

Nazwy nie są częścią standardu. Standard definiuje mechanizm, nie słownik organizacji.

Klasa nie gwarantuje tych samych funkcji wszędzie

Gateway API jest specyfikacją.

Implementacja decyduje, jak obsłuży konkretne funkcje i które rozszerzenia udostępni.

Dlatego dwie klasy mogą wyglądać podobnie:

public-nginx
public-envoy

ale różnić się w zachowaniu:

regex path matching
timeouts
body size
header manipulation
TLS options
observability
custom filters

W Ingress takie różnice często chowały się w adnotacjach.

W Gateway API powinny być jawniejsze: przez standardowe pola, polityki albo rozszerzenia implementacji.

Rodzaje GatewayClass w praktyce

Nie ma oficjalnych typów GatewayClass typu:

PublicGatewayClass
PrivateGatewayClass
MeshGatewayClass

Jest jeden zasób GatewayClass.

Rodzaje powstają z decyzji platformy.

Przykład podziału:

public
  wejście z Internetu
  TLS wymagany
  ograniczone namespace'y

internal
  wejście tylko z sieci prywatnej
  bez publicznego adresu
  inne reguły DNS

mesh
  integracja z service mesh
  polityki tożsamości usług

experimental
  nowa implementacja
  bez ruchu produkcyjnego

To jest rola GatewayClass: nazwać dopuszczony wariant infrastruktury.

Nie per aplikacja.

Per sposób dostarczania ruchu.

Dlaczego to ma znaczenie przy migracji

Przy migracji z ingress-nginx łatwo zacząć od pytania:

jak przepisać Ingress na HTTPRoute?

To jest za późno.

Najpierw trzeba wiedzieć:

jaka GatewayClass zastępuje ingressClassName: nginx?

Jeżeli wcześniej było:

spec:
  ingressClassName: nginx

to nowy model potrzebuje odpowiedzi:

spec:
  gatewayClassName: public

albo:

spec:
  gatewayClassName: nginx

albo jeszcze inaczej, zależnie od implementacji i polityki platformy.

To nie jest kosmetyka nazwy.

To decyzja, jaki kontroler programuje realną ścieżkę ruchu.

Dobra nazwa klasy mówi prawdę

Słaba nazwa:

gateway

Lepsza nazwa:

public
internal
edge
mesh

Jeszcze lepsza, jeśli organizacja ma kilka implementacji:

public-envoy
internal-nginx
mesh-istio

Nazwa powinna pomagać zespołowi aplikacyjnemu wybrać poprawny wariant bez czytania implementacyjnych szczegółów.

Ale nie powinna udawać, że implementacja nie istnieje.

Bo przy debugowaniu ona wraca zawsze:

manifest
  |
  v
controller
  |
  v
proxy or cloud load balancer
  |
  v
request

GatewayClass jest miejscem, w którym ten łańcuch zaczyna być konkretny.