Enable scraping of weave metrics

[zacblazic]

Weave has some useful metrics that it exposes on two ports:

• 6782 - Weave router
• 6781 - Weave network policy controller

This change annotates the weave pod, making it a target for scraping by prometheus.

It also adds two container ports, one for each container, which prometheus will probe for /metrics endpoints. This gets around the limitation that you can only have one prometheus.io/port annotation per pod. I've also given the ports the name "metrics" so that if necessary, users can adjust their prometheus configuration to target them more directly.

[k8s-ci-robot]

Hi @zacblazic. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[rifelpet]

Thank you! Can you bump the -kops.X suffixes on these versions as well?

kops/upup/pkg/fi/cloudup/bootstrapchannelbuilder.go

Lines 673 to 679 in 44723c3

	versions := map[string]string{
	"pre-k8s-1.6": "2.3.0-kops.2",
	"k8s-1.6": "2.3.0-kops.2",
	"k8s-1.7": "2.5.1-kops.1",
	"k8s-1.8": "2.5.1-kops.1",
	"k8s-1.12": "2.5.1-kops.1",
	}

/ok-to-test

[zacblazic]

Thank you! Can you bump the -kops.X suffixes on these versions as well?

kops/upup/pkg/fi/cloudup/bootstrapchannelbuilder.go

Lines 673 to 679 in 44723c3

	versions := map[string]string{
	"pre-k8s-1.6": "2.3.0-kops.2",
	"k8s-1.6": "2.3.0-kops.2",
	"k8s-1.7": "2.5.1-kops.1",
	"k8s-1.8": "2.5.1-kops.1",
	"k8s-1.12": "2.5.1-kops.1",
	}

Hi @rifelpet, to confirm should the change be as follows?

versions := map[string]string{ 
-  	"pre-k8s-1.6": "2.3.0-kops.2", 
-  	"k8s-1.6":     "2.3.0-kops.2", 
-  	"k8s-1.7":     "2.5.1-kops.1", 
-  	"k8s-1.8":     "2.5.1-kops.1", 
-  	"k8s-1.12":    "2.5.1-kops.1", 
-  } 
+  	"pre-k8s-1.6": "2.3.0-kops.3", 
+  	"k8s-1.6":     "2.3.0-kops.3", 
+  	"k8s-1.7":     "2.5.1-kops.2", 
+  	"k8s-1.8":     "2.5.1-kops.2", 
+  	"k8s-1.12":    "2.5.1-kops.2", 
+  }

Also, should I bump the versions in channel builder weave manifest as well?

[rifelpet]

Yes, your proposed change is good. And, yes the versions in manifest.yaml will need updating along with the manifestHashes, see the travis job output:

https://api.travis-ci.org/v3/job/564013596/log.txt

search for FAIL: in the job output to see what the tests expect for manifestHash

[justinsb]

This looks great - thank you!

FYI, we also have the hack/update-expected.sh script which should update those hashes.

(As a side note, the intent of this testing to materialize changes so that they can be inspected in code-review. I'm not sure there's a ton of review we can do on the hashes, so maybe we should mask them out in our e2e testing.)

Anyway, thanks @zacblazic :-)

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justinsb, zacblazic

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [justinsb]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment