Information required related to service kubernetes

My question is that if a client let's say kubectl has to access a cluster for various get/delete/edit operations, it uses .kube/config file and there we specify API endpoint as DNS entry. Shown below is our DNS Entry for NLB.

$ cat config |grep 6443
server: https://ac1poc-20210407164708-kube-api-f5082ea18c7584ad.elb.us-east-1.amazonaws.com:6443

2. And if kubelet needs to talk to API endpoint, it has similar entry in its configuration file /etc/kubernetes/kubelet
3. Same for kube-proxy as well. So all these three external APIs have Network Load Balancer entry configured in their respective configuration files. That means all these send Packets to NLB whenever they want to communicate with API backend.

But then I've this service also as shown below. I wanted to ask when does this service comes into play. Which API uses this service?

$ kubectl describe svc kubernetes
Name:              kubernetes
Namespace:         default
Labels:            component=apiserver
                   provider=kubernetes
Annotations:       <none>
Selector:          <none>
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.96.0.1
IPs:               10.96.0.1
Port:              https  443/TCP
TargetPort:        6443/TCP
Endpoints:         172.36.11.131:6443,172.36.12.131:6443,172.36.13.131:6443
Session Affinity:  None
Events:            <none>

My question is that if a client let's say kubectl has to access a cluster for various get/delete/edit operations

2)And if kubelet needs to talk to API endpoint

Correct, those two interactions are solving the same problem: how does a process that is external to the kubernetes cluster reach the control-plane. One could imagine that it would be restricted to (for example) just the corporate VPN for kubectl operations, or just the worker subnets for kubelet.

kubelet actually doesn't need to use the NLB (meaning traffic going out of the VPC through any Nat GW/Internet GW to the NLB and back into the VPC), it is perfectly safe and effective to point kubelet's configuration at the "internal" side of that NLB, so long as the control-plane certificates have sufficient Subject Alternative Name entries to satisfy the TLS handshake. That's usually why people don't bother distinguishing those two cases, but if it is a security (or cost!) concern for your organization, it's 100% possible to split those two interactions

Which API uses this service?

The CNI Service points at the same control-plane but that traffic travels within the cluster, and that kubernetes.default.svc.cluster.local Service is available to all Namespaces all the time, and is how any in-Pod kubernetes client uses the built-in ServiceAccount token to reach the kubernetes API. That way, anything running inside the cluster does not need to have any configuration whatsoever in order to reach the API -- including Internet access -- because that in-cluster traffic does not leave the CNI network