Kubernetes - different "Services" for TCP connection outside the cluster

Viewed 73

I am using Azure Kubernetes Service (AKS) and I need Services solely for TCP connections. I do not need for HTTP at all, I think it is important to emphasize that. For accessing our Service, outside the AKS cluster, but only from different virtual network VM (and NOT from the public internet) the conclusion from the Azure Admins was that I should:

  • expose my Pod App Service with ClusterIP
  • install NGINX Ingress Controller with internal Load Balancer type to connect to ClusterIp service
  • I created kind:Ingress resource as well BUT that was NOT needed at all since I am not using HTTP connection, but as I mentioned I am accessing to my containerized app from outside solely using the NGINX IP address and port. And everything works with this Ingress Controller in place.

I read a lot about Kubernetes services , types, connections and Ingress and I would like to summarize my dilemmas and confusions on which I would need answer - why I had to implement this approach and not some simpler networking architecture without Ingress? (since I am not using HTTP)

  • ClusterIP - It's used for accessing the Service from any node in the Cluser using the CLUSTER-IP:PORT
  • NodePort - It's used for accessing the Service outside using the Node using the NodeIP:NodePort

Question Number 1: Why I couldn't just use NodeIP:NodePort for accessing my Service using the TCP from the different Azure Virtual Network??? Of course firewall rules needs to be configured, but why this approach is not acceptable and I had to install Ingress Controller?

  • LoadBalancer - Exposes the Service externally using a cloud provider's load balancer. OK I must not use the Public Load Balancer so that is clear but why I couldn't use LoadBalancer with internal LoadBalancer Type? This is explained and mentioned on the following link: https://docs.microsoft.com/en-us/azure/aks/internal-lb where they are stating that "...accessible only to applications running in the same virtual network as the Kubernetes cluster". It uses EXTERNAL_IP:PORT value for accessing the Service.

Question Number 2: Doesn't really exist some other approach to use LoadBalancer for accessing the Service from the different virtual network but not to be exposed publicly on the Internet? Does it really have to include more complex networking architecture with Ingress Controller that needs to be created? Again I must emphasize only for TCP and not for HTTP connections use case

Question Number 3: what is the usual and regular network Service and setup that can be used in order to connect from different virtual network? Again - only for TCP connection, and if important I am looking more generally for Azure.

I will appreciate full explanation for all 3 questions, since this kind of Use Cases are not mentioned explicitly in kubernetes.io documentation - they always mentioned that Ingress resources are used for HTTP but definetly based on the instructions which I got from Admins this is also the case for TCP problematic

Thanks

0 Answers
Related