There are different types of services: ClusterIP, NodePort, LoadBalancer and ExternalName. You can specify it in spec.type. Actually the default one, when not specified is not LoadBalancer, but ClusterIP, so in your case, simply leave away the type: LoadBalancer definition and use your serviceName as backend in your ingress resource. Example:

spec:
  rules:
  - host: your.fully.qualified.host.name
    http:
      paths:
      - backend:
          serviceName: your-internal-service-name
          servicePort: 80
        path: /

Keep in mind that for some cloud providers there's also the possibility to use an internal LoadBalancer without a public IP. This is done by adding an annotation to the service configuration. For Azure AKS it looks like this:

metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"

For Google's GKE the annotation is cloud.google.com/load-balancer-type: "Internal"

Following documentation you should do the following. More information: kubernetes.github.com

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
  name: rewrite
  namespace: default
spec:
  rules:
  - host: rewrite.bar.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /something(/|$)(.*)

For example, the ingress definition above will result in the following rewrites:

rewrite.bar.com/something rewrites to rewrite.bar.com/
rewrite.bar.com/something/ rewrites to rewrite.bar.com/
rewrite.bar.com/something/new rewrites to rewrite.bar.com/new

 apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: ingress
      annotations:
        kubernetes.io/ingress.class: "nginx"
        certmanager.k8s.io/cluster-issuer: wordpress-prod
        nginx.ingress.kubernetes.io/rewrite-target: /
    spec:
      tls:
      - hosts:
        - test.test.com
        secretName: prod
      rules:
      - host: test.test.com
        http:
          paths:
          - path: /service-1
            backend:
              serviceName: service-1
              servicePort: 80
          - path: /service-2
            backend:
              serviceName: service-2
              servicePort: 5000

Sharing here documentation for ingress to target multiple services you can redirect to multi-service.

Using this you can access services like

https://test.test.com/service-1

https://test.test.com/service-2

I will try to describe the objects you need in just words.

You don't need to create a load balancer for each service. When you're using an ingress controller (like nginx), the ingress controller itself will be the type load balancer. All your other services need to be something like ClusterIP type.

Afterwards you can decide how to link your ClusterIP services with the Nginx LoadBalancer: create an ingress for each service or one ingress that exposes each service based on some rule (like paths as @harsh-manvar shows in the post above).

When you say "it's not happening", it would be good if you could provide details on your setup.

In order for Nginx ingress controller to work, it needs to be defined either as a NodePort or LoadBalancer service type. The examples provided in the nginx documentation are using LoadBalancer. However, LoadBalancer only works when your cluster supports this object (that means running in most cloud providers like AWS/GCP/Azure/DigitalOcean or newer versions of minikube). On the other hand, NodePort will expose the ingress controller on the Kubernetes node where it runs (when using minikube, that usually means a VM of sorts which then needs to be port forwarded to be accessible).

To use ingress in a local environment, you can look into minikube. All you need is to run minikube addons enable ingress and it will deploy an nginx controller for you. Afterwards, all you need to do is define an ingress and depending on your setup you may need to use kubectl port-forward to port forward port 80 on an nginx controller pod to a local port on your machine.