cli: Rename kpr Protocols status field

[brb]

This commit renames the "Protocols" field to Socket LB Protocols" to better reflect the fact that the field indicates which protocols are handled by the host reachable svc (aka socket-lb).

The example output:

    $ cilium status --verbose
    [..]
    KubeProxyReplacement Details:
      Status:              Strict
      Socket LB Protocols: TCP, UDP
      Devices:             wlp3s0 192.168.178.29 (Direct Routing)
      Mode:                SNAT
      Backend Selection:   Random
      Session Affinity:    Enabled
      XDP Acceleration:    Disabled
      Services:
      - ClusterIP:      Enabled
      - NodePort:       Enabled (Range: 30000-32767)
      - LoadBalancer:   Enabled
      - externalIPs:    Enabled
      - HostPort:       Enabled

Also, I'm using socket-lb instead of host-reachable svc, as in v1.10 we are planning to rename the feature (it's used not only for reaching services from a host nents).

[borkmann]

But if you have kpr disabled, then Protocols: would not be shown as indicator, no?

[brb]

Yep, but it's not clear without reading the code / docs.

[borkmann]

But if status says 'strict', then it's indicator that it has to be enabled. If it says 'disabled', then it has to be disabled as well. So only in case of partial this questions comes up, and there we show the protocols. Maybe this is just a matter of documentation? What does the user make out of 'Socket LB'? If it's just for us debugging isn't the code as-is or sysdump sufficient?

[joestringer]

Should we just combine this with the "Protocols:" line with a clearer format like "Socket LB Protocols: "? Personally I was confused whether socket LB was enabled or not while debugging an issue, which is why I filed #14927. It doesn't make sense to me that you'd list a bunch of the feature aspects of the kube-proxy replacement explicitly but then for socket-lb you have to infer whether it's enabled or not based on this other line called "Protocols".

[borkmann]

I think the Protocols: TCP, UDP line needs rework perhaps. For example we might still handle TCP, UDP when KPR is disabled and Cilium only xlated ClusterIP. So there should be some sort of indicator what is handled where. E.g. if we have partial and for sock LB we only have TCP xlation enabled, then cilium status --verbose should probably tell which is handled where. Maybe this somehow begs for an output like ...

Protocols:           
- North-South:      TCP, UDP
- East-West:        TCP, UDP
 - Syscall:         TCP
 - NAT:             UDP

... not sure if this can be made nicer / less complicated though.

[brb]

The N-S and E-W terminology is not used in the k8s context, so it might confuse users. For now I'd just do as @joestringer suggested above.

[joestringer]

Is that true? Some other components like traefik have been discussing east-west and north-south in k8s context:

https://traefik.io/blog/beyond-kubernetes-bringing-microservices-together-with-service-mesh/

Also, I think that anyone trying to interpret this status section probably needs the kube-proxy replacement docs anyway so we can always write a very short sentence explaining north/south and east/west.

🤷‍♂️ I'm OK with either approach.

[brb]

Is that true?

Yeah, the source of truth doesn't have any single mention of N-S or E-W.

[brb]

test-me-please

[brb]

@joestringer @borkmann I've renamed the field Protocols to Socket LB Protocols. PTAL.

[brb]

test-me-please

[BurlyLuo]

KubeProxyReplacement Details:
Status: Strict
Socket LB: Enabled
Socket LB Protocols: TCP, UDP

root@bpf1:/home/cilium# cat /tmp/cilium/config-map/bpf-lb-sock
falseroot@bpf1:/home/cilium#

The above two feature is the same of different?

[BurlyLuo]

[brb]

The above two feature is the same of different?

The same.