Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gravity: Upstream Kubernetes packaging tools

github.com

Post reply on HN
Print view View original

11–20 of 43 posts

Re: Gravity: Upstream Kubernetes packaging tools

#11

Post by alexk »

chucky_z wrote: post #10
alexk wrote: post #2

Hey all, I'm part of the team at Gravitational - a company behind this effort. Will be happy to answer any questions about this project.

Would Gravitational ever think about creating a more generic layer on this, e.g.: to manage Mesos, Nomad, or something else entirely like Corosync via some kind of driver system? I love Teleport but don't use k8s anywhere.

This is one of those ideas we always wanted to implement, but in reality, once we took on deploying K8s it completely consumed all the teams' resources :D

Re: Gravity: Upstream Kubernetes packaging tools

#12

Post by closeparen »

richardwhiuk wrote: post #4
alexk wrote: post #2

Hey all, I'm part of the team at Gravitational - a company behind this effort. Will be happy to answer any questions about this project.

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?

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).

Re: Gravity: Upstream Kubernetes packaging tools

#14

Post by ablekh »

alexk wrote: post #2

Hey all, I'm part of the team at Gravitational - a company behind this effort. Will be happy to answer any questions about this project.

1. Is Gravity a fully open source software (with commercial support) or an Open Core software? If the latter, please point to a feature matrix or relevant part of documentation.

2. How Gravity solution (and/or approach) is different from a similar offering by Replicated?

EDIT: Oops, sorry, just found the answer to my Q1: about halfway down on the following page: https://gravitational.com/gravity. However, some information on pricing structure and approximate numbers would be appreciated. Replicated is more transparent in this regard. :-) Q2 still stands. Looking forward to hearing from you.

Re: Gravity: Upstream Kubernetes packaging tools

#15

Post by chucky_z »

alexk wrote: post #11
chucky_z wrote: post #10

Earlier quoted context omitted.

Would Gravitational ever think about creating a more generic layer on this, e.g.: to manage Mesos, Nomad, or something else entirely like Corosync via some kind of driver system? I love Teleport but don't use k8s anywhere.

This is one of those ideas we always wanted to implement, but in reality, once we took on deploying K8s it completely consumed all the teams' resources :D

Anyway, just a 1-person note, but "here's an open source bottom layer for you to build (x) on top with the ux of teleport/gravity" would be incredible.

Re: Gravity: Upstream Kubernetes packaging tools

#16

Post by mwcampbell »

alexk wrote: post #2

Hey all, I'm part of the team at Gravitational - a company behind this effort. Will be happy to answer any questions about this project.

I wonder if you've considered building a complete VM image instead of a tarball. A minimal, immutable VM image could be more finely tuned and hardened than a tarball installed on top of a general-purpose distro. You could take inspiration from CoreOS or LinuxKit here. Or do you find that the sysadmins in the kind of organization that install these on-prem packages really want to install on top of their favorite distro?

Re: Gravity: Upstream Kubernetes packaging tools

#18

Post by cdoxsey »

catern wrote: post #3

I find each new development in the field of deploying Kubernetes to be grimly humorous. We had lots of techniques to package and deploy things before Kubernetes, but they were complex and inadequate in some ways, and Kubernetes fixes some of those issues. But it turns out Kubernetes itself is substantially more complicated to package and deploy than the old solutions, if you're deploying it yourself rather than using…

> But it turns out Kubernetes itself is substantially more complicated to package and deploy than the old solutions

Not really. It's pretty much the same level of complication if you used the same components. You could use all the same tools: chef, puppet, ansible, etc. Once you have it available though other applications are easier to deploy.

At any rate, this tool provides something entirely different. It lets you image the entire data center and reproduce it somewhere else. Not sure how you would've done that before.

Re: Gravity: Upstream Kubernetes packaging tools

#19

Post by alexwilliamsca »

mwcampbell wrote: post #16
alexk wrote: post #2

Hey all, I'm part of the team at Gravitational - a company behind this effort. Will be happy to answer any questions about this project.

I wonder if you've considered building a complete VM image instead of a tarball. A minimal, immutable VM image could be more finely tuned and hardened than a tarball installed on top of a general-purpose distro. You could take inspiration from CoreOS or LinuxKit here. Or do you find that the sysadmins in the kind of organization that install these on-prem packages really want to install on top of their favorite distr…

A minimal immutable VM image which is finely tuned and hardened is the exact approach we're taking with https://on-premises.com - except we haven't focused on k8s workloads. We've found that customers would much rather import a VM than "install" something, however there are valid use-cases which require special monitoring tools and other customizations which are not possible on an immutable system. Gravity is interesting and seems to meet that demand.

Re: Gravity: Upstream Kubernetes packaging tools

#20

Post by jacques_chester »

closeparen wrote: post #12
richardwhiuk wrote: post #4

Earlier quoted context omitted.

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?

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 clust…

> 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.

Post reply on HN