concept ReplicaSets in category kubernetes

This is an excerpt from Manning's book Learn Kubernetes in a Month of Lunches MEAP V07. Login to get full access to this book.

You'll use a Deployment to describe your app in most cases; the Deployment is a controller which manages ReplicaSets, and the ReplicaSet is a controller which manages Pods. You can create a ReplicaSet directly rather than using a Deployment, and we'll do that for the first few exercises just to see how scaling works. The YAML for a ReplicaSet is almost the same as for a deployment - it needs a selector to find the resources it owns, and a Pod template to create resources. Listing 6.1 shows an abbreviated spec.

Deployments add a useful management layer on top of ReplicaSets, so now that we know how they work we won't be using ReplicaSets directly any more - Deployments should be your first choice for defining applications. We won't explore all the features of Deployments until we get to application upgrades and rollbacks in chapter 9, but it's useful to understand exactly what the extra abstraction gives you - figure 6.6 shows that.

Figure 6.6 Zero is a valid number of desired replicas - Deployments scale down old ReplicaSets to zero

A Deployment is a controller for ReplicaSets, and to run at scale you include the same replicas field in the Deployment spec, and that gets passed on to the ReplicaSet. Listing 6.2 shows the abbreviated YAML for the Pi web application which explicitly sets two replicas.

# deploy the Pi app:
kubectl apply -f pi/web/
 
# check the ReplicaSet:
kubectl get rs -l app=pi-web
 
# scale up to more replicas:
kubectl apply -f pi/web/update/web-replicas-3.yaml
 
# check the RS:
kubectl get rs -l app=pi-web
 
# deploy a changed Pod spec with enhanced logging:
kubectl apply -f pi/web/update/web-logging-level.yaml
 
# and check ReplicaSets again:
kubectl get rs -l app=pi-web

copy

This is an excerpt from Manning's book GitOps and Kuberentes MEAP V06 epub. Login to get full access to this book.

Deployments - enables declarative updates for Pods and ReplicaSets.

Figure 5.4 Deployment Tutorial with ReplicaSets

This is an excerpt from Manning's book Kubernetes in Action. Login to get full access to this book.

The first thing to note is that ReplicaSets aren’t part of the v1 API, so you need to ensure you specify the proper apiVersion when creating the resource. You’re creating a resource of type ReplicaSet which has much the same contents as the Replication-Controller you created earlier.

Both ReplicationControllers and ReplicaSets are used for running a specific number of pods deployed anywhere in the Kubernetes cluster. But certain cases exist when you want a pod to run on each and every node in the cluster (and each node needs to run exactly one instance of the pod, as shown in figure 4.8).

Figure 4.8. DaemonSets run only a single pod replica on each node, whereas ReplicaSets scatter them around the whole cluster randomly.

You could have started this chapter by creating a ReplicaSet instead of a Replication-Controller, but I felt it would be a good idea to start with what was initially available in Kubernetes. Plus, you’ll still see ReplicationControllers used in the wild, so it’s good for you to know about them. That said, you should always create ReplicaSets instead of ReplicationControllers from now on. They’re almost identical, so you shouldn’t have any trouble using them instead.

You usually won’t create them directly, but instead have them created automatically when you create the higher-level Deployment resource, which you’ll learn about in chapter 9. In any case, you should understand ReplicaSets, so let’s see how they differ from ReplicationControllers.