I use jenkins-x to deploy front-end and back-end projects, and I want to use the same url in ingress with different paths.
The frontend uses mysite.com, and the backend uses mysite.com/api. At first, I wanted to directly modify "charts/my-project/template/ingress" to achieve the goal, but when the backend was deployed to gke, he did not Use the correct address, but use the default address of gke, and generate two addresses like .., ../api, I don’t Understand why this happens, is there any good way to solve this problem?
spec:
rules:
- host: mysite.com
http:
paths:
- path: /api
backend:
serviceName: {{ .Values.service.name }}
servicePort: 8080
You can set your frontend and your backend on the same domain like this:
spec:
rules:
- host: mysite.com
http:
paths:
- backend:
serviceName: <your-frontend-service-name>
servicePort: 80
path: /
- backend:
serviceName: <your-backend-service-name>
servicePort: 8080
path: /api
Related
I have a domain foobar. When I started my project, I knew I would have my webserver handling traffic for foobar.com. Also, I plan on having an elasticsearch server I wanted running at es.foobar.com. I purchased my domain at GoDaddy and I (maybe prematurely) purchased a single site certificate for foobar.com. I can't change this certificate to a wildcard cert. I would have to purchase a new one. I have my DNS record routing traffic for that simple URL. I'm managing everything using Kubernetes.
Questions:
Is it possible to use my simple single-site certificate for the main site and subdomains like my elasticsearch server or do I need to purchase another single-site certificate specifically for the elasticsearch server? I checked earlier and GoDaddy wants $350 for the multisite one.
ElasticSearch complicates this somewhat since if it's being accessed at es.foobar.com and the cert is for foobar.com it's going to reject any requests, right? Elasticsearch needs a cert in order to have solid security.
Is it possible to use my simple single-site certificate for the main site and subdomains?
To achieve your goal, you can use Name based virtual hosting ingress, since most likely your webserver foobar.com and elasticsearch es.foobar.com work on different ports and will be available under the same IP.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: name-virtual-host-ingress
spec:
rules:
- host: foobar.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: webserver
port:
number: 80
- host: es.foobar.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: elastic
port:
number: 9200-9300 #http.port parametr in elastic config
It can also be implemented using TLS private key and certificate and and creating a file for TLS. This is possible for just one level, like *.foobar.com.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: name-virtual-host-ingress
spec:
tls:
- hosts:
- foobar.com
- es.foobar.com
secretName: "foobar-secret-tls"
rules:
- host: foobar.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: webserver
port:
number: 80
- host: es.foobar.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: elastic
port:
number: 9200-9300 #http.port parametr in elastic config
Either you need to get a wildcard or separate certificate for another domain.
I'm trying to use two TLS certificates for two wildcard domains on single GCE loadbalancer ingress object. But It is giving me error that certificates could not found and it stops working on 443.
Sample Code:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: loadbalancer
spec:
tls:
- secretName: "tls-secret-1"
- secretName: "tls-secret-2"
rules:
- host: "*.domain1.com"
http:
paths:
- path: /*
backend:
serviceName: fe-svc
servicePort: 80
- host: "*.domain2.com"
http:
paths:
- path: /*
backend:
serviceName: fe2-svc
servicePort: 80
- path: /
backend:
serviceName: fe2-svc
servicePort: 80
Here is the sample code. Can anyone please provide me solution of it?
Thanks.
Learning k8s + istio here. I've setup a 2 nodes + 1 master cluster with kops. I have Istio as ingress controller. I'm trying to set up OIDC Auth for a dummy nginx service. I'm hitting a super weird bug I have no idea where it's coming from.
So, I have a
Keycloak service
Nginx service
The keycloak service runs on keycloak.example.com
The nginx service runs on example.com
There is a Classic ELB on AWS to serve that.
There are Route53 DNS records for
ALIAS example.com dualstack.awdoijawdij.amazonaws.com
ALIAS keycloak.example.com dualstack.awdoijawdij.amazonaws.com
When I was setting up the keycloak service, and there was only that service, I had no problem. But when I added the dummy nginx service, I started getting this.
I would use firefox to go to keycloak.example.com, and get a 404. If I do a hard refresh, then the page loads.
Then I would go to example.com, and would get a 404. If I do a hard refresh, then the page loads.
If I do a hard refresh on one page, then when I go to the other page, I will have to do a hard reload or I get a 404. It's like some DNS entry is toggling between these two things whenever I do the hard refresh. I have no idea on how to debug this.
If I
wget -O- example.com I have a 301 redirect to https://example.com as expected
wget -O- https://example.com I have a 200 OK as expected
wget -O- keycloak.example.com I have a 301 redirect to https://keycloak.example.com as expected
wget -O- https://keycloak.example.com I have a 200 OK as expected
Then everything is fine. Seems like the problem only occurs in the browser.
I tried opening the pages in Incognito mode, but the problem persists.
Can someone help me in debugging this?
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
name: http
protocol: TCP
selector:
app: nginx
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: nginx-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
tls:
httpsRedirect: true
hosts:
- "example.com"
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: ingress-cert
hosts:
- "example.com"
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: nginx
spec:
hosts:
- "example.com"
gateways:
- nginx-gateway
http:
- route:
- destination:
port:
number: 80
host: nginx
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: keycloak-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
tls:
httpsRedirect: true
hosts:
- "keycloak.example.com"
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: ingress-cert
hosts:
- "keycloak.example.com"
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: keycloak
spec:
hosts:
- "keycloak.example.com"
gateways:
- keycloak-gateway
http:
- route:
- destination:
port:
number: 80
host: keycloak-http
The problem was that I was using the same certificate for both Gateways, hence resulting in keeping the same tcp connection for both services.
There is a discussion about it here https://github.com/istio/istio/issues/9429
By using a different certificate for both Gateway ports, the problem disappears
I currently have an AKS cluster setup running a GraphQL server and normal nginx ingress. We're attempting to onboard GraphQL Subscriptions, which utilize Websockets. The URL that GraphQL uses for websockets is the same url that is used for GraphQL queries. We've tried adding proxy configuration to enable websocket ingress, but the connection is never established. Running the GraphQL server without Kubernetes is successful, so we think there is something kubernetes-specific going on here...has anyone had any success doing this? Relevant ingress config below
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: web-ingress
namespace: web
annotations:
kubernetes.io/ingress.class: nginx
certmanager.k8s.io/cluster-issuer: letsencrypt
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/affinity: cookie
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
nginx.ingress.kubernetes.io/configuration-snippet: |
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
spec:
tls:
- hosts:
- my.host
- my-api.host
secretName: tls-secret
rules:
- host: my.host
http:
paths:
- path: /graphql
backend:
serviceName: webapi
servicePort: 80
- path: /(.*)
backend:
serviceName: website
servicePort: 80
- host: my-api.host
http:
paths:
- backend:
serviceName: webapi
servicePort: 80
path: /(.*)
You might want to start from a bit less complex config like this:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: web-ingress
namespace: web
annotations:
kubernetes.io/ingress.class: nginx
certmanager.k8s.io/cluster-issuer: letsencrypt
ingress.kubernetes.io/ssl-redirect: "true"
kubernetes.io/tls-acme: "true"
spec:
tls:
- hosts:
- my.host
secretName: tls-secret
rules:
- host: my.host
http:
paths:
- path: /
backend:
serviceName: website
servicePort: 80
- path: /graphql
backend:
serviceName: webapi
servicePort: 80
I switched the config to one endpoint instead of two. Removed some config since NGINX handles websockets out of the box. I removed regexp. I added the tls-acme annotation. And also ssl-redirect. In summary I just made it a bit less complex. Get this up and running first and then start applying advanced config stuff like the timeouts you did.
Happy to hear any feedback on this!
I have a bare-metal kubernetes cluster (1.13) and am running nginx ingress controller (deployed via helm into the default namespace, v0.22.0).
I have an ingress in a different namespace that attempts to use the nginx controller.
#ingress.yaml
kind: Ingress
apiVersion: extensions/v1beta1
metadata:
name: myapp
annotations:
kubernetes.io/backend-protocol: https
nginx.ingress.kubernetes.io/enable-rewrite-log: "true"
nginx.ingress.kubernetes.io/rewrite-target: "/$1"
spec:
tls:
- hosts:
- my-host
secretName: tls-cert
rules:
- host: my-host
paths:
- backend:
servicename: my-service
servicePort: https
path: "/api/(.*)"
The nginx controller successfully finds the ingress, and says that there are endpoints. If I hit the endpoint, I get a 400, with no content. If I turn on custom-http-headers then I get a 404 from nginx; my service is not being hit. According to re-write logging, the url is being re-written correctly.
I have also hit the service directly from inside the pod, and that works as well.
#service.yaml
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
ports:
- name: https
protocol: TCP
port: 5000
targetPort: https
selector:
app: my-app
clusterIP: <redacted>
type: ClusterIP
sessionAffinity: None
What could be going wrong?
EDIT: Disabling https all over still gives the same 400 error. However, if my app is expecting HTTPS requests, and nginx is sending HTTP requests, then the requests get to the app (but it can't processes them)
Nginx will silently fail with 400 if request headers are invalid (like special characters in it). You can debug that using tcpdump.