It is an ambiguous choice of words but the upshot is you cannot access the initContainer through a Service.
Kubernetes Services provide access to a set of Pods by matching to their labels. In this sense a service is an aggregator. I think this is the intended meaning.
There can also be multiple containers in a Pod, each using a different port. If the Pod is matched by a Service that service can be configured to provide access to both on different ports. So a service can also make multiple ports available, though I wouldn't call that aggregation.
Pods aren't exposed by a Service until their readiness probes pass and the Pod status is ready. An initContainer runs before the probes when the Pod status is initialising. So it is logical that it cannot be reached by a Service. It would also be odd to want to expose an initContainer externally as it is temporary by nature.
Is your aim in order to debug (https://unofficial-kubernetes.readthedocs.io/en/latest/tasks/debug-application-cluster/debug-init-containers/) or to allow other Pods/Containers to access? I believe the Pod would at init have an IP address but not one which would be guaranteed to be stable so I don't know whether you might be able to port-forward for debugging https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/
I notice you say you are looking to expose the initContainer in a Job. Servicing traffic in a Job would be an unusual aim. If the aim is to monitor the Job then see Monitoring a kubernetes job