Support for network changes starting with Istio v1.10 and greater #2538
Conversation
lennyphan
requested review from
jshum2479,
rjeberhard,
tbarnes-us and
ankedia
| @@ -142,6 +142,39 @@ If the WebLogic administration port is enabled on the Administration Server: | |||
| Additionally, when Istio support is enabled for a domain, the operator | |||
| ensures that the Istio sidecar is not injected into the introspector job's pods. | |||
|
|
|||
| #### Support for network changes in Istio v1.10 and later | |||
|
|
|||
| Prior to Istio release 1.10, the Istio Envoy proxy redirected all inbound traffic to the localhost | |||
There was a problem hiding this comment.
I don't think the "prior to" paragraph is necessary and you can just begin with "Starting with Istio 1.10". Also, let's link to that article describing the change.
There was a problem hiding this comment.
I see that you did link the article later. Move the link up here :)
There was a problem hiding this comment.
Changed. Moved the link up.
There was a problem hiding this comment.
Also, removed the text describing the previous Istio network behavior.
| were bound to the localhost interface in order for WebLogic to receive the inbound traffic. | ||
| Starting with Istio 1.10, the networking behavior was changed in that the proxy no longer redirects | ||
| the traffic to the localhost interface, but instead forwards it to the network interface associated | ||
| to the pod's IP. In order to support Istio v1.10 and later, as well as pre-1.10 releases, the |
There was a problem hiding this comment.
"pre-1.10 releases" -> "previous releases"
| |----|----|----|--------|-----| | ||
| |`T3Channel-lh01`| `5556` | `127.0.0.1` | `t3`| Yes | | ||
|
|
||
| To learn more about changes to Istio networking beginning with Istio 1.10, see [Upcoming networking changes in Istio 1.10](https://istio.io/latest/blog/2021/upcoming-networking-changes//). |
There was a problem hiding this comment.
Does the user need to do anything if upgrading istio from 1.9 to 1.10 or higher, does he/she needs to re-run the introspector by updating the introspectVersion or something else?
There was a problem hiding this comment.
This is a very good question. With this change, we can support all versions of Istio and so I don't believe re-running introspection would make much difference or is necessary. Do we have a documented process for upgrading Istio in a cluster? That is, do we recommend shutting down the domain before upgrading Istio or can you upgrade Istio while a domain is running?
| self.writeln("<d:listen-port f:combine-mode=\"add\">" + str(listen_port) + "</d:listen-port>") | ||
|
|
||
| def writePublicAddress(self, public_address): | ||
| self.writeln("<d:public-address f:combine-mode=\"add\">" + public_address + "</d:public-address>") |
There was a problem hiding this comment.
Will public_address be None and can sitconfig take None at this stanza (vs not set) ?
There was a problem hiding this comment.
MBean method for setting public address can handle null when looking at the generated MBean method implementation but added a conditional check. Please review.
Beginning with Istio v1.10, network changes were made by Istio where the proxy no longer redirects the traffic to the localhost interface, but instead forwards it to the network interface associated with the pod IP (e.g. eth0). Since the operator has to support all versions of Istio, we are adding additional WebLogic network channels for binding to the localhost and pod IP network interfaces. This will allow the WebLogic managed servers to continue to receive application traffic through either network interfaces. During introspection, copies of the readiness probe and any custom WebLogic NAP's are created and listening addresses set to '127.0.0.1' so that the NAP's are bound to the localhost interface. We continue to customize any existing defined NAPs and override the listening address by setting it to the defined service name (e.g. sample-domain1-managed-server${id}).
For DII and DomainOnPV domains, we generate additional NAP's in situational config files. For example:
<d:network-access-point f:combine-mode="add">
<d:name f:combine-mode="add">http-probe</d:name>
<d:protocol f:combine-mode="add">http</d:protocol>
<d:listen-address f:combine-mode="add">sample-domain1-admin-server.sample-domain1-ns</d:listen-address>
<d:public-address f:combine-mode="add">sample-domain1-admin-server.sample-domain1-ns</d:public-address>
<d:listen-port f:combine-mode="add">8888</d:listen-port>
<d:http-enabled-for-this-protocol f:combine-mode="add">true</d:http-enabled-for-this-protocol>
<d:outbound-enabled f:combine-mode="add">true</d:outbound-enabled>
<d:enabled f:combine-mode="add">true</d:enabled>
</d:network-access-point>
<d:network-access-point f:combine-mode="add">
<d:name f:combine-mode="add">http-probe-lh01</d:name>
<d:protocol f:combine-mode="add">http</d:protocol>
<d:listen-address f:combine-mode="add">127.0.0.1</d:listen-address>
<d:public-address f:combine-mode="add">sample-domain1-admin-server.sample-domain1-ns</d:public-address>
<d:listen-port f:combine-mode="add">8888</d:listen-port>
<d:http-enabled-for-this-protocol f:combine-mode="add">true</d:http-enabled-for-this-protocol>
<d:outbound-enabled f:combine-mode="add">true</d:outbound-enabled>
<d:enabled f:combine-mode="add">true</d:enabled>
</d:network-access-point>
Since container port names are limited to a maximum of 15 characters, we truncate the names of any cloned network channel to the first 10 characters and append the identifier '-lhNN' (e.g 'http-probe-lh01')
Have successfully run all Istio integration tests on Kind cluster using Istio v1.7.3, v1.10.4, and v1.11.2