Introduction

This error appears when an Ingress manifest is updated to networking.k8s.io/v1 but still uses the old v1beta1 backend shape. In the stable v1 API, serviceName and servicePort no longer exist directly under backend, so Kubernetes rejects the manifest as having unknown fields.

Why the Error Happens

In v1beta1, an Ingress backend often looked like this:

1apiVersion: networking.k8s.io/v1beta1
2kind: Ingress
3metadata:
4  name: demo
5spec:
6  rules:
7    - host: example.com
8      http:
9        paths:
10          - path: /
11            backend:
12              serviceName: web
13              servicePort: 80

That schema is no longer valid in networking.k8s.io/v1. The backend object was restructured so that the service reference now lives under backend.service.

When you keep the old field names after switching the apiVersion, the API server sees serviceName and servicePort as unknown fields and fails validation.

The Correct v1 Backend Shape

In v1, the same backend must be written like this:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: demo
5spec:
6  rules:
7    - host: example.com
8      http:
9        paths:
10          - path: /
11            pathType: Prefix
12            backend:
13              service:
14                name: web
15                port:
16                  number: 80

The important changes are:

• 'serviceName becomes backend.service.name'
• 'servicePort becomes backend.service.port.number or backend.service.port.name'
• 'pathType is required for each path'

Those are the changes behind this specific validation error.

Named Ports Also Changed Shape

If your Service uses a named port instead of a numeric port, the v1 syntax still uses the nested service.port object.

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: demo
5spec:
6  rules:
7    - host: example.com
8      http:
9        paths:
10          - path: /
11            pathType: Prefix
12            backend:
13              service:
14                name: web
15                port:
16                  name: http

This is a common migration detail. People often replace serviceName and forget that servicePort also changed shape, especially for named ports.

pathType Is Not Optional in v1

Another migration problem is forgetting pathType. The backend fields may be corrected, but the manifest still fails because v1 requires a path type such as:

• 'Prefix'
• 'Exact'
• 'ImplementationSpecific'

For example:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: demo
5spec:
6  ingressClassName: nginx
7  rules:
8    - host: example.com
9      http:
10        paths:
11          - path: /api
12            pathType: Prefix
13            backend:
14              service:
15                name: api
16                port:
17                  number: 8080

So the migration is not just a field rename. It is a schema update.

Default Backend Migration

If your old Ingress used a top-level backend, that field also changed shape in v1.

Old style:

1spec:
2  backend:
3    serviceName: web
4    servicePort: 80

New style:

1spec:
2  defaultBackend:
3    service:
4      name: web
5      port:
6        number: 80

That matters because some manifests mix both rule-based backends and a default backend, and both areas need to be migrated correctly.

Validate the Manifest Before Applying

A safe workflow is to run client-side or server-side validation before deploying the changed Ingress.

kubectl apply --dry-run=client -f ingress.yaml
kubectl apply --dry-run=server -f ingress.yaml

If the cluster version and schema do not match your manifest, those commands usually reveal the problem early. They are especially useful during API migrations, because the syntax may look plausible while still being invalid for the target resource version.

Migration Checklist

When moving from v1beta1 to v1, check all of these together:

• 'apiVersion changed to networking.k8s.io/v1'
• 'backend.serviceName replaced by backend.service.name'
• 'backend.servicePort replaced by backend.service.port.number or .name'
• 'pathType added to each path'
• 'defaultBackend updated if present'
• 'ingressClassName reviewed if the old manifest relied on annotations only'

That full list prevents the common "fixed one field, hit the next validation error" cycle.

Common Pitfalls

One common mistake is changing only the apiVersion and assuming the old backend structure still works. It does not.

Another pitfall is migrating serviceName but forgetting that servicePort also moved into a nested port object.

A third issue is correcting the backend and then hitting a second error because pathType was not added. The v1 schema requires more than one change.

Finally, do not assume old blog posts or examples are safe to copy into a modern cluster. Many of them still show v1beta1 syntax that is now invalid.

Summary

• The error happens because networking.k8s.io/v1 no longer accepts serviceName and servicePort directly under backend.
• In v1, use backend.service.name and backend.service.port.number or .name.
• Add pathType for every path when migrating to v1.
• Update top-level default backends too if your Ingress uses them.
• Validate the manifest with kubectl --dry-run before applying it to the cluster.