Kong Manager via Helm

I’m trying to get Kong Manger working on my development cluster. I’m installing via Helm and my values override file is:
nodeSelector:
kubernetes.io/os: linux
replicaCount: 2
ingressController:
enabled: true
installCRDs: false
env:
plugins: bundled
admin_gui_url: http://manager
admin_listen: 0.0.0.0:8001
admin_gui-listen: 0.0.0.0:8002
lua_package_path: /opt/?.lua;;
prefix: /kong_prefix/
database: “postgres”
pg_host:
valueFrom:
secretKeyRef:
key: host
name: kong-settings
pg_user:
valueFrom:
secretKeyRef:
key: user
name: kong-settings
pg_password:
valueFrom:
secretKeyRef:
key: secret
name: kong-settings
pg_database:
valueFrom:
secretKeyRef:
key: name
name: kong-settings
pg_ssl: “on”
nginx_proxy_proxy_buffer_size: 160k
nginx_proxy_proxy_buffers: 64 160k
proxy:
externalTrafficPolicy: Local
podSecurityPolicy:
readOnlyRootFilesystem: false
admin:
enabled: true
http:
enabled: true
tls:
# Enable HTTPS listen for the admin API
enabled: false
enterprise:
enabled: true
manager:
enabled: true
http:
enabled: true
servicePort: 8002
containerPort: 8002
ingress:
enabled: true
hostname: manager
annotations:
kubernetes.io/ingress.class: “kong”
path: /
tls:
enabled: false

Install complete however I always get:
{
“message”:“An invalid response was received from the upstream server”
}

when try to access Manager via browser.

What am I missing?

Any difference if you remove the various _listen settings from your env? Those and the various Service/Deployment/Ingress ports are normally set up automatically when you set admin.enabled=true and so on. What you have shouldn’t cause issues, but it might.

If not, do you see anything of interest with env.admin_gui_error_log = /dev/stderr and doing kubectl port-forward to port 8002? Bypassing the proxy should hopefully make it a bit clearer what kind of broken response you’re seeing.

Doesn’t make any difference and port forwarding is throwing
Handling connection for 8002
E1220 22:14:06.886453 76728 portforward.go:400] an error occurred forwarding 8002 → 8002: error forwarding port 8002 to pod 32857a9e972e5e4edf64a7019a8395099dbbdd3614f2f6a31eeebdfe61d069a1, uid : failed to execute portforward in network namespace “/var/run/netns/cni-87e43c8d-2122-f812-420b-922587cc36f0”: failed to dial 8002: dial tcp4 127.0.0.1:8002: connect: connection refused
Handling connection for 8002
E1220 22:15:04.755167 76728 portforward.go:340] error creating error stream for port 8002 → 8002: Timeout occurred
Handling connection for 8002

I created a new Kubernetes cluster and performed a fresh install using:
nodeSelector:
kubernetes.io/os: linux
replicaCount: 2
ingressController:
enabled: true
installCRDs: false
env:
plugins: bundled #,oidc
lua_package_path: /opt/?.lua;;
prefix: /kong_prefix/
admin_gui_error_log: /dev/stderr
nginx_proxy_proxy_buffer_size: 160k
nginx_proxy_proxy_buffers: 64 160k
proxy:
externalTrafficPolicy: Local
podSecurityPolicy:
readOnlyRootFilesystem: false
admin:
enabled: true
http:
enabled: true
tls:
enabled: false
enterprise:
enabled: true
portal:
enabled: false
portalapi:
enabled: false

Still doesn’t work nothing in the stderr

What should be running in the Kong Pod I see only ingress-controller and Proxy where does manager run?

Still nothing any other ideas?

That’d indicate it isn’t listening at all. Manager (and everything other the controller) run in the proxy container. I think your issue is that you haven’t changed the image settings, so you’re still using the default OSS image, which doesn’t include Manager.

You’ll want to switch that over to the Enterprise kong-gateway image to use Manager in Enterprise free mode:

(note that we haven’t bumped the version there just yet; 2.7.0.0 is now available).

Hey @traines ,
I tried changing the repository image to

image:
  #repository: kong
  #tag: "2.7"
  # Kong Enterprise
  repository: kong/kong-gateway
  tag: "2.7.0.0"
  # 2.7  also tried with this tag

The pods are coming up fine and on accessing the kong-manager UI through ELB the UI loads as well.
But the create workspace button is greyed out.

According to the link - Kong Gateway - v2.8.x | Kong Docs
Based on the link info how do i create/delete services/routes/plugins etc through the Manager ?

What am i missing here ?
Kindly help me out. !!

I believe that’s a limitation of free mode, though Kong Gateway Licensing - v2.8.x | Kong Docs doesn’t mention it.

The default workspace is always available, however, you don’t need to create it and should be able to follow Expose your Services with Kong Gateway - v2.8.x | Kong Docs without adding a new workspace.

Hey,
Even as this link suggests , it still says we should be able to access kong manager in free mode , only that the enterprise features like vitals/dev-portal might be disabled…
Still basic functionality of viewing / adding services and routes with interaction with admin api is possible in free mode.

But when i load my UI , the workspace tab is greyed out…
even not able to create svc or routes.

The network console goes red on kong calls… where its routing to
http://kong-manager-ELB:8001/default etc…

Also in values.yml env section i have changed -

admin_gui_url: "http://ELB-kong-managerservice:80"
admin_api_uri: "http://ELB-kong-managerservice:80"

Now the Ui looks like this -

No error’s in the network trace, but these are the console errors attached.

Also /default or /default/kong gives a blank screen…

Is there anything i have missed in the admin api connection section .
below is my config:

env:
  #DB CONFIG START
  database: "postgres"
  pg_host: postgres.kong.svc.cluster.local
  pg_port: 5432
  pg_user: ****
  pg_password: ****
  pg_database: kong
  pg_ssl: "off"
  pg_ssl_verify: "off"
  #password: "kongpwd"
  #DB Config END
  #GUI Configuration
  #admin_listen: "0.0.0.0:8001 http2"
  #admin_gui_listen: "0.0.0.0:8001 http2"
  #admin_gui_url: "http://kong-kong-manager.kong.svc.cluster.local:80"
  admin_gui_url: "http://kong-manager-ELB:80"
  #admin_api_uri: "http://kong-kong-admin.kong.svc.cluster.local:8001"
  admin_api_uri: "http://kong-manager-ELB:80"
  #GUI Configuration END
  enforce_rbac: "on"
  admin_gui_auth: enabled
  admin_gui_auth: "basic-auth"
  nginx_worker_processes: "2"
  proxy_access_log: /dev/stdout
  admin_access_log: /dev/stdout
  admin_gui_access_log: /dev/stdout
  portal_api_access_log: /dev/stdout
  proxy_error_log: /dev/stderr
  admin_error_log: /dev/stderr
  admin_gui_error_log: /dev/stderr
  portal_api_error_log: /dev/stderr
  prefix: /kong_prefix/


manager:
  # Enable creating a Kubernetes service for Kong Manager
  enabled: true
  type: LoadBalancer
  # To specify annotations or labels for the Manager service, add them to the respective
  # "annotations" or "labels" dictionaries below.
  annotations: {}
  #  service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
  labels: {}

  http:
    # Enable plaintext HTTP listen for Kong Manager
    enabled: true
    servicePort: 80
    containerPort: 8002
    # Set a nodePort which is available if service type is NodePort
    # nodePort: 32080
    # Additional listen parameters, e.g. "reuseport", "backlog=16384"
    parameters: []

  tls:
    # Enable HTTPS listen for Kong Manager
    enabled: true
    servicePort: 443
    containerPort: 8445
    # Set a nodePort which is available if service type is NodePort
    # nodePort: 32443
    # Additional listen parameters, e.g. "reuseport", "backlog=16384"
    parameters:
    - http2
admin:
  # Enable creating a Kubernetes service for the admin API
  # Disabling this is recommended for most ingress controller configurations
  # Enterprise users that wish to use Kong Manager with the controller should enable this
  enabled: true
  type: ClusterIP
  # To specify annotations or labels for the admin service, add them to the respective
  # "annotations" or "labels" dictionaries below.
  annotations: {}
  #  service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
  labels: {}

  http:
    # Enable plaintext HTTP listen for the admin API
    # Disabling this and using a TLS listen only is recommended for most configuration
    enabled: true
    servicePort: 8001
    containerPort: 8001
    # Set a nodePort which is available if service type is NodePort
    # nodePort: 32080
    # Additional listen parameters, e.g. "reuseport", "backlog=16384"
    parameters: []

  tls:
    # Enable HTTPS listen for the admin API
    enabled: true
    servicePort: 8444
enterprise:
  enabled: true
  # Kong Enterprise license secret name
  # This secret must contain a single 'license' key, containing your base64-encoded license data
  # The license secret is required to unlock all Enterprise features. If you omit it,
  # Kong will run in free mode, with some Enterprise features disabled.
  # license_secret: kong-enterprise-license
  vitals:
    enabled: true
  portal:
    enabled: false
  rbac:
    enabled: true
    admin_gui_auth: basic-auth
    # If RBAC is enabled, this Secret must contain an admin_gui_session_conf key
    # The key value must be a secret configuration, following the example at
    # https://docs.konghq.com/enterprise/latest/kong-manager/authentication/sessions
    session_conf_secret: kong-session-config
    # If admin_gui_auth is not set to basic-auth, provide a secret name which
    # has an admin_gui_auth_conf key containing the plugin config JSON
    admin_gui_auth_conf_secret: CHANGEME-admin-gui-auth-conf-secret

What could i be possibly missing here?
If i change the admin_gui_listen: “0.0.0.0:80 http2” kong pod logs show permission denied error
waiting for db

Error: nginx configuration is invalid (exit code 1):
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /tmp/tmp.aBIIbN/nginx.conf:6
nginx: the configuration file /tmp/tmp.aBIIbN/nginx.conf syntax is ok
nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)
nginx: configuration file /tmp/tmp.aBIIbN/nginx.conf test failed

Does /default/routes work? Can you indeed access the admin API if you access it directly? The lack of errors in the network logs and/or CORS errors in the console suggests you can, but it’s probably worth double-checking.

Does the default workspace exist in the admin API? I think I vaguely recall similar blank pages when it was abnormally absent because migrations failed to create it. If not, you’ll want to reset, delete the release, and re-install.

If you can reach the admin API and the workspace is indeed present, not really sure–probably not anything obvious you can do from the Kubernetes configuration, and given the unhandled JS error you’ll probably want to file a bug at GitHub - Kong/kong: 🦍 The Cloud-Native API Gateway

does enterprise image in free mode behaves same as oss?