Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Serverless Gateway Enhancing: Integration of Alibaba Cloud Knative with Cloud Product ALB

Serverless Gateway Enhancing: Integration of Alibaba Cloud Knative with Cloud Product ALB

This article describes how to integrate ALB in Alibaba Cloud Container Service Knative.

By Li Peng (Yuanyi)

Knative is an open-source Serverless application framework based on Kubernetes. It helps deploy and manage Serverless workloads and build enterprise-class Serverless platforms. Application Load Balancer (ALB) provides load balancing services that target the load scenarios at the application layer, such as HTTP, HTTPS, and Quick UDP Internet Connections (QUIC). ALB is highly elastic and can process a large amount of network traffic for seven layers. In addition, ALB supports gray releases for headers and cookies. This article describes how to integrate ALB in Alibaba Cloud Container Service Knative.

Current Usage of Gateway in Container Service Knative

Currently, Container Service Knative supports community Kourier gateways and the integration with SLB gateways. However, these two gateways still have the following problems in use.

There are a few problems when using the native Kourier gateways provided by the Knative community:

  • The native Kourier gateways provided by the Knative community are deployed in user clusters. Therefore, customers need to be responsible for the O&M of Kourier gateways and cover both the resource costs and O&M costs.
  • Cookie gray release is not supported.
  • Knative is integrated with an SLB gateway. However, the gateway does not support the gray release of headers and cookies.

Target and Benefits

Target: It provides cloud product ALB gateway capabilities in the Serverless Framework (Knative).

Benefits: It enhances the capabilities of Serverless Framework gateways and expands the scenarios applicable to ALB Ingress.

The Solution to Connect ALB

Basic Idea: Convert a Knative Ingress into a Kubernetes Ingress and then create an ALB and forwarding rule with the ALB Ingress Controller. The following figure shows the architecture:

1

Key Designs

  • The corresponding relations between Knative Service, Knative Ingress, and Kubernetes Ingress
  • One Knative Service corresponds to one Knative Ingress and one Kubernetes Ingress.
  • Configuration of vSwitch (Virtual Switch)

A vSwitch should be specified to create an ALB instance. Therefore, users must configure the vSwitch ID in Knative.

Configure the parameters in the knative-serving namespace config-network configmap:

apiVersion: v1
kind: ConfigMap
metadata:
data:
  ingress.class: alb.ingress.networking.knative.dev
  vswitch-ids: vsw-2zeqgkyib34gw1fxxx,vsw-2zefv5qwao4prxxx
  ...
  • Public or Internal Network Access
  • When creating a Knative Service, start creating an ALB.
  • Determine whether to use the Internet based on the Ingress. Create an ALB in the public network by default. If only an Ingress is accessed from an internal network, an internal ALB is created.
  • Internet Access
  • Create Albconfig: knative-internet
  • Internal Network Access
  • Create Albconfig: knative-intranet
  • Gray Release
  • Gray Release based on Traffic Ratio
  • Knative Ingress converts the weight of the revision service into a Kubernetes Ingress gray weight.
  • Gray Release based on Header and Cookie

Header:

  • Knative currently supports the Header mode for gray release, which is implemented using Knative-Serving-Tag: {revision-tag}.

    • Specify the traffic revision corresponding to the Header using annotations in Knative Service.
  • Cookie: Specify the traffic revision corresponding to the Cookie using annotations in Knative Service.

Key Implementations

If you want to implement the integration of Knative and ALB, the key is the gray release based on cookies, headers, and weight ratios. Here, the implementation of gray release is mainly introduced.

Gray Release Based on Traffic Ratio

Knative Ingress converts the weight of the revision service into the gray weight of the Kubernetes Ingress.

Example of Knative Service:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/maxScale: "100"
        autoscaling.knative.dev/minScale: "0"
    spec:
      containers:
      - env:
        - name: TARGET
          value: Knative11
        image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        name: user-container
        ports:
        - containerPort: 8080
          name: http1
          protocol: TCP
  traffic:
  - latestRevision: false
    percent: 50
    revisionName: helloworld-go-00002
  - latestRevision: false
    percent: 50
    revisionName: helloworld-go-00001

Internal conversion to Kubernetes Ingress is listed below:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/actions.forward-default: '{"type":"ForwardGroup","forwardConfig":{"targetGroups":[{"serviceName":"helloworld-go-00002","servicePort":80,"weight":50},{"serviceName":"helloworld-go-00001","servicePort":80,"weight":50}]}}'
  labels:
    knative.aliyun.com/ingress: helloworld-go
  name: helloworld-go
  namespace: default
spec:
  ingressClassName: knative-alb-ingress-internet
  rules:
  - host: helloworld-go.default.example.com
    http:
      paths:
      - backend:
          service:
            name: forward-default
            port:
              name: use-annotation
        path: /
        pathType: Prefix
  - host: helloworld-go.default.svc.cluster.local
    http:
      paths:
      - backend:
          service:
            name: forward-default
            port:
              name: use-annotation
        path: /
        pathType: Prefix

Service access:

$ curl ${INGRESS_DNS} -H "Host:helloworld-go.default.example.com"
Hello Knative!
Hello Knative 2!

Gray Release Based on Cookies and Headers

  • Header-based gray release by the community

Currently, the gray release of Header is implemented by configuring tag-header-based-routing with Knative Service.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/maxScale: "100"
        autoscaling.knative.dev/minScale: "0"
    spec:
      containers:
      - env:
        - name: TARGET
          value: Knative11
        image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        name: user-container
        ports:
        - containerPort: 8080
          name: http1
          protocol: TCP
  traffic:
  - latestRevision: false
    percent: 0
    revisionName: helloworld-go-00002
    tag: rev1
  - latestRevision: false
    percent: 100
    revisionName: helloworld-go-00001

Internal conversion to Kubernetes Ingress is listed below:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/actions.forward-default: '{"type":"forward","forwardConfig":{"serverGroups":[{"serviceName":"helloworld-go-00002","servicePort":80,"weight":50},{"serviceName":"helloworld-go-00001","servicePort":80,"weight":50}]}}'
    alb.ingress.kubernetes.io/actions.forward-tag: '{"type":"forward","forwardConfig":{"targetGroups":[{"serviceName":"helloworld-go-00002","servicePort":80,"weight":100}]}}'
    alb.ingress.kubernetes.io/conditions.forward-tag: '[{"Type":"Header","CookieConfig":{"Values":null},"HeaderConfig":{"Key":"Knative-Serving-Tag","Values":["rev1"]}}]'
  labels:
    knative.aliyun.com/ingress: helloworld-go
  name: helloworld-go
  namespace: default
spec:
  ingressClassName: knative-alb-ingress-internet
  rules:
  - host: helloworld-go.default.a97e861255a18699.app.alicontainer.com
    http:
      paths:
      - backend:
          service:
            name: forward-default
            port:
              name: use-annotation
        path: /
        pathType: Prefix
  - host: helloworld-go.default.svc.cluster.local
    http:
      paths:
      - backend:
          service:
            name: forward-default
            port:
              name: use-annotation
        path: /
        pathType: Prefix
  - host: helloworld-go.default.a97e861255a18699.app.alicontainer.com
    http:
      paths:
      - backend:
          service:
            name: forward-tag
            port:
              name: use-annotation
        path: /
        pathType: Prefix
  - host: helloworld-go.default.svc.cluster.local
    http:
      paths:
      - backend:
          service:
            name: forward-tag
            port:
              name: use-annotation
        path: /
        pathType: Prefix
  - host: rev1-helloworld-go.default.svc.cluster.local
    http:
      paths:
      - backend:
          service:
            name: forward-tag
            port:
              name: use-annotation
        path: /
        pathType: Prefix

Access Method:

curl ${INGRESS_DNS} -H "Host:helloworld-go.default.example.com"  -H "Knative-Serving-Tag:rev1"
  • Header-Based Gray Release

In Knative Service, the traffic revision corresponding to the Header can be specified using annotations.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    alicloud.serving.knative.dev/headers: [{revision:helloworld-go-00002,headers:{demo:test}}]
  name: helloworld-go
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/maxScale: "100"
        autoscaling.knative.dev/minScale: "0"
    spec:
      containers:
      - env:
        - name: TARGET
          value: Knative11
        image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        name: user-container
        ports:
        - containerPort: 8080
          name: http1
          protocol: TCP
  traffic:
  - latestRevision: false
    percent: 0
    revisionName: helloworld-go-00002
  - latestRevision: false
    percent: 100
    revisionName: helloworld-go-00001

Access Method:

curl ${INGRESS_IP} -H "Host:helloworld-go.default.example.com" --header "demo=always" --header "header2=v2"
  • Gray Release based on Cookie

In Knative Service, the traffic revision corresponding to the Cookie can be specified using annotations.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    alicloud.serving.knative.dev/cookies: [{revision:helloworld-go-00002,cookies:{demo:always,cookie2:v2}}]
  name: helloworld-go
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/maxScale: "100"
        autoscaling.knative.dev/minScale: "0"
    spec:
      containers:
      - env:
        - name: TARGET
          value: Knative11
        image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        name: user-container
        ports:
        - containerPort: 8080
          name: http1
          protocol: TCP
  traffic:
  - latestRevision: false
    percent: 0
    revisionName: helloworld-go-00002
  - latestRevision: false
    percent: 100
    revisionName: helloworld-go-00001

Access Method:

curl ${INGRESS_DNS} -H "Host:helloworld-go.default.example.com" --cookie "demo=always" --cookie "cookie2=v2"

Conclusion

Integrating Knative with ALB can enhance the productization capabilities of Knative Serverless and expand the scenarios applicable to ALB Ingress.

Learn more about the product:
https://www.alibabacloud.com/help/en/container-service-for-kubernetes/latest/alb

slb Computing Container Service Containers Serverless Knative Application Load Balancer ALB
0 0 0
Share on

Read previous post:

The Definition of the New Service Mesh-Driven Scenario: AI Model Services - Model Mesh

Read next post:

Comprehensive Analysis of Kubernetes Log Collection Principles

Alibaba Container Service

166 posts | 30 followers

You may also like

Comments

Alibaba Container Service

166 posts | 30 followers

Related Products

  • ACK One

    Provides a control plane to allow users to manage Kubernetes clusters that run based on different infrastructure resources

    Learn More

  • Function Compute

    Alibaba Cloud Function Compute is a fully-managed event-driven compute service. It allows you to focus on writing and uploading code without the need to manage infrastructure such as servers.

    Learn More

  • Container Service for Kubernetes

    Alibaba Cloud Container Service for Kubernetes is a fully managed cloud container management service that supports native Kubernetes and integrates with other Alibaba Cloud products.

    Learn More

  • Serverless Workflow

    Visualization, O&M-free orchestration, and Coordination of Stateful Application Scenarios

    Learn More

More Posts by Alibaba Container Service

See All