From 5da7058ed3a8970cd150ce0a48e2743d08afe032 Mon Sep 17 00:00:00 2001 From: bsctl Date: Wed, 10 Aug 2022 23:19:41 +0200 Subject: [PATCH] fix(docs): update guides to latest changes --- deploy/kamaji-azure.env | 1 - deploy/kamaji.env | 1 - docs/kamaji-aws-deployment-guide.md | 26 -------------------------- docs/kamaji-azure-deployment-guide.md | 5 ++--- docs/kamaji-deployment-guide.md | 8 +++++--- 5 files changed, 7 insertions(+), 34 deletions(-) delete mode 100644 docs/kamaji-aws-deployment-guide.md diff --git a/deploy/kamaji-azure.env b/deploy/kamaji-azure.env index 00a9d28..3f52cd8 100644 --- a/deploy/kamaji-azure.env +++ b/deploy/kamaji-azure.env @@ -6,7 +6,6 @@ export KAMAJI_CLUSTER=kamaji export KAMAJI_NODE_RG=MC_${KAMAJI_RG}_${KAMAJI_CLUSTER}_${KAMAJI_REGION} # kamaji parameters -export ETCD_NAMESPACE=etcd-system export KAMAJI_NAMESPACE=kamaji-system # tenant cluster parameters diff --git a/deploy/kamaji.env b/deploy/kamaji.env index ee78707..4025a2d 100644 --- a/deploy/kamaji.env +++ b/deploy/kamaji.env @@ -1,5 +1,4 @@ # kamaji parameters -export ETCD_NAMESPACE=etcd-system export KAMAJI_NAMESPACE=kamaji-system # tenant cluster parameters diff --git a/docs/kamaji-aws-deployment-guide.md b/docs/kamaji-aws-deployment-guide.md deleted file mode 100644 index 4c688ba..0000000 --- a/docs/kamaji-aws-deployment-guide.md +++ /dev/null @@ -1,26 +0,0 @@ -# Setup Kamaji on AWS -This guide will lead you through the process of creating a working Kamaji setup on on Amazon AWS. It requires: - -- one bootstrap local workstation -- an EKS Kubernetes cluster to run the Admin and Tenant Control Planes -- an additional `etcd` cluster made of 3 replicas to host the datastore for the Tenants' clusters -- an arbitrary number of AWS virtual machines to host `Tenant`s' workloads - - * [Prepare the bootstrap workspace](#prepare-the-bootstrap-workspace) - * [Access Admin cluster](#access-admin-cluster) - * [Setup multi-tenant etcd](#setup-multi-tenant-etcd) - * [Install Kamaji controller](#install-kamaji-controller) - * [Create Tenant Cluster](#create-tenant-cluster) - * [Cleanup](#cleanup) - -## Prepare the bootstrap workspace - -## Access Admin cluster - -## Setup multi-tenant etcd - -## Install Kamaji controller - -## Create Tenant Cluster - -## Cleanup \ No newline at end of file diff --git a/docs/kamaji-azure-deployment-guide.md b/docs/kamaji-azure-deployment-guide.md index 4b5ccc6..b0c8109 100644 --- a/docs/kamaji-azure-deployment-guide.md +++ b/docs/kamaji-azure-deployment-guide.md @@ -3,7 +3,6 @@ This guide will lead you through the process of creating a working Kamaji setup - one bootstrap local workstation - an AKS Kubernetes cluster to run the Admin and Tenant Control Planes -- an additional `etcd` cluster made of 3 replicas to host the datastore for the Tenants' clusters - an arbitrary number of Azure virtual machines to host `Tenant`s' workloads * [Prepare the bootstrap workspace](#prepare-the-bootstrap-workspace) @@ -80,7 +79,7 @@ There are multiple ways to deploy the Kamaji controller: - Use Kustomize with Makefile - Use the Kamaji Helm Chart -The Kamaji controller needs to access a multi-tenant `etcd` in order to provision the access for tenant `kube-apiserver`. The multi-tenant `etcd` cluster will be deployed as three replicas StatefulSet into the admin cluster. Data persistence for multi-tenant `etcd` cluster is required. the Helm [Chart](../helm/kamaji/) provides the installation of an internal `etcd`. However, an externally managed `etcd` is highly recommended. If you'd like to use an externally one, you can specify the overrides and by setting the value `etcd.deploy=false`. +The Kamaji controller needs to access a multi-tenant `etcd` in order to provision the access for tenant `kube-apiserver`. The multi-tenant `etcd` cluster will be deployed as three replicas StatefulSet into the admin cluster. Data persistence for multi-tenant `etcd` cluster is required. The Helm [Chart](../helm/kamaji/) provides the installation of an internal `etcd`. However, an externally managed `etcd` is highly recommended. If you'd like to use an external one, you can specify the overrides and setting the value `etcd.deploy=false`. ### Install with Helm Chart Install with the `helm` in a dedicated namespace of the Admin cluster: @@ -107,7 +106,7 @@ You just turned your AKS cluster into a Kamaji cluster to run multiple Tenant Co ### Tenant Control Plane With Kamaji on AKS, the tenant control plane is accessible: -- from tenant work nodes through an internal loadbalancer +- from tenant worker nodes through an internal loadbalancer - from tenant admin user through an external loadbalancer responding to `https://${TENANT_NAME}.${TENANT_NAME}.${TENANT_DOMAIN}:443` Create a tenant control plane of example: diff --git a/docs/kamaji-deployment-guide.md b/docs/kamaji-deployment-guide.md index 2a56513..60dbf73 100644 --- a/docs/kamaji-deployment-guide.md +++ b/docs/kamaji-deployment-guide.md @@ -3,7 +3,6 @@ This guide will lead you through the process of creating a working Kamaji setup - one bootstrap local workstation - a Kubernetes cluster 1.22+, to run the Admin and Tenant Control Planes -- an additional `etcd` cluster made of 3 replicas to host the datastore for the Tenants' clusters - an arbitrary number of machines to host Tenants' workloads > In this guide, we assume the machines are running `Ubuntu 20.04`. @@ -54,7 +53,10 @@ There are multiple ways to deploy the Kamaji controller: - Use Kustomize with Makefile - Use the Kamaji Helm Chart -The Kamaji controller needs to access a multi-tenant `etcd` in order to provision the access for tenant `kube-apiserver`. The multi-tenant `etcd` cluster will be deployed as three replicas StatefulSet into the admin cluster. Data persistence for multi-tenant `etcd` cluster is required. the Helm [Chart](../helm/kamaji/) provides the installation of an internal `etcd`. However, an externally managed `etcd` is highly recommended. If you'd like to use an externally one, you can specify the overrides and by setting the value `etcd.deploy=false`. +### Multi-tenant datastore +The Kamaji controller needs to access a multi-tenant datastore in order to save data of the tenants' clusters. Install a multi-tenant `etcd` in the admin cluster as three replicas StatefulSet with data persistence. The Helm [Chart](../helm/kamaji/) provides the installation of an internal `etcd`. However, an externally managed `etcd` is highly recommended. If you'd like to use an external one, you can specify the overrides by setting the value `etcd.deploy=false`. + +Optionally, Kamaji offers the possibility of using a different storage system than `etcd` for the tenants' clusters, like MySQL compatible database, thanks to the [kine](https://github.com/k3s-io/kine) integration [here](../deploy/mysql/README.md). ### Install with Helm Chart Install with the `helm` in a dedicated namespace of the Admin cluster: @@ -200,7 +202,7 @@ The `LoadBalancer` service type is used to expose the Tenant Control Plane. Howe ### Konnectivity 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 network and the Konnectivity agents in the tenant worker nodes network. The Konnectivity agents initiate connections to the Konnectivity server and maintain the network connections. After enabling the Konnectivity service, all control plane to nodes traffic goes through these connections. +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.