Merge pull request #5112 from twz123/docs-move-arch-into-subfolder

Move architecture docs into the architecture subfolder
k0sproject · Oct 28, 2024 · 5fe53a4 · 5fe53a4
2 parents 8342b4d + fa4ce10
commit 5fe53a4
Show file tree

Hide file tree

Showing 7 changed files with 9 additions and 9 deletions.
diff --git a/docs/architecture.md → docs/architecture/index.md b/docs/architecture.md → docs/architecture/index.md
@@ -1,6 +1,6 @@
 # Architecture
 
-**Note:** As k0s is a new and dynamic project, the product architecture may occasionally outpace the documentation. The high level concepts and patterns, however, should always apply.
+**Note:** As k0s is a dynamic project, the product architecture may occasionally outpace the documentation. The high level concepts and patterns, however, should always apply.
 
 ## Packaging
 
@@ -12,28 +12,28 @@ The k0s package is a single, self-extracting binary that embeds Kubernetes binar
 - Provides a single package for all operating systems
 - Allows full version control for each dependency
 
-![k0s packaging as a single binary](img/k0s_packaging.png)
+![k0s packaging as a single binary](k0s_packaging.png)
 
 ## Control plane
 
 As a single binary, k0s acts as the process supervisor for all other control plane components. As such, there is no container engine or kubelet running on controllers by default, which thus means that a cluster user cannot schedule workloads onto controller nodes.
 
-![k0s Controller processes](img/k0s_controller_processes.png)
+![k0s Controller processes](k0s_controller_processes.png)
 
 Using k0s you can create, manage, and configure each of the components, running each as a "naked" process. Thus, there is no container engine running on the controller node.
 
 ## Storage
 
-Kubernetes control plane typically supports only etcd as the datastore. k0s, however, supports many other datastore options in addition to etcd, which it achieves by including [kine](https://github.com/k3s-io/kine). Kine allows the use of a wide variety of backend data stores, such as MySQL, PostgreSQL, SQLite, and dqlite (refer to the [`spec.storage` documentation](configuration.md#specstorage)).
+Kubernetes control plane typically supports only etcd as the datastore. k0s, however, supports many other datastore options in addition to etcd, which it achieves by including [kine](https://github.com/k3s-io/kine). Kine allows the use of a wide variety of backend data stores, such as MySQL, PostgreSQL, SQLite, and dqlite (refer to the [`spec.storage` documentation](../configuration.md#specstorage)).
 
 In the case of k0s managed etcd, k0s manages the full lifecycle of the etcd cluster. For example, by joining a new controller node with `k0s controller "long-join-token"` k0s  atomatically adjusts the etcd cluster membership info to allow the new member to join the cluster.
 
 **Note**: k0s cannot shrink the etcd cluster. As such, to shut down the k0s controller on a node that node must first be manually removed from the etcd cluster.
 
 ## Worker node
 
-![k0s worker processes](img/k0s_worker_processes.png)
+![k0s worker processes](k0s_worker_processes.png)
 
 As with the control plane, with k0s you can create and manage the core worker components as naked processes on the worker node.
 
-By default, k0s workers use [containerd](https://containerd.io) as a high-level runtime and [runc](https://github.com/opencontainers/runc) as a low-level runtime. Custom runtimes are also supported, refer to [Using custom CRI runtimes](runtime.md#using-custom-cri-runtimes).
+By default, k0s workers use [containerd](https://containerd.io) as a high-level runtime and [runc](https://github.com/opencontainers/runc) as a low-level runtime. Custom runtimes are also supported, refer to [Using custom CRI runtimes](../runtime.md#using-custom-cri-runtimes).
diff --git a/docs/img/k0s_controller_processes.png → ...architecture/k0s_controller_processes.png b/docs/img/k0s_controller_processes.png → ...architecture/k0s_controller_processes.png
diff --git a/docs/img/k0s_packaging.png → docs/architecture/k0s_packaging.png b/docs/img/k0s_packaging.png → docs/architecture/k0s_packaging.png
diff --git a/docs/img/k0s_worker_processes.png → docs/architecture/k0s_worker_processes.png b/docs/img/k0s_worker_processes.png → docs/architecture/k0s_worker_processes.png
diff --git a/docs/internal/publishing_docs_using_mkdocs.md b/docs/internal/publishing_docs_using_mkdocs.md
@@ -20,7 +20,7 @@ nav:
       - Run in Docker: k0s-in-docker.md
       - Single node set-up: k0s-single-node.md
   - Configuration Reference:
-      - Architecture: architecture.md
+      - Architecture: architecture/index.md
       - Networking: networking.md
       - Configuration Options: configuration.md
       - Using Cloud Providers: cloud-providers.md

diff --git a/docs/system-monitoring.md b/docs/system-monitoring.md
@@ -1,6 +1,6 @@
 # System components monitoring
 
-Controller nodes [are isolated](architecture.md#control-plane) by default, which thus means that a cluster user cannot schedule workloads onto controller nodes.
+Controller nodes [are isolated](architecture/index.md#control-plane) by default, which thus means that a cluster user cannot schedule workloads onto controller nodes.
 
 k0s provides a mechanism to expose system components for monitoring. System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts.
 You can read more about metrics for Kubernetes system components [here](https://kubernetes.io/docs/concepts/cluster-administration/system-metrics/).

diff --git a/mkdocs.yml b/mkdocs.yml
@@ -70,7 +70,7 @@ nav:
       - Common Pitfalls: troubleshooting.md
       - Support Insights: support-dump.md
   - Reference:
-      - Architecture: architecture.md
+      - Architecture: architecture/index.md
       - Command Line: cli/README.md
       - Kube-bench Security Benchmark: cis_benchmark.md
   - Releases & Support: releases.md