As DevOps team (=SCS user), I want to have the ability to create and use clusters on many different SCS-compliant container providers, where all relevant properties are either predefined by the SCS standard or can be controlled by a provider-independent cluster-settings.yaml file.
Relevant properties are those that tend to create trouble for the application deployment, e.g. k8s versions, CNI features, persistent volumes, ingress/load-balancers, anti-affinity rules (avoiding to have k8s nodes on the same host) ...
These properties should either be fixed by SCS (and then of course only evolve slowly over time) or be controllable by the customer (via a standardized, provider-independent cluster-params.yaml. For the controllable properties, we mandate existence and syntax and we may mandate all or some of the supported options. In any case, the supported options need to be discoverable (and the mechanism for discoverability should include the fixed properties as well).
Note that there is value in standardizing things that are not mandatory, in order for providers to use the same name/semantics for same things. (Obviously optional features may become mandatory for providers in the future if we decide so.)
Hints:
Extensibility: We allow for extensions, but they must be clearly distinguishable from standardized properties.
This epic should list the standardization proposals / ADRs as issues that we as SCS community want to define as SCS-compliant relevant. Some of the proposals might not make it for a v1 of the SCS standard (because they are not ready or deemed not important enough or downgraded to recommendations). The individual proposed properties / ADRs should come with a rationale and with (ideally comprehensive) conformance tests. We want to evolve the reference implementation(s) in parallel to the standardization, but intellectually keep a clear distinction b/w standards and implementation.
We need to create conformance tests for these properties; it is useful to define standards in terms of tests that must pass. (Test-driven standardization!) Obviously, using existing test suites (such as CNCF/sonobouy or aqua/kube-bench) and possibly contributing to them is a good way to do this.
Inspiration for the list below:
Individual topics for standardization:
Networking
Container Registry
Meta
Automation
Identity Management
Logging & Metrics
Security & Robustness
Storage
Tests
Definition of Done:
As DevOps team (=SCS user), I want to have the ability to create and use clusters on many different SCS-compliant container providers, where all relevant properties are either predefined by the SCS standard or can be controlled by a provider-independent cluster-settings.yaml file.
Relevant properties are those that tend to create trouble for the application deployment, e.g. k8s versions, CNI features, persistent volumes, ingress/load-balancers, anti-affinity rules (avoiding to have k8s nodes on the same host) ...
These properties should either be fixed by SCS (and then of course only evolve slowly over time) or be controllable by the customer (via a standardized, provider-independent
cluster-params.yaml. For the controllable properties, we mandate existence and syntax and we may mandate all or some of the supported options. In any case, the supported options need to be discoverable (and the mechanism for discoverability should include the fixed properties as well).Note that there is value in standardizing things that are not mandatory, in order for providers to use the same name/semantics for same things. (Obviously optional features may become mandatory for providers in the future if we decide so.)
Hints:
Extensibility: We allow for extensions, but they must be clearly distinguishable from standardized properties.
This epic should list the standardization proposals / ADRs as issues that we as SCS community want to define as SCS-compliant relevant. Some of the proposals might not make it for a v1 of the SCS standard (because they are not ready or deemed not important enough or downgraded to recommendations). The individual proposed properties / ADRs should come with a rationale and with (ideally comprehensive) conformance tests. We want to evolve the reference implementation(s) in parallel to the standardization, but intellectually keep a clear distinction b/w standards and implementation.
We need to create conformance tests for these properties; it is useful to define standards in terms of tests that must pass. (Test-driven standardization!) Obviously, using existing test suites (such as CNCF/sonobouy or aqua/kube-bench) and possibly contributing to them is a good way to do this.
Inspiration for the list below:
Individual topics for standardization:
Networking
Standardize k8s networking policies (CNI)
Service type LoadBalancer with externalTrafficPolicy: Local
LoadBalancerwithexternalTrafficPolicy: Localneeds to work out of the boxIngress Support (OPTIONAL)
Container Registry
Container registry feature overview
Registry Standard from DR SCS-0212
Derive a standard from the DR created in the previous registry issueSplit already existing document into a standard and a Decision Record only concerning the SCS clusterMeta
Supported k8s versions
K8s version support period
KaaS ControlPlane/worker machine flavors
Cluster management API
Automation
KaaS Cluster Management Gitops Controller
KaaS Gitops/CI tooling
Identity Management
Understand the requirements towards the IdP Broker to support the container layer
Implement Machine Identities
KaaS IAM federation with ID broker
Logging & Metrics
Metrics server support (OPT-OUT)(OPTIONAL)
Logging/Monitoring/Tracing features? (OPTIONAL)
Security & Robustness
Forwarding-porting and retesting of upstream intel patchset for SGX and OpenStack
K8s cluster baseline security setupK8s cluster hardeningMove Keycloak onto kubernetes powered runtime on management plane
KaaS Optional Cert-Manager
Distributed K8s nodes to ensure Anti-Affinity
KaaS Robustness features
Storage
Tests
Definition of Done: