beeinventor / charts Goto Github PK

Hi @benjamin658

I believe there is a small issue in the service definition of NSQD.

There is no HTTP protocol port. Only SCTP, TCP, UDP are supported in a kubernetes svc.

spec:
  type: {{ .Values.nsqd.service.type }}
  ports:
  - name: http
    port: 4151
    targetPort: http
    protocol: HTTP <== to change to TCP
  - name: tcp
    port: 4150
    protocol: TCP
    targetPort: tcp

Cheers.

Hello @benjamin658

This is not a bug, but probably an enhancement we can do to nsqadmin.

What basically happens when you install the chart, nsqadmin is the first candidate that quickly get fetched and when the container run, it output the following error:

[nsqadmin] 2021/08/18 09:32:32.771223 FATAL: failed to instantiate nsqadmin -
failed to resolve --lookupd-http-address (jupiter-nsqlookupd-0.jupiter-nsqlookupd:4161) -
lookup jupiter-nsqlookupd-0.jupiter-nsqlookupd on 10.96.0.10:53: no such host

Then it get restarted for few times until nsqlookupd is ready, then it starts. It looks a bit ugly to see that the container has crashed few times.

This is normal because nsqadmin does not wait for lookupd to start. I have this problem anytime I have a container which depends on another one. The way I get arround this is by adding an side car container that wait for the dependency to show up. Something like this:

initContainers:
  - name: wait-for-db
    image: groundnuty/k8s-wait-for:v1.3
    imagePullPolicy: Always
    args:
      - "pod"
        - "-lapp=mysql"

Not sure if this is the best way to do it :)

Cheers.

I noticed a bug here https://github.com/BeeInventor/charts/blob/main/beeinventor/nsq/templates/nsqd-statefulset.yaml#L43-L46 and here https://github.com/BeeInventor/charts/blob/main/beeinventor/nsq/templates/nsqd-statefulset.yaml#L43-L46

the nsqlookupd DNS results to nsq-nsqlookupd-0.nsq-nsqlookupd:4160 in my case (with helm release name nsq).
The DNS is wrong.

Instead of repeating the lookup address for each replica, you should address the service, which balances over the replicas anyways.

I was able to workaround by doing

      - nsqd:
          extraArgs:
            - "--lookupd-tcp-address=nsq-nsqlookupd:4160"
..

      - nsqadmin:
          extraArgs:
            - "--lookupd-http-address=nsq-nsqlookupd:4161" # chart has a bug and inserts wrong dns name
..

however this only adds the correct address but I cannot override the original args, which leaves errors in logs as is still tries to also call the wrong one

It would be nice if the chart was less opinionated and allowed the user to decide if they need to implement a sidecar pattern - maybe have it defaulted to the current behavior but allow enabling a couple of nsqd instances. The pattern is overkill in some prod environments and ci/cd pipelines and its unfortunate that this helm chart is not a complete deployment.

I am a newbie to NSQ. Our application currently needs to find the topic producer (nsq) through the nsqlookupd http port(4161);

I found that the nsqlookupd service address cannot be set in helm. Is this intentional or should I add this configuration?

Hello,

es-client-ingress.yaml and kibana-ingress.yml use a deprecated apiVersion=extensions/v1beta1 for Ingress object.
According to https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122 , Ingress will no longer be served in v1.22 of k8s .

Regards

just starting convo here, will submit pr. Need to add docs for nsqd to readme.

Additionally would like to add a couple of missing things to values.yaml for all nsq services:

• priorityClassName:
• extraArgs[]
• terminationMessagePolicy: FallbackToLogsOnError

Hi,

NSQ released a new version ! v.1.2.1.

We have a field normally to use a recent version of nsq but I was wondering if it would be good to bump the chart app version by default to this new release.

Cheers.

We've been using a fork of your nsq chart for sometime now that makes use of static hostPorts for tcp and http container ports as well as disables storage persistence as DaemonSet does not support persistentVolumes/volumeClaimTemplates.

Would you be interested in a PR that would add the ability to enable DaemonSet support of course keeping the default functionality of using a StatefulSet intact?

I suspect it is possible to make StatefulSet run in a similar way, dedicated one pod per node by making use of anti-affinity and nodeSelectors, but using a DaemonSet instead seems to be a decent alternative in our environment and can share if you are interested.

I'm using host_ip injected as a env variable to then be referenced in nsqd.args as a statsd endpoint. However I realize not everyone needs/wants this injected. Is there a way to make this easily configurable in the yaml?

Goal syntax would be something like:

container spec:

containers:
    env:
   {{- if .Values.env }}
   {{ toYaml .Values.env }}
   {{- end }}

values.yaml:

env:
- name: SOME_ENV
  value: someval 
- name: SOME_FIELD_ENV
  valueFrom:
      fieldRef:
          fieldPath: status.podIP 

When I try to use the above I get formatting errors and Invalid YAML: mapping values are not allowed in this context:. My yaml foo is lacking, do you have any suggestions for how to do this? I can submit a pr.