added helm chart

helm/opentelemetry-operator/.helmignore

@@ -0,0 +1,25 @@
+# Patterns to ignore when building packages.
+# This supports shell glob matching, relative path matching, and
+# negation (prefixed with !). Only one pattern per line.
+.DS_Store
+# Common VCS dirs
+.git/
+.gitignore
+.bzr/
+.bzrignore
+.hg/
+.hgignore
+.svn/
+# Common backup files
+*.swp
+*.bak
+*.tmp
+*.orig
+*~
+# Various IDEs
+.project
+.idea/
+*.tmproj
+.vscode/
+# Release related files
+release/

helm/opentelemetry-operator/CONTRIBUTING.md

@@ -0,0 +1,11 @@
+# Operator Chart Contributing Guide
+
+## Bumping Default Operator Version
+
+1. Increase the minor version of the chart by one and set the patch version to zero.
+2. Update the chart's `appVersion` to match the new operator version.
+3. In the values.yaml, update `manager.image.tag` to match the new operator release.
+4. In the values.yaml, update `manager.collectorImage.tag` to match the version of the collector managed by default by the operator.
+5. Run `make generate-examples CHARTS=opentelemetry-operator`.
+6. Run `make update-operator-crds` to update the CRDs in this chart to match the operator's.
+7. Review the [Operator release notes](https://github.com/open-telemetry/opentelemetry-operator/releases).  If any changes affect the helm chart, adjust the helm chart accordingly.

helm/opentelemetry-operator/Chart.yaml

@@ -0,0 +1,14 @@
+apiVersion: v2
+appVersion: 0.89.0
+description: OpenTelemetry Operator Helm chart for Kubernetes
+home: https://opentelemetry.io/
+icon: https://raw.githubusercontent.com/cncf/artwork/a718fa97fffec1b9fd14147682e9e3ac0c8817cb/projects/opentelemetry/icon/color/opentelemetry-icon-color.png
+maintainers:
+- name: Allex1
+- name: dmitryax
+- name: TylerHelmuth
+name: opentelemetry-operator
+sources:
+- https://github.com/open-telemetry/opentelemetry-operator
+type: application
+version: 0.43.1

helm/opentelemetry-operator/README.md

@@ -0,0 +1,273 @@
+# OpenTelemetry Operator Helm Chart
+
+The Helm chart installs [OpenTelemetry Operator](https://github.com/open-telemetry/opentelemetry-operator) in Kubernetes cluster.
+The OpenTelemetry Operator is an implementation of a [Kubernetes Operator](https://www.openshift.com/learn/topics/operators).
+At this point, it has [OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector) as the only managed component.
+
+## Prerequisites
+
+- Kubernetes 1.24+ is required for OpenTelemetry Operator installation
+- Helm 3.9+
+
+### TLS Certificate Requirement
+
+In Kubernetes, in order for the API server to communicate with the webhook component, the webhook requires a TLS
+certificate that the API server is configured to trust. There are a few different ways you can use to generate/configure the required TLS certificate.
+
+  - The easiest and default method is to install the [cert-manager](https://cert-manager.io/docs/) and set `admissionWebhooks.certManager.create` to `true`.
+    In this way, cert-manager will generate a self-signed certificate. _See [cert-manager installation](https://cert-manager.io/docs/installation/kubernetes/) for more details._
+  - You can provide your own Issuer by configuring the `admissionWebhooks.certManager.issuerRef` value. You will need
+    to specify the `kind` (Issuer or ClusterIssuer) and the `name`. Note that this method also requires the installation of cert-manager.
+  - You can use an automatically generated self-signed certificate by setting `admissionWebhooks.certManager.enabled` to `false` and `admissionWebhooks.autoGenerateCert` to `true`. Helm will create a self-signed cert and a secret for you.
+  - You can use your own generated self-signed certificate by setting both `admissionWebhooks.certManager.enabled` and `admissionWebhooks.autoGenerateCert` to `false`. You should provide the necessary values to `admissionWebhooks.cert_file`, `admissionWebhooks.key_file`, and `admissionWebhooks.ca_file`.
+  - You can sideload custom webhooks and certificate by disabling `.Values.admissionWebhooks.create` and `admissionWebhooks.certManager.enabled` while setting your custom cert secret name in `admissionWebhooks.secretName`
+  - You can disable webhooks altogether by disabling `.Values.admissionWebhooks.create` and setting env var to `ENABLE_WEBHOOKS: "false"`
+
+## Add Repository
+
+```console
+$ helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+$ helm repo update
+```
+
+_See [helm repo](https://helm.sh/docs/helm/helm_repo/) for command documentation._
+
+## Install Chart
+
+```console
+$ helm install \
+  opentelemetry-operator open-telemetry/opentelemetry-operator
+```
+
+If you created a custom namespace, like in the TLS Certificate Requirement section above, you will need to specify the namespace with the `--namespace` helm option:
+
+```console
+$ helm install --namespace opentelemetry-operator-system \
+  opentelemetry-operator open-telemetry/opentelemetry-operator
+```
+
+If you wish for helm to create an automatically generated self-signed certificate, make sure to set the appropriate values when installing the chart:
+
+```console
+$ helm install  --set admissionWebhooks.certManager.enabled=false --set admissionWebhooks.certManager.autoGenerateCert=true \
+  opentelemetry-operator open-telemetry/opentelemetry-operator
+```
+
+_See [helm install](https://helm.sh/docs/helm/helm_install/) for command documentation._
+
+## Uninstall Chart
+
+The following command uninstalls the chart whose release name is my-opentelemetry-operator.
+
+```console
+$ helm uninstall opentelemetry-operator
+```
+
+_See [helm uninstall](https://helm.sh/docs/helm/helm_uninstall/) for command documentation._
+
+This will remove all the Kubernetes components associated with the chart and deletes the release.
+
+The OpenTelemetry Collector CRD created by this chart won't be removed by default and should be manually deleted:
+
+```console
+$ kubectl delete crd opentelemetrycollectors.opentelemetry.io
+```
+
+## Upgrade Chart
+
+```console
+$ helm upgrade my-opentelemetry-operator open-telemetry/opentelemetry-operator
+```
+
+Please note that by default, the chart will be upgraded to the latest version. If you want to upgrade to a specific version,
+use `--version` flag.
+
+With Helm v3.0, CRDs created by this chart are not updated by default and should be manually updated.
+Consult also the [Helm Documentation on CRDs](https://helm.sh/docs/chart_best_practices/custom_resource_definitions).
+
+_See [helm upgrade](https://helm.sh/docs/helm/helm_upgrade/) for command documentation._
+
+## Configuration
+
+The following command will show all the configurable options with detailed comments.
+
+```console
+$ helm show values open-telemetry/opentelemetry-operator
+```
+
+## Install OpenTelemetry Collector
+
+_See [OpenTelemetry website](https://opentelemetry.io/docs/collector/) for more details about the Collector_
+
+Once the opentelemetry-operator deployment is ready, you can deploy OpenTelemetry Collector in our Kubernetes
+cluster.
+
+The Collector can be deployed as one of four modes: Deployment, DaemonSet, StatefulSet and Sidecar. The default
+mode is Deployment. We will introduce the benefits and use cases of each mode as well as giving an example for each.
+
+### Deployment Mode
+
+If you want to get more control of the OpenTelemetry Collector and create a standalone application, Deployment would
+be your choice. With Deployment, you can relatively easily scale up the Collector to monitor more targets, roll back
+to an early version if anything unexpected happens, pause the Collector, etc. In general, you can manage your Collector
+instance just as an application.
+
+The following example configuration deploys the Collector as Deployment resource. The receiver is Jaeger receiver and
+the exporter is [debug exporter](https://github.com/open-telemetry/opentelemetry-collector/blob/main/exporter/debugexporter).
+
+```console
+$ kubectl apply -f - <<EOF
+apiVersion: opentelemetry.io/v1alpha1
+kind: OpenTelemetryCollector
+metadata:
+  name: my-collector
+spec:
+  mode: deployment # This configuration is omittable.
+  config: |
+    receivers:
+      jaeger:
+        protocols:
+          grpc:
+    processors:
+
+    exporters:
+      debug:
+
+    service:
+      pipelines:
+        traces:
+          receivers: [jaeger]
+          processors: []
+          exporters: [debug]
+EOF
+```
+
+### DaemonSet Mode
+
+DaemonSet should satisfy your needs if you want the Collector to run as an agent on your Kubernetes nodes.
+In this case, every Kubernetes node will have its own Collector copy which would monitor the pods in it.
+
+The following example configuration deploys the Collector as DaemonSet resource. The receiver is Jaeger receiver and
+the exporter is debug exporter.
+
+```console
+$ kubectl apply -f - <<EOF
+apiVersion: opentelemetry.io/v1alpha1
+kind: OpenTelemetryCollector
+metadata:
+  name: my-collector
+spec:
+  mode: daemonset
+  hostNetwork: true
+  config: |
+    receivers:
+      jaeger:
+        protocols:
+          grpc:
+    processors:
+
+    exporters:
+      debug:
+        verbosity: detailed
+
+    service:
+      pipelines:
+        traces:
+          receivers: [jaeger]
+          processors: []
+          exporters: [debug]
+EOF
+```
+
+### StatefulSet Mode
+There are basically three main advantages to deploy the Collector as the StatefulSet:
+- Predictable names of the Collector instance will be expected \
+  If you use above two approaches to deploy the Collector, the pod name of your Collector instance will be unique (its name plus random sequence).
+  However, each Pod in a StatefulSet derives its hostname from the name of the StatefulSet and the ordinal of the Pod (my-col-0, my-col-1, my-col-2, etc.).
+- Rescheduling will be arranged when a Collector replica fails \
+  If a Collector pod fails in the StatefulSet, Kubernetes will attempt to reschedule a new pod with the same name to the same node. Kubernetes will also attempt
+  to attach the same sticky identity (e.g., volumes) to the new pod.
+
+The following example configuration deploys the Collector as StatefulSet resource with three replicas. The receiver
+is Jaeger receiver and the exporter is debug exporter.
+
+```console
+$ kubectl apply -f - <<EOF
+apiVersion: opentelemetry.io/v1alpha1
+kind: OpenTelemetryCollector
+metadata:
+  name: my-collector
+spec:
+  mode: statefulset
+  replicas: 3
+  config: |
+    receivers:
+      jaeger:
+        protocols:
+          grpc:
+    processors:
+
+    exporters:
+      debug:
+
+    service:
+      pipelines:
+        traces:
+          receivers: [jaeger]
+          processors: []
+          exporters: [debug]
+EOF
+```
+
+### Sidecar Mode
+The biggest advantage of the sidecar mode is that it allows people to offload their telemetry data as fast and reliable as possible from their applications.
+This Collector instance will work on the container level and no new pod will be created, which is perfect to keep your Kubernetes cluster clean and easily to be managed.
+Moreover, you can also use the sidecar mode when you want to use a different collect/export strategy, which just suits this application.
+
+Once a Sidecar instance exists in a given namespace, you can have your deployments from that namespace to get a sidecar
+by either adding the annotation `sidecar.opentelemetry.io/inject: true` to the pod spec of your application, or to the namespace.
+
+_See the [OpenTelemetry Operator github repository](https://github.com/open-telemetry/opentelemetry-operator) for more detailed information._
+
+```console
+$ kubectl apply -f - <<EOF
+apiVersion: opentelemetry.io/v1alpha1
+kind: OpenTelemetryCollector
+metadata:
+  name: sidecar-for-my-app
+spec:
+  mode: sidecar
+  config: |
+    receivers:
+      jaeger:
+        protocols:
+          thrift_compact:
+    processors:
+
+    exporters:
+      debug:
+
+    service:
+      pipelines:
+        traces:
+          receivers: [jaeger]
+          processors: []
+          exporters: [debug]
+EOF
+
+$ kubectl apply -f - <<EOF
+apiVersion: v1
+kind: Pod
+metadata:
+  name: myapp
+  annotations:
+    sidecar.opentelemetry.io/inject: "true"
+spec:
+  containers:
+  - name: myapp
+    image: jaegertracing/vertx-create-span:operator-e2e-tests
+    ports:
+      - containerPort: 8080
+        protocol: TCP
+EOF
+```

helm/opentelemetry-operator/UPGRADING.md

@@ -0,0 +1,36 @@
+# Upgrade guidelines
+
+## <0.42.3 to 0.42.3
+
+A type of flag `autoGenerateCert` has been changed, now it is an object with two attributes `enabled` and `recreate`.
+If you previously set `autoGenerateCert` to `true` or `false` you have to set `autoGenerateCert.enabled` accordingly.
+
+## <0.35.0 to 0.35.0
+OpenTelemetry Operator [0.82.0](https://github.com/open-telemetry/opentelemetry-operator/releases/tag/v0.82.0) includes a change that allows setting the management state of custom resources [PR 1888](https://github.com/open-telemetry/opentelemetry-operator/pull/1888). Since helm doesn't upgrade CRDs ([documented](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-operator#upgrade-chart)) it is critical to manually update CRDs from chart `0.35.0` or above, possibly using [this procedure](https://github.com/open-telemetry/opentelemetry-helm-charts/issues/69#issuecomment-1567285625).  If this step isn't taken existing otelcol CRs won't be reconciled by the operator.
+
+## 0.27 to 0.28
+[Allow using own self-signed certificate](https://github.com/open-telemetry/opentelemetry-helm-charts/pull/760)
+
+A new flag `admissionWebhooks.autoGenerateCert` has been added. If you want to keep benefiting from the helm generated certificate as in previous versions, you must set `admissionWebhooks.certManager.enabled` to `false` and `admissionWebhooks.autoGenerateCert` to `true`.
+
+## 0.21 to 0.22.0
+Kubernetes resource names will now use `{{opentelemetry-operator.fullname}}` as the default value which will change the name of many resources.
+Some CI/CD tools might create duplicate resources when upgrading from an older version because of this change.
+`fullnameOverride` can be used to keep `deployment` resource consistent with the same name during an upgrade.
+
+## 0.16.0 to 0.17.0
+
+The v0.17.0 helm chart version changes OpenTelemetry Collector image to the contrib version. If you want to use the core version, set `manager.collectorImage.repository` to `otel/opentelemetry-collector`.
+
+## 0.15.0 to 0.16.0
+
+Jaeger receiver no longer supports remote sampling. To be able to perform an update, it must be deactivated or replaced by a configuration of the [jaegerremotesampling](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.61.0/extension/jaegerremotesampling) extension.<br/>
+It is important that the `jaegerremotesampling` extension and the `jaegerreceiver` do not use the same port.<br/>To increase the collector version afterwards, the update must be triggered again by restarting the operator. Alternatively, the `OpenTelemetryCollector` CRD can be re-created. [otel-contrib#14707](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/14707)
+
+## 0.13.0 to 0.14.0
+
+[Allow byo webhooks and cert](https://github.com/open-telemetry/opentelemetry-helm-charts/pull/411)
+
+The ability to use admission webhooks has been moved from `admissionWebhooks.enabled` to `admissionWebhooks.create` as it now supports more use cases.
+
+In order to completely disable admission webhooks you need to explicitly set the environment variable `ENABLE_WEBHOOKS: "false"` in `.Values.manager.env` .

helm/opentelemetry-operator/ci/cert-manager-disable-nameoverride-values.yaml

@@ -0,0 +1,5 @@
+nameOverride: no-cert-manager
+
+admissionWebhooks:
+  certManager:
+    enabled: false

helm/opentelemetry-operator/ci/cert-manager-disable-values.yaml

@@ -0,0 +1,3 @@
+admissionWebhooks:
+  certManager:
+    enabled: false

helm/opentelemetry-operator/ci/nameoverride-values.yaml

@@ -0,0 +1 @@
+nameOverride: foobar

helm/opentelemetry-operator/ci/secret-name-nameoverride-values.yaml

@@ -0,0 +1,4 @@
+nameOverride: secret-name
+
+admissionWebhooks:
+  secretName: random-name

helm/opentelemetry-operator/ci/secret-name-values.yaml

@@ -0,0 +1,2 @@
+admissionWebhooks:
+  secretName: random-name