ber. To avoid such a configuration drift and to introduce operational processes for backporting changes, it is a better practice to change the desired number of replicas declaratively in the ReplicaSet or some other definition and apply the changes to Kubernetes as shown in Example 24-2. We can scale resources managing multiple Pods such as ReplicaSets, Deployments, and StatefulSets. Notice the asymmetric behavior in scaling a StatefulSet with persis‐ tent storage. As described in Chapter 11,  Stateful Service , if the StatefulSet has a  .spec.volumeClaimTemplates  element, it will create PVCs while scaling, but it won’t delete them when scaling down to preserve the storage from deletion. Another Kubernetes resource that can be scaled but follows a different naming con‐ vention is the Job resource, which we described in Chapter 7,  Batch Job . A Job can be scaled to execute multiple instances of the same Pod at the same time by changing the  .spec.parallelism  field rather than  .spec.replicas . However, the semantic effect is the same: increased capacity with more processing units that act as a single logical unit. For describing resource fields we use a JSON path notation. For example,  .spec.replicas  points to the  replicas  field of the resource’s  spec  section. Both manual scaling styles (imperative and declarative) expect a human to observe or anticipate a change in the application load, make a decision on how much to scale, and apply it to the cluster. They have the same effect, but they are not suitable for dynamic workload patterns that change often and require continuous adaptation. Next, let’s see how we can automate scaling decisions themselves. Many workloads have a dynamic nature that varies over time and makes it hard to have a fixed scaling configuration. But cloud-native technologies such as Kubernetes enable creating applications that adapt to changing loads. Autoscaling in Kubernetes allows us to define a varying application capacity that is not fixed but instead ensures just enough capacity to handle a different load. The most straightforward approach to achieving such behavior is by using a HorizontalPodAutoscaler (HPA) to horizontally scale the number of pods. Horizontal Pod Autoscaling Solution  |  205 kubectl apply -f random-generator-deployment.yaml Example 24-2. Using a Deployment for declaratively setting the number of replicas