docs: clarify helm vs CRD usage

docs/content/en/docs/Advance Configuration/Exposing Redis/_index.md

@@ -14,8 +14,14 @@ The service can be exposed with these service types:
 - **NodePort:** Exposes the Service on each Node's IP at a static port (the NodePort). A ClusterIP Service, to which the NodePort Service routes, is automatically created. You'll be able to contact the NodePort Service, from outside the cluster, by requesting <NodeIP>:<NodePort>.
 - **LoadBalancer:** Exposes the Service externally using a cloud provider's load balancer. NodePort and ClusterIP Services, to which the external load balancer routes, are automatically created.
 
+{{< alert color="info" title="Context" >}}
+Examples below are labeled as Helm values or CRD manifests. Use the CRD form if you install the operator once and apply Redis custom resources directly.
+{{< /alert >}}
+
 ## Exposing Service
 
+### Helm values (charts)
+
 Customize or create the values file with the following content. The externalService configuration is a common method of exposing service for redis standalone and cluster setup:
 
 ```yaml
@@ -39,7 +45,31 @@ $ helm upgrade redis-cluster ot-helm/redis-cluster -f custom-values.yaml \
   --set redisCluster.clusterSize=3 --install --namespace ot-operators
 ```
 
-Once helm command is completed successfully, we can verify the external service by kubectl command. As we can see in the output, there is an IP in the "EXTERNAL-IP" coloumn.
+### CRD manifest (operator)
+
+If you apply CRDs directly (no chart), configure the additional service on the custom resource. This creates a `-additional` Service for external access.
+
+```yaml
+apiVersion: redis.redis.opstreelabs.in/v1beta2
+kind: RedisCluster
+metadata:
+  name: redis-cluster
+spec:
+  clusterSize: 3
+  kubernetesConfig:
+    image: quay.io/opstree/redis:v7.0.5
+    imagePullPolicy: IfNotPresent
+    service:
+      serviceType: LoadBalancer
+      annotations:
+        service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
+      additional:
+        enabled: true
+```
+
+For standalone Redis, use `kind: Redis` with the same `spec.kubernetesConfig.service` block.
+
+Once applied, we can verify the external service by kubectl command. As we can see in the output, there is an IP in the "EXTERNAL-IP" column.
 
 ```shell
 $ kubectl get svc -n ot-operators

docs/content/en/docs/Advance Configuration/Upgrading/_index.md

@@ -9,6 +9,10 @@ description: >
 
 The upgrade strategy for standalone Redis includes the downtime of the system but for cluster setup mode any application will not face any type of issues or downtime. The operator uses the rolling deployment strategy for cluster setup where it will upgrade the redis leader pods and once the leader is upgraded it will follow the same strategy for redis follower pods.
 
+{{< alert color="info" title="Context" >}}
+This page includes both Helm-based upgrades and direct CRD updates. Each example is labeled.
+{{< /alert >}}
+
 ## Upgrade of standalone setup
 
 For upgrading the standalone setup of Redis, first we need to identify the current version of it and that can be done via combination of `kubectl` and `redis-server` command.
@@ -19,6 +23,8 @@ $ kubectl exec -it redis-0 -n ot-operators -c redis -- redis-server --version
 Redis server v=6.2.5 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=3e393a4e624651a3
 ```
 
+### Helm values (charts)
+
 Now let's say the new version, we want to migrate is `7.0.5`. In that case, we can simply use `helm upgrade` command to upgrade the redis cluster.
 
 ```shell
@@ -51,15 +57,23 @@ $ kubectl exec -it redis-0 -n ot-operators -c redis -- redis-server --version
 Redis server v=7.0.5 sha=00000000:0 malloc=jemalloc-5.2.1 bits=64 build=90d2ef529791ba03
 ```
 
-For YAML manifest based upgrade, please update the `spec` section of Redis Object. For further details check [here](../../crd-reference/redis-api/#kubernetesconfig).
+### CRD manifest (operator)
+
+If you apply CRDs directly (no chart), update the Redis custom resource:
 
 ```yaml
+apiVersion: redis.redis.opstreelabs.in/v1beta2
+kind: Redis
+metadata:
+  name: redis
 spec:
   kubernetesConfig:
     image: "quay.io/opstree/redis:v7.0.15"
     imagePullPolicy: "IfNotPresent"
 ```
 
+For further details check [here](../../crd-reference/redis-api/#kubernetesconfig).
+
 **Things to keep in mind:**
 
 {{< alert color="info" title="Note" >}}
@@ -104,6 +118,8 @@ a00493797d566f2cb1f861962e94fee453d23857 192.168.2.131:6379@16379 slave 2321a671
 af958687b0048c734b13cef5632ab2b46e386fb1 192.168.72.57:6379@16379 master - 0 1667400527000 3 connected 10923-16383
 ```
 
+### Helm values (charts)
+
 Once the version and cluster health is verified, we can trigger the upgrade of the cluster by using `helm` command. Let's upgrade the cluster version to v7.
 
 ```shell
@@ -153,15 +169,25 @@ a00493797d566f2cb1f861962e94fee453d23857 192.168.8.246:6379@16379 slave 2321a671
 93eb534f0e748b04ff4be6fe984173cdc65703eb 192.168.52.229:6379@16379 slave 670c7c36d3d89c93d4bc546e6ee02b2b843d8801 0 1667400984687 2 connected
 ```
 
-For YAML manifest based upgrade, please update the `spec` section of Redis Object. For further details check [here](../../crd-reference/redis-api/#kubernetesconfig).
+### CRD manifest (operator)
+
+If you apply CRDs directly (no chart), update the RedisCluster custom resource:
 
 ```yaml
+apiVersion: redis.redis.opstreelabs.in/v1beta2
+kind: RedisCluster
+metadata:
+  name: redis-cluster
 spec:
+  clusterSize: 3
+  clusterVersion: v7
   kubernetesConfig:
     image: "quay.io/opstree/redis:v7.0.15"
     imagePullPolicy: "IfNotPresent"
 ```
 
+For further details check [here](../../crd-reference/redis-api/#kubernetesconfig).
+
 
 **Things to keep in mind:**
 
@@ -214,4 +240,3 @@ Using the "orphan" strategy will keep the Pods running, but they won't be manage
 {{< /alert >}}
 
 This feature is useful when upgrading Redis with changes to immutable StatefulSet fields, allowing administrators to control the recreation process according to their operational requirements.
-

docs/content/en/docs/Monitoring/_index.md

@@ -15,6 +15,13 @@ The monitoring architecture is illustrated in the diagram:
 
 ![redis_operator_architecture](../../../images/redis-operator-architecture.png)
 
+{{< alert color="info" title="Context" >}}
+This page includes both Helm values (for the ot-helm charts) and CRD manifests (for direct operator usage).
+Each example is labeled.
+{{< /alert >}}
+
+### Helm values (charts)
+
 For the helm chart installation of redis setup, we can simply enable the redis exporter by creating a custom values file for helm chart. The content of the values file will look like this:
 
 ```yaml
@@ -40,10 +47,34 @@ $ helm upgrade redis-cluster ot-helm/redis-cluster -f monitoring-values.yaml \
   --set redisCluster.clusterSize=3 --install --namespace ot-operators
 ```
 
-## ServiceMonitor
+### CRD manifest (operator)
+
+If you apply CRDs directly (no chart), enable the exporter in your Redis or RedisCluster custom resource:
+
+```yaml
+apiVersion: redis.redis.opstreelabs.in/v1beta2
+kind: RedisCluster
+metadata:
+  name: redis-cluster
+spec:
+  clusterSize: 3
+  kubernetesConfig:
+    image: quay.io/opstree/redis:v7.0.5
+    imagePullPolicy: Always
+  redisExporter:
+    enabled: true
+    image: quay.io/opstree/redis-exporter:1.0
+    imagePullPolicy: Always
+```
+
+For standalone Redis, use `kind: Redis` with the same `spec.redisExporter` block.
+
+## ServiceMonitor (Prometheus Operator)
 
 Once the exporter is configured, we may have to update Prometheus to monitor this endpoint. For [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator), we have to create a CRD based object called ServiceMonitor. We can apply the CRD definition as well using the helm command.
 
+### Helm values (charts)
+
 ```yaml
 serviceMonitor:
   enabled: false
@@ -54,6 +85,8 @@ serviceMonitor:
 
 For kubectl related configuration, we may have to create `ServiceMonitor` definition in a YAML manifest and apply it using `kubectl` command.
 
+### ServiceMonitor CRD
+
 ServiceMonitor for Redis cluster setup:
 
 ```yaml