{"id":79852,"date":"2026-11-12T09:38:29","date_gmt":"2026-11-12T09:38:29","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=79852"},"modified":"2026-11-12T09:38:31","modified_gmt":"2026-11-12T09:38:31","slug":"kubernetes-ingress-controller-using-path-based-routing-complete-hands-on-lab-with-calico-vxlan","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/kubernetes-ingress-controller-using-path-based-routing-complete-hands-on-lab-with-calico-vxlan\/","title":{"rendered":"Kubernetes Ingress Controller using Path-Based Routing: Complete Hands-On Lab with Calico VXLAN"},"content":{"rendered":"\n
\n

Scope:<\/strong> Self-managed Kubernetes on two AWS EC2 Ubuntu nodes; install the community ingress-nginx v1.15.1<\/strong> bare-metal\/NodePort manifest, repair cross-node Calico networking, deploy two NGINX versions behind ClusterIP Services, configure path-based routing with URL rewriting, and validate each layer.<\/p>\n\n\n\n

Production warning (November 2026):<\/strong> The community kubernetes\/ingress-nginx<\/code> project was retired in March 2026<\/strong> and no longer receives security fixes. The exact v1.15.1 manifest below reproduces this existing training\/lab<\/strong> cluster only; do not deploy it as a new production ingress solution<\/strong>. For new production deployments, evaluate a maintained Gateway API implementation or actively supported Ingress controller. See Kubernetes retirement announcement<\/a>.<\/p>\n<\/blockquote>\n\n\n\n

Learning objectives<\/h2>\n\n\n\n

By the end, you will know how to:<\/p>\n\n\n\n

    \n
  1. Install the ingress-nginx controller and understand its NodePort and admission-webhook Services.<\/li>\n\n\n\n
  2. Identify a Calico networking failure using routes, Pod IPs, and webhook timeouts.<\/li>\n\n\n\n
  3. Enable VXLAN on an existing Calico IPPool\u00a0when that is appropriate for your cluster<\/strong>.<\/li>\n\n\n\n
  4. Deploy\u00a0app1<\/code>\u00a0and\u00a0app2<\/code>\u00a0using\u00a0scmgalaxy\/nginx-devopsschoolv1<\/code>\u00a0and\u00a0scmgalaxy\/nginx-devopsschoolv2<\/code>.<\/li>\n\n\n\n
  5. Route\u00a0\/app1<\/code>\u00a0and\u00a0\/app2<\/code>\u00a0through a\u00a0single Ingress<\/strong>\u00a0with NGINX-specific path rewriting.<\/li>\n\n\n\n
  6. Validate Kubernetes resources, networking, HTTP responses, and cleanup.<\/li>\n<\/ol>\n\n\n\n

    Lab environment and architecture<\/h2>\n\n\n\n

    These addresses and ports are from the example lab. Replace them with values from your own cluster.<\/strong><\/p>\n\n\n\n

    Component<\/th>Lab value<\/th>Purpose<\/th><\/tr><\/thead>
    Kubernetes<\/td>v1.35.10<\/td>Self-managed cluster<\/td><\/tr>
    Control-plane node<\/td>172.31.10.122<\/code><\/td>Run kubectl<\/code> and host networking tests<\/td><\/tr>
    Worker node<\/td>172.31.13.14<\/code><\/td>Runs the Ingress controller in this lab<\/td><\/tr>
    CNI<\/td>Calico<\/td>Pod networking<\/td><\/tr>
    Calico Pod CIDR<\/td>192.168.0.0\/16<\/code><\/td>Pod address pool<\/td><\/tr>
    Ingress controller<\/td>ingress-nginx v1.15.1<\/code><\/td>Lab controller, now unmaintained<\/td><\/tr>
    Ingress Controller Service<\/td>NodePort<\/code><\/td>HTTP\/HTTPS external entry point<\/td><\/tr>
    Lab HTTP NodePort<\/td>31960<\/code><\/td>Discover dynamically; value may differ<\/td><\/tr>
    Admission Service IP<\/td>10.101.95.207:443<\/code><\/td>Kubernetes API server -> webhook<\/td><\/tr>
    Admission Pod IP<\/td>192.168.131.65:8443<\/code><\/td>Example worker Pod endpoint<\/td><\/tr>
    App1<\/td>scmgalaxy\/nginx-devopsschoolv1<\/code><\/td>First demo page<\/td><\/tr>
    App2<\/td>scmgalaxy\/nginx-devopsschoolv2<\/code><\/td>Second demo page<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                             Browser \/ curl\n                               |\n                 http:\/\/WORKER_IP:HTTP_NODEPORT\n                               |\n                               v\n                   ingress-nginx controller\n                        (NodePort Service)\n                               |\n                   Ingress: path-based-ingress\n                        \/             \\\n             \/app1(\/|$)(.*)         \/app2(\/|$)(.*)\n                rewrite to \/          rewrite to \/\n                       |                 |\n                       v                 v\n                 app1-service       app2-service\n                  ClusterIP          ClusterIP\n                       |                 |\n                       v                 v\n                   app1 Pod           app2 Pod\n                 NGINX image v1     NGINX image v2\n\n   Kubernetes API server -> admission ClusterIP:443 -> controller Pod:8443\n   Inter-node Pod packets -> Calico VXLAN over UDP 4789 (in this lab)\n<\/code><\/pre>\n\n\n\n
    \n
    Why NodePort?<\/strong> This is a manually created Kubernetes cluster on EC2, not an EKS cluster automatically provisioning an AWS Load Balancer. The bare-metal ingress-nginx manifest exposes a NodePort Service. ClusterIP application Services remain private. EC2 private IPs are accessible only from networks that can reach the VPC; public Internet access also requires suitable networking and narrowly scoped security group rules.<\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    Prerequisites<\/h2>\n\n\n\n
      \n
    • An existing, working Kubernetes cluster with the\u00a0kubectl<\/code>\u00a0context set to the correct cluster.<\/li>\n\n\n\n
    • Cluster-admin permissions for installing the controller and changing Calico resources.<\/li>\n\n\n\n
    • Two schedulable nodes (the demo can run on one, but cross-node networking troubleshooting requires at least two).<\/li>\n\n\n\n
    • Calico already installed if using the Calico-specific repair steps;\u00a0this tutorial does not install Calico from scratch<\/strong>.<\/li>\n\n\n\n
    • EC2 security groups and NACLs allowing the required node-to-node traffic (see\u00a0Phase 2<\/strong>).<\/li>\n\n\n\n
    • curl<\/code>,\u00a0iproute2<\/code>, and optionally\u00a0tcpdump<\/code>\u00a0on the control-plane host.<\/li>\n<\/ul>\n\n\n
      kubectl config current-context\nkubectl get<\/span> nodes -o wide\nkubectl get<\/span> pods -n kube-system -o wide\nkubectl get<\/span> ingressclasses\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      For clean file organization:<\/p>\n\n\n
      mkdir -p ~\/ingress-path-lab\ncd ~\/ingress-path-lab\n<\/code><\/span><\/pre>\n\n\n
      \n\n\n\n
      Phase 1 \u2014 Install the ingress-nginx controller<\/h1>\n\n\n\n
      1.1 Apply the exact lab manifest<\/h2>\n\n\n\n
      \n
      Lab-only \/ legacy installation.<\/strong> This is the version used in the original demonstration.<\/p>\n<\/blockquote>\n\n\n
      kubectl apply -f https:\/\/raw.githubusercontent.com\/kubernetes\/ingress-nginx\/controller-v1.15.1\/deploy\/static\/provider\/baremetal\/deploy.yaml<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      This creates resources including the ingress-nginx<\/code> namespace, controller Deployment, Services, IngressClass, admission webhook configuration, certificate Jobs and RBAC.<\/p>\n\n\n\n
      1.2 Verify controller and webhook are ready<\/h2>\n\n\n
      kubectl rollout status deployment\/ingress-nginx-controller \\\n  -n ingress-nginx --timeout=180<\/span>s\n\nkubectl get<\/span> pods -n ingress-nginx -o wide\nkubectl get<\/span> svc -n ingress-nginx\nkubectl get<\/span> ingressclass\nkubectl get<\/span> validatingwebhookconfigurations\nkubectl get<\/span> jobs -n ingress-nginx\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Expected resource names (actual NodePort numbers vary):<\/p>\n\n\n
      ingress-nginx-controller              NodePort     ...    80:<HTTP_NODEPORT<\/span>><\/span>\/TCP,443:<HTTPS_NODEPORT<\/span>><\/span>\/TCP\ningress-nginx-controller-admission    ClusterIP    ...    443\/TCP\n\nIngressClass: nginx  ->  k8s.io\/ingress-nginx\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
      The admission webhook listens inside the controller Pod on TCP 8443<\/strong>; the admission Service exposes it at TCP 443<\/strong>. These are not<\/strong> the public application ports.<\/p>\n\n\n\n
      1.3 Discover the NodePort instead of hardcoding it<\/h2>\n\n\n
      HTTP_NODEPORT=$(kubectl get svc ingress-nginx-controller -n ingress-nginx \\\n  -o jsonpath='{.spec.ports[?(@.name==\"http\")].nodePort}'<\/span>)\n\nHTTPS_NODEPORT=$(kubectl get svc ingress-nginx-controller -n ingress-nginx \\\n  -o jsonpath='{.spec.ports[?(@.name==\"https\")].nodePort}'<\/span>)\n\nkubectl get svc ingress-nginx-controller -n ingress-nginx\nprintf 'HTTP NodePort: %s\\nHTTPS NodePort: %s\\n'<\/span> \"$HTTP_NODEPORT\"<\/span> \"$HTTPS_NODEPORT\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
      In this example, HTTP was 31960<\/code> and HTTPS was 30251<\/code>.<\/p>\n\n\n\n
      \n\n\n\n
      Phase 2 \u2014 Diagnose and fix the Calico cross-node routing issue<\/h1>\n\n\n\n
      \n
      Only apply this change if you have the same problem.<\/strong> A healthy Calico cluster can use VXLAN, IP-in-IP, or unencapsulated routing with correctly configured BGP\/underlay routes. ipipMode: Never<\/code> and vxlanMode: Never<\/code> are not inherently invalid<\/strong>; the failure in this lab was that there was no functional route to the other node’s Pod CIDR<\/strong>.<\/p>\n<\/blockquote>\n\n\n\n
      2.1 The observed error<\/h2>\n\n\n\n
      Attempting to create ing.yaml<\/code> originally failed with:<\/p>\n\n\n
      Error<\/span> from<\/span> server (InternalError<\/span>):\nfailed calling webhook \"validate.nginx.ingress.kubernetes.io\"<\/span>:\nPost \"https:\/\/ingress-nginx-controller-admission.ingress-nginx.svc:443\/networking\/v1\/ingresses?timeout=10s\"<\/span>:\ncontext deadline exceeded\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      The controller Pod was 1\/1 Running<\/code>, the admission Service and EndpointSlice existed, and the controller logged Starting validation webhook address=\":8443\"<\/code>.<\/p>\n\n\n\n
      Interpretation:<\/strong> A Running Pod and populated Service endpoints are not proof of network reachability from the API server to the webhook<\/strong>.<\/p>\n\n\n\n
      2.2 Inspect admission Service and routes<\/h2>\n\n\n
      kubectl get<\/span> svc ingress-nginx-controller-admission -n ingress-nginx -o wide\n\nkubectl get<\/span> endpointslices -n ingress-nginx \\\n  -l kubernetes.io\/service-name=ingress-nginx-controller-admission\n\nkubectl get<\/span> pods -n ingress-nginx -o wide\n\nkubectl get<\/span> validatingwebhookconfiguration ingress-nginx-admission -o yaml\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Find the webhook Pod IP from the EndpointSlice\/Pod output. In the lab it was 192.168.131.65<\/code>.<\/p>\n\n\n\n
      On the control-plane node<\/strong>:<\/p>\n\n\n
      ip route get 192.168<\/span>.131<\/span>.65<\/span>\n\ncurl --noproxy '*'<\/span> -kv --connect-timeout 5<\/span> \\\n  https:\/\/192.168.131.65:8443\/<\/span>\n\ncurl --noproxy '*'<\/span> -kv --connect-timeout 5<\/span> \\\n  https:\/\/10.101.95.207:443\/<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
      Before the fix, both curl commands timed out<\/strong>, and routing looked like:<\/p>\n\n\n
      192.168<\/span>.131<\/span>.65<\/span> via<\/span> 172.31<\/span>.0<\/span>.1<\/span> dev<\/span> enX0<\/span> src<\/span> 172.31<\/span>.10<\/span>.122<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
      That was the AWS VPC gateway, not an appropriate configured overlay route to the remote Pod. This is a strong sign of missing remote Pod routing in this particular cluster<\/strong>, not a generic rule that any route through a gateway is wrong.<\/p>\n\n\n\n
      2.3 Check the existing Calico IPPool<\/h2>\n\n\n
      kubectl get<\/span> ippools.crd.projectcalico.org -o yaml\n\nkubectl get<\/span> pods -n kube-system -l k8s-app=calico-node -o wide\n\nip -d link show vxlan.calico || true\nip -d link show tunl0 || true\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Original lab IPPool:<\/p>\n\n\n
      metadata:\n  name: default<\/span>-ipv4-ippool\nspec<\/span>:\n  cidr: 192.168<\/span>.0<\/span>.0<\/span>\/16<\/span>\n  ipipMode<\/span>: Never\n  vxlanMode<\/span>: Never\n  natOutgoing<\/span>: true<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      No functioning cross-node Pod route was present. The vxlan.calico<\/code> interface did not exist, and tunl0<\/code> was down.<\/p>\n\n\n\n
      2.4 Check AWS network requirements before<\/strong> making the change<\/h2>\n\n\n\n
      For Calico VXLAN, allow UDP 4789 in both directions between the EC2 nodes<\/strong> (for example, using an appropriate EC2 security-group-to-security-group rule, or narrowly scoped private node IP rules). Check custom network ACLs and host firewalls as well.<\/p>\n\n\n\n
      Calico transport<\/th>Node-to-node traffic<\/th><\/tr><\/thead>
      VXLAN<\/td>UDP 4789<\/td><\/tr>
      IP-in-IP<\/td>IP protocol number 4<\/td><\/tr>
      BGP<\/td>TCP 179<\/td><\/tr>
      Unencapsulated\/direct routing<\/td>Pod CIDR reachability provided by the underlay and firewall rules<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      Do not<\/strong> open UDP 4789 to the public Internet. Allow client NodePort HTTP access only from trusted IP ranges for this lab.<\/p>\n\n\n\n
      \n
      Operator-managed Calico:<\/strong> If you installed Calico through the Tigera operator, check the Installation<\/code> resource. Operator-managed pools should be changed via Installation.spec.calicoNetwork.ipPools<\/code>, not patched directly; the operator can revert direct IPPool edits. The direct IPPool command below applies to this lab’s manifest-managed<\/strong> pool.<\/p>\n<\/blockquote>\n\n\n\n
      2.5 Back up and enable VXLAN Always (manifest-managed Calico)<\/h2>\n\n\n\n
      This changes network dataplane behavior and can briefly interrupt live connections. Back up your configuration and use a maintenance window on shared clusters.<\/p>\n\n\n
      <em># Backup<\/em><\/span>\nkubectl get ippools.crd.projectcalico.org \\\n  default<\/span>-ipv4-ippool -o yaml > calico-ippool-backup.yaml\n\n<em># Verify the pool name and current mode before modifying it<\/em><\/span>\nkubectl get ippools.crd.projectcalico.org \\\n  default<\/span>-ipv4-ippool \\\n  -o jsonpath='{.spec.cidr}{\"  IPIP=\"}{.spec.ipipMode}{\"  VXLAN=\"}{.spec.vxlanMode}{\"\\n\"}'<\/span>\n\n<em># Enable overlay routing on the existing IPPool<\/em><\/span>\nkubectl patch ippools.crd.projectcalico.org default<\/span>-ipv4-ippool \\\n  --type=merge \\\n  -p '{\"spec\":{\"ipipMode\":\"Never\",\"vxlanMode\":\"Always\"}}'<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
      \n
      Why Always<\/code>, not CrossSubnet<\/code>?<\/strong> The EC2 nodes are in the same VPC subnet (172.31.0.0\/20<\/code>). CrossSubnet<\/code> may skip encapsulation between them and therefore would not solve the missing Pod-CIDR underlay routing in this lab. Always<\/code> encapsulates cross-node traffic even when the nodes share a subnet.<\/p>\n<\/blockquote>\n\n\n\n
      For Tigera operator-managed Calico<\/strong>, instead inspect:<\/p>\n\n\n
      kubectl<\/span> get<\/span> installations<\/span>.operator<\/span>.tigera<\/span>.io<\/span> default<\/span> -o<\/span> yaml<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
      Use the operator’s documented encapsulation: VXLAN<\/code> setting for the appropriate IPPool definition in that Installation resource. Do not apply the direct patch if the operator manages the pool.<\/p>\n\n\n\n
      2.6 Verify VXLAN and the new route<\/h2>\n\n\n
      kubectl get<\/span> ippools.crd.projectcalico.org default-ipv4-ippool -o yaml\n\nip -d link show vxlan.calico\n\nip route get<\/span> 192.168.131.65\n\nkubectl get<\/span> pods -n kube-system -l k8s-app=calico-node -o wide\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Observed after the fix in this lab:<\/p>\n\n\n
      vxlan<\/span>.calico<\/span>: <BROADCAST<\/span>,MULTICAST<\/span>,UP<\/span>,LOWER_UP<\/span>> mtu<\/span> 1410\n    vxlan<\/span> id<\/span> 4096 local<\/span> 172.31<\/span>.10<\/span>.122<\/span> dev<\/span> enX0<\/span> dstport<\/span> 4789\n\n192.168<\/span>.131<\/span>.65<\/span> via<\/span> 192.168<\/span>.131<\/span>.80<\/span> dev<\/span> vxlan<\/span>.calico<\/span> src<\/span> 192.168<\/span>.90<\/span>.202<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
      Important:<\/strong> The interface and route prove that VXLAN is configured; they do not<\/strong> alone prove packets cross between EC2 hosts. Retest both webhook endpoints:<\/p>\n\n\n
      curl --noproxy '*'<\/span> -kv --connect-timeout 5<\/span> \\\n  https<\/span>:\/\/192.168.131.65:8443\/<\/span>\n\ncurl --noproxy '*'<\/span> -kv --connect-timeout 5<\/span> \\\n  https<\/span>:\/\/10.101.95.207:443\/<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Any genuine HTTP response (including an expected 404<\/code>\/400<\/code> for \/<\/code>) demonstrates reachability. The bare curl<\/code> to \/<\/code> is not a functional admission-validation test<\/strong>; it simply tests connection and TLS. The definitive admission check is that the subsequent Ingress creation succeeds.<\/p>\n\n\n\n
      If timeouts continue:<\/strong> check both EC2 security groups, return traffic\/NACLs and host firewalls, and capture traffic while making a request:<\/p>\n\n\n
      sudo tcpdump -ni enX0 udp port 4789<\/span>\n<em># In a second terminal, repeat curl to the Pod IP and Service IP.<\/em><\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
      If needed, review Calico logs:<\/p>\n\n\n
      kubectl logs -n kube-system -l k8s-app=calico-node \\\n  --all-containers=false<\/span> --tail=100<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      MTU note from this lab<\/h3>\n\n\n\n
      Calico also logged Failed to auto-detect host MTU - no interfaces matched the MTU interface pattern<\/code>. The EC2 interface was named enX0<\/code>; VXLAN later showed an MTU of 1410<\/code>.<\/p>\n\n\n\n
      This is a separate item to review<\/strong> if you observe packet loss or large-request failures. Check the underlay interface MTU, tunnel MTU and Calico’s configured detection settings before making any changes. Do not blindly assign a new MTU to every cluster.<\/p>\n\n\n
      ip link show enX0\nip -d link show vxlan.calico\nkubectl get<\/span> felixconfigurations.crd.projectcalico.org -o yaml\nkubectl get<\/span> cm calico-config -n kube-system -o yaml 2>\/dev\/null || true\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      \n\n\n\n
      Phase 3 \u2014 Deploy two application Deployments and ClusterIP Services<\/h1>\n\n\n\n
      3.1 Create apps.yaml<\/code><\/h2>\n\n\n\n
      Use different Docker images so that you can recognize which backend answered each request.<\/p>\n\n\n
      cat > apps.yaml <<'YAML'<\/span>\napiVersion<\/span>: apps\/v1\nkind<\/span>: Deployment\nmetadata<\/span>:\n  name: app1\n  namespace<\/span>: default<\/span>\nspec<\/span>:\n  replicas: 1<\/span>\n  selector<\/span>:\n    matchLabels:\n      app: app1\n  template<\/span>:\n    metadata:\n      labels:\n        app: app1\n    spec<\/span>:\n      containers:\n        - name: nginx\n          image<\/span>: scmgalaxy\/nginx-devopsschoolv1\n          ports<\/span>:\n            - containerPort: 80<\/span>\n---\napiVersion: v1\nkind<\/span>: Service\nmetadata<\/span>:\n  name: app1-service\n  namespace<\/span>: default<\/span>\nspec<\/span>:\n  type: ClusterIP\n  selector<\/span>:\n    app: app1\n  ports<\/span>:\n    - name: http\n      port<\/span>: 80<\/span>\n      targetPort<\/span>: 80<\/span>\n      protocol<\/span>: TCP\n---\napiVersion: apps\/v1\nkind<\/span>: Deployment\nmetadata<\/span>:\n  name: app2\n  namespace<\/span>: default<\/span>\nspec<\/span>:\n  replicas: 1<\/span>\n  selector<\/span>:\n    matchLabels:\n      app: app2\n  template<\/span>:\n    metadata:\n      labels:\n        app: app2\n    spec<\/span>:\n      containers:\n        - name: nginx\n          image<\/span>: scmgalaxy\/nginx-devopsschoolv2\n          ports<\/span>:\n            - containerPort: 80<\/span>\n---\napiVersion: v1\nkind<\/span>: Service\nmetadata<\/span>:\n  name: app2-service\n  namespace<\/span>: default<\/span>\nspec<\/span>:\n  type: ClusterIP\n  selector<\/span>:\n    app: app2\n  ports<\/span>:\n    - name: http\n      port<\/span>: 80<\/span>\n      targetPort<\/span>: 80<\/span>\n      protocol<\/span>: TCP\nYAML\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      3.2 Deploy and verify<\/h2>\n\n\n
      kubectl apply -f apps.yaml\n\nkubectl rollout status deployment\/app1 --timeout=120<\/span>s\nkubectl rollout status deployment\/app2 --timeout=120<\/span>s\n\nkubectl get<\/span> deployments app1 app2\nkubectl get<\/span> pods -l 'app in (app1,app2)' -o wide\nkubectl get<\/span> svc app1-service app2-service\n\nkubectl get<\/span> endpointslices -l kubernetes.io\/service-name=app1-service\nkubectl get<\/span> endpointslices -l kubernetes.io\/service-name=app2-service\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Example ClusterIP addresses previously assigned in the lab:<\/p>\n\n\n
      app1-service   ClusterIP   10.102.53.234    80\/TCP\napp2-service   ClusterIP   10.103.156.112   80\/TCP\n<\/code><\/span><\/pre>\n\n\n
      They may change if Services are recreated. The Services must have ready Pod endpoints for requests to succeed.<\/p>\n\n\n\n
      3.3 Validate each Service before introducing Ingress<\/h2>\n\n\n\n
      You can curl the ClusterIP from a cluster node if your node-to-Service networking is working:<\/p>\n\n\n
      curl -i --noproxy '*'<\/span> http:\/\/10.102.53.234\/<\/span>\ncurl -i --noproxy '*'<\/span> http:\/\/10.103.156.112\/<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Or discover the current Service IPs automatically:<\/p>\n\n\n
      APP1_IP=$(kubectl get svc app1-service -o jsonpath='{.spec.clusterIP}'<\/span>)\nAPP2_IP=$(kubectl get svc app2-service -o jsonpath='{.spec.clusterIP}'<\/span>)\n\ncurl -i --noproxy '*'<\/span> \"http:\/\/${APP1_IP}\/\"<\/span>\ncurl -i --noproxy '*'<\/span> \"http:\/\/${APP2_IP}\/\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
      Expected:<\/strong> Both root pages return HTTP 200<\/code> if the images serve \/<\/code>. App1 and App2 should show their respective version-specific content.<\/p>\n\n\n\n
      \n\n\n\n
      Phase 4 \u2014 Configure path-based Ingress with URL rewriting<\/h1>\n\n\n\n
      4.1 Understand why simple Prefix rules produced 404<\/h2>\n\n\n\n
      The first Ingress used:<\/p>\n\n\n
      - path: \/app1\n  pathType: Prefix\n  backend:\n    service:\n      name: app1-service\n      port:\n        number: 80\n<\/code><\/span><\/pre>\n\n\n
      A Kubernetes Prefix<\/code> match selects the backend Service but does not remove the prefix<\/strong>. The backend NGINX received \/app1<\/code> instead of \/<\/code> and returned:<\/p>\n\n\n
      HTTP\/1.1 404 Not Found\nnginx\/1.15.10\n<\/code><\/span><\/pre>\n\n\n
      In this lab the controller reported NGINX 1.27.1<\/code>, while the 404 page identified 1.15.10<\/code>, which was a useful clue that the error came from the backend application<\/strong>, not the controller’s default backend. The specific version string can vary.<\/p>\n\n\n\n
      4.2 Create the final ing.yaml<\/code><\/h2>\n\n\n\n
      This Ingress is controller-specific<\/strong>: the nginx.ingress.kubernetes.io\/*<\/code> annotations and regex capture rewrite depend on community ingress-nginx. Other ingress controllers may require different configuration.<\/p>\n\n\n
      cat > ing.yaml <<'YAML'\napiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n  name: path-based-ingress\n  namespace: default\n  annotations:\n    nginx.ingress.kubernetes.io\/use-regex: \"true\"\n    nginx.ingress.kubernetes.io\/rewrite-target: \/$2\nspec:\n  ingressClassName: nginx\n  rules:\n    - http:\n        paths:\n          - path: \/app1(\/|$)(.*)\n            pathType: ImplementationSpecific\n            backend:\n              service:\n                name: app1-service\n                port:\n                  number: 80\n          - path: \/app2(\/|$)(.*)\n            pathType: ImplementationSpecific\n            backend:\n              service:\n                name: app2-service\n                port:\n                  number: 80\nYAML\n<\/code><\/span><\/pre>\n\n\n
      Why ImplementationSpecific<\/code>?<\/strong> Kubernetes native path types are Exact<\/code>, Prefix<\/code>, and ImplementationSpecific<\/code>. The NGINX-specific regular expression must be handled by the controller, rather than interpreted as a Kubernetes-native Prefix<\/code> rule.<\/p>\n\n\n\n
      Why \/$2<\/code>?<\/strong> In each expression, (\/|$)<\/code> is capture group $1<\/code>, and (.*)<\/code> is capture group $2<\/code>. Ingress-nginx rewrites the forwarded URL to \/<\/code> plus the content of $2<\/code>.<\/p>\n\n\n\n
      Incoming path<\/th>Selected Service<\/th>Path the Pod receives<\/th><\/tr><\/thead>
      \/app1<\/code><\/td>app1-service:80<\/code><\/td>\/<\/code><\/td><\/tr>
      \/app1\/<\/code><\/td>app1-service:80<\/code><\/td>\/<\/code><\/td><\/tr>
      \/app1\/index.html<\/code><\/td>app1-service:80<\/code><\/td>\/index.html<\/code><\/td><\/tr>
      \/app2<\/code><\/td>app2-service:80<\/code><\/td>\/<\/code><\/td><\/tr>
      \/app2\/health<\/code><\/td>app2-service:80<\/code><\/td>\/health<\/code><\/td><\/tr>
      \/app3<\/code><\/td>No matching application rule<\/td>Controller default behavior (typically 404)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      4.3 Apply and verify the Ingress<\/h2>\n\n\n
      kubectl apply --dry-run=client -f ing.yaml\nkubectl apply -f ing.yaml\n\nkubectl get<\/span> ingress\nkubectl describe ingress path-based-ingress\nkubectl get<\/span> ingress path-based-ingress -o yaml\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      You should see IngressClass<\/code> nginx<\/strong>, paths for both Services, and the two rewrite annotations.<\/p>\n\n\n\n
      If kubectl apply<\/code> fails with an admission-webhook timeout, return to Phase 2<\/strong>. Do not<\/strong> delete the webhook as a normal fix. Admission validation is useful and should stay enabled.<\/p>\n\n\n\n
      \n\n\n\n
      Phase 5 \u2014 End-to-end validation<\/h1>\n\n\n\n
      5.1 Confirm networking, backend health, and controller<\/h2>\n\n\n
      kubectl get<\/span> nodes -o wide\nkubectl get<\/span> pods -n ingress-nginx -o wide\nkubectl get<\/span> pods -l 'app in (app1,app2)' -o wide\nkubectl get<\/span> svc app1-service app2-service\nkubectl get<\/span> ingress path-based-ingress\nkubectl get<\/span> ingressclass nginx\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      5.2 Discover NodePort and worker node address<\/h2>\n\n\n
      HTTP_NODEPORT=$(kubectl get svc ingress-nginx-controller -n ingress-nginx \\\n  -o jsonpath='{.spec.ports[?(@.name==\"http\")].nodePort}'<\/span>)\n\nWORKER_IP=172.31<\/span>.13<\/span>.14<\/span>  <em># Replace with a reachable node private IP<\/em><\/span>\n\nprintf 'Testing http:\/\/%s:%s\\n'<\/span> \"$WORKER_IP\"<\/span> \"$HTTP_NODEPORT\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
      Example:<\/strong> http:\/\/172.31.13.14:31960<\/code>.<\/p>\n\n\n\n
      5.3 Test both paths<\/h2>\n\n\n
      curl -i --noproxy '*'<\/span> \"http:\/\/${WORKER_IP}:${HTTP_NODEPORT}\/app1\"<\/span>\n\ncurl -i --noproxy '*'<\/span> \"http:\/\/${WORKER_IP}:${HTTP_NODEPORT}\/app2\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Expected:<\/strong> HTTP\/1.1 200 OK<\/code> and the body of NGINX demo v1 at \/app1<\/code> and demo v2 at \/app2<\/code> (assuming both images serve their root pages correctly).<\/p>\n\n\n\n
      Additional checks:<\/p>\n\n\n
      <em># Rewritten to \/index.html by ingress-nginx<\/em><\/span>\ncurl -i --noproxy '*'<\/span> \"http:\/\/${WORKER_IP}:${HTTP_NODEPORT}\/app1\/index.html\"<\/span>\ncurl -i --noproxy '*'<\/span> \"http:\/\/${WORKER_IP}:${HTTP_NODEPORT}\/app2\/index.html\"<\/span>\n\n<em># Negative test \u2014 no matching rule<\/em><\/span>\ncurl -i --noproxy '*'<\/span> \"http:\/\/${WORKER_IP}:${HTTP_NODEPORT}\/does-not-exist\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
      5.4 Check from a local laptop if EC2 NodePort is not directly reachable<\/h2>\n\n\n\n
      The lab uses private EC2 IP addresses. If your laptop is not connected to the VPC, use SSH\/VPN\/SSM to access a node, or run this temporary port-forward from a machine where kubectl<\/code> can reach the cluster:<\/p>\n\n\n
      kubectl -n ingress-nginx port-forward \\\n  svc\/ingress-nginx-controller 8080:80\n<\/code><\/span><\/pre>\n\n\n
      From another terminal on that same machine<\/strong>:<\/p>\n\n\n
      curl -i http:\/\/127.0.0.1:8080\/app1<\/span>\ncurl -i http:\/\/127.0.0.1:8080\/app2<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Port forwarding does not require exposing the NodePort to the public Internet.<\/p>\n\n\n\n
      5.5 Confirm which backend handled the request<\/h2>\n\n\n
      kubectl get<\/span> pods -l app=app1 -o wide\nkubectl get<\/span> pods -l app=app2 -o wide\n\nkubectl logs deployment\/app1 --tail=30\nkubectl logs deployment\/app2 --tail=30\n\nkubectl logs -n ingress-nginx \\\n  deployment\/ingress-nginx-controller --tail=60\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Compare page content and each application’s access logs after hitting \/app1<\/code> and \/app2<\/code>. Different Docker images make routing demonstrations much clearer.<\/p>\n\n\n\n
      \n\n\n\n
      Phase 6 \u2014 Troubleshooting reference<\/h1>\n\n\n\n
      Symptom<\/th>Likely cause<\/th>Checks \/ fix<\/th><\/tr><\/thead>
      failed calling webhook ... context deadline exceeded<\/code><\/td>API server cannot reach admission Service<\/td>Verify EndpointSlice, Pod route, CNI, kube-proxy, security groups, TCP 8443 \/ Service 443<\/td><\/tr>
      Pod IP and ClusterIP both time out from control plane<\/td>Cross-node Pod networking\/underlay or firewall issue<\/td>ip route get POD_IP<\/code>; verify Calico overlay and UDP 4789<\/td><\/tr>
      vxlan.calico<\/code> missing after patch<\/td>Calico not configured\/reconciled for VXLAN<\/td>IPPool mode, operator ownership, calico-node<\/code> logs and DaemonSet settings<\/td><\/tr>
      vxlan.calico<\/code> is UP but curl still times out<\/td>Packets blocked or reverse path broken<\/td>EC2 SG\/NACL, host firewall, tcpdump -ni enX0 udp port 4789<\/code><\/td><\/tr>
      Ingress admission succeeds but \/app1<\/code> is 404 from backend NGINX<\/td>Prefix path was not removed<\/td>Use regex pattern and rewrite annotation in Phase 4<\/strong><\/td><\/tr>
      Ingress returns 404 for \/app3<\/code><\/td>No matching rule<\/td>Expected unless another\/default backend is configured<\/td><\/tr>
      HTTP 503 from Ingress<\/td>Service has no ready backends, wrong name\/port, or backend unreachable<\/td>kubectl get endpointslices<\/code>; Pod readiness; service selectors<\/td><\/tr>
      NodePort request cannot connect<\/td>Wrong NodePort, no reachable node IP, or blocked ingress traffic<\/td>Query actual Service NodePort; test from node\/VPC or port-forward<\/td><\/tr>
      502\/504 or intermittent issues<\/td>Backend\/process failure, CNI problems, traffic policies<\/td>Logs, Pod health, NetworkPolicies, MTU and packet captures<\/td><\/tr>
      LoadBalancer Service EXTERNAL-IP is <pending><\/code><\/td>No cloud LB integration in self-managed cluster<\/td>For this lab use the ingress-nginx NodePort<\/code> Service<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      Deep-dive diagnostic commands<\/h3>\n\n\n
      <em<\/span>><\/span># Ingress details<\/em<\/span>><\/span>\nkubectl describe ingress path-based-ingress\nkubectl get ingress path-based-ingress -o yaml\n\n<em<\/span>><\/span># Controller and admission endpoints<\/em<\/span>><\/span>\nkubectl get svc -n ingress-nginx\nkubectl get endpointslices -n ingress-nginx \\\n  -l kubernetes.io\/service-name=ingress-nginx-controller-admission\nkubectl logs -n ingress-nginx deployment\/ingress-nginx-controller --tail=100\n\n<em<\/span>><\/span># Networking and routes<\/em<\/span>><\/span>\nkubectl get ippools.crd.projectcalico.org -o yaml\nkubectl get pods -n kube-system -o wide\nip route\nip -d link show vxlan.calico\n\n<em<\/span>><\/span># Backend Pods and endpoints<\/em<\/span>><\/span>\nkubectl describe deployment app1\nkubectl describe deployment app2\nkubectl get endpointslices -l kubernetes.io\/service-name=app1-service\nkubectl get endpointslices -l kubernetes.io\/service-name=app2-service\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
      \n
      Avoid the unsafe shortcut:<\/strong> Changing the admission webhook to failurePolicy: Ignore<\/code> is not a networking fix. It can mask errors. If temporarily used for an isolated lab diagnosis, restore the original validation policy afterward and verify that admission calls succeed normally.<\/p>\n<\/blockquote>\n\n\n\n
      \n\n\n\n
      Phase 7 \u2014 Optional cleanup and rollback<\/h1>\n\n\n\n
      Delete only the demo Ingress and applications<\/h2>\n\n\n
      kubectl delete<\/span> -f ing.yaml\nkubectl delete<\/span> -f apps.yaml\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Remove the lab controller only if it is not used elsewhere<\/h2>\n\n\n
      kubectl delete<\/span> -f https:\/\/raw.githubusercontent.com\/kubernetes\/ingress-nginx\/controller-v1.15.1\/deploy\/static\/provider\/baremetal\/deploy.yaml<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Caution:<\/strong> This can disrupt other Ingress resources that depend on the same controller. Do not remove it on a shared cluster without checking usage.<\/p>\n\n\n\n
      Roll back Calico encapsulation only when you have a working alternative route<\/h2>\n\n\n\n
      Do not<\/strong> blindly revert VXLAN to Never<\/code>: that would recreate the original cross-node failure unless you first set up working BGP\/unencapsulated routing or an alternative overlay. Keep the backup file for review; do not apply a stale backup automatically to a changed production cluster.<\/p>\n\n\n\n
      \n\n\n\n
      Final success checklist<\/h1>\n\n\n\n