<p>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 &quot;kubectl get rc&quot; 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?</p>
<p><strong>Edit</strong>: 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.</p>
<p><strong>Edit2</strong>:</p>
<p><strong>Here is the conclusion from our discussion with Suresh Vishnoi over the chat.</strong></p>
<blockquote>
<p>&quot;kube-controller-manager&quot; pod which runs inside &quot;kube-system&quot;
namespace is the process that manages all the controller loops.</p>
<p>A ReplicationController is a type of controller loop along with others
like NamespaceController, EndpointController, ServiceAccountController
etc.</p>
<p><strong>From offical kubernetes docs</strong>: <em>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.</em>(<a href="https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/" rel="nofollow noreferrer">ref</a>)</p>
<p>&quot;kube-controller-manager&quot; pod runs inside &quot;kube-system&quot; namespace on
&quot;master&quot; nodes. A ReplicationController, ReplicasetController etc.
(control loops) is a &quot;goroutine&quot; in this &quot;kube-controller-manager&quot;
pod. They are not individual processes. This can also be verified if you rsh into &quot;kube-controller-manager&quot; pod (<code>oc rsh &lt;POD_NAME&gt;</code>) and do <code>ps -ef</code>. There you will see a single process.</p>
<p>See this piece of code:
<a href="https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-controller-manager/app/apps.go#L69" rel="nofollow noreferrer">https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-controller-manager/app/apps.go#L69</a></p>
<p>Go Routines vs Threads:
<a href="http://tleyden.github.io/blog/2014/10/30/goroutines-vs-threads/" rel="nofollow noreferrer">http://tleyden.github.io/blog/2014/10/30/goroutines-vs-threads/</a></p>
</blockquote>
<p>Kudos to <em>Suresh Vishnoi</em>, Cheers</p>

honor
<p><strong><a href="https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/" rel="nofollow noreferrer">kube-controller-manager</a></strong> 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 <strong>replication controller</strong>, endpoint controller, namespace controller, and service account controller.</p>

<blockquote>
  <p>If it is a process where is it created and where does it run? On master node?</p>
</blockquote>

<p>Its in the kube-system namespace </p>

<blockquote>
  <p>If it is a single process, isn't it also a single point of failure?</p>
</blockquote>

<p>it provide following flags in order to achieve  <strong>High availability</strong> </p>

<pre><code>-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.
</code></pre>
