5 ms·

It wasn’t funny. I can still see it. The answer was vpn. If you want to go fancy you can do istio with vms.

ffsm8 2y ago
And if you wanna be lazy, there is a tailscale integration to run the cluster communication over it. https://tailscale.com/kb/1236/kubernetes-operator https://tailscale.com/kb/1236/kubernetes-operator They've even improved it, so you can now actually resolve the services etc via the tailnet dns https://tailscale.com/learn/managing-access-to-kubernetes-with-tailscale https://tailscale.com/learn/managing-access-to-kubernetes-wi... I haven't tried that second part though, only read about it.
- rad_gruchalski 2y ago
  Okay, vpn it is.
  - ffsm8 2y ago
    I just wanted to provide the link in case someone was interested, I know you already mentioned it ｡ ◕ ‿ ◕ ｡ (Setting up a k8s cluster over software VPN was kinda annoying the last time I tried it manually, but super easy with the tailscale integration)
- juiyhtybr 2y ago
  yes, like i said, throw an overlay on that motherfucker and ignore the fact that when a customer request enters the network it does so at the cloud provider, then is proxied off to the final destination, possibly with multiple hops along the way. you can't just slap an overlay on and expect everything to work in a reliable and performant manner. yes, it will work for your initial tests, but then shit gets real when you find that the route from datacenter a to datacenter b is asymmetric and/or shifts between providers, altering site to site performance on a regular basis. the concept of bursting into on-prem is the most offensive bit about the original comment. when your site traffic is at its highest, you're going to add an extra network hop and proxy into the mix with a subset of your traffic getting shipped off to another datacenter over internet quality links.
  - rad_gruchalski 2y ago
    Nobody said „do it guerilla-style”. Put some thought into it.
  - chipdart 2y ago
    > yes, like i said, (...) I'm sorry, you said absolutely nothing. You just sounded like you were confused and for a moment thought you were posting on 4chan.
  - threeseed 2y ago
    a) Not every Kubernetes cluster is customer facing. b) You should be architecting your platform to accomodate these very common networking scenarios i.e. having edge caching. Because slow backends can be caused by a range of non-networking issues as well. c) Many cloud providers (even large ones like AWS) are hosted in or have special peering relationships with third party DCs e.g. [1]. So there are no "internet quality links" if you host your equipment in one of the major DCs. [1] https://www.equinix.com.au/partners/aws https://www.equinix.com.au/partners/aws

And if you wanna be lazy, there is a tailscale integration to run the cluster communication over it. https://tailscale.com/kb/1236/kubernetes-operator https://tailscale.com/kb/1236/kubernetes-operator They've even improved it, so you can now actually resolve the services etc via the tailnet dns https://tailscale.com/learn/managing-access-to-kubernetes-with-tailscale https://tailscale.com/learn/managing-access-to-kubernetes-wi... I haven't tried that second part though, only read about it.

rad_gruchalski 2y ago
Okay, vpn it is.
- ffsm8 2y ago
  I just wanted to provide the link in case someone was interested, I know you already mentioned it ｡ ◕ ‿ ◕ ｡ (Setting up a k8s cluster over software VPN was kinda annoying the last time I tried it manually, but super easy with the tailscale integration)
juiyhtybr 2y ago
yes, like i said, throw an overlay on that motherfucker and ignore the fact that when a customer request enters the network it does so at the cloud provider, then is proxied off to the final destination, possibly with multiple hops along the way. you can't just slap an overlay on and expect everything to work in a reliable and performant manner. yes, it will work for your initial tests, but then shit gets real when you find that the route from datacenter a to datacenter b is asymmetric and/or shifts between providers, altering site to site performance on a regular basis. the concept of bursting into on-prem is the most offensive bit about the original comment. when your site traffic is at its highest, you're going to add an extra network hop and proxy into the mix with a subset of your traffic getting shipped off to another datacenter over internet quality links.
- rad_gruchalski 2y ago
  Nobody said „do it guerilla-style”. Put some thought into it.
- chipdart 2y ago
  > yes, like i said, (...) I'm sorry, you said absolutely nothing. You just sounded like you were confused and for a moment thought you were posting on 4chan.
- threeseed 2y ago
  a) Not every Kubernetes cluster is customer facing. b) You should be architecting your platform to accomodate these very common networking scenarios i.e. having edge caching. Because slow backends can be caused by a range of non-networking issues as well. c) Many cloud providers (even large ones like AWS) are hosted in or have special peering relationships with third party DCs e.g. [1]. So there are no "internet quality links" if you host your equipment in one of the major DCs. [1] https://www.equinix.com.au/partners/aws https://www.equinix.com.au/partners/aws