Cannot access Kubernetes Service - Connection Refused - kubernetes

Question

I'm trying to get a very basic app running on my Kubernetes cluster.
It consists of an ASP.NET Core WebAPI and a .NET Core console application that it accessing the WebAPI.
In the console application, I receive the error: "Connection Refused":
[rro-a#dh-lnx-01 ~]$ sudo kubectl exec -it synchronizer-54b47f496b-lkb67 -n pv2-test -- /bin/bash
root#synchronizer-54b47f496b-lkb67:/app# curl http://svc-coreapi/api/Synchronizations
curl: (7) Failed to connect to svc-coreapi port 80: Connection refused
root#synchronizer-54b47f496b-lkb67:/app#
Below is my YAML for the service:
apiVersion: v1
kind: Service
metadata:
name: svc-coreapi
namespace: pv2-test
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
---
The YAML for the WebAPI:
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
creationTimestamp: null
labels:
app: pv2
name: coreapi
namespace: pv2-test
spec:
replicas: 1
selector:
matchLabels:
app: pv2
strategy: {}
template:
metadata:
annotations:
creationTimestamp: null
labels:
app: pv2
spec:
containers:
- env:
- name: DBNAME
value: <DBNAME>
- name: DBPASS
value: <PASSWORD>
- name: DBSERVER
value: <SQLSERVER>
- name: DBUSER
value: <DBUSER>
image: myrepoapi:latest
name: coreapi
ports:
- containerPort: 80
resources: {}
restartPolicy: Always
imagePullSecrets:
- name: pv2-repo-cred
status: {}
The most funny thing is: When I execute kubectl expose deployment coreapi --type=NodePort --name=svc-coreapi it works, but I do not want the WebAPI exposed to the outside.
Omitting the --type=NodePort reverts the type back to ClusterIP and I will get the Connection Refused again.
Can anyone tell me what I can do to resolve this issue?

Answer 1

As #David Maze suggested your ClusterIP service definition lacks selector field which is responsible for selecting a set of Pods labelled with key app and value pv2 as in your example:
...
spec:
replicas: 1
selector:
matchLabels:
app: pv2
strategy: {}
template:
metadata:
annotations:
creationTimestamp: null
labels:
app: pv2
...
Your service definition may look like this and it should work just fine:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: pv2
ports:
- protocol: TCP
port: 80
targetPort: 80