Kubesphere提供两个部署工具，KubeKey和ks-installer。其中，ks-installer部署Kubesphere，KubeKey安装Kubernetes和ks-installer。

代码框架

controller：shell-operator的两个脚本
deploy：部署ks-installer的yaml文件
docs：文档
env：变量
playbooks：各个playbook

• alerting.yaml：部署报警模块
• auditing：部署审计模块
• common：部署通用模块，包括es、fluent-bit、minio、openldap、mysql等等
• devops：部署devops模块
• events：部署事件模块
• harbor：部署镜像仓库模块
• ks-config：
• ks-core：部署ks核心组件，包括ks-apiserver、ks-controller-manager、ks-console等
• logging：部署日志模块
• metrics-server：部署metrics-server
• monitor：部署监控模块
• multicluster：部署多集群模块
• openpitrix：部署openpitrix
• preinstall：预安装，包括检查k8s版本、storageclass、helm版本转换等
• result-info：统计部署结果，显示welcome信息
• servicemesh：部署微服务模块
• telemetry：获取一些集群信息，如k8s版本、ks版本、machineID等等，再向ClusterConfiguration写入- - clusterID（当前镜像有问题，生成clusterID失败，因为没有uuidgen命令）
  roles：各个role目录

scripts：ks-installer相关脚本

shell-operator

ks-installer本质是一个shell-operator，监控着ClusterConfiguration资源，当ClusterConfiguration资源变化时，则会触发ks-installer的部署流程。
不像fluentbit-operator这些，shell-operator并不是一种具体的operator实现，而是提供了一种框架。按照这种框架，可以编写出具体的operator。
shell-operator 与其他 Kubernetes 工作负载类似，部署在 Pod中。在 Pod 中有一个/hooks 的一个子目录，其中存储了可执行文件，它们可以用 Bash、Python、Ruby等编写的，我们称这些可执行文件为hooks。在这些可执行文件中，声明感兴趣的Kubernetes事件，订阅这些事件，并执行这些钩子。
shell-operator 如何知道何时执行钩子呢？事实上每个钩子都有两个阶段。在启动过程中，shell-operator 使用-config参数运行每个钩子。一旦配置阶段结束，钩子将以“正常”方式执行：响应附加给它们的事件。

shell-operator支持三种钩子响应类型：
1、OnStartup：启动后即运行；
2、schedule：crontab格式的定时任务；
3、kubernetes：监控Kubernetes资源，根据定义的事件类型来响应；

shell-operator也提供了prometheus metrics，支持自定义指标，默认端口是9115。

bash-5.1$ pwd
/hooks/kubesphere
bash-5.1$ ls
installRunner.py  schedule.sh

ks-installer的pod中，/hooks/kubesphere中包含两个文件。installRunner.py用于部署ks-installer，schedule.sh定期执行telemetry的playbook，检查状态、注册clusterid等。
installRunner.py：

ks_hook = '''
{
   "onKubernetesEvent": [{
      "name": "Monitor clusterconfiguration",
      "kind": "ClusterConfiguration",
      "event": [ "add", "update" ],
      "objectName": "ks-installer",
      "namespaceSelector": {
         "matchNames": ["kubesphere-system"]
      },
      "jqFilter": ".spec",
      "allowFailure": false
   }]
}
'''
def main():
    if not os.path.exists(privateDataDir):
        os.makedirs(privateDataDir)

    if len(sys.argv) > 1 and sys.argv[1] == "--config":
        print(ks_hook)
    else:
        config.load_incluster_config()
        api = client.CustomObjectsApi()
        updateConfigMap("unready")
        generate_new_cluster_configuration(api)
        generateConfig(api)
        # execute preInstall tasks
        preInstallTasks()
        resultState = getResultInfo()
        resultInfo(resultState, api)

schedule.sh：

if [[ $1 == "--config" ]] ; then
  cat <<EOF
{
  "configVersion":"v1",
  "schedule": [
    {
      "allowFailure": true,
      "name": "every month",
      "crontab": "0 0 1 * *"
    }
  ]
}
EOF
else
  ansible-playbook /kubesphere/playbooks/telemetry.yaml -e @/kubesphere/config/ks-config.json
  if [[ $? -eq 0 ]]; then
    #statements
    str="successsful!"
    echo -e "$str"
  else
    exit
  fi
fi

这两个脚本的入口处，都是通过-config参数，配置要监控的事件，另外一个分支，就是钩子需要处理的动作。
schedule.sh是一个定时执行的任务，每个月执行telemetry.yaml。
installRunner.py就是主要的部署脚本。

installRunner.py

def main():
    if not os.path.exists(privateDataDir):
        os.makedirs(privateDataDir)

    if len(sys.argv) > 1 and sys.argv[1] == "--config":
        print(ks_hook)
    else:
        # 加载k8s配置
        config.load_incluster_config()
        # k8s客户端
        api = client.CustomObjectsApi()
        # 生成新的ClusterConfiguration配置
        generate_new_cluster_configuration(api)
        # 持久化文件/kubesphere/config/ks-config.json和/kubesphere/config/ks-status.json
        # /kubesphere/config/ks-config.json即ClusterConfiguration的配置部分（json化）
        # /kubesphere/config/ks-status.json即CLusterConfiguration的状态部分
        generateConfig(api)
        # execute preInstall tasks
        # 执行preInstall、metrics-server、common、ks-core
        preInstallTasks()
        # 实际安装，异步安装各组件
        resultState = getResultInfo()
        resultInfo(resultState, api)

部署

ks-installer容器启动（重启）后，或者感知到ClusterConfiguration变化后，都会触发ks-installer的部署流程。
每次触发部署流程，preInstall、metrics-server、common、ks-core等playbook都会再次执行。
而可插拔组件是否会执行部署，取决于ClusterConfiguration中，对应组件的status状态，当该模块不存在，或者status不为enalbed时，都会重新触发该模块的再次部署。如果要调试某个组件的重新部署，可以在status部分，删除对应组件的部分。

# kubectl get cc -n kubesphere-system   ks-installer -oyaml
status:
  clusterId: ""
  core:
    enabledTime: 2022-03-29T16:29:34CST
    status: enabled
  es:
    enabledTime: 2022-03-29T16:28:39CST
    status: enabled
  fluentbit:
    enabledTime: 2022-03-29T16:28:57CST
    status: enabled
  logging:
    enabledTime: 2022-03-29T16:31:06CST
    status: enabled
  metricsServer:
    enabledTime: 2022-03-29T16:26:37CST
    status: enabled
  minio:
    enabledTime: 2022-03-29T16:28:30CST
    status: enabled
  monitoring:
    enabledTime: 2022-03-29T16:33:33CST
    status: enabled
  servicemesh:
    enabledTime: 2022-03-29T16:31:28CST
    status: enabled

参考文章：
https://github.com/flant/shell-operator
https://cloud.tencent.com/developer/article/1701733
https://blog.fleeto.us/post/shell-operator/