Reflectors are created and run within the same function, asynchronously from the main thread.
Creating reflectors may require calls to the kubernetes api, which can return errors.
API errors are not handled in the main thread, but are handled asynchronously by retries.
Upgraded from 99c19923, branch release-3.0.
This required fetching or upgrading the following:
* k8s.io/api to kubernetes-1.9.1
* k8s.io/apimachinery to kubernetes-1.9.1
* github.com/juju/ratelimit to 1.0.1
* github.com/spf13/pflag to 4c012f6d
Also, update Scope's imports/function calls to be compatible with the new client.
`isResourceSupported` checks whether a kubernetes resource is supported by the api server.
This ensures that, if the probe is unable to communicate with the api server, the call is retried until a true/false response.
If `isResourceSupported` returns false, `ListAndWatch` is not called and `runReflectorUntil` just exits.
This change makes the underlying reader set their corresponding `eof` slot to true on termination.
This make the overall logReadCloser converge to EOF in case of errors of the underlying readers, therefore prevent spinning on read.
`bufio.Reader.ReadBytes` may not return io.EOF when `Close()` closes the underlying reader.
For instance, closing logReadCloser from the Scope App makes `bufio.Reader.ReadBytes` produce the following error: `http2: response body closed`.
This is achieved by issuing an http request for each container to kubernetes' API, which yields one Reader for the corresponding container.
`logReadCloser' then reads from the above readers in parallel as data is available, buffering when necessary, forwarding it to clients by implementing the io.ReadCloser interface.
...which is useful if we want to disable periodic fetching of all
objects.
Previously the interval was also used to set the initial backoff of
the reconnect logic. A zero value there would result in _no_
backoff. So instead we now just use the default, which is 10s which
also happens to be the default probe.kubernetes.interval, so there is
no change in behaviour for the stock settings.
Having 6 lists of topolgies in the same file is a bit much:
1. consts for topology names
2. Report type definition
3. MakeReport() Report initialisation
4. Report.Topology(name) lookup
5. Report.TopologyMap() mapping of names to topology references
6. Report.WalkPairedTopologies() iterator over topology references
We get rid of 5 and 6 by introducing a topologyNames slice. So we
are down to 5.
We replace Report.TopologyMap() with a new function,
WalkNamedTopologies, that uses topologyNames. WalkPairedTopologies()
is updated to operate in a similar fashion. Likewise for
WalkTopologies() and Topologies() - these were previously calling
Walk[Paired]Topologies, but it is clearer to simply implement them
directly.
It is unused and none of the adjacency mapping code in the renderer
takes any notice of it. Removing this shrinks the report size.
Edges were introduced in #838. At the time we had an experimental
packet sniffer under experimental/sniff/sniffer.go. That got removed
in #1646.
We can resurrect this if we ever decide to add meta data to edges.
Use Utsname from golang.org/x/sys/unix which contains byte array
instead of int8/uint8 array members. This allows to simplify the string
conversions of these members and the marshal.FromUtsname functions are
no longer needed.
EbpfTracker can die when the tcp events are received out of order. This
can happen with a buggy kernel or apparently in other cases, see:
https://github.com/weaveworks/scope/issues/2650
As a workaround, restart EbpfTracker when an event is received out of
order. This does not seem to happen often, but as a precaution,
EbpfTracker will not restart if the last failure is less than 5 minutes
ago.
This is not easy to test but I added instrumentation to trigger a
restart:
- Start Scope with:
$ sudo WEAVESCOPE_DOCKER_ARGS="-e SCOPE_DEBUG_BPF=1" ./scope launch
- Request a stop with:
$ echo stop | sudo tee /proc/$(pidof scope-probe)/root/var/run/scope/debug-bpf
This prevents cluttering host.LocalNetworks with lots of /32
addresses. These were unsightly and rather distracting in the UI. They
also bloated the report and slowed down server-side rendering.
Fixes#2748.
If the app really does take a long time to process reports, it is
better not to time out and send it more reports. However, we do want
to send at least one report per app.window, otherwise the scope UI
will go blank.
Fixes#2464 (as much as is practically possible)
...since doing so unnecessarily throttles report sending, to the point
where the app is receiving reports so infrequently that often it has
no data to show.
The timeout period itself is sufficient to prevent thrashing.
Fixes#2745.
so when there is backpressure in publishing reports, drop shortcut
reports in preference to full reports, and drop old full reports in
preference to new full reports.
Fixes#2738.
