Does ReplicaSets replace Pods?

7/18/2019

I have a conceptional question, does ReplicaSets use Pod settings? Before i applied my ReplicaSets i deleted my Pods, so there is no information about my old Pods ? If I apply now the Replicaset does this reference to the Pod settings, so with all settings like readinessProbe/livenessProbe ... ? My Questions came up because in my replicaset.yml is a container section where I specified my docker image, but why does it need that information, isn't it a redundant information, because this information is in my pods.yml ?

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: test1
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: test1
        image: test/test
-- djkobi97
kubernetes

2 Answers

7/18/2019

Does ReplicaSets replace Pods?

Yes, if you have replicaset.yml you don't need pods.yml.

I have a conceptional question, does ReplicaSets use Pod settings? Before i applied my ReplicaSets i deleted my Pods, so there is no information about my old Pods ? If I apply now the Replicaset does this reference to the Pod settings, so with all settings like readinessProbe/livenessProbe ... ?

No, the ReplicaSet manifest has to contain the Pod specification in order to determine what is the configuration of the pods that should be deployed.

With the labels, you link the ReplicaSet to running Pods. You don't link the ReplicaSet.yml manifest to the Pods.yml manifest.

Don’t use naked Pods (that is, Pods not bound to a ReplicaSet or Deployment) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure.

In 99% of the cases, there isn't a separate pods.yml manifest. The pods + the ReplicaSet are defined in a single manifest, hence the containers section in the replicaset.yml.

-- cecunami
Source: StackOverflow

7/18/2019

Pods are the smallest deployable units of computing that can be created and managed in Kubernetes.

A Pod (as in a pod of whales or pea pod) is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers.

See, https://kubernetes.io/docs/concepts/workloads/pods/pod/.

So, you can specify how your Pod will be scheduled (one or more containers, ports, probes, volumes, etc.). But in case of the node failure or anything bad that can harm to the Pod, then that Pod won't be rescheduled (you have to rescheduled manually). So, in that case, you need a controller. Kubernetes provides some controllers (each one for different purposes). They are -

  1. ReplicaSet
  2. ReplicationController
  3. Deployment
  4. StatefulSet
  5. DaemonSet
  6. Job
  7. CronJob

All of the above controllers and the Pod together are called as Workload. Because they all have a podTemplate section. And they all create some number of identical Pods ass specified by the spec.replicas field (if this field exists in the corresponding workload manifest). They all are upper-level concept than Pod.

Though the Deployment is more suitable than the ReplicaSet, this answer focuses on ReplicaSet over Pod cause the question is between the Pod and ReplicaSet.

In addition, each one of the above controllers has it's own purpose. Like a ReplicaSet’s purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.

A ReplicaSet contains a podTemplate field including selectors to identify and acquire Pod(s). A pod template specifying the configuration of new Pods it should create to meet the number of replicas criteria. It creates and deletes Pod(s) as needed to reach the desired number. When a ReplicaSet needs to create new Pod(s), it uses its Pod template.

The Pod(s) maintained by a ReplicaSet has metadata.ownerReferences field, to tell which resource owns the current Pod(s).

A ReplicaSet identifies new Pods to acquire by using its selector. If there is a Pod that has no OwnerReference or the OwnerReference is not a controller and it matches a ReplicaSet’s selector, it will be immediately acquired by said ReplicaSet.

Ref: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/

**

Now, its time to answer your questions

Since ReplicaSet is one of the Pod controller (listed above), obviously, it needs a podTemplate (using this template, your Pods will be scheduled). All of the Pods the ReplicaSet creates will have the same Pod configuration (same containers, same ports, same readiness/livelinessProbe, volumes, etc.). And having this podTemplate is not redundant info, it's needed. So, if you have a Pod controller like ReplicaSet or other (as your need), you don't need the Pod itself anymore. Because the ReplicaSet (or the other controllers) will create Pod(s).

**

Guess, you got the answer.

-- Shudipta Sharma
Source: StackOverflow