-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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 config ingress gateway #2434
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lichuqiang: 6 warnings.
In response to this:
Fixes #1969
Proposed Changes
- add clusteringress config
- update ingress reconciler to watch the configmap
- remove knative-ingressgateway usage
- add docs to tell how to set up gateway
Release Note
allow config ingress gateway
/area networking
/kind feature
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
10742d4
to
16500d5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lichuqiang: 2 unresolved warnings and 0 new warnings.
In response to this:
/lint
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
cdb16d1
to
ef0e6a7
Compare
f9f4dfe
to
7ed751f
Compare
f1bf86a
to
b4333b6
Compare
/retest |
The integration tests won't pass until we update the test dependency in pkg repo. But I'd make sure the code is fine to merge before that. As it will block things if we update the pkg repo first and not be able to get this merged. Let me rebase onto the newest code first :) |
b4333b6
to
9677c9e
Compare
The PR is ready for review :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
Thanks a lot for making this change.
There are two comments relating to replacing some docs with example bash commands and automation of knative-shared-gateway
updates, but feel free to address them in future PR.
Replace its label selector with the label of your service: | ||
|
||
``` | ||
istio: ingressgateway |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this step can be automated by reading the label selector of custom-ingressgateway.istio-system.svc
, may be from the ClusterIngress controller.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I think we could address this before merging the PR.
A tiny issue is that the automatically generated label selector can be different from what users initially wanted to see.
e.g. in current knative-shared-gateway, the labels in selector is "knative: ingressgateway", while in the service, the labels in selector are "app: knative-ingressgateway, knative: ingressgateway".
But it has no functional effect, so I think it's fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've got an implementation here: lichuqiang@a624bee
But the modification is bigger than I expected. So let's address it in another PR, to keep things light.
And I can't decide how to deal with the servers
(port
) info update in gateway. The fields can also change, and might not so regular like that of selector: Users probably only want to expose some of the service ports in the gateway.
Maybe we should just leave that to users for manually update?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's discuss in the follow up PR instead.
I think we should only propagate changes related to the label selector to Gateway.
docs/setting-up-ingress-static-ip.md
Outdated
``` | ||
|
||
The result should be something like | ||
|
||
```console | ||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE | ||
knative-ingressgateway LoadBalancer 10.50.250.120 35.210.48.100 80:32380/TCP,443:32390/TCP,32400:32400/TCP 5h | ||
istio-ingressgateway LoadBalancer 10.50.250.120 35.210.48.100 80:31380/TCP,443:31390/TCP,31400:31400/TCP... 5h |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indent columns?
|
||
Here is an example: | ||
|
||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we instead provide some bash command instead? Either way we will run into staleness issue, which may be fine for an example, but the substitution command will (hopefully) explain the idea better since it's not obvious from the yaml what the difference.
That's not blocking, we can follow up with another PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/retest |
@mattmoor these tests won't pass until we pull in the new hard coded from knative/pkg, but if we land the change in pkg too early it would break other people's tests |
@liquchiang I am not sure your changes in knative/pkg would address upgrade test. The only way I can think of is instead we get the IP address to test based on the ExternalName pre-Route Service. |
Hmm, as I see, the upgrade test is to test if we still can access to an existing service in the env after serving components upgrade. |
@lichuqiang I see. I was only worried that the upgrade test will use the same hard-coded load balancer to test that a service in both the old-version and new-version is accessible through the same gateway IP address. I am not sure if this is the case, may be the upgrade test won't both with checking the service is accessible in the old-version. @jonjohnsonjr can you please clarify whether we send requests to a service when bringing it up in old-version? |
I haven't ready too much into this so forgive me if I'm missing something, but I think we'd have to make some changes either to the upgrade test or to the spoof client. The upgrade test uses the spoof client from HEAD, so you'd be unable to hit the old service (pre-upgrade and post-downgrade) if you just fix the spoof client to use We might need some fancy logic to fallback to |
I get your point. Let me add some compatibility into the spoof client |
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the |
a26334c
to
f64c1ca
Compare
CLAs look good, thanks! |
The following is the coverage report on pkg/.
|
/test pull-knative-serving-integration-tests |
1 similar comment
/test pull-knative-serving-integration-tests |
/retest |
/test pull-knative-serving-integration-tests |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lichuqiang, mattmoor, tcnghia The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
Fixes #1969
Proposed Changes
Release Note
/area networking
/kind feature