Cloud controller manager
The cloud controller manager (CCM) is a Kubernetes component responsible for interaction with external cloud providers via an agreed interface. When a Kubernetes cluster needs to create a resource on the provider's side, CCM triggers the provider's API. CCM is installed automatically on each node of the control plane during cluster creation.
There are two scenarios that involve the Servers.com CCM:
- Node initialization
- Load balancer creation
Node initialization
Node initialization is a process of accepting a node as a part of a Kubernetes cluster. When a server is provisioned on the Servers.com side, it is integrated into the cluster with the help of the CCM.
Load balancer creation
When you create a LoadBalancer service, Kubernetes sends a command to the CCM to create an L4 (TCP) load balancer. This load balancer is located outside of the Kubernetes cluster and serves to route traffic to your applications. CCM creates a new load balancer for each service object with the LoadBalancer type.
IP address assignment
The actual creation of the load balancer happens asynchronously, and information about the provisioned balancer and its IP address is pushed back into the .status.loadBalancer field of a service object. Once the service object is destroyed, its IP address is returned to the shared pool and will eventually be assigned to another object.
Billing
A load balancer created via CCM will be billed at its regular price as a standalone service.
Annotations
Annotations manage parameters of a TCP (L4) load balancer. They are specified within a Service object.
| Name | Default | Example | Description |
|---|---|---|---|
servers.com/load-balancer-name | (automatic) | ams1-cluster-balancer | By default, a load balancer gets an automatically generated name. This annotation allows giving it a custom name when creating a service object. |
servers.com/load-balancer-location-id | (automatic) | 1 | By default, a load balancer is created in an automatically selected location. To define a specific one, specify its Public API ID during service object creation. |
servers.com/proxy-protocol | false | true | The proxy protocol enables applications to receive the client IP address, the load balancer IP address, and both port numbers. Requests originating from outside the cluster follow this path and work as expected. However, requests originating from a Pod and sent to the Service may be handled by Kubernetes as cluster-internal Service traffic and routed directly to the Service backend without traversing the external load balancer. In that case, the connection does not pass through the L4 load balancer, the PROXY protocol header is not injected, and applications expecting it may reject the connection or parse it incorrectly. Managed by the boolean values true and false. |
servers.com/cluster-id | nil | ex4mp1e | When a cluster ID is specified, a load balancer for the CCM will be created in the dedicated cluster. When not specified, a load balancer will be created in a public cluster. |
This is an example of a LoadBalancer service with the proxy protocol annotation:
---
apiVersion: v1
kind: Service
metadata:
name: hello-world-svc
annotations:
servers.com/proxy-protocol: "true"
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: hello-world-app
type: LoadBalancer