Refactor documentation and provide a website (#173)

docs/README.md

@@ -1,18 +0,0 @@
-# Kamaji documentation
-
-- [Core Concepts](./concepts.md)
-- [Architecture](./architecture.md)
-- [Getting started](./getting-started-with-kamaji.md)
-- Guides:
-  - [Deploy Kamaji on generic infrastructure](./kamaji-deployment-guide.md)
-  - [Deploy Kamaji on Azure](./kamaji-azure-deployment-guide.md)
-  - Deploy Kamaji on AWS
-  - Deploy Kamaji on GCP
-  - Deploy Kamaji on OpenStack
-  - [Setup Konnectivity service](./konnectivity.md)
-  - [MySQL as Kamaji datastore](./mysql-datastore.md)
-  - [PostgreSQL as Kamaji datastore](./postgresql-datastore.md)
-  - [Tenant Cluster Upgrade](./upgrade.md)
-- [Reference](./reference.md)
-- [CNCF Conformance](./conformance.md)
-- [Versioning](./versioning.md)

docs/architecture.md

@@ -1 +0,0 @@
-# Kamaji architecture

docs/content/concepts.md

@@ -1,6 +1,14 @@
-# Core Concepts
+# Concepts
 
-Kamaji is a Kubernetes Operator. It turns any Kubernetes cluster into an _“admin cluster”_ to orchestrate other Kubernetes clusters called _“tenant clusters”_. 
+Kamaji is a Kubernetes Operator. It turns any Kubernetes cluster into an _“admin cluster”_ to orchestrate other Kubernetes clusters called _“tenant clusters”_.
+
+These are requirements of the design behind Kamaji:
+
+- Communication between the _“admin cluster”_ and a _“tenant cluster”_ is unidirectional. The _“admin cluster”_ manages a _“tenant cluster”_, but a _“tenant cluster”_ has no awareness of the _“admin cluster”_.
+- Communication between different _“tenant clusters”_ is not allowed.
+- The worker nodes of tenant should not run anything beyond tenant's workloads.
+
+Goals and scope may vary as the project evolves.
 
 ## Tenant Control Plane
 What makes Kamaji special is that the Control Plane of a _“tenant cluster”_ is just one or more regular pods running in a namespace of the _“admin cluster”_ instead of a dedicated set of Virtual Machines. This solution makes running control planes at scale cheaper and easier to deploy and operate. The Tenant Control Plane components are packaged in the same way they are running in bare metal or virtual nodes. We leverage the `kubeadm` code to set up the control plane components as they were running on their own server. The unchanged images of upstream `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager` are used.
@@ -9,7 +17,7 @@ High Availability and rolling updates of the Tenant Control Plane pods are provi
 
 Kamaji offers a [Custom Resource Definition](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) to provide a declarative approach of managing a Tenant Control Plane. This *CRD* is called `TenantControlPlane`, or `tcp` in short.
 
-All the _“tenant clusters”_ built with Kamaji are fully compliant CNCF Kubernetes clusters and are compatible with the standard Kubernetes toolchains everybody knows and loves. See [CNCF compliance](./compliance.md).
+All the _“tenant clusters”_ built with Kamaji are fully compliant CNCF Kubernetes clusters and are compatible with the standard Kubernetes toolchains everybody knows and loves. See [CNCF compliance](reference/conformance.md).
 
 ## Tenant worker nodes
 And what about the tenant worker nodes? They are just _"worker nodes"_, i.e. regular virtual or bare metal machines, connecting to the APIs server of the Tenant Control Plane. Kamaji's goal is to manage the lifecycle of hundreds of these _“tenant clusters”_, not only one, so how to add another tenant cluster to Kamaji? As you could expect, you have just deploys a new Tenant Control Plane in one of the _“admin cluster”_ namespace, and then joins the tenant worker nodes to it.
@@ -27,11 +35,13 @@ Kamaji offers the option of using a more capable datastore than `etcd` to save t
 ### Pooling
 By default, Kamaji is expecting to persist all the _“tenant clusters”_ data in a unique datastore that could be backed by different drivers. However, you can pick a different datastore for a specific set of _“tenant clusters”_ that could have different resources assigned or a different tiering. Pooling of multiple datastore is an option you can leverage for a very large set of _“tenant clusters”_ so you can distribute the load properly. As future improvements, we have a _datastore scheduler_ feature in roadmap so that Kamaji itself can assign automatically a _“tenant cluster”_ to the best datastore in the pool.
 
-## Requirements of design
-These are requirements of design behind Kamaji:
+## Konnectivity
 
-- Communication between the _“admin cluster”_ and a _“tenant cluster”_ is unidirectional. The _“admin cluster”_ manages a _“tenant cluster”_, but a _“tenant cluster”_ has no awareness of the _“admin cluster”_.
-- Communication between different _“tenant clusters”_ is not allowed.
-- The worker nodes of tenant should not run anything beyond tenant's workloads.
+In addition to the standard control plane containers, Kamaji creates an instance of [konnectivity-server](https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/) running as sidecar container in the `tcp` pod and exposed on port `8132` of the `tcp` service.
+
+This is required when the tenant worker nodes are not reachable from the `tcp` pods. The Konnectivity service consists of two parts: the Konnectivity server in the tenant control plane pod and the Konnectivity agents running on the tenant worker nodes.
+
+After worker nodes joined the tenant control plane, the Konnectivity agents initiate connections to the Konnectivity server and maintain the network connections. After enabling the Konnectivity service, all control plane to worker nodes traffic goes through these connections.
+
+> In Kamaji, Konnectivity is enabled by default and can be disabled when not required.
 
-Goals and scope may vary as the project evolves.

docs/content/contribute/governance.md

@@ -0,0 +1,22 @@
+# Governance
+
+This document lays out the guidelines under which the Kamaji project will be governed.
+The goal is to make sure that the roles and responsibilities are well defined and clarify how decisions are made.
+
+## Roles
+
+In the context of Kamaji project, we consider the following roles:
+
+* __Users__: everyone using Kamaji, typically willing to provide feedback by proposing features and/or filing issues.
+
+* __Contributors__: everyone contributing code, documentation, examples, tests, and participating in feature proposals as well as design discussions.
+
+* __Maintainers__: are responsible for engaging with and assisting contributors to iterate on the contributions until it reaches acceptable quality. Maintainers can decide whether the contributions can be accepted into the project or rejected.
+
+## Release Management
+
+The release process will be governed by Maintainers.
+
+## Roadmap Planning
+
+Maintainers will share roadmap and release versions as milestones in GitHub [project's page](https://github.com/clastix/kamaji). 

docs/content/contribute/guidelines.md

@@ -0,0 +1,83 @@
+# General
+
+Thank you for your interest in contributing to Kamaji. Whether it's a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community.
+
+Please read through this document before submitting any issues or pull requests to ensure we have all the necessary information to effectively respond to your bug report or contribution.
+
+## Pull Requests
+
+Contributions via pull requests are much appreciated. Before sending us a pull request, please ensure that:
+
+1. You are working against the latest source on the *master* branch.
+1. You check existing open, and recently merged, pull requests to make sure someone else hasn't addressed the problem already.
+1. You open an issue to discuss any significant work: we would hate for your time to be wasted.
+
+To send us a pull request, please:
+
+1. Fork the repository.
+1. Modify the source; please focus on the specific change you are contributing. If you also reformat all the code, it
+   will be hard for us to focus on your change.
+1. Ensure local tests pass.
+1. Commit to your fork using clear commit messages.
+1. Send us a pull request, answering any default questions in the pull request interface.
+1. Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation.
+
+GitHub provides additional document on [forking a repository](https://help.github.com/articles/fork-a-repo/) and
+[creating a pull request](https://help.github.com/articles/creating-a-pull-request/).
+
+Make sure to keep Pull Requests small and functional to make them easier to review, understand, and look up in commit history. This repository uses "Squash and Commit" to keep our history clean and make it easier to revert changes based on PR. Adding the appropriate documentation, unit tests and e2e tests as part of a feature is the responsibility of the
+feature owner, whether it is done in the same Pull Request or not. All the Pull Requests must refer to an already open issue: this is the first phase to contribute also for informing maintainers about the issue.
+
+## Commits
+
+Commit's first line should not exceed 50 columns.
+
+A commit description is welcomed to explain more the changes: just ensure to put a blank line and an arbitrary number of maximum 72 characters long lines, at most one blank line between them.
+
+Please, split changes into several and documented small commits: this will help us to perform a better review. Commits must follow the Conventional Commits Specification, a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with Semantic Versioning, by describing the features, fixes, and breaking changes made in commit messages. See [Conventional Commits Specification](https://www.conventionalcommits.org) to learn about Conventional Commits.
+
+> In case of errors or need of changes to previous commits, fix them squashing to make changes atomic.
+
+## Code convention
+
+Kamaji is written in Golang. The changes must follow the Pull Request method where a _GitHub Action_ will
+check the `golangci-lint`, so ensure your changes respect the coding standard.
+
+### golint
+
+You can easily check them issuing the _Make_ recipe `golint`.
+
+```
+# make golint
+golangci-lint run -c .golangci.yml
+```
+
+> Enabled linters and related options are defined in the [.golanci.yml file](https://github.com/clastix/Kamaji/blob/master/.golangci.yml)
+
+## Finding contributions to work on
+Looking at the existing issues is a great way to find something to contribute on. As our projects, by default, use the
+default GitHub issue labels (enhancement/bug/duplicate/help wanted/invalid/question/wontfix), looking at any 'help wanted'
+and 'good first issue' issues are a great place to start.
+
+## Design Docs
+
+A contributor proposes a design with a PR on the repository to allow for revisions and discussions. If a design needs to be discussed before formulating a document for it, make use of GitHub Discussions to involve the community on the discussion.
+
+## GitHub Issues
+
+GitHub Issues are used to file bugs, work items, and feature requests with actionable items/issues.
+
+When filing an issue, please check existing open, or recently closed, issues to make sure somebody else hasn't already reported the issue. Please try to include as much information as you can. Details like these are incredibly useful:
+
+* A reproducible test case or series of steps
+* The version of the code being used
+* Any modifications you've made relevant to the bug
+* Anything unusual about your environment or deployment
+
+## Miscellanea
+
+Please, add a new single line at end of any file as the current coding style.
+
+## Licensing
+
+See the [LICENSE](https://github.com/clastix/Kamaji/blob/master/LICENSE) file for our project's licensing. We can ask you to confirm the licensing of your contribution.

docs/content/contribute/index.md

@@ -0,0 +1,2 @@
+# Guidelines
+Guidelines for community contributions.

docs/content/getting-started.md

@@ -1,19 +1,18 @@
-# Setup a minimal Kamaji for development
+# Getting started
 
-This document explains how to deploy a minimal Kamaji setup on [KinD](https://kind.sigs.k8s.io/) for development scopes. Please refer to the [Kamaji documentation](../concepts.md) for understanding all the terms used in this guide, as for example: `admin cluster`, `tenant cluster`, and `tenant control plane`.
+This document explains how to deploy a minimal Kamaji setup on [KinD](https://kind.sigs.k8s.io/) for development scopes. Please refer to the [Kamaji documentation](concepts.md) for understanding all the terms used in this guide, as for example: `admin cluster`, `tenant cluster`, and `tenant control plane`.
 
 ## Pre-requisites
 
 We assume you have installed on your workstation:
 
-- [Docker](https://docs.docker.com/engine/install/)
+- [Docker](https://docker.com)
 - [KinD](https://kind.sigs.k8s.io/)
-- [kubectl@v1.25.0](https://kubernetes.io/docs/tasks/tools/)
-- [kubeadm@v1.25.0](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)
+- [kubectl@v1.25.0](https://kubernetes.io/docs/tasks/tools/#kubectl)
+- [kubeadm@v1.25.0](https://kubernetes.io/docs/tasks/tools/#kubeadm)
 - [jq](https://stedolan.github.io/jq/)
 - [openssl](https://www.openssl.org/)
-- [cfssl](https://github.com/cloudflare/cfssl)
-- [cfssljson](https://github.com/cloudflare/cfssl)
+- [cfssl/cfssljson](https://github.com/cloudflare/cfssl)
 
 
 > Starting from Kamaji v0.0.2, `kubectl` and `kubeadm` need to meet at least minimum version to `v1.25.0`:
@@ -65,7 +64,7 @@ Deploy a MySQL/MariaDB backend into the Kamaji node:
 $ make -C deploy/kine/mysql mariadb
 ```
 
-Adjust the [Kamaji install manifest](../config/install.yaml) according to the example of a [MySQL DataStore](../config/samples/kamaji_v1alpha1_datastore_mysql.yaml) and make sure Kamaji uses the proper datastore name:
+Adjust the Kamaji install manifest `config/install.yaml` according to the example of a MySQL DataStore `config/samples/kamaji_v1alpha1_datastore_mysql.yaml` and make sure Kamaji uses the proper datastore name:
 
 ```
 --datastore={.metadata.name}
@@ -81,7 +80,7 @@ Deploy a PostgreSQL backend into the Kamaji node:
 $ make -C deploy/kine/postgresql postgresql
 ```
 
-Adjust the [Kamaji install manifest](../config/install.yaml) according to the example of a [PostgreSQL DataStore](../config/samples/kamaji_v1alpha1_datastore_postgresql.yaml) and make sure Kamaji uses the proper datastore name:
+Adjust the Kamaji install manifest `config/install.yaml` according to the example of a PostgreSQL DataStore `config/samples/kamaji_v1alpha1_datastore_postgresql.yaml` and make sure Kamaji uses the proper datastore name:
 
 ```
 --datastore={.metadata.name}

docs/content/guides/index.md

@@ -0,0 +1,3 @@
+# How to Guides
+
+This section of the Kamaji documentation contains pages that show how to do a specific thing, typically by giving a sequence of steps.

docs/content/guides/kamaji-azure-deployment-guide.md

@@ -97,9 +97,9 @@ kubectl cluster-info
 ```
 
 ## Install datastore
-The Kamaji controller needs to access a multi-tenant datastore in order to save data of the tenants' clusters. The [Helm Chart](../charts/kamaji/) provides the installation of an unamanaged `etcd`. However, a managed `etcd` is highly recommended in production.
+The Kamaji controller needs to access a multi-tenant datastore in order to save data of the tenants' clusters. The Kamaji Helm Chart provides the installation of an unamanaged `etcd`. However, a managed `etcd` is highly recommended in production.
 
-The [kamaji-etcd](https://github.com/clastix/kamaji-etcd) project provides a viable option to setup a manged multi-tenant `etcd` as 3 replicas StatefulSet with data persistence:
+As alternative, the [kamaji-etcd](https://github.com/clastix/kamaji-etcd) project provides a viable option to setup a manged multi-tenant `etcd` as 3 replicas StatefulSet with data persistence:
 
 ```bash
 helm repo add clastix https://clastix.github.io/charts
@@ -110,9 +110,7 @@ helm install etcd clastix/kamaji-etcd -n kamaji-system --create-namespace
 Optionally, Kamaji offers the possibility of using a different storage system for the tenants' clusters, as MySQL or PostgreSQL compatible database, thanks to the native [kine](https://github.com/k3s-io/kine) integration.
 
 ## Install Kamaji Controller
-There are multiple ways to deploy Kamaji, including a [single YAML file](../config/install.yaml) and the [Helm Chart](../charts/kamaji).
-
-Install with `helm` using an unmanaged `etcd` as datastore:
+Install Kamaji with `helm` using an unmanaged `etcd` as datastore:
 
 ```bash
 helm repo add clastix https://clastix.github.io/charts
@@ -273,7 +271,7 @@ NAME         ENDPOINTS           AGE
 kubernetes   10.240.0.100:6443   57m
 ```
 
-### Preparing Worker Nodes to join
+### Prepare worker nodes to join
 Currently Kamaji does not provide any helper for creation of tenant worker nodes. You should get a set of machines from your infrastructure provider, turn them into worker nodes, and then join to the tenant control plane with the `kubeadm`. In the future, we'll provide integration with Cluster APIs and other tools, as for example, Terrform.
 
 Create an Azure VM Stateful Set to host worker nodes
@@ -307,12 +305,11 @@ az vmss scale \
    --new-capacity 3
 ```
 
-### Join the tenant virtual machines to the tenant control plane
+### Join worker nodes
 The current approach for joining nodes is to use `kubeadm` and therefore, we will create a bootstrap token to perform the action. In order to facilitate the step, we will store the entire command of joining in a variable:
 
 ```bash
 TENANT_ADDR=$(kubectl -n ${TENANT_NAMESPACE} get svc ${TENANT_NAME} -o json | jq -r ."spec.loadBalancerIP")
-
 JOIN_CMD=$(echo "sudo kubeadm join ${TENANT_ADDR}:6443 ")$(kubeadm --kubeconfig=${TENANT_NAMESPACE}-${TENANT_NAME}.kubeconfig token create --print-join-command |cut -d" " -f4-)
 ```
 

docs/content/guides/kamaji-deployment-guide.md

@@ -1,5 +1,5 @@
 # Setup Kamaji on a generic infrastructure
-This guide will lead you through the process of creating a working Kamaji setup on a generic infrastructure, both virtual or bare metal.
+This guide will lead you through the process of creating a working Kamaji setup on a generic infrastructure, either virtual or bare metal.
 
 The material here is relatively dense. We strongly encourage you to dedicate time to walk through these instructions, with a mind to learning. We do NOT provide any "one-click" deployment here. However, once you've understood the components involved it is encouraged that you build suitable, auditable GitOps deployment processes around your final infrastructure.
 
@@ -36,7 +36,7 @@ We assume you have installed on your workstation:
 ## Access Admin cluster
 In Kamaji, an Admin Cluster is a regular Kubernetes cluster which hosts zero to many Tenant Cluster Control Planes. The admin cluster acts as management cluster for all the Tenant clusters and implements Monitoring, Logging, and Governance of all the Kamaji setup, including all Tenant clusters. 
 
-Throughout the following instructions, shell variables are used to indicate values that you should adjust to your environment, as of [`kamaji.env`](../deploy/kamaji.env):
+Throughout the following instructions, shell variables are used to indicate values that you should adjust to your environment:
 
 ```bash
 source kamaji.env
@@ -52,9 +52,9 @@ Any regular and conformant Kubernetes v1.22+ cluster can be turned into a Kamaji
 Make sure you have a `kubeconfig` file with admin permissions on the cluster you want to turn into Kamaji Admin Cluster.
 
 ## Install datastore
-The Kamaji controller needs to access a multi-tenant datastore in order to save data of the tenants' clusters. The [Helm Chart](../charts/kamaji/) provides the installation of an unamanaged `etcd`. However, a managed `etcd` is highly recommended in production.
+The Kamaji controller needs to access a multi-tenant datastore in order to save data of the tenants' clusters. The Kamaji Helm Chart provides the installation of an unamanaged `etcd`. However, a managed `etcd` is highly recommended in production.
 
-The [kamaji-etcd](https://github.com/clastix/kamaji-etcd) project provides a viable option to setup a manged multi-tenant `etcd` as 3 replicas StatefulSet with data persistence:
+As alternative, the [kamaji-etcd](https://github.com/clastix/kamaji-etcd) project provides a viable option to setup a manged multi-tenant `etcd` as 3 replicas StatefulSet with data persistence:
 
 ```bash
 helm repo add clastix https://clastix.github.io/charts
@@ -65,9 +65,7 @@ helm install etcd clastix/kamaji-etcd -n kamaji-system --create-namespace
 Optionally, Kamaji offers the possibility of using a different storage system for the tenants' clusters, as MySQL or PostgreSQL compatible database, thanks to the native [kine](https://github.com/k3s-io/kine) integration.
 
 ## Install Kamaji Controller
-There are multiple ways to deploy Kamaji, including a [single YAML file](../config/install.yaml) and the [Helm Chart](../charts/kamaji).
-
-Install with `helm` using an unmanaged `etcd` as datastore:
+Install Kamaji with `helm` using an unmanaged `etcd` as datastore:
 
 ```bash
 helm repo add clastix https://clastix.github.io/charts
@@ -234,11 +232,11 @@ kubernetes   192.168.32.240:6443   18m
 
 And make sure it is `${TENANT_ADDR}:${TENANT_PORT}`.
 
-### Preparing Worker Nodes to join
+### Prepare worker nodes to join
 
-Currently Kamaji does not provide any helper for creation of tenant worker nodes. You should get a set of machines from your infrastructure provider, turn them into worker nodes, and then join to the tenant control plane with the `kubeadm`. In the future, we'll provide integration with Cluster APIs and other tools, as for example, Terrform.
+Currently Kamaji does not provide any helper for creation of tenant worker nodes. You should get a set of machines from your infrastructure provider, turn them into worker nodes, and then join to the tenant control plane with the `kubeadm`. In the future, we'll provide integration with Cluster APIs and other tools, as for example, Terraform.
 
-You can use the provided helper script [`nodes-prerequisites.sh`](../deploy/nodes-prerequisites.sh), in order to install the dependencies on all the worker nodes:
+You can use the provided helper script `/deploy/nodes-prerequisites.sh`, in order to install the dependencies on all the worker nodes:
 
 - Install `containerd` as container runtime
 - Install `crictl`, the command line for working with `containerd`
@@ -253,16 +251,13 @@ HOSTS=(${WORKER0} ${WORKER1} ${WORKER2})
 ./nodes-prerequisites.sh ${TENANT_VERSION:1} ${HOSTS[@]}
 ```
 
-### Join Command
-
+### Join worker nodes
 The current approach for joining nodes is to use `kubeadm` and therefore, we will create a bootstrap token to perform the action. In order to facilitate the step, we will store the entire command of joining in a variable:
 
 ```bash
 JOIN_CMD=$(echo "sudo ")$(kubeadm --kubeconfig=${TENANT_NAMESPACE}-${TENANT_NAME}.kubeconfig token create --print-join-command)
 ```
 
-### Adding Worker Nodes
-
 A bash loop will be used to join all the available nodes.
 
 ```bash

docs/content/guides/mysql-datastore.md

@@ -2,4 +2,4 @@
 
 Kamaji offers the possibility of having a different storage system than `ETCD` thanks to [kine](https://github.com/k3s-io/kine) integration. One of the implementations is [MySQL](https://www.mysql.com/).
 
-> A detailed guide for production setup will be released soon. Please refer to [Getting Started Guide](./getting-started-with-kamaji.md) for a demo setup with KinD.
+> A detailed guide for production setup will be released soon. Please refer to [Getting Started Guide](../getting-started.md) for a demo setup with KinD.

docs/content/guides/postgresql-datastore.md

@@ -3,4 +3,4 @@
 Kamaji offers the possibility of having a different storage system than `etcd` thanks to [kine](https://github.com/k3s-io/kine) integration.
 One of the implementations is [PostgreSQL](https://www.postgresql.org/).
 
-> A detailed guide for production setup will be released soon. Please refer to [Getting Started Guide](./getting-started-with-kamaji.md) for a demo setup with KinD.
+> A detailed guide for production setup will be released soon. Please refer to [Getting Started Guide](../getting-started.md) for a demo setup with KinD.

docs/content/guides/upgrade.md

@@ -0,0 +1,13 @@
+# Tenant Cluster Upgrade
+The process of upgrading a _“tenant cluster”_ consists in two steps:
+
+1. Upgrade the Tenant Control Plane
+2. Upgrade of Tenant Worker Nodes
+
+## Upgrade of Tenant Control Plane
+You should patch the `TenantControlPlane.spec.kubernetes.version` custom resource with a new compatible value according to the [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/).
+
+> Note: during the upgrade, a new ReplicaSet of Tenant Control Plane pod will be created, so make sure you have at least two pods to avoid service disruption.
+
+## Upgrade of Tenant Worker Nodes
+As currently Kamaji is not providing any helpers for Tenant Worker Nodes, you should make sure to upgrade them manually, for example, with the help of `kubeadm`. We have in roadmap, the Cluster APIs support so that you can upgrade _“tenant clusters”_ in a fully declarative way.

docs/content/index.md

@@ -0,0 +1,51 @@
+# Kamaji
+**Kamaji** deploys and operates Kubernetes at scale with a fraction of the operational burden. 
+
+## How it works
+Kamaji turns any Kubernetes cluster into an _“admin cluster”_ to orchestrate other Kubernetes clusters called _“tenant clusters”_. What makes Kamaji special is that Control Planes of _“tenant clusters”_ are just regular pods running in the _“admin cluster”_ instead of dedicated Virtual Machines. This solution makes running control planes at scale cheaper and easier to deploy and operate. View [Concepts](concepts.md) for a deeper understanding of principles behind Kamaji's design.
+
+![Architecture](images/kamaji-light.png#gh-light-mode-only)
+![Architecture](images/kamaji-dark.png#gh-dark-mode-only)
+
+All the tenant clusters built with Kamaji are fully compliant [CNCF Certified Kubernetes](https://www.cncf.io/certification/software-conformance/) and are compatible with the standard toolchains everybody knows and loves.
+
+<p align="center" style="padding: 6px 6px">
+  <img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" width="200" />
+</p>
+
+## Features
+
+- **Self Service Kubernetes:** leave users the freedom to self-provision their Kubernetes clusters according to the assigned boundaries.
+- **Multi-cluster Management:** centrally manage multiple tenant clusters from a single admin cluster. Happy SREs. 
+- **Cheaper Control Planes:** place multiple tenant control planes on a single node, instead of having three nodes for a single control plane.
+- **Stronger Multi-Tenancy:** leave tenants to access the control plane with admin permissions while keeping the tenant isolated at the infrastructure level.
+- **Kubernetes Inception:** use Kubernetes to manage Kubernetes by re-using all the Kubernetes goodies you already know and love.
+- **Full APIs compliant:** tenant clusters are fully CNCF compliant built with upstream Kubernetes binaries. A user does not see differences between a Kamaji provisioned cluster and a dedicated cluster.
+
+## Getting started
+
+Please refer to the [Getting Started guide](getting-started.md) to deploy a minimal setup of Kamaji on [KinD](https://kind.sigs.k8s.io/).
+
+## Open Source
+Kamaji is Open Source with Apache 2 license and any contribution is welcome. Open an issue or suggest an enhancement on the GitHub [project's page](https://github.com/clastix/kamaji). Join the [Kubernetes Slack Workspace](https://slack.k8s.io/) and the [`#kamaji`](https://kubernetes.slack.com/archives/C03GLTTMWNN) channel to meet end-users and contributors.
+
+## FAQs
+Q. What does Kamaji mean?
+
+A. Kamaji is named as the character _Kamaji_ from the Japanese movie [_Spirited Away_](https://en.wikipedia.org/wiki/Spirited_Away).
+
+Q. Is Kamaji another Kubernetes distribution?
+
+A. No, Kamaji is a Kubernetes Operator you can install on top of any Kubernetes cluster to provide hundreds or thousands of managed Kubernetes clusters as a service. We tested Kamaji on vanilla Kubernetes 1.22+, KinD, and Azure AKS. We expect it to work smoothly on other Kubernetes distributions. The tenant clusters made with Kamaji are conformant CNCF Kubernetes clusters as we leverage [`kubeadm`](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/).
+
+Q. Is it safe to run Kubernetes control plane components in a pod instead of dedicated virtual machines?
+
+A. Yes, the tenant control plane components are packaged in the same way they are running in bare metal or virtual nodes. We leverage the `kubeadm` code to set up the control plane components as they were running on their own server. The unchanged images of upstream `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager` are used.
+
+Q. You already provide a Kubernetes multi-tenancy solution with [Capsule](https://capsule.clastix.io). Why does Kamaji matter?
+
+A. A multi-tenancy solution, like Capsule shares the Kubernetes control plane among all tenants keeping tenant namespaces isolated by policies. While the solution is the right choice by balancing between features and ease of usage, there are cases where a tenant user requires access to the control plane, for example, when a tenant requires to manage CRDs on his own. With Kamaji, you can provide cluster admin permissions to the tenant.
+
+Q. Well you convinced me, how to get a try?
+
+A. It is possible to get started with Kamaji on a laptop with [KinD](getting-started.md) installed.

docs/content/reference/configuration.md

@@ -39,45 +39,3 @@ Available environment variables are:
 | `KAMAJI_HEALTH_PROBE_BIND_ADDRESS`   | The address the probe endpoint binds to. (default ":8081")                                                             |
 | `KAMAJI_LEADER_ELECTION`             | Enable leader election for controller manager. Enabling this will ensure there is only one active controller manager.  |
 | `KAMAJI_TMP_DIRECTORY`               | Directory which will be used to work with temporary files. (default "/tmp/kamaji")                                     |
-
-
-## Build and deploy
-Clone the repo on your workstation.
-
-```bash
-## Install dependencies
-$ go mod tidy
-
-## Generate code
-$ make generate
-
-## Generate Manifests
-$ make manifests
-
-## Install Manifests
-$ make install
-
-## Build Docker Image
-$ IMG=<image name and tag> make docker-build
-
-## Push Docker Image
-$ IMG=<image name and tag> make docker-push
-
-## Deploy Kamaji
-$ IMG=<image name and tag> make deploy
-
-## YAML Installation File
-$ make yaml-installation-file
-
-```
-
-It will generate a yaml installation file at `config/install.yaml`. It should be customized accordingly.
-
-## Custom Resource Definitions
-
-**Kamaji** offers a set of [CRD](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) to provide a declarative approach of managing tenant control planes:
-
-- `TenantControlPlane`, or `tcp` in short
-- `DataStore`
-
-For details, see [apireference](apireference.md).

docs/content/reference/conformance.md

@@ -1,4 +1,4 @@
-# CNCF Conformance
+# Conformance
 For organizations using Kubernetes, conformance enables interoperability, consistency, and confirmability between Kubernetes installations. The Cloud Computing Native Foundation - CNCF - provides the [Certified Kubernetes Conformance Program](https://www.cncf.io/certification/software-conformance/).
 
 The standard set of conformance tests is currently those defined by the `[Conformance]` tag in the

docs/content/reference/index.md

@@ -0,0 +1,2 @@
+# Reference
+This section of the Kamaji documentation contains references to the project's specifications.

docs/content/reference/versioning.md

@@ -1,4 +1,5 @@
-# Versioning and support
+# Versioning
+
 In Kamaji, there are different components that might require independent versioning and support level:
 
 |Kamaji|Admin Cluster|Tenant Cluster (min)|Tenant Cluster (max)|Konnectivity|Tenant etcd |
@@ -6,4 +7,4 @@ In Kamaji, there are different components that might require independent version
 |0.0.1 |1.22.0+      |1.21.0              |1.23.5              |0.0.31      |3.5.4       |
 |0.0.2 |1.22.0+      |1.21.0              |1.25.0              |0.0.32      |3.5.4       | 
 
-Other combinations might work but they have not been yet tested.
+Other combinations might work but they have not been yet tested.

docs/content/use-cases.md

@@ -0,0 +1,11 @@
+# Use Cases
+Kamaji project has been initially started as a solution for actual and common problems such as minimizing the Total Cost of Ownership while running Kubernetes at large scale. However, it can open a wider range of use cases.
+
+Here are a few:
+
+- **Managed Kubernetes:** enable companies to provide Cloud Native Infrastructure with ease by introducing a strong separation of concerns between management and workloads. Centralize clusters management, monitoring, and observability by leaving developers to focus on applications, increase productivity and reduce operational costs.
+- **Kubernetes as a Service:** provide Kubernetes clusters in a self-service fashion by running management and workloads on different infrastructures with the option of Bring Your Own Device, BYOD.
+- **Control Plane as a Service:** provide multiple Kubernetes control planes running on top of a single Kubernetes cluster. Tenants who use namespaces based isolation often still need access to cluster wide resources like Cluster Roles, Admission Webhooks, or Custom Resource Definitions.
+- **Edge Computing:** distribute Kubernetes workloads across edge computing locations without having to manage multiple clusters across various providers. Centralize management of hundreds of control planes while leaving workloads to run isolated on their own dedicated infrastructure.
+- **Cluster Simulation:** check new Kubernetes API or experimental flag or a new tool without impacting production operations. Kamaji will let you simulate such things in a safe and controlled environment.
+- **Workloads Testing:** check the behaviour of your workloads on different and multiple versions of Kubernetes with ease by deploying multiple Control Planes in a single cluster.

docs/konnectivity.md

@@ -1,9 +0,0 @@
-# Set up Konnectivity service
-
-In addition to the standard control plane containers, Kamaji creates an instance of [konnectivity-server](https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/) running as sidecar container in the `tcp` pod and exposed on port `8132` of the `tcp` service.
-
-This is required when the tenant worker nodes are not reachable from the `tcp` pods. The Konnectivity service consists of two parts: the Konnectivity server in the tenant control plane pod and the Konnectivity agents running on the tenant worker nodes.
-
-After worker nodes joined the tenant control plane, the Konnectivity agents initiate connections to the Konnectivity server and maintain the network connections. After enabling the Konnectivity service, all control plane to worker nodes traffic goes through these connections.
-
-> In Kamaji, Konnectivity is enabled by default and can be disabled when not required.

docs/mkdocs.yml

@@ -0,0 +1,61 @@
+site_name: Kamaji
+repo_name: clastix/kamaji
+repo_url: https://github.com/clastix/kamaji
+site_url: https://kamaji.clastix.io/
+docs_dir: content
+site_dir: site
+
+theme:
+  name: material
+  features:
+    - navigation.tabs
+    - navigation.tabs.sticky
+    - navigation.instant
+    - navigation.sections
+  include_sidebar: true
+  palette:
+
+    # Palette toggle for automatic mode
+    - media: "(prefers-color-scheme)"
+      toggle:
+        icon: material/brightness-auto
+        name: Switch to light mode
+
+    # Palette toggle for light mode
+    - media: "(prefers-color-scheme: light)"
+      scheme: default 
+      toggle:
+        icon: material/lightbulb
+        name: Switch to dark mode
+
+    # Palette toggle for dark mode
+    - media: "(prefers-color-scheme: dark)"
+      scheme: slate
+      toggle:
+        icon: material/lightbulb-outline
+        name: Switch to system preference
+
+# Generate navigation bar
+nav:
+- 'Kamaji': index.md
+- 'Getting started': getting-started.md
+- 'Concepts': concepts.md
+- 'Guides':
+  - guides/index.md
+  - guides/kamaji-deployment-guide.md
+  - guides/kamaji-azure-deployment-guide.md
+  - guides/postgresql-datastore.md
+  - guides/mysql-datastore.md
+  - guides/upgrade.md
+- 'Use Cases': use-cases.md
+- 'Reference':
+  - reference/index.md
+  - reference/configuration.md
+  - reference/conformance.md
+  - reference/versioning.md
+  - reference/api.md
+- 'Contribute':
+  - contribute/index.md
+  - contribute/guidelines.md
+  - contribute/governance.md
+

docs/requirements.txt

@@ -0,0 +1,2 @@
+mkdocs>=1.3.0
+mkdocs-material>=8.2.8

docs/runtime.txt

@@ -0,0 +1 @@
+3.8

docs/upgrade.md

@@ -1 +0,0 @@
-# Tenant Cluster Upgrade