叮当猫的喵i

下面的分析是k8s通过ceph-csi（csi plugin）接入ceph存储（csi相关组件的分析以rbd为例进行分析），对csi系统结构、所涉及的k8s对象与组件进行了简单的介绍，以及k8s对存储进行相关操作的流程分析，存储相关操作包括了存储创建、存储扩容、存储挂载、解除存储挂载以及存储删除操作。CSI是Container Storage Interface（容器存储接口）的简写。

/ +kubebuilder:object:root=true 标记这是一个根对象，这个类型直接对应于一个 Kubernetes API 资源，而不是嵌套在其他资源中的子资源。// +kubebuilder:resource:shortName=cj2 执行该类型的缩写为 cj2// +kubebuilder:subresource:status 为该类型生成个 status 子资源// 用户自定义 crd。

之后「源 VTEP 设备」 —— 会将此「 Vxlan 数据包」进行「UDP封装」,其中「 Vxlan 数据包」会视为「UDP数据包的基础数据信息」通过「目的 Pod IP」—— 得知「目的 VTEP 设备的 MAC 地址」 —— 「源 VTEP 设备」根据得到的信息构建 Vxlan 数据包。”二层“通信 —— 指的是，需要维护「MAC 地址级别的信息」，即「虚拟IP」与「MAC 地址」的映射关系。之后此封装好的「UDP数据包」，将会通过三层网络，到达目的容器所在的主机的「目的VTEP设备」......

比如，PodFitsHost 算法（负责的是，检查 Pod 的 nodeSelector 与 Node 的名字是否匹配），这种情况下，除非 Node 的名字发生变化，否则你即使删除再多的 Pod，抢占者也不可能调度成功。具体来说，在为某一对 Pod 和 Node 执行 Predicates 算法的时候，如果待检查的 Node 是一个即将被抢占的节点，即：调度队列里有 nominatedNodeName 字段值是该 Node 名字的 Pod 存在（可以称之为：“潜在的抢占者”）。

serviceaccount的权限由集群中对应的rolebinding决定，官方文档:

注意此处，若没有 KubeSchedulerConfiguration 的声明配置，k8s 会认为这些（nvidia.com/gpumem、nvidia.com/gpucores）是资源设备，k8s 调度时候会进行寻找，发现所有节点上都没此资源设备配额（kubectl describe node nodeName 可以看到每个 node 的设备资源情况），导致该 pod 调度失败。首先创建个 device-plugin，注册 gpu 资源（nvidia.com/gpu）

组件，各种操作系统的安装方式见https://www.graphviz.org/download/#linux。UI分析工具使用起来相对比较麻烦，我们需要先导出文件，然后再使用。比如我们导出kube-scheduler的堆栈信息。然后就可以在浏览器上看到具体的堆栈信息图了。注意，这里需要在服务端安装。工具起服务进行分析。

从设计上三队列分别存储：活动队列、bakcoff队列、不可调度队列，其中backoff中会根据任务的失败来逐步递增重试时间(最长10s)、unschedulableQ队列则延迟60s通过后台定时任务分别将backoffQ队列、unschedulableQ队列来进行重试，加入到activeQ中，从而加快完成pod的失败重试调度。

scheduler extender是k8s对调度器的一种扩展机制，我们可以定义对应的extender,在对应资源的调度的时候，k8s会检查对应的资源，如果发现需要调用外部的extender,则将当前的调度数据发送给extender,然后汇总调度数据，决定最终的调度结果。当从apiserver感知到要调度的pod的时候,scheduler会根据pod的优先级，来讲其加入到内部的一个优先级队列中，后续调度的时候，会先获取优先级比较高的pod来进行优先满足调度。

的主要功能为：当某个node被打上NoExecute污点后，其上面的pod如果不能容忍该污点，则将会驱逐这些pod，而新建的pod也需要容忍该污点才能调度到该node上；通过kcm启动参数来确定是否启动true时启动（启动参数默认值为truekcm启动参数，默认值true，配合共同作用，两者均为true，才会开启污点驱逐；的主要功能为：当某个node被打上NoExecute污点后，其上面的pod如果不能容忍该污点，则将会驱逐这些pod，而新建的pod也需要容忍该污点才能调度到该node上；

kube-controller-manager驱逐主要依靠以及其中的；

go复制代码// Controller is the controller that manages node's life cycle.// taintManager监听节点的Taint/Toleration变化，用于驱逐pod// 监听pod// 返回secondary-node-eviction-rate参数值。就是根据集群是否为大集群，如果是大集群，返回secondary-node-eviction-rate,否则返回0// 返回evictionLimiterQPS参数。

检查节点是否拥有 Pod 请求的所有资源。：检查 Pod 指定的节点名称与当前节点是否匹配。：调度 Pod 时，选择资源使用更为均衡的节点。：检查挂载到节点上的卷是否满足卷提供程序的限制。：检查节点是否有请求的卷，或是否可以绑定请求的。：检查 Pod 请求的端口在节点上是否可用。：检查节点是否满足 AWS EBS 卷限制。：检查该节点是否满足 GCP-PD 卷限制。：检查该节点是否满足 Azure 卷限制。：检查该节点是否满足 CSI 卷限制。：检查请求的卷是否在任何区域都满足。

方法 https://github.com/containerd/containerd/blob/v1.4.3/runtime/v2/runc/v2/service.go#L174-L286。结合源码 https://github.com/containerd/containerd/blob/v1.4.3/runtime/v2/shim/shim.go#L221-L229。可以看出，containerd是containerd-shim的父进程，contaienrd-shim是容器进程的父进程。

问题 —— 为什么不梳理 【现存哪些 Pod】 喜欢【新 Pod】？这部分就是，将节点的得分进行累计计算，返回此符合条件的节点的得分数。这部分主要看 processExistingPod 函数。—— 因此才考虑这么详细。

这里的 topologyKey 对应的是 Node 上的标签的 Key（没有Value），可以看出，其实 topologyKey 就是用于筛选 Node 的。这里指定“同一位置” 是通过 topologyKey 来定义的，topologyKey 对应的值是 node 上的一个标签名称，比如各别节点zone=A标签，各别节点有zone=B标签，pod affinity topologyKey定义为zone，那么调度pod的时候就会围绕着A拓扑，B拓扑来调度，而相同拓扑下的node就为“同一位置”。

尽可能地将 workload 平均到不同的节点，减少单个节点宕机造成的损失可扩展性。随着集群规模的增加，怎么保证调度器不会成为性能的瓶颈高可用。调度器能做组成集群，任何一个调度器出现问题，不会影响整个集群的调度灵活性。不同的用户有不同的调度需求，一个优秀的调度器还要允许用户能配置不同的调度算法资源合理和高效利用。调度器应该尽可能地提高集群的资源利用率，防止资源的浪费一般来说，我们有4种扩展 Kubernetes 调度器的方法。

如果我们要实现自己的插件，必须向调度框架注册插件并完成配置，另外还必须实现扩展点接口，对应的扩展点接口我们可以在源码。

为了检索的需要添加了 BIN（二进制数据）、CIS（忽略大小写）、CES（大小写敏感）、TEL（电话型）等语法（Syntax）。但目录一般只执行简单的更新（写）操作，不支持批量更新所需要的事务处理功能；可以把Dex当作一个轻量级的认证的代理入口（portal），应用APP只需要通过与Dex交互，由Dex负责与后端的上游认证服务器交互，从而屏蔽了后端认证服务器的协议差异。目录信息树可以类比我们的**「磁盘文件系统目录树」**，上面的定义是官方定义，理解起来，DIT 就是指像文件系统一样的目录结构树。

OIDC 协议定义的名词和 OAuth 2.0 协议定义的稍微有些出入：OpenID Provider ，简称 OP ：相当于 OAuth 2.0 中的授权服务器，除了负责颁发 Access Token ，还会颁发 ID Token。例如 IDaaS 就是一个 OP。Relying Party ，简称 RP ：代指 OAuth 2.0 中的客户端。End User ，简称 EU ：即用户。最后， OIDC 的授权流程与 OAuth 2.0 是一样的，

几个月前，在我的博客如何在 Kubernetes 集群中利用 GPU 进行 AI 训练对 Kubernetes 1.8 如何使用 GPU 进行了分析，在 Kubernetes 1.10 中，已经推荐使用 Device Plugins 来使用 GPU 了。本文分析了 Device Plugin 的的原理和工作机制，介绍了 Extended Resource，Nvidia Device Plugin 的异常处理及改进点，如何使用和调度 GPU 等。下一篇篇博客，我将对。

可以实现 SA 具有操作别的 namespace 中资源的权限（例如 SA 在 ns1, Role 在 ns2，SA 可操作 ns2 资源）SA 通过 ClusterRoleBinding 绑定 ClusterRole，具有 ClusterRole 权限，可操作。SA 通过 RoleBinding 绑定 Role ，具有 Role 权限，只能操作。没有 ClusterRoleBinding 与 Role 的 组合。绑定 ClusterRole, 具有。

在使用openssl创建证书时，遵循的步骤是 创建秘钥 > 创建CA > 生成要颁发证书的秘钥 > 使用CA签发证书。不管是根证书，中级证书还是终端域名证书，都需要先生成一个私钥，然后通过私钥来获取公钥再进行证书签名，OpenSSL 可以通过。这样我们就配置好了三级证书的签名请求了，这里都是分开写的，大部分代码都是一样的，可以写成一个方法，这里就不扩展了。如上，我们完成了证书的生成、存储和读取等能力，证书相关的处理就结束了。，用来区分这是一个根证书，过期时间设置为十年，根证书十年足够了，

前面我们只创建了 ServiceAccount，并赋予了权限，但是我们创建 Deployment 时，若没有携带这个 ServiceAccount，就会采用默认的 default ServiceAccount，导致没有权限创建（同时花费时间排错）

若在 webhook 目录的 main.go 函数中引用 pkg 目录中的 webhook.go 中的函数，该怎么应用呢？答：go mod 名 + 目录名。

【代码】【k8s admission 学习】解决 k8s 依赖问题（k8s.io/kubernetes拉取不到）

ServiceAccount 挂载到 pod 后，一般会在/var/run/secrets/kubernetes.io/serviceaccount路径下（kubectl describe pod podname 会看到具体的挂载路径）实际上k8s中也有一个默认的serviceAccount：default，同样挂载在pod中的上述路径下，只是这个默认的serviceAccount权限很小，所以才会需要创建自定义的serviceAccount。如上：我们要操作pod资源，就要创建如下资源。

【代码】【k8s admission学习】镜像多阶段构建。

这两个资源会在 pod 、 deployment、service 创建时校验，若不删除，会影响这些资源的创建。通过 WHITELIST_REGISTRIES 指定镜像白名单的配置。校验镜像的来源是否是白名单内，不在白名单内就阻断 pod 创建。目前在 webhook 中实现的逻辑是。

以实际环境的 kubeconfig 为例进行分析，主要包含以下几部分信息三大部分clusters用于集群认证Server 字段： 存储集群的地址证书路径（）或证书内容（）可以有多个 cluster 集群users用于用户认证存储用户的证书、密钥（两种形式，路径或内容）证书形式client-certificate: /etc/kubernetes/ssl/cs_client.crtclient-key: /etc/kubernetes/ss

client-go 库访问k8s 内置资源的sdk，最常用的就是 clientSet。底层通过 http 请求访问k8s 的 api-server，从etcd获取资源信息。api 库提供了k8s的内置资源，以及注册到 Scheme 的接口，这些资源比如：Pod、Service、Deployment、Namespace。apimachinery提供k8s最核心的数据结构。，里面有一张详细的源码调用关系图。

command、args两项实现覆盖Dockerfile中ENTRYPOINT的功能,具体的command命令代替ENTRYPOINT的命令行，args代表集体的参数。非交互模式如下图所示，非交互模式就是调用 bash 解释器，通过 bash -c 后接命令的形式来解释执行命令。exec 模式是建议的使用模式，因为当运行任务的进程作为容器中的 1 号进程时，我们可以通过。[/bin/sh -c 的作用](/bin/sh -c 的作用)CMD 指令的目的是：为容器提供默认的执行命令。的方式执行任务命令。

使用 busybox 容器，其解析器的库可能无法解析 nodelocaldns 或 coredns 返回的结果（可能是 ipv6 部分，或是库不全 glibc 等，不清楚具体原因），因此导致时好时坏（有时可以解析，有时候解析不成功）在宿主机上直接进行测试，通过下面可以看到（nslookup 指定了 dns 解析地址），coredns 或 nodelocaldns 都可以进行解析。：在端口 8181 上提供的一个 HTTP 末端，当所有能够 表达自身就绪的插件都已就绪时，在此末端返回 200 OK。...

删除了 nodelocaldns 和 coredns 的 loop 插件。添加 iptables 规则，重启 coredns。

ndots:5，表示：如果查询的域名包含的点“.”，不到5个，那么进行DNS查找，将使用非完全限定名称（或者叫绝对域名），如果你查询的域名包含点数大于等于5，那么DNS查询，默认会使用绝对域名进行查询。对于使用 NodeLocalDNS 的用户一定要注意这个问题，如果使用 hosts 或者 rewrite 插件失效，基本上就是这个问题造成的。走完了search域还找不到，则使用 a.b.c.d.e. ，作为绝对域名进行DNS查找。那么我们就只有去 CoreDNS 解析了，所以这个时候我们需要把。......

注意：nslookup命令的最后指定DNS服务容器的IP，是因为，如果不指定，且DNS服务的容器存在多个的话，那么DNS请求，可能会均分到所有DNS服务的容器上，我们如果只抓某单个DNS服务容器抓到的包，可能就不全了，指定IP后，DNS的请求，就必然只会打到单个的DNS容器。ndots:5，表示：如果查询的域名包含的点“.”，不到5个，那么进行DNS查找，将使用非完全限定名称（或者叫绝对域名），如果你查询的域名包含点数大于等于5，那么DNS查询，默认会使用绝对域名进行查询。...

1.kube-proxy主要是处理集群外部通过nodePort访问集群内服务，通过iptables规则，解析cluterIP到PodIp的过程，并提供服务的负载均衡能力。2.kube-proxy还可以提供集群内部服务间通过clusterIP访问，也会经过kube-proxy负责转发。3.kube-dns主要处Pod内通过serviceName访问其他服务，找到服务对应的clusterIP的关系，和一些基本的域名解析功能。...

Infomer 中的 controller —— 源码的架构相当于 Informer 中的总管家，协调着各个组件的关系利用 Informer 传入的信息（DeltaFIFO、ListAndWatch 函数、handler回调函数等），将其他们形成 Reflector 组件、DeltaFIFO 组件、handler 等组件，组合成一个【执行框架】，处理事件的同时，还要保障更新【索引】和【缓存】简言之，就是 Informer 运行之根本（称之为运行逻辑结构）......

接着，启动 processLoop 不断从 DeltaFIFO Pop 进行消费。通过上面的 Reflector 分析可以知道，DeltaFIFO 的职责是通过队列加锁处理(queueActionLocked)、去重(dedupDeltas)、存储在由 DeltaFIFO 实现的本地缓存(local Store) 中，包括 queue(仅存 objKeys) 和 items(存 objKeys 和对应的 Deltas 增量变化)，并通过 Pop 不断消费，通过 Process(item) 处理相关逻辑。..

但是一个资源可能会有「多个 Informer 实例」监听着，而且「每个 Informer 的处理逻辑都不是一致的（AddFunc、DeleteFunc、UpdateFunc）」,因此如何通知这些 Informer 处理呢？其实他们共享着 —— 【Refactor】【Indexer】【Local Store】 —— 为了减少 Apiserver 的访问压力，及节约存储（因为都是关注着一种资源）【资源变化的事件 Delta】很多时，【processorListener】处理不过来怎么办？分发函数，而是为什么。.