Problem:
The units/kube-apiserver.service file is missing the --service-cluster-ip-range flag, which causes the Kubernetes API server to use a default service CIDR (10.0.0.0/24) that doesn't match the IP addresses included in the kube-apiserver certificate generated in Step 4.

Symptoms:
When deploying cluster addons like CoreDNS, pods fail to connect to the Kubernetes API with certificate validation errors:

x509: certificate is valid for 127.0.0.1, 10.32.0.1, ... but not 10.0.0.1

Root Cause:

1. In Step 4 (Provisioning a CA and Generating TLS Certificates), the ca.conf configuration generates a kube-apiserver certificate with 10.32.0.1 as a Subject Alternative Name (SAN). This assumes a service CIDR of 10.32.0.0/16.

2. In Step 8 (Bootstrapping the Kubernetes Control Plane), the units/kube-apiserver.service file does not specify --service-cluster-ip-range, causing kube-apiserver to use the default service CIDR of 10.0.0.0/24.

3. The kubernetes.default service gets assigned 10.0.0.1 instead of 10.32.0.1

4. When CoreDNS or other pods try to connect to https://10.0.0.1:443, the TLS handshake fails because 10.0.0.1 is not in the certificate's SAN list.

Files Affected:

• units/kube-apiserver.service - Missing --service-cluster-ip-range=10.32.0.0/16

Expected Behavior:
The kube-apiserver should be configured with --service-cluster-ip-range=10.32.0.0/16 to match the IP addresses in the generated certificate.

Proposed Fix:
Add the following line to units/kube-apiserver.service after the --service-account-issuer flag:

  --service-cluster-ip-range=10.32.0.0/16 \