In this lab, we will have a closer look at Kubernetes Replicasets. First, we will learn how ReplicaSets identify the PODs belonging to it. With that, they can control, how many POD replicas are up and running at any time. We will show that manually creating PODs with matching labels can have weird cuckoo’s eggs effects. Moreover, a POD can be detached from a ReplicaSet without stopping it by manipulating its label.

Reference

• ReplicaSets on kubernetes.io
• Main Post of this series

Step 0: Access the Kubernetes Playground

As always, we start by accessing the Katacode Kubernetes Playground.

Step 1: Create a ReplicaSet with three PODs

Step 1.1: Check that Namespace has not ReplicaSets

First, let us confirm that no ReplicaSet is running in the default namespace:

kubectl get rs

# output: No resources found.

Step 1.2: Download an Example ReplicaSet

Now, let us create a ReplicaSet from an example from kubernetes.io, so we can save some time:

curl -O https://kubernetes.io/examples/controllers/frontend.yaml
cp frontend.yaml frontend-minimalistic.yaml

Step 1.3: Minimize ReplicaSet Config

However, let us minimize the configuration in order to identify the necessary parts:

# frontend-minimalistic.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-rs                 #<------------- changed, other metadata removed
spec:
  # modify replicas according to your case
  replicas: 3                       #<------------- three replicas
  selector:
    matchLabels:
      tier: my-matching-label       #<------------- changed
  template:
    metadata:
      labels:
        tier: my-matching-label     #<------------- changed, other labels removed
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3
#<-------------- other information removed

Step 1.4: Create ReplicaSet

Now let us apply the minimalistic version:

kubectl apply -f frontend-minimalistic.yaml

replicaset.apps/frontend-rs created

Step 2: Review ReplicaSet & PODs

Let us review the Replicaset:

kubectl get rs

NAME          DESIRED   CURRENT   READY   AGE
frontend-rs   3         3         3       84s

Three POD replicas have been started:

kubectl get pod

NAME                READY   STATUS    RESTARTS   AGE
frontend-rs-8mpfg   1/1     Running   0          2m37s
frontend-rs-frzwm   1/1     Running   0          2m37s
frontend-rs-tzbqp   1/1     Running   0          2m37s

Step 3 (optional): Review Error Conditions

Here, let us review some possible error conditions for the case the YAML file is not consistent. For that, we vary the configuration YAML file a little bit.

Non-matching Label

What happens, if the labels of the selector and the template are not matching?

# frontend-not-matching.yaml (non-working example)
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-rs
spec:
  # modify replicas according to your case
  replicas: 3
  selector:
    matchLabels:
      tier: bla     #<------------------ not matching
  template:
    metadata:
      labels:
        tier: blub  #<------------------ not matching
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

In this case, we get the  following `selector` does not matchtemplate `labels` error message:

kubectl apply -f frontend-not-matching.yaml

The ReplicaSet "frontend-rs" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"tier":"blub"}: `selector` does not matchtemplate `labels`

Missing POD Template

If the labels are matching, but the template is missing, we get the following spec.template.spec.containers: Required value message:

kubectl apply -f frontend-no-spec.yaml

The ReplicaSet "frontend-rs" is invalid: spec.template.spec.containers: Required value

Step 4: Cockoo’s Egg: Acquire existing PODs

In this test, we will show that a ReplicaSet may acquire PODs that originally have not been created by its template.

Step 4.1: Delete ReplicaSet and its PODs

k delete -f frontend-minimalistic.yaml
replicaset.apps "frontend-rs" deleted

k get pods
NAME                READY   STATUS        RESTARTS   AGE
frontend-rs-frzwm   0/1     Terminating   0          34m
frontend-rs-tzbqp   0/1     Terminating   0          34m

k get pods
No resources found.

Step 4.2: Create PODs

Let us edit a file for the creation of two PODs:

# matching-label-pods.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod1
  labels:
    tier: my-matching-label
spec:
  containers:
  - name: hello1
    image: gcr.io/google-samples/hello-app:2.0

---

apiVersion: v1
kind: Pod
metadata:
  name: pod2
  labels:
    tier: my-matching-label
spec:
  containers:
  - name: hello2
    image: gcr.io/google-samples/hello-app:1.0

We choose labels that are matching the one we have used for the ReplicaSet above.

Step 4.3: Create ReplicaSet with matching Label Selector

k apply -f frontend-minimalistic.yaml
replicaset.apps/frontend-rs created

k get rs
NAME          DESIRED   CURRENT   READY   AGE
frontend-rs   3         3         3       5s

Step 4.4: Review Cuckoo’s Eggs

k get pods
NAME                READY   STATUS    RESTARTS   AGE
frontend-rs-xsp2r   1/1     Running   0          10s
pod1                1/1     Running   0          26s
pod2                1/1     Running   0          26s

In the last step, we can see that the ReplicaSet has acquired two cuckoo’s eggs: the two PODs we had created manually before. The ReplicaSet does not discriminate between existing PODs and PODs created by its template, as long as the label is matching:

k get pod -L tier
NAME                READY   STATUS    RESTARTS   AGE     TIER
frontend-rs-xsp2r   1/1     Running   0          6m59s   my-matching-label
pod1                1/1     Running   0          7m15s   my-matching-label
pod2                1/1     Running   0          7m15s   my-matching-label

Step 5: Get rid of cuckoo’s Egg without breaking it

Step 5.1: Edit Label of a POD

Now let us try to detach pod2 from the ReplicaSet without breaking it. For that, we change the label:

k edit pod pod2
pod/pod2 edited

Here, we have changed tier=my-matching-label to tier=my-non-matching-label.

Step 5.2: Review ReplicaSet and PODs

After that, we will see that the ReplicaSet has spun up an additional POD. At the same time, pod2 is detached from the ReplicaSet. It has a label that is not recognized by the ReplicaSet. Since pod2 is not counting, we see four instead of three PODs:

k get pods -L tier
NAME                READY   STATUS    RESTARTS   AGE   TIER
frontend-rs-gjkll   1/1     Running   0          22s   my-matching-label
frontend-rs-xsp2r   1/1     Running   0          12m   my-matching-label
pod1                1/1     Running   0          13m   my-matching-label
pod2                1/1     Running   0          13m   my-non-matching-label

k get rs
NAME          DESIRED   CURRENT   READY   AGE
frontend-rs   3         3         3       15m

Summary

ReplicaSets are making sure that a specified number of PODs are up and running all the time. ReplicaSets use labels to attach PODs and vice versa. This can lead to confusing situations with unwanted PODs attached to a ReplicaSet. However, you can also detach a POD from a ReplicaSet by changing its label.

Previous

• Jobs and CronJobs

Next

• Deployments and Daemonsets (Link will be updated)