Charts: [stable/traefik] : running on minikube

[arunkjn]

Is this a request for help?:

help

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT

Version of Helm and Kubernetes:
helm :
Client: &version.Version{SemVer:"v2.6.0", GitCommit:"5bc7c619f85d74702e810a8325e0a24f729aa11a", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.6.0", GitCommit:"5bc7c619f85d74702e810a8325e0a24f729aa11a", GitTreeState:"clean"}
kubernetes : v1.6.4 running in minikube v0.20.0

Which chart:
stable/traefik

What happened:
I tried to install traefik on minikube. I changed the service type to NodePort in values.yaml. Also I used traefik.local as the domain for dasboard ingress. Opening traefik.local/ in browser gives ERR_CONNECTION_REFUSED on chrome

What you expected to happen:
Using traefik.local in browser should open traefik dashboard

How to reproduce it (as minimally and precisely as possible):
install minikube
add traefik.local 192.168.99.100 to /etc/hosts
run helm init to install tiller
helm install stable/traefik --values=values.yaml
Use this values config file

Anything else we need to know:

[krancour]

I think there's an error in your expectations. Requesting traefik.local in your browser is implicitly requesting http://traefik.local:80 (port 80). The port that the service is mapped to on the minikube VM is almost certainly not port 80.

[arunkjn]

ok I get it. the node port should be in the range 30000-32767 for minikube. But, the same logic goes for that port range. Currently the configuration does not allow for a nodePort mapping for a service of type NodePort. If I change the service type to NodePort then a random nodePort is assigned.

[krancour]

But, the same logic goes for that port range. Currently the configuration does not allow for a nodePort mapping for a service of type NodePort. If I change the service type to NodePort then a random nodePort is assigned.

Yes. That _is_ a problem.

The common solution I have seen to this is the addition of the following to values.yaml:

## Further configuration for services of type NodePort
nodePort:
  ## Available port in allowable range (e.g. 30000 - 32767 on minikube)
  ## The endpoint will be exposed here
  port: 30080

And then a change like this in the Service definition:

{{- if eq .Values.serviceType "NodePort" }}
  nodePort: {{ .Values.nodePort.port }}
{{- end }}

I'd definitely LGTM (I'm a reviewer for this particular chart) if you would like to PR that change.

[arunkjn]

surely would do that! PR coming its way!

[kachkaev]

Being able to set up a specific port for NodePort would be really useful. How about supporting a custom port for the https endpoint too? It's unlikely to be used in minikube, but can be handy in small production envs.

I have a single-VM k8s cluster built with kubeadm, where I map traefik's ports 80 and 443 directly to the host's port. In order to do that, I configure the port range to 80-10000 when creating the cluster and then manually change the assigned ports once traefik is up. The benefit of this is that you no longer need a load balancer, which makes it easier and cheaper to host a few tiny personal projects. Right now my workflow is the following:

echo "
serviceType: NodePort
# ... other stuff
" > /tmp/values.yaml

## install
helm install --name=traefik stable/traefik --values /tmp/values.yaml

## manually change service's nodePort to 80 and 443;
## (only needed on a mini kubeadm cluster, not a kops one behind the LB)
kubectl edit service traefik-traefik

With the fixed port definitions for http and https endpoints, the last step can be omitted.

[krancour]

Being able to set up a specific port for NodePort would be really useful. How about supporting a custom port for the https endpoint too? It's unlikely to be used in minikube, but can be handy in small production envs.

With that in mind, I'd amend my suggestion to this:

## Further configuration for services of type NodePort
nodePort:
  ## Available port in allowable range (e.g. 30000 - 32767 on minikube)
  ## The endpoint will be exposed here
  port: 30080
  securePort: 30443

[kachkaev]

How about these names?

nodePort: 30000 # (undefined by default)
tls.nodePort: 30443 # (undefined by default)

Three reasons:

• LoadBalancer's options are flat (i.e. loadBalancerIP, loadBalancerSourceRanges insteaed of loadBalancer.*)
• nodePort may be used in LoadBalancer service type too
• tls.nodePort makes sense since all other tls options are in this group too

Both options should be undefined by default because otherwise this may cause port collisions. Only those who know what they are doing will benefit from the pre-defined port numbers.

[krancour]

LoadBalancer's options are flat (i.e. loadBalancerIP, loadBalancerSourceRanges insteaed of loadBalancer.*)

That's only because there wasn't sufficient foresight to have a loadBalancer section with multiple settings underneath. Ideally, it would have been done differently, but of course, no one wanted to break anything as options got added.

What I'd suggest is that we look at whatever conventions are used by other charts for addressing this common problem and we adopt those same conventions.

[kachkaev]

If the naming you suggest is in line with other charts, I support your option too. I haven't got a lot of experience with many charts and so justify the design in some sort of isolation.

What do you think of starting a meta issue with a list of debt being around? So that it was easy to find what to do once it's a good time for chart version 2.0.

[krancour]

@kachkaev yes... start a meta-issue.

Re: convention used by other charts, let's research it.

[arunkjn]

I referred some other chart configs. They all seem to support nesting nodePort under the parent entity. Posting a few for reference. The last link for nginx is directly relevant to us.

https://github.com/kubernetes/charts/blob/2e62901584bcfc883db7849c1fe0e2a457933317/stable/grafana/templates/svc.yaml
https://github.com/kubernetes/charts/blob/f6b1817962b45deda6b9d4f05c3774bad94281c1/stable/risk-advisor/templates/service.yaml
https://github.com/kubernetes/charts/blob/d39f1140849f2ad7244e143264b327d1d2d2b658/stable/jenkins/templates/jenkins-master-svc.yaml
https://github.com/kubernetes/charts/blob/cc6916ff6d1799e1e9208c5d5a0513d06d2c8179/stable/centrifugo/templates/service.yaml
https://github.com/kubernetes/charts/blob/54f070577bdb0a8b11687da91e9e08d84aab2020/stable/nginx-ingress/templates/controller-service.yaml

[arunkjn]

How about this-

service:
  # can switch the service type to NodePort if required
  type: LoadBalancer
  loadBalancerIP:
  # loadBalancerSourceRanges: []
  ## Useful to configure for service of type NodePort to get a specific nodePort
  ## Available port in allowable range (eg. 30000 - 32767 on minikube)
  # nodePorts:
  #   http: 31000
  #   https: 32000

[arunkjn]

I have sent a PR for the same #2106

[arunkjn]

@krancour What is the process to submit a new chart to this repo? I wanted to make a chart for apache ignite and share with the community.

[krancour]

@arunkjn no special process, afaik. (I've been deputized to do code reviews for this particular chart since I'm its original author, but I'm not a maintainer for this repo.) Just go ahead an PR it.

If you're new to writing charts from scratch, this command can help you get going:

$ helm create <new chart name>

This will create a directory for you containing a skeleton for a new chart.

Here's the guidance from Helm's own docs on how to write good charts:

https://docs.helm.sh/developing_charts/

[Catorpilor]

@arunkjn I ran into the same problem. #2106 fix this? Since this PR is not merged, what should I do to access traefik ui from a browser?

[arunkjn]

yes @Catorpilor #2106 is supposed to address this. For now you can manually amend those changes in your chart locally.

[krancour]

For now you can manually amend those changes in your chart locally.

Don't overcomplicate things. Why not just pull the branch that #2106 was opened from?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale