Cloud providers

The kubernetes/kubernetes repo no longer ships in-tree cloud-provider implementations. What remains is the cloud-provider library in staging/src/k8s.io/cloud-provider, which every vendor's cloud-controller-manager consumes, plus a sample binary in cmd/cloud-controller-manager/ that demonstrates the wiring.

What got extracted

Historically, the kube-controller-manager and kubelet had per-cloud code paths for AWS, GCE, Azure, vSphere, OpenStack, and a handful of others. Over years, this code moved out:

• AWS → kubernetes/cloud-provider-aws
• GCE → kubernetes/cloud-provider-gcp
• Azure → kubernetes/cloud-provider-azure
• vSphere → kubernetes-sigs/cloud-provider-vsphere
• OpenStack → kubernetes/cloud-provider-openstack
• IBM Cloud, Alibaba, etc. → vendor-specific repos

Each project ships its own cloud-controller-manager binary that imports this repo's staging/src/k8s.io/cloud-provider library and the same controller code from staging/src/k8s.io/cloud-provider/controllers/ (node, route, service-load-balancer).

What's left in this repo

staging/src/k8s.io/cloud-provider/
├── cloud.go                       # The `Interface` every cloud must implement
├── controllers/
│   ├── node/                      # Initialize and label nodes from cloud metadata
│   ├── nodelifecycle/             # Detect nodes that have been deleted from the cloud
│   ├── route/                     # Pod-CIDR route programming (for clouds without overlay networks)
│   └── service/                   # Service type LoadBalancer reconciliation
├── controller-manager/            # Shared options + factory used by every CCM binary
├── api/                           # CloudConfig schema
└── ...

cmd/cloud-controller-manager/      # Sample CCM binary; not for production use
└── ...

The Cloud Provider interface

staging/src/k8s.io/cloud-provider/cloud.go::Interface is what each vendor implements. The methods are split across capabilities:

• LoadBalancer — EnsureLoadBalancer, UpdateLoadBalancer, EnsureLoadBalancerDeleted. Used by the service-LB controller.
• Instances / InstancesV2 — translate node identity to cloud instance IDs, return addresses and instance types.
• Routes — program cloud-network routes for pod CIDRs. Used by clouds that don't implement an overlay network.
• Zones — return availability-zone / region for a node. Used to seed the well-known topology labels.
• Clusters — return the cloud's notion of a cluster. Rarely implemented.

The CCM binary calls cloudprovider.GetCloudProvider("aws", configFile) at boot. Each provider registers itself with RegisterCloudProvider("name", builder).

Service type LoadBalancer

The most-used controller is staging/src/k8s.io/cloud-provider/controllers/service/. It:

1. Watches Services with spec.type=LoadBalancer.
2. Resolves Service ports + node addresses.
3. Calls LoadBalancer.EnsureLoadBalancer on the cloud interface.
4. Writes the returned external IP / hostname back to Service.Status.LoadBalancer.Ingress.

For external load balancers that need per-node health checks, the controller wires externalTrafficPolicy=Local to a per-Service healthcheck port programmed by kube-proxy.

Out-of-tree node controller

The Cloud-Node controller in staging/src/k8s.io/cloud-provider/controllers/node/ is the modern replacement for the kubelet's old --cloud-provider=<vendor> flag. It:

1. Watches Node resources with the well-known taint node.cloudprovider.kubernetes.io/uninitialized.
2. Fetches cloud metadata for each node (instance ID, zone, region, instance type).
3. Sets the corresponding labels and Spec.ProviderID.
4. Removes the taint.

Until the CCM removes the taint, no pod can be scheduled to the node. This guarantees no Pod runs before its cloud metadata is in place.

Running a cloud-controller-manager

A typical flag set:

cloud-controller-manager
  --cloud-provider=aws
  --cloud-config=/etc/kubernetes/cloud.conf
  --kubeconfig=/etc/kubernetes/cloud-controller-manager.conf
  --controllers=cloud-node,cloud-node-lifecycle,service,route
  --leader-elect=true
  --use-service-account-credentials=true

Operators must disable the same controllers in kube-controller-manager via --controllers=*,-cloud-node,-cloud-node-lifecycle,-service,-route so the two don't fight.

Why a sample CCM lives here

cmd/cloud-controller-manager/ exists as:

• A reference for vendors to copy.
• The thing the e2e suite uses when exercising the cloud-provider plumbing without depending on a real cloud (it pairs with a fake provider).

It is not intended for production use. Real clusters should run a vendor-specific CCM.

Key source files

File	Purpose
staging/src/k8s.io/cloud-provider/cloud.go	The Interface
staging/src/k8s.io/cloud-provider/controllers/node/node_controller.go	Node initialization controller
staging/src/k8s.io/cloud-provider/controllers/service/controller.go	Service LB controller
staging/src/k8s.io/cloud-provider/controllers/route/route_controller.go	Route controller
cmd/cloud-controller-manager/controller-manager.go	Sample CCM main
cmd/cloud-controller-manager/app/controllermanager.go	Sample CCM run loop