[i18n] Update files under /docs/platforms/kubernetes to use absolute path (#7525)

Signed-off-by: Vitor Vasconcellos <vitor.vasconcellos@mercadolivre.com>

Author: vitorvasc

content/en/docs/platforms/kubernetes/collector/components.md

@@ -56,8 +56,9 @@ interesting metadata. By default, data passing through the processor is
 associated to a pod via the incoming request's IP address, but different rules
 can be configured. Since the processor uses the Kubernetes API, it requires
 special permissions (see example below). If you're using the
-[OpenTelemetry Collector Helm chart](../../helm/collector/) you can use the
-[`kubernetesAttributes` preset](../../helm/collector/#kubernetes-attributes-preset)
+[OpenTelemetry Collector Helm chart](/docs/platforms/kubernetes/helm/collector/)
+you can use the
+[`kubernetesAttributes` preset](/docs/platforms/kubernetes/helm/collector/#kubernetes-attributes-preset)
 to get started.
 
 The following attributes are added by default:
@@ -194,9 +195,10 @@ the node and the workloads running on the node.
 There are different methods for authentication, but typically a service account
 is used. The service account will also need proper permissions to pull data from
 the Kubelet (see below). If you're using the
-[OpenTelemetry Collector Helm chart](../../helm/collector/) you can use the
-[`kubeletMetrics` preset](../../helm/collector/#kubelet-metrics-preset) to get
-started.
+[OpenTelemetry Collector Helm chart](/docs/platforms/kubernetes/helm/collector/)
+you can use the
+[`kubeletMetrics` preset](/docs/platforms/kubernetes/helm/collector/#kubelet-metrics-preset)
+to get started.
 
 By default, metrics will be collected for pods and nodes, but you can configure
 the receiver to collect container and volume metrics as well. The receiver also
@@ -269,8 +271,10 @@ any logs from Kubernetes.
 The Filelog Receiver is composed of Operators that are chained together to
 process a log. Each Operator performs a simple responsibility, such as parsing a
 timestamp or JSON. Configuring a Filelog Receiver is not trivial. If you're
-using the [OpenTelemetry Collector Helm chart](../../helm/collector/) you can
-use the [`logsCollection` preset](../../helm/collector/#logs-collection-preset)
+using the
+[OpenTelemetry Collector Helm chart](/docs/platforms/kubernetes/helm/collector/)
+you can use the
+[`logsCollection` preset](/docs/platforms/kubernetes/helm/collector/#logs-collection-preset)
 to get started.
 
 Since Kubernetes logs normally fit a set of standard formats, a typical Filelog
@@ -354,9 +358,10 @@ the data.
 There are different methods for authentication, but typically a service account
 is used. The service account also needs proper permissions to pull data from the
 Kubernetes API server (see below). If you're using the
-[OpenTelemetry Collector Helm chart](../../helm/collector/) you can use the
-[`clusterMetrics` preset](../../helm/collector/#cluster-metrics-preset) to get
-started.
+[OpenTelemetry Collector Helm chart](/docs/platforms/kubernetes/helm/collector/)
+you can use the
+[`clusterMetrics` preset](/docs/platforms/kubernetes/helm/collector/#cluster-metrics-preset)
+to get started.
 
 For node conditions, the receiver only collects `Ready` by default, but it can
 be configured to collect more. The receiver can also be configured to report a
@@ -483,10 +488,10 @@ all the data.
 Currently only a service account can be used for authentication. The service
 account also needs proper permissions to pull data from the Kubernetes API
 server (see below). If you're using the
-[OpenTelemetry Collector Helm chart](../../helm/collector/) and you want to
-ingest events, you can use the
-[`kubernetesEvents` preset](../../helm/collector/#cluster-metrics-preset) to get
-started.
+[OpenTelemetry Collector Helm chart](/docs/platforms/kubernetes/helm/collector/)
+and you want to ingest events, you can use the
+[`kubernetesEvents` preset](/docs/platforms/kubernetes/helm/collector/#cluster-metrics-preset)
+to get started.
 
 For objects configuring for pulling, the receiver will use the Kubernetes API to
 periodically list all the objects in the Cluster. Each object will be converted
@@ -643,8 +648,9 @@ which means there are important details to consider when using it:
 
 To make configuring the Prometheus receiver easier, the OpenTelemetry Operator
 includes an optional component called the
-[Target Allocator](../../operator/target-allocator). This component can be used
-to tell a collector which Prometheus endpoints it should scrape.
+[Target Allocator](/docs/platforms/kubernetes/operator/target-allocator). This
+component can be used to tell a collector which Prometheus endpoints it should
+scrape.
 
 For more information on the design of the receiver, see
 [Design](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/prometheusreceiver/DESIGN.md).
@@ -664,9 +670,10 @@ may be worth it to disable these duplicate metrics.
 
 In Kubernetes, the receiver needs access to the `hostfs` volume to work
 properly. If you're using the
-[OpenTelemetry Collector Helm chart](../../helm/collector/) you can use the
-[`hostMetrics` preset](../../helm/collector/#host-metrics-preset) to get
-started.
+[OpenTelemetry Collector Helm chart](/docs/platforms/kubernetes/helm/collector/)
+you can use the
+[`hostMetrics` preset](/docs/platforms/kubernetes/helm/collector/#host-metrics-preset)
+to get started.
 
 The available scrapers are:
 

content/en/docs/platforms/kubernetes/getting-started.md

@@ -20,7 +20,7 @@ see how all the monitoring responds to an active workload.
 If you're looking to start migrating from Prometheus to OpenTelemetry, or if
 you're interested in using the OpenTelemetry Collector to collect Prometheus
 metrics, see
-[Prometheus Receiver](../collector/components/#prometheus-receiver).
+[Prometheus Receiver](/docs/platforms/kubernetes/collector/components/#prometheus-receiver).
 
 ## Overview
 
@@ -41,12 +41,13 @@ metrics for nodes, pods, and containers. The deployment installation of the
 collector will be used to collect metrics for the cluster and events.
 
 To install the collector, we'll use the
-[OpenTelemetry Collector Helm chart](../helm/collector/), which comes with a few
-configuration options that will make configure the collector easier. If you're
-unfamiliar with Helm, check out [the Helm project site](https://helm.sh/). If
-you're interested in using a Kubernetes operator, see
-[OpenTelemetry Operator](../operator/), but this guide will focus on the Helm
-chart.
+[OpenTelemetry Collector Helm chart](/docs/platforms/kubernetes/helm/collector/),
+which comes with a few configuration options that will make configure the
+collector easier. If you're unfamiliar with Helm, check out
+[the Helm project site](https://helm.sh/). If you're interested in using a
+Kubernetes operator, see
+[OpenTelemetry Operator](/docs/platforms/kubernetes/operator/), but this guide
+will focus on the Helm chart.
 
 ## Preparation
 
@@ -81,12 +82,12 @@ This instance of the collector will use the following components:
 
 - [OTLP Receiver](https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver):
   to collect application traces, metrics and logs.
-- [Kubernetes Attributes Processor](../collector/components/#kubernetes-attributes-processor):
+- [Kubernetes Attributes Processor](/docs/platforms/kubernetes/collector/components/#kubernetes-attributes-processor):
   to add Kubernetes metadata to incoming application telemetry.
-- [Kubeletstats Receiver](../collector/components/#kubeletstats-receiver): to
-  pull node, pod, and container metrics from the API server on a kubelet.
-- [Filelog Receiver](../collector/components/#filelog-receiver): to collect
-  Kubernetes logs and application logs written to stdout/stderr.
+- [Kubeletstats Receiver](/docs/platforms/kubernetes/collector/components/#kubeletstats-receiver):
+  to pull node, pod, and container metrics from the API server on a kubelet.
+- [Filelog Receiver](/docs/platforms/kubernetes/collector/components/#filelog-receiver):
+  to collect Kubernetes logs and application logs written to stdout/stderr.
 
 Let's break these down.
 
@@ -108,7 +109,7 @@ Kubernetes metadata using the `k8sattributes` processor.
 ### Kubernetes Attributes Processor
 
 The
-[Kubernetes Attributes Processor](../collector/components/#kubernetes-attributes-processor)
+[Kubernetes Attributes Processor](/docs/platforms/kubernetes/collector/components/#kubernetes-attributes-processor)
 is a highly recommended component in any collector receive telemetry from
 Kubernetes pods. This processor automatically discovers Kubernetes pods,
 extracts their metadata such as pod name or node name, and adds the extracted
@@ -119,8 +120,9 @@ Kubernetes telemetry, such as pod metrics and traces.
 
 ### Kubeletstats Receiver
 
-The [Kubeletstats Receiver](../collector/components/#kubeletstats-receiver) is
-the receiver that gathers metrics about the node. It will gather metrics like
+The
+[Kubeletstats Receiver](/docs/platforms/kubernetes/collector/components/#kubeletstats-receiver)
+is the receiver that gathers metrics about the node. It will gather metrics like
 container memory usage, pod cpu usage, and node network errors. All of the
 telemetry includes Kubernetes metadata like pod name or node name. Since we're
 using the Kubernetes Attributes Processor, we'll be able to correlate our
@@ -129,10 +131,12 @@ Kubeletstats Receiver.
 
 ### Filelog Receiver
 
-The [Filelog Receiver](../collector/components/#filelog-receiver) will collect
-logs written to stdout/stderr by tailing the logs Kubernetes writes to
-`/var/log/pods/*/*/*.log`. Like most log tailers, the filelog receiver provides
-a robust set of actions that allow you to parse the file however you need.
+The
+[Filelog Receiver](/docs/platforms/kubernetes/collector/components/#filelog-receiver)
+will collect logs written to stdout/stderr by tailing the logs Kubernetes writes
+to `/var/log/pods/*/*/*.log`. Like most log tailers, the filelog receiver
+provides a robust set of actions that allow you to parse the file however you
+need.
 
 Someday you may need to configure a Filelog Receiver on your own, but for this
 walkthrough the OpenTelemetry Helm Chart will handle all the complex
@@ -205,25 +209,25 @@ data.
 
 This instance of the Collector will use the following components:
 
-- [Kubernetes Cluster Receiver](../collector/components/#kubernetes-cluster-receiver):
+- [Kubernetes Cluster Receiver](/docs/platforms/kubernetes/collector/components/#kubernetes-cluster-receiver):
   to collect cluster-level metrics and entity events.
-- [Kubernetes Objects Receiver](../collector/components/#kubernetes-objects-receiver):
+- [Kubernetes Objects Receiver](/docs/platforms/kubernetes/collector/components/#kubernetes-objects-receiver):
   to collect objects, such as events, from the Kubernetes API server.
 
 Let's break these down.
 
 ### Kubernetes Cluster Receiver
 
 The
-[Kubernetes Cluster Receiver](../collector/components/#kubernetes-cluster-receiver)
+[Kubernetes Cluster Receiver](/docs/platforms/kubernetes/collector/components/#kubernetes-cluster-receiver)
 is the Collector's solution for collecting metrics about the state of the
 cluster as a whole. This receiver can gather metrics about node conditions, pod
 phases, container restarts, available and desired deployments, and more.
 
 ### Kubernetes Objects Receiver
 
 The
-[Kubernetes Objects Receiver](../collector/components/#kubernetes-objects-receiver)
+[Kubernetes Objects Receiver](/docs/platforms/kubernetes/collector/components/#kubernetes-objects-receiver)
 is the Collector's solution for collecting Kubernetes objects as logs. Although
 any object can be collected, a common and important use case is to collect
 Kubernetes events.

content/en/docs/platforms/kubernetes/operator/_index.md

@@ -80,7 +80,8 @@ EOF
 
 By default, `opentelemetry-operator` uses the
 [`opentelemetry-collector` image](https://github.com/open-telemetry/opentelemetry-collector-releases/pkgs/container/opentelemetry-collector-releases%2Fopentelemetry-collector).
-When the operator is installed using [Helm charts](../helm/), the
+When the operator is installed using
+[Helm charts](/docs/platforms/kubernetes/helm/), the
 [`opentelemetry-collector-k8s` image](https://github.com/open-telemetry/opentelemetry-collector-releases/pkgs/container/opentelemetry-collector-releases%2Fopentelemetry-collector-k8s)
 is used. If you need a component not found in these releases, you may need to
 [build your own collector](/docs/collector/custom-collector/).

content/en/docs/platforms/kubernetes/operator/automatic.md

@@ -35,10 +35,10 @@ chart, there is an option to generate a self-signed cert instead.
 ## Create an OpenTelemetry Collector (Optional)
 
 It is a best practice to send telemetry from containers to an
-[OpenTelemetry Collector](../../collector/) instead of directly to a backend.
-The Collector helps simplify secret management, decouples data export problems
-(such as a need to do retries) from your apps, and lets you add additional data
-to your telemetry, such as with the
+[OpenTelemetry Collector](/docs/platforms/kubernetes/collector/) instead of
+directly to a backend. The Collector helps simplify secret management, decouples
+data export problems (such as a need to do retries) from your apps, and lets you
+add additional data to your telemetry, such as with the
 [k8sattributesprocessor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/k8sattributesprocessor)
 component. If you chose not to use a Collector, you can skip to the next
 section.