ApiServerSource reference

    This topic provides reference information about the configurable fields for the ApiServerSource object.

    An ApiServerSource definition supports the following fields:

    The resources parameter specifies the resources that the source tracks so that it can send related lifecycle events from the Kubernetes ApiServer. The parameter includes an optional label selector to help filter.

    A resources definition supports the following fields:

    Example: Resources parameter

    Given the following YAML, the ApiServerSource object receives events for all Pods and Deployments in the namespace:

    Example: Resources parameter using matchExpressions

    Given the following YAML, ApiServerSource object receives events for all Pods in the namespace that have a label app=myapp or app=yourapp:

    1. apiVersion: sources.knative.dev/v1
    3. metadata:
    4.   name: <apiserversource>
    5.   namespace: <namespace>
    6. spec:
    7.   # ...
    8.   resources:
    9.     - apiVersion: v1
    10.       kind: Pod
    11.       selector:
    12.         matchExpressions:
    13.           - key: app
    14.             operator: In
    15.             values:
    16.               - myapp
    17.               - yourapp

    Example: Resources parameter using matchLabels

    1. kind: ApiServerSource
    2. metadata:
    3.   name: <apiserversource>
    4.   namespace: <namespace>
    5. spec:
    6.   # ...
    7.   resources:
    8.     - apiVersion: v1
    9.       kind: Pod
    10.       selector:
    11.         matchLabels:
    12.           app: myapp

    ServiceAccountName is a reference to a Kubernetes service account.

    To track the lifecycle events of the specified , you must assign the proper permissions to the ApiServerSource object.

    Example: tracking Pods

    The following YAML files create a ServiceAccount, Role and RoleBinding and grant the permission to get, list and watch Pod resources in the namespace apiserversource-example for the ApiServerSource.

    Example ServiceAccount:

    Example Role with permission to get, list and watch Pod resources:

    1. apiVersion: rbac.authorization.k8s.io/v1
    2. kind: Role
    3. metadata:
    4.   name: test-role
    5. rules:
    6.   - apiGroups:
    7.     - ""
    8.     resources:
    9.     - pods
    10.     verbs:
    11.     - get
    13.     - watch

    Example RoleBinding:

    1. apiVersion: rbac.authorization.k8s.io/v1
    2. kind: RoleBinding
    3. metadata:
    4. roleRef:
    5.   apiGroup: rbac.authorization.k8s.io
    6.   kind: Role
    7.   name: test-role
    8. subjects:
    9.   - kind: ServiceAccount
    10.     name: test-service-account
    11.     namespace: apiserversource-example

    ResourceOwner is an additional filter to only track resources that are owned by a specific resource type. If ResourceOwner matches Resources[n] then Resources[n] is allowed to pass the ResourceOwner filter.

    An owner definition supports the following fields:

    Example: Owner parameter

    1. apiVersion: sources.knative.dev/v1
    2. kind: ApiServerSource
    3. metadata:
    4.  name: <apiserversource>
    5.  namespace: <namespace>
    6. spec:
    7.   ...
    8.   owner:
    9.     apiVersion: apps/v1
    10.     kind: Deployment
    11.   ...

    CloudEvent Overrides defines overrides to control the output format and modifications of the event sent to the sink.

    A ceOverrides definition supports the following fields:

    Note

    Only valid CloudEvent attribute names are allowed as extensions. You cannot set the spec defined attributes from the extensions override configuration. For example, you can not modify the type attribute.

    Example: CloudEvent Overrides

    1. apiVersion: sources.knative.dev/v1
    2. kind: ApiServerSource
    3. metadata:
    4.  name: <apiserversource>
    5.  namespace: <namespace>
    6. spec:
    7.   ...
    8.   ceOverrides:
    9.     extensions:

    This results in the K_CE_OVERRIDES environment variable being set on the sink container as follows: