Fix typo

Signed-off-by: Eduard Serra <eduser25@gmail.com>

docs/content/docs/HA.md

@@ -5,14 +5,14 @@ type: docs
 ---
 # HA Design considerations
 
-OSM's control plane componenets are built with High Availability and Fault Tolerance in mind. The following sections will thoroughly document how are these tackled.
+OSM's control plane components are built with High Availability and Fault Tolerance in mind. The following sections will thoroughly document how are these tackled.
 
 ## High Availability and Fault Tolerance
 
 High Availability and Fault Tolerance are implemented and ensured by several design decisions and external mechanisms in OSM, which will be documented in the following points:
 
 ### Statelessness
-OSM's control plane componenets do not own or have any state-dependent data that needs to be saved at runtime; with the controlled exceptions of:
+OSM's control plane components do not own or have any state-dependent data that needs to be saved at runtime; with the controlled exceptions of:
 - CA / Root Certificate: The CA root certificate is required to be the same for multiple OSM instances when running multiple replica. For [Certificate Managers](/DESIGN.md#2-certificate-manager) implementations that require the root CA to have been generated/provided prior OSM execution (Vault, Cert-Manager), the root CA will be fetched from the provider at boot by all instances.
 For other Certificate Providers that can autogenerate a CA when none is present (such as Tresor), atomicity and synchronization will be ensured during creation, ensuring all instances load the same CA.
 - Envoy Bootstrap Certificates (used by the proxies to authenticate against the control plane): these are created during injection webhook handling and inlined as part of the Proxy's bootstrap configuration. The configuration is stored as a kubernetes secret and mounted in the injected envoy pod as a volume, assuring idempotence for a single pod at any one time.
@@ -28,7 +28,7 @@ Multiple `osm-controller`s running will subscribe to the same set of objects and
 </p>
 
 ### Restartability: 
-The previous stateless design considerations should ensure OSM's control plane componenets are fully restartable.
+The previous stateless design considerations should ensure OSM's control plane components are fully restartable.
 
 - A restarting instance will resynchronize all Kubernetes domain resources. Existing proxies will reconnect, and (assuming no changes occurred on the mesh topology or policy) the same configuration should be recomputed and pushed as a new version to the proxies.
 
@@ -58,4 +58,4 @@ Components `osm-controller` and `osm-injector` allow for separate horizontal sca
 
 
 
-[1] Headless: usually referred in the control-plane/data-plane design paradigm, refers to the concept that allows, when having a dependency between two componenets, for the depender agent to survive and keep running with latest state when the dependee dies or becomes unreachable.
+[1] Headless: usually referred in the control-plane/data-plane design paradigm, refers to the concept that allows, when having a dependency between two components, for the depender agent to survive and keep running with latest state when the dependee dies or becomes unreachable.