I am looking into a solution for air gapped k8s deployment. Many people told me to use https://www.replicated.com/. so why would you guys use gravity instead of replicated? I personally like a lot of things gravity does but how i can make the sell to my team?
Unlike the Replicated product, Gravity from the beginning was designed to be a native, Kubernetes-only solution. It never supported non-K8s or non-HA deployments.
Gravity was built around the idea of “Kuberneets appliances”, i.e. fully contained, highly available K8s clusters that can be created from a single file and do not require active management, even at scale. Features like image-based deployments, infrastructure validation, registry encapsulation and running K8s under a “cluster hypervisor” were needed to implement this vision.
Another critical requirement which Gravity addressed from the start was compliance and support for remote ops. The people behind Gravity have previously worked on Rackspace infrastructure and dealing with 7 data centers around the world and thousands of customers shaped the innovations behind Teleport, the technology which Gravity security, compliance and remote connectivity are based on.
In other words, Gravity is a large-scale enterprise solution with focus on reduced operational overhead and enforcing compliance. This is also why we’ve open sourced it. Some organizations see reliance on proprietary code bases as risk and the community can now conduct their own security audits in the open.
I hope this helps.
@Ev_Kontsevoy Thanks for your reply. This is really helpful. do you know when we can use it on mac? the document says it will work on mac link to github issue but it doesn’t? this is not very convenient for some of our mac developers to play with.
This is an unfortunate artifact of open sourcing, it takes surprising amount of work. We have temporarily lost the ability to run
tele natively on a Mac. Usually
tele runs as part of a build process, i.e. inside a CI/CD pipeline on Linux, but from developer’s productivity point of view, we should fix MacOS tele builds ASAP.
For the time being, I would recommend virtualization or/and using a cloud instance for experiments with
Totally agree. We need something "works on my machine"first, before we can make it into CI/CD. I am personally ok with even running linux as my desktop but not everyone likes that. And if we are thinking “everything-as-a-code”, i’d need to manage two workspaces now. One on mac for everything except “gravity” and one on linux for only “gravity”
One thing that might work as an interim solution, although I haven’t tried it, is running tele inside a docker container. I don’t know if it would really work or not, since you would need to map the docker socket into the container, or possible run docker inside the container as it’s own instance, but docker on mac is basically just a linux VM anyway’s, where the docker cli is setup to hide the implementaiton details.
that might work for now. I used similar solutions before for AWS Lambda functions that needs native modules. Docker-in-Docker
@Ev_Kontsevoy I am reading the white paper and it reads “Large number of smaller Kubernetes clusters as opposed to fewer large clusters.” why gravity can not support large clusters? Can you share more information on that?
Sure. In our experience, Kubernetes users fall into one of the two camps:
- Those who run everything in one giant cluster, separating apps and environments into namespaces, etc.
- Those who have a need to frequently spin up and destroy clusters, and keep many (sometimes thousands) of clusters operational across multiple regions/data centers/clouds with a small ops team.
Gravity aims to please the latter group. Most of Gravity features are aimed at reducing operational overhead (i.e. “Kubernetes appliances”) and generally treating clusters as cattle, not pets.
This means that people who only have one cluster (to which they cater, as to a pet) simply won’t be realizing most of Gravity benefits. In other words, it’s about business value, not the technology. The clusters themselves are vanilla Kubernetes, i.e. the cluster size and performance are as good as Kubernetes itself.