-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support helm install for k3s and minikube without a values override to use 1 replica for Consul server #1234
Comments
One should be seriously questioned who broke this consul chart!. We aren't talking about some unmanaged/unpopular/random chart. We are using the "official" hem chart for consul and guess what, it is broken!! |
Hi @pankaj-dahiya thanks for filing this issue and I'm sorry that you're running into trouble using it.
In this case our default installation attempts to install a 3 server replica Consul cluster and due to podAntiAffinity rules 2 of the server pods are unable to be scheduled. [link to values.yaml explaining the behaviour] You can find more information about this behaviour under the I see in your logs that you are also running on a single node in which case you should see the same problem: The following command should get you up and running:
If that does not work we'd be happy to help out, in which case could you please also attach any custom changes to the helm chart or values.yaml overrides along with logs of the servers and output from Thanks! |
Okay, got it. But I guess the default should be 1 with a recommendation to 3. So that the chart should always run with default values.yaml and any number of nodes. |
Hi @pankaj-dahiya we do have 1 replicas set for our examples with Minikube as shown here: https://learn.hashicorp.com/tutorials/consul/kubernetes-minikube#create-a-values-file. Could you tell me a little more about your environment you are installing on (we do ask that you provide some more details about your environment in our issue template)? I believe it's tricky to determine the actual environment you are installing on by just using Helm so you would need to know ahead of time that this is perhaps a demo environment and tune the values file appropriately. We do want to default to 3 because that is how we recommend running servers in production. How could we make the guidance for turning replicas to 1 more discoverable for you? |
Well under this line- Write in bold - This helm chart will fail in less than 3 nodes cluster while using default values so ditch this and start using bitnami helm chart! See, sarcasm apart, a helm chart should be able to run in as many environments with its default values. So rather than defaulting "3" as replica set values, "1" is better with a recommendation of using at least 3 for production. Because this is damn obvious that some DevOps employee running this chart in the production environment will be increasing the replica sets and even if he forgot to do so, then it is not a bit task to increase the replica set number. |
I agree your point of the default experience on k3s (which is your environment) or minikube is less than optimal without a value overrides file that specifies 1 replica, and most folks that want to try out the initial experience my try things out locally. Just for completeness it does sound like your method of discovery for installation steps would be targeted to the README. |
Hi @pankaj-dahiya we'll be defaulting to 1 server replica in a future release. Thanks for your patience on this one, and I do agree that it is a better getting started experience for users. This will be a breaking change so will happen in time with our next major Consul release. |
Closing as is addressed by #1551 |
Just two steps -
Error logs:
The text was updated successfully, but these errors were encountered: