Statistics
34
Views
0
Downloads
0
Donations
Author：iBooker it-ebooks
No description
Tags
Support Statistics
¥.00 ·
0times
Text Preview (First 20 pages)
Registered users can read the full content for free
Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.
Page
1
(This page has no text content)
Page
2
下载更多免费电子书 云服务技术课堂技术圈 云服务技术大学钉钉群 扫码关注阿里巴巴云原生 扫一扫二维码图案，关注我吧
Page
3
理论篇 4 这么理解集群控制器，能行！ 4 集群网络详解 13 集群伸缩原理 21 认证与调度 28 集群服务的三个要点和一种实现 45 镜像拉取这件小事 56 实践篇 67 读懂这一篇，集群节点不下线 67 节点下线姊妹篇 81 我们为什么会删除不了集群的命名空间？ 93 阿里云ACK产品安全组配置管理 104 二分之一活的微服务 114 半夜两点Ca证书过期问题处理惨况总结 124 目录
Page
4
这么理解集群控制器，能行！ 简介： 当我们尝试去理解 K8S 集群工作原理的时候，控制器肯定是一个难点。 这是因为控制器有很多，具体实现大相径庭；且控制器的实现用到了一些较为晦涩的 机制，不易理解。但是，我们又不能绕过控制器，因为它是集群的“大脑”。 当我们尝试去理解K8S集群工作原理的时候，控制器肯定是一个难点。这是因 为控制器有很多，具体实现大相径庭；且控制器的实现用到了一些较为晦涩的机制， 不易理解。但是，我们又不能绕过控制器，因为它是集群的“大脑”。今天这篇文章， 我们通过分析一个简易冰箱的设计过程，来深入理解集群控制器的产生，功能以及实 现方法。 大图 下图是K8S集群的核心组件，包括数据库 etcd，调度器 scheduler，集群入口 API Server，控制器Controller，服务代理 kube-proxy 以及直接管理具体业务容 器的 kubelet。这些组件逻辑上可以被分为三个部分：核心组件 etc 数据库，对 etcd 进行直接操作的入口组件API Server，以及其他组件。这里的“其他组件”之所以 可以被划分为一类，是因为它们都可以被看做是集群的控制器。 理论篇
Page
5
这么理解集群控制器，能行！ < 5 今天我们要讲的就是集群控制器原理。 控制器原理 虽然控制器是K8S集群中比较复杂的组件，但控制器本身对我们来说并不陌生 的。我们每天使用的洗衣机、冰箱、空调等，都是依靠控制器才能正常工作。在控制 器原理这一节，我们通过思考一个简易冰箱的设计过程，来理解K8S集群控制器的 原理。 简易的冰箱 这个冰箱包括五个组件：箱体、制冷系统、照明系统、温控器以及门。冰箱只有 两个功能：当有人打开冰箱门的时候，冰箱内的灯会自动开启；当有人按下温控器的 时候，制冷系统会根据温度设置，调节冰箱内温度。
Page
6
6 > 这么理解集群控制器，能行！ 统一入口 对于上边的冰箱，我们可以简单抽象成两个部分：统一的操作入口和冰箱的所有 组件。在这里，用户只有通过入口，才能操作冰箱。这个入口提供给用户两个接口： 开关门和调节温控器。用户执行这两个接口的时候，入口会分别调整冰箱门和温控器 的状态。
Page
7
这么理解集群控制器，能行！ < 7 控制器 控制器就是为了解决上边的问题产生的。控制器就是用户的操作，和冰箱各个组 件的正确状态之间的一座桥梁：当用户打开门的时候，控制器观察到了门的变化，它 替用户打开冰箱内的灯；当用户按下温控器的时候，控制器观察到了用户设置的温 度，它替用户管理制冷系统，调节冰箱内温度。 控制器管理器 冰箱有照明系统和制冷系统，显然相比一个控制器管理着两个组件，我们替每个 组件分别实现一个控制器是更为合理的选择。同时我们实现一个控制器管理器来统一 维护所有这些控制器，来保证这些控制器在正常工作。
Page
8
8 > 这么理解集群控制器，能行！ SharedInformer 上边的控制器和控制器管理器，看起来已经相当不错了。但是当冰箱功能增加， 势必有很多新的控制器加进来。这些控制器都需要通过冰箱入口，时刻监控自己关心 的组件的状态变化。比如照明系统控制器就需要时刻监控冰箱门的状态。当大量控制 器不断的和入口通信的时候，就会增加入口的压力。 这个时候，我们把监控冰箱组件状态变化这件事情，交给一个新的模块 SharedInformer 来实现。SharedInformer 作为控制器的代理，替控制器监控冰箱 组件的状态变化，并根据控制器的喜好，把不同组件状态的变化，通知给对应的控制 器。通过优化，这样的SharedInformer 可以极大的缓解冰箱入口的压力。
Page
9
这么理解集群控制器，能行！ < 9 ListWatcher
Page
10
10 > 这么理解集群控制器，能行！ 假设 SharedInformer 和冰箱入口通过 http 协议通信的话，那么 http 分块编码 （chunked transfer encoding）就是实现 ListWatcher 的一个好的选择。控制器通过 ListWatcher 给冰箱入口发送一个查询然后等待，当冰箱组件有变化的时候，入口通 过分块的 http 响应通知控制器。控制器看到 chunked 响应，会认为响应数据还没有 发送完成，所以会持续等待。 举例 以上我们从一个简易冰箱的进化过程中，了解了控制器产生的意义，扮演的角色， 以及实现的方式。现在我们回到K8S集群。K8S集群实现了大量的控制器，而且在可 以预见的未来，新的功能的控制器会不断出现，而一些旧的控制器也会被逐渐淘汰。 目前来说，我们比较常用的控制器，如 pod 控制器、deployment 控制器、 service 控制器、replicaset 控制器等。这些控制器一部分是由 kube controller manager 这个管理器实现和管理，而像 route 控制器和 service 控制器，则由
Page
11
这么理解集群控制器，能行！ < 11 cloud controller manager 实现。 之所以会出现 cloud controller manager，是因为在不同的云环境中，一部分控 制器的实现，会因为云厂商、云环境的不同，出现很大的差别。这类控制器被划分出 来，由云厂商各自基于 cloud controller manager 分别实现。 这里我们以阿里云K8S集群 cloud controller manager 实现的 route 控制器和 service 控制器为例，简单说明K8S控制器的工作原理。 服务控制器 首先，用户请求 API Server 创建一个 LoadBalancer 类型的服务，API Server 收到请求并把这个服务的详细信息写入 etcd 数据库。而这个变化，被服务控 制器观察到了。服务控制器理解 LoadBalancer 类型的服务，除了包括存放在 etcd 内部的服务记录之外，还需要一个SLB作为服务入口，以及若干 endpoints 作为服 务后端。所以服务控制器分别请求 SLB的云 openapi 和 API Server，来创建云上 SLB资源，和集群内 endpoints 资源。
Page
12
12 > 这么理解集群控制器，能行！ 路由控制器 在集群网络一章中，我们提到过，当一个节点加入一个K8S集群的时候，集群 需要在VPC路由表里增加一条路由，来搭建这个新加入节点到 pod 网络的主干道。 而这件事情，就是路由控制器来做的。路由控制器完成这件事情的流程，与上边服务 控制器的处理流程非常类似，这里不再赘述。 结束语 基本上来说，K8S 集群的控制器，其实扮演着集群大脑的角色。有了控制器， K8S集群才有机会摆脱机械和被动，变成一个自动、智能、有大用的系统。
Page
13
集群网络详解 简介： 阿里云K8S集群网络目前有两种方案，一种是 flannel 方案，另外一种是 基于 calico 和弹性网卡 eni 的 terway 方案。Terway 和 flannel 类似，不同的地方 在于，terway 支持 Pod 弹性网卡，以及NetworkPolicy 功能。 阿里云 K8S 集群网络目前有两种方案，一种是 flannel 方案，另外一种是基于 calico 和弹性网卡 eni 的 terway 方案。Terway 和 flannel 类似，不同的地方在于， terway 支持 Pod 弹性网卡，以及NetworkPolicy 功能。 今天这篇文章，我们以 flannel 为例，深入分析阿里云 K8S集群网络的实现方 法。我会从两个角度去分析，一个是网络的搭建过程，另外一个是基于网络的通信。 我们的讨论基于当前的 1.12.6 版本。 鸟瞰 总体上来说，阿里云 K8S 集群网络配置完成之后，如下图，包括集群CIDR， VPC路由表，节点网络，节点的 podCIDR，节点上的虚拟网桥 cni0，连接 Pod 和 网桥的 veth 等部分。
Page
14
14 > 集群网络详解 类似的图，大家可能在很多文章中都看过，但是因为其中相关配置过于复杂， 比较难理解。这里我们可以把这些配置，分三种情况来理解：集群配置，节点配置 以及 Pod 配置。与这三种情况对应的，其实是对集群网络 IP 段的三次划分：首先 是集群CIDR，接着为每个节点分配 podCIDR（即集群 CIDR 的子网段），最后在 podCIDR里为每个Pod分配自己的 IP。
Page
15
集群网络详解 < 15 集群网络搭建 初始阶段 集群的创建，基于云资源 VPC 和 ECS，在创建完 VPC 和 ECS 之后，我 们基本上可以得到如下图的资源配置。我们得到一个 VPC，这个 VPC 的网段是 192.168.0.0/16，我们得到若干ECS，他们从VPC网段里分配到 IP地址。 集群阶段 在以上出初始资源的基础上，我们利用集群创建控制台得到集群 CIDR。这 个值会以参数的形式传给集群节点 provision 脚本，并被脚本传给集群节点配置工 具 kubeadm。kubeadm 最后把这个参数写入集群控制器静态 Pod 的 yaml 文件 kube-controller-manager.yaml。
Page
16
16 > 集群网络详解 集群控制器有了这个参数，在节点 kubelet 注册节点到集群的时候，集群控制 器会为每个注册节点，划分一个子网出来，即为每个节点分配 podCIDR。如上图， Node B 的子网是 172.16.8.1/25，而 Node A 的子网是 172.16.0.128/25。这个配 置会记录到集群 node 的 podCIDR数据项里。 节点阶段 经过以上集群阶段，K8S有了集群CIDR，以及为每个节点划分的 podCIDR。 在此基础上，集群会下发 flanneld 到每个阶段上，进一步搭建节点上，可以给 Pod 使用的网络框架。这里主要有两个操作，第一个是集群通过Cloud Controller Manager 给 VPC 配置路由表项。路由表项对每个节点有一条。每一条的意思是， 如果VPC路由收到目的地址是某一个节点 podCIDR的 IP 地址，那么路由会把这个 网络包转发到对应的ECS上。第二个是创建虚拟网桥 cni0，以及与 cni0 相关的路 由。这些配置的作用是，从阶段外部进来的网络包，如果目的 IP是 podCIDR，则会 被节点转发到 cni0 虚拟局域网里。
Page
17
集群网络详解 < 17 注意：实际实现上，cni0 的创建，是在第一个使用Pod 网络的Pod 被调度到节 点上的时候，由下一节中 flannal cni 创建的，但是从逻辑上来说，cni0 属于节点网 络，不属于Pod网络，所以在此描述。 Pod 阶段 在前边的三个阶段，集群实际上已经为Pod 之间搭建了网络通信的干道。这个 时候，如果集群把一个Pod 调度到节点上，kubelet 会通过 flannel cni 为这个 Pod 本身创建网络命名空间和 veth 设备，然后，把其中一个 veth 设备加入到 cni0 虚拟 网桥里，并为Pod 内的 veth 设备配置 ip 地址。这样Pod 就和网络通信的干道连接 在了一起。这里需要强调的是，前一节的 flanneld 和这一节的 flannel cni 完全是两 个组件。flanneld 是一个 daemonset 下发到每个节点的 pod，它的作用是搭建网络 （干道），而 flannel cni 是节点创建的时候，通过 kubernetes-cni 这个 rpm包安装 的 cni 插件，其被 kubelet 调用，用来为具体的 pod 创建网络（分枝）。
Page
18
18 > 集群网络详解 理解这两者的区别，有助于我们理解 flanneld 和 flannel cni 相关的配置文件的 用途。比如 /run/flannel/subnet.env，是 flanneld 创建的，为 flannel cni 提供输入 的一个环境变量文件；又比如 /etc/cni/net.d/10-flannel.conf，也是 flanneld pod （准确的说，是 pod 里的脚本 install-cni）从 pod 里拷贝到节点目录，给 flannel cni 使用的子网配置文件。 通信 以上完成 Pod 网络环境搭建。基于以上的网络环境，Pod 可以完成四种通信： 本地通信，同节点Pod 通信，跨节点Pod 通信，以及Pod 和 Pod 网络之外的实体 通信。
Page
19
集群网络详解 < 19 其中本地通信，说的是Pod 内部，不同容器之前通信。因为Pod 内网容器之间 共享一个网络协议栈，所以他们之间的通信，可以通过 loopback 设备完成。 同节点Pod 之间的通信，是 cni0 虚拟网桥内部的通信，这相当于一个二层局域 网内部设备通信。 跨节点Pod 通信略微复杂一点，但也很直观，发送端数据包，通过 cni0 网桥的 网关，流转到节点上，然后经过节点 eth0 发送给 VPC路由。这里不会经过任何封 包操作。当VPC路由收到数据包时，它通过查询路由表，确认数据包目的地，并把 数据包发送给对应的ECS节点。而进去节点之后，因为 flanneld 在节点上创建了真 的 cni0 的路由，所以数据包会被发送到目的地的 cni0 局域网，再到目的地Pod。 最后一种情况，Pod 与非 Pod 网络的实体通信，需要经过节点上 iptables 规则 做 snat，而此规则就是 flanneld 依据命令行 --ip-masq 选项做的配置。
Page
20
20 > 集群网络详解 总结 以上是阿里云K8S集群网络的搭建和通信原理。我们主要通过网络搭建和通信 两个角度去分析K8S集群网络。其中网络搭建包括初始阶段，集群阶段，节点阶段 以及Pod 阶段，这么分类有助于我们理解这些复杂的配置。而理解了各个配置，集 群通信原理就比较容易理解了。
The above is a preview of the first 20 pages. Register to read the complete e-book.
Comments 0
Loading comments...
Reply to Comment
Edit Comment