Hosting Chronograf on Kubernetes

[isehuetdk]

Trying to host Chronograf on Kubernetes behind a NGINX ingress controller that runs on https://k8sURL/chronograf/. Running on version 1.8.7 using port 8888 on the application, chronograf service is running on 8080 and pointing to targetPort 8888 of the application.

apiVersion: v1
kind: Service
metadata:
  name: chronograf-svc
  namespace: testenv
spec:
  type: ClusterIP
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8888
  selector:
    app: chronograf

Ingress controller to the service is configured as below:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: chronograf-ingress-qa
  namespace: testenv
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  tls:
  - hosts:
    - k8sFQDN
    secretName: aks-ingress-tls
  rules:
  - host: k8sFQDN
    http:
      paths:
      - backend:
          serviceName: chronograf-svc
          servicePort: 8080
        path: /chronograf/(.*)

I mounted a ConfigMap as below in the Deployment.

          volumeMounts:
          - mountPath: "/etc/default"
            name: chronograf-config
      volumes:
        - name: chronograf-config
          configMap:
            name: chronograf-config

The ConfigMap includes some parameters: data:

  chronograf: |
    HOST=127.0.0.1
    BASE_PATH=/chronograf
    PUBLIC_URL=https://k8sFQDN/chronograf/

When checking cat /etc/default/..data/chronograf, I can see that the variables from the ConfigMap are set correctly. But when checking through chronograf CLI, I can see that it is throwing this error, using the wrong IP address.

level=error msg="listen tcp 0.0.0.0:8888: bind: address already in use" component=server

As if the /etc/default/chronograf setting is not applied to the server. I can thus also not browse through https://k8sFQDN/chronograf/, just getting a blank white page.

Any idea?

[rdxmb]

As this is not an issue like a bug or a feature request this should be closed. https://community.influxdata.com/ should be the right way for support.

Using HOST=127.0.0.1 does never work behind a cluster ip at all. Use 0.0.0.0 instead, for your traffic will be natted.