Provide official Skipper Helm repository and make it discoverable on artifact.io

[ccmcbeck]

It's great that we have example Helm Charts from #1233,

But it would be much nicer if it was set up as a Helm Repository or an OCI (maybe it is and I can't find it). This way I can

1. Retrieve the Charts with helm repo add / update {repo}
2. Manage it as a dependent Subchart with helm dependency update

Lots of folks use a GitHub Pages URL as their Helm Repository URL

I manage about 20 other cluster operators (from Crossplane to Argo) and they all facilitate Helm Subcharting by hosting a Helm Repository. Most of them have official entries on artifact.io

Is your feature request related to a problem? Please describe.
The problem is the difficulty when installing Skipper in Kubernetes using Helm. You've done the hard part by designing/documenting generic templates. Please go the extra mile by packaging an official repository that is discoverable on artifact.io.

https://artifacthub.io/packages/helm/sinextra/skipper is someone who is trying to fill this void

Describe the solution you would like
By hosting your own Helm Repository, you make life way simpler for those of us consuming your Helm Charts -- especially as it pertains to change management via Helm Subcharts

Describe alternatives you've considered (optional)
Not sure there are any when using Helm

Additional context (optional)
Thank you for your consideration

Would you like to work on it?
Yes

[MustafaSaber]

Hi, thanks for reaching out! That would be nice! It was discussed multiple times but we just didn't have the time to create/test the chart. However, we aren't against it; It just doesn't fit in our workflow.

Would you like to work on it?
Yes

You can check how we deploy skipper in https://github.com/zalando-incubator/kubernetes-on-aws/tree/dev/cluster/manifests/skipper. Please create a PR and we will be happy to review & extend!

[szuecs]

The question is who will maintain the helm chart?
In the past we never added one but linked to some other repository and make clear that it is not us. I think we should not bless one but we are happy to link to another repository. If you want to ask questions about a configuration we are happy to help. If we have it here we will only get questions about some helm configuration which is not easily understandable.
So in general I think I would not recommend that we have a helm chart in our repository.

So I would veto adding a helm chart.

[ccmcbeck]

This saddens me since I'm a big Skipper fan -- been using it for 5+ years.

The question is who will maintain the helm chart?

Well...every other K8s component I use either maintains its own charts or has someone like Bitnami stand in the gap. The key on artifact.io is to have Zalando's official blessing so folks can install with confidence.

If you have intimate product knowledge (which all of you guys have), building and maintaining a Helm chart is fairly trivial.

I manage about 20 other cluster operators (from Crossplane to Argo) and they all facilitate Helm Subcharting by hosting a Helm Repository. Most of them have official entries on artifact.io

There are other ways to package and deploy K8s components, but Helm 3 seems like the de facto approach. When you package your component for your community, you remove so much up-front friction for folks who just want to try out your great product.

Thank you for considering my issue. Good to know you will help me package it myself.

[szuecs]

Formerly someone of the community maintained a chart and we linked it.
Maybe that's a way to make it happen?

There are a lot of tools that could package it picking one is hard. Skipper is also useful without kubernetes so I think there would be a gap between support and it will duplicate the operations docs and support.
I think it is not sustainable for the project. Better would be to invest more into docs if needed.
Do you think we should document some parts better than we have?

[ccmcbeck]

@szuecs thank you for the thoughtful response.

Now that I've packaged both skipper and kube-ingress-aws-controller I must say the documentation is better than I originally thought. It still took me a full day to self-package.

Once my new Helm packages are fully deployed on all my clusters, I will consider submitting a PR to improve the docs. A couple right off the bat are

1. Organize the github examples like a Helm Charts folder
2. Consider 2 separate example Charts for skipper and kube-ingress-aws-controller instead of co-mingling
3. Resolve the discrepancies between https://opensource.zalando.com/skipper/kubernetes/ingress-controller/#deployment-style and https://github.com/zalando-incubator/kube-ingress-aws-controller/blob/master/deploy/skipper.yaml.example

Also, can you help me by answering these 2 questions?

1. (Roughly) What % of your customers are on Helm?
2. How important is it to you that a new user can install and trial both packages in less than an hour?

Thanks for all you guys do for the community

[szuecs]

@szuecs thank you for the thoughtful response.

Now that I've packaged both skipper and kube-ingress-aws-controller I must say the documentation is better than I originally thought. It still took me a full day to self-package.

Bundling both tools sounds like a reasonable option to have in our docs and even in our repository.
Likely you are right now convincing me to have a helm chart 🙂.

Once my new Helm packages are fully deployed on all my clusters, I will consider submitting a PR to improve the docs. A couple right off the bat are

1. Organize the github examples like a Helm Charts folder
2. Consider 2 separate example Charts for skipper and kube-ingress-aws-controller instead of co-mingling
3. Resolve the discrepancies between https://opensource.zalando.com/skipper/kubernetes/ingress-controller/#deployment-style and https://github.com/zalando-incubator/kube-ingress-aws-controller/blob/master/deploy/skipper.yaml.example

Also, can you help me by answering these 2 questions?

1. (Roughly) What % of your customers are on Helm?

I have no idea.

2. How important is it to you that a new user can install and trial both packages in less than an hour?

That's a good question, maybe we should support it.

Thanks for all you guys do for the community

Thanks for sharing your thoughts and discussing with us!

So I would say, let's have a charts/ folder to bundle both into some art of package. Would you create a PR for this?
Let's try to have least options possible to satisfy the goal of new users first.
What do you think about adding external-dns or should we better add a link or command to install it?

[ccmcbeck]

What do you think about adding external-dns or should we better add a link or command to install it?

Bitnami has us covered on external-dns at https://artifacthub.io/packages/helm/bitnami/external-dns

[ccmcbeck]

Here is our thought process when deciding on new K8s components

1. Is it actively developed?
2. Is it adequately packaged? Can I easily package it myself?
3. Is the packager trustworthy? Are they a verified publisher on artifact.io? Or do they host a Helm repo?

When a component doesn't meet those criteria, I look for a different component.

Don't get me wrong. I love Skipper. I just want ya'll to have a better OOBE (out of box experience)

[ccmcbeck]

Would you create a PR for this?

@szuecs, I will and here is my proposal

1. Create a single chart that contains both skipper and kube-ingress-aws-controller in the same package (for ease of startup)
2. Provide a values.yaml param to choose between Deployment or Daemonset for skipper
3. DRY up the default skipper -{ARGS} for both Deployment and Daemonset
4. Provides a standard way to
   1. Add annotations (especially IRSA)
   2. Add skipper container ENV vars
   3. Add labels
   4. Add additional skipper -{ARGS}
   5. Override image.tag to bump versions
5. Contains the RouteGroups CRD

FWIW, I use a Crossplane Stack (using your example Stack) for provisioning the SecurityGroup for Internet access to the LB. I will ad an example of how to do that as well.

It's the least I can do in return for 5 years of rock-solid Skipper performance