Traefik IngressRoute CRD not Registering Any Routes

I'm configuring Traefik Proxy to run on a GKE cluster to handle proxying to various microservices. I'm doing everything through their CRDs and deployed Traefik to the cluster using a custom deployment. The Traefik dashboard is accessible and working fine, however when I try to setup an IngressRoute for the service itself, it is not accessible and it does not appear in the dashboard. I've tried setting it up with a regular k8s Ingress object and when doing that, it did appear in the dashboard, however I ran into some issues with middleware, and for ease-of-use I'd prefer to go the CRD route. Also, the deployment and service for the microservice seem to be deploying fine, they both appear in the GKE dashboard and are running normally. No ingress is created, however I'm unsure of if a custom CRD IngressRoute is supposed to create one or not.

Some information about the configuration:
I'm using Kustomize to handle overlays and general data
I have a setting through kustomize to apply the namespace users to everything

Below are the config files I'm using, and the CRDs and RBAC are defined by calling

kubectl apply -f https://raw.githubusercontent.com/traefik/traefik/v2.9/docs/content/reference/dynamic-configuration/kubernetes-crd-definition-v1.yml
kubectl apply -f https://raw.githubusercontent.com/traefik/traefik/v2.9/docs/content/reference/dynamic-configuration/kubernetes-crd-rbac.yml

deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: users-service
spec:
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: users-service
    spec:
      containers:
        - name: users-service
          image: ${IMAGE}
          imagePullPolicy: IfNotPresent

          ports:
            - name: web
              containerPort: ${HTTP_PORT}

          readinessProbe:
            httpGet:
              path: /ready
              port: web
            initialDelaySeconds: 10
            periodSeconds: 2

          envFrom:
            - secretRef:
                name: users-service-env-secrets

service.yml

apiVersion: v1
kind: Service
metadata:
  name: users-service
spec:
  ports:
    - name: web
      protocol: TCP
      port: 80
      targetPort: web
  selector:
    app: users-service

ingress.yml

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: users-stripprefix
spec:
  stripPrefix:
    prefixes:
      - /userssrv
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: users-service-ingress
spec:
  entryPoints:
    - service-port
  routes:
    - kind: Rule
      match: PathPrefix(`/userssrv`)
      services:
        - name: users-service
          namespace: users
          port: service-port
      middlewares:
        - name: users-stripprefix

If any more information is needed, just lmk. Thanks!

Solution

A default Traefik installation on Kubernetes creates two entrypoints:

web for http access, and
websecure for https access

But you have in your IngressRoute configuration:

entryPoints:
    - service-port

Unless you have explicitly configured Traefik with an entrypoint named "service-port", this is probably your problem. You want to remove the entryPoints section, or specify something like:

entryPoints:
  - web

If you omit the entryPoints configuration, the service will be available on all entrypoints. If you include explicit entrypoints, then the service will only be available on those specific entrypoints (e.g. with the above configuration, the service would be available via http:// and not via https://).

Not directly related to your problem, but if you're using Kustomize, consider:

Drop the app: users-service label from the deployment, the service selector, etc, and instead set that in your kustomization.yaml using the commonLabels directive.
Drop the explicit namespace from the service specification in your IngressRoute and instead use kustomize's namespace transformer to set it (this lets you control the namespace exclusively from your kustomization.yaml).

I've put together a deployable example with all the changes mentioned in this answer here.