We have a number of installation/deployment methods like Helm, kubectl, kustomize, etc, and we're looking into adding more at #4027.
There's another aspect of the distribution we have to look into - distribution channels.
So, Kubernetes, being a big and complex ecosystem as it is, has a number of places that aggregate and siplicy both discovery and installation of the software. Conceptually sort of like Apple AppStore or Google Play Store for the end users, or like Debian/EPEL repos - you pick and install something.
We need to investigate the possibilities of shipping Vector through them.
We already have one issue related to this matter: #3384
So, we need to discover other options, and decide whether we should support them or not.
Ok. Some thoughts on this following my reading this morning.
Right now our primary mode of distribution of vector for kubernetes users is by way of the Helm charts. This could obviously change in the future but for now that's the just the way it is. With that in mind there are really two divergent paths for distribution of vector for these users.
One is, of course, the container repo and a BYO deployment which includes none of our helm charts and only our docker containers. I think it's probably safe to say that while this method is supported it's not the ideal case for our users at least until we decide whether or not we need an operator. The only reason this funnel is suboptimal for a user is the amount of work and potential pain they might experience in any attempt to get their deployment running. With that in mind, I don't think its likely very high value to sink any time into that experience specifically. This is a long winded way of saying: I don't see value in shipping containers to loads of different container repositories as a means of "distribution"
So that leaves us with the Helm artifacts. While there used to be FOUR Helm native artifact repository tools that were generating lots of buzz there are now only THREE as helm-hub has been merged into artifact-hub - leaving, as I understand thus far, the following distribution tools:
Criteria | Kubeapps Hub (Bitnami) | Artifact hub (OSS) | ChartCenter (JFrog)
-- | -- | -- | --
Chart hosting | no | no | yes
Chart dependency | no | no | yes
Chart numbers | Charts: > 1500 Versions: NA | Charts: > 2000 Versions:28k | Charts: >2000 Versions:38k
Download metrics (application level) | No (dependant on hosting) | No (dependant on hosting) | Partial
Related charts | no | yes | no
Publisher Verification | yes | yes | yes
Each platform has slightly different requirements and slightly different capabilities but all three serve the purpose of discoverability and ease of installation for Helm charts. It's relatively trivial to support all three it would seem since the process of maintenance seems to be fairly automated for each. I have no idea where the lion's share of the community energy is, but, it doesn't seem to matter much since its basically the activity of wiring our helm repo up to each platform's UI and there seem to be charts for the same pieces of software in all three locations.
We also use https://cloudsmith.com/ for our APT/YUM repos and I believe they also host charts.
Cloudsmith most certainly can host chart repos (as well as allows for some searchability), but from what I understand it is more specifically a repository host. That being said, if it's already a channel we use for distribution then we should definitely continue to use it. Since cloudsmith is a helm chart repository and these other distibution tools are not exactly repository hosts, it's possible that we could use cloudsmith as the primary repository driver that the rest of these distribution tools pass through.
Ah, this issue is going slightly off the intended topic. The idea is, assuming we have a Helm chart repository that works fine (out of the scope of this), where can we post links to it in such a way that people can discover Vector and install it - ideally with "a single click" experience.
So, we're looking for things like kubeapps.com registry - it's a list of the Helm repositories + plus the associated metadata like the Vector name and the logo. It is the primary source for the Kubeapps software - a neat GUI for installing applications into the Kubernetes clusters.
@MOZGIII correct - the three tools i outlined above are all in the same vein of kubeapps hub. They aren't repositories as much as registries for discoverability. Cloudsmith is the exception.
@eeyun right! Sorry, I've got really confused here :D
No need to apologize. I am also happy to create cards for all three and begin the process of getting us listed in these locations if you look at them and feel like they're good options.