<p>So right now we are trying to get a <a href="https://artifacthub.io/packages/helm/bitnami/redis" rel="nofollow noreferrer">Bitnami Redis Sentinel</a> cluster working, together with our Rails app + Sidekiq.</p>
<p>We tried different things, but it's not really clear to us, how we should specify the sentinels for Sidekiq (crutial part is here, that the sentinel nodes are READ ONLY, so we cannot use them for sidekiq, since job states get written).</p>
<p>Since on Kubernetes there are only 2 services available: &quot;redis&quot; and &quot;redis-headless&quot; (not sure how they differ?) - how can I specify the sentinels like this:</p>
<pre class="lang-rb prettyprint-override"><code>Sidekiq.configure_server do |config|
  config.redis = {
    url: &quot;redis&quot;,
    sentinels: [
      { host: &quot;?&quot;, port: 26379 } # why do we have to specify it here seperately, since we should be able to get a unified answer via a service, or?
      { host: &quot;?&quot;, port: 26379 }  
      { host: &quot;?&quot;, port: 26379 } 
    }
  }
end
</code></pre>
<p>Would be nice if someone can shed some light on this. As far as I understood, <strong>the bitnami redis sentiel only returns the IP of the master and the application has to handle the corresponding writes to this master then</strong> (<a href="https://github.com/bitnami/charts/tree/master/bitnami/redis#master-replicas-with-sentinel" rel="nofollow noreferrer">https://github.com/bitnami/charts/tree/master/bitnami/redis#master-replicas-with-sentinel</a>) - but I really don't understand on how to do this with sidekiq?</p>

<h2>Difference between a Kubernetes Service and a Headless Service</h2>
<p>Let's get started by clarifying the difference between a Headless Service and a Service.</p>
<p>A Service allows one to connect to one Pod, while a headless Service returns the list of available IP addresses from all the available pods, allowing to auto-discover.</p>
<p>A better detailed explanation by Marco Luksa has been published on SO <a href="https://stackoverflow.com/a/52713482/1996540">here</a>:</p>
<blockquote>
<p>Each connection to the service is forwarded to one randomly selected backing pod. But what if the client needs to connect to all of those pods? What if the backing pods themselves need to each connect to all the other backing pods. Connecting through the service clearly isn’t the way to do this. What is?</p>
<p>For a client to connect to all pods, it needs to figure out the the IP of each individual pod. One option is to have the client call the Kubernetes API server and get the list of pods and their IP addresses through an API call, but because you should always strive to keep your apps Kubernetes-agnostic, using the API server isn’t ideal</p>
<p>Luckily, Kubernetes allows clients to discover pod IPs through DNS lookups. Usually, when you perform a DNS lookup for a service, the DNS server returns a single IP — the service’s cluster IP. But if you tell Kubernetes you don’t need a cluster IP for your service (you do this by setting the clusterIP field to None in the service specification ), the DNS server will return the pod IPs instead of the single service IP. Instead of returning a single DNS A record, the DNS server will return multiple A records for the service, each pointing to the IP of an individual pod backing the service at that moment. Clients can therefore do a simple DNS A record lookup and get the IPs of all the pods that are part of the service. The client can then use that information to connect to one, many, or all of them.</p>
<p>Setting the clusterIP field in a service spec to None makes the service headless, as Kubernetes won’t assign it a cluster IP through which clients could connect to the pods backing it.</p>
</blockquote>
<p>&quot;Kubernetes in Action&quot; by Marco Luksa</p>
<h2>How to specify the sentinels</h2>
<p>As the <a href="https://github.com/redis/redis-rb#sentinel-support" rel="nofollow noreferrer">Redis documentation</a> say:</p>
<blockquote>
<p>When using the Sentinel support you need to specify a list of sentinels to connect to. The list does not need to enumerate all your Sentinel instances, but a few so that if one is down the client will try the next one. The client is able to remember the last Sentinel that was able to reply correctly and will use it for the next requests.</p>
</blockquote>
<p>So the idea is to give what you have, and if you scale up the redis pods, then you don't need to re-configure Sidekiq (or Rails if you're using Redis for caching).</p>
<h2>Combining all together</h2>
<p>Now you just need a way to fetch the IP addresses from the headless service in Ruby, and configure Redis client sentinels.</p>
<p>Fortunately, since Ruby 2.5.0, the <a href="https://ruby-doc.org/stdlib-2.5.1/libdoc/resolv/rdoc/Resolv.html" rel="nofollow noreferrer">Resolv class</a> is available and can do that for you.</p>
<pre><code>irb(main):007:0&gt; Resolv.getaddresses &quot;redis-headless&quot;
=&gt; [&quot;172.16.105.95&quot;, &quot;172.16.105.194&quot;, &quot;172.16.9.197&quot;]
</code></pre>
<p>So that you could do:</p>
<pre class="lang-rb prettyprint-override"><code>Sidekiq.configure_server do |config|
  config.redis = {
    # This `host` parameter is used by the Redis gem with the Redis command
    # `get-master-addr-by-name` (See https://redis.io/topics/sentinel#obtaining-the-address-of-the-current-master)
    # in order to retrieve the current Redis master IP address.
    host: &quot;mymaster&quot;,
    sentinels: Resolv.getaddresses('redis-headless').map do |address|
      { host: address, port: 26379 }
    end
  }
end
</code></pre>
<p>That will create an Array of Hashes with the IP address as <code>host:</code> and 26379 as the <code>port:</code>.</p>
