https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# general
a
This message was deleted.
c
servers don’t connect directly to agents. Communication is all agent-initiated.
So, configure your network so that the Rancher server addresses resolve to something that doesn’t involve going out to CF
Also, you should be aware that standalone Docker installs of Rancher Manager aren’t supported for anything other than very basic dev/proof-of-concept work.
t
FWIW I did not choose that pattern – it's what I recently inherited – but both are snapshotted regularly, the infrastructure is all declaratively version-controlled, the kubernetes manifests are all being declaratively version-controlled and soon to be continuously deployed as we speak, reducing rancher to a read-only dashboard for everything already checked in, and the production cluster is the imported one. I don't love it, but am not terrified of what currently is and have larger fish to fry at present.
And thank you. So you're proposing I hack at cluster-internal DNS resolution one way or another rather than messing with 
CATTLE_SERVER
, 
--address
| 
--internal-address
and whatever TLS knobs exist on the agent side, then?
c
yes. all that matters is the CATTLE_SERVER URL.
The agent connects to the server and maintains a websocket tunnel, when the server needs to connect to the cluster it builds a reverse connection through that websocket to the agent’s in-cluster kubernetes apiserver endpoint.
So, if you can get that URL to resolve to something internal to your VPC, that uses a cert trusted by the agent, you can avoid going out to the internet.
t
coredns to the rescue
Thank you ❤️
2 Views
Open in Slack
PreviousNext
Powered by