Community: Kubernetes SIG

[jpkrohling]

I'd like to start a discussion to gauge the interest of a Kubernetes SIG.

The idea is to have a community of people interested in having OpenTelemetry running in Kubernetes-based clusters.

The first concrete goal is to work on the operator, to be hosted as part of the open-telemetry organization. As soon as the repository is created, it will be seeded with the current contents of the PoC hosted at my personal account: https://github.com/jpkrohling/opentelemetry-operator/ .

If we go ahead with this SIG, I'd like to propose a recurring meeting at 5pm CEST (8am PDT) on the first Wed of the month. A Gitter channel could also be created, to discuss the topics relevant to the SIG.

[Vlaaaaaaad]

Is this focused on running OpenTelemetry in Kubernetes or in adding support for OpenTelemetry to Kubernetes source code?

Looking at the repo you linked hints to the first one. Either way, massive 👍 for both.

[jpkrohling]

This is about deploying and managing OpenTelemetry components, like OpenTelemetry Collector, in Kubernetes clusters. This is not about instrumenting Kubernetes source code.

[tigrannajaryan]

@owais has a lot of experience with both Collector and K8s, he is a great candidate to be a boostraping maintainer (he is OOO currently, I will let him know when he is back).

[flands]

Beyond the Collector, what aspects would this include (looking to understand difference with Collector SIG)?

[mattwelke]

This sounds interesting to me because I'm really interested lately in Kubernetes and metrics systems. I added OpenCensus instrumentation to a few Go apps at my work on our Kubernetes cluster. I wouldn't say I'm a Kubernetes expert though and I have never created anything custom for it like an operator. Do you think this is too complex for someone with my level of experience, or do you think I'd be able to usefully contribute?

[bogdandrutu]

Internally we do have receivers for the collector that can read system metrics and kubernetes specific metrics that we are considering to open source. This may be a good fit.

[jpkrohling]

Beyond the Collector, what aspects would this include (looking to understand difference with Collector SIG)?

I can certainly see that some people will be part of both SIGs, but the interests are somewhat different: Kubernetes SIG would care about how to run (day 1) and maintain (day 2) the Collector, while the folks in the Collector SIG might not care about Kubernetes at all.

@mattwelke: we have a few "good first issue" items in the Jaeger Operator and people have been able to work on them quite often. On the other end of the spectrum, we have auto-provisioning of storage clusters (Elasticsearch, with Kafka being worked on right now). I'd say that we'll certainly have tasks of all levels for this operator as well. In other words: your help will be much appreciated!

[bhs]

The crux of this (IMO) is whether we want to have weekly meetings indefinitely around k8s specifically; or if this is more about getting the collector to integrate well with k8s, which sounds (to me) to be more of a "project" than an ongoing/indefinite effort.

I am certainly not objected to the creation of a k8s SIG if it needs to exist... but if it's more about getting the collector+k8s, then I would suggest (not strongly) doing this as part of the collector SIG just for the sake of "fewer meetings" / "fewer committees" / etc.

Again, this is not a "no" vote, just my opinion. I'm fine either way and think the work certainly sounds valuable.

[jpkrohling]

I agree that a weekly meeting around Kubernetes might be overkill, which is the basis for the suggestion in having a monthly one instead. I assume we can change the frequency according to the needs.

Right now, the only concrete task I have in mind is indeed about the operator for OpenTelemetry, which at this point is basically an operator for the Collector. Given the popularity of other tools in the Kubernetes ecosystem, such as Helm, I can imagine that we'll end up having other components as well. The Kubernetes SIG would also be home to that.

I wouldn't mind starting this as part of the Collector SIG, possibly getting a new Kubernetes SIG in case we see a clear demand for it. The question is then whether the current Collector SIG members would also like to be part of the discussions around Kubernetes. @pjanotti, @tigrannajaryan, @owais and @songy23 were at the last Collector SIG meeting on Sep 11: what's your opinion?

[bhs]

@jpkrohling sorry for missing the weekly/monthly thing... I really just meant "spinning up another SIG that meets indefinitely on some period."

The work itself is absolutely valuable and would be much appreciated... TBH I'm just trying to direct things towards the structure that will maximize the amount of "real work" being done and minimize the amount of bureaucracy for you and the others willing to help with this. Ultimately I am supportive of whatever you decide, I just wanted to ask some guiding questions.

[jpkrohling]

TBH I'm just trying to direct things towards the structure that will maximize the amount of "real work" being done and minimize the amount of bureaucracy for you and the others willing to help with this

I do appreciate that! Let's see what the others think about this. If there's no interest from them, it makes no sense in creating a SIG composed of one person ;-)

[jpkrohling]

The initial comment got a few "+1" votes, but apart from that, I haven't heard from anyone wanting to take part of the SIG. I think we should start with the operator as part of the Collector SIG and spin off in case we get more volunteers.

[bhs]

Makes sense. I will close this for now... Please feel free to reopen if a group emerges! Thanks again for suggesting the k8s operator work regardless.