It turns out that, as the pod is kube-scheduler, the /var/run/secrets/kubernetes.io/serviceaccount/token the logs are referring to are is mounted from /etc/kubernetes/scheduler.conf on the master node.

For whatever reason, this was a completely empty file in my cluster. I regenerated it by following the instructions for kube-scheduler on Kubernetes the hard way:

I ran the following in the /etc/kubernetes/pki directory (where the original CAs remained):

{

cat > kube-scheduler-csr.json <<EOF
{
  "CN": "system:kube-scheduler",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:kube-scheduler",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF

cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  kube-scheduler-csr.json | cfssljson -bare kube-scheduler

}

which generates kube-scheduler-key.pem and kube-scheduler.pem.

Next, I needed to generate the new config file using the instructions here.

I ran:

{
  kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://127.0.0.1:6443 \
    --kubeconfig=kube-scheduler.kubeconfig

  kubectl config set-credentials system:kube-scheduler \
    --client-certificate=kube-scheduler.pem \
    --client-key=kube-scheduler-key.pem \
    --embed-certs=true \
    --kubeconfig=kube-scheduler.kubeconfig

  kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-scheduler \
    --kubeconfig=kube-scheduler.kubeconfig

  kubectl config use-context default --kubeconfig=kube-scheduler.kubeconfig
}

which generates kube-scheduler.kubeconfig which I renamed and moved to /etc/kubernetes/scheduler.conf.

It was then just a case of reading the logs from the pod (kubectl logs kube-scheduler-xxxxxxx -n kube-system) which will complain about various things missing from the configuration file.

These were the 'clusters' and 'contexts' blocks of the YAML which I copied from one of the other configuration files in the same directory (after verifying that they were all identical).

After copying those into scheduler.conf the errors stopped and everything kicked back into life.