Krane is unable to fully deploy resources when there are duplicate Kinds

[renescheepers]

Bug report

When a CRD installed with for kind "Deployment", Krane will be unable to deploy those resources if the scoping is different on the CRD. It will check the state of the wrong resource and in the wrong scope, cluster instead of namespace.

Expected behavior: deployment to succeed.

Actual behavior: Krane constantly checks if deployment is succeeded but eventually times out.

Version(s) affected: probably all versions.

Steps to Reproduce

1. Start a new KinD cluster.
2. Deploy the CRD in the collapsible below.
3. kubectl create ns example.
4. DEBUG=1 bundle exec exe/krane deploy example kind-krane -f krane-manifest.yaml --global-timeout=1m.
5. Krane does deploy the resource but will be unable to check the status.

In debug mode you can see that it uses the wrong command to get the resource status:

kubectl get Deployment --chunk-size=0 --context=kind-kind-krane --output=json --request-timeout=30

CRD Deployment

---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: deployments.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
  served: true
  storage: true
  schema:
    openAPIV3Schema:
      type: object
      properties:
        test:
          type: string
scope: Cluster
names:
  plural: deployments
  singular: deployment
  kind: Deployment

Deployment

---
kind: Deployment
apiVersion: apps/v1
metadata:
name: nginx-deployment
spec:
selector:
  matchLabels:
    deploy: example
template:
  metadata:
    labels:
      deploy: example
  spec:
    containers:
      - name: nginx
        image: nginx

Related to:

• Wrong CRD may be referenced by Custom Resource in global_deploy #880
• Wrong CRD may be referenced by Custom Resource with duplicate Kind #873

[sjagoe]

I'm facing this now with Role, defined by upbound.io.

In one of our clusters where we're testing crossplane, krane now can't deploy anything due to roles.rbac.authorization.k8s.io/v1 getting skipped entirely, because it overrides the built-in Role with the one defined in the iam.aws.upbound.io/v1beta1 apiVersion because the hash is keyed on kind, which is not unique.