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/vip.en.md
+122Lines changed: 122 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -5,6 +5,10 @@ In some scenarios we want to dynamically reserve part of the IP but not assign i
5
5
- Kubernetes nested Kubernetes scenarios where the upper Kubernetes uses the Underlay network take up the available addresses of the underlying Subnet.
6
6
- LB or other network infrastructure requires the use of an IP within a Subnet.
7
7
8
+
In addition, VIP can also reserve IP for Allowed-Address-Pairs to support scenarios where a single network card is configured with multiple IPs, e.g:
9
+
10
+
- Keepalived can help achieve fast failover and flexible load balancing architecture by configuring additional IP address pairs.
11
+
8
12
## Create Random Address VIP
9
13
10
14
If you just want to set aside a number of IPs and have no requirement for the IP addresses themselves, you can use the following yaml to create them:
@@ -59,8 +63,126 @@ static-vip01 10.16.0.121 00:00:00:F0:DB:26 o
59
63
60
64
It can be seen that the VIP has been assigned the expected IP address.
Specify for `StatefulSet` and `VM` resources, these Pods their owned will reuse the VIP when these Pods recreating.
65
89
66
90
VM keep VIP must be enable the `keep-vm-ip` param in `kube-ovn-controller`. Refer [Kubevirt VM Fixed Address Settings](../guide/setup-options.en.md#kubevirt-vm)
91
+
92
+
## Create VIP to support AAP
93
+
94
+
```yaml
95
+
apiVersion: kubeovn.io/v1
96
+
kind: Vip
97
+
metadata:
98
+
name: vip-aap
99
+
spec:
100
+
subnet: ovn-default
101
+
namespace: default
102
+
selector:
103
+
- "app: aap1"
104
+
```
105
+
106
+
VIP also supports the allocation of fixed addresses and random addresses, and the allocation method is as described above.
107
+
108
+
- `namespace`: In the AAP scenario, VIP needs to explicitly specify the namespace. VIP only allows resources in the same namespace to enable the AAP function.
109
+
- `selector`: In the AAP scenario, the node selector used to select the Pod attached to the vip has the same format as the NodeSelector in Kubernetes.
110
+
111
+
Query the Port corresponding to the VIP after creation:
You can use annotation to specify a VIP to enable the AAP function, and labels need to meet the conditions of the node selector in the VIP.
123
+
124
+
Pod supports specifying multiple VIPs, with a configuration format of: ovn.kubernetes.io/aaps: vip-aap,vip-aap2,vip-aap3
125
+
126
+
The AAP function supports [multiple interfaces] (./multi-nic.en.md). If the Pod is configured with multiple interfaces, AAP will configure the corresponding Port in the same subnet of the Pod and the VIP.
127
+
128
+
```yaml
129
+
apiVersion: v1
130
+
kind: Pod
131
+
metadata:
132
+
name: busybox
133
+
annotations:
134
+
ovn.kubernetes.io/aaps: vip-aap
135
+
labels:
136
+
app: aap1
137
+
spec:
138
+
containers:
139
+
- name: busybox
140
+
image: busybox
141
+
command: ["sleep", "3600"]
142
+
securityContext:
143
+
capabilities:
144
+
add:
145
+
- NET_ADMIN
146
+
```
147
+
148
+
Query the configuration corresponding to the AAP after creation:
149
+
150
+
```bash
151
+
# kubectl ko nbctl list logical_switch_port aap-vip
Virtual ip is configured as an IP reserved for VIP, while virtual parents are configured as the port corresponding to the pod that enables AAP function.
172
+
173
+
Query the configuration corresponding to the Pod after creation:
174
+
175
+
```bash
176
+
# kubectl exec -it busybox -- ip addr add 10.16.0.100/16 dev eth0
177
+
# kubectl exec -it busybox01 -- ip addr show eth0
178
+
35: eth0@if36: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1400 qdisc noqueue
inet 10.16.0.7/16 brd 10.16.255.255 scope global eth0
181
+
valid_lft forever preferred_lft forever
182
+
inet 10.16.0.100/16 scope global secondary eth0
183
+
valid_lft forever preferred_lft forever
184
+
inet6 fe80::200:ff:fee2:ab0c/64 scope link
185
+
valid_lft forever preferred_lft forever
186
+
```
187
+
188
+
In addition to the IP automatically assigned during Pod creation, the VIP IP has also been successfully bound, and other Pods within the current subnet can communicate with these two IPs.
0 commit comments