Knative Pluggability

mattmoor@google.com (@mattomata)

Last Updated: 2018-Aug-08

SHARED PUBLICLY

The Goal.

Knative aims to be “loosely coupled at the top, and pluggable at the bottom”[1].

​

… but we are not today.

[1] - http://www.youtube.com/watch?v=LtELzpw1l1M&t=37m35s

Loosely coupled at the top

???

???

See also: “Towards loosely coupled Knative components”

Use Knative components with non-Knative components that satisfy some contract/interface.

Pluggable at the bottom

The focus of this presentation.

Background

Kubernetes Ingress

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: test-ingress

spec:

rules:

- http:

paths:

- path: /testpath

backend:

serviceName: test

servicePort: 80

​

Source: https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource

1 resource definition,

N controller implementations.

​

• GCP L7
• nginx
• Istio
• Heptio Contour
• ...

Kubernetes Ingress (cont’d)

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: test-ingress

annotations:

impl.io/foo: bar

spec:

rules:

- http:

paths:

- path: /testpath

backend:

serviceName: test

servicePort: 80

​

Source: https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource

Pass implementation-specific configuration through annotations.

High-level Idea

Broad Strokes

• Determine the places Knative should be pluggable,
• Define a standard CRD to encapsulate the functionality we need,
• Implement interchangeable controllers for this common definition.

Pluggable at the bottom (revisited)

Choose your own adventure...

CRDs

Implementations

Example: Autoscaler

Pluggable at the bottom (Autoscaler)

HPA

Implementations

CRD (autoscaling.knative.dev/v1alpha1/Bikeshed)

Goal: Pluggable Autoscalers

A rough version of this as “KPA” was pitched in #1655, before seeing the pattern or alignment with the Kubernetes Ingress pattern.

• Define a common “KPA” interface for configuring autoscaling.
• Move our autoscaling implementation into a separate controller on this resource.

Example: Ingress 2.0

… or is it Ingress++?

Pluggable at the bottom (Ingress)

Implementations

CRD (networking.knative.dev/v1alpha1/Bikeshed)

Goal: Pluggable Ingress

Kubernetes Ingress is close, but lacking:

• Traffic Splitting (Route)
• Cross-Namespace routing (Route + Activator)
• Method-based routing (API Gateways)
• Request rewriting (Recording split decision for activator)

​

… we likely want the evolution of Kubernetes Ingress, but its coupling with K8s is unfortunate. Maybe it needs to evolve into a CRD outside K8s?

See also: Network routing requirements for Knative

Goal: Pluggable Ingress (cont’d)

• Extend Kubernetes IngressSpec:
• Address gaps, aim for back-compat to ease porting.

​

• Expose new Ingress and ClusterIngress CRDs that use the updated spec.
• Disallow “Namespace” in the former

​

… and provide a base implementation around Istio (to match what we use today).

Example: Image Cache

Pluggable at the bottom (Image Caching)

Slacker

Nothing

Implementations

CRD (something.knative.dev/v1alpha1/Bikeshed)

WarmImage

Goal: Improve Pod Start Latency

Variety of possible strategies, with a variety of operational costs

• A useful knob for tuning operational cost vs. performance

​

… get abstraction in place, and measure.

But why?

So why is this interesting? Win / Win.

• Better formalize our functional contract between components.
• Clearer roles and responsibilities is good for us.

​

• Providing users with choice is good.
• A lot of early criticism for the heavy Istio dependency.
• Let the best solution win.
• Providing operators a means to plug in customizations.
• Hosted offerings can plug in implementations that better integrate Knative with their platform.

How do we qualify plugins?

How do we qualify plugins?

1. Plugin to Knative
2. ???
3. Profit!

Conformance!

The elephant in the room

Google drawing doesn’t have a nonagon.

10 sides!

I’m sorry...

Questions?