Ubuntu 16.04搭建K8s集群后API访问异常：非/api/v1返回403求助

Hey there, let's work through troubleshooting this 403 Forbidden issue with your Kubernetes API server—since you used that quick 10-minute setup on Ubuntu 16.04, there are a few common culprits to check.

1. Verify Your Authentication Credentials #

First, make sure you're using valid credentials to access the API. Most 403s start with auth issues:

• If you're using kubectl, check your config file with kubectl config view. Confirm the context's associated user has a valid token or client certificate/key pair.
• If you're testing directly with curl, you need to include the cluster CA cert and valid client credentials. Use this command (replace paths with your actual file locations):

  curl --cacert /etc/kubernetes/pki/ca.crt \
       --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt \
       --key /etc/kubernetes/pki/apiserver-kubelet-client.key \
       https://[server-ip]:6443/api/v1/namespaces
  

• Alternatively, use a service account token for testing:

  # Fetch the default service account's token
  TOKEN=$(kubectl get secret $(kubectl get sa default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 -d)
  # Make the API request
  curl -H "Authorization: Bearer $TOKEN" \
       --cacert /etc/kubernetes/pki/ca.crt \
       https://[server-ip]:6443/api/v1/namespaces
  

2. Check RBAC Permissions #

Kubernetes uses RBAC to control access to API resources. If only /api/v1 works, your identity likely lacks permissions for other API groups:

• Test your current permissions with:

  kubectl auth can-i '*' '*' --all-namespaces
  

  If this returns no, your user/service account doesn't have cluster-wide access.
• Verify the cluster-admin role binding (the super-admin role) includes your identity:

  kubectl get clusterrolebinding cluster-admin -o yaml
  

  Look for your username or service account under the subjects section.
• For testing purposes (never do this in production), you can bind the cluster-admin role to the default service account:

  kubectl create clusterrolebinding default-admin --clusterrole=cluster-admin --serviceaccount=default:default
  

  Retest your API access after running this.

3. Inspect API Server Configuration #

The quick setup tutorial might have restricted enabled API groups in the API server:

• Find the API server pod in the kube-system namespace:

  kubectl get pods -n kube-system | grep kube-apiserver
  

• Check its startup parameters with:

  kubectl describe pod [kube-apiserver-pod-name] -n kube-system
  

  Look for the --runtime-config flag. If it only lists api/v1, that means other API groups (like apps/v1, extensions/v1beta1) are disabled.
• To fix this, edit the API server manifest (usually at /etc/kubernetes/manifests/kube-apiserver.yaml), update the --runtime-config line to include the groups you need, e.g.:

  --runtime-config=api/v1,apps/v1,extensions/v1beta1
  

  Save the file, and the kubelet will automatically restart the API server pod with the new config.

4. Dig Into API Server Logs #

Logs will give you exact details about why the 403 is happening:

• Pull the API server logs with:

  kubectl logs [kube-apiserver-pod-name] -n kube-system
  

• Search for 403 or Forbidden entries. The logs will tell you which user, resource, and permission is missing—this is the fastest way to pinpoint the root cause.

Quick Note for Ubuntu 16.04 #

Ubuntu 16.04 is end-of-life, and newer Kubernetes versions don't support it. If you're using an older kubeadm version, it might have default RBAC or API group restrictions that cause this issue. Consider upgrading to a compatible Kubernetes version (max 1.21.x for Ubuntu 16.04) if possible.

内容的提问来源于stack exchange，提问作者Bart de Lange