Skip to content

Conformance: Handling optional features #3997

Open
@johnbelamaric

Description

@johnbelamaric

This is an umbrella issue to track various aspects of managing optional features with respect to Kubernetes conformance.

By the current conformance test requirements, only non-optional features are eligible for conformance tests. However, there are many important features of Kubernetes that are either optional or rely upon an optional component to be deployed into order to function. For example:

  • Horizontal pod autoscaling requires the metrics server, an optional component, to be running (Promote pod autoscaling kubernetes#79954).
  • Persistent volumes require some underlying CSI provider (PVC/PV conformance testing discussion kubernetes#65155).
  • ServiceType LoadBalancer requires some form of external load balancer integration.
  • RBAC is an optional feature. Additionally, some features may only be available based upon specific roles (e.g., clusterAdmin).
  • DNS is technically optional but currently is required for conformance.

To ensure user workload portability, it is critical to validate that when an optional API / feature is available on a cluster, it behaves in a consistent way across providers. Some related efforts that have attempt to solve this in whole or in part include:

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/conformanceIssues or PRs related to kubernetes conformance testslifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.sig/architectureCategorizes an issue or PR as relevant to SIG Architecture.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions