# Deploy Redis on GKE

## In this learning path

- [Introduction](https://learn.arm.com/learning-paths/servers-and-cloud-computing/helm-on-gcp/)
- [Get started with Helm on Google Axion C4A (Arm-based)](https://learn.arm.com/learning-paths/servers-and-cloud-computing/helm-on-gcp/background/)
- [Create a Google Axion C4A virtual machine on Google Cloud](https://learn.arm.com/learning-paths/servers-and-cloud-computing/helm-on-gcp/instance/)
- [Install Helm](https://learn.arm.com/learning-paths/servers-and-cloud-computing/helm-on-gcp/installation/)
- [Validate Helm workflows on a Google Axion C4A virtual machine](https://learn.arm.com/learning-paths/servers-and-cloud-computing/helm-on-gcp/baseline/)
- [Prepare a GKE cluster for Helm deployments](https://learn.arm.com/learning-paths/servers-and-cloud-computing/helm-on-gcp/gke-cluster-for-helm/)
- [PostgreSQL Deployment Using Custom Helm Chart](https://learn.arm.com/learning-paths/servers-and-cloud-computing/helm-on-gcp/postgresql-helm/)
- [Deploy Redis on GKE](https://learn.arm.com/learning-paths/servers-and-cloud-computing/helm-on-gcp/redis-helm/)
- [Deploy NGINX with public access](https://learn.arm.com/learning-paths/servers-and-cloud-computing/helm-on-gcp/nginx-helm/)
- [Benchmark Helm concurrency on a Google Axion C4A virtual machine](https://learn.arm.com/learning-paths/servers-and-cloud-computing/helm-on-gcp/benchmarking/)
- [Next Steps](https://learn.arm.com/learning-paths/servers-and-cloud-computing/helm-on-gcp/_next-steps/)

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`:

```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`:

```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:

```yaml
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.