Nginx-Ingress Helm Deployment --tcp-services-configmap Argument not found - kubernetes
I'm trying to do TCP/UDP port-forwarding with an ingress.
Following the docs: https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/
It says to set: --tcp-services-configmap but doesn't tell you where to set it. I assume it is command line arguments. I then googled the list of command line arguments for nginx-ingress
https://kubernetes.github.io/ingress-nginx/user-guide/cli-arguments/
Here you can clearly see its an argument of the controller:
--tcp-services-configmap Name of the ConfigMap containing the definition of the TCP services to expose. The key in the map indicates the external port to be used. The value is a reference to a Service in the form "namespace/name:port", where "port" can either be a port number or name. TCP ports 80 and 443 are reserved by the controller for servicing HTTP traffic.
First Question: how do I dynamically add to the container arguments of the nginx-ingress helm chart I don't see that documented anywhere?
Second Question: What is the proper way to set this with the current version of nginx-ingress because setting the command line argument fails the container startup because the binary doesn't have that argument option.
Here in the default helm chart values.yaml there are some options about setting the namespace for the configmap for tcp-services but given the docs say I have to set it as an argument but that argument fails the startup I'm not sure how you actually set this.
https://github.com/kubernetes/ingress-nginx/blob/main/charts/ingress-nginx/values.yaml
I manually edited the deployment and set the flag on the container args:
- args:
- -nginx-plus=false
- -nginx-reload-timeout=60000
- -enable-app-protect=false
- -nginx-configmaps=$(POD_NAMESPACE)/emoney-nginx-controller-nginx-ingress
- -default-server-tls-secret=$(POD_NAMESPACE)/emoney-nginx-controller-nginx-ingress-default-server-tls
- -ingress-class=emoney-ingress
- -health-status=false
- -health-status-uri=/nginx-health
- -tcp-services-configmap=emoney-node/tcp-services-configmap
- -nginx-debug=false
- -v=1
- -nginx-status=true
- -nginx-status-port=8080
- -nginx-status-allow-cidrs=127.0.0.1
- -report-ingress-status
- -external-service=emoney-nginx-controller-nginx-ingress
- -enable-leader-election=true
- -leader-election-lock-name=emoney-nginx-controller-nginx-ingress-leader-election
- -enable-prometheus-metrics=true
- -prometheus-metrics-listen-port=9113
- -prometheus-tls-secret=
- -enable-custom-resources=true
- -enable-tls-passthrough=false
- -enable-snippets=false
- -enable-preview-policies=false
- -ready-status=true
- -ready-status-port=8081
- -enable-latency-metrics=false
env:
When I set this like the docs say should be possible the pod fails to start up because it errors out saying that argument isn't an option of the binary.
kubectl logs emoney-nginx-controller-nginx-ingress-5769565cc7-vmgrf -n emoney-node
flag provided but not defined: -tcp-services-configmap
Usage of /nginx-ingress:
-alsologtostderr
log to standard error as well as files
-default-server-tls-secret string
A Secret with a TLS certificate and key for TLS termination of the default server. Format: <namespace>/<name>.
If not set, than the certificate and key in the file "/etc/nginx/secrets/default" are used.
If "/etc/nginx/secrets/default" doesn't exist, the Ingress Controller will configure NGINX to reject TLS connections to the default server.
If a secret is set, but the Ingress controller is not able to fetch it from Kubernetes API or it is not set and the Ingress Controller
fails to read the file "/etc/nginx/secrets/default", the Ingress controller will fail to start.
-enable-app-protect
Enable support for NGINX App Protect. Requires -nginx-plus.
-enable-custom-resources
Enable custom resources (default true)
-enable-internal-routes
Enable support for internal routes with NGINX Service Mesh. Requires -spire-agent-address and -nginx-plus. Is for use with NGINX Service Mesh only.
-enable-latency-metrics
Enable collection of latency metrics for upstreams. Requires -enable-prometheus-metrics
-enable-leader-election
Enable Leader election to avoid multiple replicas of the controller reporting the status of Ingress, VirtualServer and VirtualServerRoute resources -- only one replica will report status (default true). See -report-ingress-status flag. (default true)
-enable-preview-policies
Enable preview policies
-enable-prometheus-metrics
Enable exposing NGINX or NGINX Plus metrics in the Prometheus format
-enable-snippets
Enable custom NGINX configuration snippets in Ingress, VirtualServer, VirtualServerRoute and TransportServer resources.
-enable-tls-passthrough
Enable TLS Passthrough on port 443. Requires -enable-custom-resources
-external-service string
Specifies the name of the service with the type LoadBalancer through which the Ingress controller pods are exposed externally.
The external address of the service is used when reporting the status of Ingress, VirtualServer and VirtualServerRoute resources. For Ingress resources only: Requires -report-ingress-status.
-global-configuration string
The namespace/name of the GlobalConfiguration resource for global configuration of the Ingress Controller. Requires -enable-custom-resources. Format: <namespace>/<name>
-health-status
Add a location based on the value of health-status-uri to the default server. The location responds with the 200 status code for any request.
Useful for external health-checking of the Ingress controller
-health-status-uri string
Sets the URI of health status location in the default server. Requires -health-status (default "/nginx-health")
-ingress-class string
A class of the Ingress controller.
An IngressClass resource with the name equal to the class must be deployed. Otherwise, the Ingress Controller will fail to start.
The Ingress controller only processes resources that belong to its class - i.e. have the "ingressClassName" field resource equal to the class.
The Ingress Controller processes all the VirtualServer/VirtualServerRoute/TransportServer resources that do not have the "ingressClassName" field for all versions of kubernetes. (default "nginx")
-ingress-template-path string
Path to the ingress NGINX configuration template for an ingress resource.
(default for NGINX "nginx.ingress.tmpl"; default for NGINX Plus "nginx-plus.ingress.tmpl")
-ingresslink string
Specifies the name of the IngressLink resource, which exposes the Ingress Controller pods via a BIG-IP system.
The IP of the BIG-IP system is used when reporting the status of Ingress, VirtualServer and VirtualServerRoute resources. For Ingress resources only: Requires -report-ingress-status.
-leader-election-lock-name string
Specifies the name of the ConfigMap, within the same namespace as the controller, used as the lock for leader election. Requires -enable-leader-election. (default "nginx-ingress-leader-election")
-log_backtrace_at value
when logging hits line file:N, emit a stack trace
-log_dir string
If non-empty, write log files in this directory
-logtostderr
log to standard error instead of files
-main-template-path string
Path to the main NGINX configuration template. (default for NGINX "nginx.tmpl"; default for NGINX Plus "nginx-plus.tmpl")
-nginx-configmaps string
A ConfigMap resource for customizing NGINX configuration. If a ConfigMap is set,
but the Ingress controller is not able to fetch it from Kubernetes API, the Ingress controller will fail to start.
Format: <namespace>/<name>
-nginx-debug
Enable debugging for NGINX. Uses the nginx-debug binary. Requires 'error-log-level: debug' in the ConfigMap.
-nginx-plus
Enable support for NGINX Plus
-nginx-reload-timeout int
The timeout in milliseconds which the Ingress Controller will wait for a successful NGINX reload after a change or at the initial start. (default 60000) (default 60000)
-nginx-status
Enable the NGINX stub_status, or the NGINX Plus API. (default true)
-nginx-status-allow-cidrs string
Add IPv4 IP/CIDR blocks to the allow list for NGINX stub_status or the NGINX Plus API. Separate multiple IP/CIDR by commas. (default "127.0.0.1")
-nginx-status-port int
Set the port where the NGINX stub_status or the NGINX Plus API is exposed. [1024 - 65535] (default 8080)
-prometheus-metrics-listen-port int
Set the port where the Prometheus metrics are exposed. [1024 - 65535] (default 9113)
-prometheus-tls-secret string
A Secret with a TLS certificate and key for TLS termination of the prometheus endpoint.
-proxy string
Use a proxy server to connect to Kubernetes API started by "kubectl proxy" command. For testing purposes only.
The Ingress controller does not start NGINX and does not write any generated NGINX configuration files to disk
-ready-status
Enables the readiness endpoint '/nginx-ready'. The endpoint returns a success code when NGINX has loaded all the config after the startup (default true)
-ready-status-port int
Set the port where the readiness endpoint is exposed. [1024 - 65535] (default 8081)
-report-ingress-status
Updates the address field in the status of Ingress resources. Requires the -external-service or -ingresslink flag, or the 'external-status-address' key in the ConfigMap.
-spire-agent-address string
Specifies the address of the running Spire agent. Requires -nginx-plus and is for use with NGINX Service Mesh only. If the flag is set,
but the Ingress Controller is not able to connect with the Spire Agent, the Ingress Controller will fail to start.
-stderrthreshold value
logs at or above this threshold go to stderr
-transportserver-template-path string
Path to the TransportServer NGINX configuration template for a TransportServer resource.
(default for NGINX "nginx.transportserver.tmpl"; default for NGINX Plus "nginx-plus.transportserver.tmpl")
-v value
log level for V logs
-version
Print the version, git-commit hash and build date and exit
-virtualserver-template-path string
Path to the VirtualServer NGINX configuration template for a VirtualServer resource.
(default for NGINX "nginx.virtualserver.tmpl"; default for NGINX Plus "nginx-plus.virtualserver.tmpl")
-vmodule value
comma-separated list of pattern=N settings for file-filtered logging
-watch-namespace string
Namespace to watch for Ingress resources. By default the Ingress controller watches all namespaces
-wildcard-tls-secret string
A Secret with a TLS certificate and key for TLS termination of every Ingress host for which TLS termination is enabled but the Secret is not specified.
Format: <namespace>/<name>. If the argument is not set, for such Ingress hosts NGINX will break any attempt to establish a TLS connection.
If the argument is set, but the Ingress controller is not able to fetch the Secret from Kubernetes API, the Ingress controller will fail to start.
Config Map
apiVersion: v1
data:
"1317": emoney-node/emoney-api:1317
"9090": emoney-node/emoney-grpc:9090
"26656": emoney-node/emoney:26656
"26657": emoney-node/emoney-rpc:26657
kind: ConfigMap
metadata:
annotations:
meta.helm.sh/release-name: emoney
meta.helm.sh/release-namespace: emoney-node
creationTimestamp: "2021-11-01T18:06:49Z"
labels:
app.kubernetes.io/managed-by: Helm
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:data:
.: {}
f:1317: {}
f:9090: {}
f:26656: {}
f:26657: {}
f:metadata:
f:annotations:
.: {}
f:meta.helm.sh/release-name: {}
f:meta.helm.sh/release-namespace: {}
f:labels:
.: {}
f:app.kubernetes.io/managed-by: {}
manager: helm
operation: Update
time: "2021-11-01T18:06:49Z"
name: tcp-services-configmap
namespace: emoney-node
resourceVersion: "2056146"
selfLink: /api/v1/namespaces/emoney-node/configmaps/tcp-services-configmap
uid: 188f5dc8-02f9-4ee5-a5e3-819d00ff8b67
Name: emoney
Namespace: emoney-node
Labels: app.kubernetes.io/instance=emoney
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=ibcnode
app.kubernetes.io/version=1.16.0
helm.sh/chart=ibcnode-0.1.0
Annotations: meta.helm.sh/release-name: emoney
meta.helm.sh/release-namespace: emoney-node
Selector: app.kubernetes.io/instance=emoney,app.kubernetes.io/name=ibcnode
Type: ClusterIP
IP: 172.20.30.240
Port: p2p 26656/TCP
TargetPort: 26656/TCP
Endpoints: 10.0.36.192:26656
Session Affinity: None
Events: <none>
Name: emoney-api
Namespace: emoney-node
Labels: app.kubernetes.io/instance=emoney
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=ibcnode
app.kubernetes.io/version=1.16.0
helm.sh/chart=ibcnode-0.1.0
Annotations: meta.helm.sh/release-name: emoney
meta.helm.sh/release-namespace: emoney-node
Selector: app.kubernetes.io/instance=emoney,app.kubernetes.io/name=ibcnode
Type: ClusterIP
IP: 172.20.166.97
Port: api 1317/TCP
TargetPort: 1317/TCP
Endpoints: 10.0.36.192:1317
Session Affinity: None
Events: <none>
Name: emoney-grpc
Namespace: emoney-node
Labels: app.kubernetes.io/instance=emoney
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=ibcnode
app.kubernetes.io/version=1.16.0
helm.sh/chart=ibcnode-0.1.0
Annotations: meta.helm.sh/release-name: emoney
meta.helm.sh/release-namespace: emoney-node
Selector: app.kubernetes.io/instance=emoney,app.kubernetes.io/name=ibcnode
Type: ClusterIP
IP: 172.20.136.177
Port: grpc 9090/TCP
TargetPort: 9090/TCP
Endpoints: 10.0.36.192:9090
Session Affinity: None
Events: <none>
Name: emoney-nginx-controller-nginx-ingress
Namespace: emoney-node
Labels: app.kubernetes.io/instance=emoney-nginx-controller
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=emoney-nginx-controller-nginx-ingress
helm.sh/chart=nginx-ingress-0.11.3
Annotations: meta.helm.sh/release-name: emoney-nginx-controller
meta.helm.sh/release-namespace: emoney-node
Selector: app=emoney-nginx-controller-nginx-ingress
Type: LoadBalancer
IP: 172.20.16.202
LoadBalancer Ingress: lb removed
Port: http 80/TCP
TargetPort: 80/TCP
NodePort: http 32250/TCP
Endpoints: 10.0.43.32:80
Port: https 443/TCP
TargetPort: 443/TCP
NodePort: https 32375/TCP
Endpoints: 10.0.43.32:443
Session Affinity: None
External Traffic Policy: Local
HealthCheck NodePort: 30904
Events: <none>
Name: emoney-rpc
Namespace: emoney-node
Labels: app.kubernetes.io/instance=emoney
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=ibcnode
app.kubernetes.io/version=1.16.0
helm.sh/chart=ibcnode-0.1.0
Annotations: meta.helm.sh/release-name: emoney
meta.helm.sh/release-namespace: emoney-node
Selector: app.kubernetes.io/instance=emoney,app.kubernetes.io/name=ibcnode
Type: ClusterIP
IP: 172.20.42.163
Port: rpc 26657/TCP
TargetPort: 26657/TCP
Endpoints: 10.0.36.192:26657
Session Affinity: None
Events: <none>
helm repo add nginx-stable https://helm.nginx.com/stable --kubeconfig=./kubeconfig || echo "helm repo already added"
helm repo update --kubeconfig=./kubeconfig || echo "helm repo already updated"
helm upgrade ${app_name}-nginx-controller -n ${app_namespace} nginx-stable/nginx-ingress \
--install \
--kubeconfig=./kubeconfig \
--create-namespace \
--set controller.service.type=LoadBalancer \
--set controller.tcp.configMapNamespace=${app_namespace} \
--set controller.ingressClass="${app_name}-ingress"
kubectl rollout status -w deployment/${app_name} --kubeconfig=./kubeconfig -n ${app_namespace}
#- --tcp-services-configmap=emoney-node/tcp-services-configmap
You could say the helm chart is biased in that it doesn't expose the option to set those args as chart value. It will set them by itself based on conditional logic when it's required according to the values.
When I check the nginx template in the repo, I see that additional args are passed from the template in the params helper file. Those seem to be generated dynamically. I.E.
{{- if .Values.tcp }}
- --tcp-services-configmap={{ default "$(POD_NAMESPACE)" .Values.controller.tcp.configMapNamespace }}/{{ include "ingress-nginx.fullname" . }}-tcp
{{- end }}
So, it seems it will use this flag only if the tcp value isn't empty. On the same condition, it will create the configmap.
Further, the tcp value allows you to set a key configMapNamespace. So if you were to set this key only, then the flag would be used as per paramaters helpers. Now you need to create your configmap only in the provided namespace and let it match the name {{ include "ingress-nginx.fullname" . }}-tcp.
So you could create the configmap in the default namespace and name it ingress-nginx-tcp or similar, depending on how you set the release name.
kubectl create configmap ingress-nginx-tcp --from-literal 1883=mqtt/emqx:1883 -n default
helm install --set controller.tcp.configMapNamespace=default ingress-nginx ingress-nginx/ingress-nginx
I think the only problem with that is that you cannot create it in the .Release.Namespace, since when tcp isn't empty it will attempt to create a configmap there by itself, which would result in conflicts. At least that's how I interpret the templates in the chart repo.
I personally, have configured TCP via values file that I pass to helm with -f.
helm install -f values.yaml ingress-nginx ingress-nginx/ingress-nginx
# configure the tcp configmap
tcp:
1883: mqtt/emqx:1883
8883: mqtt/emqx:8883
# enable the service and expose the tcp ports.
# be careful as this will pontentially make them
# availble on the public web
controller:
service:
enabled: true
ports:
http: 80
https: 443
mqtt: 1883
mqttssl: 8883
targetPorts:
http: http
https: https
mqtt: mqtt
mqttssl: mqttssl
Related
Nginx Ingress returns 502 Bad Gateway on Kubernetes
I have a Kubernetes cluster deployed on AWS (EKS). I deployed the cluster using the “eksctl” command line tool. I’m trying to deploy a Dash python app on the cluster without success. The default port for Dash is 8050. For the deployment I used the following resources: pod service (ClusterIP type) ingress You can check the resource configuration files below: pod-configuration-file.yml kind: Pod apiVersion: v1 metadata: name: dashboard-app labels: app: dashboard spec: containers: - name: dashboard image: my_image_from_ecr ports: - containerPort: 8050 service-configuration-file.yml kind: Service apiVersion: v1 metadata: name: dashboard-service spec: selector: app: dashboard ports: - port: 8050 # exposed port targetPort: 8050 ingress-configuration-file.yml (host based routing) kind: Ingress metadata: name: dashboard-ingress annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/force-ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: dashboard.my_domain http: paths: - backend: serviceName: dashboard-service servicePort: 8050 path: / I followed the steps below: kubectl apply -f pod-configuration-file.yml kubectl apply -f service-configuration-file.yml kubectl apply -f ingress-confguration-file.yml I also noticed that the pod deployment works as expected: kubectl logs my_pod: and the output is: Dash is running on http://127.0.0.1:8050/ Warning: This is a development server. Do not use app.run_server in production, use a production WSGI server like gunicorn instead. * Serving Flask app "annotation_analysis" (lazy loading) * Environment: production WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Debug mode: on You can see from the ingress configuration file that I want to do host based routing using my domain. For this to work, I have also deployed an nginx-ingress. I have also created an “A” record set using Route53 that maps the “dashboard.my_domain” to the nginx-ingress: kubectl get ingress and the output is: NAME HOSTS ADDRESS. PORTS. AGE dashboard-ingress dashboard.my_domain nginx-ingress.elb.aws-region.amazonaws.com 80 93s Moreover, kubectl describe ingress dashboard-ingress and the output is: Name: dashboard-ingress Namespace: default Address: nginx-ingress.elb.aws-region.amazonaws.com Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>) Rules: Host Path Backends ---- ---- -------- host.my-domain / dashboard-service:8050 (192.168.36.42:8050) Annotations: nginx.ingress.kubernetes.io/force-ssl-redirect: false nginx.ingress.kubernetes.io/rewrite-target: / nginx.ingress.kubernetes.io/ssl-redirect: false Events: <none> Unfortunately, when I try to access the Dash app on the browser, I get a 502 Bad Gateway error from the nginx. Could you please help me because my Kubernetes knowledge is limited. Thanks in advance.
It had nothing to do with Kubernetes or AWS settings. I had to change my python Dash code from: if __name__ == "__main__": app.run_server(debug=True) to: if __name__ == "__main__": app.run_server(host='0.0.0.0',debug=True). The addition of host='0.0.0.0' did the trick!
I think you'll need to check whether any other service is exposed at path / on the same host. Secondly, try removing rewrite-target annotation. Also can you please update your question with output of kubectl describe ingress <ingress_Name> I would also suggest you to use backend-protocol annotation with value as HTTP (default value, you can avoid using this if dashboard application is not SSL Configured, and only this application is served at the said host.) But, you may need to add this if multiple applications are served at this host, and create one Ingress with backend-protocol: HTTP for non SSL services, and another with backend-protocol: HTTPS to serve traffic to SSL enabled services. For more information on backend-protocol annotation, kindly refer this link. I have often faced this issue in my Ingress Setup and these steps have helped me resolve it.
Nginx Ingress Controller - Failed Calling Webhook
I set up a k8s cluster using kubeadm (v1.18) on an Ubuntu virtual machine. Now I need to add an Ingress Controller. I decided for nginx (but I'm open for other solutions). I installed it according to the docs, section "bare-metal": kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-0.31.1/deploy/static/provider/baremetal/deploy.yaml The installation seems fine to me: kubectl get all -n ingress-nginx NAME READY STATUS RESTARTS AGE pod/ingress-nginx-admission-create-b8smg 0/1 Completed 0 8m21s pod/ingress-nginx-admission-patch-6nbjb 0/1 Completed 1 8m21s pod/ingress-nginx-controller-78f6c57f64-m89n8 1/1 Running 0 8m31s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/ingress-nginx-controller NodePort 10.107.152.204 <none> 80:32367/TCP,443:31480/TCP 8m31s service/ingress-nginx-controller-admission ClusterIP 10.110.191.169 <none> 443/TCP 8m31s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/ingress-nginx-controller 1/1 1 1 8m31s NAME DESIRED CURRENT READY AGE replicaset.apps/ingress-nginx-controller-78f6c57f64 1 1 1 8m31s NAME COMPLETIONS DURATION AGE job.batch/ingress-nginx-admission-create 1/1 2s 8m31s job.batch/ingress-nginx-admission-patch 1/1 3s 8m31s However, when trying to apply a custom Ingress, I get the following error: Error from server (InternalError): error when creating "yaml/xxx/xxx-ingress.yaml": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post https://ingress-nginx-controller-admission.ingress-nginx.svc:443/extensions/v1beta1/ingresses?timeout=30s: Temporary Redirect Any idea what could be wrong? I suspected DNS, but other NodePort services are working as expected and DNS works within the cluster. The only thing I can see is that I don't have a default-http-backend which is mentioned in the docs here. However, this seems normal in my case, according to this thread. Last but not least, I tried as well the installation with manifests (after removing ingress-nginx namespace from previous installation) and the installation via Helm chart. It has the same result. I'm pretty much a beginner on k8s and this is my playground-cluster. So I'm open to alternative solutions as well, as long as I don't need to set up the whole cluster from scratch. Update: With "applying custom Ingress", I mean: kubectl apply -f <myIngress.yaml> Content of myIngress.yaml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: my-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - http: paths: - path: /someroute/fittingmyneeds pathType: Prefix backend: serviceName: some-service servicePort: 5000
Another option you have is to remove the Validating Webhook entirely: kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission I found I had to do that on another issue, but the workaround/solution works here as well. This isn't the best answer; the best answer is to figure out why this doesn't work. But at some point, you live with workarounds. I'm installing on Docker for Mac, so I used the cloud rather than baremetal version: kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.34.1/deploy/static/provider/cloud/deploy.yaml
In my case I'd mixed the installations up. I resolved the issue by executing the following steps: $ kubectl get validatingwebhookconfigurations I iterated through the list of configurations received from the above steps and deleted the configuration using $ `kubectl delete validatingwebhookconfigurations [configuration-name]`
In my case I didn't need to delete the ValidatingWebhookConfiguration. The issue was that I was using a private cluster on GCP version 1.17.14-gke.1600. If I got it correctly, on a default Kubernetes installation, the valitaingwebhook API (which of course is running on the master node), is exposed at port 443. But with GCP they changed the port to 8443 due to security reasons because in order to allocate port 443, the service needs to have root access to the node. Since they didn't want that, they changed to 8443. Now, since a private cluster only has the ports 80/443 externally allowed for Ingress on the nodes (that is, all the nodes will only accept requests to these ports), when the Kubernetes tries to validate your Ingress against the validatingwebhook-address:8443 it will fail - it would not fail if it ran on 443. This thread contains more detailed information. So the current workaround for that, as recommended by Google itself (but very poorly documented) is adding a Firewall rule on GCP, that will allow inbound (Ingress) TCP requests to your master node at port 8443, so that the other nodes within the cluster can reach the master for validatingwebhook API running on it with that very port. As to how to create the rule, this is how I did it: Went to Firewall Rules and added a new one. At the field Network I selected the VPC from which my cluster is. Direction of traffic I set as Ingress Action on match to Allow Targets to Specified target tags The Target tags can be found on the master node details in a property called Network tags. To find it, I opened a new window, went to my cluster node pools, found the master node pool. Then entered one of the nodes to look for the Virtual Machine details. There I found Network Tags. Copied its value and went back to the Firewall Rule form. Pasted the copied network tag to the tag field At Protocols and ports, checked the Specified protocols and ports Then checked TCP and placed 8443 Saved the rule and applied the manifest again. NOTE: Most threads out there will say it's the port 9443. It may work. But I first attempted 8443 since it was reported to work on this thread. It worked for me so I didn't even try 9443.
Might be because of a previous nginx-ingress-controller configuration. You can try to run the following command - kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission
I've solved this issue. The problem was that you use Kubernetes version 1.18, but the ValidatingWebhookConfiguration in current ingress-Nginx uses the oldest API; see the doc: https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#prerequisites Ensure that the Kubernetes cluster is at least as new as v1.16 (to use admissionregistration.k8s.io/v1), or v1.9 (to use admissionregistration.k8s.io/v1beta1). And in current yaml : # Source: ingress-nginx/templates/admission-webhooks/validating-webhook.yaml # before changing this value, check the required kubernetes version # https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#prerequisites apiVersion: admissionregistration.k8s.io/v1beta1 and in rules : apiVersions: - v1beta1 So you need to change it on v1 : apiVersion: admissionregistration.k8s.io/v1 and add rule -v1 : apiVersions: - v1beta1 - v1 After you change it and redeploy -your custom ingress service will deploy sucessfull
Finally, I managed to run Ingress Nginx properly by changing the way of installation. I still don't understand why the previous installation didn't work, but I'll share nevertheless the solution along with some more insights into the original problem. Solution Uninstall ingress nginx: Delete the ingress-nginx namespace. This does not remove the validating webhook configuration - delete this one manually. Then install MetalLB and install ingress nginx again. I now used the version from the Helm stable repo. Now everything works as expected. Thanks to Long on the kubernetes slack channel! Some more insights into the original problem The yamls provided by the installation guide contain a ValidatingWebHookConfiguration: apiVersion: admissionregistration.k8s.io/v1beta1 kind: ValidatingWebhookConfiguration metadata: labels: helm.sh/chart: ingress-nginx-2.0.3 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 0.32.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: admission-webhook name: ingress-nginx-admission namespace: ingress-nginx webhooks: - name: validate.nginx.ingress.kubernetes.io rules: - apiGroups: - extensions - networking.k8s.io apiVersions: - v1beta1 operations: - CREATE - UPDATE resources: - ingresses failurePolicy: Fail clientConfig: service: namespace: ingress-nginx name: ingress-nginx-controller-admission path: /extensions/v1beta1/ingresses Validation is performed whenever I create or update an ingress (the content of my ingress.yaml doesn't matter). The validation failed, because when calling the service, the response is a Temporary Redirect. I don't know why. The corresponding service is: apiVersion: v1 kind: Service metadata: labels: helm.sh/chart: ingress-nginx-2.0.3 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 0.32.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: ingress-nginx-controller-admission namespace: ingress-nginx spec: type: ClusterIP ports: - name: https-webhook port: 443 targetPort: webhook selector: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/component: controller The pod matching the selector comes from this deployment: apiVersion: apps/v1 kind: Deployment metadata: labels: helm.sh/chart: ingress-nginx-2.0.3 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 0.32.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: ingress-nginx-controller namespace: ingress-nginx spec: selector: matchLabels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/component: controller revisionHistoryLimit: 10 minReadySeconds: 0 template: metadata: labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/component: controller spec: dnsPolicy: ClusterFirst containers: - name: controller image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.32.0 imagePullPolicy: IfNotPresent lifecycle: preStop: exec: command: - /wait-shutdown args: - /nginx-ingress-controller - --election-id=ingress-controller-leader - --ingress-class=nginx - --configmap=ingress-nginx/ingress-nginx-controller - --validating-webhook=:8443 - --validating-webhook-certificate=/usr/local/certificates/cert - --validating-webhook-key=/usr/local/certificates/key securityContext: capabilities: drop: - ALL add: - NET_BIND_SERVICE runAsUser: 101 allowPrivilegeEscalation: true env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace livenessProbe: httpGet: path: /healthz port: 10254 scheme: HTTP initialDelaySeconds: 10 periodSeconds: 10 timeoutSeconds: 1 successThreshold: 1 failureThreshold: 3 readinessProbe: httpGet: path: /healthz port: 10254 scheme: HTTP initialDelaySeconds: 10 periodSeconds: 10 timeoutSeconds: 1 successThreshold: 1 failureThreshold: 3 ports: - name: http containerPort: 80 protocol: TCP - name: https containerPort: 443 protocol: TCP - name: webhook containerPort: 8443 protocol: TCP volumeMounts: - name: webhook-cert mountPath: /usr/local/certificates/ readOnly: true resources: requests: cpu: 100m memory: 90Mi serviceAccountName: ingress-nginx terminationGracePeriodSeconds: 300 volumes: - name: webhook-cert secret: secretName: ingress-nginx-admission Something in this validation chain goes wrong. Would be interesting to know, what and why, but I can continue working with my MetalLB solution. Note that this solution does not contain a validating webhook at all.
I am not sure if this helps this late, but might it be, that your cluster was behind proxy? Because in that case you have to have no_proxy configured correctly. Specifically, it has to include .svc,.cluster.local otherwise validation webhook requests such as https://ingress-nginx-controller-admission.ingress-nginx.svc:443/extensions/v1beta1/ingresses?timeout=30s will be routed via proxy server (note that .svc in the URL). I had exactly this issue and adding .svc into no_proxy variable helped. You can try this out quickly by modifying /etc/kubernetes/manifests/kube-apiserver.yaml file which will in turn automatically recreate your kubernetes api server pod. This is not the case just for ingress validation, but also for other things that might refer URL in your cluster ending with .svc or .namespace.svc.cluster.local (i.e. see this bug)
On a baremetal cluster, I disabled the admissionWebhooks during the Helm3 install: kubectl create ns ingress-nginx helm install [RELEASE_NAME] ingress-nginx/ingress-nginx -n ingress-nginx --set controller.admissionWebhooks.enabled=false
In my case, it was the AWS EKS module, which now comes with harden security group. but nginx-ingress requires the cluster to communicate with the ingress controller so I have to whitelist below port in the node security group node_security_group_additional_rules = { cluster_to_node = { description = "Cluster to ingress-nginx webhook" protocol = "-1" from_port = 8443 to_port = 8443 type = "ingress" source_cluster_security_group = true } } input_node_security_group_additional_rules
I had this error. Basically I have a script installing the nginx controller with helm; the script then immediately installs an application that uses ingress, also with helm. That app install failed, just the ingress part. Solution was to wait 60s after the install of the nginx, to give the WebAdmissionHook time to come up and be ready.
If using terraform and helm disable the Validating Webhook resource "helm_release" "nginx_ingress" { ... set { name = "controller.admissionWebhooks.enabled" value = "false" } ... }
what worked for me was to increase the timeout while waiting for ingress to come up.
I was bringing up a cluster with a known-good configuration and another had been created just last week in essentially the same way. And my error message was a little more specific about what failed in the webhook : │ Error: Failed to create Ingress 'auth-system/alertmanager-oauth2-proxy' because: Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post "https://nginx-nginx-ingress-controller-controller-admission.ingress-nginx.svc:443/networking/v1beta1/ingresses?timeout=10s": x509: certificate signed by unknown authority It turns out that in my many configs, one of them had a typo in the DNS names input to nginx creation. So nginx thought it had one domain name, but it got a certificate for a slightly different dns name, which caused the validating web hook to fail. The solution was not to delete the hook, but to address the underlying config problem in nginx dns so that it matched its X.509 certificate domain.
just use v1 instead v1beta1 in deploy.yaml
This is a solution for those using GKE cluster. I tested two ways to fix this issue. Terraform GCP Console Terraform resource "google_compute_firewall" "validate-nginx" { project = "${YOUR_PROJECT_ID}" name = "access-master-to-validatenginx" network = "${YOUR_NETWORK}" allow { protocol = "tcp" ports = ["8443"] } target_tags = ["${NODE_NETWORK_TAG}"] source_ranges = ["${CONTROL_PLANE_ADDRESS_RANGE}"] } GCP Console
To add a terraform example for GCP, extending #mauricio resource "google_container_cluster" "primary" { ... } resource "google_compute_firewall" "validate_nginx" { project = local.project name = "validate-nginx" network = google_compute_network.vpc.name allow { protocol = "tcp" ports = ["8443"] } direction = "INGRESS" source_ranges = [google_container_cluster.primary.private_cluster_config[0].master_ipv4_cidr_block] }
Google Kubernetes Ingress health check always failing
I have configured a web application pod exposed via apache on port 80. I'm unable to configure a service + ingress for accessing from the internet. The issue is that the backend services always report as UNHEALTHY. Pod Config: apiVersion: extensions/v1beta1 kind: Deployment metadata: labels: name: webapp name: webapp namespace: my-app spec: replicas: 1 selector: matchLabels: name: webapp template: metadata: labels: name: webapp spec: containers: - image: asia.gcr.io/my-app/my-app:latest name: webapp ports: - containerPort: 80 name: http-server Service Config: apiVersion: v1 kind: Service metadata: name: webapp-service spec: type: NodePort selector: name: webapp ports: - protocol: TCP port: 50000 targetPort: 80 Ingress Config: kind: Ingress metadata: name: webapp-ingress spec: backend: serviceName: webapp-service servicePort: 50000 This results in backend services reporting as UNHEALTHY. The health check settings: Path: / Protocol: HTTP Port: 32463 Proxy protocol: NONE Additional information: I've tried a different approach of exposing the deployment as a load balancer with external IP and that works perfectly. When trying to use a NodePort + Ingress, this issue persists.
With GKE, the health check on the Load balancer is created automatically when you create the ingress. Since the HC is created automatically, so are the firewall rules. Since you have no readinessProbe configured, the LB has a default HC created (the one you listed). To debug this properly, you need to isolate where the point of failure is. First, make sure your pod is serving traffic properly; kubectl exec [pod_name] -- wget localhost:80 If the application has curl built in, you can use that instead of wget. If the application has neither wget or curl, skip to the next step. get the following output and keep track of the output: kubectl get po -l name=webapp -o wide kubectl get svc webapp-service You need to keep the service and pod clusterIPs SSH to a node in your cluster and run sudo toolbox bash Install curl: apt-get install curl` Test the pods to make sure they are serving traffic within the cluster: curl -I [pod_clusterIP]:80 This needs to return a 200 response Test the service: curl -I [service_clusterIP]:80 If the pod is not returning a 200 response, the container is either not working correctly or the port is not open on the pod. if the pod is working but the service is not, there is an issue with the routes in your iptables which is managed by kube-proxy and would be an issue with the cluster. Finally, if both the pod and the service are working, there is an issue with the Load balancer health checks and also an issue that Google needs to investigate.
As Patrick mentioned, the checks will be created automatically by GCP. By default, GKE will use readinessProbe.httpGet.path for the health check. But if there is no readinessProbe configured, then it will just use the root path /, which must return an HTTP 200 (OK) response (and that's not always the case, for example, if the app redirects to another path, then the GCP health check will fail).
Kubernetes - Pass Public IP of Load Balance as Environment Variable into Pod
Gist I have a ConfigMap which provides necessary environment variables to my pods: apiVersion: v1 kind: ConfigMap metadata: name: global-config data: NODE_ENV: prod LEVEL: info # I need to set API_URL to the public IP address of the Load Balancer API_URL: http://<SOME IP>:3000 DATABASE_URL: mongodb://database:27017 SOME_SERVICE_HOST: some-service:3000 I am running my Kubernetes Cluster on Google Cloud, so it will automatically create a public endpoint for my service: apiVersion: v1 kind: Service metadata: name: gateway spec: selector: app: gateway ports: - name: http port: 3000 targetPort: 3000 nodePort: 30000 type: LoadBalancer Issue I have an web application that needs to make HTTP requests from the client's browser to the gateway service. But in order to make a request to the external service, the web app needs to know it's ip address. So I've set up the pod, which serves the web application in a way, that it picks up an environment variable "API_URL" and as a result makes all HTTP requests to this url. So I just need a way to set the API_URL environment variable to the public IP address of the gateway service to pass it into a pod when it starts.
I know this isn't the exact approach you were going for, but I've found that creating a static IP address and explicitly passing it in tends to be easier to work with. First, create a static IP address: gcloud compute addresses create gke-ip --region <region> where region is the GCP region your GKE cluster is located in. Then you can get your new IP address with: gcloud compute addresses describe gke-ip --region <region> Now you can add your static IP address to your service by specifying an explicit loadBalancerIP.1 apiVersion: v1 kind: Service metadata: name: gateway spec: selector: app: gateway ports: - name: http port: 3000 targetPort: 3000 nodePort: 30000 type: LoadBalancer loadBalancerIP: "1.2.3.4" At this point, you can also hard-code it into your ConfigMap and not worry about grabbing the value from the cluster itself. 1If you've already created a LoadBalancer with an auto-assigned IP address, setting an IP address won't change the IP of the underlying GCP load balancer. Instead, you should delete the LoadBalancer service in your cluster, wait ~15 minutes for the underlying GCP resources to get cleaned up, and then recreate the LoadBalancer with the explicit IP address.
You are trying to access gateway service from client's browser. I would like to suggest you another solution that is slightly different from what you are currently trying to achieve but it can solve your problem. From your question I was able to deduce that your web app and gateway app are on the same cluster. In my solution you dont need a service of type LoadBalancer and basic Ingress is enough to make it work. You only need to create a Service object (notice that option type: LoadBalancer is now gone) apiVersion: v1 kind: Service metadata: name: gateway spec: selector: app: gateway ports: - name: http port: 3000 targetPort: 3000 nodePort: 30000 and you alse need an ingress object (remember that na Ingress Controller needs to be deployed to cluster in order to make it work) like one below: More on how to deploy Nginx Ingress controller you can finde here and if you are already using one (maybe different one) then you can skip this step. apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: gateway-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: gateway.foo.bar.com http: paths: - path: / backend: serviceName: gateway servicePort: 3000 Notice the host field. The same you need to repeat for your web application. Remember to use appropriate host name (DNS name) e.g. for web app: foo.bar.com and for gateway: gateway.foo.bar.com and then just use the gateway.foo.bar.com dns name to connect to the gateway app from clients web browser. You also need to create a dns entry that points *.foo.bar.com to Ingress's public ip address as Ingress controller will create its own load balancer. The flow of traffic would be like below: +-------------+ +---------+ +-----------------+ +---------------------+ | Web Browser |-->| Ingress |-->| gateway Service |-->| gateway application | +-------------+ +---------+ +-----------------+ +---------------------+ This approach is better becaues it won't cause issues with Cross-Origin Resource Sharing (CORS) in clients browser. Examples of Ingress and Service manifests I took from official kubernetes documentation and modified slightly. More on Ingress you can find here and on Services here
The following deployment reads the external IP of a given service using kubectl every 10 seconds and patches a given configmap with it: apiVersion: apps/v1 kind: Deployment metadata: name: configmap-updater labels: app: configmap-updater spec: selector: matchLabels: app: configmap-updater template: metadata: labels: app: configmap-updater spec: containers: - name: configmap-updater image: alpine:3.10 command: ['sh', '-c' ] args: - | #!/bin/sh set -x apk --update add curl curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.16.0/bin/linux/amd64/kubectl chmod +x kubectl export CONFIGMAP="configmap/global-config" export SERVICE="service/gateway" while true do IP=`./kubectl get services $CONFIGMAP -o go-template --template='{{ (index .status.loadBalancer.ingress 0).ip }}'` PATCH=`printf '{"data":{"API_URL": "https://%s:3000"}}' $IP` echo ${PATCH} ./kubectl patch --type=merge -p "${PATCH}" $SERVICE sleep 10 done You probably have RBAC enabled in your GKE cluster and would still need to create the appropriate Role and RoleBinding for this to work correctly. You've got a few possibilities: If you really need this to be hacked into your setup, you could use a similar approach with a sidecar container in your pod or a global service like above. Keep in mind that you would need to recreate your pods if the configmap actually changed for the changes to be picked up by the environment variables of your containers. Watch and query the Kubernetes-API for the external IP directly in your application, eliminating the need for an environment variable. Adopt your applications to not directly depend on the external IP.
Allow pod to access domain names of service through ingress
I have a service and ingress setup on my minikube kubernetes cluster which exposes the domain name hello.life.com Now I need to access this domain from inside another pod as curl http://hello.life.com and this should return proper html My service is as follows: apiVersion: v1 kind: Service metadata: labels: app: bulging-zorse-key chart: key-0.1.0 heritage: Tiller release: bulging-zorse name: bulging-zorse-key-svc namespace: abc spec: ports: - name: http port: 80 protocol: TCP targetPort: 8080 selector: name: bulging-zorse-key type: ClusterIP status: loadBalancer: {} My ingress is as follows: apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx labels: app: bulging-zorse-key chart: key-0.1.0 heritage: Tiller release: bulging-zorse name: bulging-zorse-key-ingress namespace: dev spec: rules: - host: hello.life.com http: paths: - backend: serviceName: bulging-zorse-key-svc servicePort: 80 path: / status: loadBalancer: ingress: - {} Can someone please help me out as to what changes do I need to make to get it working? Thanks in advance!!!
I found a good explanation of your problem and the solution in the Custom DNS Entries For Kubernetes article: Suppose we have a service, foo.default.svc.cluster.local that is available to outside clients as foo.example.com. That is, when looked up outside the cluster, foo.example.com will resolve to the load balancer VIP - the external IP address for the service. Inside the cluster, it will resolve to the same thing, and so using this name internally will cause traffic to hairpin - travel out of the cluster and then back in via the external IP. The solution is: Instead, we want foo.example.com to resolve to the internal ClusterIP, avoiding the hairpin. To do this in CoreDNS, we make use of the rewrite plugin. This plugin can modify a query before it is sent down the chain to whatever backend is going to answer it. To get the behavior we want, we just need to add a rewrite rule mapping foo.example.com to foo.default.svc.cluster.local: apiVersion: v1 data: Corefile: | .:53 { errors health rewrite name foo.example.com foo.default.svc.cluster.local kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 proxy . /etc/resolv.conf cache 30 loop reload loadbalance } kind: ConfigMap metadata: creationTimestamp: "2019-01-09T15:02:52Z" name: coredns namespace: kube-system resourceVersion: "8309112" selfLink: /api/v1/namespaces/kube-system/configmaps/coredns uid: a2ef5ff1-141f-11e9-9043-42010a9c0003 Note: In your case, you have to put ingress service name as a destination for the alias. (E.g.: rewrite name hello.life.com ingress-service-name.ingress-namespace.svc.cluster.local) Make sure you're using correct service name and namespace name. Once we add that to the ConfigMap via kubectl edit configmap coredns -n kube-system or kubectl apply -f patched-coredns-deployment.yaml -n kube-system, we have to wait 10-15 minutes. Recent CoreDNS versions includes reload plugin. reload Name reload - allows automatic reload of a changed Corefile. Description This plugin periodically checks if the Corefile has changed by reading it and calculating its MD5 checksum. If the file has changed, it reloads CoreDNS with the new Corefile. This eliminates the need to send a SIGHUP or SIGUSR1 after changing the Corefile. The reloads are graceful - you should not see any loss of service when the reload happens. Even if the new Corefile has an error, CoreDNS will continue to run the old config and an error message will be printed to the log. But see the Bugs section for failure modes. In some environments (for example, Kubernetes), there may be many CoreDNS instances that started very near the same time and all share a common Corefile. To prevent these all from reloading at the same time, some jitter is added to the reload check interval. This is jitter from the perspective of multiple CoreDNS instances; each instance still checks on a regular interval, but all of these instances will have their reloads spread out across the jitter duration. This isn't strictly necessary given that the reloads are graceful, and can be disabled by setting the jitter to 0s. Jitter is re-calculated whenever the Corefile is reloaded. Running our test pod, we can see this works: $ kubectl run -it --rm --restart=Never --image=infoblox/dnstools:latest dnstools If you don't see a command prompt, try pressing enter. / # host foo foo.default.svc.cluster.local has address 10.0.0.72 / # host foo.example.com foo.example.com has address 10.0.0.72 / # host bar.example.com Host bar.example.com not found: 3(NXDOMAIN) / #