Kubernetes application deployments for restricted, regulated or remote environments.
Gravity is a Kubernetes packaging solution that takes the drama out of deploying and running applications in someone else's cloud accounts, on-premise data centers, edge locations and other "uncharted territory" environments.
With Gravity, Kubernetes apps can run and be regularly updated anywhere in the world without a massive DevOps team.
|Project Links| Description |---|---- | Gravity Website | The official website of the enterprise edition of Gravity | | Gravity Documentation | Gravity Documentation | | Gravity Examples | Examples of applications packaged with Gravity | | Blog | Our blog, where we publish Gravity news | | Security and Release Updates | Gravity Security and Release Updates |
Gravity is an open source toolkit for creating "images" of Kubernetes clusters and the applications running inside the clusters. The resulting images are called cluster images and they are just
A cluster image can be used to re-create full replicas of the original cluster in any environment where compliance and consistency matters, i.e. in locked-down AWS/GCE/Azure environments or even in air-gapped server rooms. An image can run without human supervision, as a "kubernetes appliance".
Gravity has been running in production in major financial institutions, government data centers and enterprises. Gravitational open sourced it in the fall of 2018.
There are plenty of Kubernetes distributions out there. Most of them aim to be flexible, general purpose platforms. Gravity has a more narrow focus on compliance and reducing the overhead of managing Kubernetes:
We have seen the following primary use cases for using a image-based Kubernetes approach (there may be others):
Anyone who needs Kubernetes best practices out of the box, without having to proactively manage it can benefit from Gravity. It allows you to focus on building your product instead of managing Kubernetes.
A Cluster Image produced by Gravity includes:
An image is all one needs to re-create the complete replica of the original Kubernetes cluster, with all deployed applications inside, even in an air-gapped server room.
Take a look at the examples directory in this repository to find examples of how to package and deploy Kubernetes applications using Gravity.
The following examples are currently available:
A cluster image created with Gravity can be used for:
Developers can continuously update their applications using different methods:
Each cluster provisioned with Gravity includes the built-in SSH/Kubernetes gateway called Teleport. Teleport provides the following benefits:
kubectlcommands executed on cluster nodes.
Fully autonomous Gravity clusters are running inside of large banks, government institutions, enterprises, etc. We use Gravity to run our own infrastructure.
Gravity is built by Teleport.
The original use case for Gravity was to allow Kubernetes applications to be deployed into 3rd party environments, like on-premises datacenters. That's why Gravity includes features like the built-in, graphical cluster installer, infrastructure validation and a built-in privileged access manager (Teleport) for providing remote support.
These features also resonated with security-minded teams who need to run applications in environments where compliance matters. Gravity clusters are always identical and do not allow any configuration drift over time. This allows cluster architects (aka, Devops or SREs) to "publish" clusters that are approved for production and allow multiple teams within the organization to rapidly scale their Kubernetes adoption without having to become security and Kubernetes experts themselves.
Gravity is written in Go. There are two ways to build the Gravity tools from source: by using locally installed build tools or via Docker. In both cases you will need a Linux machine.
Building on MacOS, even with Docker, is possible but not currently supported
$ git clone [email protected]:gravitational/gravity.git $ cd gravity
Running 'make' with the default target uses Docker.
The output will be stored in build/current/
If you have Go 1.10+ installed, you can build without Docker which is faster.
The output will be stored in $GOPATH/bin/
$ make install
To remove the build artifacts:
$ make clean
To contribute, please read the contribution guidelines.
Want to join our team? We are always hiring!