|
|
|
|
|
|
by pinkparsnips
2197 days ago
|
|
|
Nice, clear read. It seems like Gloo was the clear winner once you dug in.
The tests were a bit limited, but since you've toyed with both, do you see a case where you'd still run with Ambassador? We've only spun up something really small, but were leaning toward Ambassador for the same reason you had (seemed really clear). Did Ambassador have any positives over Gloo other than how easy the docs were to step into? My co-worker had been daunted by the Gloo docs, but I don't think he reached out like you did. He said he didn't get far enough to use their UI, which doesn't seem like it matters, but I kind of like the edge stuff for Ambassador. Did you get you try either? Gah! Just when we thought we were done pre-evaluating. |
|
|
I think Ambassador has better self-service CRs that function together well without needing to define explicit dependencies. An example is TLSContexts and Mappings. As long as you have a host value in your mapping which matches exactly the host value of a TLSContext, that cert is used. With Gloo, it's structured differently altogether, but they have no separate resource for tls/ssl. It's defined in the VirtualService itself, so strongly coupled to the routes. Route delegation (in newer gloo) helps with this a lot!
I believe the gloo GitHub has an open issue for making ssl config its own CR, which should help.
One other thing is Ambassador (starting in 1.0) allows Mappings to be created that refer to Kubernetes Services by name, using the Namespace the Mapping is created in to find that Service.
This is incredibly helpful when you have the same services but in different Namespaces (like with multi-tenant clusters), because the same set of Mapping YAML can be applied in each Namespace without having to first generate them from templates. It depends on how you deploy.
If you're not planning to have a huge cluster with lots of dynamically added routes, and don't already have complex deploy logic, I say it's fine to keep using Ambassador. Although due to the complexity of switching ingress controllers, standardizing on one is worth it IMO.
About the Edge stack, I did try to use it, but I was unable to successfully get it to deploy in a fresh cluster. This was literally the week of them launching it, so stuff was chaotic. I also had modifications to the codebase that were required for me to use it effectively, and Edge stack is a special container that has things baked into it, so I couldn't simply change the Deployment YAML to use my container image based on the OSS version :(