You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/advance/ovn-eip-fip-snat.en.md
+101-2Lines changed: 101 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -36,8 +36,7 @@ The CRD supported by this function is basically the same as the iptable nat gw p
36
36
37
37
## 1. Deployment
38
38
39
-
Currently allows all vpcs to share the same provider vlan subnet resources, similar to neutron ovn mode.
40
-
Compatible with previous scenarios [default VPC EIP/SNAT](../guide/eip-snat.en.md).
39
+
Currently allows all vpcs to share the same default provider vlan subnet resources, custom vpcs support extending provider vlan subnet to enable the use of multiple public networks. similar to neutron ovn mode. Compatible with previous scenarios [default VPC EIP/SNAT](../guide/eip-snat.en.md).
41
40
42
41
During the deployment phase, you may need to specify a default public network logical switch based on actual conditions.
43
42
If no vlan is in use (vlan 0 is used), the following startup parameters do not need to be configured.
@@ -130,6 +129,13 @@ Of course, you can also manually create the lrp type ovn eip in advance.
130
129
131
130
### 1.3 Custom vpc enable eip snat fip function
132
131
132
+
Clusters generally require multiple gateway nodes to achieve high availability. The configuration is as follows:
# The route currently supports automatic maintenance
203
209
```
204
210
211
+
### 1.4 Use additional public network
212
+
213
+
#### 1.4.1 Create additional underlay public network
214
+
215
+
Additional public network functions will be enabled after the default eip snat fip function is enabled. If there is only 1 public network card, please use the default eip snat fip function.
216
+
217
+
```yaml
218
+
# provider-network, vlan, subnet
219
+
# cat 01-extra-provider-network.yaml
220
+
apiVersion: kubeovn.io/v1
221
+
kind: ProviderNetwork
222
+
metadata:
223
+
name: extra
224
+
spec:
225
+
defaultInterface: vlan
226
+
# cat 02-extra-vlan.yaml
227
+
apiVersion: kubeovn.io/v1
228
+
kind: Vlan
229
+
metadata:
230
+
name: vlan0
231
+
spec:
232
+
id: 0
233
+
provider: extra
234
+
# cat 03-extra-vlan-subnet.yaml
235
+
apiVersion: kubeovn.io/v1
236
+
kind: Subnet
237
+
metadata:
238
+
name: extra
239
+
spec:
240
+
protocol: IPv4
241
+
cidrBlock: 10.10.204.0/24
242
+
gateway: 10.10.204.254
243
+
vlan: vlan0
244
+
excludeIps:
245
+
- 10.10.204.1..10.10.204.100
246
+
```
247
+
248
+
#### 1.4.2 Custom vpc configuration
249
+
250
+
```yaml
251
+
apiVersion: kubeovn.io/v1
252
+
kind: Vpc
253
+
metadata:
254
+
name: vpc1
255
+
spec:
256
+
namespaces:
257
+
- vpc1
258
+
staticRoutes: # configure routing rules: Which additional public network routes a subnet under the vpc needs to be based on needs to be added manually. The following example is for reference only. Users need to configure it according to their actual situation.
259
+
- cidr: 192.168.0.1/28
260
+
nextHopIP: 10.10.204.254
261
+
policy: policySrc
262
+
enableExternal: true # vpc enableExternal will automatically create an lrp association to the public network specified above
263
+
addExternalSubnets: # configure addExternalSubnets to support connecting multiple additional public networks
264
+
- extra
265
+
```
266
+
267
+
After the above template is applied, you should see the following resources exist
# The route currently supports automatic maintenance
292
+
# Additional public networks require manual routing configuration in the vpc. In the above example, the source IP address is 192.168.0.1/28 and will be forwarded to the additional public network.
293
+
# Users can manually configure routing rules according to the situation
294
+
```
295
+
205
296
## 2. ovn-eip
206
297
207
298
This function is designed and used in the same way as iptables-eip, ovn-eip currently has three types
@@ -224,6 +315,8 @@ spec:
224
315
# Dynamically allocate an eip resource that is reserved for fip dnat_and_snat scenarios
225
316
```
226
317
318
+
When an additional public network is configured, you can specify the public network that needs to be expanded through externalSubnet. In the above configuration, external204 and extra are optional.
319
+
227
320
### 2.1 Create an fip for pod
228
321
229
322
```bash
@@ -450,6 +543,8 @@ spec:
450
543
451
544
```
452
545
546
+
When an additional public network is configured, you can specify the public network that needs to be expanded through externalSubnet. In the above configuration, external204 and extra are optional.
547
+
453
548
### 3.2 ovn-snat corresponds to a pod IP
454
549
455
550
This feature is designed and used in much the same way as iptables-snat
@@ -488,6 +583,8 @@ spec:
488
583
489
584
```
490
585
586
+
When an additional public network is configured, you can specify the public network that needs to be expanded through externalSubnet. In the above configuration, external204 and extra are optional.
587
+
491
588
After the above resources are created, you can see the following resources that the snat public network feature depends on.
492
589
493
590
```bash
@@ -613,6 +710,8 @@ spec:
613
710
614
711
```
615
712
713
+
When an additional public network is configured, you can specify the public network that needs to be expanded through externalSubnet. In the above configuration, external204 and extra are optional.
714
+
616
715
The configuration of OvnDnatRule is similar to that of IptablesDnatRule.
0 commit comments