I am looking for a one stop solution to support multiple protocol request to my backend, such as MSMQ, HTTP, MQTT. Can I achieve this using Azure Kubernetes NGiNX ingress controller?
Nginx ingress only supports HTTP, TCP and UDP:
https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/#exposing-tcp-and-udp-services
so if you treat those as tcp or udp (whatever they use, I'm not familiar with those) you can achieve that.
Related
I am trying to switch the rest calls from ReadyAPI to our application with AMQP messaging. There is an add-on for ReadyAPI that has the AMQP steps but I need a connection to, I presume, the service bus.
I tried using the service bus as the host name with port: 5671 and 5672 but it gives me an error. Any ideeas how would I connect these two?
Thanks!
Follow the below points to fix your issue.
I think this is due to the internal company firewall restriction which blocks all the traffic on port 5671 and 5672.
So i will recommend you to set your TCP proxy HAProxy on VM.
This TCP proxy configured in such a way that which route
all incoming traffic on a specific port azure service end point.
You can change the end point using connection.setHostname("");
You should also change your port number from 5671 to 8080 in ClientConstants.
After doing all this traffic will route to TCP proxy endpoint instead of service bus as firewall blocked all traffic on 5671 port.
For More about this you can follow the official Microsoft Documentation.
My understanding is that setting the Service type to LoadBalancer creates a new Azure Load Balancer and assigns an IP address to the Service. Does this mean that I can have multiple Services using port 80? If the app behind my Service (an ASP.NET Core app) can handle TLS and HTTPS why shouldn't I just use LoadBalancer's for any Service I want to expose to the internet?
What is the advantage of using an Ingress if I don't care about TLS termination (You can let Cloudflare handle TLS termination)? If anything, it slows things down by adding an extra hop for every request.
Update
Some answers below mention that creating load balancers is costly. It should be noted that load balancers on Azure are free but they do charge for IP addresses of which they give you five for free. So for small projects where you want to expose up to five IP addresses, it's essentially free. Any more than that, then you may want to look ad usign Ingress.
Some answers also mention extra complexity if you don't use Ingress. I have already mentioned that Cloudflare can handle TLS termination for me. I've also discovered the external-dns Kubernetes project to create DNS entries in Cloudflare pointing at the load balancers IP address? It seems to me that cutting out Ingress reduces complexity as it's one less thing that I have to configure and manage. The choice of Ingress is also massive, it's likely that I'll pick the wrong one which will end up unmaintained after some time.
There is a nice article here which describe the differences on Service(Load Balancer) and Ingress.
In summary, you can have multiple Service(Load Balancer) in the cluster, where each application is exposed independently from each other. The main issue is that each Load Balancer added will increase the cost of your solution, and does not have to be this way, unless you strictly need this.
If multiple applications listen on port 80, and they are inside the container, there is no reason you also need to map it to the port 80 in the host node. You can assign it to any port, because the Service will handle the dynamic port mappings for you.
The ingress is best in this scenario, because you can have one ingress listing on port 80, and route the traffic to the right service based on many variables, like:
Domain
Url Path
Query String
And many other
Ingress in not just for TLS termination, it is in simple terms a proxy\gateway that will control the routing to the right service, TLS termination is just one of the features.
No, you cant have multiple services listening on port 80, as load balancer wont know where to route them (ingress will, however). If you can affort to host each service on different port you could use load balancer. alternatively, if you have public ip for each service and different backend port on each service you can achieve this.
quote: The protocol and port combination you entered matches another rule used by this load balancer. The protocol and port combination of each load balancing rule and inbound NAT rule on a load balancer must be unique.
again, if you are a developer, you probably do not realize how much more convenient it is to manage certificate on ingress, and not on all individual containers that are supposed to be accessible
For my project, I need to send UDP packets to a Kubernetes Pod from an outside cluster. How can I do this?
I am using Kubeadm for creating the cluster. I tried to use nodePort but it seems that my requirement cannot be fulfilled with Nodeport.
Actually, NodePort can be used to expose ports within TCP and UDP protocols. What was the problem in your case?
You can consider using Nginx Ingress Controller and creating ReplicationController to implement Nginx ingress in order to expose your Pods across UDP port as described Here or you can check this Link.
Create ConfigMap and specify External port like <namespace/service name>:<service port> which you want to access from outside Kubernetes cluster.
Finally, Nginx ingress can be exposed, i.e., using Kubernetes ExternalIP.
I am able to find the solution for my requirement.
I have exposed the UDP port for my pod and it works fine.
Example
kubectl expose pod udp-server-deployment-8c8d6d868-c77zx --port=10001 --protocol=UDP --external-ip=10.1.11.82 --name=udp-server
Thank you all for your support :)
I am not a system administrator or network administrator thus I having hard time trying to figure it out a work around to support IPv6 on an Azure Service Fabric Cluster without using the Load Balancer.
From here: IPv6 support for Azure other than the load balancer thing
I have checked that IPv6 is only supported by that lb appliances but the entry point of my current cluster is an application gateway.
Is there a recommended work around for adding Ipv6 support for using a Azure App Gateway
Is there a recommended work around for adding Ipv6 support for using a Azure App Gateway
There is no nice way to do that, only work-arounds.
Anyway, you can do the following:
instanciate an Azure back-end server,
configure this server to establish an IPv6 over IPv4 tunnel to an IPv6 public tunnel broker,
install a reverse-proxy on your back-end server, listening to an IP address chosen inside the IPv6 prefix offered by your tunnel broker,
configure this reverse-proxy to translate the accepted IPv6 https connections into outgoing http or https IPv4 requests to your Azure app gateway (the connection stays inside the Azure network, so you may accept not to encrypt it, using http instead of https).
But this will not be very efficient because:
1- this is your back-end server that will terminate and decrypt ssl connections;
2- IPv6 packets from/to your servers in Azure will go through your tunnel broker and Azure, you will not have direct connections between the clients and Azure.
To find a free IPv6 tunnel broker, see for instance Hurricane Electric.
Is there a way to have endpoints which allow protocols other than TCP or UPD. For example Protocol 50 / ESP - the protocol for native IPsec. I would like to be able to hit the "outside" edge of one of my public ip addresses with this protocol.
At this time only the TCP and UDP protocols are supported for Microsoft Azure virtual networks. You can however create a point to site endpoint using VPN; this requires you to download an agent on your client machines. Check this page for more information.