-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make Gateway Discovery work with GKE and kube-dns #140
Comments
I'm facing same issue with Kong/charts#1068, this workaround is working for me kind: GatewayConfiguration
apiVersion: gateway-operator.konghq.com/v1beta1
metadata:
name: kong
namespace: kong-system
spec:
<truncated>
controlPlaneOptions:
deployment:
podTemplateSpec:
spec:
containers:
- name: controller
image: kong/kubernetes-ingress-controller:3.3.1
env:
- name: CONTROLLER_GATEWAY_DISCOVERY_DNS_STRATEGY
value: ip
- name: CONTROLLER_KONG_ADMIN_TLS_SKIP_VERIFY
value: "true"
<truncated> |
Could it be that KIC suffers the same issue ? We are running KIC in GKE on preemptible nodes in our non-prod environment and we regularly have Kong gateway pods unhealthy with errors like the follwing from the controller:
or
The gateway never gets the config pushed to them and the gateway pods remain unhealthy until we manually restarted them all (including the controller). This weekend, we just had an incident in production after that GKE replaced an unhealthy node. The KIC failed to push the config to the Kong pods that were running on that node after they restarted. Our versions non-prod
prod
|
@joran-fonjallaz What you're describing is a different issue: seems like Kong/kubernetes-ingress-controller#6567. |
Problem Statement
https://github.com/Kong/gateway-operator/pull/1261 enabled Gateway Discovery in ControlPlanes with Service
DNSStrategy
, setting the admin servicesspec.publishNotReadyAddresses
field to true. This means that the admin service endpoints are created before the ready probes of the pod are successful. This implementation allows us to solve the chicken-egg problem (caused by the enablement of the dataplane/status/ready
endpoint) that follows:This solution has been tested and has some problems in GKE
pod-ip-address.service-name.namespace.svc
addressProposed Solution
To make KGO work with GKE and kube-dns, we may want to do the follows:
--controlplane-dns-strategy
with default value "service" and allowed values {"service", "pod"}*.namespace.pod
subject instead of*.service-name.namespace.svc
Acceptance Criteria
The text was updated successfully, but these errors were encountered: