Launching the Meteor Application with the Nginx SSL Proxy Server on Kubernet

I have a Meteor application deployed using Kubernetes on Google Cloud configured with Nginx acting as SSL termination. Everything is working fine.

However, it seems that if two different clients connect to two different SSL containers, the updates do not appear in the corresponding applications for up to 10 seconds, which makes the websites seem to be down, but the polling is effecting. I have confirmed that all clients are connected to web sockets, but since updates are not immediately distributed, it is possible that Nginx is not configured to talk correctly with the Meteor application.

Here is my SSL / Nginx service:

apiVersion: v1 kind: Service metadata: name: frontend-ssl labels: name: frontend-ssl spec: ports: - name: http port: 80 targetPort: 80 - name: https port: 443 targetPort: 443 selector: name: frontend-ssl type: LoadBalancer loadBalancerIP: 123.456.123.456 sessionAffinity: ClientIP

And here is the Meteor service:

apiVersion: v1 kind: Service metadata: name: frontend labels: name: frontend spec: ports: - port: 3000 targetPort: 3000 selector: name: flow-frontend type: LoadBalancer loadBalancerIP: 123.456.123.456 sessionAffinity: ClientIP

To complete SSL, I use the Kubernetes proposed SSL setting for forked with add-ons in Websockets https://github.com/markoshust/nginx-ssl-proxy

+8
ssl proxy nginx meteor kubernetes
source share
2 answers

In your NginX configuration, have you definitely used the ip_hash flag to directly access web windows to the same server? You must also ensure that the Upgrade Websocket headers are redirected:

 upstream meteorapp{ ip_hash; server hostname:port } server { # your server stuff here # location / { proxy_pass http://meteorapp; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto http; proxy_redirect http:// $scheme://; } } 
0
source share

The easiest way to run your application is to use the Nginx input controller instead of the Nginx service.

In my opinion, the easiest way to deploy the input controller is with the steering wheel: https://docs.helm.sh/using_helm/#installing-helm https://kubeapps.com/charts/stable/nginx-ingress

But if you prefer not to add another tool to your stack, you can use the official installation guide: https://github.com/kubernetes/ingress-nginx/tree/master/deploy .

An example configuration of an input object with network socket support can be found here: https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/websocket

0
source share

All Articles