Commit Graph

10 Commits

Author SHA1 Message Date
Phil Calçado bbed49c5bd Refactor destination service and add tests in preparation to add information about labels (#645)
* Extracted logic from destination server

* Make tests follow style used elsewhere in the code

* Extract single interface for resolvers

* Add tests for k8s and ipv4 resolvers

* Fix small usability issues

* Update dep

* Act on feedback

Signed-off-by: Phil Calcado <phil@buoyant.io>
2018-03-30 11:36:48 -07:00
Brian Smith 7dc21f9588
Add the NoEndpoints message to the Destination API (#564)
Have the controller tell the client whether the service exists, not
just what are available. This way we can implement fallback logic to
alternate service discovery mechanisms for ambigious names.

Signed-off-by: Brian Smith <brian@briansmith.org>
Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>
2018-03-27 10:45:41 -10:00
Andrew Seigner 698e65da8b
Fix flakey dns_test (#516)
The dns_test had assumed DNS changes were deterministically ordered, but
util.DiffAddresses uses a map and therefore does not guarantee ordering.

Fix dns_test to sort TCP Addresses prior to comparison.

Fixes #515

Signed-off-by: Andrew Seigner <siggy@buoyant.io>
2018-03-05 16:50:33 -08:00
Kevin Lingerfelt 8e2ef9d658
Handle ExternalName-type svcs in destination service (#490)
* Handle ExternalName-type svcs in destination service

* Move refresh interval to a global var

Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>
2018-03-02 11:30:53 -08:00
Alex Leong 9b4e847555
Add DNS label validation in destination service (#464)
Add a validation in the destination service that ensures that DNS destinations consist of valid labels.

Signed-off-by: Alex Leong <alex@buoyant.io>
2018-03-01 15:49:49 -08:00
Sean McArthur db913e3d18
controller: echo ip address if destination service receives ip (#186)
Signed-off-by: Sean McArthur <sean@seanmonstar.com>
2018-01-22 16:20:13 -08:00
Brian Smith 650dcdde1e
Stop ignoring the most significant labels of Destination names (#63)
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>
2018-01-18 11:20:54 -10:00
Kevin Lingerfelt 1dc1c00a2a
Upgrade k8s.io/client-go to v6.0.0 (#122)
* 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>
2018-01-11 10:22:37 -08:00
Brian Smith 2729fa02bc
Stop using "default" as default service namespace (#61)
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.
2017-12-20 10:44:24 -10:00
Oliver Gould b104bd0676 Introducing Conduit, the ultralight service mesh
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.
2017-12-05 00:24:55 +00:00