一、Kuboard 是什么

Kuboard 是一款类似于Kubernetes Dashboard 的轻量级的图形化管理工具。旨在帮助用户更轻松地管理 Kubernetes 集群。 Kuboard 提供了一个直观、功能丰富的用户界面，使用户可以方便地查看和操作 Kubernetes 集群中的各种资源。

• 直观的用户界面：直观、易于使用的Web界面，让用户无需深入了解 Kubernetes 的命令行操作，即可轻松管理集群中的资源。

• 资源管理和操作：对集群中的资源进行管理和操作，包括创建、删除、扩缩容等操作，从而方便管理Kubernetes集群。

• 资源和日志监控： 实时查看集群中资源的使用情况，包括 CPU、内存、网络等，还提供了日志查看功能，方便用户查看日志信息。

• 相关事件的查看： Kuboard 还提供了事件查看的强大功能，用户可以查看集群中发生的事件，帮助快速定位和解决问题。

  ​

二、Kuboard 版本及区别

• Kuboard 目前主要版本有 V2.0、V3.0、V4.0 三个版本 ，Kuboard V4.0 处于 alpha 测试阶段。

• 区别点：

  • Kuboard V3 与 Kuboard V2 不同，V3 版本不再部署在 Kubernetes 集群之中，而是作为一个独立的容器运行。
  • Kuboard V3 将大部分内容从 kube-system 迁移到 kuboard 名称空间，这也是两个版本能共存在的主要原因。
  • 从 Kuboard V2 迁移到 V3 版本的，请在 V2 的界面中卸载掉 Kuboard 套件，并在 V3 中重新安装 Kuboard 套件。

三、Kuboard V3版本主要特点

• Kuboard V3.2.0 开始，支持 kubeconfig 和 kuboard-agent 两种方式导入 Kubernetes 集群到 Kuboard 平台。
• Kuboard V3 支持多 Kubernetes 集群管理( 免费版支持3个) ，支持 amd64 (x86) 架构和 arm68 (armv8) 架构的 CPU 。
• 由于安装及运行模式的不同，用户可以同时使用 Kuboard V2 和 Kuboard V3 两种版本，相互完全不影响。

四、Kuboard V3版本安装及要求

4.1、Kuboard V3 安装方式

基于如下原因，建议您以 docker run 的方式运行 Kuboard

• 结构更清晰，便于对多个集群进行管理
• 登录Kuboard 时使用不同的认证方式
• 出现问题的时候进行排查更为简单明了

4.2、Kuboard V3 安装要求

• 用于安装 Kuboard v3 的机器已经安装了 docker，版本不低于 19.03
• 已经有自己的 Kubernetes 集群，并且版本不低于 Kubernetes v1.13

五、Kuboard V2 的安装相关

5.1、Kuboard 的安装

1、安装 Kuboard 的版本
[root@master ~]# wget https://kuboard.cn/install-script/kuboard.yaml
[root@master ~]# kubectl apply -f kuboard.yaml
deployment.apps/kuboard created
service/kuboard created
serviceaccount/kuboard-user created
clusterrolebinding.rbac.authorization.k8s.io/kuboard-user created
serviceaccount/kuboard-viewer created
clusterrolebinding.rbac.authorization.k8s.io/kuboard-viewer created

[root@master ~]# netstat -lntp | grep 32567
tcp        0      0 0.0.0.0:32567           0.0.0.0:*               LISTEN      2383/kube-proxy 


2、安装 metrics-server
[root@master ~]# wget https://addons.kuboard.cn/metrics-server/0.3.7/metrics-server.yaml
[root@master ~]# kubectl apply -f metrics-server.yaml

###  作用和 Kubernetes Dashboard 部署时的 dashboard-metrics-scraper 一样，是收集和提供Kubernetes集群的性能指标数据，以便于监控和管理


3、验证安装情况
[root@sg-50 ~]# kubectl get pod -A | grep kuboard
 kube-system   kuboard-74c645f5df-r2p5q                    1/1     Running   1          187d

[root@sg-50 ~]# kubectl get svc -A | grep kuboard
 kube-system            kuboard           NodePort    10.96.3.163     <none>        80:32567/TCP               187d

### Kuboard V2 版本，Service 服务采用的是 NodePort 的方式，使用的是 32567 端口进行访问


4、 浏览器登录验证 
#   使用任何一个节点的 IP:32567 在浏览器访问测试，看登录界面是否正常打开

5.2、登录 Token 查询

### Kuboard 的登录方法，默认和 Kubernetes Dashboard 相同，使用 Token 进行登录的。

1、 查看下安装 Kuboard 时的输出

[root@master ~]# kubectl apply -f kuboard.yaml
deployment.apps/kuboard created
service/kuboard created
serviceaccount/kuboard-user created
clusterrolebinding.rbac.authorization.k8s.io/kuboard-user created
serviceaccount/kuboard-viewer created
clusterrolebinding.rbac.authorization.k8s.io/kuboard-viewer created

# 发现生成了两个新的 SA 账号 --- kuboard-user 、  kuboard-viewer

2、账号说明
kuboard-user   管理员账号，拥有着管理员的权限
kuboard-viewer 集群只读账号，只有日志查看权限


3、获取 Token 的方式
[root@master ~]# echo $(kubectl -n kube-system get secret $(kubectl -n kube-system get secret | grep kuboard-viewer | awk '{print $1}') -o go-template='{{.data.token}}' | base64 -d)
eyJhbGciOiJSUzI1NiIsImtpZCI6InRuemFDc29HTlBJNkdaakFMVXFFbDZCQ3lGTzVYSzg0NVp3Mzd5d3JaMkkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2
                              ...     输出太长，省略部分输出    ...
k3-2kiQap4jd9U5acw8NRsKXtfocxIEv7IDsYN1PO0uaWdpXABdtlSCm8pcmETe0pku-50ZTfs0DQjIQVHNywIR310t5u1hqfQKH0L6ShOA


4、直接查询的方式
[root@sg-50 ~]# kubectl get secret -n kube-system | grep kuboard-viewer
kuboard-viewer-token-98fdj                       kubernetes.io/service-account-token   3      187d
[root@sg-50 ~]# kubectl describe secret -n kube-system kuboard-viewer-token-98fdj
Name:         kuboard-viewer-token-98fdj
Namespace:    kube-system
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: kuboard-viewer
              kubernetes.io/service-account.uid: 5628fe90-467e-405e-9a1a-9a5dca67a58b

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1066 bytes
namespace:  11 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6InRuemFDc29HTlBJNkdaakFMVXFFbDZCQ3lGTzVYSzg0NVp3Mzd5d3JaMkkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2
                              ...      输出太长，省略部分输出    ...
k3-2kiQap4jd9U5acw8NRsKXtfocxIEv7IDsYN1PO0uaWdpXABdtlSCm8pcmETe0pku-50ZTfs0DQjIQVHNywIR310t5u1hqfQKH0L6ShOA


# 两个命令结合起来使用

[root@sg-50 ~]# kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep kuboard-user | awk '{print $1}')
Name:         kuboard-user-token-9nmcs
Namespace:    kube-system
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: kuboard-user
              kubernetes.io/service-account.uid: 1cbac34b-afd5-4f90-9e14-0a42099fec98

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1066 bytes
namespace:  11 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6InRuemFDc29HTlBJNkdaakFMVXFFbDZCQ3lGTzVYSzg0NVp3Mzd5d3JaMkkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2
                 ...      输出太长，省略部分输出     ...
d3n1BC37je9cSi7OCD6FKwuEdefei35lres5ekir56h1ECLz_kBsvPFcb9E9ltuZpXZRafcT1FdMEiAXz_K5jji_x9THV92SvBGd6Z2WHXsqL1JV3qzOS_bYnk9ZjkV8UH9cSWSdbiK3ZvcqGvLOK4g

5.3、Kuboard 的登录

5.3.1、相关集群权限的区别

账号 kuboard-viewer 没有节点资源、没有存储资源的一切权限

5.3.2、具体资源权限的区别

账号 kuboard-viewer 只有对 POD 进行日志查看的权限

上面显示具体 "预览/编辑 YAML" 按钮，其实进去之后，测试更改下 POD 副本数量，发现依然是没有权限

六、Kuboard 控制台相关说明

登录进来，到了控制台，能看到的主要有三个区域

• 最上面的部分，是关于命名空间资源区域，操作量占90%以上
• 下面左边部分，是有关集群资源及使用情况区域，操作量占5%以上
• 下面的右边部分，是集群的存储资源信息区域，基本上不进行操作

七、Kuboard 相关区域使用说明

7.1、集群资源及使用量区域

此区域的信息，涉及到以下的三个部分

• 集群部分硬件资源及使用量的信息
• 集群各节点上信息及上面运行的资源对象信息
• 集群使有资源对象资源使用量的多少先后情况

7.1.1、节点相关的信息

点击任何一个集群节点，可以看到该节点的相关信息：

• 标签查看、编辑或更改、节点的调度相关的调整、污点编辑
• 该节点CPU和内存的使用情况、请求及限制、Pod数量
• 该节点上运行的使用容器组、这些容器组使用的镜像情况
• 该节点的操作系统类型、内核、容器引擎、Kubectl、Proxy 版本信息

7.1.2、集群运行Pod情况

集群所有Pod资源情况，包括以下：

• 全集群运行的Pod资源使用情况(可根据名称空间查看)
• 全集群Pod的资源占用情况排列(分CPU、内存两个维度)

7.2、集群存储资源信息区域

提示 : 涉及到存储资源相关展示时，截图为公司正在使用的一个集群

这里使用任何存储卷必须先在集群里面创建

查询存储卷的相关信息

7.3、集群命名空间资源区域

在主扩展台界面的上面部分，涉及如下操作：

• 进行新名称空间的创建、现有名称空间的删除(空名称空间才能够直接删除)
• 展示所有的名称空间(多种维度展示)、及进入到相关的名称空间去进行相关操作

分析说明： 主要分为四个可操作区域

• 名称空间的切换区域(左上的位置)
• 名称空间的资源对象区域(右下的位置)
• 名称空间内所有资源类型区域(左中的位置)
• 名称空间整个资源对象区域(中上的位置)

7.3.1、名称空间的切换

7.3.2、名称空间所有资源对象

有边区别是该空间运行的所有服务，主要有五种类型，分别对于左边 "控制器" 里面的五种

如下图所示： 七个微服务，有 4 个是 Deployments 类型的资源对象、有 2 个是 StatefulSets 类型的资源对象、有 1个 是 DaemonSets 类型的资源对象

具体资源对象服务相关信息的查看，点击具体的服务

名称空间为 Default , 名字为 web-nginx 的微服务，我们能够得到的相关信息如下：

• 左边的名称空间资源类型里面，"Deployments" 高亮，显示这个微服务的资源类型是 Deployment
• 上面的操作区域里面，可以对这个 Deloyment 进行相关的 “编辑” 、 “伸缩” 、 “重启” 、“删除” 、“编辑YAML” 、“日志查看” 等操作
• 清晰明了的看到此 Deployment 运行的节点位置、IP地址、容器镜像信息、拉取策略、副本信息、重启策略、DNS策略相关信息
• 此 Deploymen 的创建时间、运行时长、运行状态、重启次数、相关Service 端口信息、Ingress相关、存储状态 等信息

7.3.3、名称空间所有资源类型

应用程序

• 控制器： Deployments 、 StatefulSets 、 DaemonSets 、 CronJobs 、 Jobs
• 容器组： 容器组 、 Top Pods
• 公布应用： Services 、 Ingress
• 自动伸缩： HorizontalPodAutoscaler

资源

• 配置字典： ConfigMap
• 密文： Secret

存储

资源配置

事件

7.3.4、名称空间整个资源对象

这里是涉及到整个名称空间对象的操作

• 从 YAML 创建：创建资源对象，在弹出框里面输入完整的 YAML 文件内容
• 创建工作负载：图像化的创建资源对象，只包含只要的三种类型(DP、STS、DS)
• 调整镜像版本：这里展示所有的资源对象，点击进行调整其使用的镜像版本
• 导出工作负载：导出整个名称空间下的所有资源对象(包括整个左边显示的部分)
• 导入工作负载：导入上面从别的集群导出的某个名称空间对象的 YAML 文件，迅速创建所有的资源对象

相关操作说明：

• 一般我们创建资源对象，基本是不会在这里操作，都是集群里面命令行的方式创建
• 调整相关服务的镜像版本，也是自己点击下面的区域，显示更大更清楚，操作更便利
• 导出导入工作负载，特别适合于在新集群环境里，克隆某个集群几乎完全相同的服务环境
  • 如果集群环境里面涉及的组件如中间件、数据库都是K8S运行，那么导入之后直接就能够运行(各种连接使用类DNS主机名的形式)
  • 如果集群环境里面的中间件、数据库是单独部署或者涉及到注册中心之类的，则是更改相关的IP、端口信息后也能够正常运行

八、Kuboard 的应用相关

8.1、名称空间内分层的说明

在 Kuboard 中，命名空间被以分层的方式展示，这种分层展示方式有助于更直观地展示微服务架构的结构。每个名称空间可以自定义布局，使得管理更加高效。通过这种分层展示，管理员可以更好地组织和管理不同的工作负载，提高运维效率‌。

• Kuboard 的分层功能主要用于将不同的应用和服务分类管理，以方便于用户根据业务需求进行部署和管理。
• Kuboard 分层不是必须遵循的，并不是强制要求的，用户可以根据自己的需求和管理习惯选择是否使用分层功能。

8.2、Kuboard 的简单应用

创建一个工作负载举个例子

九、Kuboard 使用方式补充

9.1、使用 Nginx 进行代理

### 没有使用 SSL 证书的话，注释掉相关使用证书的行

upstream kuboard-dev {
    server 192.168.0.50:32567 max_fails=3 fail_timeout=15s;
    server 192.168.0.55:32567 max_fails=3 fail_timeout=15s;
    server 192.168.0.59:32567 max_fails=3 fail_timeout=15s;
}

server {
    listen 80;
    listen 443 ssl;

    server_name kuboard.dev.shaxxxx.com;
    charset utf-8;
    client_max_body_size 500m;

    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    ssl_certificate /etc/letsencrypt/live/dev.shaxxxx.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dev.shaxxxx.com/privkey.pem;
    ssl_session_timeout 5m;
    keepalive_timeout 900s; 
    proxy_read_timeout 900s;
    ssl_stapling on;
    ssl_stapling_verify on;

    location / {
        proxy_pass https://kuboard-dev;
    }
}

9.2、使用 Ingress 进行代理

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    k8s.kuboard.cn/displayName: kuboard
    k8s.kuboard.cn/workload: kuboard
    nginx.com/sticky-cookie-services: serviceName=kuboard srv_id expires=1h path=/
    nginx.org/websocket-services: kuboard
  name: kuboard
  namespace: kube-system
spec:
  rules:
    - host: kuboard2.dev.shaxxxx.com
      http:
        paths:
          - backend:
              serviceName: kuboard
              servicePort: http
            path: /
                   

十、Kuboard 使用的个人小结

• 对于集群业务编排而言，Kuboard V2 、Kuboard V3 主要功能点方面没什么很大的区别，无非是操作界面的区别
• 关于Kuboard V3 版本能够多集群同时管理的功能，是一个仁者见仁智者见智的命题，一个集群部署一个 Kuboard V2 版本不是什么难题也不多影响集群资源，同样多集群同时管理不停切换也会带来误操作的风险，每个人的使用习惯问题吧
• Kuboard V2 版本的自带的 Kuboard-viewer 账号的集群操作权限，不能够完全满足日志查询的全部权限功能，有时候还需要进入到 Pod 进行例如 切换文件路径、使用管道、文本过滤 等相关的操作 （ 后续可以通过 RBAC 创建一个满足需求账号来解决）
• 无论是使用 Kuboard 的集群管理工具，还是K8S官方的 Dashboard 工具，在UI 的图形界面上的操作，大部分的时候都是微操 (停止、重启资源对象，日志信息查看、CM/SECRET 信息查询、TAG更改、EVENTS查看等)，真正的部署新服务或者存储等，都是在集群里面使用YAML文件的形式处理完成的