apps: address known issues in apps/README.md

[spiffxp]

I'm breaking this issue out of #2150

I had hopes of making all apps follow some easily templated conventions that we could enforce so that:

• boilerplate could be automated away
• it's easy to tell what resources belong to which app
• it's easy to tell who "owns" an app (and how that maps to who can admin/deploy it, who can approve changes to its files, etc)

I documented the proposed conventions here: https://github.com/kubernetes/k8s.io/tree/main/apps#proposed-format

Some complexities showed up right away during the course of migrating apps over: https://github.com/kubernetes/k8s.io/tree/main/apps#known-issues

• app: label convention
  • cert-manager has multiple app: labels: cainjector, cert-manager, webhook, and many empty
  • consider a custom label k8s-infra-app:; could do prefix but then need to decide on a DNS name
  • is this a convention worth enforcing? perhaps namespace is enough?
• *.yaml can be more than k8s resources
  • consider a resources/ subdir convention for all k8s resources
  • allows for config files etc. at app root
• enforcement
  • OWNER constraints enforcemed by humans - we should automate this (and I know there are some OWNERS files that lack a sig/foo label right now)
  • no validation of yaml beyond yamllint - we now use conftest, but I don't know how much "it's valid kubernetes" it's doing for us
  • app: convention enforcement by humans - we should decide if we want this

Figure out which of these to turn into issues, checklist it up, make the known issues go away through deciding we don't care about them, or addressing/enforcing them.

/wg k8s-infra
/area cluster-infra
/milestone v1.23

[spiffxp]

/priority important-longterm

[spiffxp]

I'm proposing that we add area/apps/foo for each app foo as part of #508 (comment)

[ameukam]

/milestone clear

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[ameukam]

/remove-lifecycle stale
/lifecycle frozen
/milestone clear