3 ms·

Maybe bc no one uses that in reality and use helm instead?

saynay 5y ago
Helm is useful if you need your software to run in many different places, and is widely known. This is why you see so many projects offering Helm charts; because you see them, they are set up to run in many environments. There is no reason to use it for your own software if you just have a single cluster.
- voidfunc 5y ago
  Helms a pile of garbage but this isn’t really the fault of Helm. This is an issue with the chart or a failure to read the documentation of the chart. People have got to stop just blindly running stuff off the internet.
- coredog64 5y ago
  At a previous employer, they’re building k8s clusters not for developers but for their infrastructure teams. In the past, where a vendor might have supplied an OVF file as the distributable product, they’re now providing Helm charts.
indigochill 5y ago
I'll take that "no one" badge. I've never used Helm, always used kubectl. Well, until now, when I'm using Terraform (particularly helpful relative to kubectl when I need to provision cloud resources directly), but I've still never used Helm.
cassianoleal 5y ago
That's a very odd and factually wrong generalisation. I don't use helm at all, and I manage a large scale platform built on Kubernetes. Everything is either declared directly in YAMLs and deployed with `kubectl apply -f <YAMLs or directory containing them>`, or rendered using Kustomize and, again, deployed using `kubectl apply -f -`. Kustomize can be rough around the edges but it's predictable and I can easily render the YAMLs locally for troubleshooting and investigating.
rad_gruchalski 5y ago
That’s an organisational problem, not Kubernetes problem.
ninkendo 5y ago
The first time I used helm was to set up JenkinsCI on a k8s cluster on AWS, and in the default configuration, it setup a public-internet ELB listener (with type=LoadBalancer) for Jenkins' internal JNLP port. Which pretty much means the public internet has root access to your jenkins cluster, by default. I had crypto miners using my k8s cluster within a couple of hours. That was also the last time I used helm.
- SirMonkey 5y ago
  You mean the helm-package you installed without reading the documentation? Hate the player, not the game.
  - ninkendo 5y ago
    No. No, no no. This was legitimate a bug that they immediately fixed when I reported it... There is no legitimate reason to expose the master JNLP port to the internet, ever. The chart did not have a configuration option for this, it just exposed the JNLP port as part of the same k8s Service that exposed the web port. (The JNLP port is for jenkins workers to phone back home to the main instance, it's not for external use.) "Just read the docs" is not an answer to a chart setup which is just plain broken.
    - deleted 5y ago
      [deleted]
lukebuehler 5y ago
Also, there is the middle way: kustomize. It's built into kubectl
p_l 5y ago
I have yet to work in any environment where helm was used heavily and not just for few okne offs setup long ago and that now bring regrets.

Helm is useful if you need your software to run in many different places, and is widely known. This is why you see so many projects offering Helm charts; because you see them, they are set up to run in many environments. There is no reason to use it for your own software if you just have a single cluster.

voidfunc 5y ago
Helms a pile of garbage but this isn’t really the fault of Helm. This is an issue with the chart or a failure to read the documentation of the chart. People have got to stop just blindly running stuff off the internet.
coredog64 5y ago
At a previous employer, they’re building k8s clusters not for developers but for their infrastructure teams. In the past, where a vendor might have supplied an OVF file as the distributable product, they’re now providing Helm charts.

indigochill 5y ago

I'll take that "no one" badge. I've never used Helm, always used kubectl. Well, until now, when I'm using Terraform (particularly helpful relative to kubectl when I need to provision cloud resources directly), but I've still never used Helm.

cassianoleal 5y ago

That's a very odd and factually wrong generalisation. I don't use helm at all, and I manage a large scale platform built on Kubernetes. Everything is either declared directly in YAMLs and deployed with `kubectl apply -f <YAMLs or directory containing them>`, or rendered using Kustomize and, again, deployed using `kubectl apply -f -`. Kustomize can be rough around the edges but it's predictable and I can easily render the YAMLs locally for troubleshooting and investigating.

rad_gruchalski 5y ago

That’s an organisational problem, not Kubernetes problem.

ninkendo 5y ago

The first time I used helm was to set up JenkinsCI on a k8s cluster on AWS, and in the default configuration, it setup a public-internet ELB listener (with type=LoadBalancer) for Jenkins' internal JNLP port. Which pretty much means the public internet has root access to your jenkins cluster, by default. I had crypto miners using my k8s cluster within a couple of hours. That was also the last time I used helm.

SirMonkey 5y ago
You mean the helm-package you installed without reading the documentation? Hate the player, not the game.
- ninkendo 5y ago
  No. No, no no. This was legitimate a bug that they immediately fixed when I reported it... There is no legitimate reason to expose the master JNLP port to the internet, ever. The chart did not have a configuration option for this, it just exposed the JNLP port as part of the same k8s Service that exposed the web port. (The JNLP port is for jenkins workers to phone back home to the main instance, it's not for external use.) "Just read the docs" is not an answer to a chart setup which is just plain broken.
  - deleted 5y ago
    [deleted]

lukebuehler 5y ago

Also, there is the middle way: kustomize. It's built into kubectl

p_l 5y ago

I have yet to work in any environment where helm was used heavily and not just for few okne offs setup long ago and that now bring regrets.