Merge pull request #4109 from abhigyadufare/patch-1

Typo fix in multiple keps

Author: k8s-ci-robot

keps/provider-aws/629-alb-ingress-controller/README.md

@@ -65,5 +65,5 @@ Developers from different teams create Ingress resources in different namespaces
 ## Implementation History
 - [community#2841](https://github.com/kubernetes/community/pull/2841) Design proposal
 - [aws-alb-ingress-controller#738](https://github.com/kubernetes-sigs/aws-alb-ingress-controller/pull/738) First stable release: v1.0.0
-- 2018-12-03 Alpha release with kuberentes 1.13
+- 2018-12-03 Alpha release with kubernetes 1.13
 - 2018-03-25 Beta release with kubernetes 1.14 (scheduled)

keps/provider-aws/630-ebs-csi-driver/README.md

@@ -27,14 +27,14 @@
 AWS EBS CSI Driver implements [Container Storage Interface](https://github.com/container-storage-interface/spec/tree/master) which is the standard of storage interface for container. It provides the same in-tree AWS EBS plugin features including volume creation, volume attachment, volume mounting and volume scheduling. It is also configurable on what is the EBS volume type to create, what is the file system file should be formatted, which KMS key to use to create encrypted volume, etc.
 
 ## Motivation
-Similar to CNI plugins, AWS EBS CSI driver will be a stand alone plugin that lives out-of-tree of kuberenetes. Being out-of-tree, it will be benefit from being modularized, maintained and optimized without affecting kubernetes core code base. Aside from those benefits, it could also be consumed by other container orchestrators such as ECS.
+Similar to CNI plugins, AWS EBS CSI driver will be a stand alone plugin that lives out-of-tree of kubernetes. Being out-of-tree, it will be benefit from being modularized, maintained and optimized without affecting kubernetes core code base. Aside from those benefits, it could also be consumed by other container orchestrators such as ECS.
 
 ### Goals
 AWS EBS CSI driver will provide similar user experience as in-tree EBS plugin:
 * An application developer will not notice any difference in the operation of EBS CSI driver versus the in-tree volume plugin. His/Her workflow will stay the same as before.
 * An infrastructure operator needs to deploy/upgrade the driver and create/update storageclass to let the driver to manage underlying storage backend. The storageclass need not be updated if the name of the csi-driver referenced does not change.
 
-Since EBS CSI Driver is out-of-tree implementation that comes outside of kuberenetes distrubtion, documentations will be provided on how to install, use and upgrade the driver.
+Since EBS CSI Driver is out-of-tree implementation that comes outside of kubernetes distrubtion, documentations will be provided on how to install, use and upgrade the driver.
 
 List of driver features include volume creation/deletion, volume attach/detach, volume mount/unmount, volume scheduling, create volume configurations, volume snapshotting, mount options, raw block volume, etc.
 
@@ -67,7 +67,7 @@ Operator enables the allowVolumeExpansion feature in storageclass. When there is
 
 ### Risks and Mitigations
 * *Information disclosure* - AWS EBS CSI driver requires permission to perform AWS operations on behalf of the user. The CSI driver will not log any of the user credentials. We will also provide the user with policies that limit the access of the driver to required AWS services.
-* *Escalation of Privileges* - Since EBS CSI driver is formatting and mounting volumes, it requires root privilege to permform the operations. So that driver will have higher privilege than other containers in the cluster. The driver will not execute random commands provided by untrusted user. All of its interfaces are only provided for kuberenetes system components to interact with. The driver will also validate requests to make sure it aligns with its assumption.
+* *Escalation of Privileges* - Since EBS CSI driver is formatting and mounting volumes, it requires root privilege to permform the operations. So that driver will have higher privilege than other containers in the cluster. The driver will not execute random commands provided by untrusted user. All of its interfaces are only provided for kubernetes system components to interact with. The driver will also validate requests to make sure it aligns with its assumption.
 
 ## Graduation Criteria
 * Static provisioning is implemented.
@@ -101,6 +101,6 @@ To downgrade the driver, perform following steps:
 ## Implementation History
 * 2018-11-26 Initial proposal to SIG
 * 2018-11-26 Initial KEP draft
-* 2018-12-03 Alpha release with kuberentes 1.13
+* 2018-12-03 Alpha release with kubernetes 1.13
 * 2018-03-25 Beta release with kubernetes 1.14
 

keps/sig-api-machinery/1623-standardize-conditions/README.md

@@ -53,7 +53,7 @@ checklist items _must_ be updated for the enhancement to be released.
 
 ## Summary
 
-While many Kuberentes APIs have `.status.conditions`, the schema of `condition` varies a lot between them.
+While many Kubernetes APIs have `.status.conditions`, the schema of `condition` varies a lot between them.
 There is very little commonality at the level of serialization, proto-encoding, and required vs optional.
 Conditions are central enough to the API to make a common golang type with a fixed schema.
 The schema can be a strong recommendation to all API authors.

keps/sig-api-machinery/2339-storageversion-api-for-ha-api-servers/README.md

@@ -410,7 +410,7 @@ CRDs.  In the future, this E2E could serve as part of a conformance test.
 
 - Feature implemented behind a feature flag
 - Initial unit and integration tests completed and enabled
-- Storage version support for Kuberentes API server and aggregated API servers
+- Storage version support for Kubernetes API server and aggregated API servers
 
 #### Beta
 

keps/sig-auth/1393-oidc-discovery/README.md

@@ -73,7 +73,7 @@ mechanism that, given an issuer URL, allows a client to discover the rest of the
 issuer metadata, including the key set. Providing an OIDC-compatible discovery
 document would allow flexibility in how relying parties authenticate KSA tokens;
 they can use existing OIDC authenticators in their language/framework of choice,
-without Kuberentes-specific or provider-specific logic.
+without Kubernetes-specific or provider-specific logic.
 
 ## Motivation
 

keps/sig-auth/1687-hierarchical-namespaces-subproject/README.md

@@ -183,7 +183,7 @@ The Hierarchical Namespace Controller is currently being developed within the
 Multi-Tenancy WG. This poses a problem because working groups are not meant to
 own code. As Sig-Auth is the sponsor for the Multi-Tenancy WG, it is fitting for
 it to move into a Sig-Auth subproject. All current code has been completed in a
-kuberenetes-sig repository and has followed it's governance. Moving Hierarchical
+kubernetes-sig repository and has followed it's governance. Moving Hierarchical
 Namespace Controller to a different foundation or non-CNCF owner seems unfitting.
 
 ### Abandon Hierarchical Namespace Controller

keps/sig-scheduling/986-resource-quota-scope-selectors/README.md

@@ -77,4 +77,4 @@ We should verify the automatic creation of quota and see if it causes any proble
 ## Implementation History
 
 - ResourceQuotaScopeSelectors was introduced as alpha in kubernetes 1.11
-- In Kuberenetes 1.12 this feature was promoted to Beta
+- In Kubernetes 1.12 this feature was promoted to Beta

keps/sig-storage/2263-volume-scale-testing/README.md

@@ -32,7 +32,7 @@ This KEP outlines a plan for testing scalability and performance of K8s storage
 ## Motivation
 
 Adding storage scale and performance tests will help:
-* Understand the current scale limits of the Kuberentes storage system.
+* Understand the current scale limits of the Kubernetes storage system.
 * Set expectations (SLOs) for consumers of the Volume API.
 * Determine bottlenecks and influence which need addressing.
 

keps/sig-storage/989-extend-datasource/README.md

@@ -129,7 +129,7 @@ Require addition of E2E tests using the clone feature of the CSI host provisione
 
 Currently the only feature gate related to DataSources is the VolumeSnapshotDataSource gate.  This KEP would require an additional Data Source related feature gate `VolumeDataSource`.  Going forward we may continue to add additional feature gates for new DataSource types.  This KEP proposes that feature for Alpha, then following through the standard process for graduation based on feedback and stability during it's alpha release cycle.
 
-Given that the only implementation changes in Kuberenetes is to enable the feature in the API (all of the actual Clone implementation is handled by the CSI Plugin and back end device) the main criteria for completion will be successful implementation and agreement from the CSI community regarding the Kubernetes API.
+Given that the only implementation changes in Kubernetes is to enable the feature in the API (all of the actual Clone implementation is handled by the CSI Plugin and back end device) the main criteria for completion will be successful implementation and agreement from the CSI community regarding the Kubernetes API.
 
 ## Implementation History
 

keps/sig-windows/1122-windows-csi-support/README.md

@@ -105,7 +105,7 @@ Given the above context, the main motivations for this KEP are:
 
 In this KEP, we propose a set of enhancements in pre-existing components to support CSI Node Plugins on Windows nodes.
 
-The following enhancements are necessary in existing Kuberentes community managed code:
+The following enhancements are necessary in existing Kubernetes community managed code:
 1. Ability to handle Windows file paths in the Kubelet plugin watcher for domain sockets on Windows nodes.
 2. Refactor code in the CSI Node Driver Registrar so that it can be compiled for Windows.
 3. Build official CSI Node Driver Registrar container images based on Windows base images and publish them in official CSI community container registry.
@@ -1171,7 +1171,7 @@ We could enable prometheus for volume operations metrics in the future
 <!--
 This section must be completed when targeting beta to a release.
 -->
-No. All the Windows OS versions supported by Kuberentes can support CSI-proxy.
+No. All the Windows OS versions supported by Kubernetes can support CSI-proxy.
 
 ###### Does this feature depend on any specific services running in the cluster?
 

keps/sig-windows/689-windows-gmsa/README.md

@@ -407,7 +407,7 @@ In order to enforce authorization of service accounts in a cluster before they c
 
 Today, if PSP or RBAC mode is not configured in a cluster, nothing stops pods with special capabilities from being scheduled. To align with this, we should allow GMSA configurations on pods to be enabled without requiring GMSAAuthorizer to be running and RBAC mode to be enabled.
 
-Further, decoupling basic GMSA functionality in the Kubelet and CRI layers from authorization keeps the core Kuberenetes code non-opinionated around enforcement of authorization of service accounts for GMSA usage. Kubernetes cluster setup tools as well as Kubernetes distribution vendors can ensure that RBAC mode is enabled and GMSAAuthorizer is configured and installed when Windows nodes joined to a domain are deployed in a cluster.
+Further, decoupling basic GMSA functionality in the Kubelet and CRI layers from authorization keeps the core Kubernetes code non-opinionated around enforcement of authorization of service accounts for GMSA usage. Kubernetes cluster setup tools as well as Kubernetes distribution vendors can ensure that RBAC mode is enabled and GMSAAuthorizer is configured and installed when Windows nodes joined to a domain are deployed in a cluster.
 
 
 <!-- end matter -->