Karmada v1.2发布：开启全文本搜索新纪元

Karmada v1.2发布：开启全文本搜索新纪元

摘要：Karmada v1.2 版本对调度器能力做了较大增强，初步提供了分布式搜索引擎支持，此外还借助聚合API提供了诸如 logs, watch等实用的命令行工具，资源解释器（Resource Interpreter）开始支持状态收集定制。

本文分享自华为云社区《​​Karmada v1.2发布：开启全文本搜索新纪元​​》，作者： 云容器大未来。

与之前的版本一样，v1.2与前面的版本仍然保持兼容。

新特性

全局全文搜索K8s资源

该版本提供了一个名为”karmada-search”的组件，用于缓存集群中部署的资源对象和事件，并通过搜索API对外提供检索服务。

与聚合API提供的查询服务所不同的是，缓存检索不需要访问目标集群，定位于需要经常进行数据搜索和分析的场景，比如构建实时的资源、事件看板。

用户可以使用ResourceRegistry API来指定缓存的资源类型以及数据源（目标集群），例如以下配置指示从member1 和member2两个集群中缓存Deployment资源：

apiVersion: search.karmada.io/v1alpha1kind: ResourceRegistrymetadata: name: foospec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment targetCluster: clusterNames: - member1 - member2

将该配置提交给karmada-apiserver，便可使用search API 进行检索，例如查询缓存的deployment：

# kubectl get --raw /apis/search.karmada.io/v1alpha1/search/cache/apis/apps/v1/deployments{ "apiVersion": "v1", "kind": "List", "metadata": {}, "items": [{ "apiVersion": "apps/v1", "kind": "Deployment", "metadata": { "annotations": { "cluster.karmada.io/name": "member1", }, } }, ]}

该URL中，/apis/search.karmada.io/v1alpha1/search/cache为固定前缀，后面部分与Kubernetes原生API路径完全一致。

此外，`karmada-search`还支持第三方存储，如搜索引擎（Elasticsearch或OpenSearch）以及关系型数据库（MySQL）、图数据库等，当前版本仅支持搜索引擎。

借助搜索引擎强大的数据搜索和分析能力，可以对资源对象和事件进行随意组合形成各种报表，比如镜像拉取情况，节点OOM情况等。

Karmada聚合API大放异彩

聚合API能力首次在v1.0版本中提供，它提供聚合多个集群API入口的能力，用户仅通过Karmada控制面即可实时查询集群中的资源对象。

在v1.2版本中，我们借助该能力提供了多个运程过程中常用的命令行工具。

karmadactl get：跨集群查询资源

# karmadactl get deployment -n defaultNAME CLUSTER READY UP-TO-DATE AVAILABLE AGE ADOPTIONnginx member1 2/2 2 2 33h Nnginx member2 1/1 1 1 4m38s Ypodinfo member3 2/2 2 2 27h N

在v1.2版本中使用聚合API重新实现了get命令，并支持了Pull模式的集群查询。

karmadactl logs: 跨集群查询容器日志

# ./karmadactl logs nginx-6799fc88d8-9mpxn -c nginx -C member1/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d//docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf...

容器日志的现在也可以在Karmada控制面进行查询。

除了logs, get还新增了watch命令进行跨集群监听资源变化和exec命令在远程容器中执行命令。

Karmada资源解释器支持状态收集定制化

自Karmada v0.10版本中新增资源解释器特性以来，社区不断地丰富该特性所支持的功能。在v1.2版本中，我们新加入了对InterpretStatus操作的支持。InterpretStatus操作支持用户自定义收集Kubernetes资源的状态信息，包括自定义资源CustomResourceDefinition（CRD）。

Karmada支持多集群资源以及资源状态管理 。在用户通过分发策略将指定资源分发到不同成员集群中之后，Karmada会将相应资源在不同成员集群上的状态信息经过层层收集，最终汇聚到控制面中的资源模板上，从而方便用户查看。比如说Deployment的状态信息：

# kubectl get deployments.apps nginx -oyamlapiVersion: apps/v1kind: Deploymentmetadata: … labels: app: nginx propagationpolicy.karmada.io/name: nginx-propagation propagationpolicy.karmada.io/namespace: default name: nginx namespace: defaultspec: …status: availableReplicas: 2 readyReplicas: 2 replicas: 2 updatedReplicas: 2

在资源状态收集过程中，Karmada原有的策略是收集资源的整个Status，这样带来的直接问题就是会收集到很多冗余的资源状态信息，这样会导致Karmada消耗更多的内存与存储资源，进而限制Karmada资源管理的规模。

InterpretStatus操作的引入，可以很好的解决上述问题。Karmada通过调用由用户自定义的资源状态收集钩子，就能够收集到经过处理后，不含冗余信息的资源状态。这对于CRD资源来说，尤其具有意义。因为对于CRD资源来说，Karmada并不清楚其Status定义，这意味着我们不能通过build-in的方式来处理状态信息。此时，用户可以借助该能力定制状态收集行为。

调度器能力增强：重平衡和故障驱逐

新的组件: karmada-descheduler

新增加了karmada-descheduler组件进行平衡调度结果，比如随着时间推移，集群中的Pod或许会因为集群资源变化（如Node故障）而变得无法运行，此时karmada-descheduler可以对该类资源进行驱逐，进而触发Karmada 调度器进行二次调度，重新为该工作负载分配新的可用集群。

新的插件

新加了名为ClusterLocality 的打分插件，该插件会根据调度约束和集群位置进行打分，便于调度器进行精准调度。

新加了名为SpreadConstraint 的过滤插件，该插件会过滤掉不满足约束的集群。

在这两个插件基础上，还增加了对spread-by-region的调度支持，借此可支持用户方便地根据region进行部署。

故障迁移和驱逐

该版本还启动了故障迁移和驱逐的优化工作，社区计划在下个版本中完成，部分优化工作已经在本版本中完成，比如更合理的故障判定规则和故障超期启动驱逐等。

控制器中新增加了--cluster-failure-threshold参数用于指定集群故障容忍周期，只有故障时间超过该周期，Karmada才将该集群判定为故障，避免因网络波动造成的误判。

控制器中还增加了--failover-eviction-timeout 参数指定故障驱逐容忍时间，一旦集群故障超过该周期，Karmada即启动故障驱逐（当前版本仅会对集群设置污点，驱逐能力将在下个版本提供）。

借助原生API集成周边生态：安全合规治理、helm chart跨集群分发

在Karmada 1.2版本中，Karmada借助Kubernetes原生API集成了Kubernetes周边生态，为用户提供了在Karmada中使用安全合规治理策略以及helm chart跨集群分发的实践案例。

安全合规治理

在生产环境中应用 Karmada时，出于安全、合规等管控目的，经常需要对工作负载进行审计、校验以及变更，例如下列场景：

为了便于在监控和日志中识别特定集群的应用，我们希望某个业务应用的 Pod 具备合适的标签结构，标识本 Pod 所在集群位置及业务角色。为了防范供应链攻击或是加速特定集群的镜像加载，我们限制特定集群的应用只能从特定仓库中拉取镜像，且拉取策略总是“Always”。Karmada在提升多集群的运维能力的同时也需要限制恶意用户对集群的破坏行为，或是运维人员在运维过程中的误操作，例如删除一个仍有工作负载工作的命名空间。

基于以上种种，Karmada需要一个安全策略引擎以满足多集群的安全合规治理。借助于原生API，Karmada可以无侵入地集成CNCF主流的安全策略引擎项目，当前社区已提供了Gatekeeper以及Kyverno的集成实践，用户可以基于上述实践以及生产需求生成自有的Karmada安全合规策略。

Helm chart跨集群分发

当前Karmada已实现对Kubernetes原生资源的跨集群分发，然而在生产环境中，应用通常包含不止一个工作负载，还包括RBAC资源、configmap、secret等，这就要求Karmada跨集群分发应用的能力。通常，用户选择Helm chart来进行应用的打包，在跨集群场景下，Karmada可以通过集成Flux的方式轻松实现helm chart跨集群分发的能力，不只于此，借助Karmada的OverridePolicy，用户可以定制针对特定集群的应用，在统一的Karmada控制面上管理跨集群的应用。

致谢贡献者

Karmada v1.2 版本包含了来自48位贡献者的数百次代码提交，在此对各位贡献者表示由衷的感谢：

贡献者GitHub ID:

@AllenZMC

@anu491

@carlory

@CharlesQQ

@chaunceyjiang

@chinmaym07

@CuiDengdeng

@dddddai

@duanmeng

@duanmengkk

@ErikJiang

@fanzhihai0215

@fleeto

@Garrybest

@gf457832386

@gy95

@hanweisen

@huiwq1990

@huntsman-li

@huone1

@ikaven1024

@jameszhangyukun

@kerthcet

@learner0810

@lfbear

@likakuli

@liys87x

@lonelyCZ

@lvyanru8200

@mikeshng

@mrlihanbo

@my-git9

@pangsq

@pigletfly

@Poor12

@prodanlabs

@RainbowMango

@sayaoailun

@snowplayfire

@stingshen

@Tingtal

@wuyingjun-lucky

@Notes:​​chart跨集群分发实践：​​https://github.com/karmada-io/karmada/blob/master/docs/working-with-flux.md​​

华为伙伴暨开发者大会2022火热来袭，重磅内容不容错过！

【精彩活动】

【技术专题】

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。