Skip to content
This repository has been archived by the owner on May 16, 2023. It is now read-only.

Adding Example for Kubernetes KIND #274

Merged
merged 3 commits into from
Oct 11, 2019
Merged

Adding Example for Kubernetes KIND #274

merged 3 commits into from
Oct 11, 2019

Conversation

salaboy
Copy link
Contributor

@salaboy salaboy commented Sep 10, 2019

  • Chart version not bumped (the versions are all bumped and released at the same time)
  • [x ] README.md updated with any new values or changes
  • Updated template tests in ${CHART}/tests/*.py
  • Updated integration tests in ${CHART}/examples/*/test/goss.yaml

This PR adds support for running elastic for development purposes on Kubernetes KIND (https://github.com/kubernetes-sigs/kind) which for some reason require the directory to be created before using it for elasticsearch data. Hence the use of an initContainer.

@elasticmachine
Copy link
Collaborator

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

Copy link
Contributor

@Crazybus Crazybus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had one question but the rest LGTM!

resources:
requests:
storage: 100M
extraInitContainers: |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you explain why these extra init containers are needed for a kind deployment? The chart is already correctly setting the permissions and the elasticsearch process should be creating those directories.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Crazybus yeah.. that is needed for KIND.. for some reason the container doesn't create that by default and the whole deployment was failing. You can give it a try and see if you find the reason why the container is failing to do so.. I couldn't see anything in the logs except for an exception saying that it didn't had access to write the files in the /usr/share/elasticsearch/data/nodes/ directory. Once the directory is created, everything works as expected.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I'll certainly give it a go to see if I can reproduce it. Seems like a bit of a shame that kind doesn't seem to be compatible with the way that normal kubernetes works though :(. It makes sense that resources and node anti affinity need to be relaxed but this makes it impossible to properly test with kind.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be super straight forward to reproduce it and find the cause if you can debug the ElasticSearch container. But for now that is needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Crazybus also I notice that for KIND this is required: storageClassName: "standard"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry that I haven't gotten around to testing this out just yet. Did you also try just leaving storageClassName out completely? That should just use whatever the default is set to which is probably "standard"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that is true.. I am removing that line completely

@jmlrt
Copy link
Member

jmlrt commented Oct 11, 2019

jenkins test this please

Copy link
Member

@jmlrt jmlrt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jmlrt jmlrt merged commit 6533c9a into elastic:master Oct 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants