Merge pull request #37218 from tengqm/tweak-net-plugin

Tweak line wrappings in the network-plugins page

Author: k8s-ci-robot

content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md

@@ -12,9 +12,12 @@ weight: 10
 <!-- overview -->
 
 Kubernetes {{< skew currentVersion >}} supports [Container Network Interface](https://github.com/containernetworking/cni)
-(CNI) plugins for cluster networking. You must use a CNI plugin that is compatible with your cluster and that suits your needs. Different plugins are available (both open- and closed- source) in the wider Kubernetes ecosystem.
+(CNI) plugins for cluster networking. You must use a CNI plugin that is compatible with your
+cluster and that suits your needs. Different plugins are available (both open- and closed- source)
+in the wider Kubernetes ecosystem.
 
-A CNI plugin is required to implement the [Kubernetes network model](/docs/concepts/services-networking/#the-kubernetes-network-model). 
+A CNI plugin is required to implement the
+[Kubernetes network model](/docs/concepts/services-networking/#the-kubernetes-network-model). 
 
 You must use a CNI plugin that is compatible with the 
 [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) or later
@@ -26,43 +29,62 @@ CNI specification (plugins can be compatible with multiple spec versions).
 
 ## Installation
 
-A Container Runtime, in the networking context, is a daemon on a node configured to provide CRI Services for kubelet. In particular, the Container Runtime must be configured to load the CNI plugins required to implement the Kubernetes network model.
+A Container Runtime, in the networking context, is a daemon on a node configured to provide CRI
+Services for kubelet. In particular, the Container Runtime must be configured to load the CNI
+plugins required to implement the Kubernetes network model.
 
 {{< note >}}
-Prior to Kubernetes 1.24, the CNI plugins could also be managed by the kubelet using the `cni-bin-dir` and `network-plugin` command-line parameters.
-These command-line parameters were removed in Kubernetes 1.24, with management of the CNI no longer in scope for kubelet.
+Prior to Kubernetes 1.24, the CNI plugins could also be managed by the kubelet using the
+`cni-bin-dir` and `network-plugin` command-line parameters.
+These command-line parameters were removed in Kubernetes 1.24, with management of the CNI no
+longer in scope for kubelet.
 
 See [Troubleshooting CNI plugin-related errors](/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)
 if you are facing issues following the removal of dockershim.
 {{< /note >}}
 
-For specific information about how a Container Runtime manages the CNI plugins, see the documentation for that Container Runtime, for example:
+For specific information about how a Container Runtime manages the CNI plugins, see the
+documentation for that Container Runtime, for example:
+
 - [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni)
 - [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md)
 
-For specific information about how to install and manage a CNI plugin, see the documentation for that plugin or [networking provider](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
+For specific information about how to install and manage a CNI plugin, see the documentation for
+that plugin or [networking provider](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
 
 ## Network Plugin Requirements
 
-For plugin developers and users who regularly build or deploy Kubernetes, the plugin may also need specific configuration to support kube-proxy.
-The iptables proxy depends on iptables, and the plugin may need to ensure that container traffic is made available to iptables.
-For example, if the plugin connects containers to a Linux bridge, the plugin must set the `net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions correctly.
-If the plugin does not use a Linux bridge, but uses something like Open vSwitch or some other mechanism instead, it should ensure container traffic is appropriately routed for the proxy.
+For plugin developers and users who regularly build or deploy Kubernetes, the plugin may also need
+specific configuration to support kube-proxy. The iptables proxy depends on iptables, and the
+plugin may need to ensure that container traffic is made available to iptables. For example, if
+the plugin connects containers to a Linux bridge, the plugin must set the
+`net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions
+correctly. If the plugin does not use a Linux bridge, but uses something like Open vSwitch or
+some other mechanism instead, it should ensure container traffic is appropriately routed for the
+proxy.
 
-By default, if no kubelet network plugin is specified, the `noop` plugin is used, which sets `net/bridge/bridge-nf-call-iptables=1` to ensure simple configurations (like Docker with a bridge) work correctly with the iptables proxy.
+By default, if no kubelet network plugin is specified, the `noop` plugin is used, which sets
+`net/bridge/bridge-nf-call-iptables=1` to ensure simple configurations (like Docker with a bridge)
+work correctly with the iptables proxy.
 
 ### Loopback CNI
 
-In addition to the CNI plugin installed on the nodes for implementing the Kubernetes network model, Kubernetes also requires the container runtimes to provide a loopback interface `lo`, which is used for each sandbox (pod sandboxes, vm sandboxes, ...).
-Implementing the loopback interface can be accomplished by re-using the [CNI loopback plugin.](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) or by developing your own code to achieve this (see [this example from CRI-O](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91)).
+In addition to the CNI plugin installed on the nodes for implementing the Kubernetes network
+model, Kubernetes also requires the container runtimes to provide a loopback interface `lo`, which
+is used for each sandbox (pod sandboxes, vm sandboxes, ...).
+Implementing the loopback interface can be accomplished by re-using the
+[CNI loopback plugin.](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)
+or by developing your own code to achieve this (see
+[this example from CRI-O](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91)).
 
 ### Support hostPort
 
-The CNI networking plugin supports `hostPort`. You can use the official [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
+The CNI networking plugin supports `hostPort`. You can use the official
+[portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
 plugin offered by the CNI plugin team or use your own plugin with portMapping functionality.
 
-If you want to enable `hostPort` support, you must specify `portMappings capability` in your `cni-conf-dir`.
-For example:
+If you want to enable `hostPort` support, you must specify `portMappings capability` in your
+`cni-conf-dir`. For example:
 
 ```json
 {
@@ -97,11 +119,13 @@ For example:
 
 **Experimental Feature**
 
-The CNI networking plugin also supports pod ingress and egress traffic shaping. You can use the official [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth)
+The CNI networking plugin also supports pod ingress and egress traffic shaping. You can use the
+official [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth)
 plugin offered by the CNI plugin team or use your own plugin with bandwidth control functionality.
 
-If you want to enable traffic shaping support, you must add the `bandwidth` plugin to your CNI configuration file
-(default `/etc/cni/net.d`) and ensure that the binary is included in your CNI bin dir (default `/opt/cni/bin`).
+If you want to enable traffic shaping support, you must add the `bandwidth` plugin to your CNI
+configuration file (default `/etc/cni/net.d`) and ensure that the binary is included in your CNI
+bin dir (default `/opt/cni/bin`).
 
 ```json
 {
@@ -132,8 +156,8 @@ If you want to enable traffic shaping support, you must add the `bandwidth` plug
 }
 ```
 
-Now you can add the `kubernetes.io/ingress-bandwidth` and `kubernetes.io/egress-bandwidth` annotations to your pod.
-For example:
+Now you can add the `kubernetes.io/ingress-bandwidth` and `kubernetes.io/egress-bandwidth`
+annotations to your Pod. For example:
 
 ```yaml
 apiVersion: v1
@@ -146,3 +170,4 @@ metadata:
 ```
 
 ## {{% heading "whatsnext" %}}
+