Stephan Lo
43cbd69c9c
- Move all existing docs content (concepts, project, solution) to /docs/v1/ - Add legacy banner component to warn users about archived documentation - Create v1 index page with legacy notice and redirect guidance - Implement automatic banner display for all v1 paths - Preserve all original content for reference during migration This enables incremental content migration while maintaining access to original documentation.
23 lines
969 B
Markdown
23 lines
969 B
Markdown
---
|
|
title: Agnostic EDF Deployment
|
|
weight: 2
|
|
description: The implementation of EDF must be kubernetes provider agnostic
|
|
---
|
|
|
|
* Type: Proposal
|
|
* Owner: Stephan Lo (stephan.lo@telekom.de)
|
|
* Reviewers: EDF Architects
|
|
* Status: Speculative, revision 0.1
|
|
|
|
## Background
|
|
|
|
EDF is running as a controlplane - or let's say an orchestration plane, correct wording is still to be defined - in a kubernetes cluster.
|
|
Right now we have at least ArgoCD as controller of manifests which we provide as CNOE stacks of packages and standalone packages.
|
|
|
|
## Proposal
|
|
|
|
The implementation of EDF must be kubernetes provider agnostic. Thus each provider specific deployment dependency must be factored out into provider specific definitions or deployment procedures.
|
|
|
|
## Local deployment
|
|
|
|
This implies that EDF must always be deployable into a local cluster, whereby by 'local' we mean a cluster which is under the full control of the platform engineer, e.g. a kind cluster on their laptop.
|