Visual Studio使用 离线安装包 在页面 [4] 下载安装引导命令，下载完成后使用命令（对于C++来说） bat 1 vs_Professional.exe --layout ‪1111 --add Microsoft.VisualStudio.Workload.NativeDesktop --includeRecommended --lang en-US zh-CN 随后会触发下载，等待下载完成后，在 --layout 指定的目录上点击 vs_setup 开始离线安装。 Note: 对于完全脱离C盘安装可以使用下面的脚本，更改变量为要安装的路径 bat 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 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 :: 关闭终端回显 @echo off SET ROOT_PATH=D:\Program Files\Microsoft Visual Studio SET X86_PATH=%ROOT_PATH%\Program Files (x86) SET X86_VS_PATH=%X86_PATH%\Microsoft Visual Studio SET X86_SDK_PATH=%X86_PATH%\Microsoft SDKs SET X86_KITS_PATH=%X86_PATH%\Windows Kits SET X86_AV_PATH=%X86_PATH%\Application Verifier SET X64_PATH=%ROOT_PATH%\Program Files rem SET X64_VS_PATH=%X64_PATH%\Microsoft Visual Studio SET X64_AV_PATH=%X64_PATH%\Application Verifier SET X64_SQL_PATH=%X64_PATH%\Microsoft SQL Server SET PD_PATH=%ROOT_PATH%\ProgramData SET PD_VS_PATH=%PD_PATH%\Microsoft\VisualStudio SET PD_PC_PATH=%PD_PATH%\Package Cache @echo =======link directory to %ROOT_PATH%=======: SET S_X86_SKD_PATH=C:\Program Files (x86)\Microsoft SDKs SET S_X86_VS_PATH=C:\Program Files (x86)\Microsoft Visual Studio SET S_X86_KITS_PATH=C:\Program Files (x86)\Windows Kits SET S_X86_AV_PATH=C:\Program Files (x86)\Application Verifier SET S_X64_AV_PATH=C:\Program Files\Application Verifier SET S_X64_SQL_PATH=C:\Program Files\Microsoft SQL Server SET S_PD_VS_PATH=C:\ProgramData\Microsoft\VisualStudio SET S_PD_PC_PATH=C:\ProgramData\Package Cache pause @echo =======setting visual studio environment=======: @echo =======check directory exist=======: if not exist %ROOT_PATH% ( echo "%ROOT_PATH%目录不存在，已创建该目录！" md "%ROOT_PATH%" ) if not exist %X86_PATH% ( echo "%X86_PATH%目录不存在，已创建该目录！" md "%X86_PATH%" ) if not exist %X86_VS_PATH% ( echo "%X86_VS_PATH%目录不存在，已创建该目录！" md "%X86_VS_PATH%" ) if not exist %X86_SDK_PATH% ( echo "%X86_SDK_PATH%目录不存在，已创建该目录！" md "%X86_SDK_PATH%" ) if not exist %X86_KITS_PATH% ( echo "%X86_KITS_PATH%目录不存在，已创建该目录！" md "%X86_KITS_PATH%" ) if not exist %X86_AV_PATH% ( echo "%X86_AV_PATH%目录不存在，已创建该目录！" md "%X86_AV_PATH%" ) if not exist %X64_PATH% ( echo "%X64_PATH%目录不存在，已创建该目录！" md "%X64_PATH%" ) if not exist %X64_AV_PATH% ( echo "%X64_AV_PATH%目录不存在，已创建该目录！" md "%X64_AV_PATH%" ) if not exist %X64_SQL_PATH% ( echo "%X64_SQL_PATH%目录不存在，已创建该目录！" md "%X64_SQL_PATH%" ) if not exist %PD_PATH% ( echo "%PD_PATH%目录不存在，已创建该目录！" md "%PD_PATH%" ) if not exist %PD_VS_PATH% ( echo "%PD_VS_PATH%目录不存在，已创建该目录！" md "%PD_VS_PATH%" ) if not exist %PD_PC_PATH% ( echo "%PD_PC_PATH%目录不存在，已创建该目录！" md "%PD_PC_PATH%" ) @echo =======link directory to %ROOT_PATH%=======: :: x86 link mklink /j "%S_X86_SKD_PATH%" "%X86_SDK_PATH%" mklink /j "%S_X86_VS_PATH%" "%X86_VS_PATH%" mklink /j "%S_X86_KITS_PATH%" "%X86_KITS_PATH%" mklink /j "%S_X86_AV_PATH%" "%X86_AV_PATH%" :: x64 link mklink /j "%S_X64_AV_PATH%" "%X64_AV_PATH%" mklink /j "%S_X64_SQL_PATH%" "%X64_SQL_PATH%" :: ProgramData link mklink /j "%S_PD_VS_PATH%" "%PD_VS_PATH%" mklink /j "%S_PD_PC_PATH%" "%PD_PC_PATH%" pause VS快捷键 快捷键 含义 Ctrl + k,Ctrl + f 自动格式化代码 Ctrl + k,Ctrl + c 注释代码 Ctrl + k,Ctrl + u 取消注释代码 F9 设置断点 F5 调试运行 Ctrl + F5 不调试运行 Ctrl + Shift + b 编译，不运行 F10 next调试 F11 step调试 调试 添加行号：工具–》选项 –》文本编辑器–》C/C++ –》行号...

Principle of token bucket 随着互联网的发展，在处理流量的方法也不仅仅为 first-come，first-served，而在共享网络中实现流量管理的基本机制就是排队。而公平算法则是实现在优先级队列中基于哪些策略来排队的 “公平队列” 。Token Bucket 则是为公平排队提供了替代方案。Fair Queue 与 Token Bucket的区别主要在，对于Fair Queue来讲，如果请求者目前空闲，Queue会将该请求者的带宽分配给其他请求者；而 Token Bucket 则是分配给请求者的带宽是带宽的上限。 通过例子了解算法原理 假设出站带宽是 4个数据包/ms，此时有一个需求为，为一个特定的发送端 A 来分配 1个数据包/ms的带宽。此时可以使用公平排队的方法分给发送 A 25%的带宽。 此时存在的问题是我们希望可以灵活地允许 A 的数据包以无规则的时间间隔发送。例如假设 A 在每个数据包发送后等待1毫秒后再开始下一个数据包的发送。 sence1：此时假设 A 以 1ms 的间隔去发送数据包，而由于某种原因导致应该在 t=6 到达的数据包却在 t=6.5 到达。随后的数据包在 t=7 准时到达，在这种情况下是否应该保留到t=7.5？ sence2：或者是否允许在 t=6.5 发送一个迟到的数据包，在 t=7 发送下一个数据包，此时理论上平均速率仍然还是 1 个数据包/ms？ 显然sence2是合理的，这个场景的解决方法就是令牌桶算法，规定 A 的配额，允许指定平均速率和突发容量。当数据包不符合令牌桶规范，那么就认为其不合理，此时会做出一下相应： delay，直到桶准备好 drop mark，标记为不合规的数据包 delay 被称为 整形 shaping , shaping 是指在某个时间间隔内发送超过 Bc（Committed Burst）的大小，Bc 在这里指桶的尺寸。由于数据流量是突发性的，当在一段时间内不活动后，再次激活后的在一个间隔内发送的数量大于 Bc ，那么额外的流量被称为Be （burst excess）。 将流量丢弃或标记超额流量，保持在一个流量速率限制称为 “管制” policing。...

本文是关于深入理解Kubernetes网络原理系列第4章 深入理解Kubernetes Pod网络原理 - 网络名称空间 深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术 深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理 深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路 概述 本文将简述探讨 Kubernetes 中常见的网络模型，以及对这些网络模型的 route path 进行分析。本章节是作为CNI 原理的前置条件，也为后续的练习提供一些基础知识。...

本文是关于深入理解Kubernetes网络原理系列第4章 深入理解Kubernetes Pod网络原理 - 网络名称空间 深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术 深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理 深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路 Overview 本文将引入一个思路：“在Kubernetes集群发生网络异常时如何排查”。文章将引入Kubernetes 集群中网络排查的思路，包含网络异常模型，常用工具，并且提出一些案例以供学习。 Pod常见网络异常分类 网络排查工具 Pod网络异常排查思路及流程模型 CNI网络异常排查步骤 案例学习 Pod网络异常 网络异常大概分为如下几类：...

Overview 本文将深入讲解 如何扩展 Kubernetes scheduler 中各个扩展点如何使用，与扩展scheduler的原理，这些是作为扩展 scheduler 的所需的知识点。最后会完成一个实验，基于网络流量的调度器。 kubernetes调度配置 kubernetes集群中允许运行多个不同的 scheduler ，也可以为Pod指定不同的调度器进行调度。在一般的Kubernetes调度教程中并没有提到这点，这也就是说，对于亲和性，污点等策略实际上并没有完全的使用kubernetes调度功能，在之前的文章中提到的一些调度插件，如基于端口占用的调度 NodePorts 等策略一般情况下是没有使用到的，本章节就是对这部分内容进行讲解，这也是作为扩展调度器的一个基础。 Scheduler Configuration [1] kube-scheduler 提供了配置文件的资源，作为给 kube-scheduler 的配置文件，启动时通过 --onfig= 来指定文件。目前各个kubernetes版本中使用的 KubeSchedulerConfiguration 为， 1.21 之前版本使用 v1beta1 1.22 版本使用 v1beta2 ，但保留了 v1beta1 1.23, 1.24, 1.25 版本使用 v1beta3 ，但保留了 v1beta2，删除了 v1beta1 下面是一个简单的 kubeSchedulerConfiguration 示例，其中 kubeconfig 与启动参数 --kubeconfig 是相同的功效。而 kubeSchedulerConfiguration 与其他组件的配置文件类似，如 kubeletConfiguration 都是作为服务启动的配置文件。 yaml 1 2 3 4 apiVersion: kubescheduler.config.k8s.io/v1beta1 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig Notes: --kubeconfig 与 --config 是不可以同时指定的，指定了 --config 则其他参数自然失效 [2]...

调度框架 [1] 本文基于 kubernetes 1.24 进行分析 调度框架（Scheduling Framework）是Kubernetes 的调度器 kube-scheduler 设计的的可插拔架构，将插件（调度算法）嵌入到调度上下文的每个扩展点中，并编译为 kube-scheduler 在 kube-scheduler 1.22 之后，在 pkg/scheduler/framework/interface.go 中定义了一个 Plugin 的 interface，这个 interface 作为了所有插件的父级。而每个未调度的 Pod，Kubernetes 调度器会根据一组规则尝试在集群中寻找一个节点。 go 1 2 3 type Plugin interface { Name() string } 下面会对每个算法是如何实现的进行分析 在初始化 scheduler 时，会创建一个 profile，profile是关于 scheduler 调度配置相关的定义 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 func New(client clientset.Interface, ....

Scheduler Scheduler 是整个 kube-scheduler 的一个 structure，提供了 kube-scheduler 运行所需的组件。 go 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 type Scheduler struct { // Cache是一个抽象，会缓存pod的信息，作为scheduler进行查找，操作是基于Pod进行增加 Cache internalcache.Cache // Extenders 算是调度框架中提供的调度插件，会影响kubernetes中的调度策略 Extenders []framework.Extender // NextPod 作为一个函数提供，会阻塞获取下一个ke'diao'du NextPod func() *framework.QueuedPodInfo // Error is called if there is an error. It is passed the pod in // question, and the error Error func(*framework....

Overview [1] kubernetes集群中的调度程序 kube-scheduler 会 watch 未分配节点的新创建的Pod，并未该Pod找到可运行的最佳（特定）节点。那么这些动作或者说这些原理是怎么实现的呢，让我们往下剖析下。 对于新创建的 pod 或其他未调度的 pod来讲，kube-scheduler 选择一个最佳节点供它们运行。但是，Pod 中的每个容器对资源的要求都不同，每个 Pod 也有不同的要求。因此，需要根据具体的调度要求对现有节点进行过滤。 在Kubernetes集群中，满足 Pod 调度要求的节点称为可行节点 （ feasible nodes FN） 。如果没有合适的节点，则 pod 将保持未调度状态，直到调度程序能够放置它。也就是说，当我们创建Pod时，如果长期处于 Pending 状态，这个时候应该看你的集群调度器是否因为某些问题没有合适的节点了 调度器为 Pod 找到 FN 后，然后运行一组函数对 FN 进行评分，并在 FN 中找到得分最高的节点来运行 Pod。 调度策略在决策时需要考虑的因素包括个人和集体资源需求、硬件/软件/策略约束 （constraints）、亲和性 (affinity) 和反亲和性（ anti-affinity ）规范、数据局部性、工作负载间干扰等。 如何为pod选择节点？ kube-scheduler 为pod选择节点会分位两部： 过滤 (Filtering) 打分 (Scoring) 过滤也被称为预选 （Predicates），该步骤会找到可调度的节点集，然后通过是否满足特定资源的请求，例如通过 PodFitsResources 过滤器检查候选节点是否有足够的资源来满足 Pod 资源的请求。这个步骤完成后会得到一个包含合适的节点的列表（通常为多个），如果列表为空，则Pod不可调度。 打分也被称为优选（Priorities），在该步骤中，会对上一个步骤的输出进行打分，Scheduer 通过打分的规则为每个通过 Filtering 步骤的节点计算出一个分数。 完成上述两个步骤之后，kube-scheduler 会将Pod分配给分数最高的 Node，如果存在多个相同分数的节点，会随机选择一个。 kubernetes的调度策略 Kubernetes 1.21之前版本可以在代码 kubernetes\pkg\scheduler\algorithmprovider\registry.go 中看到对应的注册模式，在1.22 scheduler 更换了其路径，对于registry文件更换到了kubernetes\pkg\scheduler\framework\plugins\registry.go ；对于kubernetes官方说法为，调度策略是用于“预选” (Predicates )或 过滤（filtering ） 和 用于 优选（Priorities）或 评分 (scoring)的...

本文是关于Kubernetes 4A解析的第3章 深入理解Kubernetes 4A - Authentication源码解析 深入理解Kubernetes 4A - Authorization源码解析 深入理解Kubernetes 4A - Admission Control源码解析 深入理解Kubernetes 4A - Audit源码解析 TLS Everywhere - 解密kubernetes集群的安全认证 所有关于Kubernetes 4A部分代码上传至仓库 github.com/cylonchau/hello-k8s-4A 如有错别字或理解错误地方请多多担待，代码是以1.24进行整理，实验是以1.19环境进行，差别不大 BACKGROUND admission controllers的特点： 可定制性：准入功能可针对不同的场景进行调整。 可预防性：审计则是为了检测问题，而准入控制器可以预防问题发生 可扩展性：在kubernetes自有的验证机制外，增加了另外的防线，弥补了RBAC仅能对资源提供安全保证。 下图，显示了用户操作资源的流程，可以看出 admission controllers 作用是在通过身份验证资源持久化之前起到拦截作用。在准入控制器的加入会使kubernetes增加了更高级的安全功能。 图：Kubernetes API 请求的请求处理步骤图 Source：https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/ 这里找到一个大佬博客画的图，通过两张图可以很清晰的了解到admission webhook流程，与官方给出的不一样的地方在于，这里清楚地定位了kubernetes admission webhook 处于准入控制中，RBAC之后，push 之前。 图：Kubernetes API 请求的请求处理步骤图（详细） Source：https://www.armosec.io/blog/kubernetes-admission-controller/ 两种控制器有什么区别？ 根据官方提供的说法是 Mutating controllers may modify related objects to the requests they admit; validating controllers may not 从结构图中也可以看出，validating 是在持久化之前，而 Mutating 是在结构验证前，根据这些特性我们可以使用 Mutating 修改这个资源对象内容（如增加验证的信息），在 validating 中验证是否合法。...

各个云厂商都会为自己的服务提供通用可缩放矢量图形 (SVG) 图标，以便用户为自己的软件绘制架构图，例如Microsoft 为Visio 提供 Azure 服务的图标。文本在这里简单整理了几个关于云服务的图标 Azure-Design 提供了大量并完整的azure的一些图标 AWS-Architecture-Icons 提供了一些关于AWS的图标，不过图标为2019年时的 Microsoft-Integration-and-Azure 整合了一些关于微软的图标，并附带了矢量图 更多的图标可以在github或google搜索相关关键词 visio stencil 网络上还是有很多相关的图标库 将图标导入到visio中 为了能使下载的图标在Visio 中可用，只需要简单的一个步骤即可。 将下载下来的图标放置到 C:\Users\<UserName>\Documents\My Shapes 中文系统为 用户目录\文档\我的图形 我的图形需要安装visio后才会有这个文件夹 如图所示： 测试导入后的效果，我们在这里导入了aws与azure的图标库，故可以看到有两个，但是两个中又包含很多，已经足够使用了 最后再附上一个大神制作的 VISIO Protable 版本，匿名网盘，失效不补

Background NGINX 是一个通用且流行的应用程序。也是最流行的 Web 服务器，它可用于提供静态文件内容，但也通常与其他服务一起用作分布式系统中的组件，在其中它用作反向代理、负载均衡 或 API 网关。 分布式追踪 distributed tracing 是一种可用于分析与监控应用程序的机制，将追踪在从源到目的的整个过程中的单个请求，这与仅通过单个应用程序域来追踪请求的形式不同。 换句话说，我们可以说分布式追踪是对跨多个系统的多个请求的拼接。拼接通常由一个或多个相关 ID 完成，并且跟踪通常是一组记录的、跨所有系统的结构化日志事件，存储在一个中心位置。 在这种背景的情况下， OpenTracing 应运而生。OpenTracing 是一个与应用供应商无关的 API，它可帮助开发人员轻松地跟踪单一请求的域。目前有多种开源产品都支持 OpenTracing（例如，Jaeger, skywalking 等），并将其作为一种检测分布式追踪的标准化方法。 本文将围绕，从0到1实现在nginx配置分布式追踪的架构的简单实例说明。本文实例使用的组件为 nginx v1.22 jaeger-all-in-on v1.38 nginx-opentracing v1.22 jaeger-client-cpp v0.9 源码构建nginx-opentracing 准备nginx-opentracing nginx-opentracing 仓库中可以看到，官方为每个nginx版本都提供了一个编译好的动态库（Nginx1.19.13+），我们可以直接拿来使用这个动态库，如果你想将这个利用Nginx 提供的编译参数 --add-module=/path/to/module 构建为nginx的内置功能的话，可能会出现一些问题，例如下面的一些错误： text 1 ngx_http_opentracing_module.so/config was found bash 1 2 3 /root/nginx-opentracing-0.25.0/opentracing//src/ngx_http_opentracing_module.cpp In file included from /root/nginx-opentracing-0.25.0/opentracing//src/ngx_http_opentracing_module.cpp:1:0: /root/nginx-opentracing-0.25.0/opentracing//src/load_tracer.h:3:38: fatal error: opentracing/dynamic_load.h: No such file or directory 根据 issue 中查询得知 nginx-opentracing 需要嵌入到nginx中，是需要一些 opentracing-cpp 因为对c++不熟，尝试调试很久还是上面的错误，故直接使用了官方提供的动态库。...

Backgroud 前一章中，对kubernetes的选举原理进行了深度剖析，下面就通过一个example来实现一个，利用kubernetes提供的选举机制完成的高可用应用。 对于此章需要提前对一些概念有所了解后才可以继续看下去 leader election mechanism RBCA Pod runtime mechanism Implementation 代码实现 如果仅仅是使用Kubernetes中的锁，实现的代码也只有几行而已。 go 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 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 package main import ( "context" "flag" "fmt" "os" "os/signal" "syscall" "time" metav1 "k8s....

Overview 在 Kubernetes的 kube-controller-manager , kube-scheduler, 以及使用 Operator 的底层实现 controller-rumtime 都支持高可用系统中的leader选举，本文将以理解 controller-rumtime （底层的实现是 client-go） 中的leader选举以在kubernetes controller中是如何实现的。 Background 在运行 kube-controller-manager 时，是有一些参数提供给cm进行leader选举使用的，可以参考官方文档提供的 参数 来了解相关参数。 bash 1 2 3 4 5 6 7 --leader-elect Default: true --leader-elect-renew-deadline duration Default: 10s --leader-elect-resource-lock string Default: "leases" --leader-elect-resource-name string Default: "kube-controller-manager" --leader-elect-resource-namespace string Default: "kube-system" --leader-elect-retry-period duration Default: 2s ... 本身以为这些组件的选举动作时通过etcd进行的，但是后面对 controller-runtime 学习时，发现并没有配置其相关的etcd相关参数，这就引起了对选举机制的好奇。怀着这种好奇心搜索了下有关于 kubernetes的选举，发现官网是这么介绍的，下面是对官方的说明进行一个通俗总结。simple leader election with kubernetes 通过阅读文章得知，kubernetes API 提供了一中选举机制，只要运行在集群内的容器，都是可以实现选举功能的。 Kubernetes API通过提供了两个属性来完成选举动作的 ResourceVersions：每个API对象唯一一个ResourceVersion Annotations：每个API对象都可以对这些key进行注释 注：这种选举会增加APIServer的压力。也就对etcd会产生影响...

Overview controller-runtime 是 Kubernetes 社区提供可供快速搭建一套 实现了controller 功能的工具，无需自行实现Controller的功能了；在 Kubebuilder 与 Operator SDK 也是使用 controller-runtime 。本文将对 controller-runtime 的工作原理以及在不同场景下的使用方式进行简要的总结和介绍。 controller-runtime structure controller-runtime 主要组成是需要用户创建的 Manager 和 Reconciler 以及 Controller Runtime 自己启动的 Cache 和 Controller 。 Manager：是用户在初始化时创建的，用于启动 Controller Runtime 组件 Reconciler：是用户需要提供来处理自己的业务逻辑的组件（即在通过 code-generator 生成的api-like而实现的controller中的业务处理部分）。 Cache：一个缓存，用来建立 Informer 到 ApiServer 的连接来监听资源并将被监听的对象推送到queue中。 Controller： 一方面向 Informer 注册 eventHandler，另一方面从队列中获取数据。controller 将从队列中获取数据并执行用户自定义的 Reconciler 功能。 图：controller-runtime structure 图：controller-runtime flowchart 由图可知，Controller会向 Informer 注册一些列eventHandler；然后Cache启动Informer（informer属于cache包中），与ApiServer建立监听；当Informer检测到资源变化时，将对象加入queue，Controller 将元素取出并在用户端执行 Reconciler。 Controller引入 我们从 controller-rumtime项目的 example 进行引入看下，整个架构都是如何实现的。 可以看到 example 下的实际上实现了一个 reconciler 的结构体，实现了 Reconciler 抽象和 Client 结构体...

Overview What is Kubernetes aggregation Kubernetes apiserver aggregation AA 是Kubernetes提供的一种扩展API的方法，目前并没有GA Difference between CRD and AA 众所周知，kubernetes扩展API的方法大概为三种：CRD、AA、手动扩展源码。根据CNCF分享中Min Kim说的AA更关注于实践，而用户无需了解底层的原理，这里使用过 kubebuilder， code-generator 的用户是很能体会到这点。官方也给出了CRD与AA的区别 API Access Control Authentication CR: All strategies supported. Configured by root apiserver. AA: Supporting all root apiserver’s authenticating strategies but it has to be done via authentication token review api except for authentication proxy which will cause an extra cost of network RTT. Authorization CR: All strategies supported. Configured by root apiserver....

Overview 根据Kuberneter文档对Controller的描述，Controller在kubernetes中是负责协调的组件，根据设计模式可知，controller会不断的你的对象（如Pod）从当前状态与期望状态同步的一个过程。当然Controller会监听你的实际状态与期望状态。 Writing Controllers go 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 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 package main import ( "flag" "fmt" "os" "time" v1 "k8s....

Overview Kubernetes中提供了多种自定义控制器的方式： code-generator kubebuilder Operator Controller 作为CRD的核心，这里将解释如何使用 code-generator 来创建自定义的控制器，作为文章的案例，将完成一个 Firewalld Port 规则的控制器作为描述，通过 Kubernetes 规则来生成对应节点上的 iptables规则。 Prerequisites CRD yaml 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 apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: ports.firewalld.fedoraproject.org spec: group: firewalld.fedoraproject.org scope: Namespaced names: plural: ports singular: port kind: PortRule shortNames: - fp versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: name: type: string port: type: integer host: type: string isPermanent: type: boolean code-generator 需要预先下载 code-generator 。因为这个工具不是必需要求的。...

Kubernetes的主节点或控制面板当中主要有三个组件，其中apiserver是整个系统的数据库，借助于Cluster Store（etcd）服务，来实现所有的包括用户所期望状态的定义，以及集群上资源当前状态的实时记录等。 etcd是分布式通用的K/V系统 KV Store ，可存储用户所定义的任何由KV Store所支持的可持久化的数据。它不仅仅被apiserver所使用，如flannel、calico二者也需要以etcd来保存当前应用程序对应的存储数据。 任何一个分布式应用程序几乎都会用到一个高可用的存储系统。 apiserver将etcd所提供的存储接口做了高度抽象，使用户通过apiserver来完成数据存取时，只能使用apiserver中所内建支持的数据范式。在某种情况之下，我们所期望管理的资源或存储对象在现有的Kubernetes资源无法满足需求时。 Operator本身是建构在StatefulSet以及本身的基本Kubernetes资源之上，由开发者自定义的更高级的、更抽象的自定义资源类型。他可借助于底层的Pod、Service功能，再次抽象出新资源类型。更重要的是，整个集群本身可抽象成一个单一资源。 为了实现更高级的资源管理，需要利用已有的基础资源类型，做一个更高级的抽象，来定义成更能符合用户所需要的、可单一管理的资源类型，而无需去分别管理每一个资源。 在Kubernetes之上自定义资源一般被称为扩展Kubernetes所支持的资源类型， 自定义资源类型 CRD Custom Resource Definition 自定义apiserver 修改APIServer源代码，改动内部的资源类型定义 CRD是kubernetes内建的资源类型，从而使得用户可以定义的不是具体的资源，而是资源类型，也是扩展Kubernetes最简单的方式。 Intorduction CRD 什么是CRD 在 Kubernetes API 中，resources 是存储 API 对象集合的endpoint。例如，内置 Pod resource 包含 Pod 对象的集合。当我们想扩展API，原生的Kubernetes就不能满足我们的需求了，这时 CRD (CustomResourceDefinition) 就出现了。在 Kubernetes 中创建了 CRD 后，就可以像使用任何其他原生 Kubernetes 对象一样使用它，从而利用 Kubernetes 的所有功能、如安全性、API 服务、RBAC 等。 Kubernetes 1.7 之后增加了对 CRD 自定义资源二次开发能力来扩展 Kubernetes API，通过 CRD 我们可以向 Kubernetes API 中增加新资源类型，而不需要修改 Kubernetes 源码来创建自定义的 API server，该功能大大提高了 Kubernetes 的扩展能力。 创建 CRD 前提条件： Kubernetes 服务器版本必须不低于版本 1....

OSI Model OSI 七层网络模型如下（由下到上）： 应用层 Application layer ：直接接触用户数据的层。软件应用程序依靠应用层发起通信。这里的应用值得是协议而不是客户端软件；应用层协议包括 HTTP, SMTP, FTP, DNS,Telnet, etc.. 表示层 Presentation layer：表示层充当角色为网络数据转换器，负责完成数据转换，加密和压缩 会话层 Session layer：负责建立、管理和终止两个设备之间的通信 传输层 Transport layer：负责两个设备间的端到端通信。包括从会话层提取数据，将数据分解为多个区块（称为数据段）；传输层协议包括，TCP, UDP 网络层 Network layer：负责管理网络地址，定位设备，决定路由，通俗来讲是负责*“不同”*网络之间的传输，也就是路由功能；网络层协议包括 IP,ARP,ICMP；代表设备 3 layer swtich, router, firewall。相应就代表对应网络协议也是三层的，如RIP, OSPF, BGP 数据链路层 Data link layer：数据链路层负责*“同一”*网络上设备之间的数据传输；该层协议包括 Ethernet, PPP(Point-to-Point Protocol)；代表设备 Switch,Bridges，同样的MAC地址也是该层的 物理层 Physical layer：该层表示参与数据传输的物理设备，如网线，同时还负责将数据转换为位流，也就是由 1 和 0 构成的字符串。 图：OSI七层模型 Source：https://www.cloudflare.com/zh-cn/learning/ddos/glossary/open-systems-interconnection-model-osi/ MAC MAC地址介绍 MAC (Media Access Control) 地址用来定义网络设备的位置，由48比特长，12位的16进制组成，其中从左到右，0-23bit为厂商想IETF等机构申请用来标识厂商的代码OUI Organizationally-Unique Identifier，24-47bit由厂商自行分配，是厂商制造所有网卡的唯一编号。如00-50-56-C0-00-08 MAC地址类型 MAC地址分为三种类型： 物理MAC地址：Mac地址唯一的标识了以太网的一个终端，该地址为全球唯一的硬件地址。 广播(broadcast) MAC地址：每个比特都是 1 的 MAC 地址。广播 MAC 地址是组播 MAC 地址的一个特例。11111111-11111111-11111111-11111111-11111111-11111111 16进制表示为 FF-FF-FF-FF-FF-FF。 组播(multicast) MAC地址：第一个字节的最低位是 1 的 MAC 地址。二进制表示为 xxxxxxx1-xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx ；16进制表示为01-00-00-00-00-00。如 a5-a9-a6-aa-5a-a6 这个mac地址的第一个字节的最低位 16进制a5 转换为二进制为10100101 最后一位为1就是组播MAC地址。 单播 (unicast) MAC 地址：第一个字节的最低位是 0 的 MAC 地址 xxxxxxx0-xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx。 静态MAC地址 由用户通过命令配置的静态转发的MAC地址，静态MAC地址和动态MAC地址的功能不同，静态地址一旦被加入，该地址在删除之前将一直有效，不受最大老化时间的限制...

通用队列 在kubernetes中，使用go的channel无法满足kubernetes的应用场景，如延迟、限速等；在kubernetes中存在三种队列通用队列 common queue ，延迟队列 delaying queue，和限速队列 rate limiters queue Inferface Interface作为所有队列的一个抽象定义 go 1 2 3 4 5 6 7 8 type Interface interface { Add(item interface{}) Len() int Get() (item interface{}, shutdown bool) Done(item interface{}) ShutDown() ShuttingDown() bool } Implementation go 1 2 3 4 5 6 7 8 9 10 11 12 13 type Type struct { // 一个work queue queue []t // queue用slice做存储 dirty set // 脏位，定义了需要处理的元素，类似于操作系统，表示已修改但为写入 processing set // 当前正在处理的元素集合 cond *sync....