"failed to sync *v1alpha2.GRPCRoute: context deadline exceeded" with gateway-grpcroute source

[zhengxiaoxuer]

What happened:
external-dns container is failing with error "failed to sync *v1alpha2.GRPCRoute: context deadline exceeded" when gateway-grpcroute source is enabled.

What you expected to happen:
DNS record created and container not restarting.

How to reproduce it (as minimally and precisely as possible):
Set values:

sources
  - gateway-httproute
  - gateway-grpcroute

Anything else we need to know?:

Environment:

• External-DNS version (use external-dns --version): 0.13.5 (installed from helm chart 1.13.0)
  DNS provider: Google
  Others: GKE (v1.26.5-gke.1400)

[Kyrremann]

I've followed the tutorial guide and end up with the same state.
https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/gateway-api.md#manifest-with-rbac

[Kyrremann]

Turns out GKE only supports httproute, so all other will fail.
See more in https://cloud.google.com/kubernetes-engine/docs/how-to/deploying-gateways#limitations

[erichorwath]

We see the same CrashLoopBackOff of external-dns 0.13.2 and 0.13.6 on 10-nodes Minikube 0.20.0 cluster (K8s 1.27.4, both Containerd and Docker runtime), reproducible in our pipeline.

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: kube-system
  name: external-dns
spec:
  selector:
    matchLabels:
      app: external-dns
  template:
    metadata:
      labels:
        app: external-dns
    spec:
      nodeSelector:
        node-role.kubernetes.io/control-plane: ""
      tolerations:
      - operator: Exists
        effect: NoSchedule
      - operator: Exists
        effect: NoExecute
      serviceAccountName: external-dns
      containers:
      - name: external-dns
        image: registry.k8s.io/external-dns/external-dns:v0.13.6
        args:
        - --source=service
        - --source=ingress
        - --source=istio-gateway
        - --source=istio-virtualservice
        - --provider=coredns
        - --log-level=debug
        env:
        - name: ETCD_URLS
          value: https://$cluster_id-control-plane:2379
        - name: ETCD_CA_FILE
          value: /etc/etcd/tls/ca.crt
        - name: ETCD_CERT_FILE
          value: /etc/etcd/tls/tls.crt
        - name: ETCD_KEY_FILE
          value: /etc/etcd/tls/tls.key
        volumeMounts:
        - mountPath: /etc/etcd/tls
          name: etcd-tls
          readOnly: true
      volumes:
      - secret:
          secretName: etcd-tls
        name: etcd-tls

[OzoneChris]

I had this after installing the standard channel CRDs for Gateway API (v1.0.0). It cleared up after I installed the experimental channel CRDs.

This was setting up a new cluster using the values file from an older cluster, it could be you need to ensure the selected sources are aligned with the resources you have in the cluster.

sources:
  - service
  - ingress
  - gateway-httproute
  - gateway-grpcroute
  - gateway-tlsroute
  - gateway-tcproute
  - gateway-udproute

[orenlevi111]

same here with aws EKS 1.26, latest 1.14.2 external-dns and when enabling "gateway-grpcroute" it fails.

[orenlevi111]

I figured out how to fix it before the PR,
add this to your values.yaml:

rbac:
  additionalPermissions:
    - apiGroups: [""]
      resources: ["namespaces"]
      verbs: ["get","watch","list"]
    - apiGroups: ["gateway.networking.k8s.io"]
      resources: ["gateways","httproutes","grpcroutes","tlsroutes","tcproutes","udproutes"] 
      verbs: ["get","watch","list"]

[ri0day]

@zhengxiaoxuer i had this issue before,then i found i was using standard channel gateway api 1.0 crd .which only support httproute ,
then i installed gateway api crd 1.0 from experimental channel .
the experimental channel support all Routes in external-dns docs
BTW, you also need got RBAC permission right

kubectl get crd|grep gateway
backendtlspolicies.gateway.networking.k8s.io                     2024-01-24T08:58:21Z
gatewayclasses.gateway.networking.k8s.io                         2024-01-23T06:24:10Z
gateways.gateway.networking.k8s.io                               2024-01-23T06:24:10Z
grpcroutes.gateway.networking.k8s.io                             2024-01-24T08:58:22Z
httproutes.gateway.networking.k8s.io                             2024-01-23T06:24:11Z
referencegrants.gateway.networking.k8s.io                        2024-01-23T06:24:11Z
tcproutes.gateway.networking.k8s.io                              2024-01-24T08:58:22Z
tlsroutes.gateway.networking.k8s.io                              2024-01-24T08:58:22Z
udproutes.gateway.networking.k8s.io                              2024-01-24T08:58:22Z

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.