How to put in communication two clusters in Kubernetes

[mder...@gmail.com]

I have a situation like this:

- a cluster of web machines
- a cluster of db machines and other services

The question is how put in communication the 2 clusters in order to use some hostnames in /etc/hosts of web machines.

To protect your data, is it safe create an ingress service to make visible the db from the external? I tried with a nodePort service (so using internal ip addresses) but I'm not able to put in contact db-web between different clusters

At the moment my temporary solution is:

a) define a public static ip with the command:
gcloud compute addresses create my-public-static-ip --global

b) use an ingress configuration for my db service where I set the static ip with the option:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-ingress
annotations:
kubernetes.io/ingress.global-static-ip-name: my-public-static-ip

c) in my daemonset.yaml I define a hostAliases:

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: my-daemonset

spec:
updateStrategy:
type: RollingUpdate

template:
spec:
nodeSelector:
app: frontend-node

terminationGracePeriodSeconds: 30

hostAliases:
- ip: <public_ip_addr>
hostnames:
- "my-db-service"

and it's working. But I'm not too convinced that this solution is the best or however correct on a live environment...

[Tim Hockin]

On Tue, Dec 12, 2017 at 12:49 AM, <mder...@gmail.com> wrote:
> I have a situation like this:
>
> - a cluster of web machines
> - a cluster of db machines and other services

I think you have made the problem much more complicated than it needs
to be. Why not one cluster?

> --
> 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-use...@googlegroups.com.
> To post to this group, send email to kubernet...@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.

[Marco De Rosa]

The main reason is that the "web" cluster has hardware features different from the "db" cluster and I didn't find a way to have a cluster with for example one node better, in cpu and/or ram, than others.

So 2 clusters to put in communication with the doubt that I have described above.

The alternative could be create a single cluster with n nodes sized in such a way as to support web traffic and database work. 

So a situation where I have for example 4 nodes: in 3 nodes 6 web-pods plus the last node as pure db machine.

But this solution is quite complicated in terms of how precisely to size the web pods, the db and the overall characteristics of the cluster..

So the idea to create two different clusters

> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@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.

--
You received this message because you are subscribed to a topic in the Google Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kubernetes-users/d8xJqXYDAZ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

[David Rosenstrauch]

On 2017-12-12 4:38 pm, Marco De Rosa wrote:
> The main reason is that the "web" cluster has hardware features
> different from the "db" cluster and I didn't find a way to have a
> cluster with for example one node better, in cpu and/or ram, than
> others.
> So 2 clusters to put in communication with the doubt that I have
> described above.
> The alternative could be create a single cluster with n nodes sized in
> such a way as to support web traffic and database work.
> So a situation where I have for example 4 nodes: in 3 nodes 6 web-pods
> plus the last node as pure db machine.
> But this solution is quite complicated in terms of how precisely to
> size the web pods, the db and the overall characteristics of the
> cluster..
> So the idea to create two different clusters

FYI, this could probably be easily accomplished on a single cluster,
using node labels and node selectors.

Let's say you had 2 types of nodes: machines with big disks, and
machines with lots of memory. Then let's say that you have 2 different
types of containers - one that runs a memory cache, and one that runs a
log file processing system. What you could do is label the nodes as,
say, either "type=hidisk" or "type=himem", as appropriate. And then you
could set a node selector on the caches to only run on nodes with
"type=himem", and a node selector on the log processors to only run on
nodes with "type=hidisk".

HTH,

DR

[mder...@gmail.com]

I think that the situation is more complicated if we start looking at machine prices.
Let me use some real data:
1) I have to use a db machine like gcloud n1-standard-16 ---> kubernetes cluster with 1 node for 500$/month
2) I have to use 9 web server like n1-standard-2 ---> kubernetes cluster with 9 nodes for 480$/month

So with about 1000$/month I have the configuration that currently supports the web traffic of my company.

If I wanted to use a single cluster I should choose nodes like n1-standard-16.
Wanting not to exceed the $1000 limit, I could create a cluster with 2 nodes.
So I'll have: a node for db and a node for 9 (web) pod

So the real question could be: in terms of performance, scalability and stability which is the better solution between: (9 nodes with 1 pod) vs (1 node with 9 pods)

If two alternatives are comparable I could use a single cluster :)

[Rodrigo Campos]

Can't you use an internal load balancer to communicate?

To answer the original question

--
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-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.

[Rodrigo Campos]

Sorry, not follow the price argument. You are only charged for the nodes you use on a Kubernetes cluster (no Masters, no matter cluster size).

So, I really don't why it makes a difference the number of clusters

--
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-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.

[Gmail]

Sorry, not follow the price argument. You are only charged for the nodes you use on a Kubernetes cluster (no Masters, no matter cluster size).

I don't understand very well "no matter cluster size" whereas no one has ever talked about creating nodes that will not be used later. In my example every node will be used and of course I will be charged the cost, making the cluster size very important to define total spending

So, I really don't why it makes a difference the number of clusters

what I mean is very simple:
if I have to use a single cluster, the minimum hardware features must be able to bear db requirements.
My db must have 60 GB of RAM.
So every node in this cluster will have 60 gb.
I can spend 1000$/month so I can afford two nodes.
One node will be for db, the other will be used for many (8-10-6 I don't know) web pod
So I'm asking

in terms of performance, scalability and stability which is the better solution between:

a single cluster with 2 nodes where 1 node is used for db and other for n web-pod

or

(considering that the requirements of the db machine are very different from those of the web machines) two clusters, one for db (n1-standard-16 single node) and another for web machines (with more n1-standard-2 nodes)

Can't you use an internal load balancer to communicate?

I noticed that if I create a load balancer service or an ingress service, Kubernetes will create a public ip address.
So when you say internal load balancer, what are you referring to?
Because I tried to use a nodeport service to communicate between cluster and didn't work

You received this message because you are subscribed to a topic in the Google Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kubernetes-users/d8xJqXYDAZ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kubernetes-use...@googlegroups.com.

[Rodrigo Campos]

On Wednesday, December 13, 2017, Gmail <mder...@gmail.com> wrote:

Sorry, not follow the price argument. You are only charged for the nodes you use on a Kubernetes cluster (no Masters, no matter cluster size).

I don't understand very well "no matter cluster size" whereas no one has ever talked about creating nodes that will not be used later. In my example every node will be used and of course I will be charged the cost, making the cluster size very important to define total spending

Yes, but that you can use the same instances either on one cluster or two. One 60gb and the other(s) N gb, right?

 

So, I really don't why it makes a difference the number of clusters

what I mean is very simple:
if I have to use a single cluster, the minimum hardware features must be able to bear db requirements.
My db must have 60 GB of RAM.
So every node in this cluster will have 60 gb.

Ohh, okay. I think this is the confusion. No, not every node of your cluster must be the same size. You don't need every node to have 60gb.

I'm quite sure (don't use gke, though) You can use several instance groups, each one with the number of instances you want, the size you want. All in the same Kubernetes cluster.

[Rodrigo Campos]

On Wednesday, December 13, 2017, Gmail <mder...@gmail.com> wrote:

Can't you use an internal load balancer to communicate?

I noticed that if I create a load balancer service or an ingress service, Kubernetes will create a public ip address.
So when you say internal load balancer, what are you referring to?
Because I tried to use a nodeport service to communicate between cluster and didn't work

My reference was to this: https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing

Shouldn't that do the trick?

[Tim Hockin]

On Wed, Dec 13, 2017 at 6:47 AM, Gmail <mder...@gmail.com> wrote:
> Sorry, not follow the price argument. You are only charged for the nodes you
> use on a Kubernetes cluster (no Masters, no matter cluster size).
>
>
> I don't understand very well "no matter cluster size" whereas no one has
> ever talked about creating nodes that will not be used later. In my example
> every node will be used and of course I will be charged the cost, making the
> cluster size very important to define total spending
>
>
> So, I really don't why it makes a difference the number of clusters
>
> what I mean is very simple:
> if I have to use a single cluster, the minimum hardware features must be
> able to bear db requirements.
> My db must have 60 GB of RAM.
> So every node in this cluster will have 60 gb.

Not true. You can add many NodePools to a single cluster, each with a
different shape. Resource scheduling will ensure that your DB lands
on a big machine, and smaller jobs fit in wherever they can.

> I can spend 1000$/month so I can afford two nodes.
> One node will be for db, the other will be used for many (8-10-6 I don't
> know) web pod
> So I'm asking
>
> in terms of performance, scalability and stability which is the better
> solution between:
>
>
> a single cluster with 2 nodes where 1 node is used for db and other for n
> web-pod
>
> or
>
> (considering that the requirements of the db machine are very different from
> those of the web machines) two clusters, one for db (n1-standard-16 single
> node) and another for web machines (with more n1-standard-2 nodes)

I think you are always better off with more nodes of smaller size,
though I wouldn't go artificially small. 2 cores or 4 cores give you
a lot of freedom, unless you need to run pods that just do not fit,
and they give you better availability properties.

[Gmail]

> Ohh, okay. I think this is the confusion. No, not every node of your
> cluster must be the same size. You don't need every node to have 60gb.
>
> I'm quite sure (don't use gke, though) You can use several instance
> groups, each one with the number of instances you want, the size you
> want. All in the same Kubernetes cluster.

ah ok sorry I didn't know.. that's why we were not understanding :)
So I have to check how create a single cluster with more groups with
different sizes or how to add ...

> ... many NodePools to a single cluster, each with a
> different shape.

> My reference was to this:
> https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing

yes it could be the perfect solution with 2 different clusters. I'm
going to study how it works

> I think you are always better off with more nodes of smaller size,
> though I wouldn't go artificially small. 2 cores or 4 cores give you
> a lot of freedom, unless you need to run pods that just do not fit,
> and they give you better availability properties.

I think the same thing too

Many thanks!

Marco




Il 13/12/2017 17:31, 'Tim Hockin' via Kubernetes user discussion and Q&A
ha scritto: