diff --git a/docs/architecture.md b/docs/architecture.md index 3fab67840..843a1215a 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -14,21 +14,21 @@ Kubeless is built around below core concepts: A _Function_ is representation of the code to be executed. Along with the code a _Function_ contains metadata about its runtime dependencies, build instructions etc. A _Function_ has a independent life-cycle. The following methods are supported: -* Deploy - deploy function as function instances. This step may involve building the function image or re-use pre-generated image and deploying it on the cluster. -* Execute - invoke a function directly i.e) not through any event source -* Get - Returns the function metadata and spec +* Deploy - Deploy function as function instances. This step may involve building the function image or re-use pre-generated image and deploying it on the cluster. +* Execute - Invoke a function directly i.e) not through any event source +* Get - Return the function metadata and spec * Update - Modify the function specification and its metadata -* Delete - Deletes a function, and clean up any resource provisioned for the function from the cluster +* Delete - Delete a function, and clean up any resource provisioned for the function from the cluster * List - Show the list of functions and their metadata * Logs - Return the logs generated by a function ### Triggers -A _Trigger_ represents an event source the functions associated to it. When an event occurs in the event source, Kubeless will ensure that the associated function are invoked **at most once**. A Trigger can be associated to a single function or to several ones depending on the event source type. They are decoupled from the life-cycle of functions and can be independently operated with the following methods: +A _Trigger_ represents an event source for the functions associated to it. When an event occurs in the event source, Kubeless will ensure that the associated functions are invoked **at most once**. A Trigger can be associated to a single function or to several ones depending on the event source type. They are decoupled from the life-cycle of functions and can be independently operated with the following methods: -* Create - create a new trigger with details on event source and associated functions +* Create - Create a new trigger with details on event source and associated functions * Update - Modify the trigger specification -* Delete - Deletes a trigger, and clean up any resource provisioned for the trigger +* Delete - Delete a trigger, and clean up any resource provisioned for the trigger * List - Show the list of trigger and their specification ### Runtime @@ -37,13 +37,13 @@ A _Runtime_ represents language and runtime specific environment in which functi ## Design -Kubeless leverages multiple concepts of Kubernetes in order to support deploy functions on top of it. In details, we have been using: +Kubeless leverages multiple concepts of Kubernetes in order to support functions deployed on top of it. In details, we have been using: - A Custom Resource Definitions (CRD) is used to represent function -- Each event source is modelled as a separate Trigger CRD object +- Each event source is modeled as a separate Trigger CRD object - Separate Custom Resource Definitions controller to handle CRUD operations corresponding to CRD object - Deployment / Pod to run the corresponding runtime. -- Configmap to inject function's code to the runtime pod. +- Configmap to inject function's code into the runtime pod. - Init-container to load the dependencies that function might have. - Service to expose function. - Ingress resources to expose functions externally @@ -144,7 +144,7 @@ spec: `function.spec` contains function's details like code, handler, runtime and probably its dependency file etc. -Kubeless ships with a CRD controller named `function-controller` which continuously watch changes to function objects and react accordingly. By default function-controller is installed in `kubeless-controller-manager` deployment which is deployed into `kubeless` namespace. Function-controller watches for create events corresponding to creation of _Function_ object. Function-controller creates a deployment for the function, and exposes the function as a clusterIP service. Both deployment and service resource created for the function can be controlled by the function creator by explicitly specifying deployment spec and service spec respectively in the `function.spec`. +Kubeless ships with a CRD controller named `function-controller` which continuously watches changes to function objects and reacts accordingly. By default function-controller is installed in `kubeless-controller-manager` deployment which is deployed into `kubeless` namespace. Function-controller watches for create events corresponding to creation of _Function_ object. Function-controller creates a deployment for the function, and exposes the function as a clusterIP service. Both deployment and service resources created for the function can be controlled by the function creator by explicitly specifying deployment spec and service spec respectively in the `function.spec`. Runtime image used for the function deployment could be chosen by one of the below options: @@ -198,7 +198,7 @@ spec: ``` HTTP trigger object spec contains below fields: -* function-name - name of the associated function that need to be invoked when URL corresponding to http trigger is accessed +* function-name - name of the associated function that needs to be invoked when URL corresponding to http trigger is accessed * host-name - name used for virtual hosting * path - route requests with this path to function service * tls - true if TLS is to be enabled @@ -244,7 +244,7 @@ spec: Cronjob trigger object spec contains below fields: -* function-name - name of the associated function that need to be invoked periodically as per specified +* function-name - name of the associated function that needs to be invoked periodically as per specified * schedule - it takes a Cron format string, e.g. 0 * * * * or @hourly, as schedule time of its jobs to be created and executed. `kubeless-controller-manager` ships with Cronjob trigger CRD controller which watches for the Cronjob trigger CRD objects and configures Kubernetes cronjobs to run the functions at scheduled intrerval time. @@ -291,7 +291,7 @@ spec: Kafka trigger object spec contains below fields: -* functionSelector - label selector that selects list of matching function +* functionSelector - label selector that selects list of matching functions * topic - Kafka topic messages to which the functions associated must be invoked. ## Kubeless command-line client @@ -306,13 +306,13 @@ Usage: kubeless [command] Available Commands: - autoscale manage autoscale to function on Kubeless + autoscale Manage autoscale to function on Kubeless completion Output shell completion code for the specified shell. - function function specific operations + function Function specific operations get-server-config Print the current configuration of the controller help Help about any command - topic manage message topics in Kubeless - trigger trigger specific operations + topic Manage message topics in Kubeless + trigger Trigger specific operations version Print the version of Kubeless Flags: @@ -329,14 +329,14 @@ Kubeless CLI is written in Go as well, using the popular cli library `github.com ## Directory structure -In order to help you getting a better feeling before you start diving into the project, we would give you the 10,000 foot view of the source code directory structure. +In order to help you getting a better feeling before you start diving into the project, we would give you the 10,000 feet view of the source code directory structure. -- chart: chart to deploy Kubeless with Helm +- chart: chart to deploy Kubeless with Helm. - cmd: contains kubeless cli implementation and kubeless-controller. - docker: contains artifacts for building the kubeless-controller and runtime images. - docs: contains documentations. - examples: contains some samples of running function with kubeless. -- manifests: collection of manifests for additional features +- manifests: collection of manifests for additional features. - pkg: contains shared packages. - script: contains build scripts. - vendor: contains dependencies packages.