Problems with Kong installation via Helm Chart 2.38.0

[kartef]

Is there an existing issue for this?

• I have searched the existing issues

Kong version ($ kong version)

3.6

Current Behavior

After installing Kong with the latest Helm Chart, I'm receiving the following error message:

info setup Retrying Kong admin API client call after error {"v"d"}: 0, "retries": "41/60", "error": "making HTTP request: Get "https://localhost:8444/\": dia: 0, "retries": "41/60", "error": "making HTl tcp [::1]:8444: connect: connection refused"}

The installation with Helm Chart version 2.29.0 with same values.yaml works without any problems. I've noticed there was a similar issue reported in #10334, but the PR couldn't help me with that.

The used values.yaml file.:

deployment:
  daemonset: true
#
containerSecurityContext:
  capabilities:
    add: [NET_BIND_SERVICE]
  runAsGroup: 0
  runAsNonRoot: false
  runAsUser: 0
env:
  nginx_http_large_client_header_buffers: 4 32k
  trusted_ips: ...
proxy:
  stream:
  - #
    containerPort: 9000
    servicePort: 9000
    protocol: TCP
  # TLS
  - #
    containerPort: 9443
    servicePort: 9443
    protocol: TCP
    parameters: [ssl]
resources:
  limits:
    cpu: 0.5
    memory: 2Gi
  requests:
    cpu: 0.02
    memory: 700Mi

Expected Behavior

No response

Steps To Reproduce

helm repo add kong https://charts.konghq.com
helm repo update
helm install kong kong/kong -n kong -f values.yaml

Anything else?

No response

[xorduna]

Hi,

I am having the same problem. It worked perfectly one year ago with an older version of the chart.

Couple of things I found:

• When passing only this configuration (without the runAsUser:0 and runAsGroup:0):

containerSecurityContext: # run as root to bind to lower ports
  capabilities:
    add: [NET_BIND_SERVICE]
  runAsNonRoot: false

It starts and works, but when I patch the service manually to enable the stream (this was how it was described to be done in previous versions) then, the pod is restarted and the same error is thrown again.

• Tried to enable the AdminAPI with:

admin:
  enabled: true

But it does not work. In fact I don't see anything started.

What I don't understand is that if you install kong without this configuration, it does not checks for this API ...

Any clue?

[xorduna]

After some digging, there is a containerSecurityContext.capabilities.drop: [ ALL ] in the default values.yaml that conflicts with your configuration.

If you change this to:

containerSecurityContext:
  capabilities:
    add: [NET_BIND_SERVICE]
    drop: []
  runAsGroup: 0
  runAsNonRoot: false
  runAsUser: 0

Fixed the problem for me.

[github-actions]

This issue is marked as stale because it has been open for 14 days with no activity.