![](https://img-blog.csdnimg.cn/20201014180756754.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
深入剖析 Kubernetes
文章平均质量分 92
深入剖析 Kubernetes
_Rye_
左手代码右手诗
一行代码一行诗
展开
-
52 | 答疑:在问题中解决问题,在思考中产生思考
这使得后期大量的低价值或者周边型的项目不断冲进 OpenStack 社区,大大降低了社区的含金量,并且分散了大量的社区精力在这些价值相对不高的项目上,从而拖慢并干扰了比如 Cinder、Neutron 等核心项目的演进步伐和方向,最终使得整个社区在容器的热潮下难以掉头,不可避免地走向了下滑的态势。在第 35 篇文章的正文里,已经讲解过,隧道模式最大的特点,在于需要通过某种方式比如 UDP 或者 VXLAN 来对原始的容器间通信的网络包进行封装,然后伪装成宿主机间的网络通信来完成容器跨主通信。原创 2023-11-22 14:18:03 · 77 阅读 · 0 评论 -
51 | 谈谈Kubernetes开源社区和未来走向
在本篇文章里,详细讲述了 CNCF 和 Kubernetes 社区的关系,以及 Kubernetes 社区的运作方式,希望能够帮助你更好地理解这个社区的特点和它的先进之处。除此之外,你可能还听说过 Kubernetes 社区里有一个叫作 Kubernetes Steering Committee 的组织。这个组织,其实也是属于Kubernetes Community 库的一部分。原创 2023-11-22 10:49:11 · 70 阅读 · 0 评论 -
50 | 让日志无处可逃:容器日志收集与管理
在本篇文章中,详细讲解了 Kubernetes 项目对容器应用日志的收集方式。综合对比以上三种方案,比较建议将应用日志输出到 stdout 和 stderr,然后通过在宿主机上部署 logging-agent 的方式来集中处理日志。这种方案不仅管理简单,kubectl logs 也可以用,而且可靠性高,并且宿主机本身,很可能就自带了 rsyslogd 等非常成熟的日志收集组件来供你使用。原创 2023-11-22 10:04:35 · 106 阅读 · 0 评论 -
49 | Custom Metrics: 让Auto Scaling不再“食之无味”
在本篇文章中,详细讲解了 Kubernetes 里对自定义监控指标,即 Custom Metrics 的设计与实现机制。这套机制的可扩展性非常强,也终于使得 Auto Scaling 在 Kubernetes 里面不再是一个“食之无味”的鸡肋功能了。另外可以看到,Kubernetes 的 Aggregator APIServer,是一个非常行之有效的 API 扩展机制。而且,Kubernetes 社区已经为你提供了一套叫作。原创 2023-11-22 09:06:09 · 91 阅读 · 0 评论 -
48 | Prometheus、Metrics Server与Kubernetes监控体系
在本篇文章中,主要介绍了 Kubernetes 当前监控体系的设计,介绍了 Prometheus 项目在这套体系中的地位,讲解了以 Prometheus 为核心的监控系统的架构设计。然后,详细地解读了 Kubernetes 核心监控数据的来源,即:Metrics Server 的具体工作原理,以及 Aggregator APIServer 的设计思路。原创 2023-11-21 23:48:04 · 245 阅读 · 0 评论 -
47 | 绝不仅仅是安全:Kata Containers 与 gVisor
在本篇文章中,详细地介绍了拥有独立内核的安全容器项目,对比了 KataContainers 和 gVisor 的设计与实现细节。在性能上,KataContainers 和 KVM 实现的 gVisor 基本不分伯仲,在启动速度和占用资源上,基于用户态内核的 gVisor 还略胜一筹。但是,对于系统调用密集的应用,比如重 I/O 或者重网络的应用,gVisor 就会因为需要频繁拦截系统调用而出现性能急剧下降的情况。原创 2023-11-21 23:14:17 · 268 阅读 · 0 评论 -
46 | 解读 CRI 与 容器运行时
在本篇文章中,详细解读了 CRI 的设计和具体工作原理,并梳理了实现 CRI 接口的核心流程。从这些讲解中不难看出,CRI 这个接口的设计,实际上还是比较宽松的。这就意味着,作为容器项目的维护者,我在实现 CRI 的具体接口时,往往拥有着很高的自由度,这个自由度不仅包括了容器的生命周期管理,也包括了如何将 Pod 映射成为我自己的实现,还包括了如何调用 CNI 插件来为 Pod 设置网络的过程。原创 2023-11-21 22:04:40 · 87 阅读 · 0 评论 -
45 | 幕后英雄:SIG-Node与CRI
在本篇文章中,首先介绍了 SIG-Node 的职责,以及 kubelet 这个组件的工作原理。接下来,重点讲解了 kubelet 究竟是如何将 Kubernetes 对应用的定义,一步步转换成最终对 Docker 或者其他容器项目的 API 请求的。不难看到,在这个过程中,kubelet 的 SyncLoop 和 CRI 的设计,是其中最重要的两个关键点。也正是基于以上设计,SyncLoop 本身就要求这个控制循环是绝对不可以被阻塞的。原创 2023-11-21 18:28:49 · 42 阅读 · 0 评论 -
44 | Kubernetes GPU管理与Device Plugin机制
在本篇文章中,详细讲述了 Kubernetes 对 GPU 的管理方式,以及它所需要使用的 Device Plugin 机制。需要指出的是,Device Plugin 的设计,长期以来都是以 Google Cloud 的用户需求为主导的,所以,它的整套工作机制和流程上,实际上跟学术界和工业界的真实场景还有着不小的差异。这里最大的问题在于,GPU 等硬件设备的调度工作,实际上是由 kubelet 完成的。原创 2023-11-21 18:01:01 · 425 阅读 · 1 评论 -
43 | Kubernetes默认调度器的优先级与抢占机制
在本篇文章中,详细讲述了 Kubernetes 里关于 Pod 的优先级和抢占机制的设计与实现。这个特性在 v1.11 之后已经是 Beta 了,意味着比较稳定了。所以,建议在 Kubernetes 集群中开启这两个特性,以便实现更高的资源使用率。原创 2023-11-21 17:20:31 · 64 阅读 · 0 评论 -
42 | Kubernetes默认调度器调度策略解析
在本篇文章中,讲述了 Kubernetes 默认调度器里的主要调度算法。需要注意的是,除了本篇讲述的这些规则,Kubernetes 调度器里其实还有一些默认不会开启的策略。可以通过为 kube-scheduler 指定一个配置文件或者创建一个 ConfigMap ,来配置哪些规则需要开启、哪些规则需要关闭。并且,可以通过为 Priorities 设置权重,来控制调度器的调度行为。原创 2023-11-21 16:47:08 · 64 阅读 · 0 评论 -
41 | 十字路口上的Kubernetes默认调度器
在本篇文章中,详细讲解了 Kubernetes 里默认调度器的设计与实现,分析了它现在正在经历的重构,以及未来的走向。不难看到,在 Kubernetes 的整体架构中,kube-scheduler 的责任虽然重大,但其实它却是在社区里最少受到关注的组件之一。这里的原因也很简单,调度这个事情,在不同的公司和团队里的实际需求一定是大相径庭的,上游社区不可能提供一个大而全的方案出来。所以,将默认调度器进一步做轻做薄,并且插件化,才是 kube-scheduler 正确的演进方向。原创 2023-11-21 15:46:05 · 39 阅读 · 0 评论 -
40 | Kubernetes的资源模型与资源管理
在本篇文章中,详细讲解了 Kubernetes 里对资源的定义方式和资源模型的设计。然后,我为你讲述了 Kubernetes 里对 Pod 进行 Eviction 的具体策略和实践方式。正是基于上述讲述,在实际的使用中,强烈建议将 DaemonSet 的 Pod 都设置为 Guaranteed 的 QoS 类型。否则,一旦 DaemonSet 的 Pod 被回收,它又会立即在原宿主机上被重建出来,这就使得前面资源回收的动作,完全没有意义了。原创 2023-11-21 14:54:17 · 55 阅读 · 0 评论 -
39 | 谈谈Service与Ingress
在这篇文章里,详细讲解了 Ingress 这个概念在 Kubernetes 里到底是怎么一回事儿。正如在文章里所描述的,Ingress 实际上就是 Kubernetes 对“反向代理”的抽象。目前,Ingress 只能工作在七层,而 Service 只能工作在四层。所以当你想要在 Kubernetes 里为应用进行 TLS 配置等 HTTP 相关的操作时,都必须通过 Ingress 来进行。原创 2023-11-21 14:10:02 · 74 阅读 · 0 评论 -
38 | 从外界连通Service与Service调试“三板斧”
在本篇文章中,详细讲解了从外部访问 Service 的三种方式(NodePort、LoadBalancer 和 External Name)和具体的工作原理。然后,我还为你讲述了当 Service 出现故障的时候,如何根据它的工作原理,按照一定的思路去定位问题的可行之道。通过上述讲解不难看出,所谓 Service,其实就是 Kubernetes 为 Pod 分配的、固定的、基于 iptables(或者 IPVS)的访问入口。原创 2023-11-21 11:57:08 · 57 阅读 · 0 评论 -
37 | 找到容器不容易:Service、DNS与服务发现
在这篇文章里,详细讲解了 Service 的工作原理。实际上,Service 机制,以及 Kubernetes 里的 DNS 插件,都是在帮助你解决同样一个问题,即:如何找到我的某一个容器?这个问题在平台级项目中,往往就被称作服务发现,即:当我的一个服务(Pod)的 IP 地址是不固定的且没办法提前获知时,我该如何通过一个固定的方式访问到这个 Pod 呢?而在这里讲解的、ClusterIP 模式的 Service 为你提供的,就是一个 Pod 的稳定的 IP 地址,即 VIP。原创 2023-11-21 11:02:14 · 56 阅读 · 0 评论 -
36 | 为什么说Kubernetes只有soft multi-tenancy?
在本篇文章中,主要分享了 Kubernetes 对 Pod 进行“隔离”的手段,即:NetworkPolicy。可以看到,NetworkPolicy 实际上只是宿主机上的一系列 iptables 规则。这跟传统 IaaS 里面的安全组(Security Group)其实是非常类似的。而基于上述讲述,就会发现这样一个事实:Kubernetes 的网络模型以及大多数容器网络实现,其实既不会保证容器之间二层网络的互通,也不会实现容器之间的二层网络隔离。这跟 IaaS 项目管理虚拟机的方式,是完全不同的。原创 2023-11-21 10:08:30 · 42 阅读 · 0 评论 -
35 | 解读Kubernetes三层网络方案
在本篇文章中,详细讲述了 Fannel host-gw 模式和 Calico 这两种纯三层网络方案的工作原理。需要注意的是,在大规模集群里,三层网络方案在宿主机上的路由规则可能会非常多,这会导致错误排查变得困难。此外,在系统故障的时候,路由规则出现重叠冲突的概率也会变大。基于上述原因,如果是在公有云上,由于宿主机网络本身比较“直白”,我一般会推荐更加简单的 Flannel host-gw 模式。原创 2023-11-21 08:52:40 · 61 阅读 · 0 评论 -
34 | Kubernetes网络模型与CNI网络插件
在本篇文章中,详细讲解了 Kubernetes 中 CNI 网络的实现原理。根据这个原理,其实就很容易理解所谓的“Kubernetes 网络模型”了:1. 所有容器都可以直接使用 IP 地址与其他容器通信,而无需使用 NAT。2. 所有宿主机都可以直接使用 IP 地址与所有容器通信,而无需使用 NAT。反之亦然。3. 容器自己“看到”的自己的 IP 地址,和别人(宿主机或者容器)看到的地址是完全一样的。可以看到,这个网络模型,其实可以用一个字总结,那就是“通”。原创 2023-11-20 23:31:18 · 81 阅读 · 0 评论 -
33 | 深入解析容器跨主机网络
在本篇文章中,详细讲解了 Flannel UDP 和 VXLAN 模式的工作原理。这两种模式其实都可以称作“隧道”机制,也是很多其他容器网络插件的基础。比如 Weave 的两种模式,以及 Docker 的 Overlay 模式。此外,从上面的讲解中我们可以看到,VXLAN 模式组建的覆盖网络,其实就是一个由不同宿主机上的 VTEP 设备,也就是 flannel.1 设备组成的虚拟二层网络。对于 VTEP 设备来说,它发出的“内部数据帧”就仿佛是一直在这个虚拟的二层网络上流动。这,也正是覆盖网络的含义。原创 2023-11-20 23:21:02 · 446 阅读 · 0 评论 -
32 | 浅谈容器网络
在今天这篇文章中,主要介绍了在本地环境下,单机容器网络的实现原理和 docker0 网桥的作用。这里的关键在于,容器要想跟外界进行通信,它发出的 IP 包就必须从它的 Network Namespace 里出来,来到宿主机上。而解决这个问题的方法就是:为容器创建一个一端在容器里充当默认网卡、另一端在宿主机上的 Veth Pair 设备。上述单机容器网络的知识,是后面我们讲解多机容器网络的重要基础,请务必认真消化理解。原创 2023-11-20 18:39:43 · 288 阅读 · 0 评论 -
31 | 容器存储实践:CSI插件编写指南
在今天这篇文章中,以一个 DigitalOcean 的 CSI 插件为例,分享了编写 CSI 插件的具体流程。基于这些讲述,现在应该已经对 Kubernetes 持久化存储体系有了一个更加全面和深入的认识。原创 2023-11-20 18:25:43 · 161 阅读 · 0 评论 -
30 | 编写自己的存储插件:FlexVolume与CSI
在本篇文章里,详细讲解了 FlexVolume 和 CSI 这两种自定义存储插件的工作原理。可以看到,相比于 FlexVolume,CSI 的设计思想,把插件的职责从“两阶段处理”,扩展成了 Provision、Attach 和 Mount 三个阶段。其中,Provision 等价于“创建磁盘”,Attach 等价于“挂载磁盘到虚拟机”,Mount 等价于“将该磁盘格式化后,挂载在 Volume 的宿主机目录上”。原创 2023-11-20 17:35:53 · 122 阅读 · 0 评论 -
29 | PV、PVC体系是不是多此一举?从本地持久化卷谈起
在今天这篇文章中,详细介绍了 Kubernetes 里 Local Persistent Volume 的实现方式。可以看到,正是通过 PV 和 PVC,以及 StorageClass 这套存储体系,这个后来新添加的持久化存储方案,对 Kubernetes 已有用户的影响,几乎可以忽略不计。作为用户,你的 Pod 的 YAML 和 PVC 的 YAML,并没有任何特殊的改变,这个特性所有的实现只会影响到 PV 的处理,也就是由运维人员负责的那部分工作。而这,正是这套存储体系带来的“解耦”的好处。原创 2023-11-20 16:43:05 · 50 阅读 · 0 评论 -
28 | PV、PVC、StorageClass,这些到底在说啥?
在今天的分享中,详细解释了 PVC 和 PV 的设计与实现原理,并阐述了 StorageClass 到底是干什么用的。这些概念之间的关系,可以用如下所示的一幅示意图描述:从图中我们可以看到,在这个体系中:PVC 描述的,是 Pod 想要使用的持久化存储的属性,比如存储的大小、读写权限等。PV 描述的,则是一个具体的 Volume 的属性,比如 Volume 的类型、挂载目录、远程存储服务器地址等。而 StorageClass 的作用,则是充当 PV 的模板。原创 2023-11-20 15:49:51 · 43 阅读 · 0 评论 -
27 | 聪明的微创新:Operator工作原理解读
在今天这篇文章中,以 Etcd Operator 为例,详细介绍了一个 Operator 的工作原理和编写过程。可以看到,Etcd 集群本身就拥有良好的分布式设计和一定的高可用能力。在这种情况下,StatefulSet“为 Pod 编号”和“将 Pod 同 PV 绑定”这两个主要的特性,就不太有用武之地了。而相比之下,Etcd Operator 把一个 Etcd 集群,抽象成了一个具有一定“自治能力”的整体。原创 2023-11-20 15:05:20 · 80 阅读 · 0 评论 -
26 | 基于角色的权限控制:RBAC
在今天这篇文章中,主要讲解了基于角色的访问控制(RBAC)。其实,你现在已经能够理解,所谓角色(Role),其实就是一组权限规则列表。而我们分配这些权限的方式,就是通过创建 RoleBinding 对象,将被作用者(subject)和权限列表进行绑定。另外,与之对应的 ClusterRole 和 ClusterRoleBinding,则是 Kubernetes 集群级别的 Role 和 RoleBinding,它们的作用范围不受 Namespace 限制。原创 2023-11-20 14:15:56 · 94 阅读 · 0 评论 -
25 | 深入解析声明式API(二):编写自定义控制器
在今天这篇文章中,剖析了 Kubernetes API 编程范式的具体原理,并编写了一个自定义控制器。这其中,有如下几个概念和机制,是一定要理解清楚的:所谓的 Informer,就是一个自带缓存和索引机制,可以触发 Handler 的客户端库。这个本地缓存在 Kubernetes 中一般被称为 Store,索引一般被称为 Index。Informer 使用了 Reflector 包,它是一个可以通过 ListAndWatch 机制获取并监视 API 对象变化的客户端封装。原创 2023-11-20 11:30:06 · 58 阅读 · 0 评论 -
24 | 深入解析声明式API(一):API对象的奥秘
在今天这篇文章中,详细解析了 Kubernetes 声明式 API 的工作原理,讲解了如何遵循声明式 API 的设计,为 Kubernetes 添加一个名叫 Network 的 API 资源类型。从而达到了通过标准的 kubectl create 和 get 操作,来管理自定义 API 对象的目的。不过,创建出这样一个自定义 API 对象,我们只是完成了 Kubernetes 声明式 API 的一半工作。原创 2023-11-20 11:09:48 · 117 阅读 · 0 评论 -
23 | 声明式API与Kubernetes编程范式
在今天这篇文章中,重点讲解了 Kubernetes 声明式 API 的含义。并且,通过对 Istio 项目的剖析,说明了它使用 Kubernetes 的 Initializer 特性,完成 Envoy 容器“自动注入”的原理。事实上,从“使用 Kubernetes 部署代码”,到“使用 Kubernetes 编写代码”的蜕变过程,正是从一个 Kubernetes 用户,到 Kubernetes 玩家的晋级之路。原创 2023-11-20 10:45:16 · 273 阅读 · 0 评论 -
22 | 撬动离线业务:Job与CronJob
在今天这篇文章中,主要分享了 Job 这个离线业务的编排方法,讲解了 completions 和 parallelism 字段的含义,以及 Job Controller 的执行原理。紧接着,通过实例分享了 Job 对象三种常见的使用方法。但是,根据在社区和生产环境中的经验,大多数情况下用户还是更倾向于自己控制 Job 对象。所以,相比于这些固定的“模式”,掌握 Job 的 API 对象,和它各个字段的准确含义会更加重要。最后,还介绍了一种 Job 的控制器,叫作:CronJob。原创 2023-11-20 08:55:29 · 149 阅读 · 0 评论 -
21 | 容器化守护进程的意义:DaemonSet
在今天这篇文章中,首先简单介绍了 StatefulSet 的“滚动更新”,然后重点讲解了本专栏的第三个重要编排对象:DaemonSet。相比于 Deployment,DaemonSet 只管理 Pod 对象,然后通过 nodeAffinity 和 Toleration 这两个调度器的小功能,保证了每个节点上有且只有一个 Pod。这个控制器的实现原理简单易懂,希望能够快速掌握。与此同时,DaemonSet 使用 ControllerRevision,来保存和管理自己对应的“版本”。原创 2023-11-19 21:46:50 · 42 阅读 · 0 评论 -
20 | 深入理解StatefulSet(三):有状态应用实践
在今天这篇文章中,以 MySQL 集群为例,详细分享了一个实际的 StatefulSet 的编写过程。这个 YAML 文件的链接在这里,希望能多花一些时间认真消化。在这个过程中,有以下几个关键点(坑)特别值得注意和体会。1. “人格分裂”:在解决需求的过程中,一定要记得思考,该 Pod 在扮演不同角色时的不同操作。2. “阅后即焚”:很多“有状态应用”的节点,只是在第一次启动的时候才需要做额外处理。原创 2023-11-19 21:10:43 · 142 阅读 · 0 评论 -
19 | 深入理解StatefulSet(二):存储状态
在今天这篇文章中,详细介绍了 StatefulSet 处理存储状态的方法。然后,以此为基础,梳理了 StatefulSet 控制器的工作原理。从这些讲述中,我们不难看出 StatefulSet 的设计思想:StatefulSet 其实就是一种特殊的 Deployment,而其独特之处在于,它的每个 Pod 都被编号了。而且,这个编号会体现在 Pod 的名字和 hostname 等标识信息上,这不仅代表了 Pod 的创建顺序,也是 Pod 的重要网络标识(即:在整个集群里唯一的、可被访问的身份)。原创 2023-11-19 19:58:30 · 107 阅读 · 0 评论 -
18 | 深入理解StatefulSet(一):拓扑状态
在今天这篇文章中,首先分享了 StatefulSet 的基本概念,解释了什么是应用的“状态”。紧接着 ,分析了 StatefulSet 如何保证应用实例之间“拓扑状态”的稳定性。如果用一句话来总结的话,可以这么理解这个过程:StatefulSet 这个控制器的主要作用之一,就是使用 Pod 模板创建 Pod 的时候,对它们进行编号,并且按照编号顺序逐一完成创建工作。原创 2023-11-19 19:23:52 · 62 阅读 · 0 评论 -
17 | 经典PaaS的记忆:作业副本与水平扩展
在今天这篇文章中,详细讲解了 Deployment 这个 Kubernetes 项目中最基本的编排控制器的实现原理和使用方法。通过这些讲解,应该了解到:Deployment 实际上是一个两层控制器。首先,它通过ReplicaSet 的个数来描述应用的版本;然后,它再通过ReplicaSet 的属性(比如 replicas 的值),来保证 Pod 的副本数量。备注:Deployment 控制 ReplicaSet(版本),ReplicaSet 控制 Pod(副本数)。这个两层控制关系一定要牢记。原创 2023-11-19 18:58:14 · 39 阅读 · 0 评论 -
16 | 编排其实很简单:谈谈“控制器”模型
在今天这篇文章中,以 Deployment 为例,详细分享了 Kubernetes 项目如何通过一个称作“控制器模式”(controller pattern)的设计方法,来统一地实现对各种不同的对象或者资源进行的编排操作。在后面的讲解中,还会讲到很多不同类型的容器编排功能,比如 StatefulSet、DaemonSet 等等,它们无一例外地都有这样一个甚至多个控制器的存在,并遵循控制循环(control loop)的流程,完成各自的编排逻辑。原创 2023-11-19 11:12:03 · 60 阅读 · 0 评论 -
15 | 深入解析Pod对象(二):使用进阶
在今天这篇文章中,详细介绍了 Pod 对象更高阶的使用方法,希望通过对这些实例的讲解,你可以更深入地理解 Pod API 对象的各个字段。而在学习这些字段的同时,还应该认真体会一下 Kubernetes“一切皆对象”的设计思想:比如应用是 Pod 对象,应用的配置是 ConfigMap 对象,应用要访问的密码则是 Secret 对象。所以,也就自然而然地有了 PodPreset 这样专门用来对 Pod 进行批量化、自动化修改的工具对象。原创 2023-11-19 11:01:32 · 57 阅读 · 0 评论 -
14 | 深入解析Pod对象(一):基本概念
在今天这篇文章中,详细讲解了 Pod API 对象,介绍了 Pod 的核心使用方法,并分析了 Pod 和 Container 在字段上的异同。希望这些讲解能够帮你更好地理解和记忆 Pod YAML 中的核心字段,以及这些字段的准确含义。实际上,Pod API 对象是整个 Kubernetes 体系中最核心的一个概念,也是后面讲解各种控制器时都要用到的。原创 2023-11-18 23:53:07 · 146 阅读 · 0 评论 -
13 | 为什么我们需要Pod?
在本篇文章中重点分享了 Kubernetes 项目中 Pod 的实现原理。Pod 是 Kubernetes 项目与其他单容器项目相比最大的不同,也是一位容器技术初学者需要面对的第一个与常规认知不一致的知识点。事实上,直到现在,仍有很多人把容器跟虚拟机相提并论,他们把容器当做性能更好的虚拟机,喜欢讨论如何把应用从虚拟机无缝地迁移到容器中。但实际上,无论是从具体的实现原理,还是从使用方法、特性、功能等方面,容器与虚拟机几乎没有任何相似的地方;也不存在一种普遍的方法,能够把虚拟机里的应用无缝迁移到容器中。原创 2023-11-18 20:58:50 · 66 阅读 · 0 评论