mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 21:46:22 +01:00
Updates ADV errors for configuring network settings
This commit is contained in:
Steven Smith
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
df7d5c9350
commit
8a12e9fb51
@@ -6,8 +6,9 @@
|
||||
[id="nw-ipfailover-cluster-ha-ingress_{context}"]
|
||||
= High availability For ExternalIP
|
||||
|
||||
In non-cloud clusters, IP failover and `ExternalIP` to a service can be combined. The result is high availability services for users that create services using `ExternalIP`.
|
||||
[role="_abstract"]
|
||||
High availability for `ExternalIP` in non-cloud clusters of {product-title} combines IP failover with `ExternalIP` auto-assignment to ensure services remain accessible when nodes fail. You can configure this by using the same CIDR range for both `ExternalIP` auto-assignment and IP failover.
|
||||
|
||||
The approach is to specify an `spec.ExternalIP.autoAssignCIDRs` range of the cluster network configuration, and then use the same range in creating the IP failover configuration.
|
||||
To configure high availability for `ExternalIP`, you can specify a `spec.ExternalIP.autoAssignCIDRs` range of the cluster network configuration, and then use the same range in creating the IP failover configuration.
|
||||
|
||||
Because IP failover can support up to a maximum of 255 VIPs for the entire cluster, the `spec.ExternalIP.autoAssignCIDRs` must be `/24` or smaller.
|
||||
|
||||
@@ -6,21 +6,20 @@
|
||||
[id="nw-ipfailover-configuration_{context}"]
|
||||
= Configuring IP failover in your cluster
|
||||
|
||||
As a cluster administrator, you can configure IP failover on an entire cluster, or on a subset of nodes, as defined by the label selector. You can also configure multiple IP failover deployments in your cluster, where each one is independent of the others.
|
||||
[role="_abstract"]
|
||||
To configure IP failover in your {product-title} cluster and provide high availability for Virtual IP addresses, you can create a deployment that runs Keepalived on selected nodes to monitor services and fail over VIPs when nodes become unavailable.
|
||||
|
||||
The IP failover deployment ensures that a failover pod runs on each of the nodes matching the constraints or the label used.
|
||||
|
||||
This pod runs Keepalived, which can monitor an endpoint and use Virtual Router Redundancy Protocol (VRRP) to fail over the virtual IP (VIP) from one node to another if the first node cannot reach the service or endpoint.
|
||||
The IP failover deployment ensures that a failover pod runs on each of the nodes matching the constraints or the label used. The pod, which runs Keepalived, can monitor an endpoint and use Virtual Router Redundancy Protocol (VRRP) to fail over the virtual IP (VIP) from one node to another if the first node cannot reach the service or endpoint.
|
||||
|
||||
For production use, set a `selector` that selects at least two nodes, and set `replicas` equal to the number of selected nodes.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* You are logged in to the cluster as a user with `cluster-admin` privileges.
|
||||
* You created a pull secret.
|
||||
* You have logged in to the cluster as a user with `cluster-admin` privileges.
|
||||
* You have created a pull secret.
|
||||
* {rh-openstack-first} only:
|
||||
** You installed an link:https://docs.openstack.org/python-openstackclient/latest/[{rh-openstack} client ({op-system} documentation)] on the target environment.
|
||||
** You also downloaded the link:https://docs.openstack.org/zh_CN/user-guide/common/cli-set-environment-variables-using-openstack-rc.html[{rh-openstack} `openrc.sh` rc file ({op-system} documentation)].
|
||||
** You have installed an link:https://docs.openstack.org/python-openstackclient/latest/[{rh-openstack} client ({op-system} documentation)] on the target environment.
|
||||
** You have downloaded the link:https://docs.openstack.org/zh_CN/user-guide/common/cli-set-environment-variables-using-openstack-rc.html[{rh-openstack} `openrc.sh` rc file ({op-system} documentation)].
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -100,7 +99,7 @@ For {rh-openstack-first}, you do not need to re-create the deployment YAML file.
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: ipfailover-keepalived <1>
|
||||
name: ipfailover-keepalived
|
||||
labels:
|
||||
ipfailover: hello-openshift
|
||||
spec:
|
||||
@@ -145,31 +144,31 @@ spec:
|
||||
env:
|
||||
- name: OPENSHIFT_HA_CONFIG_NAME
|
||||
value: "ipfailover"
|
||||
- name: OPENSHIFT_HA_VIRTUAL_IPS <2>
|
||||
- name: OPENSHIFT_HA_VIRTUAL_IPS
|
||||
value: "1.1.1.1-2"
|
||||
- name: OPENSHIFT_HA_VIP_GROUPS <3>
|
||||
- name: OPENSHIFT_HA_VIP_GROUPS
|
||||
value: "10"
|
||||
- name: OPENSHIFT_HA_NETWORK_INTERFACE <4>
|
||||
- name: OPENSHIFT_HA_NETWORK_INTERFACE
|
||||
value: "ens3" #The host interface to assign the VIPs
|
||||
- name: OPENSHIFT_HA_MONITOR_PORT <5>
|
||||
- name: OPENSHIFT_HA_MONITOR_PORT
|
||||
value: "30060"
|
||||
- name: OPENSHIFT_HA_VRRP_ID_OFFSET <6>
|
||||
- name: OPENSHIFT_HA_VRRP_ID_OFFSET
|
||||
value: "10"
|
||||
- name: OPENSHIFT_HA_REPLICA_COUNT <7>
|
||||
- name: OPENSHIFT_HA_REPLICA_COUNT
|
||||
value: "2" #Must match the number of replicas in the deployment
|
||||
- name: OPENSHIFT_HA_USE_UNICAST
|
||||
value: "false"
|
||||
#- name: OPENSHIFT_HA_UNICAST_PEERS
|
||||
#value: "10.0.148.40,10.0.160.234,10.0.199.110"
|
||||
- name: OPENSHIFT_HA_IPTABLES_CHAIN <8>
|
||||
- name: OPENSHIFT_HA_IPTABLES_CHAIN
|
||||
value: "INPUT"
|
||||
#- name: OPENSHIFT_HA_NOTIFY_SCRIPT <9>
|
||||
#- name: OPENSHIFT_HA_NOTIFY_SCRIPT
|
||||
# value: /etc/keepalive/mynotifyscript.sh
|
||||
- name: OPENSHIFT_HA_CHECK_SCRIPT <10>
|
||||
- name: OPENSHIFT_HA_CHECK_SCRIPT
|
||||
value: "/etc/keepalive/mycheckscript.sh"
|
||||
- name: OPENSHIFT_HA_PREEMPTION <11>
|
||||
- name: OPENSHIFT_HA_PREEMPTION
|
||||
value: "preempt_delay 300"
|
||||
- name: OPENSHIFT_HA_CHECK_INTERVAL <12>
|
||||
- name: OPENSHIFT_HA_CHECK_INTERVAL
|
||||
value: "2"
|
||||
livenessProbe:
|
||||
initialDelaySeconds: 10
|
||||
@@ -194,18 +193,25 @@ spec:
|
||||
name: keepalived-checkscript
|
||||
name: config-volume
|
||||
imagePullSecrets:
|
||||
- name: openshift-pull-secret <13>
|
||||
- name: openshift-pull-secret
|
||||
----
|
||||
<1> The name of the IP failover deployment.
|
||||
<2> The list of IP address ranges to replicate. This must be provided. For example, `1.2.3.4-6,1.2.3.9`.
|
||||
<3> The number of groups to create for VRRP. If not set, a group is created for each virtual IP range specified with the `OPENSHIFT_HA_VIP_GROUPS` variable.
|
||||
<4> The interface name that IP failover uses to send VRRP traffic. By default, `eth0` is used.
|
||||
<5> The IP failover pod tries to open a TCP connection to this port on each VIP. If connection is established, the service is considered to be running. If this port is set to `0`, the test always passes. The default value is `80`.
|
||||
<6> The offset value used to set the virtual router IDs. Using different offset values allows multiple IP failover configurations to exist within the same cluster. The default offset is `10`, and the allowed range is `0` through `255`.
|
||||
<7> The number of replicas to create. This must match `spec.replicas` value in IP failover deployment configuration. The default value is `2`.
|
||||
<8> The name of the `iptables` chain to automatically add an `iptables` rule to allow the VRRP traffic on. If the value is not set, an `iptables` rule is not added. If the chain does not exist, it is not created, and Keepalived operates in unicast mode. The default is `INPUT`.
|
||||
<9> The full path name in the pod file system of a script that is run whenever the state changes.
|
||||
<10> The full path name in the pod file system of a script that is periodically run to verify the application is operating.
|
||||
<11> The strategy for handling a new higher priority host. The default value is `preempt_delay 300`, which causes a Keepalived instance to take over a VIP after 5 minutes if a lower-priority master is holding the VIP.
|
||||
<12> The period, in seconds, that the check script is run. The default value is `2`.
|
||||
<13> Create the pull secret before creating the deployment, otherwise you will get an error when creating the deployment.
|
||||
+
|
||||
where:
|
||||
+
|
||||
--
|
||||
`ipfailover-keepalived`:: Specifies the name of the IP failover deployment.
|
||||
`OPENSHIFT_HA_VIRTUAL_IPS`:: Specifies the lis t of IP address ranges to replicate. This must be provided. For example, `1.2.3.4-6,1.2.3.9`.
|
||||
`OPENSHIFT_HA_VIP_GROUPS`:: Specifies the number of groups to create for VRRP. If not set, a group is created for each virtual IP range specified with the `OPENSHIFT_HA_VIP_GROUPS` variable.
|
||||
`OPENSHIFT_HA_NETWORK_INTERFACE`:: Specifies the interface name that IP failover uses to send VRRP traffic. By default, `eth0` is used.
|
||||
`OPENSHIFT_HA_MONITOR_PORT`:: Specifies the IP failover pod tries to open a TCP connection to this port on each VIP. If connection is established, the service is considered to be running. If this port is set to `0`, the test always passes. The default value is `80`.
|
||||
`OPENSHIFT_HA_VRRP_ID_OFFSET`:: Specifies the offset value used to set the virtual router IDs. Using different offset values allows multiple IP failover configurations to exist within the same cluster. The default offset is `10`, and the allowed range is `0` through `255`.
|
||||
`OPENSHIFT_HA_REPLICA_COUNT`:: Specifies the number of replicas to create. This must match `spec.replicas` value in IP failover configuration. The default value is `2`.
|
||||
`OPENSHIFT_HA_USE_UNICAST`:: Specifies whether to use unicast mode for VRRP. The default value is `false`.
|
||||
`OPENSHIFT_HA_UNICAST_PEERS`:: Specifies the list of IP addresses of the unicast peers. This must be provided if `OPENSHIFT_HA_USE_UNICAST` is set to `true`.
|
||||
`OPENSHIFT_HA_IPTABLES_CHAIN`:: Specifies the name of the `iptables` chain to automatically add an `iptables` rule to allow the VRRP traffic on. If the value is not set, an `iptables` rule is not added. If the chain does not exist, it is not created, and Keepalived operates in unicast mode. The default is `INPUT`.
|
||||
`OPENSHIFT_HA_NOTIFY_SCRIPT`:: Specifies the full path name in the pod file system of a script that is run whenever the state changes.
|
||||
`OPENSHIFT_HA_CHECK_SCRIPT`:: Specifies the full path name in the pod file system of a script that is periodically run to verify the application is operating.
|
||||
`OPENSHIFT_HA_PREEMPTION`:: Specifies the strategy for handling a new higher priority host. The default value is `preempt_delay 300`, which causes a Keepalived instance to take over a VIP after 5 minutes if a lower-priority master is holding the VIP.
|
||||
`OPENSHIFT_HA_CHECK_INTERVAL`:: Specifies the period, in seconds, that the check script is run. The default value is `2`.
|
||||
`openshift-pull-secret`:: Specifies the name of the pull secret to use for the IP failover deployment. Create the pull secret before creating the deployment, otherwise you will get an error when creating the deployment.
|
||||
--
|
||||
@@ -6,27 +6,28 @@
|
||||
[id="nw-ipfailover-configuring-check-notify-scripts_{context}"]
|
||||
= Configuring check and notify scripts
|
||||
|
||||
Keepalived monitors the health of the application by periodically running an optional user-supplied check script. For example, the script can test a web server by issuing a request and verifying the response. As cluster administrator, you can provide an optional notify script, which is called whenever the state changes.
|
||||
[role="_abstract"]
|
||||
To customize health monitoring for IP failover and receive notifications when VIP state changes in {product-title}, you can configure check and notify scripts by using `ConfigMap` objects.
|
||||
|
||||
The check and notify scripts run in the IP failover pod and use the pod file system, not the host file system. However, the IP failover pod makes the host file system available under the `/hosts` mount path. When configuring a check or notify script, you must provide the full path to the script. The recommended approach for providing the scripts is to use a `ConfigMap` object.
|
||||
The check and notify scripts run inside the IP failover pod and use the pod file system rather than the host file system. The host file system is available to the pod under the `/hosts` mount path. When configuring a check or notify script, you must provide the full path to the script.
|
||||
|
||||
The full path names of the check and notify scripts are added to the Keepalived configuration file, `_/etc/keepalived/keepalived.conf`, which is loaded every time Keepalived starts. The scripts can be added to the pod with a `ConfigMap` object as described in the following methods.
|
||||
Each IP failover pod manages a Keepalived daemon that controls one or more virtual IP (VIP) addresses on the node where the pod is running. Keepalived tracks the state of each VIP on the node, which can be `master`, `backup`, or `fault`.
|
||||
|
||||
*Check script*
|
||||
The full path names of the check and notify scripts are added to the Keepalived configuration file, `/etc/keepalived/keepalived.conf`, which is loaded each time Keepalived starts. You add the scripts to the pod by using a `ConfigMap` object, as described in the following sections.
|
||||
|
||||
When a check script is not provided, a simple default script is run that tests the TCP connection. This default test is suppressed when the monitor port is `0`.
|
||||
Check script::
|
||||
+
|
||||
Keepalived monitors application health by periodically running an optional, user-supplied check script. For example, the script can test a web server by issuing a request and verifying the response. If you do not provide a check script, Keepalived runs a default script that tests the TCP connection. This default test is suppressed when the monitor port is set to `0`.
|
||||
+
|
||||
If the check script returns a non-zero value, the node enters the `backup` state and any VIPs that it holds are reassigned.
|
||||
|
||||
Each IP failover pod manages a Keepalived daemon that manages one or more virtual IP (VIP) addresses on the node where the pod is running. The Keepalived daemon keeps the state of each VIP for that node. A particular VIP on a particular node might be in `master`, `backup`, or `fault` state.
|
||||
|
||||
If the check script returns non-zero, the node enters the `backup` state, and any VIPs it holds are reassigned.
|
||||
|
||||
*Notify script*
|
||||
|
||||
Keepalived passes the following three parameters to the notify script:
|
||||
|
||||
* `$1` - `group` or `instance`
|
||||
* `$2` - Name of the `group` or `instance`
|
||||
* `$3` - The new state: `master`, `backup`, or `fault`
|
||||
Notify script::
|
||||
+
|
||||
As a cluster administrator, you can provide an optional notify script that Keepalived calls whenever the VIP state changes. Keepalived passes the following parameters to the notify script:
|
||||
+
|
||||
* `$1` — `group` or `instance`
|
||||
* `$2` — Name of the `group` or `instance`
|
||||
* `$3` — New state: `master`, `backup`, or `fault`
|
||||
|
||||
.Prerequisites
|
||||
|
||||
@@ -47,14 +48,16 @@ The check script, `_mycheckscript.sh_`:
|
||||
exit 0
|
||||
----
|
||||
|
||||
. Create the `ConfigMap` object :
|
||||
. Create the `ConfigMap` object by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create configmap mycustomcheck --from-file=mycheckscript.sh
|
||||
----
|
||||
+
|
||||
. Add the script to the pod. The `defaultMode` for the mounted `ConfigMap` object files must able to run by using `oc` commands or by editing the deployment configuration. A value of `0755`, `493` decimal, is typical:
|
||||
|
||||
. Add the script to the pod. The `defaultMode` for the mounted `ConfigMap` object files must able to run by using `oc` commands or by editing the IP failover configuration.
|
||||
|
||||
.. Add the script to the pod by running the following command. A value of `0755`, `493` decimal, is typical. For example:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
@@ -74,40 +77,46 @@ $ oc set volume deploy/ipfailover-keepalived --add --overwrite \
|
||||
====
|
||||
The `oc set env` command is whitespace sensitive. There must be no whitespace on either side of the `=` sign.
|
||||
====
|
||||
+
|
||||
[TIP]
|
||||
====
|
||||
You can alternatively edit the `ipfailover-keepalived` deployment configuration:
|
||||
|
||||
.. Alternatively, edit the `ipfailover-keepalived` configuration by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc edit deploy ipfailover-keepalived
|
||||
----
|
||||
|
||||
+
|
||||
.Example `ipfailover-keepalived` configuration
|
||||
[source,yaml]
|
||||
----
|
||||
spec:
|
||||
containers:
|
||||
- env:
|
||||
- name: OPENSHIFT_HA_CHECK_SCRIPT <1>
|
||||
- name: OPENSHIFT_HA_CHECK_SCRIPT
|
||||
value: /etc/keepalive/mycheckscript.sh
|
||||
...
|
||||
volumeMounts: <2>
|
||||
volumeMounts:
|
||||
- mountPath: /etc/keepalive
|
||||
name: config-volume
|
||||
dnsPolicy: ClusterFirst
|
||||
...
|
||||
volumes: <3>
|
||||
volumes:
|
||||
- configMap:
|
||||
defaultMode: 0755 <4>
|
||||
defaultMode: 0755
|
||||
name: customrouter
|
||||
name: config-volume
|
||||
...
|
||||
----
|
||||
<1> In the `spec.container.env` field, add the `OPENSHIFT_HA_CHECK_SCRIPT` environment variable to point to the mounted script file.
|
||||
<2> Add the `spec.container.volumeMounts` field to create the mount point.
|
||||
<3> Add a new `spec.volumes` field to mention the config map.
|
||||
<4> This sets run permission on the files. When read back, it is displayed in decimal, `493`.
|
||||
+
|
||||
where:
|
||||
+
|
||||
--
|
||||
`spec.container.env.name`:: Specifies the `OPENSHIFT_HA_CHECK_SCRIPT` environment variable to point to the mounted script file.
|
||||
|
||||
Save the changes and exit the editor. This restarts `ipfailover-keepalived`.
|
||||
====
|
||||
`spec.container.volumeMounts`:: Specifies the `spec.container.volumeMounts` field to create the mount point.
|
||||
|
||||
`spec.volumes`:: Specifies a new `spec.volumes` field to mention the config map.
|
||||
|
||||
`spec.volumes.configMap.defaultMode`:: Specifies run permission on the files. When read back, it is displayed in decimal, `493`.
|
||||
--
|
||||
|
||||
.. Save the changes and exit the editor. This restarts the `ipfailover-keepalived` configuration.
|
||||
@@ -6,7 +6,8 @@
|
||||
[id="nw-ipfailover-configuring-more-than-254_{context}"]
|
||||
= Configuring IP failover for more than 254 addresses
|
||||
|
||||
IP failover management is limited to 254 groups of Virtual IP (VIP) addresses. By default {product-title} assigns one IP address to each group. You can use the `OPENSHIFT_HA_VIP_GROUPS` variable to change this so multiple IP addresses are in each group and define the number of VIP groups available for each Virtual Router Redundancy Protocol (VRRP) instance when configuring IP failover.
|
||||
[role="_abstract"]
|
||||
To configure IP failover for more than 254 Virtual IP addresses in {product-title}, you can use the `OPENSHIFT_HA_VIP_GROUPS` variable to group multiple addresses together. By using the `OPENSHIFT_HA_VIP_GROUPS` variable, you can change the number of VIPs per VRRP instance and define the number of VIP groups available for each VRRP instance when configuring IP failover.
|
||||
|
||||
Grouping VIPs creates a wider range of allocation of VIPs per VRRP in the case of VRRP failover events, and is useful when all hosts in the cluster have access to a service locally. For example, when a service is being exposed with an `ExternalIP`.
|
||||
|
||||
@@ -34,13 +35,14 @@ If you are using {product-title} health checks, the nature of IP failover and gr
|
||||
...
|
||||
spec:
|
||||
env:
|
||||
- name: OPENSHIFT_HA_VIP_GROUPS <1>
|
||||
- name: OPENSHIFT_HA_VIP_GROUPS
|
||||
value: "3"
|
||||
...
|
||||
----
|
||||
<1> If `OPENSHIFT_HA_VIP_GROUPS` is set to `3` in an environment with seven VIPs, it creates three groups, assigning three VIPs to the first group, and two VIPs to the two remaining groups.
|
||||
|
||||
+
|
||||
In this example, the `OPENSHIFT_HA_VIP_GROUPS` variable is set to `3`. In an environment with seven VIPs, it creates three groups, assigning three VIPs to the first group, and two VIPs to the two remaining groups.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
If the number of groups set by `OPENSHIFT_HA_VIP_GROUPS` is fewer than the number of IP addresses set to fail over, the group contains more than one IP address, and all of the addresses move as a single unit.
|
||||
====
|
||||
====
|
||||
@@ -6,8 +6,17 @@
|
||||
[id="nw-ipfailover-configuring-vrrp-preemption_{context}"]
|
||||
= Configuring VRRP preemption
|
||||
|
||||
When a Virtual IP (VIP) on a node leaves the `fault` state by passing the check script, the VIP on the node enters the `backup` state if it has lower priority than the VIP on the node that is currently in the `master` state.
|
||||
The `nopreempt` strategy does not move `master` from the lower priority VIP on the host to the higher priority VIP on the host. With `preempt_delay 300`, the default, Keepalived waits the specified 300 seconds and moves `master` to the higher priority VIP on the host.
|
||||
[role="_abstract"]
|
||||
To control VIP preemption behavior when nodes recover in {product-title}, you can configure the `OPENSHIFT_HA_PREEMPTION` variable to set a delay before higher priority VIPs take over or disable preemption entirely.
|
||||
|
||||
When a virtual IP (VIP) on a node recovers from the `fault` state, it enters the `backup` state if it has a lower priority than the VIP currently in the `master` state.
|
||||
|
||||
There are two options for the `OPENSHIFT_HA_PREEMPTION` variable:
|
||||
|
||||
* `nopreempt`: When set, the `master` role does not move from a lower-priority VIP to a higher-priority VIP.
|
||||
* `preempt_delay 300`: When set, Keepalived waits 300 seconds before moving the `master` role to the higher-priority VIP.
|
||||
|
||||
In the following example, the `OPENSHIFT_HA_PREEMPTION` value is set to `preempt_delay 300`.
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -20,14 +29,11 @@ $ oc edit deploy ipfailover-keepalived
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
...
|
||||
# ...
|
||||
spec:
|
||||
containers:
|
||||
- env:
|
||||
- name: OPENSHIFT_HA_PREEMPTION <1>
|
||||
- name: OPENSHIFT_HA_PREEMPTION
|
||||
value: preempt_delay 300
|
||||
...
|
||||
#...
|
||||
----
|
||||
<1> Set the `OPENSHIFT_HA_PREEMPTION` value:
|
||||
- `preempt_delay 300`: Keepalived waits the specified 300 seconds and moves `master` to the higher priority VIP on the host. This is the default value.
|
||||
- `nopreempt`: does not move `master` from the lower priority VIP on the host to the higher priority VIP on the host.
|
||||
|
||||
@@ -6,7 +6,8 @@
|
||||
[id="nw-ipfailover-environment-variables_{context}"]
|
||||
= IP failover environment variables
|
||||
|
||||
The following table contains the variables used to configure IP failover.
|
||||
[role="_abstract"]
|
||||
The IP failover environment variables reference lists all variables you can use to configure IP failover in {product-title}, including VIP addresses, monitoring ports, and network interfaces.
|
||||
|
||||
.IP failover environment variables
|
||||
[cols="3a,1a,4a",options="header"]
|
||||
|
||||
@@ -6,6 +6,9 @@
|
||||
[id="nw-ipfailover-remove_{context}"]
|
||||
= Removing IP failover
|
||||
|
||||
[role="_abstract"]
|
||||
To remove IP failover from your {product-title} cluster and clean up iptables rules and virtual IP addresses, you can delete the deployment and service account, then run a cleanup job on each configured node.
|
||||
|
||||
When IP failover is initially configured, the worker nodes in the cluster are modified with an `iptables` rule that explicitly allows multicast packets on `224.0.0.18` for Keepalived. Because of the change to the nodes, removing IP failover requires running a job to remove the `iptables` rule and removing the virtual IP addresses used by Keepalived.
|
||||
|
||||
.Procedure
|
||||
@@ -92,12 +95,13 @@ spec:
|
||||
- name: remove-ipfailover
|
||||
image: registry.redhat.io/openshift4/ose-keepalived-ipfailover-rhel9:v{product-version}
|
||||
command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
|
||||
nodeSelector: <1>
|
||||
kubernetes.io/hostname: <host_name> <2>
|
||||
nodeSelector:
|
||||
kubernetes.io/hostname: <host_name>
|
||||
restartPolicy: Never
|
||||
----
|
||||
<1> The `nodeSelector` is likely the same as the selector used in the old IP failover deployment.
|
||||
<2> Run the job for each node in your cluster that was configured for IP failover and replace the hostname each time.
|
||||
+
|
||||
** The `nodeSelector` is likely the same as the selector used in the old IP failover deployment.
|
||||
** Run the job for each node in your cluster that was configured for IP failover and replace the hostname each time.
|
||||
|
||||
.. Run the job:
|
||||
+
|
||||
|
||||
@@ -6,10 +6,13 @@
|
||||
[id="nw-ipfailover-vrrp-ip-offset_{context}"]
|
||||
= Deploying multiple IP failover instances
|
||||
|
||||
Each IP failover pod managed by the IP failover deployment configuration, `1` pod per node or replica, runs a Keepalived daemon. As more IP failover deployment configurations are configured, more pods are created and more daemons join into the common Virtual Router Redundancy Protocol (VRRP) negotiation. This negotiation is done by all the Keepalived daemons and it determines which nodes service which virtual IPs (VIP).
|
||||
[role="_abstract"]
|
||||
When deploying multiple IP failover instances in {product-title}, each Keepalived daemon assigns unique VRRP IDs to virtual IP addresses. Configure the `OPENSHIFT_HA_VRRP_ID_OFFSET` variable to prevent VRRP ID range overlaps between different IP failover configurations.
|
||||
|
||||
Internally, Keepalived assigns a unique `vrrp-id` to each VIP. The negotiation uses this set of `vrrp-ids`, when a decision is made, the VIP corresponding to the winning `vrrp-id` is serviced on the winning node.
|
||||
Each IP failover pod created by an IP failover configuration (one pod per node or replica) runs a Keepalived daemon. When multiple IP failover configurations are present, additional pods are created, and their Keepalived daemons participate together in Virtual Router Redundancy Protocol (VRRP) negotiation. This negotiation determines which node services each virtual IP (VIP).
|
||||
|
||||
Therefore, for every VIP defined in the IP failover deployment configuration, the IP failover pod must assign a corresponding `vrrp-id`. This is done by starting at `OPENSHIFT_HA_VRRP_ID_OFFSET` and sequentially assigning the `vrrp-ids` to the list of VIPs. The `vrrp-ids` can have values in the range `1..255`.
|
||||
For each VIP, Keepalived assigns a unique internal `vrrp-id`. During VRRP negotiation, these `vrrp-id` values are used to select the node that services the corresponding VIP.
|
||||
|
||||
When there are multiple IP failover deployment configurations, you must specify `OPENSHIFT_HA_VRRP_ID_OFFSET` so that there is room to increase the number of VIPs in the deployment configuration and none of the `vrrp-id` ranges overlap.
|
||||
The IP failover pod assigns `vrrp-id` values sequentially to the VIPs defined in the IP failover configuration, starting from the value specified by `OPENSHIFT_HA_VRRP_ID_OFFSET`. Valid `vrrp-id` values are in the range 1..255.
|
||||
|
||||
When you deploy multiple IP failover configurations, ensure that the configured offset leaves sufficient space for additional VIPs and prevents `vrrp-id` ranges from overlapping across configurations.
|
||||
|
||||
@@ -6,7 +6,8 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
This topic describes configuring IP failover for pods and services on your {product-title} cluster.
|
||||
[role="_abstract"]
|
||||
To provide high availability for Virtual IP addresses and ensure services remain accessible when nodes fail in {product-title}, you can configure IP failover using Keepalived.
|
||||
|
||||
IP failover uses link:http://www.keepalived.org/[Keepalived] to host a set of externally accessible Virtual IP (VIP) addresses on a set of hosts. Each VIP address is only serviced by a single host at a time. Keepalived uses the Virtual Router Redundancy Protocol (VRRP) to determine which host, from the set of hosts, services which VIP. If a host becomes unavailable, or if the service that Keepalived is watching does not respond, the VIP is switched to another host from the set. This means a VIP is always serviced as long as a host is available.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user