Merge pull request #704 from fujitatomoya/enable-codespell

Enable codespell

Author: kubeedge-bot

blog/cncf-sandbox-announcement/index.mdx

@@ -52,15 +52,15 @@ CNCF Sandbox page: [CNCF Sandbox Projects](https://www.cncf.io/sandbox-projects/
 
 Open source edge computing is going through its most dynamic phase of development in the industry. So many open source platforms, so many consolidations and so many initiatives for standardization! This shows the strong drive to build better platforms to bring cloud computing to the edges to meet ever increasing demand. KubeEdge, which was announced last year, now brings great news for cloud native computing! It provides a complete edge computing solution based on Kubernetes with separate cloud and edge core modules. Currently, both the cloud and edge modules are open sourced.
 
-Unlike certain light weight kubernetes platforms available around, KubeEdge is made to build edge computing solutions extending the cloud. The control plane resides in cloud, though scalable and extendable. At the same time, the edge can work in offline mode. Also it is lightweight and containerized, and can support heterogeneous hardware at the edge. With the optimization in edge resource utlization, KubeEdge positions to save significant setup and operation cost for edge solutions. This makes it the most compelling edge computing platform in the world currently, based on Kubernetes!
+Unlike certain light weight kubernetes platforms available around, KubeEdge is made to build edge computing solutions extending the cloud. The control plane resides in cloud, though scalable and extendable. At the same time, the edge can work in offline mode. Also it is lightweight and containerized, and can support heterogeneous hardware at the edge. With the optimization in edge resource utilization, KubeEdge positions to save significant setup and operation cost for edge solutions. This makes it the most compelling edge computing platform in the world currently, based on Kubernetes!
 
 ### **_Kube(rnetes)Edge_!** - Opening up a new Kubernetes-based ecosystem for Edge Computing
 
 The key goal for KubeEdge is extending Kubernetes ecosystem from cloud to edge. From the time it was announced to the public at KubeCon in Shanghai in November 2018, the architecture direction for KubeEdge was aligned to Kubernetes, as its name!
 
 It started with its v0.1 providing the basic edge computing features. Now, with its latest release v0.2, it brings the cloud components to connect and complete the loop. With consistent and scalable Kubernetes-based interfaces, KubeEdge enables the orchestration and management of edge clusters similar to how Kubernetes manages in the cloud. This opens up seamless possibilities of bringing cloud computing capabilities to the edge, quickly and efficiently.
 
-Based on its roadmap and architecture, KubeEdge tries to support all edge nodes, applications, devices and even the cluster management consistent with the Kuberenetes interface. This will help the edge cloud act exactly like a cloud cluster. This can save a lot of time and cost on the edge cloud development deployment based on KubeEdge.
+Based on its roadmap and architecture, KubeEdge tries to support all edge nodes, applications, devices and even the cluster management consistent with the Kubernetes interface. This will help the edge cloud act exactly like a cloud cluster. This can save a lot of time and cost on the edge cloud development deployment based on KubeEdge.
 
 KubeEdge provides a containerized edge computing platform, which is inherently scalable. As it’s modular and optimized, it is lightweight (66MB foot print and ~30MB running memory) and could be deployed on low resource devices. Similarly, the edge node can be of different hardware architecture and with different hardware configurations. For the device connectivity, it can support multiple protocols and it uses a standard MQTT-based communication. This helps in scaling the edge clusters with new nodes and devices efficiently.
 
@@ -70,7 +70,7 @@ KubeEdge provides a containerized edge computing platform, which is inherently s
 
 By open sourcing both the edge and cloud modules, KubeEdge brings a complete cloud vendor agnostic lightweight heterogeneous edge computing platform. It is now ready to support building a complete Kubernetes ecosystem for edge computing, exploiting most of the existing cloud native projects or software modules. This can enable a mini-cloud at the edge to support demanding use cases like data analytics, video analytics, machine learning and more.
 
-KubeEdge Architecture: Building Kuberenetes Native Edge computing!
+KubeEdge Architecture: Building Kubernetes Native Edge computing!
 The core architecture tenet for KubeEdge is to build interfaces that are consistent with Kubernetes, be it on the cloud side or edge side.
 
 **Edged**: Manages containerized Applications at the Edge.

blog/contributor-contest/index.mdx

@@ -22,7 +22,7 @@ tags:
 - cloud native
 title: KubeEdge Contribution Competition
 ---
-KubeEdge is a CNCF Sandbox project that extends K8s from Cloud to Edge. We would like to invite you to join us in furthering this project and making it useable for everyone. To make this contribution effort more fun, we're proposing a contribution competition. See below for details. May the best contributor win!
+KubeEdge is a CNCF Sandbox project that extends K8s from Cloud to Edge. We would like to invite you to join us in furthering this project and making it usable for everyone. To make this contribution effort more fun, we're proposing a contribution competition. See below for details. May the best contributor win!
 
 <!--truncate-->
 

blog/release-v1.10/index.mdx

@@ -117,7 +117,7 @@ If you want to deploy the KubeEdge v1.10.0, please note that the Kubernetes depe
 
 - Add script for build release ([#3467](https://github.com/kubeedge/kubeedge/pull/3467), [@gy95](https://github.com/gy95))
 
-- Using lateset codes to do keadm_e2e ([#3469](https://github.com/kubeedge/kubeedge/pull/3469), [@gy95](https://github.com/gy95))
+- Using latest codes to do keadm_e2e ([#3469](https://github.com/kubeedge/kubeedge/pull/3469), [@gy95](https://github.com/gy95))
 
 - Change the resourceType of msg issued by synccontroller ([#3496](https://github.com/kubeedge/kubeedge/pull/3496), [@Rachel-Shao](https://github.com/Rachel-Shao))
 

blog/release-v1.15/index.mdx

@@ -53,11 +53,11 @@ Refer to the link for more details. ([#4914](https://github.com/kubeedge/kubeedg
 
 The device API is updated from `v1alpha2` to `v1beta1`, in v1beta1 API updates include:
 
-- The built-in protocols incude Modbus, Opc-UA and Bluetooth are removed in device instance, and the built-in mappers for these proytocols still exists and will be maintained and updated to latest verison.
+- The built-in protocols include Modbus, Opc-UA and Bluetooth are removed in device instance, and the built-in mappers for these proytocols still exists and will be maintained and updated to latest version.
 
 - Users must define the protocol config through `CustomizedValue` in `ProtocolConfig`.
 
-- DMI date plane related fields are added, users can config the collection and reporting frequency of device data, and the destination to whcih(such as database, httpserver) data is pushed.
+- DMI date plane related fields are added, users can config the collection and reporting frequency of device data, and the destination to which(such as database, httpserver) data is pushed.
 
 - Controls whether to report device data to cloud.
 
@@ -78,7 +78,7 @@ Refer to the link for more details. ([#4825](https://github.com/kubeedge/kubeedg
 
 ### Support more Kubernetes Native Plugin Running on Edge Node
 
-Kubernetes non-resource kind request `/version` is supported from edge node, users now can do `/version` requests in edge node from metaserver. In addition, it can easily support other non-resource kind of requests like `/healthz` in edge node with the curent framework. Many kubernetes plugins like cilium/calico which depend on these non-resource kind of requests, now can run on edge nodes.
+Kubernetes non-resource kind request `/version` is supported from edge node, users now can do `/version` requests in edge node from metaserver. In addition, it can easily support other non-resource kind of requests like `/healthz` in edge node with the current framework. Many kubernetes plugins like cilium/calico which depend on these non-resource kind of requests, now can run on edge nodes.
 
 Refer to the link for more details. ([#4904](https://github.com/kubeedge/kubeedge/pull/4904))
 

blog/release-v1.16/index.mdx

@@ -154,7 +154,7 @@ Refer to the link for more details.([#5308](https://github.com/kubeedge/kubeedge
 
 ### Integrate Redis and TDengine Database in DMI Data Plane
 
-Integrate redis and tdengine database in DMI data plane. The mapper project generated by mapper-framework has build-in ability to push data to redis and tdengine database. Users can push data directly through configuring device instance files.
+Integrate redis and tdengine database in DMI data plane. The mapper project generated by mapper-framework has built-in ability to push data to redis and tdengine database. Users can push data directly through configuring device instance files.
 
 Database Field Definition:
 ```json

blog/secure-kubeedge/index.md

@@ -85,7 +85,7 @@ Security is a paramount requirement for edge computing architecture as security
 
 * Certificate rotation: Short-lived certificates are generated and rotation policies can be configured for every service communication. There is no need for custom agents and reliance on specific orchestrators for certificate rotation configuration and management.
 
-* Automated non-root CA certificate heirarchical deployments: Edge spire servers can be configured to not share any root CA chain for downstream nodes and workloads.
+* Automated non-root CA certificate hierarchical deployments: Edge spire servers can be configured to not share any root CA chain for downstream nodes and workloads.
 
 ## Example Demo
 

docs/advanced/edgesite.md

@@ -125,7 +125,7 @@ Click [here](https://github.com/kubeedge/kubeedge/releases) and download.
 
 #### Configuring EdgeSite
 
-Genarate edgesite config by `edgesite --minconfig` and update:
+Generate edgesite config by `edgesite --minconfig` and update:
 
 + Configure K8S (API Server)
 

docs/architecture/edge/edged.md

@@ -70,7 +70,7 @@ The flow diagram below explains the message flow.
 
 *Fig 7: Secret Message Handling at EdgeD*
 
-Edged uses the MetaClient module to fetch secrets from MetaManager. If edged queries for a new secret which is not yet stored in MetaManager, the request is forwarded to the Cloud. Before sending the response containing the secret, MetaManager stores it in a local database. Subsequent queries for the same secret key will be retrieved from the database, reducing latency. The flow diagram below shows how a secret is fetched from MetaManager and the Cloud. It also descibes how the secret is stored in MetaManager.
+Edged uses the MetaClient module to fetch secrets from MetaManager. If edged queries for a new secret which is not yet stored in MetaManager, the request is forwarded to the Cloud. Before sending the response containing the secret, MetaManager stores it in a local database. Subsequent queries for the same secret key will be retrieved from the database, reducing latency. The flow diagram below shows how a secret is fetched from MetaManager and the Cloud. It also describes how the secret is stored in MetaManager.
 
 ![Query Secret](/img/edged/query-secret-from-edged.png)
 
@@ -91,7 +91,7 @@ The flow diagram below explains the message flow.
 
 *Fig 9: ConfigMap Message Handling at EdgeD*
 
-Edged uses the MetaClient module to fetch ConfigMaps from MetaManager. If edged queries for a new ConfigMap which is not yet stored in MetaManager, the request is forwarded to the Cloud. Before sending the response containing the ConfigMap, MetaManager stores it in a local database. Subsequent queries for the same ConfigMap key will be retrieved from the database, reducing latency. The flow diagram below shows how ConfigMaps are fetched from MetaManager and the Cloud. It also descibes how ConfigMaps are stored in MetaManager.
+Edged uses the MetaClient module to fetch ConfigMaps from MetaManager. If edged queries for a new ConfigMap which is not yet stored in MetaManager, the request is forwarded to the Cloud. Before sending the response containing the ConfigMap, MetaManager stores it in a local database. Subsequent queries for the same ConfigMap key will be retrieved from the database, reducing latency. The flow diagram below shows how ConfigMaps are fetched from MetaManager and the Cloud. It also describes how ConfigMaps are stored in MetaManager.
 
 ![Query Configmaps](/img/edged/query-configmap-from-edged.png)
 

docs/community/release.md

@@ -13,7 +13,7 @@ The release process can be thought of as having four main phases:
 
 - **Feature Definition (Week 1~2)**
 
-    With ongoing feature definition through the year, some set of items will bubble up as targeting a given release. During the initial two weeks, feature work for the given release is defined in suitable planning artifacts in conjunction with SIG Release Team. Milestone is created adn applied correctly so that SIG Release Team can track enhancements and bugs.
+    With ongoing feature definition through the year, some set of items will bubble up as targeting a given release. During the initial two weeks, feature work for the given release is defined in suitable planning artifacts in conjunction with SIG Release Team. Milestone is created and applied correctly so that SIG Release Team can track enhancements and bugs.
 
 - **Feature Work (Week 3~10)**
 
@@ -25,7 +25,7 @@ The release process can be thought of as having four main phases:
 
 - **Release (Week 12)**
 
-  Once the first three phases are comleted, the release branch enters the final stage. The community prepares for the official release by conducting thorough testing and ensuring documentation and release notes are up-to-date. Following this, the final version is officially released and made available for public use.
+  Once the first three phases are completed, the release branch enters the final stage. The community prepares for the official release by conducting thorough testing and ensuring documentation and release notes are up-to-date. Following this, the final version is officially released and made available for public use.
 
 When the code base is sufficiently stable, the master branch opens for general development and work begins there for the next release milestone. 
 

docs/concept/device/mapper.md

@@ -7,7 +7,7 @@ Mapper is a manager between KubeEdge and devices. It could set/get device data,
 get and report the device status. KubeEdge uses Device Controller, Device Twin and Mapper to control 
 the devices. The Device Controller is on the cloud side, it uses CRD to define and control devices. 
 The Device Twin is on the edge side, it stores the value/status from the Mapper and transfers the messages 
-with Device Controller and Mapper. Meanwhile, DMI in the Device Twin is used for registing Mapper and transfer
+with Device Controller and Mapper. Meanwhile, DMI in the Device Twin is used for registering Mapper and transfer
 Device Instance and Device Model to user Mapper.
 
 Currently, a Mapper is responsible for managing devices that use a **certain protocol**. DMI will package the device 
@@ -20,7 +20,7 @@ explore the possibility of two or more Mappers with same protocol running on sam
 ### Creating a Mapper
 Users can easily generate their own Mapper through **[Mapper Framework](../../developer/mapper-framework)**.
 
-You can follew the **[guide](../../developer/mappers#how-to-create-your-own-mappers)** to create your Mapper.
+You can follow the **[guide](../../developer/mappers#how-to-create-your-own-mappers)** to create your Mapper.