While NodePort services provide basic external acccess, they are often unsuitable for production due to port range limitations and management overhead. Similarly, creating a dedicated LoadBalancer service for every microservice can become prohibitively expensive and difficult to scale. Kubernetes Ingress addresses these issues by acting as a single entry point that manages HTTP and HTTPS routing to internal services based on defined rules.\n\nAn Ingress resource defines the routing logic, while an Ingress Controller (such as NGINX, HAProxy, or Traefik) implements those rules. In many cloud environments, the Ingress Controller integrates with the provider's native load balancer to expose the cluster to the internet.\n\n### Component Architecture\n\nTo demonstrate traffic distribution, consider a scenario with two microservices: inventory-api and orders-api. The objective is to route traffic based on the URL path:\n- http://api.example.com/inventory maps to inventory-api\n- http://api.example.com/orders maps to orders-api\n\n### Deploying Microservice Workloads\n\nThe first step is to deploy the applications. The following YAML defines a deployement for the inventory service. The application listens on port 8080 and is configured with standard resource constraints.\n\nyaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: inventory-deployment\n labels:\n svc: inventory\nspec:\n replicas: 2\n selector:\n matchLabels:\n svc: inventory\n template:\n metadata:\n labels:\n svc: inventory\n spec:\n containers:\n - name: inventory-app\n image: registry.example.com/inventory:v1.2.0\n ports:\n - containerPort: 8080\n env:\n - name: APP_ENV\n value: "production"\n resources:\n limits:\n cpu: "500m"\n memory: "512Mi"\n requests:\n cpu: "200m"\n memory: "128Mi"\n\n\nA similar deployment would be created for the orders-api, changing the labels and image references accordingly.\n\n### Exposing Services Internally\n\nBefore configuring the Ingress, each deployment must be accessible via a Service. While Ingress controllers can often route directly to pods, a Service resource provides a stable abstraction. For many cloud-integrated Ingress controllers, the Service type should be set to NodePort or ClusterIP.\n\nyaml\napiVersion: v1\nkind: Service\nmetadata:\n name: inventory-service\nspec:\n type: NodePort\n selector:\n svc: inventory\n ports:\n - protocol: TCP\n port: 80\n targetPort: 8080\n nodePort: 32080\n\n\n### Implementing Traffic Routing Rules\n\nWith the services in place, the Ingress resource is defined to manage the routing logic. This configuration specifies how external requests are directed to the internal services based on the request path.\n\nyaml\napiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: microservice-gateway\n annotations:\n kubernetes.io/ingress.class: "nginx"\n nginx.ingress.kubernetes.io/rewrite-target: /\nspec:\n rules:\n - host: api.example.com\n http:\n paths:\n - path: /inventory\n pathType: Prefix\n backend:\n service:\n name: inventory-service\n port:\n number: 80\n - path: /orders\n pathType: Prefix\n backend:\n service:\n name: orders-service\n port:\n number: 80\n\n\nIn this configuration, the pathType: Prefix ensures that any sub-paths under /inventory are also routed correctly. If the Ingress Controller is properly configured with a cloud provider, an external IP address will be assigned to the Ingress resource. You can verify this using the following command:\n\nbash\nkubectl get ingress microservice-gateway\n\n\n### DNS and Hostname Mapping\n\nTo access the services via a domain name, the domain (e.g., api.example.com) must be pointed to the external IP of the Ingress Controller's load balancer. Once the DNS record propagates, requests to http://api.example.com/inventory will be transparently routed to the inventory-deployment pods, and requests to http://api.example.com/orders will reach the orders-deployment pods.\n\nThis approach centralizes SSL termination, authentication, and routing logic, significantly reducing the complexity of managing multiple microservices within a Kubernetes cluster.