# 5 SRE tips for Rails workloads in Kubernetes

DevFeed: [5 SRE tips for Rails workloads in Kubernetes](<https://devfeed.tech/articles/5-sre-tips-for-rails-workloads-in-kubernetes-20020.md>)

Original publisher: [Read original article](<https://technology.doximity.com/articles/5-sre-tips-for-rails-workloads-in-kubernetes>)

Author: Doximity

Published: 2022-12-02T13:00:00Z

Content type: article

Language: en

Sources: [Doximity](<https://devfeed.tech/sources/doximity.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Rails](<https://devfeed.tech/topics/rails.md>), [Deployment Strategies](<https://devfeed.tech/topics/deployment-strategies.md>), [Kafka](<https://devfeed.tech/topics/kafka.md>), [Sidekiq](<https://devfeed.tech/topics/sidekiq.md>), [site-reliability-engineering](<https://devfeed.tech/topics/site-reliability-engineering.md>)

Tags: [bugs](<https://devfeed.tech/tags/bugs.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [deployment-strategies](<https://devfeed.tech/tags/deployment-strategies.md>), [kafka](<https://devfeed.tech/tags/kafka.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [performance](<https://devfeed.tech/tags/performance.md>), [rails](<https://devfeed.tech/tags/rails.md>), [sidekiq](<https://devfeed.tech/tags/sidekiq.md>)

## AI overview

The article presents five changes made to Kubernetes clusters to better support Rails workloads and workflows. The supplied text focuses on deployment strategies: RollingUpdate is used for web traffic, while Recreate is used for Kafka and Sidekiq workloads because RollingUpdate caused rebalancing, performance, and compatibility issues during deployments.

## Source excerpt

In a previous post we shared some suggestions for how to adjust a Rails application to make it run better in a containerized setting. In this post I'd like to explore the opposite relationship: five changes we have made to our Kubernetes clusters to better accommodate Rails workloads and workflows. All of these ideas can be relevant to non-Rails apps too! Selecting the right deployment strategies The two deployment strategies Kubernetes offers out of the box are RollingUpdate or Recreate. Initially we selected RollingUpdate for all of our workloads; with this strategy some new pods are created before old ones are terminated. The RollingUpdate strategy is ideal for our web traffic because if Kubernetes shuts down all of the existing pods before it starts up any new pods, users will see 5XX errors until the new web pods are healthy, not good. That said, the RollingUpdate strategy created issues with our Sidekiq and Kafka workloads so we switched those to use the Recreate strategy. Looking at Kafka first, consumers are basically just a group of processes working together to handle messages. Kafka consumers follow a rebalancing protocol when a new member wants to join a consumer group. During deployments we encountered bugs and performance issues while using RollingUpdate approach because new pods kept trickling-in and wanting to join the consumer group therefore triggering multiple rebalances. Switching our Kafka consumers to deploy using the Recreate strategy means all the existing Pods get killed before any new pods get created. This results in much more predictable deployment behavior, and now we see only a single rebalance with all new consumers joining the group at basically the same time. Next, looking at Sidekiq, it does not stop workers from processing jobs when a new worker process joins, so we didn't have quite as many issues with using the RollingUpdate approach. However, it did occasionally cause subtle bugs on some deployments. For example, if a team creat