search

kubernetes / kops

Kubernetes Operations (kOps) - Production Grade k8s Installation, Upgrades and Management
https://kops.sigs.k8s.io/
Apache License 2.0
15.91k stars 4.65k forks source link

Use Charts to install addons #2391

Closed kenden closed 6 years ago

kenden commented 7 years ago

Isn't addon_manager just a light version of helm?

Instead of managing addons like the cluster-autoscaller addon, for example, which then requires to maintain its configuration, why not just use the aws-cluster-autoscaler chart ?

We could keep addons as a thin wrapper for helm charts. They would basically just call helm, for ex: helm upgrade --install latest stable/aws-cluster-autoscaler --values config.yaml

Where config.yml would contain kops specific configuration.

fhemberger commented 7 years ago

See: https://github.com/kubernetes/kops/issues/2399#issuecomment-296227004

I think it would make sense to move all addons to the Helm project, also for all addons provided in kubernetes/kubernetes to avoid the effort of managing the same addons in different locations. As helm also offers versioning of packages, it would help to provide the correct addon version for the Kubernetes version in question.

kenden commented 7 years ago

This is related: https://github.com/kubernetes/kops/issues/1180

archseer commented 7 years ago

To add to the discussion, I agree that helm would be preferable since helm charts have more maintainers and a wider community adoption (instead of kops specific packaging). At the time of writing, heapster is 3 major versions behind, ingress-nginx is 0.8.3, whereas the latest is 0.9.0-beta.5, cluster-autoscaler is 2 versions behind, etc.

chrislovecnm commented 7 years ago

@justinsb ... your take on this?

chrislovecnm commented 7 years ago

/label area/addon-manager

chrislovecnm commented 7 years ago

/area addon-manager

StevenACoffman commented 7 years ago

@justinsb What are your thoughts here?

justinsb commented 7 years ago

There's a lot of progress on deciding on an addon manager for the kubernetes project, which might end up being helm, but it's more likely to be something lower level which helm would then leverage IMO. See bgrant's "Declarative Application Management" presentations.

For the core addons (kube-dns) we don't want to & probably can't use helm - this is low level bootstrapping. Then some people have asked for standalone manifests for things like dashboard, and so we maintain those in addons/. Those are purely optional however.

I hope we'll get a kubernetes-wide addon approach agreed, and then we can indeed have a standard manifest for all addons in the source repos. We'll probably still have to vendor our core addons (e.g. kube-dns), but then hopefully there will no need to addons/

chrislovecnm commented 7 years ago

I may be working on extending our addons functionality that we have in kop. For bootstrapping the cluster is works very well. For instance installing Jenkins or another ci tool that would build the cluster services for you.

We have the channels tool, and do not see it going away until we have a project wide replacement. We need to keep kops bootstrapping dead simple IMO.

Helm is a great tool, but installing a cni provide needs to be simple ;)

StevenACoffman commented 7 years ago

Thanks! Brian Grant was involved in this Declarative application management in Kubernetes document which may be what your are referring to.

fejta-bot commented 6 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta. /lifecycle stale

chrislovecnm commented 6 years ago

I am going to close this as work will start on the addon manager, which will probably not use charts.