The status of Route/Ksvc is not updated even when KCert is updated
- Dominant language
- Go
- Stars
- 6.1k
- Forks
- 1.2k
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 2
Description
## In what area(s)?
/area networking
## What version of Knative?
HEAD
## Steps to Reproduce the Problem
### 1. Deploy Knative with autoTLS.
```
istioctl install -y
kubectl apply -f ${SERVING_REPO}/third_party/cert-manager-latest/
kubectl apply --filename https://storage.googleapis.com/knative-nightly/serving/latest/serving-crds.yaml
kubectl apply --filename https://storage.googleapis.com/knative-nightly/serving/latest/serving-core.yaml
kubectl apply --filename https://storage.googleapis.com/knative-nightly/net-istio/latest/release.yaml
kubectl create ns serving-tests
kubectl apply -f ${SERVING_REPO}/test/config/autotls/certmanager/caissuer/
kubectl patch cm config-network -n "knative-serving" -p '{"data":{"autoTLS":"Enabled"}}'
```
### 2. Modify `config-certmanager` with the invalid value
__Note:__ This is a simple step to produce the issue. The same issue happens with some other reasons like let's encrypt issued the certificates slowly.
```
$ kubectl edit cm -n knative-serving config-certmanager
```
BEFORE:
```
issuerRef: |
kind: ClusterIssuer
name: ca-issuer
```
AFTER
```
issuerRef: |
kind: ClusterIssuer
name: INVALID
```
### 3. Create Ksvc (it hangs due to invalid cert)
```
$ kn service create hello-example --image=gcr.io/knative-samples/helloworld-go
...
3.607s Certificate default.example.com is not ready.
```
The status of Ksvc and route are `CertificateNotReady` as expected.
```
$ kubectl get ksvc,rt
NAME URL LATESTCREATED LATESTREADY READY REASON
service.serving.knative.dev/hello-example https://hello-example.default.example.com hello-example-00001 hello-example-00001 Unknown CertificateNotReady
NAME URL READY REASON
route.serving.knative.dev/hello-example https://hello-example.default.example.com Unknown CertificateNotReady
```
### 4. Fix the cert by reverting step-2
```
$ kubectl edit cm -n knative-serving config-certmanager
```
AFTER
```
issuerRef: |
kind: ClusterIssuer
name: ca-issuer
```
### 5. Check the status
Kcert and King become `Ready`.
```
$ kubectl get kcert,king
NAME READY REASON
certificate.networking.internal.knative.dev/default.example.com True
NAME READY REASON
ingress.networking.internal.knative.dev/hello-example True
```
But Ksvc and Route are still `CertificateNotReady`.
```
$ kubectl get ksvc
NAME URL LATESTCREATED LATESTREADY READY REASON
hello-example https://hello-example.default.example.com hello-example-00001 hello-example-00001 Unknown CertificateNotReady
```
## Expected Behavior
- When Kcert and Kingress became ready at step-4, Ksvc should become Ready as well.
## Actual Behavior
- The status of Ksvc is not updated at step-4.
- When some events trigger the reconcile loop in controller, the status will be updated.
Contributor guide
Research direction
Start with the controller reconciliation path for Ksvc and Route and how KCert and KIngress readiness changes are propagated. Reproduce the invalid and corrected config-certmanager steps, then verify that Ksvc and Route become Ready immediately after the certificate and ingress recover, without another unrelated event.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100