Installation and Configuration Options¶

In One-Click Installation we use the default configuration for installation. Kube-OVN also supports more custom configurations, which can be configured in the installation script, or later by changing the parameters of individual components. This document will describe what these customization options do, and how to configure them.

Built-in Network Settings¶

Kube-OVN will configure two built-in Subnets during installation:

1. default Subnet, as the default subnet used by the Pod to assign IPs, with a default CIDR of 10.16.0.0/16 and a gateway of 10.16.0.1.
2. The join subnet, as a special subnet for network communication between the Node and Pod, has a default CIDR of 100.64.0.0/16 and a gateway of 100.64.0.1.

The configuration of these two subnets can be changed during installation via the installation scripts variables:

POD_CIDR="10.16.0.0/16"
POD_GATEWAY="10.16.0.1"
JOIN_CIDR="100.64.0.0/16"
EXCLUDE_IPS=""

EXCLUDE_IP sets the address range for which kube-ovn-controller will not automatically assign from it, the format is: 192.168.10.20..192.168.10.30.

Note that in the Overlay case these two Subnets CIDRs cannot conflict with existing host networks and Service CIDRs.

You can change the address range of both Subnets after installation by referring to Change Subnet CIDR and Change Join Subnet CIDR.

Config Service CIDR¶

Since some of the iptables and routing rules set by kube-proxy will conflict with the rules set by Kube-OVN, Kube-OVN needs to know the CIDR of the service to set the corresponding rules correctly.

This can be done by modifying the installation script:

SVC_CIDR="10.96.0.0/12"  

You can also modify the args of the kube-ovn-controller Deployment after installation:

args:
- --service-cluster-ip-range=10.96.0.0/12

Overlay NIC Selection¶

In the case of multiple NICs on a node, Kube-OVN will select the NIC corresponding to the Kubernetes Node IP as the NIC for cross-node communication between containers and establish the corresponding tunnel.

If you need to select another NIC to create a container tunnel, you can change it in the installation script:

IFACE=eth1

This option supports regular expressions separated by commas, e.g. 'ens[a-z0-9],eth[a-z0-9]'.

It can also be adjusted after installation by modifying the args of the kube-ovn-cni DaemonSet:

args:
- --iface=eth1

If each machine has a different NIC name and there is no fixed pattern, you can use the node annotation ovn.kubernetes.io/tunnel_interface to configure each node one by one. This annotation will override the configuration of iface.

kubectl annotate node no1 ovn.kubernetes.io/tunnel_interface=ethx

To specify different encapsulation NICs for different subnets, please refer to Overlay Encapsulation NIC Selection.

Use a /32 Address as the Tunnel Source¶

Some cloud platforms assign a /32 or /128 address to the host interface. A single eligible full-mask address is selected by default. If it shares the interface with other usable addresses of the same family, Kube-OVN may treat it as a virtual IP and skip it; set HOST_TUNNEL_SRC=true to include it as a tunnel source:

HOST_TUNNEL_SRC=true

Set HOST_TUNNEL_SRC=true when installing with the installation script. The value is passed to the Kube-OVN daemon on each node. When installing with Helm, set the field for the chart in use:

# charts/kube-ovn
func:
  HOST_TUNNEL_SRC: true

# charts/kube-ovn-v2
features:
  enableHostTunnelSrc: true

Both Helm fields and the installation script variable default to false. When enabled, the daemon includes eligible full-mask addresses when selecting a tunnel source; loopback addresses are always excluded. Make sure that the address on every node is usable for node-to-node tunnel communication, and verify Overlay connectivity after enabling the option.

Config MTU¶

Since Overlay encapsulation requires additional space, Kube-OVN will adjust the MTU of the container NIC based on the MTU of the selected NIC when creating the container NIC. By default, the Pod NIC MTU is the host NIC MTU - 100 on the Overlay Subnet, and the Pod NIC and host NIC have the same MTU on the Underlay Subnet.

If you need to adjust the size of the MTU under the Overlay subnet, you can modify the parameters of the kube-ovn-cni DaemonSet:

args:
- --mtu=1333

Global Traffic Mirroring Setting¶

When global traffic mirroring is enabled, Kube-OVN will create a mirror0 virtual NIC on each node and copy all container network traffic from the current machine to that NIC, Users can perform traffic analysis with tcpdump and other tools. This function can be enabled in the installation script:

ENABLE_MIRROR=true

It can also be adjusted after installation by modifying the args of the kube-ovn-cni DaemonSet:

args:
- --enable-mirror=true

The ability to mirror traffic is disabled in the default installation, if you need fine-grained traffic mirroring or need to mirror traffic to additional NICs please refer to Traffic Mirror.

LB Settings¶

In Underlay scenarios, kube-proxy cannot intercept container network traffic, so it cannot implement Service forwarding functionality. In this case, you can enable OVN's built-in L2 LB capability to implement ClusterIP forwarding. In scenarios where Service forwarding capability is not needed, you can disable the LB capability to achieve better performance. Note that this feature only implements ClusterIP forwarding for container networks and cannot replace all capabilities of kube-proxy, so it cannot replace kube-proxy.

This feature can be configured in the installation script:

ENABLE_LB=false

It can also be configured after installation by changing the args of the kube-ovn-controller Deployment:

args:
- --enable-lb=false

The LB feature is enabled in the default installation.

The spec field enableLb has been added to the subnet crd definition since Kube-OVN v1.12.0 to migrate the LB function of Kube-OVN to the subnet level. You can set whether to enable the LB function based on different subnets. The enable-lb parameter in the kube-ovn-controller deployment is used as a global switch to control whether to create a load-balancer record. The enableLb parameter added in the subnet is used to control whether the subnet is associated with a load-balancer record. After the previous version is upgraded to v1.12.0, the enableLb parameter of the subnet will automatically inherit the value of the original global switch parameter.

NetworkPolicy Settings¶

Kube-OVN uses ACLs in OVN to implement NetworkPolicy. Users can choose to disable the NetworkPolicy feature or use the Cilium Chain approach to implement NetworkPolicy using eBPF. In this case, the NetworkPolicy feature of Kube-OVN can be disabled to achieve better performance on the control plane and data plane.

This feature can be configured in the installation script:

ENABLE_NP=false

It can also be configured after installation by changing the args of the kube-ovn-controller Deployment:

args:
- --enable-np=false

NetworkPolicy is enabled by default.

EIP and SNAT Settings¶

If the EIP and SNAT capabilities are not required on the default VPC, users can choose to disable them to reduce the performance overhead of kube-ovn-controller in large scale cluster environments and improve processing speed.

This feature can be configured in the installation script:

ENABLE_EIP_SNAT=false

It can also be configured after installation by changing the args of the kube-ovn-controller Deployment:

args:
- --enable-eip-snat=false

EIP and SNAT is enabled by default. More information can refer to EIP and SNAT.

LoadBalancer Service Settings¶

Enable this option to support LoadBalancer Services in the default VPC. For usage and other configuration options, see LoadBalancer Type Service.

This feature is disabled by default. To enable it in the installation script, set:

ENABLE_LB_SVC=true

It can also be enabled after installation by changing the args of the kube-ovn-controller Deployment:

args:
- --enable-lb-svc=true

Centralized Gateway ECMP Settings¶

The centralized gateway supports two mode of high availability, primary-backup and ECMP. If you want to enable ECMP mode, you need to change the args of kube-ovn-controller Deployment:

args:
- --enable-ecmp=true 

Centralized gateway default installation under the primary-backup mode, more gateway-related content please refer to Config Subnet.

The spec field enableEcmp has been added to the subnet crd definition since Kube-OVN v1.12.0 to migrate the ECMP switch to the subnet level. You can set whether to enable ECMP mode based on different subnets. The enable-ecmp parameter in the kube-ovn-controller deployment is no longer used. After the previous version is upgraded to v1.12.0, the subnet switch will automatically inherit the value of the original global switch parameter.

Kubevirt VM Fixed Address Settings¶

For VM instances created by Kubevirt, kube-ovn-controller can assign and manage IP addresses in a similar way to the StatefulSet Pod. This allows VM instances address fixed during start-up, shutdown, upgrade, migration, and other operations throughout their lifecycle, making them more compatible with the actual virtualization user experience.

This feature is enabled by default after v1.10.6. To disable this feature, you need to change the following args in the kube-ovn-controller Deployment:

args:
- --keep-vm-ip=false

CNI Settings¶

By default, Kube-OVN installs the CNI binary in the /opt/cni/bin directory and the CNI configuration file 01-kube-ovn.conflist in the /etc/cni/net.d directory. If you need to change the installation location and the priority of the CNI configuration file, you can modify the following parameters of the installation script.

CNI_CONF_DIR="/etc/cni/net.d"
CNI_BIN_DIR="/opt/cni/bin"
CNI_CONFIG_PRIORITY="01"

Or change the Volume mount and args of the kube-ovn-cni DaemonSet after installation:

volumes:
- name: cni-conf
  hostPath:
    path: "/etc/cni/net.d"
- name: cni-bin
  hostPath:
    path:"/opt/cni/bin"
...
args:
- --cni-conf-name=01-kube-ovn.conflist

The standalone installation script also installs the loopback, portmap, macvlan, and ipvlan plugins bundled in the Kube-OVN image by default. If another component already provides these plugins on the nodes, set the following during installation:

INSTALL_CNI_PLUGINS=false

Setting this to false skips only the bundled plugins; the Kube-OVN CNI binary and configuration are still installed. With Helm v1, set cni_conf.INSTALL_CNI_PLUGINS: false; with Helm v2, set cni.installCNIPlugins: false.

Periodic CNI recompute¶

Periodic OVN controller recompute in the kube-ovn-cni DaemonSet is disabled by default. To run this periodic operation, explicitly enable it in the standalone installation script:

ENABLE_RECOMPUTE=true

Helm v1 and Helm v2 use the following values respectively:

# Helm v1
func:
  ENABLE_RECOMPUTE: true

# Helm v2
features:
  enableRecompute: true

After installation, you can also set --enable-recompute=true in the kube-ovn-cni DaemonSet. When enabled, the daemon runs a periodic recompute every 10 minutes. With the default false value, this periodic worker is not started; other event-driven processing is unchanged.

Tunnel Type Settings¶

The default encapsulation mode of Kube-OVN Overlay is Geneve, if you want to change it to Vxlan or STT, please adjust the following parameters in the installation script:

TUNNEL_TYPE="vxlan"

Or change the environment variables of ovs-ovn DaemonSet after installation:

env:
- name: TUNNEL_TYPE
  value: "vxlan"

If you need to use the STT tunnel and need to compile additional kernel modules for ovs, please refer to Performance Tuning.

Please refer to Tunneling Protocol Selection for the differences between the different protocols in practice.

SSL Settings¶

The OVN NB/SB database API and Kube-OVN secure-serving endpoints both support TLS. TLS is disabled by default. The following installation script environment variables configure TLS for OVN central/DB; they do not set the TLS version or cipher suites for secure-serving endpoints:

ENABLE_SSL=true
TLS_MIN_VERSION="TLS12"
TLS_MAX_VERSION="TLS13"
TLS_CIPHER_SUITES="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_AES_128_GCM_SHA256"

TLS_MIN_VERSION and TLS_MAX_VERSION support TLS10, TLS11, TLS12, and TLS13. An empty value uses the component default. If both values are set, the minimum must be less than or equal to the maximum. The selected protocol range is applied to the OVN NB/SB database servers.

TLS_CIPHER_SUITES is a comma-separated list of Go TLS cipher suite names. The OVN DB server only accepts suites that the installation script maps to OpenSSL names. The accepted names are:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

Cipher suites must match the key type of the certificate in the kube-ovn-tls Secret. The default generated kube-ovn-tls uses an RSA certificate, so using only ECDSA cipher suites with the default RSA certificate causes TLS handshakes to fail. To use ECDSA-only suites, provide a matching ECDSA certificate and key first.

The following Helm settings are converted by the chart's componentTLSArgs template into the --tls-min-version, --tls-max-version, and --tls-cipher-suites arguments for each component. These arguments configure secure-serving endpoints. The installation script's TLS_* variables do not inject these component arguments. Setting only these TLS parameters does not enable secure-serving; the chart's secure-serving switch must also be enabled. The classic chart uses func.SECURE_SERVING, while the v2 chart uses features.enableSecureServing; TLS versions and cipher suites remain under networking.

For the classic Helm chart, set the following values:

func:
  SECURE_SERVING: true
networking:
  ENABLE_SSL: true
  TLS_MIN_VERSION: TLS12
  TLS_MAX_VERSION: TLS13
  TLS_CIPHER_SUITES:
    - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    - TLS_AES_128_GCM_SHA256

For the v2 Helm chart, use the following values:

features:
  enableSecureServing: true
networking:
  enableSsl: true
  tlsMinVersion: TLS12
  tlsMaxVersion: TLS13
  tlsCipherSuites:
    - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    - TLS_AES_128_GCM_SHA256

When ENABLE_SSL=true (or networking.enableSsl=true), Kube-OVN uses the kube-ovn-tls Secret. The Secret contains cacert, cert, and key, which are mounted under /var/run/tls. The classic Helm chart's regular installation and the v2 Helm chart create this Secret when it does not already exist. Only the classic Helm chart has a special rule for installMode: dataPlaneOnly: when networking.ENABLE_SSL=true, pre-create kube-ovn-tls in the target namespace with the same CA, certificate, and key used by the management cluster's OVN central. The classic chart template fails when this Secret is missing and does not render a local Secret. The v2 Helm chart does not define an installMode: dataPlaneOnly value, so this pre-seeding rule does not apply to the v2 chart.

When SSL is enabled, kube-ovn-controller manages the kube-ovn-tls Secret. The Secret keeps the existing cacert, cert, and key data keys. If the Secret already exists without the Kube-OVN certificate hash annotation, the controller adopts it first instead of replacing the certificate immediately after an upgrade.

Automatic checks and rotation are controlled by KUBE_OVN_TLS_ROTATION_INTERVAL. The default is 8760h (one year), and setting it to 0 disables automatic rotation. This value is the check interval, not a forced renewal period; a new certificate is generated only after the current certificate passes the halfway point of its validity period. Set it in the installation script as follows:

ENABLE_SSL=true
KUBE_OVN_TLS_ROTATION_INTERVAL=8760h

For a Helm installation, the values depend on the chart version. The classic chart (charts/kube-ovn) uses uppercase keys:

networking:
  ENABLE_SSL: true
  KUBE_OVN_TLS_ROTATION_INTERVAL: 8760h

When the classic chart is installed with installMode: dataPlaneOnly, it forces this interval to 0 because the management cluster owns kube-ovn-tls and must perform the rotation.

The v2 chart (charts/kube-ovn-v2) uses camel-case keys:

networking:
  enableSsl: true
  kubeOvnTlsRotationInterval: 8760h

After the Secret is updated, the OVN processes in ovn-central and ovs-ovn, together with Kube-OVN Go clients, reload the mounted certificate files or read the new certificate during the next TLS handshake. Kube-OVN Pods do not need to restart. To verify adoption or rotation, inspect the kube-ovn.io/kube-ovn-tls-cert-hash annotation on kube-ovn-tls, component logs, and container restart counts.

Conntrack-skip Destination CIDR List¶

For destinations that need to bypass conntrack processing (for example, side traffic that already has NAT or session affinity handled elsewhere), a skip list can be configured in the installation script or as a kube-ovn-controller flag. Multiple CIDRs are comma-separated:

SKIP_CONNTRACK_DST_CIDRS="10.10.0.0/16,fd00:10::/64"

args:
- --skip-conntrack-dst-cidrs=10.10.0.0/16,fd00:10::/64

Empty by default.

Enable OVN IPSec¶

Once enabled, Kube-OVN encrypts the inter-node Geneve/Vxlan/STT tunnels via OVN's built-in IPSec capability and issues certificates automatically.

ENABLE_OVN_IPSEC=true

This switch must be turned on for both the controller and the daemon:

args:
- --enable-ovn-ipsec=true

For details, see OVN IPSec.

AdminNetworkPolicy / DNS Name Resolver Support¶

Enable AdminNetworkPolicy (ANP/CNP) and DNS-name-based access control (which depends on the DNSNameResolver CRD):

ENABLE_ANP=true
ENABLE_DNS_NAME_RESOLVER=true

args:
- --enable-anp=true
- --enable-dns-name-resolver=true

For usage, see Domain-name-based Access Control.

VPC NAT Gateway Master Switch¶

Controls whether the VPC NAT Gateway controllers are enabled. Enabled by default:

ENABLE_NAT_GW=true

The runtime switch can also be controlled via the enable-vpc-nat-gw field in the ovn-vpc-nat-gw-config ConfigMap.

ovn-northd Thread Count¶

For large-scale clusters, the number of ovn-northd worker threads can be tuned to speed up incremental computation:

OVN_NORTHD_N_THREADS=4

Defaults to 1. Choose a value based on the available node CPU resources.

NetworkPolicy Enforcement Mode¶

Kube-OVN supports two NetworkPolicy enforcement modes, standard and lax. The global default can be configured as follows:

NP_ENFORCEMENT=standard

args:
- --np-enforcement=standard

The mode can also be overridden on individual NetworkPolicies via the ovn.kubernetes.io/network_policy_enforcement annotation. See NetworkPolicy Support for details.

Disable VXLAN TX Checksum Offload¶

Some NICs have compatibility issues with checksum offload during VXLAN tunnel encapsulation, which can be disabled:

SET_VXLAN_TX_OFF=true

args:
- --set-vxlan-tx-off=true

Disable Geneve TX Checksum Offload¶

Some NICs or kernel versions may also have checksum offload compatibility issues during Geneve tunnel encapsulation. Kube-OVN leaves Geneve TX checksum offload unchanged by default. To disable it, set the following in the installation script:

SET_GENEVE_TX_OFF=true

The installation script passes this value to the --set-geneve-tx-off argument of kube-ovn-daemon. You can also set the argument in the kube-ovn-cni DaemonSet after installation:

args:
- --set-geneve-tx-off=true

When installing with Helm, configure the following fields in the classic and v2 charts respectively:

# classic chart
func:
  SET_GENEVE_TX_OFF: true

# v2 chart
features:
  SET_GENEVE_TX_OFF: true

When enabled, the daemon disables TX checksum offload on genev_sys_6081 during startup. If that interface does not exist on a node, the initialization step is skipped. This setting only changes the interface during startup: changing it from true to false does not re-enable offload that was already disabled, so restore the node interface separately before relying on the default offload state. SET_GENEVE_TX_OFF and SET_VXLAN_TX_OFF control the Geneve and VXLAN interfaces independently.

KubeVirt Live Migration Optimization¶

Once enabled, the controller optimizes port-binding switches during KubeVirt live migration to reduce transient packet loss. Enabled by default:

ENABLE_LIVE_MIGRATION_OPTIMIZE=true

OVN LB Prefer Local Endpoint¶

Once enabled, the OVN built-in LoadBalancer prefers endpoints on the same node, intended to be used together with externalTrafficPolicy=Local:

ENABLE_OVN_LB_PREFER_LOCAL=true

args:
- --enable-ovn-lb-prefer-local=true

External Gateway ConfigMap Namespace¶

ConfigMaps related to the centralized external gateway (such as external-gw-config) live in kube-system by default. They can be moved to a different namespace via:

EXTERNAL_GATEWAY_CONFIG_NS=kube-system

Non-Primary CNI Mode¶

In this mode, Kube-OVN only acts as an attachment network provider and no longer allocates the Pod primary-network IP; the primary network is delegated to another CNI. Both the controller and the daemon must enable this switch:

args:
- --non-primary-cni-mode=true

It can also be configured via Helm with cni_conf.NON_PRIMARY_CNI=true (chart v1) or cni.nonPrimaryCNI=true (chart v2). See Non-Primary CNI Mode for details.

Controller Leader Election Timing¶

The controller uses Kubernetes leader election. The following duration flags can be used to tune how quickly a standby controller takes over when the current leader stops renewing its lease:

args:
- --leader-elect-lease-duration=30s
- --leader-elect-renew-deadline=20s
- --leader-elect-retry-period=6s

The defaults are 30s, 20s, and 6s respectively. All values must be positive durations. The controller validates the relationship before creating Kubernetes clients:

• lease-duration must be greater than renew-deadline.
• renew-deadline must be greater than retry-period multiplied by the Kubernetes client-go leader-election jitter factor (1.2).

You can set the values through the installation script:

export LEADER_ELECT_LEASE_DURATION=1m
export LEADER_ELECT_RENEW_DEADLINE=40s
export LEADER_ELECT_RETRY_PERIOD=10s
bash install.sh

The Helm values are empty by default, so a chart only renders these flags when you set them. Use kube-ovn-controller.leaderElection in the classic chart:

kube-ovn-controller:
  leaderElection:
    leaseDuration: "30s"
    renewDeadline: "20s"
    retryPeriod: "6s"

Use controller.leaderElection in the v2 chart:

controller:
  leaderElection:
    leaseDuration: "30s"
    renewDeadline: "20s"
    retryPeriod: "6s"

kube-ovn-monitor replicas¶

kube-ovn-monitor runs with one replica by default. Configure the monitor Deployment replica count through Helm:

# classic chart
kube-ovn-monitor:
  replicas: 1

# v2 chart
monitor:
  replicas: 1

The classic chart uses kube-ovn-monitor.replicas, while the v2 chart uses monitor.replicas; both default to 1. In an HA OVN central deployment, set the replica count to the number of central nodes that need to be observed so kube-ovn-monitor can collect the local OVN Raft role from each node.

Because the Deployment is scheduled only on eligible master nodes and uses required hostname-based pod anti-affinity, do not set the replica count higher than the number of eligible master or central nodes. Otherwise, the extra Pods remain Pending.

During an upgrade, Helm renders the Deployment with the configured replica count instead of resetting it to 1. Manage this value in Helm values rather than relying only on a temporary kubectl scale change.

kube-ovn-v2 Deployment Tolerations¶

The kube-ovn-v2 chart provides configurable toleration lists for these workloads:

• controller.tolerations: kube-ovn-controller, defaulting to NoSchedule with operator: Exists and key: CriticalAddonsOnly with operator: Exists.
• central.tolerations: ovn-central, defaulting to the two entries above plus NoExecute with operator: Exists.
• monitor.tolerations: kube-ovn-monitor, with the same defaults as controller.tolerations.
• validatingWebhook.tolerations: kube-ovn-webhook, defaulting only to NoSchedule with operator: Exists.
• ic.tolerations: ovn-ic-controller, with the same defaults as central.tolerations.

These fields are rendered directly as spec.template.spec.tolerations on the corresponding Pod template. central renders a Deployment normally and a StatefulSet when central.hcp.enabled is true; ic is rendered only when features.enableOvnInterconnections is enabled. The defaults preserve the previous templates, so leaving the values unset keeps the existing behavior. The default keyless tolerations match every taint with the corresponding effect, including node.kubernetes.io/unschedulable. Because these workloads are normally placed on master nodes with hostname anti-affinity, a replacement Pod can be scheduled back onto a cordoned node after a drain or cordon. To make a component avoid cordoned nodes, set a keyed toleration list for each workload that needs to change, for example:

controller:
  tolerations:
    - key: node-role.kubernetes.io/control-plane
      operator: Exists
      effect: NoSchedule
    - key: node-role.kubernetes.io/master
      operator: Exists
      effect: NoSchedule
    - key: CriticalAddonsOnly
      operator: Exists

central:
  tolerations:
    - key: node-role.kubernetes.io/control-plane
      operator: Exists
      effect: NoSchedule
    - key: node-role.kubernetes.io/master
      operator: Exists
      effect: NoSchedule
    - key: CriticalAddonsOnly
      operator: Exists

Setting a field replaces the entire default list for that workload; the same example can be applied to monitor, validatingWebhook, and ic. Retain the tolerations required by the control-plane taints in your cluster. DaemonSets such as ovs-ovn, kube-ovn-agent, kube-ovn-pinger, and kube-ovn-speaker are unchanged and do not use these fields.

PDF Slack Support

Comments