K8S Internals 系列：第三期
随着 Kubernetes 越来越成熟，以 kubernetes 为根底构建基础设施层的企业越来越多。据 CNCF 基金会统计，目前应用 Kubernetes 作为容器管理工具的企业占比早已过半，并且远远超过排名第二的 Swarm。
随同着 Kubernetes 的应用越来越多，过程中也逐步发现了一些问题，并促成了 kubernetes 联邦集群的倒退。这些问题次要包含：
1、kubernetes 集群本身限度
依据 kubernetes 官网大规模集群注意事项，以最新版本 Kubernetes v1.24 为例咱们能够看到 kubernetes 集群存在以下限度：
· 节点数不超过 5000
· 每个节点的 Pod 数量不超过 110 个
· Pod 总数不超过 150000
· 容器总数不超过 300000
因为单个集群的限度，有些业务可能须要部署在大量的 Kubernetes 集群上，此时就须要对多集群进行治理。
2、多集群治理的强烈需要
首先，将业务部署在单个的大规模集群中是比部署在多个较小集群中危险的，例如单个大集群呈现故障，无奈进行故障转移。其次，通过联邦集群能够在集群间进行资源同步和跨集群的服务发现，例如同城双活的场景。
鉴于以上（不限于）多种起因，企业内的 K8S 集群数量越来越多，K8S 本身的治理也变得日益简单。
01 kubernetes 联邦集群的发展史
为了解决上述问题，kubernetes 兴趣小组最后推出了我的项目 kubefed v1。Kubefed v1 在 Kubernetes v1.6 时进入了 Beta 阶段，然而 kubefed v1 后续的倒退不尽人意，最终在 Kubernetes v1.11 左右正式被弃用，弃用的次要起因是因为它存在以下问题：
管制立体组件会因为产生问题，而影响整体集群效率。
无奈兼容新的 Kubernetes API 资源。
无奈无效的在多个集群管理权限，如不反对 RBAC。
联邦层级的设定与策略依赖 API 资源的 Annotations 内容，这使得弹性不佳
kubernetes 兴趣小组并没有放弃倒退 kubernetes 联邦集群, 起初升级版的 kubefed v2 呈现了，kubefed v2 解决了兼容新的 kubernetes API 资源的问题，通过 CRD 裁减可反对的资源，并将集群划分为 Host 和 Member 两种类型的集群：
Host : 用于提供 KubeFed API 与管制立体的集群。
Member : 通过 KubeFed API 注册的集群，并提供相干身份凭证来让 KubeFed Controller 可能连贯集群。Host 集群也能够作为 Member 被退出。
继 V1 版本之后，社区又推出了 Kubefed V2。相比于 kubefed v1，V2 有了微小的扭转，例如对 kubernetes 原生资源散发的反对更加灵便，能够反对多个版本的 API，补救了 kubefed v1 无奈兼容新 API 的毛病，另外还反对了 CRD 本身，通过 Placement 字段配置资源散发，通过 Overrides 字段能够差异化配置散发到不同集群的资源。然而 kubefed v2 在推广过程中呈现了以下问题：
使用者部署 Kubernetes 资源须要相熟一套的全新 API，例如 FederatedDeployment。应用一套新的 API 替换 Kubernetes 原生的 API(例如：Deployment)，很大地减少了用户的学习老本。
例如部署 deployment:
apiVersion: types.kubefed.io/v1beta1 kind: FederatedDeployment #自定义资源类型 metadata: name: test-deployment namespace: test-namespace spec: template: #要部署的资源模板 metadata: labels: app: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: – image: nginx name: nginx placement: # 对象须要部署到集群 member1 和 member2 clusters: – name: member1 – name: member2 overrides: # 批改部署到 member2 集群的正本数为 2 – clusterName: member2 clusterOverrides: – path: “/spec/replicas” value: 2
须要通过遍历集群能力获取部署的利用的具体状态，在管制面只能看到利用是否散发胜利。
经验了多年倒退，联邦集群这个畛域的两次尝试都算不上胜利。难道就没有一个更好用的我的项目用来治理 kubernetes 联邦集群吗？
此时社区中的另一个我的项目 karmada 初露头角，karmada 继承和改良了 kubefed，例如部署 deployment, 在 karmada 中 FederatedDeployment 被拆解成了三个独自的资源，别离是资源模板 resource template 是 Kubernetes 原生 API 应用起来更难受, 调度策略 propagation policy 和差异化配置策略 override policy。
上面咱们简略介绍一下 karmada 架构及相干资源概念。
02 Karmada 架构
以 karmada v1.2.0 版本为例，karmada 的构造如下图所示：
其中的 karmada controller-manager,karmada aggregated-api-server,karmada Scheduler,karmada DeScheduler,karmada scheduler-estimator, karmada Agent 是 karmada 官网开发的组件，ETCD 即 ETCD 官网镜像，karmada API server 是 Kubernetes 官网的 API server 组件镜像。
karmada API server 与 API server 在 Kubernetes 集群中的性能相似，用来解决资源的增删改查及将数据长久到 ETCD 中。karmada controller-manager 性能是治理 karmada 中的实现的 controllers，负责它们的启动和进行等。
karmada aggregated-api-server 是一个聚合 API，该组件实现了通过 karmada API server 即可拜访成员集群资源的性能，并实现了对立鉴权认证，不必切换 kubeconfig 即可拜访不同成员集群。
karmada Scheduler 实现了 karmada 对资源调度到成员集群的调度性能，并实现了多种调度策略。
karmada DeScheduler 实现了每隔一段时间就检测一次所有部署，将指标集群中不可调度的正本再调度到其余可调度的集群上。
karmada scheduler-estimator 用来评估成员集群上可调度的正本数，在一些调度策略中调度器将依据其计算正本数来计算每个指标集群上须要调度的正本数。
karmada Agent 是部署在成员集群上的组件，用来上报成员集群信息到 karmda 管制立体和从 karmada 管制立体拉取散发到成员集群的资源信息。
03 Karmada 相干资源概念
上面咱们简略介绍一下 karmada 散发资源到成员集群波及的相干资源，这些资源可分为：
用于设定策略的资源：PropagationPolicy，OverridePolicy。
执行策略相干的资源：ResourceBinding，ClusterResourceBinding，Work。
karmadaresourcerelationkarmada
散发资源到成员集群流程如上图所示，在 karmada 管制立体创立 Resource Template 即为 kubernetes 原生资源，例如 Deployment，Service, configmap 等资源，同时创立 Propagation Policy 资源用来形容散发 Resource Template 到成员集群的策略，例如形容调度到哪些成员集群，应用动态权重策略等，如果有须要同时也能够创立 Override Policy 用来笼罩散发到不通成员集权中 Resource Template 中某些字段，例如批改 Deployment 中的容器镜像地址，容器参数等。
BindingController 依据 Resource Binging 资源内容创立 work 资源到各个成员集群的执行命名空间, work 中形容了要分到指标集群的资源内容，最终由 ExeuctionController 在各个成员集群中创立被散发的资源。
PropagationPolicy
散发策略蕴含集群级别的 ClusterPropagationPolicy 和 Namespace 级别的 PropagationPolicy，集群级别的能够散发各个命名空间的 resource Template，namespace 级别的只能散发本人命名空间级别的 resource Template，用来定义将创立的 resource Templater 散发到成员集群的策略。咱们具体看一下该资源相应字段：
Spec :Spec.ResourceSelector :Spec.Placement：Spec.Placement.ClusterAffinity：Spec.Placement.SpreadConstraint：Spec.Placement.ReplicaSchedulingStrategy：Spec.Placement.ClusterAffinity.FieldSelector：Spec.Placement.ReplicaSchedulingStrategy.WeightPreference, ClusterPreferences：DynamicWeightByAvailableReplicas 示意应依据可用资源（可用正本）生成集群权重列表。// Example: // The scheduler selected 3 clusters (A/B/C) and should divide 12 replicas to them. // Workload: // Desired replica: 12 // Cluster: // A: Max available replica: 6 // B: Max available replica: 12 // C: Max available replica: 18 // The weight of cluster A:B:C will be 6:12:18 (equals to 1:2:3). At last, the assignment would be ‘A: 2, B: 4, C: 6’. 复制代码
Spec.Placement.ReplicaSchedulingStrategy.WeightPreference.StaticClusterWeight：
OverridePolicy
OverridePolicy 和 ClusterOverridePolicy 定义下发到不通成员集群中不通配置，karmada 反对的有：
ImageOverrider 笼罩工负载的镜像
CommandOverrider 笼罩工作负载的 commands
ArgsOverrider 笼罩工作负载的 args
PlaintextOverrider 通用工具，笼罩任何品种的资源
Spec :
RuleWithCluster：
Overriders：
ImageOverrider :
ImagePredicate：
PlaintextOverrider：
CommandArgsOverrider：
ResourceBinding 和 ClusterResource
BindingResourceBinding 是由控制器 ResourceDetector 依据 resource Template 和 Propagation Policy 的内容主动创立的资源，代表一个 kubernetes 资源和一个散发策略的绑定，与散发策略绝对应 ResourceBinding 也分为集群级别的 ClusterResourceBinding 和 Namespace 级别的 ResourceBinding，同时也会记录 resource Template 最中部署的状态和后果。具体字段如下：
Spec:
Spec.ObjectReference：
Spec.ReplicaRequirements：
Spec.ReplicaRequirements.NodeClaim：
TargetCluster:
BindingSnapshot：
ResourceBindingStatus：
AggregatedStatusItem：
Work
work 定义了部署到指标成员集群的资源列表，由 bingingController 创立或者更新，由 execctionController 进行协调。
karmada 会为每一个散发的资源每个指标成员集群的执行命名空间（karmada-es-*) 中创立一个 work。被散发的资源不辨别是自定义资源还是 kubernetes 内置资源先被转化为 Unstructured 类型的数据，而后在 woker 中以 JSON 字节流的模式保留，而后在 execution_controller 中再反序列化，解析出 GVR，通过 dynamicClusterClient 在指标成员集群中创立指定散发资源。具体字段如下：
Spec:
WorkloadTemplate：
Manifest：
Status：
ManifestStatus：
ResourceIdentifier：
04 关注
在 karmada 的 2022 年的 roadmap 中，社区打算欠缺 Multi-cluster HA scheduling policy，联邦资源配额，及增加多集群日志、存储、RABC, 治理，多集群监控等。本期文章先介绍那么多，前面咱们也会继续关注 karmada 的倒退，并再推出 karmada 更深刻的介绍文章。