Serving: Race Condition installing Serving from release yaml

[n3wscott]

/area API
/area test-and-release
/kind bug

Expected Behavior

Serving installs clean every time.

Actual Behavior

Install Serving with the following: kubectl apply --filename https://github.com/knative/serving/releases/download/v0.3.0/serving.yaml

And among the output are the following error lines:

unable to recognize "https://github.com/knative/serving/releases/download/v0.3.0/serving.yaml": no matches for kind "Image" in version "caching.internal.knative.dev/v1alpha1"
unable to recognize "https://github.com/knative/serving/releases/download/v0.3.0/serving.yaml": no matches for kind "Image" in version "caching.internal.knative.dev/v1alpha1"

Steps to Reproduce the Problem

1. Have a clean cluster.
2. Install istio.
3. Attempt to install Serving.

[akauppi]

Second this. So new to Knative I hardly can provide help, yet.

GKE with Kubernetes 1.11.6-gke.2

---

Hint for other newcomers who just want to get Knative 0.3.0 running - this worked for me:

$ kubectl apply --filename https://storage.googleapis.com/knative-releases/build/latest/release.yaml

Edit

After the above, also @n3wscott 's original command succeeds:

$ kubectl apply --filename https://github.com/knative/serving/releases/download/v0.3.0/serving.yaml
namespace "knative-serving" configured
...
image.caching.internal.knative.dev "queue-proxy" created
image.caching.internal.knative.dev "fluentd-sidecar" created
...

Most of the lines were "configured" or "unchanged" but the two above say "created". I had some problems with this installation so maybe this will fix it.

[hideakiaoyagi]

I encountered the event, too.
I think the cause of that event is that CustomResourceDefinition (CRD) is executed asynchronously.

If that event occurs, there are two temporary solutions:

1. After the error occurs, execute only the part that failed, that is, the following manifest:

apiVersion: caching.internal.knative.dev/v1alpha1
kind: Image
metadata:
  name: queue-proxy
  namespace: knative-serving
spec:
  image: gcr.io/knative-releases/github.com/knative/serving/cmd/queue@sha256:fc49125cb29f7bb2de2c4d6bd51153ce190cb522cf42df59898147d2074885cc
---
apiVersion: caching.internal.knative.dev/v1alpha1
kind: Image
metadata:
  name: fluentd-sidecar
  namespace: knative-serving
spec:
  image: k8s.gcr.io/fluentd-elasticsearch:v2.0.4

1. Split the YAML file and run it after a while.

I hope that a fundamental solution will be presented.

[csantanapr]

Users deploying on a clean cluster are hitting this, I just hit this problem.
Workaround for now is to run the command twice if you see the error unable to recognize

unable to recognize "https://github.com/knative/serving/releases/download/v0.3.0/serving.yaml": no matches for kind "Image" in version "caching.internal.knative.dev/v1alpha1"
unable to recognize "https://github.com/knative/serving/releases/download/v0.3.0/serving.yaml": no matches for kind "Image" in version "caching.internal.knative.dev/v1alpha1"

I think we should add a note to the install docs with the workaround in the mean time.

kubectl apply --filename https://github.com/knative/serving/releases/download/v0.3.0/serving.yaml

[mattmoor]

If this is from release yaml, then this issue probably is better suited for knative/docs?

[n3wscott]

This is fixed with the new labels.

[cliveseldon]

I'm still seeing this error following the docs: https://knative.dev/docs/install/knative-with-any-k8s/

First run with

 kubectl apply --selector knative.dev/crd-install=true \
   --filename https://github.com/knative/serving/releases/download/v0.8.0/serving.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.8.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.8.0/monitoring.yaml

Needed to run twice. Was using a fresh Kind cluster.

[csantanapr]

Yes I hit this recently also, always need to run twice with a sleep between the runs

Using kind also

[nimakaviani]

relevant: https://github.com/kubernetes-sigs/kind/issues/762

we attributed it to resource convergence taking longer on kind.

[Ciantic]

This still happens with kind. Using istio 1.3.0 and knative 0.9, and kind v0.5.1. Should this bug report be re-opened or kubernetes-sigs/kind#762 ?

[sumowrestler]

Getting this issue even with the reported fix, failed in first pass:

kubectl apply --selector knative.dev/crd-install=true \
  --filename https://github.com/knative/serving/releases/download/v0.9.0/serving.yaml \
  --filename https://github.com/knative/serving/releases/download/v0.9.0/serving-cert-manager.yaml

resulted in:

customresourcedefinition.apiextensions.k8s.io/certificates.networking.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/clusteringresses.networking.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/images.caching.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/ingresses.networking.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/metrics.autoscaling.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/podautoscalers.autoscaling.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/serverlessservices.networking.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/configurations.serving.knative.dev created
customresourcedefinition.apiextensions.k8s.io/revisions.serving.knative.dev created
customresourcedefinition.apiextensions.k8s.io/routes.serving.knative.dev created
customresourcedefinition.apiextensions.k8s.io/services.serving.knative.dev created
error: unable to recognize "https://github.com/knative/serving/releases/download/v0.9.0/serving.yaml": no matches for kind "Image" in version "caching.internal.knative.dev/v1alpha1"

simply ran again for it to succeed but would be awful if we can't make this deterministic.

[drnic]

I'm getting this on GKE with istio 1.3.0 from third_party folder, and v0.9.0 serving.

[cheld]

Problems still appears on Kubernetes v1.16.1 and Knative0.9. Fixed by rerun