emissary-ingress / emissary Goto Github PK
View Code? Open in Web Editor NEWopen source Kubernetes-native API gateway for microservices built on the Envoy Proxy
Home Page: https://www.getambassador.io
License: Apache License 2.0
open source Kubernetes-native API gateway for microservices built on the Envoy Proxy
Home Page: https://www.getambassador.io
License: Apache License 2.0
Creating a service in Ambassador shouldn't need a port, because the K8s service record has the port. That requires Ambassador-SDS to honor that port number though (currently, it doesn't).
That's the Envoy admin port. We should gateway it through Ambassador, if it's exposed in any way at all.
It's not hard to build and run a modified Ambassador... but since it's not documented, it might as well be.
No clue how cross brittle or crossplatform the tail/awk stuff is, but at least limiting to just the ambassador service would kill some noise, especially on a busy cluster.
export AMBASSADORIP=$(kubectl get services ambassador | tail -1 | awk '{print $3}')
Ambassador is meant to have a role that is operationally critical, so we should have one running all the time actually handling significant amounts of traffic while both its services and itself are coming, going, being upgraded, etc.
This would also be a good place to test various types of failures.
Check that Istio features work as expected with Amabassdor. The big ticket item are that session identifiers propagate all the way to the edge and HTTP/2 works correctly.
A Better Way is to automagically reconfigure on POST
.
Ambassador needs documentation around Installation and Upgrade that is written from an Operational / Administrative perspective for production usage.
We can probably fire up certbot easily...
Ambassador just needs a statsd-sink
service to be defined, but we should document that.
Ambassador needs to be able to send stats off to statsd, whatever statsd the user wants to use.
Ambassador needs to support Json Web Token ("JWT") an an authentication mechanism.
Information we need to collect:
Outputs:
Sigh.
Istio is capable of a rich set of routing behaviors that Ambassador should provide access to, for example:
Much of these can be managed by weighted round-robin, but some will require intelligence in how Ambassador constructs Envoy clusters.
The current build process relies on hand-set environment variables, making sure you manually run bump2version
, doesn't really support dev builds, etc. Yuck.
A dev build - which should be any build not run under CI - needs to figure out its own version number based on the most recent tag.
CI builds should increment the version number automagically.
Dev builds should default to using the datawire-dev DockerHub org, but that must be overridable.
...notably including:
...since skunkworks should be showing nice donuts...
Desired features
This will be useful for setting up release tests and soak tests, as well as providing the foundation for the actl
command.
Envoy supports the prefix_rewrite
directive to morph one URL prefix into another. We need to support that.
(We need to support many other directives, too, but this is probably first.)
At minimum, they need to be able to specify a cert for the listener, and whether to use SSL to the back end.
The V1 config files are going to go the way of the dinosaur. We need to migrate to the V2 APIs.
Graphite is likely the simplest way we can show some stats.
This might be covered by the definition of #9...
I've included the logs below. The deployment goes into the CrashLoopBackoff and never seems to come alive... I see this in the logs...
[rhs@venture ambassador]$ kubectl logs ambassador-381468975-trd2g ambassador
/application
[2017-05-04 01:20:23.017][9][warning][main] initializing epoch 0 (hot restart version=7.2490552)
[2017-05-04 01:20:23.030][9][warning][main] all clusters initialized. initializing init manager
[2017-05-04 01:20:23.034][9][warning][main] all dependencies initialized. starting workers
[2017-05-04 01:20:23.034][9][warning][main] starting main dispatch loop
2017-05-04 01:20:23 ambassador 0.8.0 INFO: initializing on ambassador-381468975-trd2g (resolved 172.17.0.5)
2017-05-04 01:20:43 ambassador 0.8.0 INFO: ambassador found restarter PID 6
Traceback (most recent call last):
File "/application/ambassador.py", line 489, in <module>
main()
File "/application/ambassador.py", line 475, in main
new_config(envoy_restarter_pid = -1) # Don't automagically signal here.
File "/application/ambassador.py", line 303, in new_config
num_mappings = len(rc.mappings)
TypeError: object of type 'NoneType' has no len()
This needs to be written down and agreed upon by all stakeholders ASAP. It will end up being a part of the Quick Start.
Envoy already supports this.
DoD:
To limit scope for this project, let's just use config rewriting and point services at the Kubernetes DNS entry for the service, rather than using the SDS to query Kubernetes endpoints.
We have a prototype authentication service, but we have no documentation for how to use it.
DoD:
It's pointless; SDS handles that.
As it stands, anyone in the world can do anything. That's obviously unacceptable.
The most straightforward way to handle this is to take request headers and hand them off to an auth service (which, naturally, will be vectored through Ambassador).
DoD:
If SDS or other such services die, they need to be restarted.
First stage of GH-9
Having REST and gRPC would be make life easier for some users than simply REST.
This should Just Work in Envoy, but Ambassador may need to know more than it does about gRPC.
If you create a service where a ports
entry has no name
, kaboom.
ambassador-sds
uses the port
name
to match against the service name, in case a service advertises multiple ports that aren't really the same functionality. Should be OK to assume that a nameless port
is a match.
Always deploy ambassador-store
instead, which will be used only for us.
Later we'll very likely be changing the storage model, so, better to isolate it.
when I redeploy a kubernetes service sitting behind a given ambassador route, there seem to be 5-10 seconds of downtime... this doesn't happen if I'm connecting directly to the external ip of the service
The docs talk about mappings, but the endpoints say services. That's silly.
...including, of course, automated tests.
There will be others needed, too, but Datadog is first.
In order to to make Ambassador easier to distribute, install and reuse packaging at a Helm Chart is important.
Output of this Issue should be:
My ambassador got into a mysteriously wedged state. It was responding just fine to /ambassador/* queries, but it refused to route to my upstream "hello" cluster.
After some head scratching I managed to track this down to the sds service being wedged. I was able to diagnose this because a) the sds service was hanging when I queried it, and b) I got the appended stack trace from the logs.
This raises the obvious question of why it got wedged in this way, but perhaps more importantly this points to the need for some kind of health checking on the various envoy "plugin" services.
[rhs@venture hello]$ kubectl logs ambassador-sds-3085809130-cp47x
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 699, in inner
srv.serve_forever()
File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 536, in serve_forever
HTTPServer.serve_forever(self)
File "/usr/lib/python2.7/SocketServer.py", line 238, in serve_forever
self._handle_request_noblock()
File "/usr/lib/python2.7/SocketServer.py", line 297, in _handle_request_noblock
self.handle_error(request, client_address)
File "/usr/lib/python2.7/SocketServer.py", line 295, in _handle_request_noblock
self.process_request(request, client_address)
File "/usr/lib/python2.7/SocketServer.py", line 321, in process_request
self.finish_request(request, client_address)
File "/usr/lib/python2.7/SocketServer.py", line 334, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python2.7/SocketServer.py", line 649, in __init__
self.handle()
File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 232, in handle
rv = BaseHTTPRequestHandler.handle(self)
File "/usr/lib/python2.7/BaseHTTPServer.py", line 340, in handle
self.handle_one_request()
File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 267, in handle_one_request
return self.run_wsgi()
File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 209, in run_wsgi
execute(self.server.app)
File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 200, in execute
write(data)
File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 168, in write
self.send_header(key, value)
File "/usr/lib/python2.7/BaseHTTPServer.py", line 401, in send_header
self.wfile.write("%s: %s\r\n" % (keyword, value))
IOError: [Errno 32] Broken pipe
We had a fun situation here where a tester made a bad change to Ambassador's config (specifically, they fed Ambassador an extauth URL that was malformed) and its Envoy crashed. In this case, you can't recover without some serious magic.
Thus:
Currently Ambassador maintains a second Ingress rather than just managing the Istio Ingress. It would be ideal to remove this extra hop in each request routing by letting Ambassador manage the Istio Ingress directly. It would also simplify the deployment of Ambassador so that there are not two Ingresses to think about.
Outputs:
In theory this will Just Work™ now. It needs to be tested, though.
Can this be configurable?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.