Jaeger-operator: Inject sidecars in other controllers

Created on 8 Nov 2019  路  10Comments  路  Source: jaegertracing/jaeger-operator

For instance, on OpenShift if we are using DeploymentConfigs instead of Deployments we cant auto inject jaeger sidecars. With the latest Istio setup on OpenShift daemonsets are deprecated, so this becomes more important.

Places I can think of where sidecars could be injected:

  • [x] Deployments
  • [x] StatefulSets
  • [ ] DaemonSets
  • [ ] DeploymentConfigs (OpenShift)
  • [ ] CronJobs

I think https://github.com/jaegertracing/jaeger-operator/issues/171 would solve this for all controllers (as well as pods without a controller).

duplicate enhancement question

All 10 comments

One of the motivations behind #171 is indeed to be able to inject sidecars into any workload that is backed by pods, but it adds some complexity to the setup. Unfortunately, this can't be currently covered by OLM (to the best of our knowledge), so, it's currently a blocker for us.

If you absolutely require support for DeploymentConfigs, we could discuss about adding it to the current mechanism, but it will bring quite some maintenance burden.

I'm marking as "duplicate", as I'm sure we talked about this in the past.

I just added the sidecars manually for now, which works for small deployments. Not a blocker.

I just added the sidecars manually for now, which works for small deployments. Not a blocker. While #171 can't be dealt with purely on OLM, it looks like the actual complexity of the webhook (the ca bundle, etc) can be. The actual injector is relatively simple and could be run as its own service.

Apparently, support for mutating webhook is coming to the operator SDK in the future. Once it is there, we should certainly re-evaluate this!

It is a blocker for some usages, we like to deploy our artifcats the same way, using one single "rule them all" pipeline, which makes it impossible for us, as of today, to unify completely, because our periodic jobs do not receive their associated sidecar. We have to rely on a DaemonSet "ring" of agents to which our workloads connects.
I am sure we are not the only ones trying to unify their workloads deployment strategies in terms of labels, annotations, URLs and such, that's why I believe this can be a very valuable feature.

Maybe regular one off Job(s) could benefit from this feature eventually?

Oh I might add, I'm now programatically adding the sidecar agent when generating the cronjob, using my conventionnal --reporter.grpc.host-port=dns://my-jaeger-collector-headless.ns-jaeger:14250.

Worth noting, when the job finishes, the jaeger-agent doesn't exit and thus the job doesn't complete because of the sidecar nature of the agent (discussed more widely over there: https://github.com/kubernetes/kubernetes/issues/25908 .

I am just giving this as a sidenote to be kept in mind, I'll fall back to another mode of functionning for .my jobs

Can operator start supporting inject in ArgoCD Rollouts? https://argoproj.github.io/argo-rollouts/

As I understood, ArgoCD Rollouts create ReplicaSets. As such, it should work once #171 is there.

Just wanted to chime in here - while #171 is being worked on, an alternative solution is now available through KubeMod (as described in my comment).

Was this page helpful?
0 / 5 - 0 ratings