diff --git a/build/charts/antrea-windows/conf/antrea-agent.conf b/build/charts/antrea-windows/conf/antrea-agent.conf index 5193ef5fd3c..8aa3a281782 100644 --- a/build/charts/antrea-windows/conf/antrea-agent.conf +++ b/build/charts/antrea-windows/conf/antrea-agent.conf @@ -119,7 +119,7 @@ antreaProxy: # To disable AntreaProxy, set this to false. It should be enabled on Windows, otherwise NetworkPolicy will # not take effect on Service traffic. enable: true - # ProxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from. + # proxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from. # Therefore, running kube-proxy is no longer required. This requires the AntreaProxy feature to be enabled. # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access # apiserver directly. diff --git a/build/charts/antrea/conf/antrea-agent.conf b/build/charts/antrea/conf/antrea-agent.conf index e140f3c0790..24eaf7df46b 100644 --- a/build/charts/antrea/conf/antrea-agent.conf +++ b/build/charts/antrea/conf/antrea-agent.conf @@ -342,7 +342,7 @@ antreaProxy: {{- with .Values.antreaProxy }} # To disable AntreaProxy, set this to false. enable: {{.enable}} - # ProxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic, + # proxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic, # regardless of where they come from. Therefore, running kube-proxy is no longer required. # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access # apiserver directly. @@ -365,7 +365,7 @@ antreaProxy: # External IPs of LoadBalancer Services. This is useful when the external LoadBalancer provides additional # capabilities (e.g. TLS termination) and it is desirable for Pod-to-ExternalIP traffic to be sent to the # external LoadBalancer instead of being load-balanced to an Endpoint directly by AntreaProxy. - # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and + # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when proxyAll is set to true and # kube-proxy is removed from the cluster, otherwise kube-proxy will still load-balance this traffic. proxyLoadBalancerIPs: {{ .proxyLoadBalancerIPs }} # The value of the "service.kubernetes.io/service-proxy-name" label for AntreaProxy to match. If it is set, diff --git a/build/yamls/antrea-aks.yml b/build/yamls/antrea-aks.yml index 1d9c4c57eff..64564b55682 100644 --- a/build/yamls/antrea-aks.yml +++ b/build/yamls/antrea-aks.yml @@ -4038,7 +4038,7 @@ data: antreaProxy: # To disable AntreaProxy, set this to false. enable: true - # ProxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic, + # proxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic, # regardless of where they come from. Therefore, running kube-proxy is no longer required. # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access # apiserver directly. @@ -4055,7 +4055,7 @@ data: # External IPs of LoadBalancer Services. This is useful when the external LoadBalancer provides additional # capabilities (e.g. TLS termination) and it is desirable for Pod-to-ExternalIP traffic to be sent to the # external LoadBalancer instead of being load-balanced to an Endpoint directly by AntreaProxy. - # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and + # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when proxyAll is set to true and # kube-proxy is removed from the cluster, otherwise kube-proxy will still load-balance this traffic. proxyLoadBalancerIPs: true # The value of the "service.kubernetes.io/service-proxy-name" label for AntreaProxy to match. If it is set, @@ -5110,7 +5110,7 @@ spec: kubectl.kubernetes.io/default-container: antrea-agent # Automatically restart Pods with a RollingUpdate if the ConfigMap changes # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments - checksum/config: f976029accf54258d01ad907fe19b50ac671eee014cd8aea968c6a0bc7e8f95a + checksum/config: 71bf05ff579aa9bea7b360669c5e2ce2830ca88dc4ab54480638ce006eaeaf11 labels: app: antrea component: antrea-agent @@ -5348,7 +5348,7 @@ spec: annotations: # Automatically restart Pod if the ConfigMap changes # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments - checksum/config: f976029accf54258d01ad907fe19b50ac671eee014cd8aea968c6a0bc7e8f95a + checksum/config: 71bf05ff579aa9bea7b360669c5e2ce2830ca88dc4ab54480638ce006eaeaf11 labels: app: antrea component: antrea-controller diff --git a/build/yamls/antrea-eks.yml b/build/yamls/antrea-eks.yml index 62e00bc5f1b..4cf276c9961 100644 --- a/build/yamls/antrea-eks.yml +++ b/build/yamls/antrea-eks.yml @@ -4038,7 +4038,7 @@ data: antreaProxy: # To disable AntreaProxy, set this to false. enable: true - # ProxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic, + # proxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic, # regardless of where they come from. Therefore, running kube-proxy is no longer required. # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access # apiserver directly. @@ -4055,7 +4055,7 @@ data: # External IPs of LoadBalancer Services. This is useful when the external LoadBalancer provides additional # capabilities (e.g. TLS termination) and it is desirable for Pod-to-ExternalIP traffic to be sent to the # external LoadBalancer instead of being load-balanced to an Endpoint directly by AntreaProxy. - # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and + # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when proxyAll is set to true and # kube-proxy is removed from the cluster, otherwise kube-proxy will still load-balance this traffic. proxyLoadBalancerIPs: true # The value of the "service.kubernetes.io/service-proxy-name" label for AntreaProxy to match. If it is set, @@ -5110,7 +5110,7 @@ spec: kubectl.kubernetes.io/default-container: antrea-agent # Automatically restart Pods with a RollingUpdate if the ConfigMap changes # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments - checksum/config: f976029accf54258d01ad907fe19b50ac671eee014cd8aea968c6a0bc7e8f95a + checksum/config: 71bf05ff579aa9bea7b360669c5e2ce2830ca88dc4ab54480638ce006eaeaf11 labels: app: antrea component: antrea-agent @@ -5349,7 +5349,7 @@ spec: annotations: # Automatically restart Pod if the ConfigMap changes # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments - checksum/config: f976029accf54258d01ad907fe19b50ac671eee014cd8aea968c6a0bc7e8f95a + checksum/config: 71bf05ff579aa9bea7b360669c5e2ce2830ca88dc4ab54480638ce006eaeaf11 labels: app: antrea component: antrea-controller diff --git a/build/yamls/antrea-gke.yml b/build/yamls/antrea-gke.yml index 22665a948c9..3e37bf206f5 100644 --- a/build/yamls/antrea-gke.yml +++ b/build/yamls/antrea-gke.yml @@ -4038,7 +4038,7 @@ data: antreaProxy: # To disable AntreaProxy, set this to false. enable: true - # ProxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic, + # proxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic, # regardless of where they come from. Therefore, running kube-proxy is no longer required. # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access # apiserver directly. @@ -4055,7 +4055,7 @@ data: # External IPs of LoadBalancer Services. This is useful when the external LoadBalancer provides additional # capabilities (e.g. TLS termination) and it is desirable for Pod-to-ExternalIP traffic to be sent to the # external LoadBalancer instead of being load-balanced to an Endpoint directly by AntreaProxy. - # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and + # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when proxyAll is set to true and # kube-proxy is removed from the cluster, otherwise kube-proxy will still load-balance this traffic. proxyLoadBalancerIPs: true # The value of the "service.kubernetes.io/service-proxy-name" label for AntreaProxy to match. If it is set, @@ -5110,7 +5110,7 @@ spec: kubectl.kubernetes.io/default-container: antrea-agent # Automatically restart Pods with a RollingUpdate if the ConfigMap changes # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments - checksum/config: 5299e6235e262daf606758cf900766470fcb8dd21a0d707a3ae284548bd8c2b2 + checksum/config: 91ff2b609519e4aaead6ab850252a49bbe674dec17f6f239c4d0fa6c7b5705f6 labels: app: antrea component: antrea-agent @@ -5346,7 +5346,7 @@ spec: annotations: # Automatically restart Pod if the ConfigMap changes # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments - checksum/config: 5299e6235e262daf606758cf900766470fcb8dd21a0d707a3ae284548bd8c2b2 + checksum/config: 91ff2b609519e4aaead6ab850252a49bbe674dec17f6f239c4d0fa6c7b5705f6 labels: app: antrea component: antrea-controller diff --git a/build/yamls/antrea-ipsec.yml b/build/yamls/antrea-ipsec.yml index 0c9afaa9857..c17048997b1 100644 --- a/build/yamls/antrea-ipsec.yml +++ b/build/yamls/antrea-ipsec.yml @@ -4051,7 +4051,7 @@ data: antreaProxy: # To disable AntreaProxy, set this to false. enable: true - # ProxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic, + # proxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic, # regardless of where they come from. Therefore, running kube-proxy is no longer required. # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access # apiserver directly. @@ -4068,7 +4068,7 @@ data: # External IPs of LoadBalancer Services. This is useful when the external LoadBalancer provides additional # capabilities (e.g. TLS termination) and it is desirable for Pod-to-ExternalIP traffic to be sent to the # external LoadBalancer instead of being load-balanced to an Endpoint directly by AntreaProxy. - # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and + # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when proxyAll is set to true and # kube-proxy is removed from the cluster, otherwise kube-proxy will still load-balance this traffic. proxyLoadBalancerIPs: true # The value of the "service.kubernetes.io/service-proxy-name" label for AntreaProxy to match. If it is set, @@ -5123,7 +5123,7 @@ spec: kubectl.kubernetes.io/default-container: antrea-agent # Automatically restart Pods with a RollingUpdate if the ConfigMap changes # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments - checksum/config: ba93df141f512a1f8483114b5994444c7231b298e7e9133483ddc1f4210ec395 + checksum/config: 2d75956786eb552eaba94f89dfa5c6bab570bf662b82449e9af31a57ca138750 checksum/ipsec-secret: d0eb9c52d0cd4311b6d252a951126bf9bea27ec05590bed8a394f0f792dcb2a4 labels: app: antrea @@ -5405,7 +5405,7 @@ spec: annotations: # Automatically restart Pod if the ConfigMap changes # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments - checksum/config: ba93df141f512a1f8483114b5994444c7231b298e7e9133483ddc1f4210ec395 + checksum/config: 2d75956786eb552eaba94f89dfa5c6bab570bf662b82449e9af31a57ca138750 labels: app: antrea component: antrea-controller diff --git a/build/yamls/antrea-windows-with-ovs.yml b/build/yamls/antrea-windows-with-ovs.yml index a3b0987f0a9..181af18900f 100644 --- a/build/yamls/antrea-windows-with-ovs.yml +++ b/build/yamls/antrea-windows-with-ovs.yml @@ -246,7 +246,7 @@ data: # To disable AntreaProxy, set this to false. It should be enabled on Windows, otherwise NetworkPolicy will # not take effect on Service traffic. enable: true - # ProxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from. + # proxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from. # Therefore, running kube-proxy is no longer required. This requires the AntreaProxy feature to be enabled. # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access # apiserver directly. @@ -306,7 +306,7 @@ spec: metadata: annotations: checksum/agent-windows: 86f999cb18501659a52d982f20b3df5cdf666ffd849f50ed183c366e75d01ac5 - checksum/windows-config: 10ad2be0a04b1752abc224fed0124f7b1da36efc5e7323e193eb38e11b25e798 + checksum/windows-config: 4f07164f32afc61e20b4aef984a8781142e5d99f7c58f7581e4ccfeabb34855f microsoft.com/hostprocess-inherit-user: "true" labels: app: antrea diff --git a/build/yamls/antrea-windows.yml b/build/yamls/antrea-windows.yml index 00d330405b7..2a383708453 100644 --- a/build/yamls/antrea-windows.yml +++ b/build/yamls/antrea-windows.yml @@ -174,7 +174,7 @@ data: # To disable AntreaProxy, set this to false. It should be enabled on Windows, otherwise NetworkPolicy will # not take effect on Service traffic. enable: true - # ProxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from. + # proxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from. # Therefore, running kube-proxy is no longer required. This requires the AntreaProxy feature to be enabled. # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access # apiserver directly. @@ -234,7 +234,7 @@ spec: metadata: annotations: checksum/agent-windows: 63f16e1fadb6b1354efda21c73702b4290400181136d4d47d4b1cd6a5f82d037 - checksum/windows-config: 10ad2be0a04b1752abc224fed0124f7b1da36efc5e7323e193eb38e11b25e798 + checksum/windows-config: 4f07164f32afc61e20b4aef984a8781142e5d99f7c58f7581e4ccfeabb34855f microsoft.com/hostprocess-inherit-user: "true" labels: app: antrea diff --git a/build/yamls/antrea.yml b/build/yamls/antrea.yml index b938d9f83bc..97fd9640a66 100644 --- a/build/yamls/antrea.yml +++ b/build/yamls/antrea.yml @@ -4038,7 +4038,7 @@ data: antreaProxy: # To disable AntreaProxy, set this to false. enable: true - # ProxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic, + # proxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic, # regardless of where they come from. Therefore, running kube-proxy is no longer required. # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access # apiserver directly. @@ -4055,7 +4055,7 @@ data: # External IPs of LoadBalancer Services. This is useful when the external LoadBalancer provides additional # capabilities (e.g. TLS termination) and it is desirable for Pod-to-ExternalIP traffic to be sent to the # external LoadBalancer instead of being load-balanced to an Endpoint directly by AntreaProxy. - # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and + # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when proxyAll is set to true and # kube-proxy is removed from the cluster, otherwise kube-proxy will still load-balance this traffic. proxyLoadBalancerIPs: true # The value of the "service.kubernetes.io/service-proxy-name" label for AntreaProxy to match. If it is set, @@ -5110,7 +5110,7 @@ spec: kubectl.kubernetes.io/default-container: antrea-agent # Automatically restart Pods with a RollingUpdate if the ConfigMap changes # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments - checksum/config: aca23e21519e0fc112647f23d3ce6f92a3dea0bc7ebf1c6d7a7eed2dbe80f0a3 + checksum/config: ebc0be79b0fc65db51609f5c9185ca8a0533e265811d14c687f577cf93497a58 labels: app: antrea component: antrea-agent @@ -5346,7 +5346,7 @@ spec: annotations: # Automatically restart Pod if the ConfigMap changes # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments - checksum/config: aca23e21519e0fc112647f23d3ce6f92a3dea0bc7ebf1c6d7a7eed2dbe80f0a3 + checksum/config: ebc0be79b0fc65db51609f5c9185ca8a0533e265811d14c687f577cf93497a58 labels: app: antrea component: antrea-controller diff --git a/docs/antrea-ipam.md b/docs/antrea-ipam.md index 3e4a412443a..41baa073e5a 100644 --- a/docs/antrea-ipam.md +++ b/docs/antrea-ipam.md @@ -278,8 +278,8 @@ where the underlay router will route the traffic to the destination VLAN. ### Requirements for this Feature As of now, this feature is supported on Linux Nodes, with IPv4, `system` OVS datapath -type, `noEncap`, `noSNAT` traffic mode, and `AntreaProxy` feature enabled. Configuration -with `ProxyAll` feature enabled is not verified. +type, `noEncap`, `noSNAT` traffic mode, and Antrea Proxy enabled. Configuration +with `proxyAll` enabled is not verified. The IPs in the `IPPools` without VLAN must be in the same underlay subnet as the Node IP, because inter-Node traffic of AntreaIPAM Pods is forwarded by the Node network. diff --git a/docs/antrea-network-policy.md b/docs/antrea-network-policy.md index 96ed35c1fcc..db4e27e226a 100644 --- a/docs/antrea-network-policy.md +++ b/docs/antrea-network-policy.md @@ -1490,7 +1490,7 @@ Kubernetes](https://kubernetes.io/docs/concepts/services-networking/dns-pod-serv Services. The reason is that Antrea will use the information included in A or AAAA DNS records to implement FQDN based policies. In the case of "normal" (not headless) Services, the DNS name resolves to the ClusterIP for the Service, but -policy rules are enforced after AntreaProxy Service Load-Balancing and at that +policy rules are enforced after Antrea Proxy Service Load-Balancing and at that stage the destination IP address has already been rewritten to the address of an endpoint backing the Service. For headless Services, a ClusterIP is not allocated and, assuming the Service has a selector, the DNS server returns A / @@ -1571,8 +1571,8 @@ A combination of Service name and Service Namespace can be used in `toServices` by this field. A sample policy can be found [here](#acnp-for-toservices-rule). Since `toServices` represents a combination of IP+port, it cannot be used with `to` or `ports` within the same egress rule. -Also, since the matching process relies on the groupID assigned to Service by AntreaProxy, this field can only be used when -AntreaProxy is enabled. +Also, since the matching process relies on the groupID assigned to Service by Antrea Proxy, this field can only be used when +Antrea Proxy is enabled. This clusterIP-based match has one caveat: direct access to the Endpoints of this Service is not affected by `toServices` rules. To restrict access towards backend Endpoints of a Service, define a `ClusterGroup` with `ServiceReference` @@ -1952,11 +1952,11 @@ Similar RBAC is applied to the ClusterGroup resource. won't be blocked by new rules. - For hairpin Service traffic, when a Pod initiates traffic towards the Service it provides, and the same Pod is selected as the Endpoint, NetworkPolicies will - consistently permit this traffic during ingress enforcement if AntreaProxy is enabled, + consistently permit this traffic during ingress enforcement if Antrea Proxy is enabled, irrespective of the ingress rules defined by the user. In the presence of ingress rules preventing access to the Service from Pods providing the Service, accessing the Service from one of these Pods will succeed if traffic is hairpinned back to the source Pod, and - will fail if a different Endpoint is selected by AntreaProxy. However, when AntreaProxy + will fail if a different Endpoint is selected by Antrea Proxy. However, when Antrea Proxy is disabled, NetworkPolicies may not function as expected for hairpin Service traffic. This is due to kube-proxy performing SNAT, which conceals the original source IP from Antrea. Consequently, NetworkPolicies are unable to differentiate between hairpin diff --git a/docs/antrea-proxy.md b/docs/antrea-proxy.md index 5164367db31..ccdf1ba31c2 100644 --- a/docs/antrea-proxy.md +++ b/docs/antrea-proxy.md @@ -1,10 +1,10 @@ -# AntreaProxy +# Antrea Proxy ## Table of Contents - [Introduction](#introduction) -- [AntreaProxy with proxyAll](#antreaproxy-with-proxyall) +- [Antrea Proxy with proxyAll](#antrea-proxy-with-proxyall) - [Removing kube-proxy](#removing-kube-proxy) - [Windows Nodes](#windows-nodes) - [Configuring load balancer mode for external traffic](#configuring-load-balancer-mode-for-external-traffic) @@ -16,26 +16,26 @@ ## Introduction -AntreaProxy was first introduced in Antrea v0.8 and has been enabled by default -on all platforms since v0.11. AntreaProxy enables some or all of the cluster's +Antrea Proxy was first introduced in Antrea v0.8 and has been enabled by default +on all platforms since v0.11. Antrea Proxy enables some or all of the cluster's Service traffic to be load-balanced as part of the OVS pipeline, instead of depending on kube-proxy. We typically observe latency improvements for Service -traffic when AntreaProxy is used. +traffic when Antrea Proxy is used. -While AntreaProxy can be disabled on Linux Nodes by setting the `AntreaProxy` +While Antrea Proxy can be disabled on Linux Nodes by setting the `AntreaProxy` Feature Gate to `false`, it should remain enabled on all Windows Nodes, as it is needed for correct NetworkPolicy implementation for Pod-to-Service traffic. -By default, AntreaProxy will only handle Service traffic originating from Pods +By default, Antrea Proxy will only handle Service traffic originating from Pods in the cluster, with no support for NodePort. However, starting with Antrea -v1.4, a new operating mode was introduced in which AntreaProxy can handle all +v1.4, a new operating mode was introduced in which Antrea Proxy can handle all Service traffic, including NodePort. See the following -[section](#antreaproxy-with-proxyall) for more information. +[section](#antrea-proxy-with-proxyall) for more information. -## AntreaProxy with proxyAll +## Antrea Proxy with proxyAll The `proxyAll` configuration parameter can be enabled in the Antrea -configuration if you want AntreaProxy to handle all Service traffic, with the +configuration if you want Antrea Proxy to handle all Service traffic, with the possibility to remove kube-proxy altogether and have one less DaemonSet running in the cluster. This is particularly interesting on Windows Nodes, since until the introduction of `proxyAll`, Antrea relied on userspace kube-proxy, which is @@ -43,19 +43,19 @@ no longer actively maintained by the K8s community and is slower than other kube-proxy backends. Note that on Linux, before Antrea v2.1, when `proxyAll` is enabled, kube-proxy -will usually take priority over AntreaProxy and will keep handling all kinds of +will usually take priority over Antrea Proxy and will keep handling all kinds of Service traffic (unless the source is a Pod, which is pretty unusual as Pods typically access Services by ClusterIP). This is because kube-proxy rules typically -come before the rules installed by AntreaProxy to redirect traffic to OVS. When -kube-proxy is not deployed or is removed from the cluster, AntreaProxy will then +come before the rules installed by Antrea Proxy to redirect traffic to OVS. When +kube-proxy is not deployed or is removed from the cluster, Antrea Proxy will then handle all Service traffic. -Starting with Antrea v2.1, when `proxyAll` is enabled, AntreaProxy will handle +Starting with Antrea v2.1, when `proxyAll` is enabled, Antrea Proxy will handle Service traffic destined to NodePort, LoadBalancerIP and ExternalIP, even if kube-proxy is present. This benefits users who want to take advantage of -AntreaProxy's advanced features, such as Direct Server Return (DSR) mode, but +Antrea Proxy's advanced features, such as Direct Server Return (DSR) mode, but lack control over kube-proxy's installation. This is accomplished by -prioritizing the rules installed by AntreaProxy over those installed by +prioritizing the rules installed by Antrea Proxy over those installed by kube-proxy, thus it works only with kube-proxy iptables mode. Support for other kube-proxy modes may be added in the future. @@ -141,7 +141,7 @@ kube-proxy: Starting with Antrea v1.13, the `defaultLoadBalancerMode` configuration parameter and the `service.antrea.io/load-balancer-mode` Service annotation -can be used to specify how you want AntreaProxy to handle external traffic +can be used to specify how you want Antrea Proxy to handle external traffic destined to LoadBalancerIPs and ExternalIPs of Services. Specifically, the mode determines how external traffic is processed when it's load balanced across Nodes. Currently, it has two options: `nat` (default) and `dsr`. @@ -209,8 +209,8 @@ configured to bind to that address and can therefore intercept queries. In case of a cache miss, queries can be sent to the cluster CoreDNS Pods thanks to a "shadow" Service which will expose CoreDNS Pods via a new ClusterIP. -When AntreaProxy is enabled (default), Pod DNS queries to the kube-dns ClusterIP -will be load-balanced directly by AntreaProxy to a CoreDNS Pod endpoint. This +When Antrea Proxy is enabled (default), Pod DNS queries to the kube-dns ClusterIP +will be load-balanced directly by Antrea Proxy to a CoreDNS Pod endpoint. This means that NodeLocal DNSCache is completely bypassed, which is probably not acceptable for users who want to leverage this feature to improve DNS performance in their clusters. While these users can update the Pod @@ -219,8 +219,8 @@ interface, this is not always ideal in the context of CaaS, as it can require everyone running Pods in the cluster to be aware of the situation. This is the reason why we initially introduced the `skipServices` configuration -option for AntreaProxy in Antrea v1.4. By adding the kube-dns Service (which -exposes CoreDNS) to the list, you can ensure that AntreaProxy will "ignore" Pod +option for Antrea Proxy in Antrea v1.4. By adding the kube-dns Service (which +exposes CoreDNS) to the list, you can ensure that Antrea Proxy will "ignore" Pod DNS queries, and that they will be forwarded to NodeLocal DNSCache. You can edit the `antrea-config` ConfigMap as follows: @@ -241,11 +241,11 @@ data: In some cases, the external LoadBalancer for a cluster provides additional capabilities (e.g., TLS termination) and it is desirable for Pods to access in-cluster Services through the external LoadBalancer. By default, this is not -the case as both kube-proxy and AntreaProxy will install rules to load-balance +the case as both kube-proxy and Antrea Proxy will install rules to load-balance this traffic directly at the source Node (even when the destination IP is set to the external `loadBalancerIP`). To circumvent this behavior, we introduced the -`proxyLoadBalancerIPs` configuration option for AntreaProxy in Antrea v1.5. This -option defaults to `true`, but when setting it to `false`, AntreaProxy will no +`proxyLoadBalancerIPs` configuration option for Antrea Proxy in Antrea v1.5. This +option defaults to `true`, but when setting it to `false`, Antrea Proxy will no longer load-balance traffic destined to external `loadBalancerIP`s, hence ensuring that this traffic can go to the external LoadBalancer. You can set it to `false` by editing the `antrea-config` ConfigMap as follows: @@ -262,7 +262,7 @@ data: proxyLoadBalancerIPs: false ``` -With the above configuration, AntreaProxy will ignore all external `loadBalancerIP`s. +With the above configuration, Antrea Proxy will ignore all external `loadBalancerIP`s. Starting with K8s v1.29, feature [LoadBalancerIPMode](https://kubernetes.io/docs/concepts/services-networking/service/#load-balancer-ip-mode) was introduced, providing users with a more fine-grained mechanism to control how every external `loadBalancerIP` behaves in a LoadBalancer Service. @@ -274,12 +274,12 @@ every external `loadBalancerIP` behaves in a LoadBalancer Service. destined for the corresponding external `loadBalancerIP` should be sent to the external LoadBalancer. -Starting with Antrea v2.0, AntreaProxy will respect `LoadBalancerIPMode` in LoadBalancer +Starting with Antrea v2.0, Antrea Proxy will respect `LoadBalancerIPMode` in LoadBalancer Services when the configuration option `proxyLoadBalancerIPs` is set to `true` -(default). In this case, AntreaProxy will serve only the external `loadBalancerIP`s +(default). In this case, Antrea Proxy will serve only the external `loadBalancerIP`s configured with `LoadBalancerIPModeVIP`, and those configured with -`LoadBalancerIPModeProxy` will bypass AntreaProxy. If the configuration option -`proxyLoadBalancerIPs` is set to `false`, AntreaProxy will ignore the external +`LoadBalancerIPModeProxy` will bypass Antrea Proxy. If the configuration option +`proxyLoadBalancerIPs` is set to `false`, Antrea Proxy will ignore the external `loadBalancerIP`s even if configured with `LoadBalancerIPModeVIP`. There are two important prerequisites for this feature: diff --git a/docs/design/architecture.md b/docs/design/architecture.md index 140a46e9087..1567195288a 100644 --- a/docs/design/architecture.md +++ b/docs/design/architecture.md @@ -205,7 +205,7 @@ so their source IP will be rewritten to the Node's IP before going out. ### ClusterIP Service Antrea supports two ways to implement Services of type ClusterIP - leveraging -`kube-proxy`, or AntreaProxy that implements load balancing for ClusterIP +`kube-proxy`, or Antrea Proxy that implements load balancing for ClusterIP Service traffic with OVS. When leveraging `kube-proxy`, Antrea Agent adds OVS flows to forward the packets @@ -222,12 +222,12 @@ the tunnel. See the [Kubernetes Service Proxies documentation](https://kubernetes.io/docs/reference/networking/virtual-ips) for more details. -When AntreaProxy is enabled, Antrea Agent will add OVS flows that implement +When Antrea Proxy is enabled, Antrea Agent will add OVS flows that implement load balancing and DNAT for the ClusterIP Service traffic. In this way, Service traffic load balancing is done inside OVS together with the rest of the forwarding, and it can achieve better performance than using `kube-proxy`, as there is no extra overhead of forwarding Service traffic to the host's network -stack and iptables processing. The AntreaProxy implementation in Antrea Agent +stack and iptables processing. The Antrea Proxy implementation in Antrea Agent leverages some `kube-proxy` packages to watch and process Service Endpoints. ### NetworkPolicy diff --git a/docs/design/ovs-pipeline.md b/docs/design/ovs-pipeline.md index 0dcf9ff7e07..5f3aecd2f07 100644 --- a/docs/design/ovs-pipeline.md +++ b/docs/design/ovs-pipeline.md @@ -257,7 +257,7 @@ Like K8s NetworkPolicy, several tables of the pipeline are dedicated to [Kuberne Service](https://kubernetes.io/docs/concepts/services-networking/service/) implementation (tables [NodePortMark], [SessionAffinity], [ServiceLB], and [EndpointDNAT]). -By enabling `proxyAll`, ClusterIP, NodePort, LoadBalancer, and ExternalIP are all handled by AntreaProxy. Otherwise, +By enabling `proxyAll`, ClusterIP, NodePort, LoadBalancer, and ExternalIP are all handled by Antrea Proxy. Otherwise, only in-cluster ClusterIP is handled. In this document, we use the sample K8s Services below. These Services select Pods with the label `app: web` as Endpoints. @@ -788,12 +788,13 @@ Flow 1 is for case 1, matching packets received on the local Antrea gateway port addresses. There are some cases where the source IP of the packets through the local Antrea gateway port is not the local Antrea gateway IP address: -- When Antrea is deployed with kube-proxy, and `AntreaProxy` is not enabled, packets from local Pods destined for Services - will first go through the gateway port, get load-balanced by the kube-proxy data path (undergoes DNAT) then re-enter - the OVS pipeline through the gateway port (through an "onlink" route, installed by Antrea, directing the DNAT'd packets - to the gateway port), resulting in the source IP being that of a local Pod. -- When Antrea is deployed without kube-proxy, and both `AntreaProxy` and `proxyAll` are enabled, packets from the external - network destined for Services will be routed to OVS through the gateway port without masquerading source IP. +- When Antrea is deployed with kube-proxy, and the feature `AntreaProxy` is not enabled, packets from local Pods destined + for Services will first go through the gateway port, get load-balanced by the kube-proxy data path (undergoes DNAT) + then re-enter the OVS pipeline through the gateway port (through an "onlink" route, installed by Antrea, directing the + DNAT'd packets to the gateway port), resulting in the source IP being that of a local Pod. +- When Antrea is deployed without kube-proxy, and both the feature `AntreaProxy` and option `proxyAll` are enabled, + packets from the external network destined for Services will be routed to OVS through the gateway port without + masquerading source IP. - When Antrea is deployed with kube-proxy, packets from the external network destined for Services whose `externalTrafficPolicy` is set to `Local` will get load-balanced by the kube-proxy data path (undergoes DNAT with a local Endpoint selected by the kube-proxy) and then enter the OVS pipeline through the gateway (through a "onlink" @@ -1303,7 +1304,7 @@ through the local Antrea gateway. In other words, these are connections for whic (SYN packet for TCP) was received through the local Antrea gateway. It rewrites the destination MAC address to that of the local Antrea gateway, loads `ToGatewayRegMark`, and forwards them to table [L3DecTTL]. This ensures that reply packets can be forwarded back to the local Antrea gateway in subsequent tables. This flow is required to handle -the following cases when AntreaProxy is not enabled: +the following cases when Antrea Proxy is not enabled: - Reply traffic for connections from a local Pod to a ClusterIP Service, which are handled by kube-proxy and go through DNAT. In this case, the destination IP address of the reply traffic is the Pod which initiated the connection to the diff --git a/docs/design/windows-design.md b/docs/design/windows-design.md index 0d80658c8c4..592d0f2f2d2 100644 --- a/docs/design/windows-design.md +++ b/docs/design/windows-design.md @@ -210,7 +210,7 @@ Kube-proxy userspace mode is configured to provide NodePort Service function. A "HNS Internal NIC" is provided to kube-proxy to configure Service addresses. The OpenFlow entries for the NodePort Service traffic on Windows are the same as those on Linux. -AntreaProxy implements the ClusterIP Service function. Antrea Agent installs routes to send ClusterIP Service +Antrea Proxy implements the ClusterIP Service function. Antrea Agent installs routes to send ClusterIP Service traffic from host network to the OVS bridge. For each Service, it adds a route that routes the traffic via a virtual IP (169.254.0.253), and it also adds a route to indicate that the virtual IP is reachable via antrea-gw0. The reason to add a virtual IP, rather than routing the traffic directly to antrea-gw0, is that diff --git a/docs/feature-gates.md b/docs/feature-gates.md index 287d9dacc58..8efb4388ed9 100644 --- a/docs/feature-gates.md +++ b/docs/feature-gates.md @@ -64,18 +64,15 @@ edit the Agent configuration in the ### AntreaProxy -`AntreaProxy` implements Service load-balancing for ClusterIP Services as part of the OVS pipeline, as opposed to -relying on kube-proxy. This only applies to traffic originating from Pods, and destined to ClusterIP Services. In -particular, it does not apply to NodePort Services. Please note that due to some restrictions on the implementation of -Services in Antrea, the maximum number of Endpoints that Antrea can support at the moment is 800. If the number of -Endpoints for a given Service exceeds 800, extra Endpoints will be dropped. +`AntreaProxy` enables Antrea Proxy which implements Service load-balancing for ClusterIP Services as part of the OVS +pipeline, as opposed to relying on kube-proxy. By default, this only applies to traffic originating from Pods, and +destined to ClusterIP Services. However, it can be configured to support all types of Services, replacing kube-proxy +entirely. Please refer to this [document](antrea-proxy.md) for extra information on Antrea Proxy and how it can be configured. Note that this feature must be enabled for Windows. The Antrea Windows YAML manifest provided as part of releases enables this feature by default. If you edit the manifest, make sure you do not disable it, as it is needed for correct NetworkPolicy implementation for Pod-to-Service traffic. -Please refer to this [document](antrea-proxy.md) for extra information on AntreaProxy and how it can be configured. - #### Requirements for this Feature When using the OVS built-in kernel module (which is the most common case), your kernel version must be >= 4.6 (as @@ -83,9 +80,9 @@ opposed to >= 4.4 without this feature). ### EndpointSlice -`EndpointSlice` enables Service EndpointSlice support in AntreaProxy. The EndpointSlice API was introduced in Kubernetes +`EndpointSlice` enables Service EndpointSlice support in Antrea Proxy. The EndpointSlice API was introduced in Kubernetes 1.16 (alpha) and it is enabled by default in Kubernetes 1.17 (beta), promoted to GA in Kubernetes 1.21. The EndpointSlice -feature will take no effect if AntreaProxy is not enabled. Refer to this [link](https://kubernetes.io/docs/tasks/administer-cluster/enabling-endpointslices/) +feature will take no effect if Antrea Proxy is not enabled. Refer to this [link](https://kubernetes.io/docs/tasks/administer-cluster/enabling-endpointslices/) for more information about EndpointSlice. If this feature is enabled but the EndpointSlice v1 API is not available (Kubernetes version is lower than 1.21), Antrea Agent will log a message and fallback to the Endpoints API. @@ -96,7 +93,7 @@ for more information about EndpointSlice. If this feature is enabled but the End ### TopologyAwareHints -`TopologyAwareHints` enables TopologyAwareHints support in AntreaProxy. For AntreaProxy, traffic can be routed to the +`TopologyAwareHints` enables TopologyAwareHints support in Antrea Proxy. For Antrea Proxy, traffic can be routed to the Endpoint which is closer to where it originated when this feature is enabled. Refer to this [link](https://kubernetes.io/docs/concepts/services-networking/topology-aware-hints/) for more information about TopologyAwareHints. @@ -111,7 +108,7 @@ for more information about TopologyAwareHints. mode determines how external traffic destined to LoadBalancerIPs and ExternalIPs of Services is processed when it's load balanced across Nodes. In DSR mode, external traffic is never SNAT'd and backend Pods running on Nodes that are not the ingress Node can reply to clients directly, bypassing the ingress Node. Therefore, DSR mode can preserve client IP of -requests, and usually has lower latency and higher throughput. It's only meaningful to use this feature when AntreaProxy +requests, and usually has lower latency and higher throughput. It's only meaningful to use this feature when Antrea Proxy is enabled and configured to proxy external traffic (proxyAll=true). Refer to this [link]( antrea-proxy.md#configuring-load-balancer-mode-for-external-traffic) for more information about load balancer mode. @@ -124,7 +121,7 @@ antrea-proxy.md#configuring-load-balancer-mode-for-external-traffic) for more in ### CleanupStaleUDPSvcConntrack -`CleanupStaleUDPSvcConntrack` enables support for cleaning up stale UDP Service conntrack connections in AntreaProxy. +`CleanupStaleUDPSvcConntrack` enables support for cleaning up stale UDP Service conntrack connections in Antrea Proxy. #### Requirements for this Feature @@ -155,7 +152,7 @@ for both Linux and Windows). In v0.11, this feature was graduated to Beta (enabl lifted. In order to support cluster Services as the destination for tracing requests, option `antreaProxy.enable` should be set -to true to enable AntreaProxy. +to true to enable Antrea Proxy. ### Flow Exporter diff --git a/docs/noencap-hybrid-modes.md b/docs/noencap-hybrid-modes.md index ab0c3b311a9..0c96e121c44 100644 --- a/docs/noencap-hybrid-modes.md +++ b/docs/noencap-hybrid-modes.md @@ -9,10 +9,10 @@ are in different subnets, but does not encapsulate when the source and the destination Nodes are in the same subnet. This document describes how to configure Antrea with the `NoEncap` and `Hybrid` modes. -The NoEncap and Hybrid traffic modes require AntreaProxy to support correct -NetworkPolicy enforcement, which is why trying to disable AntreaProxy in these +The NoEncap and Hybrid traffic modes require Antrea Proxy to support correct +NetworkPolicy enforcement, which is why trying to disable Antrea Proxy in these modes will normally cause the Antrea Agent to fail. It is possible to override -this behavior and force AntreaProxy to be disabled by setting the +this behavior and force Antrea Proxy to be disabled by setting the ALLOW_NO_ENCAP_WITHOUT_ANTREA_PROXY environment variable to true for the Antrea Agent in the [Antrea deployment yaml](../build/yamls/antrea.yml). For example: diff --git a/docs/prometheus-integration.md b/docs/prometheus-integration.md index 25a49b9b33c..47a4daf7a3b 100644 --- a/docs/prometheus-integration.md +++ b/docs/prometheus-integration.md @@ -207,15 +207,15 @@ duration of syncing internal-networkpolicy #### Antrea Proxy Metrics - **antrea_proxy_sync_proxy_rules_duration_seconds:** SyncProxyRules duration -of AntreaProxy in seconds +of Antrea Proxy in seconds - **antrea_proxy_total_endpoints_installed:** The number of Endpoints -installed by AntreaProxy +installed by Antrea Proxy - **antrea_proxy_total_endpoints_updates:** The cumulative number of Endpoint -updates received by AntreaProxy +updates received by Antrea Proxy - **antrea_proxy_total_services_installed:** The number of Services installed -by AntreaProxy +by Antrea Proxy - **antrea_proxy_total_services_updates:** The cumulative number of Service -updates received by AntreaProxy +updates received by Antrea Proxy ### Common Metrics Provided by Infrastructure diff --git a/docs/service-loadbalancer.md b/docs/service-loadbalancer.md index 7f8235da0db..3210ab5134e 100644 --- a/docs/service-loadbalancer.md +++ b/docs/service-loadbalancer.md @@ -36,7 +36,7 @@ LoadBalancer ## Service external IP management by Antrea Antrea supports external IP management for Services of type LoadBalancer -since version 1.5, which can work together with `AntreaProxy` or +since version 1.5, which can work together with Antrea Proxy or `kube-proxy` to implement Services of type LoadBalancer, without requiring an external load balancer. With the external IP management feature, Antrea can allocate an external IP for a Service of type LoadBalancer from an @@ -44,7 +44,7 @@ allocate an external IP for a Service of type LoadBalancer from an based on the ExternalIPPool's NodeSelector to host the external IP. Antrea configures the Service's external IP on the selected Node, and thus Service requests to the external IP will get to the Node, and they are then handled by -`AntreaProxy` or `kube-proxy` on the Node and distributed to the Service's +Antrea Proxy or `kube-proxy` on the Node and distributed to the Service's Endpoints. Antrea also implements a Node failover mechanism for Service external IPs. When Antrea detects a Node hosting an external IP is down, it will move the external IP to another available Node of the ExternalIPPool. @@ -56,7 +56,7 @@ enabled in the `kube-proxy` configuration. For more information about how to configure `kube-proxy`, please refer to the [Interoperability with kube-proxy IPVS mode](#interoperability-with-kube-proxy-ipvs-mode) section. -If you are using `kube-proxy` iptables mode or [`AntreaProxy` with `proxyAll`](antrea-proxy.md#antreaproxy-with-proxyall), +If you are using `kube-proxy` iptables mode or [Antrea Proxy with `proxyAll`](antrea-proxy.md#antrea-proxy-with-proxyall), no extra configuration change is needed. ### Configuration @@ -84,15 +84,15 @@ data: ServiceExternalIP: true ``` -The feature works with both `AntreaProxy` and `kube-proxy`, including the +The feature works with both Antrea Proxy and `kube-proxy`, including the following configurations: -- `AntreaProxy` without `proxyAll` enabled - this is `antrea-agent`'s default +- Antrea Proxy without `proxyAll` enabled - this is `antrea-agent`'s default configuration, in which `kube-proxy` serves the request traffic for Services -of type LoadBalancer (while `AntreaProxy` handles Service requests from Pods). -- `AntreaProxy` with `proxyAll` enabled - in this case, `AntreaProxy` handles +of type LoadBalancer (while Antrea Proxy handles Service requests from Pods). +- Antrea Proxy with `proxyAll` enabled - in this case, Antrea Proxy handles all Service traffic, including Services of type LoadBalancer. -- `AntreaProxy` disabled - `kube-proxy` handles all Service traffic, including +- Antrea Proxy disabled - `kube-proxy` handles all Service traffic, including Services of type LoadBalancer. #### Create an ExternalIPPool custom resource @@ -312,7 +312,7 @@ As MetalLB will allocate external IPs for all Services of type LoadBalancer, once it is running, the Service external IP management feature of Antrea should not be enabled to avoid conflicts with MetalLB. You can deploy Antrea with the default configuration (in which the `ServiceExternalIP` feature gate of -`antrea-agent` is set to `false`). MetalLB can work with both `AntreaProxy` and +`antrea-agent` is set to `false`). MetalLB can work with both Antrea Proxy and `kube-proxy` configurations of `antrea-agent`. ### Configure MetalLB with layer 2 mode diff --git a/docs/traceflow-guide.md b/docs/traceflow-guide.md index 0a3f553105f..bf4c2c0605b 100644 --- a/docs/traceflow-guide.md +++ b/docs/traceflow-guide.md @@ -30,7 +30,7 @@ graph. ## Prerequisites The Traceflow feature is enabled by default since Antrea version v0.11. In order -to use a Service as the destination in traces, AntreaProxy (also enabled by +to use a Service as the destination in traces, Antrea Proxy (also enabled by default since v0.11) is required. ## Start a New Traceflow diff --git a/docs/windows.md b/docs/windows.md index a2a31197ad0..871de34748e 100644 --- a/docs/windows.md +++ b/docs/windows.md @@ -142,10 +142,10 @@ configuration file as the Antrea Proxy `proxyAll` mode is enabled by default. # Defaults to "". It must be a host string, a host:port pair, or a URL to the base of the apiserver. kubeAPIServerOverride: "10.10.1.1:6443" - # Option antreaProxy contains AntreaProxy related configuration options. + # Option antreaProxy contains Antrea Proxy related configuration options. antreaProxy: - # ProxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from. - # Therefore, running kube-proxy is no longer required. This requires the AntreaProxy feature to be enabled. + # Option proxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from. + # Therefore, running kube-proxy is no longer required. This requires the Antrea Proxy feature to be enabled. # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access # apiserver directly. proxyAll: true diff --git a/pkg/agent/proxy/metrics/metrics.go b/pkg/agent/proxy/metrics/metrics.go index a14df15126f..ea71dc05e18 100644 --- a/pkg/agent/proxy/metrics/metrics.go +++ b/pkg/agent/proxy/metrics/metrics.go @@ -37,7 +37,7 @@ var ( ConstLabels: map[string]string{"ip_family": "v4"}, StabilityLevel: kmetrics.ALPHA, Name: "sync_proxy_rules_duration_seconds", - Help: "SyncProxyRules duration of AntreaProxy in seconds", + Help: "SyncProxyRules duration of Antrea Proxy in seconds", }, ) ServicesInstalledTotal = kmetrics.NewGauge( @@ -47,7 +47,7 @@ var ( ConstLabels: map[string]string{"ip_family": "v4"}, StabilityLevel: kmetrics.ALPHA, Name: "total_services_installed", - Help: "The number of Services installed by AntreaProxy", + Help: "The number of Services installed by Antrea Proxy", }, ) EndpointsInstalledTotal = kmetrics.NewGauge( @@ -57,7 +57,7 @@ var ( ConstLabels: map[string]string{"ip_family": "v4"}, StabilityLevel: kmetrics.ALPHA, Name: "total_endpoints_installed", - Help: "The number of Endpoints installed by AntreaProxy", + Help: "The number of Endpoints installed by Antrea Proxy", }, ) ServicesUpdatesTotal = kmetrics.NewCounter( @@ -67,7 +67,7 @@ var ( ConstLabels: map[string]string{"ip_family": "v4"}, StabilityLevel: kmetrics.ALPHA, Name: "total_services_updates", - Help: "The cumulative number of Service updates received by AntreaProxy", + Help: "The cumulative number of Service updates received by Antrea Proxy", }, ) EndpointsUpdatesTotal = kmetrics.NewCounter( @@ -77,7 +77,7 @@ var ( ConstLabels: map[string]string{"ip_family": "v4"}, StabilityLevel: kmetrics.ALPHA, Name: "total_endpoints_updates", - Help: "The cumulative number of Endpoint updates received by AntreaProxy", + Help: "The cumulative number of Endpoint updates received by Antrea Proxy", }, ) @@ -88,7 +88,7 @@ var ( ConstLabels: map[string]string{"ip_family": "v6"}, StabilityLevel: kmetrics.ALPHA, Name: "sync_proxy_rules_duration_seconds", - Help: "SyncProxyRules duration of AntreaProxy in seconds", + Help: "SyncProxyRules duration of Antrea Proxy in seconds", }, ) ServicesInstalledTotalV6 = kmetrics.NewGauge( @@ -98,7 +98,7 @@ var ( ConstLabels: map[string]string{"ip_family": "v6"}, StabilityLevel: kmetrics.ALPHA, Name: "total_services_installed", - Help: "The number of Services installed by AntreaProxy", + Help: "The number of Services installed by Antrea Proxy", }, ) EndpointsInstalledTotalV6 = kmetrics.NewGauge( @@ -108,7 +108,7 @@ var ( ConstLabels: map[string]string{"ip_family": "v6"}, StabilityLevel: kmetrics.ALPHA, Name: "total_endpoints_installed", - Help: "The number of Endpoints installed by AntreaProxy", + Help: "The number of Endpoints installed by Antrea Proxy", }, ) ServicesUpdatesTotalV6 = kmetrics.NewCounter( @@ -118,7 +118,7 @@ var ( ConstLabels: map[string]string{"ip_family": "v6"}, StabilityLevel: kmetrics.ALPHA, Name: "total_services_updates", - Help: "The cumulative number of Service updates received by AntreaProxy", + Help: "The cumulative number of Service updates received by Antrea Proxy", }, ) EndpointsUpdatesTotalV6 = kmetrics.NewCounter( @@ -128,7 +128,7 @@ var ( ConstLabels: map[string]string{"ip_family": "v6"}, StabilityLevel: kmetrics.ALPHA, Name: "total_endpoints_updates", - Help: "The cumulative number of Endpoint updates received by AntreaProxy", + Help: "The cumulative number of Endpoint updates received by Antrea Proxy", }, ) )