architecture.md : fixing some typos (#1186)

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.