概述
KubeSphere,GitHub,一款开源项目,在目前主流容器调度平台k8s之上构建的企业级分布式多租户容器管理平台,提供简单易用的操作界面以及向导式操作方式,在降低用户使用容器调度平台学习成本的同时,极大降低开发、测试、运维的日常工作的复杂度。
KubeSphere旨在降低k8s使用门槛,提供全栈的云原生管理能力。基于k8s构建,通过向导式界面和模块化设计,集成DevOps、多集群管理、微服务治理、监控告警等企业级功能,目标是成为“云原生分布式操作系统”。
其核心理念是屏蔽底层复杂性,让开发者与运维人员无需深入掌握k8s的细节,即可高效管理容器化应用。无论是私有云、公有云还是混合云环境,KubeSphere均可无缝部署,并支持与主流云原生工具(如Istio、Prometheus)集成。
功能:
- 多集群与多租户管理:统一纳管跨云、跨地域的k8s集群,支持基于角色的细粒度权限控制;
- DevOps流水线:内置CI/CD工具链,无缝对接Git、Jenkins等,实现自动化构建与部署;
- 可观测性:集成监控、日志、告警、审计功能,支持Prometheus、Fluent Operator等工具;
- 微服务治理:基于Service Mesh技术实现服务流量管理、熔断和灰度发布;
- 边缘计算支持:通过EdgeWize模块管理边缘节点,赋能智能制造、物联网等场景。
LuBan架构:插件化革命
2024 年发布的KubeSphere v4标志着其技术架构的里程碑式升级。基于LuBan可插拔架构,实现了从“容器管理平台”向“云原生操作系统”的跨越:
- 动态扩展:支持第三方界面、API和功能模块以插件形式热插拔,例如存储管理组件可快速接入不同厂商的解决方案;
- 灵活定制:用户可根据业务需求选择功能模块,避免冗余资源占用;
- 生态开放:通过扩展市场(Extension Marketplace)提供40余款官方及社区开发的插件,覆盖网络、存储、AI加速等场景。
安装
既有k8s集群安装:helm upgrade --install -n kubesphere-system --create-namespace ks-core https://charts.kubesphere.io/main/ks-core-x.x.x.tgz --debug --wait
云供应商安装:
# Amazon
https://aws.amazon.com/quickstart/architecture/qingcloud-kubesphere/
# Azure
https://market.azure.cn/marketplace/apps/qingcloud.kubesphere
# DigitalOcean
https://marketplace.digitalocean.com/apps/kubesphere
# QingCloud
https://www.qingcloud.com/products/kubesphereqke
使用
即Web的操作
集群管理
日常操作都是在这里。
集群类型:
- 主集群:只有一个,无法删除,只能编辑;
- 成员集群:可以有多个,可以编辑、删除。
添加集群
标签列表如下,即所谓的环境,也就是说,企业可以只部署一套KubeSphere,通过下面将提到的RBAC来管理不同环境,不同提供商的K8s集群。
提供商列表如下:
支持主流的国内外云服务提供商。
连接模式
- 直接连接:KubeSphere多集群控制平面通过提供的kubeconfig来直接连接导入集群,要求当前集群能够通过kubeconfig中的server地址直接访问待导入集群。适用于:
- 当前集群和待导入集群在同一内网网络中;
- 当前集群和待导入集群已通过VPN或隧道等其它技术连通所在网络;
- kubeconfig的server地址可以通过公网访问
- 代理连接:KubeSphere控制平面通过代理方式连接待导入集群,控制平面启动一个公开的代理服务,待导入集群创建相应的客户端组件连接代理服务,与控制平面之间建立一个反向代理。此种方式不需要待导入集群和控制平面在同一网络,也不要求待导入集群暴露集群的apiserver地址,但会有一定的网络性能损耗。适用于:
- 当前集群和待导入集群不在同一网络中;
- 当前集群和待导入集群无法通过VPN或隧道等其它技术连通所在网络;
- 对集群间网络性能损耗能容忍。
点击页面右上角的【编辑YAML】
支持通过yaml文件的方式来添加集群:
apiVersion: cluster.kubesphere.io/v1alpha1
kind: Cluster
spec:
provider: Huawei Cloud CCE
connection:
type: direct # 直接连接,代理连接是:proxy
kubeconfig: ''
joinFederation: true
metadata:
name: test
移除集群
滑动式删除,也是让我开了眼,一般这种都是输入Delete,或深入集群名称来删除。
集群列表
集群详情
点击某个集群,最核心的日常操作在这里面。
【概览】标签页如下:
概览页的信息量:
- 基本信息:提供商、版本号、企业空间可见性;
- Kubernetes状态:包括:每秒API请求数、API请求延迟、调度次数、调度失败次数;
- 系统组件:包括KubeSphere、k8s、监控;
- 资源用量:三件套(内存、CPU、磁盘)加上容器组;
- 工具:包括kubectl和kubeconfig;
- 节点:用于跟进k8s集群的调度策略和节点的负载情况。
除了概览,还有:
节点:集群节点分为控制平面节点和工作节点;节点污点(Taint)可以阻止某些容器组部署到该节点,与容忍度(Toleration)一起使用,可确保容器组不会被调度到不合适的节点上。打开终端,也就是SSH连接到那个节点。停止调度和删除节点的区别?
状态有3种:无法调度、运行中、告警。
系统组件:包括
- KubeSphere:有3种
- ks-apiserver:提供用于集群管理的API接口。此组件同时也用于集群内部模块通信和集群安全控制;
- ks-console:提供KubeSphere的控制台服务;
- ks-controller-manager:实现业务逻辑。例如,创建企业空间时创建对应的权限,创建服务策略时生成对应的Istio配置。
- kubernetes:有很多
- metrics-server:k8s的监控组件,用于从每个节点的kubelet采集指标信息;
- storage-crd-validate-service
- ack-node-local-dns-admission-controller
- heapster
- kube-dns
- storage-monitor-service
- kube-prom-stack-coredns
- kube-prom-stack-kube-proxy
- kube-prom-stack-kube-etcd
- kube-prom-stack-kube-controller-manager
- kube-scheduler-svc:k8s调度器,用于将容器组调度到合适的节点;
- cnfs-cache-ds-service:
- kube-controller-manager-svc:守护进程,用于内嵌随k8s一起发布的核心控制回路;
- kube-prom-stack-kube-scheduler:
- Monitoring:有prometheus-operator用于管理Prometheus实例。
- KubeSphere:有3种
项目:包括用户项目和系统项目,实际上就是命名空间。
k get ns --show-labels
命令输出如果带kubesphere.io/workspace=system-workspace
,则是系统项目
系统项目部分可以编辑(别名和描述)
用户项目可以编辑(别名和描述)、分配企业空间、删除。
应用负载:包括
- 工作负载:Workload,用于处理业务请求,可包含一个或多个容器组。日志、监控等系统功能也是由工作负载实现的。包括部署(即Deployment)、有状态副本集(即Statefulset)、守护进程集(即Daemonset)三种类型。操作包括:编辑信息、编辑YAML、重新创建、删除。
- 任务:Job,用于运行短暂的一次性任务。任务会创建一个或多个容器组,并保证指定数量的容器组成功结束。包括Job和CronJob两种类型。Job的操作包括:编辑、重新运行、删除。CronJob的操作包括:编辑信息、编辑YAML、暂停、删除。
- 容器组:Pod,k8s应用程序的基本执行单元,是您创建或部署的k8s对象模型中最小和最简单的单元。操作包括:查看yaml、删除。
- 服务:Service,提供一种抽象的方法,将运行在Pod上的应用程序公开为网络服务。操作包括:编辑信息、编辑YAML、编辑服务、编辑外部访问、删除。
- 应用路由:提供一种聚合服务的方式,您可以通过一个外部可访问的IP地址将集群的内部服务暴露给外部。操作包括:编辑信息、编辑YAML、编辑路由规则、编辑注解、删除。
配置:包括:
- 保密字典:Secret,一种包含少量敏感信息的资源对象,如密码、令牌、保密字典等,以键值对形式保存并且可以在容器组中使用。操作包括:编辑信息、编辑YAML、编辑设置、删除。
- 配置字典:ConfigMap,常用于存储工作负载所需的配置信息,许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。操作包括:编辑信息、编辑YAML、编辑设置、删除。
配置字典默认是用Base64编码,点击右侧的按钮,查看明文。
在KubeSphere里编辑ConfigMap时,需要注意填入在线或离线Base64编码后的内容,而不是原始内容
- 服务账户:Service Account,为容器组中运行的进程提供一个标识,用于访问API Server。操作包括:编辑、编辑YAML、修改角色、删除。Service Account里可使用Secret。
定制资源定义:Custom Resource Definition,CRD,是一种k8s实现自定义资源类型的扩展方式,您可以像操作内置资源对象一样操作定制资源定义对象。作用域包括:Namespaced和Cluster。
存储:包括
- 持久卷声明:持久卷声明(PVC,Persistent Volume Claims)定义存储需求,系统根据持久卷声明创建持久卷(PV,Persistent Volume)。本地卷是创建在集群本地文件系统中的卷。持久卷声明操作包括:创建、编辑信息、编辑YAML、删除。
- 存储类:StorageClass,支持动态卷供应,使管理员能够按需创建新的卷,不同的存储类为集群用户提供不同类型的卷。操作包括:创建、编辑、删除。
- 卷快照:卷在特定时间点的副本,可使用快照中的数据预配新卷,或者将卷恢复至快照捕捉到的先前状态。卷快照类定义用于创建卷快照的存储种类,操作包括:创建、编辑信息、编辑YAML、删除。卷快照内容是一种代表卷快照具体内容的资源。
- 卷快照类:
监控告警:包括集群状态、应用监控、自定义监控。
集群设置:包括基本信息、集群可见性、集群成员、集群角色、网关设置。网关的作用:对集群中的外网访问网关以及服务治理等配置进行设置和管理;包括:集群网关、项目网关。
访问控制
RBAC这一套。
【平台角色】标签页如下:
可知,系统预置3个默认角色,(页面上)不支持编辑(信息和权限)、删除:
- platform-admin:管理KubeSphere平台上的所有资源;
- platform-regular:被邀请加入企业空间之前无法访问任何资源;
- platform-self-provisioner:创建企业空间并成为所创建的企业空间的管理员;
支持【创建】角色,可编辑(信息和权限)、删除。【编辑信息】没啥好说的,【编辑权限】如下:
【用户】标签页如下:
可知,系统预置admin用户,并授予platform-admin
角色,无法编辑、禁用、删除。
支持【创建】用户,创建用户时可选择角色。
【企业空间】标签页如下:
预置system-workspace
可访问所有集群。
支持创建新的企业空间:
创建成功后如下图所示:
适合有多个K8S集群的场景。
平台设置
如上图,支持的通知渠道包括:
- 邮件
- 钉钉
- 企微
- Slack
- Webhook:支持三种认证类型:无需认证,Bearer Token,基础认证。
点击上图中的小锤子,提供如下工具箱:
问题
回退
支持不太好。
KubeSphere和Rancher
核心区别
- KubeSphere:定位是以应用为中心的容器平台,集成原生Istio等功能,提供简单易用的操作界面,更加符合开发的使用习惯;
- Rancher:核心竞争力在于其强大的多集群管理能力,提供极其简便的K8s部署及管理能力。提供集成开源监控、日志、Git CI的能力,学习成本较高,提供一站式解决方案,对运维更加友好。
对比项 | Rancher | KubeSphere |
---|---|---|
部署方式 | 需要要提前安装好docker,通过Rancher或RKE方式部署,提前走义好网络、服务、备份、版本等参数,主机角色,比较方便运维进行管理维护。 两种部署方式: 1.直接通过rancher部署集群,设置好相关参数。优点:简单方便,设置好主机角色,网络参数,服务参数即可,如果是测试环境,可直接用默认配置,部署时间大大缩短。缺点:可维护性没有RKE部署方式好; 2.使用RKE方式部署优点:配置好相关的 cluster.yml 文件,可直接部署,可维护性好,后期增加节点、修改集群参数比较方便。缺点:没有通过rancher直接部署方式直观,易操作整体优点:etcd备份与恢复机制,CA证书轮转操作都比较简单对于运维进行集群维护比较友好整体。 缺点:角色权限分配粒度不够细,开发进行应用部署较KubeSphere,操作不够简化 |
通过ansible进行部署,类似于kubeadm部署方式,只要在部署前配置好节点角色,需要安装的组件参数即可。 优点:部署简单,对于开发进行程序发布比较友好,易上手,但是感觉部署复杂度较RKE高,ansible简化相关安装流程。缺点:监控告警机制不够完善,告警方式只有邮件,日志输出很大程度只能用内置的es(资源使用比较多),只有一种 |
高可用性 | master,etcd高可用部署,设置好主机角色,直接修改配置文件或使用命令添加主机即可,Rancher服务可以内置或外置,单节点Rancher | master,etcd高可用部署,修改配置文件,设置好主机角色,需要配置api网关负载均衡,然后执行相关脚本即可 |
集群维护性 | 维护简单。etcd备份与恢复,有专门的文档,命令,CA证书到期转换有专门的命令或者在界面操作即可,集群扩容可以修改配置文件执行命令即可,或者直接在界面操作。一个Rancher可以维护多个k8s集群 | 维护相对简单,etcd备份有走时任务,集群扩容,修改配文件,执行相关脚本即可,工作节点执行addnode.sh,etcd、master节点执行install.sh,ansible方式类似于声明式,不会对原有集群服务有太大影响(可能会有服务重启),集群升级有专用脚本,但是感觉还是不太完善。一个KubeSphere只能对应1个k8s集群 |
应用部署便捷性 | 相对简单 | 简单,易上手,对开发人员很友好,界面比较直观 |
账号管理 | 权限分配比较细,但不如KubeSphere细 | 权限分配很细,直观 |
日志 | 有多种输出方式。提供简单的日志查询界面,一般都使用Kibana查询 | 可靠的只有es这一种,日志查询界面比较友好 |
监控与告警 | 支持多种告警方式:Webhook,企微,邮件等 | 支持多种告警方式:邮件 |
整体感觉 | 对于运维来说,比较友好,集群维护比较简单易上手,中文文档很完善,Rancher可维护多个k8s集群,但是项目权限分配还不够细,有些内容并不想让开发看到,但是权限设置不了 | 对于运维来说,集群维护可直接参考kubeadm部署的方式进行维护,包括集群扩容、高可用、备份与恢复,对于项目营理,账号权限分配的比较细,对于k8s了解比较少的人也能很快上手。整体界面比较直观。 |
个人总结 | 面向运维较友好 | 面向应用部署较放好 |
rancher更像容器云整合平台,是在k8s下一层做文章。KubeSphere更倾向于管理k8s集群资源的管理,以应用为中心,是在k8s之上做文章。
KubeSphere将大量云原生相关组件整合进来,相对来说更符合云原生发展的理念