Stop ignoring the most significant labels of Destination names
Previously the destinations service was ignoring all the labels in a
destination name after the first two labels. Thus, for example,
"name.ns.another.domain.example.com" would be
considered the same as "name.ns.svc.cluster.local". This was very
wrong.
Match destination names taking into consideration every label in the
destination name.
Provisions have been made for the case where the controller and the
proxies with the zone name to use. However, currently neither the
controller nor the proxies are actually configured with the zone, so
the implementation was made to work in the current configuration too,
as long as fully-qualified names are not used.
A negative consequence of this change is that a name like
"name.ns.svc.cluster.local" won't resolve in the current configuration,
because the controller doesn't know the zone is "cluster.local"
Unit tests are included for the new mapping rules.
Signed-off-by: Brian Smith <brian@briansmith.org>
* Sort imports
Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>
* Upgrade k8s.io/client-go to v6.0.0
Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>
* Make k8s store initialization blocking with timeout
Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>
Previously the destinations service would look for services in the
"default" namespace if the service name didn't have at least two
labels. However, the "default" namespace is almost always the wrong
namespace. The only reasonable default namespace is the namespace of
the client service, which isn't given to the destinations service.
Therefore it shouldn't try to default the namespace.
Accordingly, stop defaulting the namespace to "default".
Validated by manually testing the emojivoto service before and after
the proxy implemented namespace defaulting itself.
We’ve built Conduit from the ground up to be the fastest, lightest,
simplest, and most secure service mesh in the world. It features an
incredibly fast and safe data plane written in Rust, a simple yet
powerful control plane written in Go, and a design that’s focused on
performance, security, and usability. Most importantly, Conduit
incorporates the many lessons we’ve learned from over 18 months of
production service mesh experience with Linkerd.
This repository contains a few tightly-related components:
- `proxy` -- an HTTP/2 proxy written in Rust;
- `controller` -- a control plane written in Go with gRPC;
- `web` -- a UI written in React, served by Go.
Sean McArthur
Brian Smith
Kevin Lingerfelt
Oliver Gould