On Saturday, September 16, 2017 at 4:43:53 AM UTC+5:30, Mark Petrovic wrote:
> Hello.
> 
> 
> I would have made this shorter if I could.  Sorry.  My context is
> Kubernetes, but my immediate questions are around clusters I configure on
> Google Compute Engine (GCE).  Someone out there is bound to be in my 
> situation, so I feel
> comfortable coming here, having been here a few times over the years.
> 
> 
> I am in pre-production research mode for running Kubernetes clusters
> on regular GCE  VMs.  I know about Google Container Engine, but I'm not ready 
> to take that step.
> 
> 
> My work history: I have a couple years of working with Kubernetes
> in various ways, but I'm still far from an expert.
> 
> 
> The very recent past:
> 
> 
> I've successfully setup a k8s cluster on GCE where the control plane
> VMs (master, scheduler, controller, kubelet, kube-proxy) resided
> on a GCE-Custom VPC network 10.0.0.0/24  (I'm avoiding the regional
> default networks because I'm in learning mode and I want and learn
> from that control).  In this k8s cluster, I created a second VPC
> "podVPC" 172.16.0.0/16 from which pod IPs are allocated.  On each
> node's kubelet, I configure a /24 from the podVPC for pods.  I know
> the controller-manager *can* be involved in pod CIDR management,
> but I have chosen that it not be.  I tell the kubelet what pod cidr,
> via the kubelet param --pod_cidr, it can use, not the controller.
> I followed what I call the "cbr0" model in crafting the cluster
> config, found here:
> https://kubernetes.io/docs/getting-started-guides/scratch/.  That
> guide is dated, but I pieced it together.
> 
> 
> In this model, to make pod IPs routable within the cluster you have
> to create GCE VPC Routes that route pod IPs through their respective
> nodes.  Did that, and it works fine.   You also need GCE firewall rules so 
> the control plane members on net-10 can 
> talk to each other; did that, works fine.
> 
> 
> This cluster works as intended.
> 
> 
> Now, the problem with this network approach is that if you want to route
> pod IPs across a VPN to your corp network via, say, BGP + Cloud
> Router, this design won't work because GCE just won't do that routing
> yet.
> 
> 
> So, enter GCE IP Aliases: https://cloud.google.com/compute/docs/alias-ip/
> 
> 
> The present:
> 
> 
> I need those pod IPs routed to my corp network, so I need to evolve my design.
> 
> 
> Keep the cluster configuration the same as the cluster above.
> Meaning, no changes to the kubelet or controller manager.
> 
> 
> However, the GCE VM configs *do* change.  Now you create VMs with
> GCE-secondary subnets, aka IP Aliases.  Out of these per-VM secondary
> ranges, you allocate pod IPs.  This means you do not create a second
> podVPC as above and manually route pod CIDRs to their respective
> nodes.  When you define a secondary subnet on a network, GCE will
> setup those routes for you, and announce those routes over VPN to
> your corp network.
> 
> 
> My first problem:  if I bring up a couple of nodes with IP Alias
> ranges defined on them, without any pods running at all, I can
> already ping addresses where the pods will be allocated.  This makes
> me think two things:  1) I've read the IP Alias docs carefully but
> I've already screwed up my VM config, 2) my node VM config is correct
> and nodes are supposed to masquerade as secondary workloads.  And
> if 2 obtains, when a real pod does come up, how do I tell (via some
> k8s control plane flag??) the GCE fabric to stop masquerading as
> the pod?
> 
> 
> Thanks for reading this far.

Are there any problems present if I try running Kubernetes Cluster present in a 
distributed form across a number of VMs that are part of a VPN?

If yes, what problems might be headed my way and how can I avoid them?

Although this is a Kubernetes group, if someone has experience doing something 
similar, running docker in Swarm mode, running containers on VMs present in a 
VPN, instead of a Kubernetes cluster, kindly share your two cents. I am new to 
the Kubernetes/docker-swarm mode but have worked with Docker in the past.

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to