Try Kubernetes

Documentation for Kubernetes v1.4 is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.

Edit This Page

What is a Replica Set?

Replica Set is the next-generation Replication Controller. The only difference between a Replica Set and a Replication Controller right now is the selector support. Replica Set supports the new set-based selector requirements as described in the labels user guide whereas a Replication Controller only supports equality-based selector requirements.

Most kubectl commands that support Replication Controllers also support Replica Sets. One exception is the rolling-update command. If you want the rolling update functionality please consider using Deployments instead. Also, the rolling-update command is imperative whereas Deployments are declarative, so we recommend using Deployments through the rollout command.

While Replica Sets can be used independently, today it’s mainly used by Deployments as a mechanism to orchestrate pod creation, deletion and updates. When you use Deployments you don’t have to worry about managing the Replica Sets that they create. Deployments own and manage their Replica Sets.

When to use a Replica Set?

A Replica Set ensures that a specified number of pod “replicas” are running at any given time. However, a Deployment is a higher-level concept that manages Replica Sets and provides declarative updates to pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don’t require updates at all.

This actually means that you may never need to manipulate Replica Set objects: use directly a Deployment and define your application in the spec section.

Example

replicasets/frontend.yaml
 
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
  # these labels can be applied automatically
  # from the labels in the pod template if not set
  # labels:
    # app: guestbook
    # tier: frontend
spec:
  # this replicas value is default
  # modify it according to your case
  replicas: 3
  # selector can be applied automatically
  # from the labels in the pod template if not set,
  # but we are specifying the selector here to
  # demonstrate its usage.
  selector:
    matchLabels:
      tier: frontend
    matchExpressions:
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        env:
        - name: GET_HOSTS_FROM
          value: dns
          # If your cluster config does not include a dns service, then to
          # instead access environment variables to find service host
          # info, comment out the 'value: dns' line above, and uncomment the
          # line below.
          # value: env
        ports:
        - containerPort: 80

Saving this config into frontend.yaml and submitting it to a Kubernetes cluster should create the defined Replica Set and the pods that it manages.

$ kubectl create -f frontend.yaml
replicaset "frontend" created
$ kubectl describe rs/frontend
Name:		frontend
Namespace:	default
Image(s):	gcr.io/google_samples/gb-frontend:v3
Selector:	tier=frontend,tier in (frontend)
Labels:		app=guestbook,tier=frontend
Replicas:	3 current / 3 desired
Pods Status:	3 Running / 0 Waiting / 0 Succeeded / 0 Failed
No volumes.
Events:
  FirstSeen	LastSeen	Count	From				SubobjectPath	Type		Reason			Message
  ---------	--------	-----	----				-------------	--------	------			-------
  1m		1m		1	{replicaset-controller }			Normal		SuccessfulCreate	Created pod: frontend-qhloh
  1m		1m		1	{replicaset-controller }			Normal		SuccessfulCreate	Created pod: frontend-dnjpy
  1m		1m		1	{replicaset-controller }			Normal		SuccessfulCreate	Created pod: frontend-9si5l
$ kubectl get pods
NAME             READY     STATUS    RESTARTS   AGE
frontend-9si5l   1/1       Running   0          1m
frontend-dnjpy   1/1       Running   0          1m
frontend-qhloh   1/1       Running   0          1m

Replica Set as an Horizontal Pod Autoscaler target

A Replica Set can also be a target for Horizontal Pod Autoscalers (HPA), i.e. a Replica Set can be auto-scaled by an HPA. Here is an example HPA targeting the Replica Set we created in the previous example.

replicasets/hpa-rs.yaml
 
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-scaler
spec:
  scaleTargetRef:
    kind: ReplicaSet
    name: frontend
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

Saving this config into hpa-rs.yaml and submitting it to a Kubernetes cluster should create the defined HPA that autoscales the target Replica Set depending on the CPU usage of the replicated pods.

kubectl create -f hpa-rs.yaml

Alternatively, you can just use the kubectl autoscale command to acomplish the same (and it’s easier!)

kubectl autoscale rs frontend

Analytics

Create an Issue Edit this Page