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:
On Wed, Dec 13, 2017 at 6:47 AM, Gmail <[email protected]> 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.
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
Il 13/12/2017 13:56, Rodrigo Campos ha scritto:
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
On Wednesday, December 13, 2017, <[email protected]> wrote:
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 :)
Il giorno martedì 12 dicembre 2017 23:00:10 UTC+1, David Rosenstrauch ha
scritto:
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
--
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 [email protected].
To post to this group, send email to [email protected].
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
[email protected].
To post to this group, send email to [email protected].
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 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 [email protected].
To post to this group, send email to [email protected].
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 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.
