Краткое изложение знаний по Linux с предложениями и подборками интеллект-карт

некоторое время назад,Kubernetes SIG-Network[1] выпустил долгожданный Gateway API 0.5.0 версия. основные компоненты Api Обновление до beta (v1beta1), что означает, что скоро мы увидим больше проектов, использующих эти примитивы.

Давайте рассмотрим основы API шлюза, для чего он предназначен и какие преимущества он имеет.

Что такое API шлюза K8s?

Gateway API — это новая коллекция официальных ресурсов Kubernetes, которые определяют спецификации, реализованные поставщиками, аналогично тому, как Ingress реализован Google, Amazon и т. д.

Новые ресурсы, которые он представляет:

• Gateway（ beta ）
• GatewayClass ( beta )
• HTTPRoute ( beta )
• ReferenceGrant (все еще в стадии альфа, заменяет ReferencePolicy )
• TCPRoute (все еще на стадии альфа-версии)
• TLSRoute (все еще на стадии альфа-версии)
• UDPRoute (все еще на стадии альфа-версии)

SIG-Network 所述的новыйGateway API[2]Цель：

• ролевой：Gateway Зависит от API ресурсы, эти API Использование и настройка пары ресурсов Kubernetes Смоделируйте организационные роли сервисных сетей.
• Портативный：Это не улучшение,но то, что должно остаться неизменным。как Ingress Это универсальная спецификация с несколькими реализациями, например Gateway. API Разработан как портативная версия, Зависит от Многие реализации поддерживаются.
• Выразительный: Gateway API Поддержка ресурсов, например, на основеheaderсоответствовать、взвешивание трафикаи Другие основные функции,Эти функции доступны только через пользовательские аннотации в Ingress.
• Расширяемый：Gateway API разрешено в API Каждый уровень связывает пользовательские ресурсы. Это делает API Возможна тонкая настройка там, где это необходимо в структуре.

Gateway и GatewayClass — это компоненты уровня инфраструктуры, лежащие в основе компонента XRoute (именно поэтому этот выпуск интересен).

Давайте посмотрим, как на самом деле выглядит эта иерархия:

Ролевой API: один кластер, несколько пользователей, разные роли.

Первым непосредственным преимуществом API шлюза является то, что он позволяет лучше разделить задачи.

Объект Ingress великолепен и представляет собой тонкий объект, который инженерам Devops и приложениям часто приходится совместно выяснять конфигурацию. Разработчики приложений знают маршрутизацию приложения, но часто не знают таких деталей, как сертификаты TLS, которые обычно находятся в домене Devops. , в Эта и другие конфигурации, возникающие в одном и том же объекте Ingress, препятствуют автономии обеих сторон и оставляют больше возможностей для неправильной настройки.

В новом API шлюза API шлюза разделяет эти и другие конфигурации на объекты шлюза и маршрута, позволяя инженерам приложений и инженерам Devops/операторам кластера действовать свободно и безопасно следующим образом:

Упрощенная функциональность

Еще одним важным преимуществом нового API является то, что большая функциональность выражается в определении объекта API шлюза, а не в том, что поставщик определяет его с помощью пользовательских аннотаций. Это усовершенствование дает несколько преимуществ:

1. Переносимость: объекты менее подвержены изменениям с учетом разных поставщиков шлюзов.
2. Экспертиза. Позвольте инженерам сосредоточиться на ознакомлении со спецификациями Kubernetes, а не на спецификациях конкретного поставщика.

Давайте рассмотрим пример: как вы можете определить разделение трафика с помощью объекта Ingress и AWS alb.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: "groundcover-app"
  namespace: "app"
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/actions.blue-green: |
      {
        "type":"forward",
        "forwardConfig":{
          "targetGroups":[
            {
              "serviceName":"groundcover-app-v1",
              "servicePort":"80",
              "weight":80
            },
            {
              "serviceName":"groundcover-app-v2",
              "servicePort":"80",
              "weight":20
            }
          ]
        }
      }
  labels:
    app: groundcover-app
spec:
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: blue-green
                port:
                  name: use-annotation

Как видите, здесь много определений, специфичных для конкретного поставщика, с интенсивным использованием аннотаций, однако при использовании нового API шлюза эквивалентом будет

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: prod-web
spec:
  gatewayClassName: acme-lb
  listeners:
  - protocol: HTTP
    port: 80
    name: prod-web-gw
    allowedRoutes:
      namespaces:
        from: Same

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: "hello-kubernetes"
  labels:
    gateway: prod-web-gw
spec:
  hostnames:
  - app.groundcover.com
  rules:
  - backendRefs:
    - name: groundcover-app-v1
      port: 80
      weight: 90
    - name: groundcover-app-v2
      port: 80
      weight: 10

Как видите, конфигурация здесь намного чище, а определения полностью переносимы!

Маршрутизация между пространствами имен

В рамках понимания того, что существуют разные роли, управляющие разными компонентами в кластере Kubernetes, необходимо поддерживать ссылки между пространствами имен, поскольку эти разные организационные подразделения часто работают в разных пространствах имен, но при этом используют общие компоненты инфраструктуры. Например, сертификат TLS, хост имя и т. д.

Для достижения вышеуказанной функциональности API шлюза поддерживает создание объекта шлюза в кластере и создание объекта маршрута в каждом пространстве имен приложения/подразделения, которое ссылается на него.

Вот инструкция по такой настройке:

Операторы инфраструктуры также могут явно ограничить тех, кто может регистрировать объект Route на шлюзе, который в нашем примере определяется следующим образом:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: shared-gateway
  namespace: infra-ns
spec:
  gatewayClassName: shared-gateway-class
  listeners:
  - name: https
    hostname: "foo.example.com"
    protocol: HTTPS
    port: 443
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            shared-gateway-access: "true"
    tls:
      certificateRefs:
      - name: foo-example-com

Шлюз разрешает использовать общий шлюз только пространствам имен с тегом Shared-Gateway-Access: «true», поэтому в нашем примере объект пространства имен должен быть определен следующим образом:

apiVersion: v1
kind: Namespace
metadata:
  name: infra-ns
  labels:
    shared-gateway-access: "true"
---
apiVersion: v1
kind: Namespace
metadata:
  name: site-ns
  labels:
    shared-gateway-access: "true"
---
apiVersion: v1
kind: Namespace
metadata:
  name: store-ns
  labels:
    shared-gateway-access: "true"

После развертывания этих уровней разработчики приложений могут зарегистрировать свои объекты маршрута, ссылающиеся на общий шлюз.

В нашем примере объект Store Route будет выглядеть следующим образом:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: store
  namespace: store-ns
spec:
  parentRefs:
  - name: shared-gateway
    namespace: infra-ns
  rules:
  - matches:
    - path:
        value: /store
    backendRefs:
    - name: store
      port: 8080

Ценность универсального API K8s

Эта статья во многом опирается на Kubernetes SIG-Network,они взапись[3]новый API отлично справляется со своей задачей, если вам интересно попробовать это сейчас Gateway API,ихздесь[4]Перечисляет доступные реализации。

Kubernetes быстро меняется, хотя адаптироваться к этим изменениям сложно, а иногда и разочаровывающе. Но оно того стоит.

На мой взгляд, сообщество проделало отличную работу по сбору тематических исследований и их ответственному объединению.

Предоставление пользователям Kubernetes возможности приобретать знания в области общих API, а не становиться экспертами по конкретным поставщикам, поможет создавать более зрелые продукты, ориентированные на создание ценности и более легкое применение наших навыков в различных средах.

Исходный текст: https://www.groundcover.com/blog/k8s-gateway-api.

Ссылки

[1]

Kubernetes SIG-Network: https://github.com/kubernetes/community/tree/master/sig-network

[2]

Gateway API: https://gateway-api.sigs.k8s.io/

[3]

Записывать: https://gateway-api.sigs.k8s.io/

[4]

Здесь: https://gateway-api.sigs.k8s.io/implementations/

- END -