Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Knative Services to not be exposed via Ingress #2127

Closed
scothis opened this issue Oct 1, 2018 · 6 comments
Closed

Allow Knative Services to not be exposed via Ingress #2127

scothis opened this issue Oct 1, 2018 · 6 comments
Assignees
Labels
area/API API objects and controllers area/networking kind/feature Well-understood/specified features, ready for coding.
Milestone

Comments

@scothis
Copy link
Contributor

scothis commented Oct 1, 2018

Expected Behavior

It should be possible to create a Knative Service that is not exposed via Ingress. This could be an event driven function that is invoked internally and should never be exposed to the public.

The same surgical routing that the Route resource provides for canaries and blue/green deployments is still desired. The only expected difference is that traffic from outside the cluster should be rejected.

Actual Behavior

All Knative Services are exposed publicly via Ingress.

Additional Info

This is an issue I've considered opening in the past. An attendee at SpringOne asked if this was possible. Unfortunately, I don't have more specifics about the particular use case.

/cc @tcnghia

@knative-prow-robot knative-prow-robot added area/API API objects and controllers area/networking kind/feature Well-understood/specified features, ready for coding. labels Oct 1, 2018
@tcnghia
Copy link
Contributor

tcnghia commented Oct 1, 2018

Thanks for opening this issue. The same has been raised by many other users. We should prioritize this.

@tcnghia
Copy link
Contributor

tcnghia commented Oct 1, 2018

Since we are currently using Istio Gateway pods to avoid requiring Istio sidecar for making request to Route's internal domain, we can just simply drop the Route's VirtualService from the Gateway.

We probably will need to find another way to still expose the Route's internal domain for cluster local access without sidecar.

@tcnghia tcnghia self-assigned this Oct 1, 2018
tcnghia pushed a commit to tcnghia/serving that referenced this issue Oct 5, 2018
knative-prow-robot pushed a commit that referenced this issue Oct 5, 2018
)

* Add new type ClusterIngress and some basic validation & defaults.

* Fix doc of ClassAnnotationKey.

* Add OWNERS file.

* Update documentation to highlight relation to K8s Ingress.

* Add duck.VerifyType checks.

* Update PR feedback.

* Address PR feedback.

* Update based on PR feedback.

* Update PR feedback.

* Add TODO linking to #2127.

* Update PR feedback.

* Address PR feedback.
@mattmoor
Copy link
Member

We get this ask a lot. Let's consider it for 0.3?

@tcnghia
Copy link
Contributor

tcnghia commented Nov 6, 2018

/assign @lichuqiang

@ZhiminXiang
Copy link

/cc

@sebgoa
Copy link
Contributor

sebgoa commented Dec 17, 2018

I mentioned this early in August. I would consider this a blocker.

So big +1

tcnghia added a commit to tcnghia/networking that referenced this issue May 16, 2020
…151)

* Add new type ClusterIngress and some basic validation & defaults.

* Fix doc of ClassAnnotationKey.

* Add OWNERS file.

* Update documentation to highlight relation to K8s Ingress.

* Add duck.VerifyType checks.

* Update PR feedback.

* Address PR feedback.

* Update based on PR feedback.

* Update PR feedback.

* Add TODO linking to knative/serving#2127.

* Update PR feedback.

* Address PR feedback.
tcnghia added a commit to knative/networking that referenced this issue May 16, 2020
…151)

* Add new type ClusterIngress and some basic validation & defaults.

* Fix doc of ClassAnnotationKey.

* Add OWNERS file.

* Update documentation to highlight relation to K8s Ingress.

* Add duck.VerifyType checks.

* Update PR feedback.

* Address PR feedback.

* Update based on PR feedback.

* Update PR feedback.

* Add TODO linking to knative/serving#2127.

* Update PR feedback.

* Address PR feedback.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/API API objects and controllers area/networking kind/feature Well-understood/specified features, ready for coding.
Projects
None yet
Development

No branches or pull requests

7 participants