Fixed image paths

Author: amuraru

content/_index.md

@@ -7,15 +7,15 @@ title: Koperator
 	<a class="btn btn-lg btn-primary mr-3 mb-4" href="{{< relref "/docs/" >}}" title="Read the documentation">
 		Documentation <i class="fa-solid fa-circle-right ml-2"></i>
 	</a>
-	<a class="btn btn-lg btn-secondary mr-3 mb-4" href="/docs/install-kafka-operator/" title="Install Koperator">
+	<a class="btn btn-lg btn-secondary mr-3 mb-4" href="{{< relref "/docs/install-kafka-operator/" >}}" title="Install Koperator">
 		Install <i class="fa-brands fa-github ml-2 "></i>
 	</a>
 	<p class="lead mt-5">The Koperator (formerly called Banzai Cloud Kafka Operator) is a Kubernetes operator to automate provisioning, management, autoscaling and operations of Apache Kafka clusters deployed to Kubernetes.</p>
 </div>
 {{< /blocks/cover >}}
 
 {{< blocks/section color="dark" type="row">}}
-{{% blocks/feature icon="fa-lightbulb" title="Learn more about Koperator!" url="/docs/" %}}
+{{% blocks/feature icon="fa-lightbulb" title="Learn more about Koperator!" url="{{< relref \"/docs/\" >}}" %}}
 Read the Koperator documentation.
 {{% /blocks/feature %}}
 

content/docs/_index.md

@@ -20,7 +20,7 @@ The Koperator (formerly called Banzai Cloud Kafka Operator) is a Kubernetes oper
 - graceful rolling upgrade
 - advanced topic and user management via CRD
 
-![Koperator architecture](/img/kafka-operator-arch.png)
+![Koperator architecture](../img/kafka-operator-arch.png)
 
 {{% include-headless "kafka-operator-intro.md" %}}
 
@@ -80,14 +80,14 @@ We know how to operate Apache Kafka at scale (we are contributors and have been
 
 The Koperator externalizes access to Apache Kafka using a dynamically (re)configured Envoy proxy. Using Envoy allows us to use **a single** LoadBalancer, so there's no need for a LoadBalancer for each Broker.
 
-![Kafka External Access](/img/kafka-external.png)
+![Kafka External Access](../img/kafka-external.png)
 
 ### Communication via SSL
 
 The operator fully automates Kafka's SSL support.
 The operator can provision the required secrets and certificates for you, or you can provide your own.
 
-![SSL support for Kafka](/img/kafka-ssl.png)
+![SSL support for Kafka](../img/kafka-ssl.png)
 
 ### Monitoring via Prometheus
 

content/docs/monitoring.md

@@ -6,7 +6,7 @@ weight: 600
 
 
 
-This documentation shows you how to enable custom monitoring on an Apache Kafka cluster installed using the [Koperator](/products/kafka-operator/).
+This documentation shows you how to enable custom monitoring on an Apache Kafka cluster installed using the [Koperator]({{< relref "/docs/" >}}).
 
 ## Using Helm for Prometheus
 

content/docs/rackawareness/index.md

@@ -46,7 +46,7 @@ Note that depending on your use case, you might need additional configuration on
 As mentioned earlier, `broker.rack` is a read-only broker config, so is set whenever the broker starts or restarts. The [Koperator](https://github.com/adobe/koperator) holds all its configs within a ConfigMap in each broker.
 Getting label values from nodes and using them to generate a ConfigMap is relatively easy, but to determine where the exact broker/pod is scheduled, the operator has to wait until the pod is *actually* scheduled to a node. Luckily, Kubernetes schedules pods even when a given ConfigMap is unavailable. However, the corresponding pod will remain in a pending state as long as the ConfigMap is not available to mount. The operator makes use of this pending state to gather all the necessary node labels and initialize a ConfigMap with the fetched data. To take advantage of this, we introduced a status field called `RackAwarenessState` in our CRD. The operator populates this status field with two values, `WaitingForRackAwareness` and `Configured`.
 
-![Rack Awareness](/img/blog/kafka-rack-awareness/kafkarack.gif)
+![Rack Awareness](kafkarack.gif)
 
 ## When a broker fails