Have probe query kube dns to find the app.

[tomwilkie]

Fixes #1373

[tomwilkie]

Have tested with following change to the probe yaml, works well:

diff --git a/scope-probe-ds.yaml b/scope-probe-ds.yaml
index 5c23180..7b4c835 100644
--- a/scope-probe-ds.yaml
+++ b/scope-probe-ds.yaml
@@ -28,19 +28,7 @@ spec:
         - --probe.docker=true
         - --probe.kubernetes=true
         - --probe.weave.addr=
-        # We cannot refer to the Scope App with its Kubernetes Service
-        # DNS name (weave-scope-app) directly because Docker doesn't
-        # allow customizing the DNS servers (the Kubernetes DNS add-on
-        # server in this case) of a container when it runs in the
-        # host's network namespace (see
-        # https://github.com/docker/docker/issues/10384#issuecomment-72069550
-        # ). Instead, we use variable expansion on its service
-        # environment variables.
-        #
-        # NOTE: Unfortunately this imposes a specific creation
-        # ordering since the Scope App Service needs to be created first for
-        # the service environment variables below to be accesible.
-        - "$(WEAVE_SCOPE_APP_SERVICE_HOST):$(WEAVE_SCOPE_APP_SERVICE_PORT)"
+        - weave-scope-app.default.svc.cluster.local:4040
         securityContext:
           privileged: true
         resources:

[2opremio]

Have tested with following change to the probe yaml,

Did you also move the probe to kube-system namespace? Otherwise KUBE_DNS_SERVICE_HOST won't be available.

I think it would be cleaner to do something like

diff --git a/scope-probe-ds.yaml b/scope-probe-ds.yaml
index 5c23180..7b4c835 100644
--- a/scope-probe-ds.yaml
+++ b/scope-probe-ds.yaml
@@ -28,19 +28,7 @@ spec:
         - --probe.docker=true
         - --probe.kubernetes=true
         - --probe.weave.addr=
-        # We cannot refer to the Scope App with its Kubernetes Service
-        # DNS name (weave-scope-app) directly because Docker doesn't
-        # allow customizing the DNS servers (the Kubernetes DNS add-on
-        # server in this case) of a container when it runs in the
-        # host's network namespace (see
-        # https://github.com/docker/docker/issues/10384#issuecomment-72069550
-        # ). Instead, we use variable expansion on its service
-        # environment variables.
-        #
-        # NOTE: Unfortunately this imposes a specific creation
-        # ordering since the Scope App Service needs to be created first for
-        # the service environment variables below to be accesible.
-        - "$(WEAVE_SCOPE_APP_SERVICE_HOST):$(WEAVE_SCOPE_APP_SERVICE_PORT)"
+        - --probe.resolver "$(KUBE_DNS_SERVICE_HOST)"
+        - weave-scope-app.default.svc.cluster.local:4040
         securityContext:
           privileged: true
         resources:

and implement --probe.resolver instead of hardcoding the the variable name (which may not always be available depending on namespaces etc ... )

[tomwilkie]

Did you also move the probe to kube-system namespace?

As a matter of fact, I did (a couple of days ago).

I can add a resolver flag if you like.

[tomwilkie]

Okay I don't understand why this doesn't work any more:

Looking up entries in skydns from the app seems to work:

Toms-MacBook-Pro:service twilkie$ docker exec -ti k8s_weave-scope-app.18b7593d_weave-scope-app-2ahs8_kube-system_19cce9e1-12c3-11e6-8c37-4e93ef53825d_e0f13214 /bin/sh

/home/weave # nslookup weave-scope-app.kube-system.svc.cluster.local 10.0.0.10
Server:    10.0.0.10
Address 1: 10.0.0.10

Name:      weave-scope-app.kube-system.svc.cluster.local
Address 1: 10.0.0.39
/home/weave # exit

But looking up entries from the probe doesn't:

Toms-MacBook-Pro:service twilkie$ docker exec -ti k8s_weave-scope-probe.44a42fdc_weave-scope-probe-41wfa_kube-system_1a0e3d5d-12c3-11e6-8c37-4e93ef53825d_a4023716 /bin/sh
/home/weave # nslookup weave-scope-app.kube-system.svc.cluster.local 10.0.0.10
Server:    10.0.0.10
Address 1: 10.0.0.10

nslookup: can't resolve 'weave-scope-app.kube-system.svc.cluster.local': Name does not resolve

I don't think its a iptables / kube proxy thing, as the probe can still talk to the app by service IP address.

[tomwilkie]

Actually ignore me, thats alpine nslookup being unhelpful:

/home/weave # dig @10.0.0.10 weave-scope-app.kube-system.svc.cluster.local +notcp

; <<>> DiG 9.10.2 <<>> @10.0.0.10 weave-scope-app.kube-system.svc.cluster.local +notcp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18500
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;weave-scope-app.kube-system.svc.cluster.local. IN A

;; ANSWER SECTION:
weave-scope-app.kube-system.svc.cluster.local. 30 IN A 10.0.0.39

;; Query time: 5 msec
;; SERVER: 10.0.0.10#53(10.0.0.10)
;; WHEN: Thu May 05 13:25:31 UTC 2016
;; MSG SIZE  rcvd: 79

If I change resolve.conf to look at the skydns virtual IP it works:

/home/weave # vi /etc/resolv.conf 
/home/weave # nslookup  weave-scope-app.kube-system.svc.cluster.local 10.0.0.10
Server:    10.0.0.10
Address 1: 10.0.0.10

Name:      weave-scope-app.kube-system.svc.cluster.local
Address 1: 10.0.0.39

[tomwilkie]

@2opremio PTAL, works now

[2opremio]

LGTM

[2opremio]

Tests are failing though