English | 中文

In addition to supporting deploy on VM and BM, KubeSphere also supports installing on cloud-hosted and on-premises Kubernetes clusters,

• Kubernetes Version: 1.13.x, 1.14.x, 1.15.x;
• Helm Version: >= 2.10.0 (excluding 2.16.0), see Install and Configure Helm in Kubernetes;
• CPU > 1 Core, Memory > 2 G;
• An existing Storage Class in your Kubernetes clusters.

1. Make sure your Kubernetes version is greater than 1.13.0, run kubectl version in your cluster node. The output looks like the following:

root@kubernetes:~# kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.1", GitCommit:"4485c6f18cee9a5d3c3b4e523bd27972b1b53892", GitTreeState:"clean", BuildDate:"2019-07-18T09:09:21Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.1", GitCommit:"4485c6f18cee9a5d3c3b4e523bd27972b1b53892", GitTreeState:"clean", BuildDate:"2019-07-18T09:09:21Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

Note: Pay attention to Server Version line, if GitVersion is greater than v1.13.0, it's good. Otherwise you need to upgrade your kubernetes first. You can refer to Upgrading kubeadm clusters from v1.12 to v1.13.

2. Make sure you've already installed Helm, and it's version is greater than 2.10.0. You can run helm version to check, the output looks like below:

root@kubernetes:~# helm version
Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}

Note: If you get helm: command not found, it means Helm is not installed yet. You can refer to Install Helm to find out how to install Helm, and don't forget to run helm init first after installation. If you use an older version (<2.10.0), you need to Upgrade Helm and Tiller.

3. Check if the available resources meet the minimal prerequisite in your cluster.

root@kubernetes:~# free -g
              total        used        free      shared  buff/cache   available
Mem:              16          4          10           0           3           2
Swap:             0           0           0

4. Check if there is a default Storage Class in your cluster, an existing Storage Class is the prerequisite for KubeSphere installation.

root@kubernetes:~$ kubectl get sc
NAME                      PROVISIONER               AGE
glusterfs (default)               kubernetes.io/glusterfs   3d4h

If your Kubernetes cluster environment meets all above 4 requirements, then you can install it.

Attention: Following section is only used for minimal installation by default, KubeSphere has decoupled some core components in v2.1.0, for more pluggable components installation, see Enable Pluggable Components and Configuration Table below.

$ kubectl apply -f https://raw.githubusercontent.com/kubesphere/ks-installer/master/kubesphere-minimal.yaml

Then inspect the logs of installation.

$ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l app=ks-install -o jsonpath='{.items[0].metadata.name}') -f

When all Pods of KubeSphere are running, it means the installation is successsful. Then you can use http://IP:30880 to access the dashboard with default account admin/P@88w0rd.

Attention: You have to make sure there is enough and available CPU and memory in your cluster, see the Configuration Table below.

1. Create the Secret of CA certificate of your Kubernetes cluster. The CA certificate is the prerequisite of enabling DevOps and OpenPitrix components installation.

Note: To create this secret according to the certificate paths of ca.crt and ca.key of your cluster. Generally, the certificate path of cluster which is created by kubeadm is /etc/kubernetes/pki.

$ kubectl create ns kubesphere-system

$ kubectl -n kubesphere-system create secret generic kubesphere-ca  \
--from-file=ca.crt=/etc/kubernetes/pki/ca.crt  \
--from-file=ca.key=/etc/kubernetes/pki/ca.key

2. Create the Secret of certificate for etcd in your Kubernetes cluster. This step is only needed when you prefer enabling etcd monitoring.

Note: Create the secret according to the actual ETCD certificate path of your cluster; If the ETCD has not been configured certificate, an empty secret need to be created

• If the ETCD has been configured with certificates, refer to the following step （The following command is an example which is only used for the cluster created by kubeadm）:

$ kubectl -n kubesphere-monitoring-system create secret generic kube-etcd-client-certs  \
--from-file=etcd-client-ca.crt=/etc/kubernetes/pki/etcd/ca.crt  \
--from-file=etcd-client.crt=/etc/kubernetes/pki/etcd/healthcheck-client.crt  \
--from-file=etcd-client.key=/etc/kubernetes/pki/etcd/healthcheck-client.key

• If the ETCD has not been configured with certificates.

$ kubectl -n kubesphere-monitoring-system create secret generic kube-etcd-client-certs

3. Then we can edit the ConfigMap to enable any pluggable components that you need.

$ kubectl edit cm ks-installer -n kubesphere-system

Attention: After complete ConfigMap edit, you can exit directly then it'll automatically trigger the installation.

4. Inspect the logs of installation.

$ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l app=ks-install -o jsonpath='{.items[0].metadata.name}') -f

When all Pods of KubeSphere are running, it means the installation is successsful. Then you can use http://IP:30880 to access the dashboard with default account admin/P@88w0rd.

Pay attention to the resource request in the first column, you have to make sure there is enough and available CPU and memory in your cluster, especially for enable Logging, DevOps, Istio, Harbor and GitLab installation.

If you need any help with KubeSphere, please join us at Slack Channel.