Answers: <p>(Rancher employee) Kubernetes itself is really <a href="https://kubernetes.io/docs/setup/multiple-zones/" rel="nofollow noreferrer">not meant</a> for that use-case.  A cluster is generally a set of machines in the same provider with close proximity (latency) to each other.</p>
  
  <ul>
  <li>Etcd (and therefore API/CLI/UI/scheduling/everything) performance depends heavily on the (worst-case) latency between all members.</li>
  <li>Only one cloud-provider integration (storage providers, L4 load balancers) can be configured and most assume nodes are all in the same "region" or similar concept.</li>
  <li>Commonly used network plugins assume adjacency and/or provide no encryption or authentication suitable for communicating across untrusted networks/the internet.</li>
  <li>Communication between pods/services within the cluster has no consideration for where the "nearest" place to reach a pod for that service is, so latency from a pod to another service can be large (however far apart the two worst nodes are) and unpredictable (sometimes close, sometimes far).  (There is an option for nodePorts to <em>always</em> go to a local pod, but if there is no local pod it will just get dropped).</li>
  </ul>
  
  <p>You <em>can</em> make a "custom" cluster and add nodes from wherever and do what you're asking in Rancher, but you're not going to have a good time (no matter what product is building the cluster).</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-04-17T23:13:46.230Z
Answers: Thanks that's disappointing to hear but exactly what I wanted to know. I appreciate it.
Answers: Travis
Answers: CC BY-SA 4.0
Answers: 2019-04-17T23:08:24.900Z
Answers: 2019-04-17T23:08:24.900Z
Answers: Vincent Fiduccia
Body: <p>I'm exploring doing kubernetes on a multicloud setup the configuration I want is a master connected to nodes in multiple cloud platforms. In my limited research I haven't found many tools to make this happen,   from what I can tell rancher seems like the best option, but I don't think this fits within the traditional usecase. My question is does this sound like something rancher was made for? Honestly it seems more of a kubeadm usecase but the caveat is I want to use multiple managed solutions where multiple masters all share a common node pool.</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-04-21T17:09:29.183Z
Comments: as the accept answer says clusters are not meant to span different cloud provider. if you automate everything you can keep many clusters in sync that run anywhere. we use git webhooks to drive helmfile to manage all out environments from config in git. we open sourced our git driven approach for okd Kubernetes as ocd at https://ocd-scm.github.io/ocd-meta/
Comments: simbo1905
Tags: <kubernetes><rancher>
Title: Kubernetes multi cloud
UserDisplayName: Travis
ThreadText: # Kubernetes multi cloud
  
  (Asked by: username_0 on 2019-04-17)
  
  I'm exploring doing kubernetes on a multicloud setup the configuration I want is a master connected to nodes in multiple cloud platforms. In my limited research I haven't found many tools to make this happen, from what I can tell rancher seems like the best option, but I don't think this fits within the traditional usecase. My question is does this sound like something rancher was made for? Honestly it seems more of a kubeadm usecase but the caveat is I want to use multiple managed solutions where multiple masters all share a common node pool.
  
  **Tags:** kubernetes, rancher
  
  > **Comments:**
  > **username_1**: as the accept answer says clusters are not meant to span different cloud provider. if you automate everything you can keep many clusters in sync that run anywhere. we use git webhooks to drive helmfile to manage all out environments from config in git. we open sourced our git driven approach for okd Kubernetes as ocd at https://ocd-scm.github.io/ocd-meta/  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-04-17. Score: 1 | Accepted answer
  
  (Rancher employee) Kubernetes itself is really [not meant](https://kubernetes.io/docs/setup/multiple-zones/) for that use-case. A cluster is generally a set of machines in the same provider with close proximity (latency) to each other.
  
  * Etcd (and therefore API/CLI/UI/scheduling/everything) performance depends heavily on the (worst-case) latency between all members.
  * Only one cloud-provider integration (storage providers, L4 load balancers) can be configured and most assume nodes are all in the same "region" or similar concept.
  * Commonly used network plugins assume adjacency and/or provide no encryption or authentication suitable for communicating across untrusted networks/the internet.
  * Communication between pods/services within the cluster has no consideration for where the "nearest" place to reach a pod for that service is, so latency from a pod to another service can be large (however far apart the two worst nodes are) and unpredictable (sometimes close, sometimes far). (There is an option for nodePorts to *always* go to a local pod, but if there is no local pod it will just get dropped).
  
  You *can* make a "custom" cluster and add nodes from wherever and do what you're asking in Rancher, but you're not going to have a good time (no matter what product is building the cluster).
  
  > **Comments:**
  > **username_0**: Thanks that's disappointing to hear but exactly what I wanted to know. I appreciate it.  
  
  ---
  
  