Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move architecture docs into the architecture subfolder #5112

Merged
merged 1 commit into from
Oct 28, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions docs/architecture.md → docs/architecture/index.md
Original file line number Diff line number Diff line change
@@ -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

Expand All @@ -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).
File renamed without changes
2 changes: 1 addition & 1 deletion docs/internal/publishing_docs_using_mkdocs.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion docs/system-monitoring.md
Original file line number Diff line number Diff line change
@@ -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/).
Expand Down
2 changes: 1 addition & 1 deletion mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
Loading