v0.5.0

Changed

• Adds Kubernetes 1.22 dependencies updates and some cleanups.

v0.4.0

Changes

Modified the volumes names in order to avoid collisions

This change was needed in order to be able to instrument nri-kube-events.

v0.3.0

Changes

First release packaged in the newrelic-infra-operator chart

Configure in which pods the sidecar should be injected

Policies are available in order to configure in which pods the sidecar should be injected.
Each policy is evaluated independently and if at least one policy matches the operator will inject the sidecar.

Policies are composed by namespaceSelector checking the labels of the Pod namespace, podSelector checking
the labels of the Pod and namespace checking the namespace name. Each of those, if specified, are ANDed.

By default, the policies are configured in order to inject the sidecar in each pod belonging to a Fargate profile.

Moreover, it is possible to add the label infra-operator.newrelic.com/disable-injection to Pods to exclude injection
for a single Pod that otherwise would be selected by the policies.

Please make sure to configure policies correctly to avoid injecting sidecar for pods running on EC2 nodes
already monitored by the infrastructure DaemonSet.

Configure the sidecar with labelsSelectors

It is also possible to configure resourceRequirements and extraEnvVars based on the labels of the mutating Pod.

The current configuration increases the resource requirements for sidecar injected on KSM instances. Moreover,
injectes disable the DISABLE_KUBE_STATE_METRICS environment variable for Pods not running on KSM instances
to decrease the load on the API server.

Hash computed for each configWithSelectors

Right now, we hash an injected container without environment variables
or resource requirements. This commit improves that and add all other
configuration options to the mix, which make sense, like cluster name,
resource prefix etc.

Also now, each config selector will have it's own hash, with specific
value, so when config selector configuration changes, only affected pods
will need to be re-created.

Alternatively, we could cache entire configuration struct, however, that
would give a lot of false positives, as in any configuration change, all
pods would have to be re-created.

v0.2.0

fix(customAttributes): moving CustomAttributes in the agentConfig (#74)

v0.1.0

Initial release