fix-k8s-entity-styling

Author: sheilattran8

gdi/opentelemetry/automatic-discovery/k8s/k8s-backend.rst

@@ -143,8 +143,8 @@ To properly ingest trace telemetry data, the attribute ``deployment.environment`
   * - Through the values.yaml file and ``instrumentation.env`` or ``instrumentation.{instrumentation_library}.env`` configuration
     - Allows you to set ``deployment.environment`` either for all auto-instrumented applications collectively or per auto-instrumentation language.
     - Add the ``OTEL_RESOURCE_ATTRIBUTES`` environment variable, setting its value to ``deployment.environment=prd``.
-  * - Through your Kubernetes application deployment, daemonset, or pod specification
-    - Allows you to set ``deployment.environment`` at the level of individual deployments, daemonsets, or pods.
+  * - Through your Kubernetes application deployment, DaemonSet, or pod specification
+    - Allows you to set ``deployment.environment`` at the level of individual deployments, DaemonSets, or pods.
     - Employ the ``OTEL_RESOURCE_ATTRIBUTES`` environment variable, assigning the value ``deployment.environment=prd``.
 
 The following examples show how to set the attribute using each method:
@@ -283,7 +283,7 @@ The instrumentation in the collector namespace must include the following:
 Set annotations to instrument applications
 ==============================================================
 
-If the related Kubernetes object (deployment, daemonset, or pod) is not deployed, add the ``instrumentation.opentelemetry.io/inject-java`` annotation to the application object YAML.
+If the related Kubernetes object (deployment, DaemonSet, or pod) is not deployed, add the ``instrumentation.opentelemetry.io/inject-java`` annotation to the application object YAML.
 
 The annotation you set depends on the language runtime you're using. You can set multiple annotations in the same Kubernetes object. See the following available annotations:
 

gdi/opentelemetry/collector-kubernetes/kubernetes-config-add.rst

@@ -67,7 +67,7 @@ This example shows how to add the :ref:`mysql-receiver` to your configuration fi
 Add the MySQL receiver in the ``agent`` section
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To use the Collector agent daemonset to collect ``mysql`` metrics from every node the agent is deployed to, add this to your configuration:
+To use the Collector agent DaemonSet to collect ``mysql`` metrics from every node the agent is deployed to, add this to your configuration:
 
 .. code:: yaml
 
@@ -100,7 +100,7 @@ This example shows how to add the :ref:`rabbitmq` integration to your configurat
 Add RabbitMQ in the ``agent`` section
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If you want to activate the RabbitMQ monitor in the Collector agent daemonset, add ``mysql`` to the ``receivers`` section of your agent section in the configuration file:
+If you want to activate the RabbitMQ monitor in the Collector agent DaemonSet, add ``mysql`` to the ``receivers`` section of your agent section in the configuration file:
 
 .. code:: yaml
 

gdi/opentelemetry/collector-kubernetes/kubernetes-config-advanced.rst

@@ -432,7 +432,7 @@ By default, data is persisted in the ``/var/addon/splunk/exporter_queue`` direct
 
 Check the :new-page:`Data Persistence in the OpenTelemetry Collector <https://community.splunk.com/t5/Community-Blog/Data-Persistence-in-the-OpenTelemetry-Collector/ba-p/624583>` for a detailed explantion.
 
-.. note:: Data can only be persisted for agent daemonsets.
+.. note:: Data can only be persisted for agent DaemonSets.
 
 Config examples
 -----------------------------------------------------------------------------

gdi/opentelemetry/collector-kubernetes/kubernetes-config.rst

@@ -86,7 +86,7 @@ Search for "Autopilot overview" on the :new-page:`Google Cloud documentation sit
 
 .. note:: GKE Autopilot doesn't support native OpenTelemetry logs collection.
 
-The Collector agent daemonset can have problems scheduling in Autopilot mode. If this happens, do the following to assign the daemonset a higher priority class to ensure that the daemonset pods are always present on each node:
+The Collector agent DaemonSet can have problems scheduling in Autopilot mode. If this happens, do the following to assign the DaemonSet a higher priority class to ensure that the DaemonSet pods are always present on each node:
 
 1. Create a new priority class for the Collector agent:
 
@@ -134,7 +134,7 @@ To run the Collector in the Amazon EKS with Fargate profiles, set the required `
 
 This distribution operates similarly to the ``eks`` distribution, but with the following distinctions:
 
-* The Collector agent daemonset is not applied since Fargate does not support daemonsets. Any desired Collector instances running as agents must be configured manually as sidecar containers in your custom deployments. This includes any application logging services like Fluentd. Set ``gateway.enabled`` to ``true`` and configure your instrumented applications to report metrics, traces, and logs to the gateway ``<installed-chart-name>-splunk-otel-collector`` service address. Any desired agent instances that would run as a daemonset should instead run as sidecar containers in your pods.
+* The Collector agent DaemonSet is not applied since Fargate does not support DaemonSets. Any desired Collector instances running as agents must be configured manually as sidecar containers in your custom deployments. This includes any application logging services like Fluentd. Set ``gateway.enabled`` to ``true`` and configure your instrumented applications to report metrics, traces, and logs to the gateway ``<installed-chart-name>-splunk-otel-collector`` service address. Any desired agent instances that would run as a DaemonSet should instead run as sidecar containers in your pods.
 * Since Fargate nodes use a VM boundary to prevent access to host-based resources used by other pods, pods are not able to reach their own kubelet. The cluster receiver for the Fargate distribution has two primary differences between regular ``eks`` to work around this limitation:
    * The configured cluster receiver is deployed as a two-replica StatefulSet instead of a Deployment, and uses a Kubernetes Observer extension that discovers the cluster's nodes and, on the second replica, its pods for user-configurable receiver creator additions.Using this observer dynamically creates the Kubelet Stats receiver instances that report kubelet metrics for all observed Fargate nodes. The first replica monitors the cluster with a ``k8s_cluster`` receiver, and the second cluster monitors all kubelets except its own (due to an EKS/Fargate networking restriction).
    * The first replica's Collector monitors the second's kubelet. This is made possible by a Fargate-specific ``splunk-otel-eks-fargate-kubeletstats-receiver-node`` node label. The Collector ClusterRole for ``eks/fargate`` allows the ``patch`` verb on ``nodes`` resources for the default API groups to allow the cluster receiver's init container to add this node label for designated self monitoring.

gdi/opentelemetry/collector-kubernetes/kubernetes-upgrade.rst

@@ -80,13 +80,13 @@ To update the access token for your Collector for Kubernetes instance follow the
 
     helm get values <Release_Name> 
 
-5. Restart the Collector's daemonset and deployments: 
+5. Restart the Collector's DaemonSet and deployments: 
 
-  * If ``agent.enabled=true``, restart the Collector's agent daemonset:
+  * If ``agent.enabled=true``, restart the Collector's agent DaemonSet:
 
   .. code-block:: bash
 
-    kubectl rollout restart daemonset <Release_Name>-agent
+    kubectl rollout restart DaemonSet <Release_Name>-agent
     
   * If ``clusterReceiver.enabled=true``, restart the Collector's cluster receiver deployment:
 

gdi/opentelemetry/collector-kubernetes/metrics-ootb-k8s.rst

@@ -183,7 +183,7 @@ Pod level metrics and dimensions
     - Exported?
 
   * - ``k8s.cronjob.active_jobs``
-    - Active cronjob jobs    
+    - Active CronJob jobs    
     -   
     - Yes  
 
@@ -208,7 +208,7 @@ Pod level metrics and dimensions
     - Yes  
 
   * - ``k8s.job.successful_pods``
-    - Succesful pod jobs   
+    - Successful pod jobs   
     -   
     - Yes 
 

gdi/opentelemetry/components/kubelet-stats-receiver.rst

@@ -115,7 +115,7 @@ The following example shows how to configure the ``kubeletstats`` receiver with
          receivers: [kubeletstats]
          exporters: [file]
 
-.. caution:: A missing or empty ``endpoint`` value causes the host name on which the Collector is running to be used as the endpoint. If the ``hostNetwork`` flag is set, and the Collector is running in a Pod, the host name resolves to the node's network namespace.
+.. caution:: A missing or empty ``endpoint`` value causes the host name on which the Collector is running to be used as the endpoint. If the ``hostNetwork`` flag is set, and the Collector is running in a pod, the host name resolves to the node's network namespace.
 
 Advanced use cases
 ==================================================================
@@ -142,7 +142,7 @@ By default, all produced metrics get resource attributes based on what kubelet t
 The kubelet stats receiver supports the following metadata:
 
 -  ``container.id``: Enriches metric metadata with the Container ID label obtained from container statuses exposed using ``/pods``.
--  ``k8s.volume.type``: Collects the volume type from the Pod spec exposed using ``/pods`` and add it as an attribute to volume metrics. If more metadata than the volume type is available, the receiver syncs it depending on the available fields and the type of volume. For example, ``aws.volume.id`` is synced from ``awsElasticBlockStore`` and ``gcp.pd.name`` is synced from ``gcePersistentDisk``.
+-  ``k8s.volume.type``: Collects the volume type from the pod spec exposed using ``/pods`` and add it as an attribute to volume metrics. If more metadata than the volume type is available, the receiver syncs it depending on the available fields and the type of volume. For example, ``aws.volume.id`` is synced from ``awsElasticBlockStore`` and ``gcp.pd.name`` is synced from ``gcePersistentDisk``.
 
 To add the ``container.id`` label to your metrics, set the ``extra_metadata_labels`` field. For example:
 
@@ -177,7 +177,7 @@ When dealing with persistent volume claims, you can sync metadata from the under
        k8s_api_config:
          auth_type: serviceAccount
 
-If ``k8s_api_config`` is set, the receiver attempts to collect metadata from underlying storage resources for persistent volume claims. For example, if a Pod is using a persistent volume claim backed by an Elastic Block Store (EBS) instance on AWS, the receiver sets the ``k8s.volume.type`` label to ``awsElasticBlockStore`` rather than ``persistentVolumeClaim``.
+If ``k8s_api_config`` is set, the receiver attempts to collect metadata from underlying storage resources for persistent volume claims. For example, if a pod is using a persistent volume claim backed by an Elastic Block Store (EBS) instance on AWS, the receiver sets the ``k8s.volume.type`` label to ``awsElasticBlockStore`` rather than ``persistentVolumeClaim``.
 
 Configure metric groups
 --------------------------------------------------------------

gdi/opentelemetry/components/kubernetes-attributes-processor.rst

@@ -135,7 +135,7 @@ The following example shows how to give a ServiceAccount the necessary permissio
 Discovery filters
 -------------------------------------
 
-You can use the Kubernetes attributes processor in Collectors deployed either as agents or as gateways, using DaemonSets or Deployments respectively. See :ref:`otel-deployment-mode` for more information.
+You can use the Kubernetes attributes processor in Collectors deployed either as agents or as gateways, using DaemonSets or deployments respectively. See :ref:`otel-deployment-mode` for more information.
 
 Agent configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^