Remove obsolete kubenet information from networking.md

docs/networking.md

@@ -13,7 +13,7 @@ listed below, are available which implement and manage this abstraction.
 The following table provides the support status for various networking providers with regards to kOps version:
 
 | Network provider | Experimental | Stable | Deprecated |         Removed |
-| ------------ | -----------: | -----: | ---------: | ------: |
+|------------------|-------------:|-------:|-----------:|----------------:|
 | AWS VPC          |          1.9 |   1.21 |          - |               - |
 | Calico           |          1.6 |   1.11 |          - |               - |
 | Canal            |         1.12 |      - |          - |               - |
@@ -60,8 +60,6 @@ Kubenet is the default networking option because of its simplicity, however, it
 production clusters which expect a gradual increase in traffic and/or workload over time. Such clusters
 will eventually "out-grow" the `kubenet` networking provider.
 
-For more on the `kubenet` networking provider, please see the [`kubenet` section of the Kubernetes documentation](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet).
-
 ### CNI
 
 [Container Network Interface](https://github.com/containernetworking/cni) provides a specification
@@ -111,7 +109,6 @@ You will notice that `kube-dns` and similar pods that depend on pod networks fai
 
 Here are some steps items that will confirm a good CNI install:
 
-- `kubelet` is running with the with `--network-plugin=cni` option.
 - The CNS provider started without errors.
 - `kube-dns` daemonset starts.
 - Logging on a node will display messages on pod create and delete.