How would we use persistentDisk? about kubernetes-elasticsearch-cluster HOT 12 CLOSED

In case someone lands here looking for a workaround, I used the suggestion from @davidopp in kubernetes/kubernetes#3945: set a hostPort for the datanode pod. That prevents two instances of from being scheduled on the same node.

    ports:
    - containerPort: 65535
      name: anti-affinity
      hostPort: 65535

It is sub optimal because the anti-affinity port number needs to be unique for the pod template, but it avoids the need to match pod resources to node resources (I still want to run other pods on the node)

from kubernetes-elasticsearch-cluster.

I have a workaround for this that is related to kubernetes/kubernetes#3945 in the sense that we can limit the number of Elasticsearch data-nodes, which I think are the only ones needing to persist data, running on a minion. Sorry, node :-p

from kubernetes-elasticsearch-cluster.

we can limit the number of Elasticsearch data-nodes

Yes, by simply using replicas: 1. In what sense does kubernetes/kubernetes#3945 factor in here? Your issue seems a lot fancier because its about smart resource allocation wherein e.g. its impossible to schedule more than one pod per machine because e.g. it doesn't make sense for throughput.

So while we have "solution" with replicas: 1 its a very limiting one of course because we cannot scale that pod. The replicationController part is a lie for now : )

from kubernetes-elasticsearch-cluster.

I think we can set the number of replicas we wish. We just need a couple
things:

• nodeSelector for pods to be scheduled in specific machines marked with
  predefined labels
• set data-node pods resources (like ram) to match the VM allocated ram in
  a way that said machine can't hold more than one data-node.

This way you can have multiple data-nodes and as many replicas as machines
available.
On Feb 3, 2015 12:07 AM, "Jason Kuhrt" [email protected] wrote:

we can limit the number of Elasticsearch data-nodes

Yes, by simply using replicas: 1. In what sense does
kubernetes/kubernetes#3945
kubernetes/kubernetes#3945 factor in
here? Your issue seems a lot fancier because its about smart resource
allocation wherein e.g. its impossible to schedule more than one pod per
machine because e.g. it doesn't make sense for throughput.

So while we have "solution" with replicas: 1 its a very limiting one of
course because we cannot scale that pod. The replicationController part
is a lie for now : )

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

from kubernetes-elasticsearch-cluster.

Ok, I'm curious to see what you will come up with. I'm trying things on my fork and will share anything useful.

from kubernetes-elasticsearch-cluster.

You can see some issues I am running into with PD here: kubernetes/kubernetes#4052

from kubernetes-elasticsearch-cluster.

Has there been any solution to this problem? I can't figure out how to provide persistent storage for my Elasticsearch cluster, which makes it useless :(

from kubernetes-elasticsearch-cluster.

@mlamina this is not a bug so it doesn't need to be fixed. This is something that you, as an user, should change to match your environment. I can't force a volume setup other than the emptyDir nor can I support every possibility in existence. I urge you to learn about Kubernetes volume plug-ins and adapt the data node replicationController as you see fit.

from kubernetes-elasticsearch-cluster.

I understand that! Do you have a recommendation which scales with the ReplicationController? GCE PersistentDisk doesn't seem to work and I feel like setting up a GlusterFS cluster seems to be overkill?

from kubernetes-elasticsearch-cluster.

There are more plug-ins than those two. Choose what's best to your use-case.

from kubernetes-elasticsearch-cluster.

You can also try integration with flocker.

from kubernetes-elasticsearch-cluster.

I agree with you

from kubernetes-elasticsearch-cluster.