I know what a replication controller is responsible for and what it is not. I exactly know the purpose and how to use them. But I can't find an answer to this question. What is a replication controller? Is it a pod? Is it a process? I think it is not a pod because when I list the pods, replication controllers are not listed. You say "kubectl get rc" to list replication controllers. So is it a process? If it is a process where is it created and where does it run? On master node? If it is a single process, isn't it also a single point of failure?
Edit: As I said, I know what it is, what it is not. And I exactly know how to use it. Please don't try to explain what ReplicationController and ReplicaSet do.
Edit2:
Here is the conclusion from our discussion with Suresh Vishnoi over the chat.
"kube-controller-manager" pod which runs inside "kube-system" namespace is the process that manages all the controller loops.
A ReplicationController is a type of controller loop along with others like NamespaceController, EndpointController, ServiceAccountController etc.
From offical kubernetes docs: In applications of robotics and automation, a control loop is a non-terminating loop that regulates the state of the system. In Kubernetes, a controller is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and serviceaccounts controller.(ref)
"kube-controller-manager" pod runs inside "kube-system" namespace on "master" nodes. A ReplicationController, ReplicasetController etc. (control loops) is a "goroutine" in this "kube-controller-manager" pod. They are not individual processes. This can also be verified if you rsh into "kube-controller-manager" pod (
oc rsh <POD_NAME>) and dops -ef. There you will see a single process.See this piece of code: https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-controller-manager/app/apps.go#L69
Go Routines vs Threads: http://tleyden.github.io/blog/2014/10/30/goroutines-vs-threads/
Kudos to Suresh Vishnoi, Cheers
Replication Controller is depreciated. Replication Controller was responsible for ensuring that enough number of replicas of your Pod are running in a given time.
Instead of Using Replication Controller you can take advantage of Replicas inside your deployment file to specify the desired number of replicas of your pod.
kind: Deployment
metadata:
name: admin
spec:
replicas: 3
selector:
matchLabels:Kubernetes replication controller is an older version of replica sets.
Replication controller basically works to manage the replica running for particular deployments.
kind: Deployment
metadata:
name: <Meta data>
spec:
replicas: 3
selector:Difference between Replication controller and replicasets is that, Replicasets supports set based selector.
note that replication controllers are replaced with ReplicaSets in kubernetes. Replicaset/replication Controller is a daemon that runs in never ending loop. Its purpose is to compare running pods count with the desired count.
If there is a mismatch then the controller will try to deploy new pods until the actual pods count matches desired count.
example, If you deploy a deployment or stateful object or a ReplicaSet with replica count as 3. Then it is the replication/replicaset controller that is responsible to ensure that 3 pods are running at any point of time in the cluster.
kube-controller-manager is the process you are looking for. It has the reconciling loops which works toward getting the shared state of cluster and then make changes to bring the current status of the server to the desired state. The key controllers are replication controller, endpoint controller, namespace controller, and service account controller.
If it is a process where is it created and where does it run? On master node?
Its in the kube-system namespace
If it is a single process, isn't it also a single point of failure?
it provide following flags in order to achieve High availability
-leader-elect Default: true
Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability.
--leader-elect-lease-duration duration Default: 15s
The duration that non-leader candidates will wait after observing a leadership renewal until attempting to acquire leadership of a led but unrenewed leader slot. This is effectively the maximum duration that a leader can be stopped before it is replaced by another candidate. This is only applicable if leader election is enabled.
--leader-elect-renew-deadline duration Default: 10s
The interval between attempts by the acting master to renew a leadership slot before it stops leading. This must be less than or equal to the lease duration. This is only applicable if leader election is enabled.