Fixed kubeadm and kubelet to lower case per Lubomir.

Author: cheftako

keps/sig-cloud-provider/0013-build-deploy-ccm.md

@@ -50,7 +50,7 @@ status: provisional
           - [Migrating to a CCM Build](#migrating-to-a-ccm-build)
           - [Flags, Service Accounts, etc](#flags,-service-accounts,-etc)
           - [Deployment Scripts](#deployment-scripts)
-          - [KubeAdm](#kubeadm)
+          - [kubeadm](#kubeadm)
           - [CI, TestGrid and Other Testing Issues](#ci,-testgrid-and-other-testing-issues)
    - [Alternatives](#alternatives)
       - [Staging Alternatives](#staging-alternatives)
@@ -102,7 +102,7 @@ changes in to an official build. The relevant dependencies require changes in th
 
 - [Kube Controller Manager](https://kubernetes.io/docs/reference/generated/kube-controller-manager/) - Track usages of [CMServer.CloudProvider](https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-controller-manager/app/options/options.go)
 - [API Server](https://kubernetes.io/docs/reference/generated/kube-apiserver/) - Track usages of [ServerRunOptions.CloudProvider](https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-apiserver/app/options/options.go)
-- [Kubelet](https://kubernetes.io/docs/reference/generated/kubelet/) - Track usages of [KubeletFlags.CloudProvider](https://github.com/kubernetes/kubernetes/blob/master/cmd/kubelet/app/options/options.go)
+- [kubelet](https://kubernetes.io/docs/reference/generated/kubelet/) - Track usages of [KubeletFlags.CloudProvider](https://github.com/kubernetes/kubernetes/blob/master/cmd/kubelet/app/options/options.go)
 - [How Cloud Provider Functionality is deployed to and enabled in the cluster](https://kubernetes.io/docs/setup/pick-right-solution/#hosted-solutions) - Track usage from [PROVIDER_UTILS](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-util.sh)
 
 For the cloud providers who are in repo, moving out would allow them to more quickly iterate on their solution and
@@ -162,7 +162,7 @@ not have to attempt to support all the different cloud provider configurations.
 local deployment option, which K8s/K8s should continue to support.
 
 Lastly there are specific flags which need to be set on various binaries for this to work. Kubernetes API-Server, 
-Kubernetes Controller-Manager and Kubelet should all have the --cloud-provider flag set to external. For the Cloud 
+Kubernetes Controller-Manager and kubelet should all have the --cloud-provider flag set to external. For the Cloud 
 Controller-Manager the --cloud-provider flag should be set appropriately for that cloud provider. In addition we need 
 to set the set of controllers running in the Kubernetes Controller-Manager. More on that later.
 
@@ -185,7 +185,7 @@ The code which needs to be shared can be broken into several types.
 There is code which properly belongs in the various cloud-provider repos. The classic example of this would be the 
 implementations of the cloud provider interface. (Eg. [gce](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce) 
 or [aws](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)) These sections of code 
-need to be shared until we can remove all cloud provider dependencies from K8s/K8s. (i.e. When KAS, KCM and Kubelet no 
+need to be shared until we can remove all cloud provider dependencies from K8s/K8s. (i.e. When KAS, KCM and kubelet no 
 longer contain a cloud-provider flag and no longer depend on either the cloud provider interface or any cloud provider 
 implementations) At that point they should be permanently moved to the individual provider repos. I would suggest that 
 as long as the code is shared it be in vendor for K8s/cloud-provider. We would want to create a separate Staging repo 
@@ -324,7 +324,7 @@ import (
 We then get to the issue of creating a deployable artifact for each cloud provider. There are several artifacts beyond 
 the CCM which are cloud provider specific. These artifacts include things like the deployment scripts themselves, the 
 contents of the add-on manager and the sidecar needed to get CSI/cloud-specific persistent storage to work. Ideally 
-these would then be packaged with a version of the Kubernetes core components (KAS, KCM, Kubelet, …) which have not 
+these would then be packaged with a version of the Kubernetes core components (KAS, KCM, kubelet, …) which have not 
 been statically linked against the cloud provider libraries. However in the short term the K8s/K8s deployable builds 
 will still need to link these binaries against all of the in-tree plugins. We need a way for the K8s/cloud-provider 
 repo to consume artifacts generated by the K8s/K8s repo. For official releases these artifacts should be published to a 
@@ -359,9 +359,9 @@ upgrade steps are cloud provider specific, we do provide guidance that the contr
 first (master version >= kubelet version) and that the system should be able to handle up to a 2 revision difference 
 between the control plane and the kubelets. In addition with disruptions budgets etc, there will not be a consistent 
 version of the kubelets, until the upgrade completes. So we need to ensure that our cloud provider/CCM builds work with 
-existing clusters. This means that we need to account for things like older Kubelets having the cloud provider enabled 
+existing clusters. This means that we need to account for things like older kubelets having the cloud provider enabled 
 and using it for things like direct volume mount/unmount, IP discovery, … We can even expect that scaling events such 
-as increases in the size of a replica set may cause us to deploy old Kubelet images which directly use the cloud 
+as increases in the size of a replica set may cause us to deploy old kubelet images which directly use the cloud 
 provider implementation in clusters which are controlled by a CCM build. We need to make sure we test these sort of 
 scenarios and ensure they work (get their IP, can mount cloud specific volume types, …) 
 
@@ -423,11 +423,11 @@ and flexibility in K8s/K8s is not needed in K8s/Cloud-provider. It is also worth
 [CCM Repo Requirements](#repository-requirements) for some suggestions on common K8s/Cloud-provider 
 layout suggestions. These include an installer directory for custom installer code.
 
-#### KubeAdm [WIP]
+#### kubeadm [WIP]
 
-KubeAdm is a tool for creating clusters. For reference see [creating cluster with KubeAdm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/). 
-Need to determine how KubeAdm and K8s/Cloud-providers should interact. More planning clearly needs to be done on 
-cloud-provider and KubeAdm planning.
+kubeadm is a tool for creating clusters. For reference see [creating cluster with kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/). 
+Need to determine how kubeadm and K8s/Cloud-providers should interact. More planning clearly needs to be done on 
+cloud-provider and kubeadm planning.
 
 #### CI, TestGrid and Other Testing Issues [WIP]