Merge pull request #1248 from zhxcai/kube

Automatic merge from submit-queue.

Update technical words for kubernetes

contributors/design-proposals/architecture/0000-kep-template.md

@@ -165,7 +165,7 @@ Major milestones in the life cycle of a KEP should be tracked in
   design
 - the date implementation started
 - the first Kubernetes release where an initial version of the KEP was available
-- the version of Kubneretes where the KEP graduated to general availability
+- the version of Kubernetes where the KEP graduated to general availability
 - when the KEP was retired or superseded
 
 ## Drawbacks [optional]

contributors/design-proposals/architecture/1-kubernetes-enhancement-proposal-process.md

@@ -289,7 +289,7 @@ with the following example structure
 │   └── retired
 ├── sig-node
 │   ├── deferred
-│   ├── kublet
+│   ├── kubelet
 │   ├── orphaned
 │   └── retired
 ├── sig-release

contributors/design-proposals/scalability/kubemark.md

@@ -45,8 +45,8 @@ components on non-default ports, and in the same time will allow to run multiple
 generate credentials for cluster communication and pass them to HollowKubelet/HollowProxy to use. Master will treat all HollowNodes as
 normal ones.
 
-![Kubmark architecture diagram for option 1](Kubemark_architecture.png?raw=true "Kubemark architecture overview")
-*Kubmark architecture diagram for option 1*
+![Kubemark architecture diagram for option 1](Kubemark_architecture.png?raw=true "Kubemark architecture overview")
+*Kubemark architecture diagram for option 1*
 
 ### Option 2
 

contributors/design-proposals/scalability/scalability-testing.md

@@ -19,7 +19,7 @@ Once we have a better understanding of their consequences, we may want to
 decide to drop one of them, but we are not yet in that position.
 
 
-## Proposal 1 - Kubmark
+## Proposal 1 - Kubemark
 
 In this proposal we are focusing on scalability testing of master components.
 We do NOT focus on node-scalability - this issue should be handled separately.