Usually when one refers to L2 vs L3 CNI plugins, they are talking less about the reach-ability of their pods (public vs private), and more about the OSI network model layer of connectivity the networking plugin provides between that pod and other Kubernetes pods.

For example, if all pods can send L2 traffic to each other (e.g., ARP) then the CNI plugin is providing L2 connectivity. Most CNI plugins provide IP (L3) networking to Kubernetes pods, since that is what is defined by the Kubernetes networking model.

Some examples of Kubernetes network implementations that provide L3 networking across hosts: Calico, flannel, Canal, kube-router, etc.

The only example I can think of that can provide L2 networking across hosts is Weave Net, but I expect there are likely others I'm forgetting.

Note that many of the above can use encapsulation methods like VXLAN to provide pod-to-pod networking across hosts. This is commonly misunderstood to mean that they provide L2 networking between pods. However, they often still use an IP routing step between the pod and its host, meaning it provides L3 pod-to-pod connectivity.

Also note that many of the above connect pods on the same host using a linux bridge, meaning that pods on the same host will get L2 connectivity but pods on other hosts will be routed (L3). It's much easier to scale L3 networks to large number of endpoints, so this makes sense. Calico is a slight exception here, using an L3 routed network even for pods on the same host.