Deploy Redis on GKE

Deploy Redis using a custom Helm chart

In this section you’ll deploy Redis on Kubernetes using a custom Helm chart. After deployment, Redis will be running with internal access using a ClusterIP Service and basic connectivity validated using redis-cli.

Create a Helm chart

Create a Helm chart skeleton:

    

        
        
helm create my-redis

    

Resulting structure

    

        
        
my-redis/
├── Chart.yaml
├── values.yaml
└── templates/

    

Clean templates

The default Helm chart includes several files that aren’t required for a basic Redis deployment. Remove the following files from my-redis/templates/ to avoid unnecessary complexity and template errors: ingress.yaml, hpa.yaml, serviceaccount.yaml, tests/, NOTES.txt, and httproute.yaml.

    

        
        
cd ./my-redis/templates
rm -rf hpa.yaml ingress.yaml serviceaccount.yaml tests/ NOTES.txt httproute.yaml
cd $HOME/helm-microservices

    

Only Redis-specific templates will be maintained.

Configure values.yaml

Replace the entire contents of my-redis/values.yaml:

    

        
        
replicaCount: 1

image:
  repository: redis
  tag: "7"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 6379

    

This configuration centralizes settings, simplifies future updates, and prevents Helm template evaluation issues.

Deployment definition (deployment.yaml)

Replace the entire contents of my-redis/templates/deployment.yaml:

    

        
        
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-redis.fullname" . }}

spec:
  replicas: 1
  selector:
    matchLabels:
      app: {{ include "my-redis.name" . }}

  template:
    metadata:
      labels:
        app: {{ include "my-redis.name" . }}

    spec:
      containers:
        - name: redis
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: 6379

    

Redis runs as a single pod with no persistence configured, which is suitable for learning and caching use cases.

Service definition (service.yaml)

Replace the entire contents of my-redis/templates/service.yaml to create an internal service:

    

        
        
apiVersion: v1
kind: Service
metadata:
  name: {{ include "my-redis.fullname" . }}
spec:
  type: ClusterIP
  ports:
    - port: 6379
  selector:
    app: {{ include "my-redis.name" . }}

    

Install Redis using Helm

Install Redis and validate that it’s running:

    

        
        
cd $HOME/helm-microservices
helm install redis ./my-redis

    

Confirm that the redis pod is operating:

    

        
        
kubectl get pods
kubectl get svc

    

Get the Redis pod name from the output, then test connectivity:

    

        
        
kubectl exec -it <redis-pod-name> -- redis-cli ping

    

Replace <redis-pod-name> with the actual pod name (for example, redis-my-redis-75c88646fb-6lz8v).

You should see an output similar to:

    

        
        NAME                                        READY   STATUS    RESTARTS   AGE
postgres-app-my-postgres-6dbc8759b6-jgpxs   1/1     Running   0          6m38s
redis-my-redis-75c88646fb-6lz8v             1/1     Running   0          13s

NAME                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
kubernetes                 ClusterIP   34.118.224.1     <none>        443/TCP    37m
postgres-app-my-postgres   ClusterIP   34.118.233.240   <none>        5432/TCP   22m
redis-my-redis             ClusterIP   34.118.229.221   <none>        6379/TCP   3m19s

        
    

Finally, execute a sample ping via redis:

    

        
        
kubectl exec -it <redis-pod> -- redis-cli ping

    

You should see an output similar to:

    

        
        PONG

        
    

The Redis pod should be in Running state and the service should be ClusterIP type.

What you’ve accomplished and what’s next

You’ve successfully deployed Redis using a custom Helm chart with internal access via a Kubernetes Service. You’ve validated connectivity and created a clean, reusable Helm structure that’s accessible via the service name redis.

Next, you’ll deploy NGINX as a frontend service with public access to complete your microservices deployment.