CNCF随笔

1、kustomize

kustomize和helm一样是k8s的yaml包管理工具，相较于Helm不需要学习一套特定领域配置语言，且是k8s官方的并集成进了kubectl。
常见的术语：
kustomization 指的是 kustomization.yaml 文件，或者指的是包含 kustomization.yaml 文件的目录以及它里面引用的所有相关文件路径；
base 指的是一个 kustomization , 任何的 kustomization 包括 overlay，都可以作为另一个 kustomization 的 base (简单理解为基础目录)。base 中描述了共享的内容，如资源和常见的资源配置；
overlay 是一个 kustomization, 它修改(并因此依赖于)另外一个 kustomization，没有 base, overlay 无法使用，并且一个 overlay 可以用作 另一个 overlay 的 base(基础)。简而言之，overlay 声明了与 base 之间的差异，通过 overlay 来维护基于 base 的不同 variants(变体)，例如开发、QA 和生产环境的不同 variants；
variant 是在集群中将 overlay 应用于 base 的结果。例如开发和生产环境都修改了一些共同 base 以创建不同的 variant。这些 variant 使用相同的总体资源，并与简单的方式变化，例如 deployment 的副本数、ConfigMap使用的数据源等。简而言之，variant 是含有同一组 base 的不同 kustomization；
resource 是描述 k8s API 对象的 YAML 或 JSON 文件的相对路径，即指向一个声明了 kubernetes API 对象的 YAML 文件
patch是修改文件的一般说明，指向一个声明了 kubernetes API patch 的 YAML 文件

2、Argo CD

        Argo CD是遵循声明式 GitOps 理念的持续部署CD工具，而持续集成CI一般是交给 Jenkins。
        ArgoCD与Flux CD的主要职责都是监听Git Repositories变化，对比当前应用运行状态与期望运行状态的差异，然后自动拉取变更并同步部署到集群环境中。
        Argo CD主要包括ArgoCD API server(提供API给Web UI，CLI以及其他CI/CD做系统调用或集成)、repossitory server(维护一个Git Repo中应用编排文件的本地缓存)、Application Controller(k8s Controller，主要是持续监听应用当前运行状态与期望状态（Git Repo中描述的状态）的不同，并自动检测应用OutOfSync状态并根据Sync测试执行下一步动作)。
        且Argo CD集成了CLI和Web UI，且支持管理多集群，以secret的方式存储外部集群的凭证。

3、Flux CD
        主要包括Flux daemon， 主要职责是持续监听用户配置的Git Repo中Kubernetes资源编排文件的变化，然后同步部署到集群中； 它还可以检测容器镜像仓库中image更新，提交更新到用户Git Repo，然后同步部署到集群中。 以上同步部署动作均基于用户设置的策略。
        Flux CD目前不提供UI，且不支持多集群管理，需要在每个集群中部署Flux CD组件。

4、Thanos

Thanos是单集群内多Pormetheus多分片数据的高可用的解决方案，通常是sidecar的方式，主要解决了Prometheus数据持久化存储和集中化全局视图。

5、SLO

SLO是(service level objective)服务质量目标的简称，如qps、响应时间。

6、华为云-多集群管理-Karmada

1、能够支持独立的etcd和scheduler，
2、Push 模式：Karmada 控制⾯直接管理成员集群并执行资源同步（这种模式下，不需要为成员集群部署额外的组件，只需要将成员集群注册到Karmada控制面即可）
3、Pull 模式：成员集群主动向Karmada控制面拉取资源并同步⾃⾝状态（这种模式下，成员集群只需要部署“karmada-agent”组件即可，该组件会自动完成集群注册）
4、参考：https://mp.weixin.qq.com/s/1NGeXAnIklkUZBbSMH6FPg

5、以Karmada为核心的集群联邦可以稳定支持100个大规模集群，管理超过50万个节点和200万个Pod；

7、dapr：Distributed Application Runtime

dapr 利用标准 API 暴露各种分布式能力，来屏蔽多运行时架构，容器运行时就是容器运行起来需要的一系列程序和环境。

8、eBPF

eBPF 是当有事件触发时，在操作系统的内核中能够安全运行的自定义程序（eBPF程序的代码是直接在内核空间中运行的，并且当 eBPF 程序被加载到内核中时，会有一个验证器来确保它是安全运行的，如果无法确认，就会被拒绝运行）。
而传统的程序一般都运行在用户空间，内核生成的所有原始数据必须先从内核空间复制到用户空间，这种数据复制和过滤的操作会对 CPU 造成较大的负担。

9、code-generator、controller-tools、kubebuiler

code-generator的作用是client-gen、lister-gen、informer-gen、deepcopy-gen；

controller-tools是kubebuiler的子项目，作用是生成crd、deepcopy、types文件；

kubebuilder作用是

10、CrossPlane

CrossPlane能够使用 kubectl 并以k8s的restful api风格统一配置和管理云基础设施和应用程序。

11、IaaS、PaaS、SaaS

IaaS：EC2、S3 存储、虚拟机等；
PaaS：⼯具和服务的集合；
SaaS：Github

12、云原生配置语言

• Ballerina
• Pulumi
• Cue
• KCL
• Kusion

13、云原生开源项目大全

Awesome Cloud NativeA curated list of awesome Go frameworks, libraries and softwarehttps://jimmysong.io/awesome-cloud-native/

14、velero

velero主要有两种方式：

（1）快照方式snapshot，存储须支持CSI快照接口，只存储API对象，且只能在本集群做恢复；
（2）文件复制方式restic，支持没有快照功能的存储，能同时存储API对象和PVC数据，通过S3 bucket中的备份数据，可将应用恢复至其他集群；

velero backup create fourier-backup --include-namespaces velero --selector aaa=velero
velero backup describe fourier-backup
velero restore create --from-backup fourier-backup --include-namespaces velero --selector aaa=velero

15、GitOps

GitOps是将Git作为CI/CD流水线的核心，将应用程序和应用部署计划都存放在Git版本库中，每个开发人员都可以使用Git，来加速和简化应用程序部署和运维任务

16、jenkins

jenkins是CI&CD 软件领导者，提供超过1000个插件来支持构建、部署、自动化，满足任何项目的代码编译、代码检查、打包镜像、归档发布、集成测试的需要。

17、ArgoCD 

当用户向 Git 仓库提交合并请求，合并通过后，Git 仓库中应用状态的配置清单发生变化，此时 Git 仓库可以通过 WebHook 触发 ArgoCD 的应用同步，如果未配置 WebHook，ArgoCD 会轮询检测 Git 仓库的变更来触发应用同步，检测周期默认为 3 分钟；
且能通过ApplicationSet实现多集群部署；

18、云原生概念

云原生落地的难点在使用，如何能将云原生底层复杂的技术包装成开发者熟悉的应用层属性和动作，开发者就不用学习新的概念和技术。

应用管理比资源管理复杂很多，涉及到应用开发、应用架构、应用交付和应用运维等应用层的管理，还要配合应用解决资源自动化管理问题，云原生本质就是解决应用的自动化管理问题。

19、弹性伸缩相关记录

为什么要做PPA?

使用 CPA 设置各个时间段的容器数，有一定的优化效果。但是，CPA 设置的时间段越多，运维成本越高，并且不够灵活，目标容器数的配置也比较困难，太少则无法保证应对业务高峰，太多又起不到优化成本的效果，需要反复尝试进行调整。
PPA可以根据业务历史指标，自动识别弹性周期并对容量进行预测，解决弹性滞后的问题。

兜底保护策略：设置实例数上下界值实现弹性兜底

20、OpenKruise CloneSet的原地升级策略

所谓原地升级，可以理解为 pod 在升级的时候，通过 edit 或者 patch 等子命令行为对 Yaml 资源文件进行更新后重新使用，而不是销毁重建，但是仍会重建container。

重建升级时我们要删除旧 Pod、创建新 Pod：

• Pod 名字和 uid 发生变化，因为它们是完全不同的两个 Pod 对象（比如 Deployment 升级）

• Pod 名字可能不变、但 uid 变化，因为它们是不同的 Pod 对象，只是复用了同一个名字（比如 StatefulSet 升级）

• Pod 所在 Node 名字发生变化，因为新 Pod 很大可能性是不会调度到之前所在的 Node 节点的

• Pod IP 发生变化，因为新 Pod 很大可能性是不会被分配到之前的 IP 地址的

但是对于原地升级，我们仍然复用同一个 Pod 对象，只是修改它里面的字段。因此：

• 可以避免如 调度、分配 IP、分配、挂载盘 等额外的操作和代价。

• 更快的镜像拉取，因为复用已有旧镜像的大部分 layer 层，只需要拉取新镜像变化的一些 layer。

• 当一个容器在原地升级时，Pod 中的其他容器不会受到影响，仍然维持运行。

这种升级类型名为 InPlaceIfPossible，它意味着Kruise 会尽量对 Pod 采取原地升级，如果不能则退化到重建升级。

21、k8s原地更新提案

k8s的提案Pod原地垂直伸缩能够允许 Pod 资源 requests 和 limits 的原地更新，而不需要重新启动 Pod 或其容器。

在Pod 资源清单中新增了一个 resizePolicy 属性，支持：

ReStartNotRequired（如果可能，尝试在不重启容器的情况下调整它的资源规格）。

Restart（容器需要重新启动才能应用新的资源规格）。

参考：

enhancements/keps/sig-node/1287-in-place-update-pod-resources at master · kubernetes/enhancements · GitHub

https://github.com/kubernetes/kubernetes/pull/102884

22、k8s备份与恢复方案

（1）Velero能够实现在 etcd 中存储的资源对象本身、应用所绑定的持久卷的备份，但没能妥善处理应用内存中的状态数据，以及操作系统磁盘缓存中的数据，因此如果不对应用进行特殊改造，就会存在发生迁移后数据丢失的风险。
（2）CRIU 是 Linux 下的一个用户态软件，它可以获取一个正在运行中的进程的快照，将快照复制到其他的机器上后，又能完全恢复出该进程，并保持打快照时的程序状态。
CRIU 的进程快照包含了包括进程内存、文件描述符、进程树、地址空间信息、设备信息等等各种与进程相关数据，因此可以非常完整的恢复整个进程，基于 CRIU 技术可以方便的实现容器的热迁移。
提案  KEP-2008: Forensic Container Checkpointing 的，正是采用了 CRIU 技术来扩展 Kubelet 以实现容器迁移（以及取样分析等），通过调用该 Kubelet API，就可以对任意容器创建一个快照拷贝，并将其用于分析、迁移等用途。该功能目前已经在 K8s v1.25 版本中 alpha。