2024-11-05 18:16:15.868 [INFO][1] typha/client.go 253: Unable to initialize default Tier error=connection is unauthorized: tiers.crd.projectcalico.org is forbidden: User "system:serviceaccount:kube-system:calico-node" cannot create resource "tiers" in API group "crd.projectcalico.org" at the cluster scope
2024-11-05 18:16:15.868 [INFO][1] typha/client.go 258: Unable to initialize adminnetworkpolicy Tier error=connection is unauthorized: tiers.crd.projectcalico.org is forbidden: User "system:serviceaccount:kube-system:calico-node" cannot create resource "tiers" in API group "crd.projectcalico.org" at the cluster scope
2024-11-05 18:16:15.868 [ERROR][1] typha/daemon.go 318: Failed to initialize datastore error=connection is unauthorized: tiers.crd.projectcalico.org is forbidden: User "system:serviceaccount:kube-system:calico-node" cannot create resource "tiers" in API group "crd.projectcalico.org" at the cluster scope
`
Possible Solution
In the YAML located in the documentation, the calico-typha Deployment uses the serviceAccountName 'calico-node' and, by extension, the 'calico-node' ClusterRole. I was able to resolve this issue rather quickly by adding the 'create' verb to the list of resources (including tiers) under the 'crd.projectcalico.org' apiGroup.
Given that this ClusterRole is shared between the calico-node DaemonSet and the calico-typha Deployment, I wasn't sure if that was the Calico-approved way of handling this error. I would appreciate any further guidance here.
Hello,
Installing Calico v3.29 using the "Manifest" approach outlined on this document results in an error with the calico-typha Deployment. https://docs.tigera.io/calico/latest/getting-started/kubernetes/self-managed-onprem/onpremises#install-calico-with-kubernetes-api-datastore-more-than-50-nodes
I'm specifically using the section for "Install Calico with Kubernetes API datastore, more than 50 nodes".
This is the raw YAML that I am applying: https://raw.githubusercontent.com/projectcalico/calico/v3.29.0/manifests/calico-typha.yaml
Expected Behavior
I expect the calico-typha Pods to become healthy.
Current Behavior
The calico-typha Pods remain in a CrashLoopBackOff state. The output of 'kubectl logs' mentions the following failure:
` 2024-11-05 18:16:15.865 [INFO][1] typha/daemon.go 312: Initializing the datastore (if needed).
2024-11-05 18:16:15.868 [INFO][1] typha/client.go 253: Unable to initialize default Tier error=connection is unauthorized: tiers.crd.projectcalico.org is forbidden: User "system:serviceaccount:kube-system:calico-node" cannot create resource "tiers" in API group "crd.projectcalico.org" at the cluster scope
2024-11-05 18:16:15.868 [INFO][1] typha/client.go 258: Unable to initialize adminnetworkpolicy Tier error=connection is unauthorized: tiers.crd.projectcalico.org is forbidden: User "system:serviceaccount:kube-system:calico-node" cannot create resource "tiers" in API group "crd.projectcalico.org" at the cluster scope
2024-11-05 18:16:15.868 [ERROR][1] typha/daemon.go 318: Failed to initialize datastore error=connection is unauthorized: tiers.crd.projectcalico.org is forbidden: User "system:serviceaccount:kube-system:calico-node" cannot create resource "tiers" in API group "crd.projectcalico.org" at the cluster scope `
Possible Solution
In the YAML located in the documentation, the calico-typha Deployment uses the serviceAccountName 'calico-node' and, by extension, the 'calico-node' ClusterRole. I was able to resolve this issue rather quickly by adding the 'create' verb to the list of resources (including tiers) under the 'crd.projectcalico.org' apiGroup.
Given that this ClusterRole is shared between the calico-node DaemonSet and the calico-typha Deployment, I wasn't sure if that was the Calico-approved way of handling this error. I would appreciate any further guidance here.
Steps to Reproduce (for bugs)
Your Environment
Thanks!