Hacker News Reader

Comment by alexk | Hacker News Reader

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.

View on HN

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.

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.

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?

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.

This look interesting, is there a way to try out meta without being funneled into the sales pipeline?

What is the workflow for baking a machine? Are you using packer under the covers or some other tooling? What on-prem machine image formats are supported?

There's still a bit of "manual" work to get someone up and running on our Meta appliance, so unfortunately you would have to go through our sales process. However if you just want a video or screen recording of how it works then I can put something online in the next hour or two.

For baking the machine, we use Ansible under the covers and have a set of Lisp scripts to manage everything. As for image formats: qcow2, raw, vhd (and vmdk in the .ova file).

Not trying to hijack Gravitational's thread, please contact me (email in profile, or 'aw-' on FreeNode) if you want to discuss more.

Actually, some of our customers are doing just that - taking a tarball and making it a VM image. There are a couple of things we are making now to support this use case better, e.g. ability to easily change the ip on the VM boot up.

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?

Yep, check out integration with helm for multiple apps:

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.

Looks like that functionality is locked behind the Enterprise edition correct?

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

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

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

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.

I'm not sure I follow you, could you elaborate?

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

Reply on news.ycombinator.com