4 ms·

This seems to assume that each app will run on a separate Kubernetes cluster. Have you given any thought to packaging apps which will run on a single Kubernetes

This seems to assume that each app will run on a separate Kubernetes cluster. Have you given any thought to packaging apps which will run on a single Kubernetes cluster?

alexk 7y ago
Yep, check out integration with helm for multiple apps: https://gravitational.com/gravity/docs/catalog/#publish-an-application-image https://gravitational.com/gravity/docs/catalog/#publish-an-a... It's something we support right now, but still polishing UX, the idea is to add more support for Helm 3.0 in the future in addition to Helm 2.0 we already support.
- llama052 7y ago
  Looks like that functionality is locked behind the Enterprise edition correct?
  - alexk 7y ago
    Seems like we have to fix the docs a bit, `gravity app` is supposed to work with any helm registry or even without one: tele build helm-package ->> tarball gravity app install tarball
closeparen 7y ago
Is cluster-per-app a thing people really do? Seems to defeat the purpose. We use Mesos rather than Kubernetes, but the point is that a central infrastructure team (maybe 15 people) manages the cluster itself. It provides service owners (several thousand people) with a small and straightfoward abstraction to provision, upgrade, and decommission their particular apps. If each service team had to deal with its own cluster scheduling, these systems would usually be massive timewasters relative to the old ways (Puppet, shell scripts, etc).
- jacques_chester 7y ago
  > Is cluster-per-app a thing people really do? Seems to defeat the purpose. Yes it is and yes, it does. Kubernetes has a fairly soft tenancy model, so in practice, multi-cluster is becoming a big deal, despite the cost in utilisation efficiency. Various attempts are being made to recover the utilisation efficiencies, such as Virtual Kubelet or Project Pacific. I think that the original sin of Kubernetes was the lack of a firm, first-class, top-down, mandatory access control model of tenancy. Disclosure: I work for VMware, which is responsible for Project Pacific.
  - alexk 7y ago
    If you think of an application as composed of hundreds of micro services, than it makes perfect sense. It's a multi-tenant system, it's just each tenant is a part of the same app.
    - jacques_chester 7y ago
      I'm not sure I follow you, could you elaborate?
- alexk 7y ago
  > Is cluster-per-app a thing people really do? Gravity enables a somewhat unique scenario of companies taking their complex micro-services stack and delivering it as an installer for software application. From the end users' perspective they don't even know that it's a k8s cluster, they consume an application that consists of multiple components. However Gravity supports the scenario when multiple applications are installed in the cluster as well.

This seems to assume that each app will run on a separate Kubernetes cluster. Have you given any thought to packaging apps which will run on a single Kubernetes cluster?

alexk 7y ago

Yep, check out integration with helm for multiple apps: https://gravitational.com/gravity/docs/catalog/#publish-an-application-image https://gravitational.com/gravity/docs/catalog/#publish-an-a... It's something we support right now, but still polishing UX, the idea is to add more support for Helm 3.0 in the future in addition to Helm 2.0 we already support.

llama052 7y ago
Looks like that functionality is locked behind the Enterprise edition correct?
- alexk 7y ago
  Seems like we have to fix the docs a bit, `gravity app` is supposed to work with any helm registry or even without one: tele build helm-package ->> tarball gravity app install tarball

closeparen 7y ago

Is cluster-per-app a thing people really do? Seems to defeat the purpose. We use Mesos rather than Kubernetes, but the point is that a central infrastructure team (maybe 15 people) manages the cluster itself. It provides service owners (several thousand people) with a small and straightfoward abstraction to provision, upgrade, and decommission their particular apps. If each service team had to deal with its own cluster scheduling, these systems would usually be massive timewasters relative to the old ways (Puppet, shell scripts, etc).

jacques_chester 7y ago
> Is cluster-per-app a thing people really do? Seems to defeat the purpose. Yes it is and yes, it does. Kubernetes has a fairly soft tenancy model, so in practice, multi-cluster is becoming a big deal, despite the cost in utilisation efficiency. Various attempts are being made to recover the utilisation efficiencies, such as Virtual Kubelet or Project Pacific. I think that the original sin of Kubernetes was the lack of a firm, first-class, top-down, mandatory access control model of tenancy. Disclosure: I work for VMware, which is responsible for Project Pacific.
- alexk 7y ago
  If you think of an application as composed of hundreds of micro services, than it makes perfect sense. It's a multi-tenant system, it's just each tenant is a part of the same app.
  - jacques_chester 7y ago
    I'm not sure I follow you, could you elaborate?
alexk 7y ago
> Is cluster-per-app a thing people really do? Gravity enables a somewhat unique scenario of companies taking their complex micro-services stack and delivering it as an installer for software application. From the end users' perspective they don't even know that it's a k8s cluster, they consume an application that consists of multiple components. However Gravity supports the scenario when multiple applications are installed in the cluster as well.