Allow traffic going outside the cluster#1123
Allow traffic going outside the cluster#1123mdemirhan merged 4 commits intoknative:masterfrom mdemirhan:istioegress2
Conversation
mdemirhan
commented
Jun 9, 2018
- Changed the default installation to allow traffic going outside without getting terminated by Istio's sidecar.
- Refactored config map informer in route controller to use a shared factory and reuse the same factory within the revision controller as well.
- NOTE: k8sflag with Dynamic setting was tested; however it was very inconsistent in getting updates to the config map, missing more than half of the updates. Because of that, ConfigMap informers are used to get changes in the config map.
…hout getting terminated by Istio's sidecar. * Refactored config map informer in route controller to use a shared factory and reuse the same factory within the revision controller as well. NOTE: k8sflag with Dynamic setting was tested; however it was very inconsistent in getting updates to the config map, missing more than half of the updates. Because of that, ConfigMap informers are used to get changes in the config map.
|
@vaikas-google and @grantr Funnily enough, we now need config map updates in another controller as well and I refactored my checkin today to do the thing I said we didn't need :) Please take a look. My first shot at this change was to use k8sflag package but it was very frequently missing updates and never getting them. That is why k8sflag with Dynamic option is not used here. |
|
The following is the coverage report on pkg/. Say
*TestCoverage feature is being tested, do not rely on any info here yet |
| elaInformerFactory := informers.NewSharedInformerFactory(elaClient, time.Second*30) | ||
| buildInformerFactory := buildinformers.NewSharedInformerFactory(buildClient, time.Second*30) | ||
| servingSystemInformerFactory := kubeinformers.NewFilteredSharedInformerFactory(kubeClient, | ||
| time.Minute*5, pkg.GetServingSystemNamespace(), nil) |
There was a problem hiding this comment.
Just curious where the 5 minutes comes from. Others are in 30 resync so just curious.
There was a problem hiding this comment.
With other informers, we end up reconciling everything every 30 seconds. I didn't think that we needed that aggressive reconcilliation for domain configuration or the network configuration - those should change only once in the lifetime of the cluster if ever. Also, the reconcilliation is needed only if we somehow missed the original notification that gets sent when the configuration changes (I don't know how we would miss the notification - may be when there are successive deletes and creates the ordering might cause an issue?).
Let me know if you want me to change this to 30 seconds.
| namespace: knative-serving-system | ||
| data: | ||
| # Specifies the IP ranges that Istio sidecar will intercept. | ||
| # Replace this with the IP ranges of your cluster. |
There was a problem hiding this comment.
Perhaps add an example of how to determine what this range is?
There was a problem hiding this comment.
hehe, I see it now below. perhaps:
Replace this with the IP ranges of your cluster (see below for some examples).
or just leave it as is. Just when I was reading this the first time, I was like roh-roh?
There was a problem hiding this comment.
I will add an extra (see below...) :)
| podTemplateAnnotations[sidecarIstioInjectAnnotation] = "true" | ||
|
|
||
| // Inject the IP ranges for istio sidecar configuration. | ||
| // We will inject this value only if all of the following is true: |
| // Inject the IP ranges for istio sidecar configuration. | ||
| // We will inject this value only if all of the following is true: | ||
| // - the config map contains a non-empty value | ||
| // - the user doesn't specify this annotation in their configuration |
There was a problem hiding this comment.
'in their configuration', meaning the pod template? Perhaps clarify.
There was a problem hiding this comment.
Yes, that is correct. Clarified in the comments.
| // - the user doesn't specify this annotation in their configuration | ||
| // - configured values are valid CIDR notation IP addresses | ||
| // If these conditions are not met, this value will be left untouched. | ||
| // * is a special value that is accepted as a valid. |
There was a problem hiding this comment.
What does * mean? It's valid, but is it obvious from Istio configuration? Does this mean all traffic is then intercepted?
There was a problem hiding this comment.
Yes, that is correct. I clarified in the comments.
|
The following is the coverage report on pkg/. Say
*TestCoverage feature is being tested, do not rely on any info here yet |
|
The following is the coverage report on pkg/. Say
*TestCoverage feature is being tested, do not rely on any info here yet |
|
/lgtm |
Can you tell me more about this? It does take a minute for the kubelet to pickup config map changes and update the mounted filesystem. |
# Conflicts: # pkg/controller/service/service.go
|
The following is the coverage report on pkg/. Say
*TestCoverage feature is being tested, do not rely on any info here yet |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mdemirhan, vaikas-google The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
The following is the coverage report on pkg/. Say
*TestCoverage feature is being tested, do not rely on any info here yet |
|
@mdemirhan: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. I understand the commands that are listed here. |
* Add update-ci to generate ci configs * Update README * Exclude mutli and init container image * Update to better message