Can Ingress route requests based on ip?

nginx ingress controller
kubernetes ingress
kubectl get ingress controller
gke ingress
kubernetes ingress annotations
kubernetes ingress multiple paths
kubernetes ingress tutorial
kubectl describe ingress

I have been with K8s-ingress well so far but I have a question.

Can ingress route requests based on IP?

I've already know that ingress do routing based on hosts like a.com, b.com... to each services and URI like path /a-service/, /b-service/ to each services.

However, I'm curious with the idea that Ingress can route by IP? I'd like requests from my office(certain ip) to route a specific service for tests.

Does it make sense? and any idea for that?

If this is just for testing I would just whitelist the IP. You can read the docs about nginx ingress annotations

You can specify allowed client IP source ranges through the nginx.ingress.kubernetes.io/whitelist-source-range annotation. The value is a comma separated list of CIDRs, e.g. 10.0.0.0/24,172.10.0.1.

Example yaml might look like this:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: whitelist
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: "1.1.1.1/24"
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /
        backend:
          serviceName: echoheaders
          servicePort: 80

Also it looks like you can do that in Istio (I did not tried it) in kind ServiceRole and ServiceRoleBinding for specifying detailed access control requirements. For this you would use source.ip property. It's explained on Constraints and Properties

Ingress, For example, the following Ingress resource will route to the IP address without a hostname defined in request� Welcome to a blog series titled Kubernetes Ingress 101: Why and How, inspired by my talk at the Open Source Summit with Theodora Cheng. Photo by Matthew T Rader on Unsplash Series overview: One of

This is not part of the main Ingress abstraction as you noted, however many Ingress Controllers offer extra features through annotations or secondary CRDs. So in theory it could be added like that. I don't think any do routing like this though, so in practical terms, probably not available off the shelf.

Setting up HTTP(S) Load Balancing with Ingress, Find out the external IP address of the load balancer serving your routes the requests with path starting with /v2/ to the web2 Service; routes all other Name- based virtual hosting: You can use Ingress to reuse the load� If you would like to enable client source IP preservation for requests to containers in your cluster, add --set controller.service.externalTrafficPolicy=Local to the Helm install command. The client source IP is stored in the request header under X-Forwarded-For. When using an ingress controller with client source IP preservation enabled, TLS pass-through will not work.

As coderanger stated in his answer, ingress does not have it by default.

I'm not sure if IP based routing is the way to proceed, because how will you test/hit actual deployments/services from Office IP's when needed?

I think you can add a check to perform routing based on IP and header. For ex: you can pass a header 'redirect-to-test: true'. So if you set this to false, you can still access the production services.

Ingress - F5 Cloud Docs, You can use Ingress to make internal services reachable from outside the cluster. HTTP (and HTTPS) requests to the Ingress that match the host and path of the routes traffic from a single IP address to more than one Service, based on the� Re: MPLS - ingress routing for IP packet Hello, If you are querying from a CE router perspective and this router has multiple paths to the same destination prefix then route selection is based on the routing protocol you are using and normal L3 lookup is used.

Internal ingress NLB can't route to same IP as request was sent from , Based off of Kubernetes The Hard Way by Kelsey Hightower. Others: What happened: Setting up an internal ingress-nginx controller on my� Is it possible to route Ingress requests based on service labels instead of a service name? I would like to have 2 services with the same name but different label values. Can Ingress route traffic like this? service-name.labelA.com -> service with label = A service-name.labelB.com -> service with label = A Is it possible to do so?

Bare-metal considerations - NGINX Ingress Controller, In this mode, one node attracts all the traffic for the ingress-nginx Service IP. MetalLB can be deployed either with a simple Kubernetes manifest or with Helm. In order to preserve the source IP address in HTTP requests sent to NGINX, it is the externalIPs option causes kube-proxy to route traffic sent to arbitrary IP� An Ingress gives you a way to route requests to services based on the request host or path, centralizing a number of services into a single entrypoint. With an Ingress, there is no need to create a bunch of Load Balancers or exposing each service on the Node. You can simply consolidate your routing rules into a single resource. Ingress Options

Routing Applications in Kubernetes with Nginx-Ingress, Setting up nginx-ingress; Define Name based Routing; Define Path Based routing In case you are new to Alibaba Cloud, you can get $10 worth in credit through my referral link NodePort: Exposes the service on each Node's IP at a static port (the NodePort ) Its job is to satisfy requests for Ingresses. Using an ingress controller and ingress rules, a single IP address can be used to route traffic to multiple services in a Kubernetes cluster. This article shows you how to deploy the NGINX ingress controller in an Azure Kubernetes Service (AKS) cluster.

Comments
  • Eww. Sorry about that. Could I delete it?
  • Do you need ip based routing only for testing or is there any other use case also ?
  • @AnkitDeshpande Only for testing now.
  • I also came across this one, however, this is not what I want. Thank you though !
  • Thank you ! I will search for it more and think of my structure again.
  • FWIW a few controllers do allow IP-based ACLs, but not routing. So you could use a hostname-based route specifically for testing and then ACL-restrict it your office. You may also want to look into the (very complex) world of Service Mesh tools as they sometimes offer more complex networking goop.
  • Thank you for letting me know that idea. I've also searched for Istio but I'm quite new to k8s so I will adopt Istio later when I get used to k8s and need more complex network and other needs.
  • Let me try it out later. I decided to use a hostname-based route for that though.