Introduction

The error ipfamily IPv6 is not configured on cluster means your Service manifest asks Kubernetes for IPv6 behavior that the cluster does not support. Most often the manifest explicitly sets ipFamilies, ipFamilyPolicy, or a concrete IPv6 clusterIP while the cluster is IPv4-only.

The fix is not to keep retrying kubectl apply. You need to align the Service spec with the cluster networking mode, or rebuild the cluster with dual-stack or IPv6 enabled.

Why Kubernetes Rejects the Service

A Kubernetes Service is not just a label selector. It also allocates virtual IP addresses through the cluster network configuration. If the cluster was created with only IPv4 service CIDRs, the API server and controller manager cannot allocate an IPv6 Service address.

A manifest like this will fail on an IPv4-only cluster:

1apiVersion: v1
2kind: Service
3metadata:
4  name: demo
5spec:
6  selector:
7    app: demo
8  ports:
9    - port: 80
10      targetPort: 8080
11  ipFamilies:
12    - IPv6
13  ipFamilyPolicy: SingleStack

You may also see the error if you set clusterIP to an IPv6 literal or request PreferDualStack on a cluster that was never configured for dual-stack.

Fix the Manifest First

If your cluster is IPv4-only, remove the IPv6 request and let Kubernetes allocate an IPv4 Service IP.

1apiVersion: v1
2kind: Service
3metadata:
4  name: demo
5spec:
6  selector:
7    app: demo
8  ports:
9    - port: 80
10      targetPort: 8080
11  type: ClusterIP

That is the safest default. Kubernetes will pick the right address family for the cluster.

If you really need dual-stack, the manifest can look like this:

1apiVersion: v1
2kind: Service
3metadata:
4  name: demo
5spec:
6  selector:
7    app: demo
8  ports:
9    - port: 80
10      targetPort: 8080
11  ipFamilyPolicy: PreferDualStack
12  ipFamilies:
13    - IPv4
14    - IPv6

But that only works if the cluster itself was created with dual-stack networking and the CNI plugin supports it.

How to Verify Cluster Capability

Check the Service CIDR and cluster network setup before changing YAML blindly. A quick first step is to inspect existing Services and their IP families.

kubectl get svc -A -o wide
kubectl get svc kubernetes -o yaml
kubectl cluster-info dump | grep -i service-cluster-ip-range

If existing Service IPs are all IPv4 and the cluster was provisioned with a single IPv4 service range, your current cluster is not dual-stack.

On managed platforms, IPv6 support is also provider-dependent. Even if Kubernetes supports dual-stack at your version, the cloud integration, load balancer controller, and CNI still have to support it end to end.

When Rebuilding the Cluster Is the Real Fix

If the manifest is correct and your application genuinely requires IPv6, you need to provision a cluster with IPv6 or dual-stack from the start. This is often a cluster creation setting, not something you toggle casually after workloads already exist.

For example, a kind cluster needs dual-stack networking in its config. A managed cluster may require specific Kubernetes versions, VPC configuration, and CNI settings. The exact procedure depends on the platform, but the principle is stable: the Service spec cannot request an address family the cluster control plane does not know how to allocate.

Common Pitfalls

A common mistake is hard-coding ipFamilies when it is not needed. If you do not have a concrete requirement, let Kubernetes choose defaults.

Another issue is assuming Kubernetes version alone determines support. Version matters, but so do the control plane flags, service CIDRs, and CNI plugin. A cluster can run a version that knows about dual-stack while still being deployed as IPv4-only.

Developers also sometimes confuse Pod networking with Service networking. Even if Pods can reach IPv6 destinations externally, Service allocation may still be IPv4-only.

Finally, avoid copying manifests between clusters without checking the network assumptions. A YAML file that works in one environment can fail immediately in another because the cluster networking model is different.

Summary

• The error means the Service spec requests IPv6 on a cluster that does not provide it.
• Remove ipFamilies and related IPv6 fields if the cluster is IPv4-only.
• Use dual-stack Service settings only when the cluster was provisioned for dual-stack.
• Verify real cluster capability with kubectl and platform networking settings.
• If IPv6 is required, the correct fix may be cluster re-provisioning rather than YAML edits.