Use OAM to model Knative Serving and Scaling

[resouer]

Xref: #390 (comment)

In context of serverless, OAM and Knative are complementary to each other:

• Knative works on vertical dimension:
  • defines abstractions for serverless workload (serving, scaling etc) and map them to K8s resources
• OAM/Rudr works on the horizontal dimension:
  • organizes and manages abstractions for better interoperability and manageability so platform builder could assemble them into a user facing serverless platform.

We will use this issue to tracking the effort of modeling Knative with OAM as soon as OAM spec 0.3.0 is released. It should be straightforward.

/cc @glyn

[xiang90]

More precisely, Rudr implements the core workload defined by OAM spec on Kubernetes platform, and also provide necessary utilities for implementing additional traits/components.

The OAM spec defines a set of concepts/rules. The goal is to makes it easier for different components from different parties to compose as an application.

[resouer]

Just drafted a quick sample about Knative serving Component (has already showed to @glyn):

---
apiVersion: core.oam.dev/v1alpha1
kind: WorkloadDefinition
metadata:
  name: service.serving.knative.dev
spec:
  definitionRef:
    # reference to the name of real-world crd
    name: service.serving.knative.dev
---
apiVersion: core.oam.dev/v1alpha3
kind: Component
metadata:
  name: example-service
spec:
  workload:
    # this is exactly a knative serving CR which will be enforced & validated by WorkloadDefinition above
    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: helloworld-go
    spec:
      template:
        spec:
          containers:
            - image: docker.io/test/helloworld-go
              env:
                - name: TARGET
                  value: "Go Sample v1"
  # (optional) overridable parameters for this workload
  parameters:
  - name: image
    required: true
    fieldPaths:
    - ".spec.containers[0].image[0]"
---
apiVersion: core.oam.dev/v1alpha3
kind: Component
metadata:
  name: example-cache
spec:
  workload:
    apiVersion: service-operator.aws/v1alpha1
    kind: ElastiCache
    metadata:
      name: elastic-cache
    spec:
      cacheSubnetGroupName: "loadtest-cluster-k8s"
      vpcSecurityGroupIds: "sg-0581b94aa3c0db58c, sg-02b6d0034e8c2fa1b"
      autoMinorVersionUpgrade: true
      engine: redis
      engineVersion: 5.0.0
      numCacheNodes: 1
      port: 6379
      cacheNodeType: "cache.m4.large"
---
apiVersion: core.oam.dev/v1alpha3
kind: ApplicationConfiguration
metadata:
  name: cool-example
spec:
  components:
  - componentName: example-service
    # (optional) override image parameters to a production image 
    parameterValues:
    - name: image
      value: docker.io/prod/helloworld-go
  # the ElastiCache instance consumed by "example-service"
  - componentName: example-cache

The knative scaling will be modeled as trait, this will need some glue code as right now scaling is represented as annotation of knative serving obj.

[resouer]

All done! Knative works like a charming in OAM: https://github.com/oam-dev/samples/tree/master/6.Knative_with_Cloud_Resource_App