back to home

k8s-operatorhub / community-operators

The canonical source for Kubernetes Operators that are published on OperatorHub.io and part of the default catalog of the Operator Lifecycle Manager.

262 stars
697 forks
19 issues
DockerfileShell

AI Architecture Analysis

This repository is indexed by RepoMind. By analyzing k8s-operatorhub/community-operators in our AI interface, you can instantly generate complete architecture diagrams, visualize control flows, and perform automated security audits across the entire codebase.

Our Agentic Context Augmented Generation (Agentic CAG) engine loads full source files into context on-demand, avoiding the fragmentation of traditional RAG systems. Ask questions about the architecture, dependencies, or specific features to see it in action.

Source files are only loaded when you start an analysis to optimize performance.

Embed this Badge

Showcase RepoMind's analysis directly in your repository's README.

[![Analyzed by RepoMind](https://img.shields.io/badge/Analyzed%20by-RepoMind-4F46E5?style=for-the-badge)](https://repomind.in/repo/k8s-operatorhub/community-operators)
Preview:Analyzed by RepoMind

Repository Overview (README excerpt)

Crawler view

Kubernetes Community Operators About this repository This repo is the canonical source for Kubernetes Operators that appear on OperatorHub.io. The solutions merged on this repository are distributed via the [OLM][olm] index catalog [quay.io/operatorhubio/catalog][quay.io]. Users can install [OLM][olm] in any Kubernetes or vendor such as Openshift to consume this content by adding a new CatalogSource for the index image . [(more info)][catalog] **NOTE** If you are looking to distribute solutions on Openshift/OKD catalog then, you also should publish them into the repository Community Operators. Documentation Full documentation is generated via mkdoc and is located at https://k8s-operatorhub.github.io/community-operators/ IMPORTANT NOTICE Some APIs versions are deprecated and are OR will no longer be served on the Kubernetes version and consequently on vendors like Openshift . **What does it mean for you?** Operator bundle versions using the removed APIs can not work successfully from the respective releases. Therefore, it is recommended to check if your solutions are failing in these scenarios to let its users be aware. Note that you can inform via the CSV the minimal ( ) and the max Kubernetes version (metadata.annotation ) where your solution can successfully work. This information can be checked on the details of each release on OperatorHub.io. Please, make sure you check the following announcements: • How to deal with removal of v1beta1 CRD removals in Kubernetes 1.22 • Kubernetes API removals on 1.25/1.26 might impact your Operator. How to deal with it? > **NOTE** _If you have been distributing solutions on Openshift you might be aware of the property which can be used to block cluster admins upgrades when they have Operator versions installed that can **not** work well in OCP versions higher than the value informed. Nothing prevents you from using this property here, however, be aware that it is ignored on OperatorHub.io and that the index catalog built from this repository is not part of the Openshift catalog. So that, it can be useful only for those who are creating a new Source Catalog on Openshift using the index image: ._ Reporting Bugs Use the issue tracker in this repository to report bugs. [k8s-deprecated-guide]: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22 [olm]: https://github.com/operator-framework/operator-lifecycle-manager [quay.io]: https://quay.io/repository/operatorhubio/catalog?tag=latest&tab=tags [catalog]: https://k8s-operatorhub.github.io/community-operators/testing-operators/#1-create-the-catalogsource