https://rancher.com/ logo
#general
Title
# general
a

adamant-kite-43734

10/10/2022, 10:56 PM
This message was deleted.
c

creamy-pencil-82913

10/11/2022, 12:07 AM
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

tall-summer-94523

10/11/2022, 12:19 AM
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

creamy-pencil-82913

10/11/2022, 12:36 AM
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

tall-summer-94523

10/11/2022, 12:39 AM
coredns to the rescue
Thank you ❤️
2 Views