headshed/mvk
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

rewording for mvk

Browse source
This commit is contained in:
Jon Brookes 2025-07-13 14:04:00 +01:00
parent 96a18d2b9b
commit 44fc9d76de
1 changed files with 6 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

12
src/content/docs/guides/mvk.md
View file

@ -7,17 +7,17 @@ Kubernetes is complicated but additional to this it is designed with cloud compu
Thus, self hosting options can be limiting.
Out of the box, Kubernetes 'expects' for there to be key ingredient of infrastructure to be present, for example, ingress, storage, load balancers. So if these fundamentals are not present, they need to be supplied in a form that Kubernetes can consume them.
Out of the box, Kubernetes 'expects' key ingredient of infrastructure to be present. For example, ingress, storage and load balancers. So if any of these are not present, they will need to be supplied in a form that Kubernetes can consume them.
Adding all these pre-requisites can be a challenge and even learning about Kubernetes, let alone setting up a development or 'lab' environment can quickly become messy. Knowing what to create in 'dev' as opposed to 'prod` may introduce unpredictable configuration, even technical debt.
Adding the missing pre-requisites can be a challenge. Even learning about Kubernetes, let alone setting up a development or 'lab' environment, can quickly become messy. Knowing what to create in 'dev' as opposed to 'prod` may introduce inconsistent configurations and can even result in adding technical debt.
Production environments can also become complex, difficult to manage, even over engineered which may add to technical debt.
Production environments can also become complex, difficult to manage, even over engineered.
Out of these scenarios, Minimal Viable Kubernetes (MVK) is a design pattern attempting to solve these issues.
Responding to these challenging scenarios, Minimal Viable Kubernetes (MVK) provides tooling and design patterns aimed toward solving these issues.
MVK is there for a minimal setup to get a viable implementation of Kubernetes up and running initially for test and development but also for production use in an entirely self hosted environment, outside of any managed Kubernetes or cloud platform that is proprietary in its design and provisioning.
MVK helps create a minimal K8s setup and one which is a viable implementation of Kubernetes. Initially this may be used for test and development work but extending this into production is also its goal. Typical use cases of MVK are aimed toward entirely self hosted environments. This may be entirely outside of any managed Kubernetes or cloud platform, that are often as not proprietary in their design and provisioning of k8s.
This increases portability, reduces the likelihood of 'vendor lock in'. It can reduce costs, provided that its users are or become more familiar with Kubernetes and its day to day operational and management requirements - spoiler alert, we think everyone should know more about this so as not to become totally reliant on others to do this for them - and above all, can increase control over our own digital sovereignty.
The goals of MVK are to increase portability and reduces 'vendor lock in'. It can also reduce costs, provided that its users are already, or become, familiar with Kubernetes and its day to day operational and management. *We think that everyone should know more about Kubernetes*. A greater understanding of k8s results in us all becoming less reliant on others doing this for us. It protects our industry from losing these skills entirely. Above all it can help us to gain control over our digital sovereignty.