erpan笔记👏

官方文档 概述 在 Kubernetes 中，准入控制是保障 API 请求安全和合规性的重要机制。它在 API 请求流程中扮演着关键角色，拦截即将发送到 Kubernetes APIServer的请求，在持久化之前，但在身份验证和授权之后。其位置如下图所示： 图片来源https://sysdig.com/blog/kubernetes-admission-controllers/ 准入控制器适用于创建、删除或修改对象的请求，同时也可以阻止自定义动作。读操作会绕过准入控制层，不会受到准入控制器的影响。当有多个准入控制器存在时，它们会依次被调用，只要其中一个准入控制器拒绝请求，整个请求就会被立即驳回。 准入控制常常被用来自动化设置默认资源请求和限制、应用标签和注释以及强制命名约定等管理任务。 准入控制分两个阶段： 变更准入控制器，用于在请求处理过程中对对象进行修改。 验证准入控制器，负责验证请求是否符合特定规则。 需要注意的是，部分控制器兼具变更准入和验证准入的功能。 启用准入 1 kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ... 关闭准入 1 kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ... 准入的两种类型： 静态准入：由 Kubernetes 内置提供，无需额外配置。 动态准入：允许用户根据自身需求进行扩展。 动态准入控制器： MutatingAdmissionWebhook 此准入控制器调用任何与请求匹配的变更（Mutating） Webhook。匹配的 Webhook 将被顺序调用 ValidatingAdmissionWebhook 此准入控制器调用与请求匹配的所有验证性 Webhook。 匹配的 Webhook 将被并行调用。如果其中任何一个拒绝请求，则整个请求将失败。 该准入控制器仅在验证（Validating）阶段运行 ValidatingAdmissionPolicy 验证准入策略使用通用表达语言 (Common Expression Language，CEL) 来声明策略的验证规则，是一种声明式的、进程内的验证准入 Webhook 方案 MutatingAdmissionPolicy 提供了一种声明式的、进程内的方案， 可以用来替代变更性准入 Webhook 实现 步骤概览 实现一个 MutatingAdmissionWebhook 主要包括以下几个步骤： 生成证书，Kubernetes 和 Webhook 服务使用 TLS 加密通信 APIServer对Webhook的认证 Webhook对APIServer的认证（可选） 实现一个接口，接收AdmissionReview请求，解析并填充response字段，响应相同版本的AdmissionReview 部署上面接口，集群内外都可以 注册准入控制器 监控 Admission Webhook 以下面需求为例：...

仅作为个人笔记，不保证完全的准确性和正确性，请自行甄别 顺序写 文件IO中的“顺序写”通常指的是对文件进行连续写入操作的过程，即从文件的一个位置开始，依次向后写入数据，即追加。可以提高写入效率，尤其是在传统的机械硬盘（HDD）上，因为不需要频繁地在不同的位置之间切换，减少了寻道时间和旋转延迟。 需要注意的是，“顺序写”并不直接等同于物理磁盘上的连续空间写入。虽然理想情况下，操作系统和文件系统会尽量将文件的数据块分配到物理上连续的存储空间中，以提高读写性能，但实际上由于多种因素（如文件系统的碎片、先前删除文件留下的空洞、以及其他文件的存在等），很难保证文件的所有部分都能被分配到完全连续的物理空间中。因此，通常说的“顺序写”，更多是指逻辑上的连续写入，即按照文件内部的偏移量顺序写入数据，而不是指物理磁盘上的连续写入。 即，“顺序写”主要关注的是逻辑层面的连续性，而物理层面的连续性则是文件系统和操作系统尽力优化的结果。 示例 顺序写： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 package main import ( "fmt" "os" ) func main() { fileName := "t....

同时启很多个goroutine来完成一个任务，在一些必要的情况下如何跟踪或取消这些goroutine？常见的有下面几种方式： WaitGroup，goroutine之间的同步 for select 加上 stop channel来监听消息管理协程 context包 context包就是用来在goroutine之间传递上下文信息的，它提供了超时timeout和取消cancel机制，利用了channel进行信息传递，方便的管理具有复杂层级关系的多个goroutine，这些复杂的层级关系类似于一棵树，可以有多个分叉。Go标准库中的net/http，database/sql等都用到了context包。 接口 context包定义了两个接口 Context 1 2 3 4 5 6 type Context interface { Deadline() (deadline time.Time, ok bool) Done() <-chan struct{} Err() error Value(key interface{}) interface{} } Deadline 方法，第一个返回值是该上下文执行完的截止时间，第二个返回值是布尔值，表示是否设置了截止日期，没设置返回ok==false，否则为true。该方法幂等 Done，返回一个只读通道，在context被取消或者context到了deadline时，此通道会被关闭 WithCancel 上下文，当调用cancel后此通道关闭关闭 WithDeadline，到达deadline时间点后自动关闭此通道 WithTimeout，指定的时间超时后自动关闭此通道 Err，Done返回的通道未被关闭时，Err的返回值是nil，关闭后，返回 context 取消的原因，被取消时返回Canceled，到了截止时间返回 DeadlineExceeded Value，获取该Context上绑定的值，需要注意的是键和值都是any类型。以上四个方法都是幂等的 canceler ，私有接口，表示一个可以被取消cancel的context对象，包内的*cancelCtx 和 *timerCtx结构体实现了此接口 1 2 3 4 type canceler interface { cancel(removeFromParent bool, err, cause error) Done() <-chan struct{} } 创建 几个实现此接口的结构体关系：...

ArgoCD 遵循GitOPS模式，应用定义、配置和环境等都应该是声明式和版本化的。应用部署和生命周期管理是自动化、可审计和易于理解的 特性 拥有GitOPS的一切特性，如回滚到任意git commit点 自动发布应用到指定环境，支持多集群管理 支持多种配置管理工具、模板 (Kustomize，Helm， Jsonnet， plain-YAML，自定义配置管理插件) 支持单点登录 (OIDC, OAuth2, LDAP, SAML 2.0, GitHub, GitLab, Microsoft, LinkedIn) 支持多租户及RBAC授权 服务健康状态分析 资源版本偏移检查和Web UI实时可视化 可自动或手动同步资源到目标状态 提供命令行工具，自动化集成简单方便 Webhook 集成 (GitHub, BitBucket, GitLab) 支持访问令牌 支持各阶段钩子定义PreSync, Sync, PostSync hooks to support complex application rollouts (e.g.blue/green & canary upgrades) 应用事件和API调用审计追踪 有暴露Prometheus 指标 Parameter overrides for overriding helm parameters in Git 几个核心概念 Application：指定manifest路径下的一组kubernetes资源，是一个CRD AppProject：Application的逻辑分组，可以配置一些约束选项，如限制git源、目标集群、namespace和资源类型等，也可以订阅project roles App of Apps：官网文档中的 cluster bootstrapping，一个Application包含多个子Application，在批量创建Application时比较有用，也可以用来自我管理（官方文档有示例） 下图是定义了一个Application对象，其指定的仓库目录下包含多种资源，其中的子Application对象所指定的仓库目录又可以包含多种资源，我们可以开启递归的选项，在往仓库添加资源对象的时候自动apply到对应集群当中去 注意点： 一个ArgoCD实例中，Application名字是唯一的，且只能放在与argo部署的同一名称空间中 Application中没有指定resources-finalizer.argocd.argoproj.io终结器，在删除Application的时候是不会删除它所管理的资源，App of Apps也是一样 ApplicationSet 跨集群和仓库灵活的管理Applications，补充了以集群管理为中心的场景...

在client-go源码中，processorListener对象里面定义了一个RingBuffer用于缓存所有尚未分发的事件通知，在此记录下这个RingBuffer。 RingBuffer一般用于数据的缓存机制，例如tcp协议里面数据包的缓冲就利用到了RingBuffer。 client-go中的这个buffer是非线程安全、可增长、无边界的先进先出环形缓冲区。环是一个逻辑上的概念，有了环，此段内存空间就可以重复利用，不用频繁重新申请内存，本质上数据还是存在数组里面的，这个数组的大小可以按需进行倍数扩容，扩容后需要重新分配内存空间并拷贝未消费的数据到新数组来。因为它是数组，内存是预先分配的，数组是内存上连续的一段空间，它有一个容易预测的访问模式，因此对CPU高速缓存友好，垃圾回收（GC）在这种情况下也不用做什么。 在实现上，可以理解为两个指针：a) 读指针、b)写指针。在一段buffer上，读指针控制下一次该读数据的位置，写指针控制下一次该写数据的位置。在数组里面我们可以直接用数组下标。要遵循FIFO原则，读指针不能超过写指针，两指针重叠了要么buffer写满了，要么buffer为空。 参考这里的一张图 目前我们只需要考虑： 存储啥数据类型 数据如何存放 何时空间满了需要扩容 不能丢失未消费数据 k8s中的源码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 // 源码路径k8s....