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 config ingress gateway #2434

Merged
merged 5 commits into from Nov 30, 2018

Conversation

lichuqiang
Copy link
Contributor

@lichuqiang lichuqiang commented Nov 8, 2018

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

- Remove `knative-ingressgateway`.
- Allow users to choose an alternative gateway other than `istio-ingressgateway`. 

/area networking
/kind feature

@knative-prow-robot knative-prow-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. area/networking kind/feature Well-understood/specified features, ready for coding. labels Nov 8, 2018
@knative-prow-robot knative-prow-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Nov 8, 2018
Copy link
Contributor

@knative-prow-robot knative-prow-robot left a 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.

pkg/reconciler/v1alpha1/clusteringress/config/store.go Outdated Show resolved Hide resolved
pkg/reconciler/v1alpha1/clusteringress/config/store.go Outdated Show resolved Hide resolved
pkg/reconciler/v1alpha1/clusteringress/config/store.go Outdated Show resolved Hide resolved
pkg/reconciler/v1alpha1/clusteringress/config/store.go Outdated Show resolved Hide resolved
pkg/reconciler/v1alpha1/clusteringress/config/store.go Outdated Show resolved Hide resolved
pkg/reconciler/v1alpha1/clusteringress/config/store.go Outdated Show resolved Hide resolved
Copy link
Contributor

@knative-prow-robot knative-prow-robot left a 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.

@lichuqiang lichuqiang force-pushed the remove_gateway branch 2 times, most recently from cdb16d1 to ef0e6a7 Compare November 12, 2018 01:49
@lichuqiang lichuqiang force-pushed the remove_gateway branch 2 times, most recently from f9f4dfe to 7ed751f Compare November 13, 2018 12:39
@lichuqiang lichuqiang changed the title WIP: Allow config ingress gateway Allow config ingress gateway Nov 13, 2018
@knative-prow-robot knative-prow-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 13, 2018
@lichuqiang lichuqiang force-pushed the remove_gateway branch 2 times, most recently from f1bf86a to b4333b6 Compare November 16, 2018 08:52
@tcnghia
Copy link
Contributor

tcnghia commented Nov 19, 2018

/retest

@lichuqiang
Copy link
Contributor Author

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 :)

@knative-prow-robot knative-prow-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Nov 20, 2018
@lichuqiang
Copy link
Contributor Author

The PR is ready for review :)

Copy link
Contributor

@tcnghia tcnghia left a 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
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

```

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
Copy link
Contributor

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:

```
Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mattmoor
Copy link
Member

/retest

@tcnghia
Copy link
Contributor

tcnghia commented Nov 22, 2018

@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

@tcnghia
Copy link
Contributor

tcnghia commented Nov 22, 2018

@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.

@lichuqiang
Copy link
Contributor Author

lichuqiang commented Nov 23, 2018

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.
And with the change in knative/pkg, both the ingress service under knative shared gateway and the request url in spoof client should be updated to istio-ingressgateway. Am I missing something?

@tcnghia
Copy link
Contributor

tcnghia commented Nov 23, 2018

@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?

@jonjohnsonjr
Copy link
Contributor

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 istio-ingressgateway.

We might need some fancy logic to fallback to knative-ingressgateway here if istio-ingressgateway doesn't exist.

@lichuqiang
Copy link
Contributor Author

I get your point. Let me add some compatibility into the spoof client

@knative-prow-robot knative-prow-robot removed the lgtm Indicates that a PR is ready to be merged. label Nov 28, 2018
@googlebot
Copy link

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 cla/google commit status will not change from this state. It's up to you to confirm consent of all the commit author(s), set the cla label to yes (if enabled on your project), and then merge this pull request when appropriate.

@googlebot
Copy link

CLAs look good, thanks!

@knative-metrics-robot
Copy link

The following is the coverage report on pkg/.
Say /test pull-knative-serving-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/v1alpha1/clusteringress/clusteringress.go 70.1% 82.4% 12.3

@tcnghia
Copy link
Contributor

tcnghia commented Nov 30, 2018

/test pull-knative-serving-integration-tests

1 similar comment
@tcnghia
Copy link
Contributor

tcnghia commented Nov 30, 2018

/test pull-knative-serving-integration-tests

@tcnghia
Copy link
Contributor

tcnghia commented Nov 30, 2018

/retest

@tcnghia
Copy link
Contributor

tcnghia commented Nov 30, 2018

/test pull-knative-serving-integration-tests

@mattmoor
Copy link
Member

/approve

@knative-prow-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@knative-prow-robot knative-prow-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 30, 2018
@tcnghia
Copy link
Contributor

tcnghia commented Nov 30, 2018

/lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/networking kind/feature Well-understood/specified features, ready for coding. lgtm Indicates that a PR is ready to be merged. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants