博客
- Cluster API Searching Has Never Been Easier
- Clusterpedia 入选云原生全景图
- Clusterpedia v0.2.0 发布
- 使用 Helm 快速部署 Clusterpedia
- Clusterpedia 上榜| CSDN IT 技术影响力之星
- 视频讲解|Clusterpedia -- 多云环境下的资源复杂检索
- 首发|Clusterpedia 0.1.0 四大重要功能
- 升级到 Clusterpedia 0.1.0
- Clusterpedia 加持 kubectl,检索多集群资源
Cluster API Searching Has Never Been Easier
0.4.0 后,Clusterpedia 提供了更加友好的接入多云平台的方式,用户在多云平台创建或者纳管集群后,便可以直接使用 kubectl 来检索这些集群内的资源。
我们在 Clusterpedia 仓库 中维护了各个多云平台的 ClusterImportPolicy。 非常欢迎大家提交用于对接其他多云平台的 ClusterImportPolicy。
用户在安装 Clusterpedia 后,创建合适的 ClusterImportPolicy 即可,用户也可以根据自己的需求来创建新的 ClusterImportPolicy
Cluster API 的 ClusterImportPolicy 已经在 clusterpedia#288 中提交, 在 Cluster API 中创建集群后,可以直接使用 Clusterpedia 来对这些集群内的资源进行复杂检索。
$ kubectl get cluster
NAME PHASE AGE VERSION
capi-quickstart Provisioned 10m v1.24.2
capi-quickstart-2 Provisioned 118s v1.24.2
$ kubectl get kubeadmcontrolplane
NAME CLUSTER INITIALIZED API SERVER AVAILABLE REPLICAS READY UPDATED UNAVAILABLE AGE VERSION
capi-quickstart-2-ctm9k capi-quickstart-2 true 1 1 1 10m v1.24.2
capi-quickstart-2xcsz capi-quickstart true 1 1 1 19m v1.24.2
$ # pediacluster 会根据 cluster 资源自动创建,更新和删除
$ kubectl get pediacluster -o wide
NAME READY VERSION APISERVER VALIDATED SYNCHRORUNNING CLUSTERHEALTHY
default-capi-quickstart True v1.24.2 Validated Running Healthy
default-capi-quickstart-2 True v1.24.2 Validated Running Healthy
$ kubectl --cluster clusterpedia get no
CLUSTER NAME STATUS ROLES AGE VERSION
default-capi-quickstart-2 capi-quickstart-2-ctm9k-g2m87 NotReady control-plane 12m v1.24.2
default-capi-quickstart-2 capi-quickstart-2-md-0-s8hbx-7bd44554b5-kzcb6 NotReady <none> 11m v1.24.2
default-capi-quickstart capi-quickstart-2xcsz-fxrrk NotReady control-plane 21m v1.24.2
default-capi-quickstart capi-quickstart-md-0-9tw2g-b8b4f46cf-gggvq NotReady <none> 20m v1.24.2
快速部署一套 Cluster API And Clusterpedia 的示例环境
预备条件
- 安装 kubectl 到本地环境
- 安装 Kind and Docker
- 安装 clusterctl
Minimum kind supported version: v0.14.0
创键管理集群并部署 Cluster API
部署 Cluster API 也可以参考 https://cluster-api.sigs.k8s.io/user/quick-start.html
$ cat > kind-cluster-with-extramounts.yaml <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraMounts:
- hostPath: /var/run/docker.sock
containerPath: /var/run/docker.sock
EOF
$ kind create cluster --name capi-sample --config kind-cluster-with-extramounts.yaml
$ export CLUSTER_TOPOLOGY=true
$ clusterctl init --infrastructure docker
部署 Clusterpedia
$ git clone https://github.com/clusterpedia-io/clusterpedia.git && cd clusterpedia/charts
$ helm install clusterpedia . \
--namespace clusterpedia-system \
--create-namespace \
--set installCRDs=true \
# --set persistenceMatchNode={{ LOCAL_PV_NODE }}
--set persistenceMatchNode=capi-sample-control-plane
clusterpedia charts 提供了 Local PV,需要创建 LOCAL PV 绑定的节点. 如果不需要 charts 来创建 LOCAL PV,可以使用
--set persistenceMatchNode=None
. 详见
创建用于接入 Cluster API 的集群自动导入策略
$ kubectl apply -f https://raw.githubusercontent.com/Iceber/clusterpedia/add_cluster_api_clusterimportpolicy/deploy/clusterimportpolicy/cluster_api.yaml
Clusterpedia 可以接入任何的多云管理平台,接入方式可以参考 Interfacing to Multi-Cloud Platforms
生成 kubectl cluster shortcut,如果使用 client-go 或者 OpenAPI 来访问,可以省略该步骤
$ curl -sfL https://raw.githubusercontent.com/clusterpedia-io/clusterpedia/main/hack/gen-clusterconfigs.sh | sh -
$ # 使用 kubectl 检索多集群资源,当前 Cluster API 未创建集群,所以返回空
$ kubectl --cluster clusterpedia api-resources
使用 Cluster API 创建集群
使用示例环境的 Docker Provider 来创建集群时,需要添加 --flavor development
$ clusterctl generate cluster capi-quickstart --flavor development \
--kubernetes-version v1.24.2 \
--control-plane-machine-count=1 \
--worker-machine-count=1 \
> capi-quickstart.yaml
$ kubectl apply -f ./capi-quickstart.yaml
观察集群创建情况
$ kubectl get cluster
NAME PHASE AGE VERSION
capi-quickstart Provisioned 8s v1.24.2
$ kubectl get kubeadmcontrolplane -w
NAME CLUSTER INITIALIZED API SERVER AVAILABLE REPLICAS READY UPDATED UNAVAILABLE AGE VERSION
capi-quickstart-2xcsz capi-quickstart true 1 1 1 86s v1.24.2
当 kubeadmcontrolplane 的 Initialized 为 True 后,clusterpedia 会自动同步该集群内的资源,可以使用 kubectl --cluster clusterpedia get po -A
来查看资源
$ kubectl get pediacluster
NAME READY VERSION APISERVER
default-capi-quickstart True v1.24.2
$ kubectl --cluster clusterpedia get pod -A
NAMESPACE CLUSTER NAME READY STATUS RESTARTS AGE
kube-system default-capi-quickstart kube-apiserver-capi-quickstart-2xcsz-fxrrk 1/1 Running 0 2m32s
kube-system default-capi-quickstart kube-scheduler-capi-quickstart-2xcsz-fxrrk 1/1 Running 0 2m31s
kube-system default-capi-quickstart coredns-6d4b75cb6d-lrwj4 0/1 Pending 0 2m20s
kube-system default-capi-quickstart kube-proxy-p8v9m 1/1 Running 0 2m20s
kube-system default-capi-quickstart kube-controller-manager-capi-quickstart-2xcsz-fxrrk 1/1 Running 0 2m32s
kube-system default-capi-quickstart etcd-capi-quickstart-2xcsz-fxrrk 1/1 Running 0 2m32s
kube-system default-capi-quickstart kube-proxy-2ln2w 1/1 Running 0 105s
kube-system default-capi-quickstart coredns-6d4b75cb6d-2hcmz 0/1 Pending 0 2m20s
自动创建的 pediacluster 默认的同步资源在 cluster-api clusterimportpolicy 中设置,
用户也可以手动修改 pediacluster 中同步的配置, Synchronize Cluster Resources
在 Cluster API 中删除集群时,Clusterpedia 也同步删除 PeidaCluster,不会继续同步该集群
对多个集群的资源检索
使用上述步骤创建多个集群
$ kubectl get cluster
NAME PHASE AGE VERSION
capi-quickstart Provisioned 10m v1.24.2
capi-quickstart-2 Provisioned 118s v1.24.2
$ kubectl get kubeadmcontrolplane
NAME CLUSTER INITIALIZED API SERVER AVAILABLE REPLICAS READY UPDATED UNAVAILABLE AGE VERSION
capi-quickstart-2-ctm9k capi-quickstart-2 true 1 1 1 10m v1.24.2
capi-quickstart-2xcsz capi-quickstart true 1 1 1 19m v1.24.2
$ # pediacluster 会根据 cluster 资源自动创建
$ kubectl get pediacluster -o wide
NAME READY VERSION APISERVER VALIDATED SYNCHRORUNNING CLUSTERHEALTHY
default-capi-quickstart True v1.24.2 Validated Running Healthy
default-capi-quickstart-2 True v1.24.2 Validated Running Healthy
$ kubectl --cluster clusterpedia get no
CLUSTER NAME STATUS ROLES AGE VERSION
default-capi-quickstart-2 capi-quickstart-2-ctm9k-g2m87 NotReady control-plane 12m v1.24.2
default-capi-quickstart-2 capi-quickstart-2-md-0-s8hbx-7bd44554b5-kzcb6 NotReady <none> 11m v1.24.2
default-capi-quickstart capi-quickstart-2xcsz-fxrrk NotReady control-plane 21m v1.24.2
default-capi-quickstart capi-quickstart-md-0-9tw2g-b8b4f46cf-gggvq NotReady <none> 20m v1.24.2
clusterpedia 提供了两种资源检索方式
$ kubectl --cluster clusterpedia get cm -A
NAMESPACE CLUSTER NAME DATA AGE
kube-system default-capi-quickstart extension-apiserver-authentication 6 19m
kube-system default-capi-quickstart kubeadm-config 1 19m
kube-public default-capi-quickstart cluster-info 2 19m
kube-system default-capi-quickstart kube-proxy 2 19m
kube-node-lease default-capi-quickstart kube-root-ca.crt 1 19m
kube-system default-capi-quickstart-2 extension-apiserver-authentication 6 10m
kube-system default-capi-quickstart kubelet-config 1 19m
kube-system default-capi-quickstart coredns 1 19m
kube-system default-capi-quickstart kube-root-ca.crt 1 19m
kube-public default-capi-quickstart kube-root-ca.crt 1 19m
kube-system default-capi-quickstart-2 coredns 1 10m
default default-capi-quickstart kube-root-ca.crt 1 19m
kube-system default-capi-quickstart-2 kube-proxy 2 10m
kube-system default-capi-quickstart-2 kubeadm-config 1 10m
kube-system default-capi-quickstart-2 kubelet-config 1 10m
kube-system default-capi-quickstart-2 kube-root-ca.crt 1 10m
kube-node-lease default-capi-quickstart-2 kube-root-ca.crt 1 10m
kube-public default-capi-quickstart-2 cluster-info 3 10m
kube-public default-capi-quickstart-2 kube-root-ca.crt 1 10m
default default-capi-quickstart-2 kube-root-ca.crt 1 10m
$ # gen cluster shortcuts
$ curl -sfL https://raw.githubusercontent.com/clusterpedia-io/clusterpedia/main/hack/gen-clusterconfigs.sh | sh -
$ kubectl --cluster default-capi-quickstart get cm -n kube-system
$ kubectl get collectionresources
NAME RESOURCES
any *
workloads apps.deployments,apps.daemonsets,apps.statefulsets
kuberesources .*,admission.k8s.io.*,admissionregistration.k8s.io.*,apiextensions.k8s.io.*,apps.*,authentication.k8s.io.*,authorization.k8s.io.*,autoscaling.*,batch.*,certificates.k8s.io.*,coordination.k8s.io.*,discovery.k8s.io.*,events.k8s.io.*,extensions.*,flowcontrol.apiserver.k8s.io.*,imagepolicy.k8s.io.*,internal.apiserver.k8s.io.*,networking.k8s.io.*,node.k8s.io.*,policy.*,rbac.authorization.k8s.io.*,scheduling.k8s.io.*,storage.k8s.io.*
$ kubectl get collectionresources workloads
检索条件
$ kubectl --cluster clusterpedia get cm -A -l \
"search.clusterpedia.io/clusters in (default-capi-quickstart,default-capi-quickstart-2),\
search.clusterpedia.io/namespaces in (kube-system,default)"
NAMESPACE CLUSTER NAME DATA AGE
kube-system default-capi-quickstart extension-apiserver-authentication 6 23m
kube-system default-capi-quickstart kubeadm-config 1 23m
kube-system default-capi-quickstart kube-proxy 2 23m
kube-system default-capi-quickstart-2 extension-apiserver-authentication 6 14m
kube-system default-capi-quickstart kubelet-config 1 23m
kube-system default-capi-quickstart coredns 1 23m
kube-system default-capi-quickstart kube-root-ca.crt 1 23m
kube-system default-capi-quickstart-2 coredns 1 14m
default default-capi-quickstart kube-root-ca.crt 1 23m
kube-system default-capi-quickstart-2 kube-proxy 2 14m
kube-system default-capi-quickstart-2 kubeadm-config 1 14m
kube-system default-capi-quickstart-2 kubelet-config 1 14m
kube-system default-capi-quickstart-2 kube-root-ca.crt 1 14m
default default-capi-quickstart-2 kube-root-ca.crt 1 14m
Clusterpedia 入选云原生全景图
在 CNCF 最新发布的云原生全景图 (Cloud Native Landscape) 中,Clusterpedia入选Orchestration & Management (编排与管理) 层的 Scheduling & Orchestration (调度与编排) 象限,成为 CNCF 推荐的云原生多集群复杂检索工具。
CNCF 全称 Cloud Native Computing Foundation (云原生计算基金会),隶属于 Linux 基金会,成立于 2015 年 12 月,是非营利性组织,致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术,普及云原生应用。
云原生全景图由 CNCF 从 2016 年 12 月开始维护,汇总了社区成熟和使用范围较广、具有最佳实践的产品和方案,并加以分类,为企业构建云原生体系提供参考,在云生态研发、运维领域具有广泛影响力。
Clusterpedia v0.2.0 发布
使用 kube config 来接入集群
v0.1.0 时,用户需要分别填写被接入集群的 apiserver 地址,以及访问集群时的认证信息
apiVersion: cluster.clusterpedia.io/v1alpha2
kind: PediaCluster
metadata:
name: cluster-example
spec:
apiserver: "https://10.30.43.43:6443"
caData:
tokenData:
certData:
keyData:
syncResources: []
在 v0.2.0 中 PediaCluster
增加了 spec.kubeconfig
字段,用户可以直接使用 kube config 来接入集群。
首先 base64 集群的 kube config:
$ base64 ./kubeconfig.yaml
然后填充到 PediaCluster 的 spec.kubeconfig
字段中
apiVersion: cluster.clusterpedia.io/v1alpha2
kind: PediaCluster
metadata:
name: cluster-example
spec:
kubeconfig: **base64 kubeconfig**
syncResources: []
在使用 kube config 时,不需要填写 spec.apiserver
以及其他认证字段。
需要注意,使用 kubectl get pediacluster
查看接入的集群列表时,APISERVER 不会显示集群地址
$ kubectl get pediacluster
NAME APISERVER VERSION STATUS
cluster-example v1.22.2 Healthy
如果需要显示,那么需要额外手动设置 spec.kubeconfig
,未来会添加 Mutating Admission Webhook 来解析 kubeconfig 并自动填充 spec.apiserver
字段。
新增的检索功能
通过资源的创建时间来过滤资源
作用 | Search Label Key | URL Query |
---|---|---|
Since | search.clusterpedia.io/since | since |
Before | search.clusterpedia.io/before | before |
创建时间的区间采用左闭右开的规则,since <= creation time < before。
时间格式支持 4 种:
Unix 时间戳格式
为了方便使用会根据时间戳的长度来区分单位为 s 还是 ms。 10 位时间戳单位为秒,13 位时间戳单位为毫秒。RFC3339
2006-01-02T15:04:05Z or 2006-01-02T15:04:05+08:00UTC Date
2006-01-02UTC Datetime
2006-01-02 15:04:05
由于 Kube Label Selector 的限制,Search Label 只支持使用 Unix 时间戳和 UTC Data 的格式 URL Query 可以使用四种格式
首先查看一下当前都有哪些资源
$ kubectl --cluster clusterpedia get pods
CLUSTER NAME READY STATUS RESTARTS AGE
cluster-example quickstart-ingress-nginx-admission-create--1-kxlnn 0/1 Completed 0 171d
cluster-example fake-pod-698dfbbd5b-wvtvw 1/1 Running 0 8d
cluster-example fake-pod-698dfbbd5b-74cjx 1/1 Running 0 21d
cluster-example fake-pod-698dfbbd5b-tmcw7 1/1 Running 0 8d
我们使用创建时间来过滤资源
$ kubectl --cluster clusterpedia get pods -l "search.clusterpedia.io/since=2022-03-20"
CLUSTER NAME READY STATUS RESTARTS AGE
cluster-example fake-pod-698dfbbd5b-wvtvw 1/1 Running 0 8d
cluster-example fake-pod-698dfbbd5b-tmcw7 1/1 Running 0 8d
$ kubectl --cluster clusterpedia get pods -l "search.clusterpedia.io/before=2022-03-20"
CLUSTER NAME READY STATUS RESTARTS AGE
cluster-example quickstart-ingress-nginx-admission-create--1-kxlnn 0/1 Completed 0 171d
cluster-example fake-pod-698dfbbd5b-74cjx 1/1 Running 0 21d
使用 Owner Name 检索
在 v0.1.0 时,我们可以指定祖辈或者父辈 Owner UID
来查询资源,不过 Owner UID
使用起来并不方便,毕竟还需要提前得知 Owner 资源的 UID。
在 v0.2.0 版本中,支持直接使用 Owner Name
来查询,并且 Owner 查询由实验性功能进入到正式功能,Search Label 的前缀也由 internalstorage.clusterpedia.io 升级为 search.clusterpedia.io,并且提供了 URL Query。
作用 | Search Label Key | URL Query |
---|---|---|
指定 Owner UID | search.clusterpedia.io/owner-uid | ownerUID |
指定 Owner Name | search.clusterpedia.io/owner-name | ownerName |
指定 Owner Group Resource | search.clusterpedia.io/owner-gr | ownerGR |
指定 Owner 辈分 | internalstorage.clusterpedia.io/owner-seniority | ownerSeniority |
如果用户同时指定了
Owner UID
和Owner Name
,那么Owner Name
会被忽略。
$ kubectl --cluster cluster-example get pods -l \
"search.clusterpedia.io/owner-name=fake-pod, \
search.clusterpedia.io/owner-seniority=1"
CLUSTER NAME READY STATUS RESTARTS AGE
cluster-example fake-pod-698dfbbd5b-wvtvw 1/1 Running 0 8d
cluster-example fake-pod-698dfbbd5b-74cjx 1/1 Running 0 21d
cluster-example fake-pod-698dfbbd5b-tmcw7 1/1 Running 0 8d
另外为了避免某些情况下,owner 资源存在多种类型,我们可以使用 Owner Group Resource
来限制 Owner 的类型。
$ kubectl --cluster cluster-example get pods -l \
"search.clusterpedia.io/owner-name=fake-pod,\
search.clusterpedia.io/owner-gr=deployments.apps,\
search.clusterpedia.io/owner-seniority=1"
... some output
根据资源名称的模糊搜索
模糊搜索是一个非常常用的功能,当前暂时只提供了资源名称上的模糊搜索,由于还需要更多功能上的讨论,暂时作为试验性功能
作用 | Search Label Key | URL Query |
---|---|---|
根据资源名称进行模糊搜索 | internalstorage.clusterpedia.io/fuzzy-name | - |
$ kubectl --cluster clusterpedia get deployments -l "internalstorage.clusterpedia.io/fuzzy-name=fake"
CLUSTER NAME READY UP-TO-DATE AVAILABLE AGE
cluster-example fake-pod 3/3 3 3 113d
可以使用 in
操作符来指定多个参数,这样可以过滤出名字包含所有模糊字符串的资源。
其他功能
在 v0.1.0 中,查询资源列表时,允许返回的剩余的资源数量,这样用户可以通过计算就能得知当前检索添加下的资源总量。
在 v0.2.0 中对该功能进行了强化, 当分页查询的 Offset
参数过大时,ReaminingItemCount
可以为负数,
这样可以保证通过 offset + len(list.items) + list.metadata.remainingItemCount
总是可以计算出正确的资源总量。
发布日志
What’s New
- 支持使用 Helm 部署 (#53, #125, @calvin0327, @wzshiming)
- PediaCluster 支持使用 kube config 来接入集群 (#115, @wzshiming)
APIServer
- 支持通过创建时间的区间来过滤资源 (#113, @cleverhu)
- 支持根据 Owner 的名字来检索资源,并且 Owner 查询成为 clusterpedia 的正式功能,同时支持 Search Label 和 URL Query (#91, @Iceber)
Default Storage Layer
- 支持根据资源名称的模糊搜索 (#117, @cleverhu)
- RemainingItemCount 可以为负数,在 Offset 过大时依然可以使用
offset + len(items) + remainingItemCount
来计算资源总量。(#123, @cleverhu)
Bug Fixes
Deprecation
- Owner 查询已移动到正式功能,用于 Owner 查询的试验性 Search Label ——
internalstorage.clusterpedia.io/owner-name
和internalstorage.clusterpedia.io/owner-seniority
会在下一个版本被移除 (#91, @Iceber)
使用 Helm 快速部署 Clusterpedia
当前 Clusterpedia 已经支持通过 Helm 来快速部署。
首先需要保证当前环境已经安装 helm v3。
准备阶段
拉取 Clusterpedia 仓库代码。
当前暂时还未将 chart 上传至 charts 公共仓库。
$ git clone https://github.com/clusterpedia-io/clusterpedia.git
$ cd clusterpedia/charts
由于 clusterpedia 使用 bitnami/postgresql
和 bitnami/mysql
作为存储组件子 chart,
所以需要添加 bitnami 仓库,并更新 clusterpedia chart 的依赖。
$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm dependency build
选择存储组件
Clusterpedia Chart 通过子 chart 的方式,提供了 bitnami/postgresql
和 bitnami/mysql
两款存储组件可供选择。
postgresql
为默认的存储组件,如果想要使用 MySQL,那么在后续安装命令中添加 --set postgresql.enabled=false --set mysql.enabled=true
更多关于存储组件的配置,可以参考 bitnami/postgresql 和 bitnami/mysql。
用户也可以选择不安装存储组件,而是使用外部组件,相关设置可以参考 charts/values.yaml
选择 CRD 的安装/管理方式
clusterpedia 要求环境中创建相应的 CRD 资源,可以选择手动部署 CRD YAML,也可以在 Helm 中管理。
手动管理
$ kubectl apply -f ./_crds
使用 Helm 管理
在后续安装命令中需要手动添加 --set installCRDs=true
即可。
决定是否需要创建 Local PV
Clusterpedia Chart 可以为用户创建存储组件使用 Local PV。
用户在安装时需要通过 --set persistenceMatchNode=<selected node name>
来指定 Local PV 所在节点。
如果用户不需要创建 Local PV,那么需要使用 --set persistenceMatchNode=None
显式声明。
安装 Clusterpedia
经过上述决策后,用户可以进行安装:
$ helm install clusterpedia . \
--namespace clusterpedia-system \
--create-namespace \
--set persistenceMatchNode={{ LOCAL_PV_NODE }} \
# --set installCRDs=true
卸载 Clusterpedia
在卸载 Clusterpedia 前需要手动清理所有 PediaCluster
资源。
$ kubectl get pediacluster
PediaCluster
清理完成后就可以执行卸载命令。
$ helm -n clusterpedia-system uninstall clusterpedia
如果用户使用手动创建的 CRD 资源,那么同样也需要手动清理 CRD。
$ kubectl delete -f ./_crds
注意 PVC 和 PV 并不会删除,用户需要手动删除。
如果创建了 Local PV,那么还需要进入相应节点,清理 Local PV 的遗留数据。
# 登录 Local PV 绑定的节点
$ rm -rf /var/local/clusterpedia/internalstorage/<storage type>
Clusterpedia 上榜| CSDN IT 技术影响力之星
3 月 30 日,CSDN 正式公布 IT 技术影响力之星评选结果,Clusterpedia 入选「2021 年度云原生技术产品」。
在多云时代,多集群内部资源管理和检索越来越复杂,成为多云管理的一大难题。
在单集群中,我们通常使用 kubectl 来查看资源,或者直接访问 Kubernetes 的 OpenAPI,在代码中也可以借助 client-go 来对资源进行检索。
而在多集群环境下,Clusterpedia 通过兼容 Kubernetes OpenAPI ,用户可以依然使用单集群的方式,来对多集群资源进行复杂检索,无需从每个集群中拉取数据到本地进行过滤。
视频讲解|Clusterpedia -- 多云环境下的资源复杂检索
Clusterpedia 的发起人 –「Daocloud 道客」的云原生研发工程师蔡威,为大家详细介绍 Clusterpedia 在资源检索上提供的功能,让大家可以直观的了解到使用 Clusterepdia 可以解决哪些问题。
Clusterpedia 多集群资源检索神器
随着云原生技术的发展、承载业务量的增加以及集群规模的不断扩大,单个 Kubernetes 集群已经无法满足很多企业的需求,我们在逐渐的步入多云时代,多集群内部资源管理和检索变得越发复杂和困难。
由此,社区不断出现了很多优秀的的开源项目,例如用于集群生命周期管理的 cluster api,以及多云应用管理的 karmada, clusternet 等。而 Clusterpedia 便是建立在这些云管平台之上,为用户提供多集群资源的复杂检索。
在单集群中,我们通常使用 kubectl 来查看资源,或者直接访问 Kubernetes 的 OpenAPI,在代码中也可以借助 client-go 来对资源进行检索。
而在多集群环境下,Clusterpedia 通过兼容 Kubernetes OpenAPI ,用户可以依然使用单集群的方式,来对多集群资源进行复杂检索,无需从每个集群中拉取数据到本地进行过滤。
当然 Clusterpedia 的能力并不仅仅只是检索查看,未来还会支持对资源的简单控制,就像 wiki 同样支持编辑词条一样。Clusterpedia 具有许多特性和功能:
- 支持复杂的检索条件,过滤条件,排序,分页等等
- 支持查询资源时请求附带关系资源
- 统一主集群和多集群资源检索入口
- 兼容 kubernetes OpenAPI, 可以直接使用 kubectl 进行多集群检索, 而无需第三方插件或者工具
- 兼容收集不同版本的集群资源,不受主集群版本约束,
- 资源收集高性能,低内存
- 根据集群当前的健康状态,自动启停资源收集
- 插件化存储层,用户可以根据自己需求使用其他存储组件来自定义存储层
- 高可用
下期内容
除了支持多集群的复杂检索,Clusterpedia 还有很多其他优点,例如通过聚合式 API 来统一主集群和多集群资源的访问入口,在实时同步子集群资源时的低内存占用以及弱网优化,另外还有通过插件化存储层来解耦对存储组件的依赖。
下一期将为大家介绍具体设计和实现原理,详细解读 Clusterpedia 的优点,敬请期待。
首发|Clusterpedia 0.1.0 四大重要功能
Clusterpedia 第一个版本 – Clusterpedia 0.1.0 正式发布,即日起进入版本迭代阶段。相比于初期的 0.0.8 和 0.0.9-alpha,0.1.0 添加了很多功能,并且做了一些不兼容的更新。
如果由 0.0.9-alpha 升级的话,可以参考 Upgrade to Clusterpedia 0.1.0
重要功能
我们先介绍一下在 0.1.0 中增加的四大重要的功能:
- 对 Not Ready 的集群进行资源检索时,增加了 Warning 提醒
- 增强了原生 Field Selector 的能力
- 根据父辈或者祖辈的 Owner 来进行查询
- 响应数据携带 remaining item count
资源检索时的 Warning 提醒
集群由于某些原因处于非 Ready 的状态时,资源通常也无法正常同步,在获取到该集群内的资源时,会通过 Warnning 提醒来告知用户集群异常,并且获取到的资源可能并不是实时准确的。
$ kubectl get pediacluster
NAME APISERVER VERSION STATUS
cluster-1 https://10.6.100.10:6443 v1.22.2 ClusterSynchroStop
$ kubectl --cluster cluster-1 get pods
Warning: cluster-1 is not ready and the resources obtained may be inaccurate, reason: ClusterSynchroStop
CLUSTER NAME READY STATUS RESTARTS AGE
cluster-1 fake-pod-698dfbbd5b-64fsx 1/1 Running 0 68d
cluster-1 fake-pod-698dfbbd5b-9ftzh 1/1 Running 0 39d
cluster-1 fake-pod-698dfbbd5b-rk74p 1/1 Running 0 39d
cluster-1 quickstart-ingress-nginx-admission-create--1-kxlnn 0/1 Completed 0 126d
强化 Field Selector
原生 kubernetes 对于 Field Selector 的支持非常有限,默认只支持 metadata.namespace 和 metadata.name 字段的过滤,尽管一些特定的资源会支持一些特殊的字段,但是使用起来还是比较局限,操作符只能支持 =, ==, !=。
Clusterpedia 在兼容原生 Field Selector 的基础上,不仅仅支持了更加灵活的字段过滤,还支持和 Label Selector 相同的操作符:!, =, !=, ==, in, notin。
例如我们可以像 label selector 一样,通过 annotations 过滤资源。
kubectl get deploy --field-selector="metadata.annotations['test.io'] in (value1, value2)"
根据父辈或者祖辈 Owner 进行查询
Kubernetes 资源之间通常会存在一种 Owner 关系, 例如:
apiVersion: v1
kind: Pod
metadata:
ownerReferences:
- apiVersion: apps/v1
blockOwnerDeletion: true
controller: true
kind: ReplicaSet
name: fake-pod-698dfbbd5b
uid: d5bf2bdd-47d2-4932-84fb-98bde486d244
Clusterpedia 不仅支持根据 Owner 查询,还支持对 Owner 进行辈分提升来根据祖辈或者更高辈分的 Owner 来检索资源。
例如可以通过 Deployment 获取相应的所有 pods。
当前暂时只支持通过Owner UID 来查询资源, 使用 Owner Name 来进行查询的功能尚在讨论中,可以在 issue: Support for searching resources by owner 参与讨论。 v0.2.0 中已经支持通过 Owner name 进行查询
$ DEPLOY_UID=$(kubectl --cluster cluster-1 get deploy fake-deploy -o jsonpath="{.metadata.uid}")
$ kubectl --cluster cluster-1 get pods -l \
"internalstorage.clusterpedia.io/owner-uid=$DEPLOY_UID,\
internalstorage.clusterpedia.io/owner-seniority=1"
响应数据内携带剩余资源数量
在一些 UI 场景下,往往需要获取当前检索条件下的资源总量。
Kubernetes 响应的 ListMeta 中 RemainingItemCount 字段表示剩余的资源数量。
type ListMeta struct {
...
// remainingItemCount is the number of subsequent items in the list which are not included in this
// list response. If the list request contained label or field selectors, then the number of
// remaining items is unknown and the field will be left unset and omitted during serialization.
// If the list is complete (either because it is not chunking or because this is the last chunk),
// then there are no more remaining items and this field will be left unset and omitted during
// serialization.
// Servers older than v1.15 do not set this field.
// The intended use of the remainingItemCount is *estimating* the size of a collection. Clients
// should not rely on the remainingItemCount to be set or to be exact.
// +optional
RemainingItemCount *int64 `json:"remainingItemCount,omitempty" protobuf:"bytes,4,opt,name=remainingItemCount"`
}
复用 ListMeta.RemainingItemCount,通过简单计算便可以获取当前检索条件下的资源总量: total = offset + len(list.items) + list.metadata.remainingItemCount
该功能需要搭配分页功能一起使用
$ kubectl get --raw="/apis/clusterpedia.io/v1beta1/resources/apis/apps/v1/deployments?withRemainingCount&limit=1" | jq
{
"kind": "DeploymentList",
"apiVersion": "apps/v1",
"metadata": {
"remainingItemCount": 24
},
"items": [
...
]
}
升级到 Clusterpedia 0.1.0
随着 Clusterpedia 0.1.0 版本的发布,我们可以将早期的 0.0.9-alpha 或者 0.0.8 更新到 0.1.0 了。
旧版本资源清理
由于资源检索的路径发生了修改(#73),所以需要使用 0.0.9-alpha 的 clean-clusterconfigs.sh 来清理 .kube/config 中的 Clusterpedia 集群访问配置
curl -sfL https://raw.githubusercontent.com/clusterpedia-io/clusterpedia/v0.0.9-alpha/hack/clean-clusterconfigs.sh | sh -
备份并删除 PediaCluster
资源
kubectl get pediacluster -o yaml > clusters.yaml.bak
kubectl delete pediacluster --all
所有的 PediaCluster
资源都删除后,删除 PediaCluster CRD
kubectl delete crd pediaclusters.clusters.clusterpedia.io
删除用于注册聚合式 API 的 APIServices
kubectl delete apiservices v1alpha1.pedia.clusterpedia.io
更新 Clusterpedia
新建 PediaCluster CRD
, 并且更新 Clusterpedia APIServer
和 Clustersynchro Manager
DEPLOY_YAML_PATH=https://raw.githubusercontent.com/clusterpedia-io/clusterpedia/v0.1.0/deploy
CRD_YAML_PATH=$DEPLOY_YAML_PATH/crds
kubectl apply -f \
$CRD_YAML_PATH/cluster.clusterpedia.io_pediaclusters.yaml,\
$DEPLOY_YAML_PATH/clusterpedia_clustersynchro_manager_deployment.yaml,\
$DEPLOY_YAML_PATH/clusterpedia_apiserver_deployment.yaml,\
$DEPLOY_YAML_PATH/clusterpedia_apiserver_apiservice.yaml
可以将 YAML 下载到本地,或者拉取项目到本地,进入 ./deploy 目录下执行 kubectl apply。
重新接入集群
由于 PediaCluster
的 APIVersion 和结构都进行了一些不兼容的优化,所以需要重新根据备份的 clusters.yaml.bak 来重新创建 PediaCluster
。
当前 PediaCluster
的示例为:
apiVersion: cluster.clusterpedia.io/v1alpha2
kind: PediaCluster
metadata:
name: cluster-example
spec:
apiserver: "https://10.30.43.43:6443"
caData:
tokenData:
certData:
keyData:
syncResources:
- group: apps
resources:
- deployments
- group: ""
resources:
- pods
相比 0.0.9-alpha 主要有三个修改:
apiVersion
由 clusters.clusterpedia.io/v1alpha1 -> cluster.clusterpedia.io/v1alpha2spec.apiserverURL
->spec.apiserver
spec.resources
->spec.syncResources
根据 clusters.yaml.bak 内旧的 PediaCluster 来创建新的 PediaCluster
。
apiVersion: cluster.clusterpedia.io/v1alpha2
kind: PediaCluster
metadata:
name: cluster-1
spec: {}
---
apiVersion: cluster.clusterpedia.io/v1alpha2
kind: PediaCluster
metadata:
name: cluster-2
spec: {}
查看集群接入状态
kubectl get pediacluster
为多集群检索生成快捷访问配置
curl -sfL https://raw.githubusercontent.com/clusterpedia-io/clusterpedia/v0.1.0/hack/gen-clusterconfigs.sh | sh -
Clusterpedia 加持 kubectl,检索多集群资源
在多集群时代,我们可以通过 cluster-api 来批量创建管理集群,使用 Karmada/Clusternet 来分发部署应用。
不过我们貌似还是缺少了什么功能,我们要如何去统一的查看多个集群中的资源呢?
对于单个集群的资源,我们可以使用 kubectl 来查看搜索资源,但是在想要检索多集群的资源时,貌似没有什么趁手的产品可以使用。
不过从今天开始,这个问题不会再困扰你,因为在 Clusterpedia 的加持下,你手上的 kubectl 已经可以用来检索多集群资源啦。
例如,使用 kubectl 来获取多个集群下 kube-system 命名空间内的 deployments。
$ kubectl get deployments -n kube-system
CLUSTER NAME READY UP-TO-DATE AVAILABLE AGE
cluster-1 calico-kube-controllers 1/1 1 1 63d
cluster-1 coredns 2/2 2 2 63d
cluster-2 calico-kube-controllers 1/1 1 1 109d
cluster-2 coredns-coredns 2/2 2 2 109d
cluster-2 dce-chart-manager 1/1 1 1 109d
cluster-2 dce-clair 1/1 1 1 109d
Clusterpedia 介绍
Clusterpedia,名字借鉴自 Wikipedia,同样也展现了 Clusterpedia 的核心理念 —— 多集群的百科全书。
通过聚合多集群资源,在兼容 Kubernetes OpenAPI 的基础上额外提供了更加强大的检索功能,让用户更快更方便的在多集群中获取到想要的任何资源。
当然 Clusterpedia 的能力并不仅仅只是检索查看,未来还会支持对资源的简单控制,就像 wiki 同样支持编辑词条一样。
架构设计
Clusterpedia 在架构上分为四个部分:Clusterpedia APIServer
:以 Aggregated API 的方式注册到 Kube APIServer,通过统一的入口来提供服务。ClusterSynchro Manager
:管理用于同步集群资源的 Cluster Synchro。Storage Layer (存储层)
:用来连接操作具体的存储组件,然后通过存储层接口注册到 Clusterpedia APIServer 和 ClusterSynchro Manager 中。存储组件
:具体的存储设施,例如 mysql, postgres,redis 或者其他图数据库。 另外,Clusterpedia 会使用 PediaCluster 这个自定义资源来实现集群认证和资源收集配置
Clusterpedia 还提供了可以接入 mysql 和 postgres 的默认存储层。
Clusterpedia 并不关心用户所使用的具体存储设置是什么,用户可以根据自己的需求来选择或者实现存储层,然后将存储层以插件的形式注册到 Clusterpedia 中来使用。
特性和功能
- 支持复杂的检索条件,过滤条件,排序,分页等等
- 支持查询资源时请求附带关系资源
- 统一主集群和多集群资源检索入口
- 兼容 kubernetes OpenAPI, 可以直接使用 kubectl 进行多集群检索, 而无需第三方插件或者工具
- 兼容收集不同版本的集群资源,不受主集群版本约束,
- 资源收集高性能,低内存
- 根据集群当前的健康状态,自动启停资源收集
- 插件化存储层,用户可以根据自己需求使用其他存储组件来自定义存储层
- 高可用
部署
关于部署的详细流程,可以查看 安装 Clusterpedia,这里着重介绍了如何使用 clusterpedia。
集群资源收集
clusterpedia 部署完成后,我们可以通过 kubectl 来操作 PediaCluster 资源。
$ kubectl get pediaclusters
在 examples 目录下,可以看到 PediaCluster 的示例
apiVersion: clusters.clusterpedia.io/v1alpha1
kind: PediaCluster
metadata:
name: cluster-example
spec:
apiserverURL: "https://172.30.43.41:6443"
caData: ""
tokenData: ""
certData: ""
keyData: ""
resources:
- group: apps
resources:
- deployments
- group: ""
resources:
- pods
PediaCluster 在配置上可以分成两部分
- 集群认证
- 指定资源收集 .spec.resources
集群认证
caData , tokenData , certData , keyData 字段用于集群的验证。
当前暂时不支持从 ConfigMap 或者 Secret 中获取验证相关的信息,不过已经在 Roadmap 中了。
在设置验证字段时,注意要使用 base64 后的字符串
在 examples 目录下提供了生成用于访问子集群的 rbac yaml clusterpedia_synchro_rbac.yaml,来方便的获取子集群的权限 token。
在子集群中部署该 yaml,然后获取对应的 token 和 ca 证书。
$ # 当前 kubectl 连接到子集群中
$ kubectl apply -f examples/clusterpedia_synchro_rbac.yaml
clusterrole.rbac.authorization.k8s.io/clusterpedia-synchro created
serviceaccount/clusterpedia-synchro created
clusterrolebinding.rbac.authorization.k8s.io/clusterpedia-synchro created
$ SYNCHRO_TOKEN=$(kubectl get secret $(kubectl get serviceaccount clusterpedia-synchro -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}')
$ SYNCHRO_CA=$(kubectl get secret $(kubectl get serviceaccount clusterpedia-synchro -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.ca\.crt}')
复制 ./examples/pediacluster.yaml, 并修改 .spec.apiserverURL 和 .metadata.name 字段,并且将 $SYNCHRO_TOKEN 和 $SYNCHRO_CA 填写到 tokenData 和 caData 中。
使用 kubectl apply 创建。
$ kubectl apply -f cluster-1.yaml
pediacluster.clusters.clusterpedia.io/cluster-1 created
为了方便后续使用,建议再创建一个 cluster-2
集群收集
可以通过设置 spec.resources 字段的 group 和 group 下的 resources 来进行指定收集的资源。
在 status 中我们也可以看到资源的收集状态。
status:
conditions:
- lastTransitionTime: "2021-12-02T04:00:45Z"
message: ""
reason: Healthy
status: "True"
type: Ready
resources:
- group: ""
resources:
- kind: Pod
namespaced: true
resource: pods
syncConditions:
- lastTransitionTime: "2021-12-02T04:00:45Z"
status: Syncing
storageVersion: v1
version: v1
- group: apps
resources:
- kind: Deployment
namespaced: true
resource: deployments
syncConditions:
- lastTransitionTime: "2021-12-02T04:00:45Z"
status: Syncing
storageVersion: v1
version: v1
version: v1.22.2
资源检索
配置好我们需要收集的资源后,我们就可以进行重头戏了 —— 集群检索
clusterpedia 支持两种资源检索:
- 兼容 Kubernetes OpenAPI 的资源检索
- 集合资源 (Collection Resource) 的检索
$ kubectl api-resources | grep pedia.clusterpedia.io
collectionresources pedia.clusterpedia.io/v1alpha1 false CollectionResource
resources pedia.clusterpedia.io/v1alpha1 false Resources
为了方便我们更好的使用 kubectl 来进行检索,我们可以先通过 make gen-clusterconfig 来为子集群创建用于检索的 ‘快捷方式’。
$ make gen-clusterconfigs
./hack/gen-clusterconfigs.sh
Current Context: kubernetes-admin@kubernetes
Current Cluster: kubernetes
Server: https://10.9.11.11:6443
TLS Server Name:
Insecure Skip TLS Verify:
Certificate Authority:
Certificate Authority Data: ***
Cluster "clusterpedia" set.
Cluster "cluster-1" set.
使用 kubectl config get-clusters 可以查看当前支持的集群。
其中 clusterpedia 是一个特殊的 cluster,用于多集群检索,以 kubectl –cluster clusterpedia 的方式来检索多个集群的资源。
多集群资源检索
我们先看一下我们都收集了哪些资源,只有被收集的资源才可以进行检索。
$ kubectl --cluster clusterpedia api-resources
NAME SHORTNAMES APIVERSION NAMESPACED KIND
pods po v1 true Pod
deployments deploy apps/v1 true Deployment
可以看到当前收集并支持 pods 和 deployments.apps 两种资源
查看所有集群的 kube-system 命名空间下的 deployments
$ kubectl --cluster clusterpedia get deployments -n kube-system
CLUSTER NAME READY UP-TO-DATE AVAILABLE AGE
cluster-1 calico-kube-controllers 1/1 1 1 63d
cluster-1 coredns 2/2 2 2 63d
cluster-2 calico-kube-controllers 1/1 1 1 109d
cluster-2 coredns-coredns 2/2 2 2 109d
cluster-2 dce-chart-manager 1/1 1 1 109d
cluster-2 dce-clair 1/1 1 1 109d
查看所有集群的 kube-system, default 命名空间下的 deployments
$ kubectl --cluster clusterpedia get deployments -A -l "search.clusterpedia.io/namespaces in (kube-system, default)"
查看 cluster-1, cluster-2 两个集群下的 kube-system, default 命名空间下中的 deployments
$ kubectl --cluster clusterpedia get deployments -A -l "search.clusterpedia.io/clusters in (cluster-1, cluster-2),\
search.clusterpedia.io/namespaces in (kube-system,default)"
NAMESPACE CLUSTER NAME READY UP-TO-DATE AVAILABLE AGE
kube-system cluster-1 calico-kube-controllers 1/1 1 1 63d
kube-system cluster-1 coredns 2/2 2 2 63d
default cluster-1 dao-2048-2048 1/1 1 1 20d
default cluster-1 hello-world-server 1/1 1 1 26d
default cluster-1 my-nginx 1/1 1 1 39d
default cluster-1 phpldapadmin 1/1 1 1 40d
kube-system cluster-2 calico-kube-controllers 1/1 1 1 109d
kube-system cluster-2 coredns-coredns 2/2 2 2 109d
kube-system cluster-2 dce-chart-manager 1/1 1 1 109d
kube-system cluster-2 dce-clair 1/1 1 1 109d
显示数据有删减,略多
查看 cluster-1, cluster-2 两个集群下的 kube-system, default 命名空间下中的 deployments,并根据资源的名字排序
$ kubectl --cluster clusterpedia get deployments -A -l "search.clusterpedia.io/clusters in (cluster-1, cluster-2),\
search.clusterpedia.io/namespaces in (kube-system,default),\
search.clusterpedia.io/orderby=name"
kube-system cluster-1 calico-kube-controllers 1/1 1 1 63d
kube-system cluster-2 calico-kube-controllers 1/1 1 1 109d
kube-system cluster-1 coredns 2/2 2 2 63d
kube-system cluster-2 coredns-coredns 2/2 2 2 109d
default cluster-1 dao-2048-2048 1/1 1 1 20d
kube-system cluster-2 dce-chart-manager 1/1 1 1 109d
kube-system cluster-2 dce-clair 1/1 1 1 109d
kube-system cluster-2 dce-registry 1/1 1 1 109d
kube-system cluster-2 dce-uds-storage-server 1/1 1 1 109d
default cluster-1 dd-airflow-scheduler 0/1 1 0 53d
default cluster-1 dd-airflow-web 0/1 1 0 53d
kube-system cluster-2 metrics-server 1/1 1 1 109d
default cluster-1 my-nginx 1/1 1 1 39d
default cluster-1 nginx-dev 1/1 1 1 14d
default cluster-1 openldap 1/1 1 1 40d
default cluster-1 phpldapadmin 1/1 1 1 40d
显示数据有删减,略多
指定集群检索
我们如果想要检索指定集群的资源的话,我们可以使用 –cluster 来指定具体的集群名称
$ kubectl --cluster cluster-1 get deployments -A
NAMESPACE CLUSTER NAME READY UP-TO-DATE AVAILABLE AGE
kubeapps-oidc cluster-1 apach2-apache 1/1 1 1 35d
kube-system cluster-1 calico-kube-controllers 1/1 1 1 63d
cert-manager cluster-1 cert-manager 1/1 1 1 42d
cert-manager cluster-1 cert-manager-cainjector 1/1 1 1 42d
cert-manager cluster-1 cert-manager-webhook 1/1 1 1 42d
kube-system cluster-1 coredns 2/2 2 2 63d
default cluster-1 dao-2048-2048 1/1 1 1 20d
kubernetes-dashboard cluster-1 dashboard-metrics-scraper 1/1 1 1 54d
default cluster-1 dd-airflow-scheduler 0/1 1 0 53d
default cluster-1 dd-airflow-web 0/1 1 0 53d
显示数据有删减,略多
除了 http://search.clusterpedia.io/clusters 外其余的复杂查询的支持和多集群检索相同。
如果我们要获取一个资源的详情,那么也是需要指定集群才可以。
$ kubectl --cluster cluster-1 -n kube-system get deployments coredns
CLUSTER NAME READY UP-TO-DATE AVAILABLE AGE
cluster-1 apach2-apache 1/1 1 1 35d
复杂检索clusterpedia 支持以下复杂检索:
- 指定一个或者多个集群名称
- 指定一个或者多个命名空间
- 指定一个或者多个资源名称
- 指定多个字段的排序
- 分页功能,可以指定 size 和 offset
- labels 过滤
对于字段的排序,实际的效果是根据存储层来决定的,默认存储层支持根据 cluster , name , namespace , created_at , resource_version 进行正序或者倒序的排序。
检索条件的传递方式
上面实例中,演示了使用 kubectl 来进行检索,而这些复杂的检索条件通过 label 来传递的。实际上 clusterpedia 还支持直接通过 url query 的传递这些检索条件。
功能 | label key | url query | example |
---|---|---|---|
Specified resource name | search.clusterpedia.io/names | names | ?names=pod-1,pod-2 |
Specified namespace | search.clusterpedia.io/namespaces | namespaces | ?namespaces=kube-system,default |
Specified cluster name | search.clusterpedia.io/clusters | clusters | ?clusters=cluster-1,cluster-2 |
Sort by specified fileds | search.clusterpedia.io/orderby | orderby | ?orderby=name desc,namespace |
Specified size | search.clusterpedia.io/size | size | ?size=100 |
Specified offset | search.clsuterpedia.io/offset | offset | ?offset=10 |
search label key 的操作符支持 ==, =, !=, in, not in 对于 size 这个条件,实际上 kubectl 可以通过 –chunk-size 来指定,而不需要通过 label key。
聚合资源(Collection Resource)
在 clusterpedia 还有对资源更加高级的聚合,使用 Collection Resource 可以一次性获取到一组不同类型的资源。
可以先查看一下当前 clusterpedia 支持哪些 Collection Resource。
$ kubectl get collectionresources
NAME RESOURCES
workloads deployments.apps,daemonsets.apps,statefulsets.apps
通过获取 workloads 便可获取到一组 deployment, daemonset, statefulset 聚合在一起的资源 而且 Collection Resource 同样支持所有的复杂查询。
kubectl get collectionresources workloads
会默认获取所有集群下所有命名空间的相应资源。
$ kubectl get collectionresources workloads
CLUSTER GROUP VERSION KIND NAMESPACE NAME AGE
cluster-1 apps v1 DaemonSet kube-system vsphere-cloud-controller-manager 63d
cluster-2 apps v1 Deployment kube-system calico-kube-controllers 109d
cluster-2 apps v1 Deployment kube-system coredns-coredns 109d
cluster-2 apps v1 Deployment dce-acm-agent dce-acm-agent 84d
在 cluster-1 中增加收集 Daemonset, 输出有删减,太多
由于 kubectl 的限制所以无法在 kubectl 来使用复杂查询,只能通过 url query 的方式来查询。
自定义 Collection Resource
Collection Resource 支持哪些资源是由存储层来提供,而默认存储层未来会支持自定义组合 Collection Resource。
新特性议题
对资源进行更复杂的操作
clusterpedia 不仅仅只是用来做资源检索,和 wiki 一样,它也应该具有对资源简单的控制能力,例如 watch, create, delete, update 等操作。
对于写操作,实际会采用双写 + 响应 warning 的方式来完成。
感兴趣的话可以在 issue 中一起讨论。
集群的自动发现与收集
clusterpedia 中用来表示集群的资源叫做 PediaCluster, 而不是简单的 Cluster,最主要的原因便是 clusterpedia 设计初衷便是让 clusterpedia 可以建立在已有的多集群管理平台之上。
为了遵循初衷,第一个问题便是不能和已有的多集群平台中的资源冲突, Cluster 便是一个最通用的代表集群的资源名称。
另外为了更好的去接入到已有的多集群平台上,让已经接入的集群可以自动的完成资源收集,我们需要另外的一个集群发现机制。这个发现机制需要解决以下问题:
- 能够获取到访问集群的认证信息
- 可以配置触发 PediaCluster 生命周期的 Condition 条件
- 设置默认的资源收集策略,以及名称前缀等
这个功能会在 Q1 或者 Q2 中开始详细讨论实现。
当前进展
clusterpedia 当前处于比较早期的阶段 (v0.0.9-alpha),核心功能刚刚完成,还有很多可以优化的地方,对于这些优化点也都提了对应的 issues,欢迎大家一起讨论
这里简单说一些进入 v0.1.0 版本前的优化点:
- 从具有 Server-Side Apply 特性的集群中收集到的资源会带有很臃肿的 managedFields 字段, clustersynchro manager 模块会增加相应 feature gate,来允许用户在收集时裁减掉这个字段
- 同样的臃肿字段 annotations 中的 http://kubectl.kubernetes.io/last-applied-configuration,也要允许裁剪这个字段
- 在指定集群获取资源时,如果集群处于异常状态时,应该在响应中添加 warning 来提醒用户
- 对 PediaCluster 的状态信息有更准确的更新
- 弱网环境下,资源收集的优化
更多的优化项,大家可以在 issue 中提出新的想法。
Roadmap
当前只是暂定的 Roadmap,具体的排期还要看社区的需求程度
2021 Q4
在 2021 的 Q4 阶段会完成上述的优化项,并且完成对自定义资源的收集
- 详细化资源收集状态
- 自定义资源的收集
2022 Q1
- 支持插件化存储层
- 实现集群的自动发现和收集
2022 Q3
- 支持对集群资源更多的控制,例如 watch/create/update/delete 等操作
- 默认存储层支持自定义 Collection Resource
- 支持请求附带关系资源
使用注意
多集群网络连通
clusterpedia 实际并不会解决多集群环境下的网络连通问题,用户可以使用tower等工具来连接访问子集群,也可以借助 submariner 或者 skupper 来解决跨集群网络问题。