diff --git a/docs/hardware_ready/ADRs/Longhorn_as_storage_solution.md b/docs/hardware_ready/ADRs/Longhorn_as_storage_solution.md index 2865101..5dce246 100644 --- a/docs/hardware_ready/ADRs/Longhorn_as_storage_solution.md +++ b/docs/hardware_ready/ADRs/Longhorn_as_storage_solution.md @@ -8,7 +8,6 @@ date: "2025-03-18" | --- | --- | --- | | approved | 2025-03-18 | Sofus Albertsen | - ## Context and Problem Statement ### Do i need it? @@ -16,12 +15,12 @@ date: "2025-03-18" Even though Kubernetes (and their Container Storage Interface) is production ready for persistency and statefull workloads, keeping your cluster stateless have several advantages: * Dead simple disaster recovery (and duplication) of your cluster: everything is defined as code, so (re)creating a cluster is as easy as running your setupscripts once more and wait for everything to come up. -* Backup and restore has never been simple, and Kubernetes is not solving this for you. +* Backup and restore has never been simple, and Kubernetes is not solving this for you. At it's core, we want stateless [cloud native applications](https://kodekloud.com/blog/cloud-native-principles-explained/). Remember the distinction between the need for persistency and ephemeral storage; your chaching service needs ephemeral storage, but does not need backup/restore of said data. Those are perfectly fitting for Kubernetes. -Often time your Database is sitting on some special hardware, and is catered to by specialized competences. +Often time your Database is sitting on some special hardware, and is catered to by specialized competences. Keep it that way, and connect to the database from your cluster. ### What are the criterias for choosing this? @@ -29,7 +28,7 @@ Keep it that way, and connect to the database from your cluster. * **Performance Requirements:** What are the expected Input/Output Operations Per Second (IOPS) that your applications will demand? What about throughput? * **Scalability Needs:** Are you able to add storage seamlessly after the initial creation? * **Data Availability and Durability:** What are you requrements to replica's, time to recover etc. -* **Team Expertise and Comfort Level:** What is your team's existing knowledge and experience with the specific storage solutions you are considering? +* **Team Expertise and Comfort Level:** What is your team's existing knowledge and experience with the specific storage solutions you are considering? ### What are our weights for making a choice? @@ -39,7 +38,6 @@ Therefore, the primary weight is; if you have a storage solution that already su Secondary, it is the complexity introduced that we will focus on. - ## Considered Options * **Longhorn:** A lightweight, reliable, and easy-to-use distributed block storage system for Kubernetes. It's built by Rancher (now SUSE). Key features include built-in snapshots, backups, replication, and a user-friendly GUI. It's designed specifically *for* Kubernetes and integrates deeply. @@ -50,22 +48,18 @@ Secondary, it is the complexity introduced that we will focus on. * **Portworx:** A commercial (paid) storage platform designed for Kubernetes. It offers high performance, high availability, and advanced features like data encryption, storage-level snapshots, and automated scaling. It's a mature and feature-rich solution, but comes with licensing costs. - ## Decision Outcome - -Chosen option: **Longhorn**, because it provides a good balance of features, ease of use, and integration with Kubernetes, while minimizing the complexity overhead for our team. +Chosen option: **Longhorn**, because it provides a good balance of features, ease of use, and integration with Kubernetes, while minimizing the complexity overhead for our team. It's a strong, open-source option that aligns well with our focus on simplicity. It meets our needs for persistent storage within the cluster without introducing the operational overhead of a more complex solution like Rook/Ceph. +Based on different scenarios, the following general recommendations can be made: -Based on different scenarios, the following general recommendations can be made: - -- For organizations that require massive scalability, support for block, object, and file storage within a unified system, and have a team with the necessary expertise to manage a complex distributed storage platform, Ceph/Rook is a powerful option. -- For users who are looking for a straightforward and reliable distributed block storage solution that is easy to deploy and manage within Kubernetes, especially for smaller to medium-sized environments, Longhorn is an excellent choice. -- If you lack the required skillset all together, and need a high-performance, feature-rich, and commercially supported solution, and where the licensing costs are justified then Portworx is our recommendation. - +* For organizations that require massive scalability, support for block, object, and file storage within a unified system, and have a team with the necessary expertise to manage a complex distributed storage platform, Ceph/Rook is a powerful option. +* For users who are looking for a straightforward and reliable distributed block storage solution that is easy to deploy and manage within Kubernetes, especially for smaller to medium-sized environments, Longhorn is an excellent choice. +* If you lack the required skillset all together, and need a high-performance, feature-rich, and commercially supported solution, and where the licensing costs are justified then Portworx is our recommendation. ### Consequences diff --git a/docs/software_ready/_index.md b/docs/software_ready/_index.md index c064540..5a84950 100644 --- a/docs/software_ready/_index.md +++ b/docs/software_ready/_index.md @@ -6,4 +6,12 @@ title: Getting your software ready | Problem domain | Description | Reason for importance | Tool recommendation | |:---:|:---:|:---:|:---:| -| Image Registry | A common place to store and fetch images | High availability, secure access control | Harbor | +| Image Registry | A common place to store and fetch images | High availability, secure access control | | +| Secret Management | Securely store and manage sensitive information like passwords and API keys | Prevent unauthorized access and data leaks | | +| Ingress Controller / Gateway API | Manage external access to services in the cluster | Enable routing, load balancing, and secure communication | | +| GitOps / Deployment Pipelines | Automate application deployments using Git as the source of truth | Ensure consistency, traceability, and faster deployments | | +| Monitoring Infrastructure | Observe and analyze the health and performance of the cluster and applications | Proactive issue detection and resolution | | +| Service Mesh | Manage service-to-service communication within the cluster | Enable observability, security, and traffic control | | +| Network Policies | Define rules for communication between pods and services | Enhance security by restricting unauthorized traffic | | +| Authorization Integration | Manage user and service access to cluster resources | Enforce role-based access control and compliance | | +| Container Scanning | Identify vulnerabilities in container images | Ensure secure and compliant deployments | |