As I see from your question and the YAML file in your comment, the possible reason as I think is that you set the command in your deployment container, this command will overwrite the default command in the image. So I doubt maybe your application does not start, you can take a check.

I will also suggest you check if the port you expose to the outside is the same as the port in the image.

Did you try to hit restApi URIs like

ExternalIP:Port/uri

This should be accessible, I also use this approach with AKS

I have been able to lift one of the 4 microservices.

I have tried to lift the three remaining microservices with the same YAML (changing the image URL and the port) and these do not work.

The YAML used is this:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: permissions
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: permissions
    spec:
      containers:
      - name: permissions
        image: URL IMAGE
        ports:
        - containerPort: 6060
      imagePullSecrets:
      - name: nameimage
---
apiVersion: v1
kind: Service
metadata:
  name: permissions
spec:
  type: LoadBalancer
  ports:
  - port: 6060
  selector:
    app: permissions

I added this to set resource limits for the others Microservices:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: users
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: users
    spec:
      containers:
      - name: users
        image: URL IMAGE
        resources:
          requests:
          limits:
            memory: "128Mi"
            cpu: "500m"
        ports:
        - containerPort: 6061
---
apiVersion: v1
kind: Service
metadata:
  name: users
spec:
  type: LoadBalancer
  ports:
  - port: 6061
  selector:
    app: users

As I said, I could only lift the first one.

Some help?

Thanks!

Kubernetes is a little bit more complex than simple docker containers, so it might get confusing to get it running at first. I will explain at which points you need to configure exposure of a service.

Each container has an own ip address space, so each container can use the same port for an application. In your case you might want to use port 6060. This is the port the application needs to bind to and on all network interfaces (ip 0.0.0.0) to be reachable from the outside. This is the port you would declare as EXPOSE in your dockerfile.

When testing locally you can map each container to a different local port for testing: docker run -p external-port:internal-port

The port you use for EXPOSE is the port you configure as containerPort in a Pod or Deployment.

One or many pods are exposed as load balanced service inside kubernetes using a Service. There you might want to map a request port - for http usually 80 - to the container port, in your case 6060.

The service can then be exposed externally using a LoadBalancer. The external IP of the LoadBalancer will be mapped to the (virtual IP) of your Service, the Service maps the request port to the container port and selects an appropriate pod using the selector. The pod contains a container listening on the container port and then replies to your request.

The whole chain must be configured correctly in order to get it working. Keeping it simple (not using different ports for each application) makes it easier to get right.