= Replacing {brandname} Pods on Kubernetes
As an alternative to rolling upgrades, you can do a rolling update on Kubernetes that replaces existing pods with new ones.

* link:https://docs.openshift.org/latest/dev_guide/deployments/deployment_strategies.html#rolling-strategy[Rolling Updates]
* link:https://docs.openshift.org/latest/dev_guide/deployments/deployment_strategies.html#when-to-use-a-rolling-deployment[When to Use a Rolling Deployment]

.Example DeploymentConfiguration for Rolling Updates
[source,yaml]
----
include::config_examples/rolling_updates.yaml[]
----

[TIP]
====
Kubernetes uses very similar concept to Deployment Configurations called
`Deployment`.
====

It is also highly recommended to adjust the JGroups stack to discover new nodes (or leaves) more quickly. One should at least
adjust the value of `FD_ALL` timeout and adjust it to the longest GC Pause.

.Other hints for tuning configuration parameters are:
* OpenShift should replace running nodes one by one. This can be achieved by adjusting `rollingParams` (`maxUnavailable: 1` and `maxSurge: 1`).
* Depending on the cluster size, one needs to adjust `updatePeriodSeconds` and `intervalSeconds`. The bigger cluster size is, the bigger those values should be used.
* When using Initial State Transfer, the `initialDelaySeconds` value for both probes should be set to higher value.
* During Initial State Transfer nodes might not respond to probes. The best results are achieved with higher values of `failureThreshold` and `successThreshold` values.
