Either via DNS or by writing a simple variant of kube2sky (https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/dns/kube2sky) that feeds into our proxy system.
Description
Description
Details
Details
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| operations/puppet | production | +323 -0 | dynamicproxy: add support for kubernetes | |
| operations/puppet | production | +2 -13 | tools: Add k8s::webproxy to tools::proxy |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | yuvipanda | T111885 Initial Deployment of Kubernetes to Tool Labs | |||
| Resolved | Joe | T111916 Add support to dynamicproxy for kubernetes based web services |
Event Timeline
Comment Actions
Change 242448 had a related patch set uploaded (by Yuvipanda):
tools: Add k8s::webproxy to tools::proxy
Comment Actions
Change 241908 had a related patch set uploaded (by Giuseppe Lavagetto):
dynamicproxy: add support for kubernetes
Comment Actions
What do we still need:
- Download requests with pip3 (needs a pip3 provider or an ugly exec)
- Provide the kube token via some mechanism like hiera or something.
I'd call only the first as a requirement to consider the ticket resolved.
Comment Actions
Do we still need python3-requests that's different? I don't find any actual errors there, but not sure if that's because pip3 already installed requests?
I"m doing the token mechanism now.
Comment Actions
Yes, it looks like it's being read from /usr/local (the requests library) so it was definitely imported from pip3...
Let's put in a fixed package in our repos instead....