K
Q

Referencing Helm Redis master from another pod within Kubernetes

8/13/2019

I am running Redis via Helm on Kubernetes and wondering how I reference the master pod from my application which is also running inside of Kubernetes as a pod. Helm is nice enough to create ClusterIP services, but I am still unclear in my application what I put to always reference the master:

MacBook-Pro ➜  api git:(master) ✗ kubectl get services
NAME                           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
ignoble-hyena-redis-master     ClusterIP   10.100.187.188   <none>        6379/TCP         5h21m
ignoble-hyena-redis-slave      ClusterIP   10.100.236.164   <none>        6379/TCP         5h21m

MacBook-Pro ➜  api git:(master) ✗ kubectl describe service ignoble-hyena-redis-master
Name:              ignoble-hyena-redis-master
Namespace:         default
Labels:            app=redis
                   chart=redis-9.0.1
                   heritage=Tiller
                   release=ignoble-hyena
Annotations:       <none>
Selector:          app=redis,release=ignoble-hyena,role=master
Type:              ClusterIP
IP:                10.100.187.188
Port:              redis  6379/TCP
TargetPort:        redis/TCP
Endpoints:         192.168.34.46:6379
Session Affinity:  None
Events:            <none>

Do I use: redis://my-password@ignoble-hyena-redis-master:6379. That seems fragile as the pod name changes every time I redeploy the Helm chart. What is the recommended way to handle internal service discovery within the Kubernetes cluster?

-- Justin
kubernetes
kubernetes-helm
redis

Similar Questions

Fix "The credentials supplied to the package were not recognized" when calling K8S API
Internal service requests in Istio
Failed to pull image - unauthorized: authentication required (ImagePullBackOff )
How to get list of pods that are not linked to any service
Helm create secret from env file

2 Answers

8/13/2019

I couldn’t find it well-documented but following the template code you should be able to set the fullnameOverride value to some string you control, and the redis master will be exposed as <yourFullname>-master, and you can have your clients reach it via that. If your clients are in a different namespace, they can reach the masters at <yourFullname>-master.<redisMasterServiceNamespace>.

-- Amit Kumar Gupta
Source: StackOverflow
8/18/2019

You should package your application as a Helm chart. This basically involves running helm create, then copying your existing deployment YAML into the templates directory. Charts can have dependencies and so you can declare that your application needs Redis. Using the version in the standard Helm charts repository you can say something like

# I am requirements.yaml
- name: redis
  version: ~9.0.2
  repository: https://kubernetes-charts.storage.googleapis.com

The important detail here is that your application and its Redis will have the same Helm release name -- if your application is ignoble-hyena-myapp then its Redis will be ignoble-hyena-redis-master. You can set this in your deployment YAML spec using templates

env:
  - name: REDIS_HOST
    value: {{ .Release.Name }}-redis-master

Because of the way Kubernetes works internally, even if you helm upgrade your chart to a newer image tag, it won't usually touch the Redis. Helm will upload a new version of the Redis artifacts that looks exactly the same as the old one, and Kubernetes will take no action.

-- David Maze
Source: StackOverflow