Comments (10)
Regarding 1st item: Ingresses in kubernetes do not define any relation (i.e. precedence) between multiple routes/virtual hosts specified within the same ingress resources. Therefore, we don't "lose" anything if mapping a single ingress into an unordered set of route rules. This is the approach I took so far in the ingress controller work.
from pilot.
from pilot.
Regarding 2nd item: adding port (numbers and/or names) into the model (e.g., under WeightedDestination
seems to be the only viable way to capture user intent expressed in ingress resources. Aside from ingress rules, this can be used for rerouting traffic transparently between services (i.e., client addresses service-a:80, which is rerouted to service-b:8080 by the proxy).
from pilot.
Regarding 3rd item: ingresses allows to specify a default backend for requests that doesn't match any route. An ingress controller needs to honor that specification. If not specified, we can do anything we dim fit (reply with 404, use sidecar default route rules [what are these anyway], ...). My thinking is that 404 is the proper response for ingress traffic which do not meet any explicit user-provided routes.
from pilot.
I think we need to reconsider if a route rule spec is sufficient for ingress controller. It is not clear how to associate TLS certs, which are bound to specific hostnames, with a route rule or a destination policy. The hostname in ingress spec does not match the destination fields in route rules and policies. Moreover, the destination field in the ingress backend (service name) could benefit from applying route rules to it, to apply client side traffic shifting at the ingress proxy instead of standing up a separate proxy.
Maybe we should make ingress an explicit model element, like the route rule?
Do we lose any features that we get for free if we treat ingress rule like other route rules?
from pilot.
from pilot.
@rshriram: The Kubernetes ingress spec allows different TLS certs to be used based on host: https://github.com/kubernetes/kubernetes/blob/9497139cb62015905ba5b3d11836f2b0c117ff80/pkg/apis/extensions/types.go#L604
Currently, we map Kubernetes Ingress rules to Istio rules and we need some way to convey that information.
from pilot.
The hostname in ingress spec does not match the destination fields in route rules and policies.
Don't think it's a problem. We use the route rule's headers matching map to match on the host from ingress spec.
The destination field in the ingress backend (service name) could benefit from applying route rules to it
Definitely (#217). Does separating ingress rules and route rules will get us closer to that? I was thinking this could be somehow achieved by the ingressWatcher
processing both kind of rule kinds.
One incompatibility that we do have today is that we need to pass the target service port from the ingress spec to the ingress watcher. Today we do that uncleanly via the destination tags.
As for TLS, won't we need some way to specify certs location in the model, regardless of ingress?
Maybe we need to extend the model with some CertificateStore
.
from pilot.
For beta, we should define a unified ingress rule definition that covers k8s/extended ingress controllers/Istio use cases. It's clear now that we need a unified model to combine various sources of ingress definitions (k8s, deployment annotations, internal istio) that specifically covers edge traffic concerns (TLS, url/host rewriting) and that plays well with in-cluster routing.
from pilot.
The ingress is going nowhere and its a PITA. We should get rid of ingress and create our own front proxy using LB ports. Besides, @kyessenov has managed to combine ingress spec with route rules for most part. Close?
from pilot.
Related Issues (20)
- istioctl not defaulting ns to "default" HOT 1
- Sidecar injection with mutating webhooks HOT 4
- Tests :Sidecar injection with mutating webhooks HOT 3
- Istio injection is not working for modified Deployments. HOT 6
- Ingress with host network HOT 1
- Request Headers Route Rule with composite services does not work HOT 1
- handling service registry client errors HOT 3
- Redirecting all ingress http traffic to https HOT 1
- Relational database adapter for Pilot config store HOT 10
- Diego BBS adapter for Pilot platform data HOT 12
- bazel 0.7 - make setup fails with bazel error on macOS HOT 12
- Use readable cluster names in stats HOT 4
- Build fails on Intel for Istioctl(pilot) HOT 14
- destination.labels is ignored in weighted rule HOT 4
- fails to create mixer configs when namespace field is empty
- Compute Envoy config eagerly rather than on-demand HOT 33
- istioctl kube-inject doesn't work when my pod has 2 containers HOT 2
- Add a script to query pilot for proxy configurations HOT 1
- gRPC-web HOT 1
- How to access the external services when istio with sidecar injected. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pilot.