krusty Ignores Resources with "List" Suffix in Kind Name Without Warning

[EulerLee]

What happened?

When using krusty from the Kustomize API, I noticed that it ignores resources whose Kind name ends with "List". For example, resources defined as Kind: AccessWhiteList are not included in the output of krusty. This occurs without any errors or warnings.

What did you expect to happen?

I expected all resources listed in the kustomization.yaml file to be processed by krusty, regardless of their Kind name. If certain resources are not compatible or cannot be processed, an error or warning should be provided.

How can we reproduce it (as minimally and precisely as possible)?

1. Create a set of YAML files defining custom resources, ensuring some have Kind names ending in "List".

# resources.yaml
apiVersion: infra.protonbase.io/v1alpha1
kind: AccessWhiteList
metadata:
  name: wlmls5769f
  namespace: dc7i4hyxzw
spec:
  rules:
  - sourceIps: 0.0.0.0/16

2. Add these files to a kustomization.yaml under the resources section.

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./resources.yaml

3. Run krusty to process the directory. dir like:

./
├── kustomization.yaml
└── resources.yaml

4. Observe that resources with Kind names ending in "List" are not processed.

package main

import (
	"fmt"
	"io/fs"

	securefs "github.com/fluxcd/pkg/kustomize/filesys"
	"sigs.k8s.io/kustomize/api/krusty"
	kustypes "sigs.k8s.io/kustomize/api/types"
)

func main() {
	rootDir := "YOUR_ROOT_DIR"              // for example: /tmp/euler
	subDir := "YOUR_SUB_DIR_UNDER_ROOT_DIR" // for example: /tmp/euler/test

	fst, err := securefs.MakeFsOnDiskSecureBuild(rootDir)
	if err != nil {
		panic(err)
	}

	buildOptions := &krusty.Options{
		LoadRestrictions: kustypes.LoadRestrictionsNone,
		PluginConfig:     kustypes.DisabledPluginConfig(),
	}
	k := krusty.MakeKustomizer(buildOptions)
	m, err := k.Run(fst, subDir)
	if err != nil {
		panic(err)
	}

	fmt.Println("Euler len: ", len(m.Resources()))
	for _, res := range m.Resources() {
		fmt.Printf("euler: resName: %s, resKind: %s, resApiVersion: %s\n", res.GetName(), res.GetKind(), res.GetApiVersion())
	}
}

Expected output

Euler len:  1
euler: resName: wlmls5769f, resKind: AccessWhitelist, resApiVersion: infra.protonbase.io/v1alpha1

or warning/error

Actual output

Euler len:  0

Kustomize version

sigs.k8s.io/kustomize/[email protected]

Operating system

None

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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/test-infra repository.

[Bharadwajshivam28]

I can take on this issue if no one is working. I need some details and steps to get started

[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.