From 8fdaff0bc78b76a2f6f3dfd8fcc2b2ffc7cba02b Mon Sep 17 00:00:00 2001 From: Mike Bell Date: Tue, 5 Mar 2024 14:17:25 +0000 Subject: [PATCH 1/4] Initial commit of adr-38 split components infrastructure --- .../038-split-components-infrastructure.md | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 architecture-decision-record/038-split-components-infrastructure.md diff --git a/architecture-decision-record/038-split-components-infrastructure.md b/architecture-decision-record/038-split-components-infrastructure.md new file mode 100644 index 00000000..d2abf50a --- /dev/null +++ b/architecture-decision-record/038-split-components-infrastructure.md @@ -0,0 +1,41 @@ +# 38. Split Components Infrastructure + +Date: 2024-03-04 + +## Status + +🤔 Incomplete + +## Context + +As part of the move to Kubernetes 1.25 PSP was deprecated and replaced with Gatekeeper. This meant a large change in the way our cluster operates and the modules at a components level. While upgrading it became clear that there are a large number of components dependent on each other that are not required. This makes the component level difficult to work with. We also found modules that used non standard methods of declaring dependency because of the version of terraform used at the time. Removing dependencies at the components level will allow us to focus on future features such as [multi cluster](036-multi-cluster.md) and blue green clusters. + +We propose to add a new level to our build process called core. This splits our process into 3 distinct areas within our terraform: + +* EKS - Everything required to bring up a basic cluster. +* Core - Core components that are required for our users to be able to safely and securely deploy their application to. +* Components - Optional components that provide additional functionality to a cluster + +> Components are not optional in `live`. When testing new components and features all components should be used to make sure there are no edge case issues. + +### Considerations + +* Developing this using test clusters will be easier than `live`, documentation and a focus on how we deploy this to `live` should be at the front of the work. +* Evaluate each component to determine whether they are core or optional components. +* Prometheus CRDs are a hard requirement on a lot of components, we can split these into `core` but would that increase complexity? +* Each stage must be a concrete deliverable. + +## Decision + +We have decided to: + +* Start planning out the work required to split the components into `core`. +* Document the process of moving components. +* Test changes using test clusters. +* Apply the changes to `live`, `live-2` and `manager` + +## Consequences + +By implementing this solution we will be decreasing our component level complexity. + +It opens up a lot of future roadmap work. \ No newline at end of file From 3852e01dfa1fced3078f024a07ab85c60d8cda20 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Tue, 5 Mar 2024 14:18:31 +0000 Subject: [PATCH 2/4] Commit changes made by code formatters --- .../038-split-components-infrastructure.md | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/architecture-decision-record/038-split-components-infrastructure.md b/architecture-decision-record/038-split-components-infrastructure.md index d2abf50a..d15dbc1d 100644 --- a/architecture-decision-record/038-split-components-infrastructure.md +++ b/architecture-decision-record/038-split-components-infrastructure.md @@ -12,30 +12,30 @@ As part of the move to Kubernetes 1.25 PSP was deprecated and replaced with Gate We propose to add a new level to our build process called core. This splits our process into 3 distinct areas within our terraform: -* EKS - Everything required to bring up a basic cluster. -* Core - Core components that are required for our users to be able to safely and securely deploy their application to. -* Components - Optional components that provide additional functionality to a cluster +- EKS - Everything required to bring up a basic cluster. +- Core - Core components that are required for our users to be able to safely and securely deploy their application to. +- Components - Optional components that provide additional functionality to a cluster > Components are not optional in `live`. When testing new components and features all components should be used to make sure there are no edge case issues. ### Considerations -* Developing this using test clusters will be easier than `live`, documentation and a focus on how we deploy this to `live` should be at the front of the work. -* Evaluate each component to determine whether they are core or optional components. -* Prometheus CRDs are a hard requirement on a lot of components, we can split these into `core` but would that increase complexity? -* Each stage must be a concrete deliverable. +- Developing this using test clusters will be easier than `live`, documentation and a focus on how we deploy this to `live` should be at the front of the work. +- Evaluate each component to determine whether they are core or optional components. +- Prometheus CRDs are a hard requirement on a lot of components, we can split these into `core` but would that increase complexity? +- Each stage must be a concrete deliverable. ## Decision We have decided to: -* Start planning out the work required to split the components into `core`. -* Document the process of moving components. -* Test changes using test clusters. -* Apply the changes to `live`, `live-2` and `manager` +- Start planning out the work required to split the components into `core`. +- Document the process of moving components. +- Test changes using test clusters. +- Apply the changes to `live`, `live-2` and `manager` ## Consequences By implementing this solution we will be decreasing our component level complexity. -It opens up a lot of future roadmap work. \ No newline at end of file +It opens up a lot of future roadmap work. From c37862e04a2bf4d39b8b6e32f67a15bc3e179df1 Mon Sep 17 00:00:00 2001 From: Mike Bell Date: Tue, 5 Mar 2024 14:51:46 +0000 Subject: [PATCH 3/4] Update architecture-decision-record/038-split-components-infrastructure.md Co-authored-by: Steve Williams <105657964+sj-williams@users.noreply.github.com> --- .../038-split-components-infrastructure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/architecture-decision-record/038-split-components-infrastructure.md b/architecture-decision-record/038-split-components-infrastructure.md index d15dbc1d..3a5b08d1 100644 --- a/architecture-decision-record/038-split-components-infrastructure.md +++ b/architecture-decision-record/038-split-components-infrastructure.md @@ -8,7 +8,7 @@ Date: 2024-03-04 ## Context -As part of the move to Kubernetes 1.25 PSP was deprecated and replaced with Gatekeeper. This meant a large change in the way our cluster operates and the modules at a components level. While upgrading it became clear that there are a large number of components dependent on each other that are not required. This makes the component level difficult to work with. We also found modules that used non standard methods of declaring dependency because of the version of terraform used at the time. Removing dependencies at the components level will allow us to focus on future features such as [multi cluster](036-multi-cluster.md) and blue green clusters. +Following the upgrade to Kubernetes 1.25, PodSecurityPolicy was removed, and the team chose to use Gatekeeper's mutating capabilities to replace the functionality that was previously provided by our PSP configurations. This meant a large change in the way our cluster operates and the modules at a components level. While upgrading it became clear that there are a large number of components dependent on each other that are not required. This makes the component level difficult to work with. We also found modules that used non standard methods of declaring dependency because of the version of terraform used at the time. Removing dependencies at the components level will allow us to focus on future features such as [multi cluster](036-multi-cluster.md) and blue green clusters. We propose to add a new level to our build process called core. This splits our process into 3 distinct areas within our terraform: From 1ff3c33e20a0aad4809cea688188fbc3b6fb8b35 Mon Sep 17 00:00:00 2001 From: Mike Bell Date: Tue, 5 Mar 2024 14:51:51 +0000 Subject: [PATCH 4/4] Update architecture-decision-record/038-split-components-infrastructure.md Co-authored-by: Steve Williams <105657964+sj-williams@users.noreply.github.com> --- .../038-split-components-infrastructure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/architecture-decision-record/038-split-components-infrastructure.md b/architecture-decision-record/038-split-components-infrastructure.md index 3a5b08d1..34580853 100644 --- a/architecture-decision-record/038-split-components-infrastructure.md +++ b/architecture-decision-record/038-split-components-infrastructure.md @@ -20,7 +20,7 @@ We propose to add a new level to our build process called core. This splits our ### Considerations -- Developing this using test clusters will be easier than `live`, documentation and a focus on how we deploy this to `live` should be at the front of the work. +- Developing this using test clusters will be easier than `live`, documentation and a focus on how we deploy this to `live`, and safely migrate existing terraform state into its new s3 location should be at the front of the work. - Evaluate each component to determine whether they are core or optional components. - Prometheus CRDs are a hard requirement on a lot of components, we can split these into `core` but would that increase complexity? - Each stage must be a concrete deliverable.