-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kubernetes Operator to support Jaeger-v2 #2717
Comments
A tip for implementation from @pavolloffay jaegertracing/jaeger#5221 (comment) |
Hello @yurishkuro, my name is Tanga I would like to help in developing the new operator as a prospective LFX mentee. Any other tips as of now? |
All tips are in the description. If you have specific questions don't hesitate to ask. |
Hello @yurishkuro! 👋🏼 I have been working with operators since a while now and I am also familiar with all the technologies that are mentioned. |
Hi @projectmaintainer, The Jaeger v2 project looks exciting! I’m particularly interested in the OpenTelemetry integration and deployment strategies. Are there any specific resources or documentation you recommend for getting up to speed? Looking forward to contributing! |
@Ali-Alnosairi all resources are already linked in the description. |
would love to give it a try for this fall term |
Hi @yurishkuro , This text is from the project description:
would you please clarify what is meant by "robust configuration management system that allows users to easily customize Jaeger deployments". Thank you in advance! |
@Ali-Alnosairi I don't know if it needs to be an "interface" or just a process, but the business need here is that even though the operator deploys Jaeger-v2 components in broad strokes, the users still need the ability to customize the YAML configuration of Jaeger, e.g. to fine-tune some parameters, maybe configure additional pipeline components, etc. So the question is how will they achieve that while still deploying the code via Operator. |
@yurishkuro Does Kubernetes have API to extend this feature? |
This should already work in OTEL Collector Operator, we just need to adopt the same procedure & document it. |
Hi @yurishkuro , I wanted to ensure my understanding of the first objective of leveraging the Opentelemetry operator is correct. In the linked approach provided by @pavolloffay above I see that the file of kind OpenTelemetryCollector deployed using Otel operator, but I am not clear on how other Jaeger components besides collectors are handled in this case as Otel operator is not concerned with those. It would be helpful if you could elaborate more on that approach. Alternatively, I found this thread (not sure if it’s outdated or still relevant) but looks like embedding Otel config in Jaeger custom resource is reasonable so I was thinking on building on this to come up with a solution. |
In Jaeger v2 there is only a single binary to deploy, but it can be deployed in different roles depending on its configuration. I assume OTEL Operator already allows deploying Collector at minimum in two roles, as a local host agent / sidecar and as a central tier. We do not need Jaeger to be deployed as agent anymore, but we do need three other roles: collector, ingester (when using Kafka, although technically it's also "collector"), and query-service / ui. |
Summary
Develop a new operator for Jaeger-v2 that achieves feature parity with the v1 operator while introducing improvements and new capabilities. This new operator will leverage the OpenTelemetry operator for Jaeger-v2 deployment while maintaining and enhancing the storage management features from the v1 operator.
Background
Part of LFX Mentorship 2024 Term 3 jaegertracing/jaeger#5772.
Jaeger is an open-source, end-to-end distributed tracing system that helps monitor and troubleshoot transactions in complex, microservices-based environments. Jaeger v2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector, bringing significant improvements and changes to the platform.
Jaeger-v1 has its own Kubernetes Operator which deploys Jaeger components according to the deployment strategy as well as the database or datastore.
Relevant links:
Project Objective
The goal of this project is to develop a new operator for Jaeger-v2 that achieves feature parity with the v1 operator while introducing improvements and new capabilities. This new operator will leverage the OpenTelemetry operator for Jaeger-v2 deployment while maintaining and enhancing the storage management features from the v1 operator.
Key Features and Implementation
OpenTelemetry Integration
Deployment Strategies
Configuration Management
Documentation and Examples
Expected Outcome
By the end of this project, we aim to achieve full feature parity between the Jaeger v2 operator and the v1 operator, with the added benefits of OpenTelemetry integration. The new operator will provide a seamless experience for users, maintaining the robustness and flexibility of v1 while introducing the advantages of v2 and OpenTelemetry.
Please note that Jaeger v2 operator will not manage/orchestrate the storage backends and we should provide documentation pointing to the Operators for Cassandra, ElasticSearch, and OpenSearch for the users to install and manage the datastores.
The text was updated successfully, but these errors were encountered: