Kubernetes进阶实战（第2版）

元数据 §

Kubernetes进阶实战（第2版）

• 
• 书名： Kubernetes进阶实战（第2版）
• 作者： 马永亮
• 简介： 全书分为5个部分。第一部分介绍Kubernetes系统基础架构及核心概述，并提供一个Kubernetes快速部署和应用的入门指南。第二部分剖析分Kubernetes系统的应用编排核心组件，对Pod、Controller、Service和Ingress、存储卷和应用配置等进行深入介绍。第三部分介绍安全相关的话题，主要涉及认证、授权、准入控制、网络模型和网络策略等话题。第四部分介绍Kubernetes系统高级话题及系统扩展，包括调度策略、CRD和Operator、资源指标与系统监控及应用管理器等。第五部分介绍基于Kubernetes的服务治理与服务网络，涉及数据平面组件Envoy、Istio架构、部署和应用案例等话题。
• 出版时间 2021-01-01 00:00:00
• ISBN： 9787111671862
• 分类： 计算机-编程设计
• 出版社： 机械工业出版社

高亮划线 §

1.2 Kubernetes基础 §

• 📌 Pod类似于单机操作系统上的“进程组”，它包含一到多个容器，却是Kubernetes上的最小调度单元，因而同一Pod内的容器必须运行于同一工作节点之上 ^36511877-7-2337-2412

  • ⏱ 2021-11-30 12:00:31

• 📌 Pod是一组容器组成的集合并包含这些容器的管理机制 ^36511877-7-7086-7111

  • ⏱ 2021-11-30 13:47:18

• 📌 kubelet是Kubernetes中最重要的组件之一，是运行于每个Node之上的“节点代理”服务，负责接收并执行Master发来的指令，以及管理当前Node上Pod对象的容器等任务。 ^36511877-7-6638-6730

  • ⏱ 2021-11-30 13:50:04

• 📌 kube-proxy是Kubernetes的核心网络组件，它本质上更像是Pod的代理及负载均衡器，负责确保集群中Node、Service和Pod对象之间的有效通信。 ^36511877-7-7445-7527

  • ⏱ 2021-11-30 13:50:47

• 📌 Kubernetes常用的集中式日志系统是由ElasticSearch、Fluentd和Kibana（称之为EFK）组合提供的整体解决方案。 ^36511877-7-8367-8437

  • ⏱ 2021-11-30 13:56:25

1.3 应用的运行与互联互通 §

• 📌 首先将部署于集群操作系统Kubernetes之上的应用定义为Pod的API对象描述，提交给API Server后经调度器从可用的工作节点中匹配出一个最佳选择，而后由相应工作节点上的kubelet代理程序根据其定义进行Pod创建、运行和状态监控等操作。位于同一网络中的各Pod实例可直接互相通信，但“用后即弃”的Pod自身的IP地址显然无法作为可持续使用的访问入口。Service资源用于为Pod提供固定访问端点，并基于该端点将流量调度至一组Pod实例之上。 ^36511877-8-393-621

  • ⏱ 2021-11-30 14:04:56

• 📌 Pod本质上是共享Network、IPC和UTS名称空间以及存储资源的容器集合，如图1-9所示。我们可以把每个Pod对象想象成一个逻辑主机，它类似于现实世界中的物理主机或虚拟机，而运行于同一个Pod对象中多个进程则类似于物理机或虚拟机上独立运行的进程，不同的是，Pod中各进程运行于彼此隔离的容器中，并于各容器间共享网络和存储两种关键资源。 ^36511877-8-714-884

  • ⏱ 2021-11-30 14:16:07

2.4 命令式应用编排 §

• 📌 为Pod对象创建Service对象，以便向客户端提供固定的访问端点，并能够借助KubeDNS进行服务发现 ^36511877-15-695-747
  • ⏱ 2021-11-30 15:58:13

3.1 资源对象与API群组 §

• 📌 ReplicationController、ReplicaSet和Deployment负责管理无状态应用，StatefulSet则用于管控有状态类应用。还有些应用较为独特，有些需要在集群中的每个节点上运行单个Pod资源，负责收集日志或运行系统服务等任务，该类编排操作由DaemonSet控制器对象进行，而需要在正常完成后退出故无须始终处于运行状态任务的编排工作则隶属Job控制器对象。CronJob控制器对象还能为Job型的任务提供定期执行机制。 ^36511877-19-2552-2775

  • ⏱ 2021-11-30 16:18:18

• 📌 以资源的主要功能作为分类标准，Kubernetes的API对象大体可分为工作负载、发现与负载均衡、配置与存储、集群和元数据几个类别 ^36511877-19-1319-1519

  • ⏱ 2021-11-30 17:25:00

• 📌 一个应用通常需要多个资源的支撑，例如用Deployment资源编排应用实例（Pod）、用ConfigMap和Secret资源保存应用配置、用Service或Ingress资源暴露服务、用Volume资源提供持久化存储等。 ^36511877-19-5614-5724

  • ⏱ 2021-11-30 17:46:12

• 📌 资源对象代表了系统上的持久类实体，而Kubernetes用这些持久实体来表达集群的状态，包括容器化的应用程序正运行于哪些节点，每个应用程序有哪些资源可用，以及每个应用程序各自的行为策略，例如重启、升级及容错策略等。一个对象可能会由多个资源组合而成，用户可对这些资源执行增、删、改、查等管理操作。Kubernetes通常使用标准的RESTful术语来描述API概念。 ^36511877-19-5913-6095

  • ⏱ 2021-11-30 17:48:57

• 📌 名称空间级别的每一个资源类型在API的URL路径表示都可简单抽象为形如/apis///namespaces//的路径。 ^36511877-19-9076-9175

  • ⏱ 2021-11-30 18:01:28

3.4 节点资源 §

• 📌 kubelet是运行于节点之上的主代理程序，它负责从API Server接收并执行由自身承载的Pod管理任务，并需要向Master上报自身运行状态（心跳消息）以维持集群正常运行。 ^36511877-22-1017-1106
  • ⏱ 2021-11-30 18:58:35

4.1 应用容器与Pod资源 §

• 📌 现代应用容器技术用来运行单个进程（包括子进程），它在容器中PID名称空间中的进程号为1，可直接接收并处理信号，因而该进程终止也将导致容器终止并退出。这种设计使得容器与内部进程具有共同的生命周期，更容易发现和判定故障，也更利于对单个应用程序按需求进行扩容和缩容。单进程容器可将应用日志直接送往标准输出（STDOUT）和标准错误（STDERR），有利于让容器引擎及容器编排工具获取、存储和管理。因此，一个容器中仅应该运行一个进程是应用容器“立身之本”，这也是Docker及Kubernetes使用容器的标准方式。凡事有利就有弊，单进程模型的应用容器显然不利于有IPC通信等需求的多个具有强耦合关系的进程间的协同，除非在组织这类容器时人为地让它们运行于同一内核之上共享IPC名称空间。于是，跨多个主机运行的容器编排系统需要能够描述这种容器间的强耦合关系，并确保它们始终能够被调度至集群中的同一个节点之上，Kubernetes为应对这种需求发明了Pod这一抽象概念，并将其设计为顶级API对象，是集群的“一等公民”。 ^36511877-27-587-1093

  • ⏱ 2021-12-01 20:53:06

• 📌 Pod除了是一组共享特定名称空间的容器的集合之外，其设计还隐藏了容器运行时复杂的命令行选项以及管理容器实例、存储卷及其他资源的复杂性，也隐藏了不同容器运行时彼此间的差异。从而让最终用户只需要掌握Pod资源配置格式便能够创建并运行容器，且无须关心具体的运行时就能够平滑地在不同的OCI容器运行时之间迁移容器。同一Pod中，这些共享PID、IPC、Network和UTS名称空间的容器彼此间可通过IPC通信，共享使用主机名和网络接口、IP地址、端口和路由等各种网络资源，因而各容器进程能够通过lo网络接口通信且不能使用相同的网络套接字地址。尽管可以把Pod类比为物理机或虚拟机，但一个Pod内通常仅应该运行具有强耦合关系的容器，否则除了pause以外，只应该存在单个容器，或者只存在单个主容器和一个以上的辅助类容器（例如服务网格中的Sidecar容器等），这也更符合单进程应用容器的设计初衷。 ^36511877-27-1700-2120

  • ⏱ 2021-12-01 21:12:22

• 📌 考虑到Pod应用的水平伸缩导致的同一应用的Pod对象的规模变动，因而便有了Service资源这个中间层结合KubeDNS进行服务发现 ^36511877-27-2662-2728

  • ⏱ 2021-12-01 21:38:43

• 📌 断路、路由、计量和监视 ^36511877-27-5267-5278

  • ⏱ 2021-12-02 08:41:40

• 📌 配置更新 ^36511877-27-5294-5298

  • ⏱ 2021-12-02 08:41:48

• 📌 日志记录服务、数据同步服务、配置服务和代理服务 ^36511877-27-4618-4641

  • ⏱ 2021-12-02 08:42:48

• 📌 大使模式为内部容器提供了简化统一的外部服务视图，适配器模式则刚好反过来，它通过标准化容器的输出和接口，为外界展示了一个简化的应用视图 ^36511877-27-6129-6195

  • ⏱ 2021-12-02 09:03:30

• 📌 存在可写入的共享资源 ^36511877-27-7813-7823

  • ⏱ 2021-12-02 09:16:51

• 📌 对结果进行聚合 ^36511877-27-7850-7857

  • ⏱ 2021-12-02 09:17:12

• 📌 每个任务实例外挂一个选举容器 ^36511877-27-8412-8426

  • ⏱ 2021-12-02 09:55:39

• 📌 存活状态监测失败将导致容器重启，而就绪状态监测失败会使得该容器从其所属的Service对象的可用端点列表中移除 ^36511877-27-11606-11661

  • ⏱ 2021-12-02 10:17:47

4.2 在Pod中运行应用 §

• 📌 容器镜像启动容器时运行的默认应用程序由其Dockerfile文件中的ENTRYPOINT指令进行定义，传递给程序的参数则通过CMD指令设定，ETRYPOINT指令不存在时，CMD可同时指定程序及其参数。 ^36511877-28-8343-8444
  • ⏱ 2021-12-02 10:58:46

4.3 暴露容器服务 §

• 📌 注意，hostPort与NodePort类型的Service对象暴露端口的方式不同，NodePort是通过所有节点暴露容器服务，而hostPort则能经由Pod对象所在节点的IP地址进行。 ^36511877-29-2941-3035
  • ⏱ 2021-12-02 13:25:58

4.4 容器安全上下文 §

• 📌 特权模式（具有访问主机设备的权限） ^36511877-30-523-540
  • ⏱ 2021-12-02 13:33:10

4.5 容器应用的管理接口 §

• 📌 SIGKILL信号是由底层操作系统接收的，而非应用进程，一旦检测到该信号，内核将停止为相应进程提供内核资源，并终止进程正在使用的所有CPU线程，类似于直接切断了进程的电源。 ^36511877-31-16358-16444
  • ⏱ 2021-12-02 14:36:34

4.6 多容器Pod §

• 📌 Envoy程序是服务网格领域著名的数据平面实现，它在Istio服务网格中以Sidecar的模式同每一个微服务应用程序单独组成一个Pod，负责代理该微服务应用的所有通信事件，并为其提供限流、熔断、超时、重试等多种高级功能。 ^36511877-32-5304-5414

  • ⏱ 2021-12-02 17:23:17

• 📌 支持用户在生命周期字段中将容器标记为Sidecar，这类容器全部转为就绪状态后，普通应用容器方可启动 ^36511877-32-7191-7241

  • ⏱ 2021-12-02 17:30:32

4.7 资源需求与资源限制 §

• 📌 资源需求：定义需要系统预留给该容器使用的资源最小可用值，容器运行时可能用不到这些额度的资源，但用到时必须确保有相应数量的资源可用 ^36511877-33-1242-1306

  • ⏱ 2021-12-02 17:38:27

• 📌 同等级别优先级的Pod资源在OOM时，与自身的requests属性相比，其内存占用比例最大的Pod对象将先被杀死 ^36511877-33-9597-9653

  • ⏱ 2021-12-02 17:52:00

• 📌 OOM是内存耗尽时的处理机制 ^36511877-33-10053-10067

  • ⏱ 2021-12-02 17:56:27

第5章 存储卷与数据持久化 §

• 📌 其存储卷绑定于Pod对象而非容器级别，并可共享给内部的所有容器使用 ^36511877-36-516-549
  • ⏱ 2021-12-02 18:00:03

5.6 容器存储接口CSI §

• 📌 Longhorn遵循微服务的原则，利用容器将小型独立组件构建为分布式块存储，并使用编排工具来协调这些组件，从而形成弹性分布式系统。 ^36511877-42-3590-3655
  • ⏱ 2021-12-02 22:57:00

第6章 应用配置 §

• 📌 ConfigMap和Secret将相应的配置信息保存于资源对象中，而后在Pod对象上以存储卷的形式将其挂载并加载相关的配置，降低了配置与镜像文件的耦合关系。 ^36511877-44-476-554
  • ⏱ 2021-12-02 23:07:00

6.1 容器化应用配置 §

• 📌 CMD指令以列表形式指定要运行的程序及其相关的参数，若同时存在ENTRYPOINT指令，则CMD指令中的列表所有元素均被视作由ENTRYPOINT指定程序的命令行参数。 ^36511877-45-1186-1270

  • ⏱ 2021-12-02 23:08:39

• 📌 其中的[COMMAND]即为自定义运行的程序，[ARG]则是传递给程序的参数。若定义相关的镜像文件时使用了ENTRYPOINT指令，则[COMMAND]和[ARG]都会被当作命令行参数传递给ENTRYPOINT指令中指定的程序，除非为docker run命令额外使用—entrypoint选项覆盖ENTRYPOINT指令而指定运行其他程序。 ^36511877-45-1482-1653

  • ⏱ 2021-12-02 23:10:18

• 📌 在基于此类镜像启动容器时，通过docker run命令的-e选项向环境变量传值即能实现应用配置，命令的使用格式为docker run -e SETTING1=foo -e SETTING2=bar … 。 ^36511877-45-2390-2512

  • ⏱ 2021-12-02 23:12:54

7.1 Service资源及其实现模型 §

• 📌 事实上是一种抽象：通过规则定义出由多个Pod对象组合而成的逻辑集合，以及访问这组Pod的策略 ^36511877-51-436-482

  • ⏱ 2021-12-03 00:15:27

• 📌 Service资源基于标签选择器把筛选出的一组Pod对象定义成一个逻辑组合，并通过自己的IP地址和端口将请求分发给该组内的Pod对象 ^36511877-51-1257-1323

  • ⏱ 2021-12-03 00:19:32

• 📌 Service对象会通过API Server持续监视（watch）标签选择器匹配到的后端Pod对象，并实时跟踪这些Pod对象的变动情况，例如IP地址变动以及Pod对象的增加或删除等。 ^36511877-51-1958-2049

  • ⏱ 2021-12-03 00:27:15

• 📌 Endpoints资源对象 ^36511877-51-2085-2098

  • ⏱ 2021-12-03 00:27:28

• 📌 本质上来讲，一个Service对象对应于工作节点内核之中的一组iptables或/和ipvs规则，这些规则能够将到达Service对象的ClusterIP的流量调度转发至相应Endpoint对象指向的IP地址和端口之上。内核中的iptables或ipvs规则的作用域仅为其所在工作节点的一个主机，因而生效于集群范围内的Service对象就需要在每个工作节点上都生成相关规则，从而确保任一节点上发往该Service对象请求的流量都能被正确转发。 ^36511877-51-2329-2550

  • ⏱ 2021-12-03 00:29:13

• 📌 每个工作节点的kube-proxy组件通过API Server持续监控着各Service及其关联的Pod对象，并将Service对象的创建或变动实时反映至当前工作节点上相应的iptables或ipvs规则上。 ^36511877-51-2576-2680

  • ⏱ 2021-12-03 00:39:00

• 📌 Netfilter是Linux内核中用于管理网络报文的框架，它具有网络地址转换（NAT）、报文改动和报文过滤等防火墙功能，用户可借助用户空间的iptables等工具按需自由定制规则使用其各项功能。ipvs是借助于Netfilter实现的网络请求报文调度框架，支持rr、wrr、lc、wlc、sh、sed和nq等10余种调度算法，用户空间的命令行工具是ipvsadm，用于管理工作于ipvs之上的调度规则。 ^36511877-51-3071-3273

  • ⏱ 2021-12-03 00:39:53

• 📌 创建Service对象的操作会触发集群中的每个kube-proxy并将其转换为定义在所属节点上的iptables规则，用于转发工作接口接收到的、与此Service资源ClusterIP和端口相关的流量。 ^36511877-51-4457-4558

  • ⏱ 2021-12-03 00:48:35

• 📌 与iptables规则的不同之处仅在于客户端请求流量的调度功能由ipvs实现，余下的其他功能仍由iptables完成。 ^36511877-51-5452-5511

  • ⏱ 2021-12-03 08:09:47

• 📌 ipvs代理模型中Service的服务发现和负载均衡功能均基于内核中的ipvs规则实现。类似于iptables，ipvs也构建于内核中的netfilter之上，但它使用hash表作为底层数据结构且工作于内核空间，因此具有流量转发速度快、规则同步性能好的特性，适用于存在大量Service资源且对性能要求较高的场景。ipvs代理模型支持rr、lc、dh、sh、s ^36511877-51-5805-5985

  • ⏱ 2021-12-03 08:17:39

• 📌 无论哪一种代理模型，Service资源都可统一根据其工作逻辑分为ClusterIP、NodePort、LoadBalancer和ExternalName这4种类型。 ^36511877-51-6091-6173

  • ⏱ 2021-12-03 08:43:28

• 📌 ClusterIP地址仅在集群内部可达，因而无法被集群外部的客户端访问。 ^36511877-51-6252-6288

  • ⏱ 2021-12-03 08:48:22

• 📌 NodePort类型是对ClusterIP类型Service资源的扩展，它支持通过特定的节点端口接入集群外部的请求流量， ^36511877-51-6366-6426

  • ⏱ 2021-12-03 08:48:37

• 📌 显然，若集群外部的请求报文首先到的节点并非Service调度的目标Server Pod所在的节点，该请求必然因需要额外的转发过程（跃点）和更多的处理步骤而产生更多延迟。 ^36511877-51-6540-6624

  • ⏱ 2021-12-03 08:50:02

• 📌 自身的节点IP ^36511877-51-7115-7122

  • ⏱ 2021-12-03 08:54:30

• 📌 创建LoadBalancer类型的Service对象时会在集群上创建一个NodePort类型的Service，并额外触发Kubernetes调用底层的IaaS服务的API创建一个软件负载均衡器，而集群外部的请求流量会先路由至该负载均衡器，并由该负载均衡器调度至各节点上该Service对象的NodePort ^36511877-51-7361-7514

  • ⏱ 2021-12-03 08:56:43

• 📌 把集群外部的某服务以DNS CNAME记录的方式映射到集群内，从而让集群内的Pod资源能够访问外部服务的一种实现方式 ^36511877-51-8076-8134

  • ⏱ 2021-12-03 09:02:12

• 📌 总体来说，若需要将Service资源发布至集群外部，应该将其配置为NodePort或Load-Balancer类型，而若要把外部的服务发布于集群内部供Pod对象使用，则需要定义一个ExternalName类型的Service资源 ^36511877-51-8521-8635

  • ⏱ 2021-12-03 09:04:37

7.2 应用Service资源 §

• 📌 Service对象自身只是iptables或ipvs规则，它并不能处理客户端的服务请求，而是需要把请求报文通过目标地址转换（DNAT）后转发至后端某个Server Pod ^36511877-52-3222-3307
  • ⏱ 2021-12-03 09:13:58

7.4 深入理解Service资源 §

• 📌 本质上，Service对象代表着由kube-proxy借助于自身的程序逻辑（userspace）、iptables或ipvs，甚至是某种形式的组合所构建出的流量代理和调度转发机制，每个Service对象的创建、更新与删除都会经由kube-proxy反映为程序配置、iptables规则或ipvs规则的相应操作。 ^36511877-54-391-546

  • ⏱ 2021-12-03 10:38:24

• 📌 单个Service对象的iptables数量与后端端点的数量正相关 ^36511877-54-11615-11648

  • ⏱ 2021-12-03 11:08:33

• 📌 ipvs代理模型通过将流量匹配和分发功能配置为少量ipvs规则，有效降低了对系统资源的占用，从而能够承载更大规模的Kubernetes集群 ^36511877-54-11845-11914

  • ⏱ 2021-12-03 11:09:57

• 📌 相较于iptables代理模型的复杂表示逻辑，ipvs的代理逻辑也较为简单，它仅有两个关键配置要素。首先，kube-proxy会在每个节点上创建一个名为kube-ipvs0的虚拟网络接口，并将集群上所有Service对象的ClusterIP和ExternalIP配置到该接口，使相应IP地址的流量都可被当前节点捕获。其次，kube-proxy会为每个Service生成相关的ipvs虚拟服务器（Virtual Server）定义，该虚拟服务器的真实服务器（Real Server）是由相应Service对象的后端端点组成，到达虚拟服务器VIP（虚拟IP地址）上的服务端口的请求流量由默认或指定的调度算法分发至相关的各真实服务器。 ^36511877-54-13558-13872

  • ⏱ 2021-12-03 11:15:11

• 📌 除了更加多样的调度算法选择外，它的转发性能并没有显著提升，不过因为避免了使用大量的iptables规则，所以系统资源开销显著降低 ^36511877-54-15394-15458

  • ⏱ 2021-12-03 11:22:08

7.5 Kubernetes服务发现 §

• 📌 服务发现就是服务或者应用之间互相定位的过程 ^36511877-55-648-669

  • ⏱ 2021-12-03 11:25:21

• 📌 服务发现机制的基本实现，一般是事先部署好一个网络位置较为稳定的服务注册中心（也称为服务总线），由服务提供者（服务端）向注册中心注册自己的位置信息，并在变动后及时予以更新，相应地，服务消费方周期性地从注册中心获取服务提供者的最新位置信息，从而“发现”要访问的目标服务资源。 ^36511877-55-904-1039

  • ⏱ 2021-12-03 11:26:55

• 📌 在服务的动态性很强的场景中，DNS记录的传播速度可能会跟不上服务的变更速度，因此它并不适用于微服务环境。 ^36511877-55-1454-1506

  • ⏱ 2021-12-03 11:33:15

• 📌 在传统实践中，常见的服务注册中心是ZooKeeper和etcd等分布式键值存储系统，它们可提供基本的数据存储功能，但距离实现完整的服务发现机制还有大量的二次开发任务需要完成。而且，它们更注重数据一致性而不得不弱化可用性（分布式系统的CAP理论），这背离了微服务发现场景中更注重服务可用性的需求。 ^36511877-55-1532-1679

  • ⏱ 2021-12-03 11:33:41

8.1 Kubernetes控制器基础 §

• 📌 这一类负责把API Server上存储的对象定义实例化到集群上的程序就是控制器。 ^36511877-59-615-655

  • ⏱ 2021-12-03 12:56:41

• 📌 控制器需要运行为守护进程：一方面，注册监视API Server上隶属该控制器类型的对象定义（spec）的变动，及时将变动反映到集群中的对象实例之上；另一方面，通过控制循环（control loop，也可称为控制回路）持续监视集群上由其负责管控的对象实例的实际状态，在因故障、更新或其他原因导致当前状态（Status）发生变化而与期望状态（spec）时，通过实时运行相应的程序代码尝试让对象的真实状态向期望状态迁移和逼近。 ^36511877-59-655-865

  • ⏱ 2021-12-03 12:57:43

• 📌 通常，一个工作负载控制器资源通常应该包含3个基本的组成部分。▪标签选择器：匹配并关联Pod对象，并据此完成受其管控的Pod对象的计数。▪期望的副本数：期望在集群中精确运行受控的Pod对象数量。▪Pod模板：用于新建Pod对象使用的模板资源。 ^36511877-59-3566-3767

  • ⏱ 2021-12-03 13:12:34

• 📌 DaemonSet控制器用于确保集群中每个工作节点或符合条件的每个节点上都运行着一个Pod副本，而非某个预设的精确数量值，因而不具有上面组成部分中的第二项。 ^36511877-59-3849-3927

  • ⏱ 2021-12-03 13:13:23

8.3 Deployment控制器 §

• 📌 Deployment是标准的API资源类型，它以ReplicaSet资源为基础资源进行应用编排，并能够自动实现策略式滚动更新或单批次重建式更新 ^36511877-61-1612-1683

  • ⏱ 2021-12-03 17:10:11

• 📌 尽管滚动更新以节约系统资源著称，但它也存在着一些劣势。直接改动现有环境，会为系统引入不确定性风险，而且一旦在更新过程中遇到问题，回滚操作的过程会较为缓慢。有鉴于此，金丝雀部署可能是较为理想的实现方式。 ^36511877-61-9889-9989

  • ⏱ 2021-12-03 17:45:38

• 📌 暂停Deployment资源的更新过程，需要将其spec.pause字段的值从false修改为true，这可通过修改资源规范后再次应用（apply）完成，也可通过kubectl rollout pause命令进行。 ^36511877-61-14893-15000

  • ⏱ 2021-12-03 18:00:33

8.4 StatefulSet控制器 §

• 📌 事实上，在云原生应用的体系里有两组常用的近义词：第一组是无状态（stateless）、牲畜（cattle）、无名（nameless）和可丢弃（disposable），它们都可用于表述无状态应用；另一组是有状态（stateful）、宠物（pet）、具名（having name）和不可丢弃（non-disposable），它们都可用于表示有状态应用。 ^36511877-62-891-1065

  • ⏱ 2021-12-03 18:15:08

• 📌 有状态应用进程客户端的每次连接都在先前事务的上下文中执行，并可能会受到该上下文的影响，事务意外中断时其上下文和历史行为会被进程予以存储，从而能支持客户端恢复该连接。这种处理方式表明，有状态应用进程对同一个客户端的请求处理应该始终由同一服务器进行。多实例场景中，管理员或代理服务器需要独立标识每个客户端及每个后端服务器，并为一个特定的客户端建立到后端某服务器的固定映射关系。于是，有状态应用的编排模型也就必然要求控制器能独立识别每个Pod对象，确保每个Pod对象故障时的替代者仍能具有相同的标识且拥有先前实例特有的上下文，而这种上下文数据在先后实例间的传递通常要借助每个Pod自身专用的存储卷完成。 ^36511877-62-567-865

  • ⏱ 2021-12-03 18:31:19

• 📌 对于拥有N个副本的StatefulSet资源来说，它会以{0…N–1}依次对各Pod对象进行编号及顺序创建，当前Pod对象就绪后才会创建下一个，删除则以相反的顺序进行，每个Pod删除完成后才会继续删除前一个。 ^36511877-62-1626-1744

  • ⏱ 2021-12-03 18:35:32

• 📌 删除Pod对象甚至是StatefulSet控制器，并不会删除其相关的PV资源以确保数据可用性 ^36511877-62-2185-2231

  • ⏱ 2021-12-03 18:44:59

• 📌 多数有状态应用都不支持规模性安全、快速的缩减操作，因此StatefulSet控制器不支持并行缩容机制，而是要严格遵守一次仅能终止一个Pod资源的法则，以免导致数据讹误。这通常也意味着，存在错误且未恢复的Pod资源时，StatefulSet资源会拒绝启动缩容操作。此外，缩容操作导致的Pod资源终止同样不会删除其相关的PV，以确保数据可用。 ^36511877-62-2708-2877

  • ⏱ 2021-12-03 18:48:43

• 📌 StatefulSet资源的滚动更新还支持分区（partition）机制，用户可基于某个用于分区的索引号对Pod资源进行分区，所有大于等于此索引号的Pod对象会被滚动更新，如图8-17所示，而小于此索引号的则不会被更新 ^36511877-62-3053-3162

  • ⏱ 2021-12-03 18:52:35

• 📌 一般说来，一个典型的、完整可用的StatefulSet资源通常由两个组件构成：Headless Service和StatefulSet资源。Headless Service用于为各Pod资源固定、唯一的标识符生成可解析的DNS资源记录，StatefulSet用于编排Pod对象，并借助volumeClaimTemplate以静态或动态的PV供给方式为各Pod资源提供专有且固定的存储资源。 ^36511877-62-1406-1600

  • ⏱ 2021-12-03 18:54:11

• 📌 Followers节点仅支持只读操作，它们会把接收到的写请求通过307响应码重定向给Leader节点 ^36511877-62-6846-6896

  • ⏱ 2021-12-05 13:48:33

8.8 Pod中断预算 §

• 📌 用户可以为那些部署在Kubernetes的任何应用程序创建一个对应PDB对象以限制自愿中断时最大可以中断的副本数或者最少应该保持可用的副本数，从而保证应用自身的可用性。 ^36511877-66-812-896
  • ⏱ 2021-12-05 14:45:00

第9章 认证、授权与准入控制 §

• 📌 来者是谁 ^36511877-69-440-444

  • ⏱ 2021-12-05 14:51:33

• 📌 他有权做哪些事 ^36511877-69-462-469

  • ⏱ 2021-12-05 14:51:37

9.1 Kubernetes访问控制 §

• 📌 客户端认证操作由API Server配置的一到多个认证插件完成。收到请求后，API Server依次调用配置的认证插件来校验客户端身份，直到其中一个插件可以识别出请求者的身份为止。授权操作则由一到多个授权插件完成，这些插件负责确定通过认证的用户是否有权限执行发出的资源操作请求，该类操作包括创建、读取、删除或修改指定的对象等。随后，通过授权检测的用户请求修改相关的操作还要经由一到多个准入控制插件的遍历式检测，例如使用默认值补足要创建的目标资源对象中未定义的各字段、检查目标Namespace资源对象是否存在、检查请求创建的Pod对象是否违反系统资源限制等，而其中任何的检查失败都可能会导致写入操作失败。 ^36511877-70-1081-1383

  • ⏱ 2021-12-05 15:03:07

• 📌 Kubernetes支持的认证方式包括X.509数字证书、承载令牌（bearer token，也称为不记名令牌）、身份验证代理（authenticating proxy）和HTTP Basic认证等。 ^36511877-70-3565-3665

  • ⏱ 2021-12-05 16:34:19

• 📌 静态令牌文件认证 ^36511877-70-4196-4204

  • ⏱ 2021-12-05 16:50:33

• 📌 X509客户端证书认证 ^36511877-70-4450-4461

  • ⏱ 2021-12-05 16:50:58

• 📌 OpenID Connect令牌认证：简称为OIDC，是OAuth 2协议的一种扩展 ^36511877-70-5340-5382

  • ⏱ 2021-12-05 16:59:42

• 📌 主要扩展是返回的附加字段 ^36511877-70-5437-5449

  • ⏱ 2021-12-05 17:06:12

• 📌 JSON Web令牌 ^36511877-70-5468-5478

  • ⏱ 2021-12-05 17:16:27

• 📌 API Server主要支持使用4类内置的授权插件来定义用户的操作权限。▪Node：基于Pod资源的目标调度节点来实现对kubelet的访问控制。▪ABAC：Attribute-based access control，基于属性的访问控制。▪RBAC：Role-based access control，基于角色的访问控制。▪Webhook：基于HTTP回调机制实现外部REST服务检查，确认用户授权的访问控制。 ^36511877-70-7170-7484

  • ⏱ 2021-12-05 17:24:57

• 📌 准入控制器[1]（admission controller）则用于在客户端请求经过身份验证和授权检查之后，将对象持久化存储到etcd之前拦截请求 ^36511877-70-7709-7825

  • ⏱ 2021-12-05 17:28:40

• 📌 而读取资源信息的操作请求则不会经由准入控制器检查 ^36511877-70-7861-7885

  • ⏱ 2021-12-05 17:28:50

9.2 ServiceAccount及认证 §

• 📌 Secret对象默认的挂载路径是/var/run/secrets/kubernetes.io/serviceaccount。与API Server交互时，工作负载进程会使用该目录下的ca.crt证书文件验证API Server的服务器证书是否为自己信任的证书颁发机构（所在集群的kubernetes-ca）所签发；验证服务器身份成功通过后，工作负载向API Server请求操作namespace文件指定的名称空间中的资源时，会将token文件中的令牌以承载令牌的认证方式提交给API Server进行验证，权限校验则由授权插件完成。 ^36511877-71-9098-9365
  • ⏱ 2021-12-05 18:21:17

9.3 X509数字证书认证 §

• 📌 X509数字证书认证常用的方式有“单向认证”和“双向认证”。SSL / TLS最常见的应用场景是将X.509数字证书与服务器端关联，但客户端不使用证书。单向认证是客户端能够验证服务端的身份 ^36511877-72-388-482

  • ⏱ 2021-12-05 18:32:22

• 📌 双向认证的场景中，服务端与客户端需各自配备一套数字证书，并拥有信任的签证机构的证书列表。 ^36511877-72-1320-1364

  • ⏱ 2021-12-05 18:33:00

• 📌 X509数字证书认证是Kubernetes默认使用的认证机制，采用双向认证模式。 ^36511877-72-1426-1466

  • ⏱ 2021-12-05 18:34:02

• 📌 Kubernetes集群中存在3个需要独立完成X509数字证书认证和HTTPS通信的体系：一是etcd集群成员、服务器及其客户端；二是API Server及其客户端，以及kubelet API及其客户端；三是Kubernetes认证代理体系中的服务器和客户端。这3个独立的体系各自需要一个独立证书颁发机构为体系内的服务器和客户端颁发证书，完成体系内的组件身份认证同时又彼此隔离 ^36511877-72-2232-2420

  • ⏱ 2021-12-05 18:41:43

9.4 kubeconfig配置文件 §

• 📌 kubeconfig文件中，各集群的接入端点以列表形式定义在clusters配置段中，每个列表项代表一个Kubernetes集群，并拥有名称标识；各身份认证信息（credentials）定义在users配置段中，每个列表项代表一个能够认证到某Kubernetes集群的凭据。将身份凭据与集群分开定义以便复用，具体使用时还要以context（上下文）在二者之间按需建立映射关系，各context以列表形式定义在contexts配置段中，而当前使用的映射关系则定义在current-context配置段中。 ^36511877-73-1166-1417

  • ⏱ 2021-12-05 19:08:14

• 📌 实践中，API Server支持的X509数字证书认证和OpenID Connect令牌认证才是客户端使用最多的认证方式 ^36511877-73-8326-8386

  • ⏱ 2021-12-05 19:09:49

9.5 基于角色的访问控制：RBAC §

• 📌 RBAC是一种特定的权限管理模型，它把可以施加在“资源对象”上的“动作”称为“许可权限”，这些许可权限能够按需组合在一起构建出“角色”及其职能，并通过为“用户账户或组账户”分配一到多个角色完成权限委派。这些能够发出动作的用户在RBAC中也称为“主体”。 ^36511877-74-1146-1272

  • ⏱ 2021-12-05 20:55:53

• 📌 Kubernetes系统的RBAC授权插件将角色分为Role和ClusterRole两类，它们都是Kubernetes内置支持的API资源类型，其中Role作用于名称空间级别，用于承载名称空间内的资源权限集合，而ClusterRole则能够同时承载名称空间和集群级别的资源权限集合。 ^36511877-74-2864-3005

  • ⏱ 2021-12-05 21:03:30

• 📌 RoleBinding可以引用同一名称中的Role，也可以引用集群级别的ClusterRole，但引用ClusterRole的许可权限会降级到仅能在RoleBinding所在的名称空间生效。 ^36511877-74-3280-3375

  • ⏱ 2021-12-05 21:07:23

• 📌 通常，我们可以把Kubernetes集群用户大体规划为集群管理员、名称空间管理员和用户（通常为开发人员）3类。 ^36511877-74-4061-4116

  • ⏱ 2021-12-05 21:11:14

• 📌 Role和ClusterRole资源上定义的rules也称为PolicyRule ^36511877-74-4775-4815

  • ⏱ 2021-12-05 21:13:59

• 📌 API Server内置了一组默认的ClusterRole和ClusterRoleBinding资源预留给系统使用，其中大多数都以system:为前缀。另外有一些不以system:为前缀的默认的ClusterRole资源是为面向用户的需求而设计，包括集群管理员角色cluster-admin，以及专用于授予特定名称空间级别权限的集群角色admin、edit和view ^36511877-74-16977-17160

  • ⏱ 2021-12-05 21:34:24

9.7 准入控制器 §

• 📌 准入控制也会根据准入控制器类型分阶段运行，第一个阶段串行运行各变异型控制器，第二阶段则串行运行各验证型控制器 ^36511877-76-1073-1127

  • ⏱ 2021-12-05 22:10:47

• 📌 尽管LimitRange资源能在名称空间上限制单个容器、Pod或PVC相关的系统资源用量，但用户依然可以创建出无数的资源对象，进而侵占集群上所有的可用系统资源。ResourceQuota资源能够定义名称空间级别的资源配额，从而在名称空间上限制聚合资源消耗的边界 ^36511877-76-6983-7113

  • ⏱ 2021-12-05 22:24:35

10.1 容器网络模型 §

• 📌 网络设备虚拟化技术 ^36511877-79-430-439

  • ⏱ 2021-12-06 11:57:31

• 📌 Bridge是指Linux内核支持的虚拟网桥设备，它模拟的是物理网桥设备，工作于数据链路层，根据习得的MAC地址表向设备端口转发数据帧。虚拟以太网接口设备对（veth pair）是连接虚拟网桥和容器的网络媒介：一端插入到容器的网络栈中，表现为通信接口（例如eth0等），另一端则于宿主机上关联虚拟网桥并被降级为当前网桥的“从设备”，失去调用网络协议栈处理数据包的资格，从而表现为桥设备的一个端口，如图10-1所示。图10-1　桥接式虚拟网络docker0 ^36511877-79-949-1458

  • ⏱ 2021-12-06 12:18:06

• 📌 同一个Pod内运行的多个容器通过lo接口即可在本地内核协议栈上完成交互 ^36511877-79-3090-3125

  • ⏱ 2021-12-06 12:24:19

• 📌 集群内的Pod间通信，即便通过Service进行“代理”和“调度”，但绝大部分都无须使用NAT，而是Pod间的直接通信 ^36511877-79-5053-5112

  • ⏱ 2021-12-06 13:02:13

• 📌 通常，遵循CNI规范的网络插件是一个可执行程序文件，它们可由容器编排系统（例如Kubernetes等）调用，负责向容器的网络名称空间插入一个网络接口并在宿主机上执行必要的任务以完成虚拟网络配置，因而通常被称为网络管理插件，即NetPlugin。随后，NetPlugin还需要借助IPAM插件为容器的网络接口分配IP地址，这意味着CNI允许将核心网络管理功能与IP地址分配等功能相分离，并通过插件组合的方式堆叠出一个完整的解决方案。简单来说，目前的CNI规范主要由NetPlugin和IPAM两个插件API组成 ^36511877-79-5949-6203

  • ⏱ 2021-12-06 13:14:15

• 📌 ▪veth设备：创建一个网桥，并为每个容器创建一对虚拟以太网接口，一个接入容器内部，另一个留置于根名称空间内添加为Linux内核桥接功能或OpenvSwitch（OVS）网桥的从设备。▪多路复用：多路复用可以由一个中间网络设备组成，它暴露多个虚拟接口，使用数据包转发规则来控制每个数据包转到的目标接口；MAC VLAN技术为每个虚拟接口配置一个MAC地址并基于此地址完成二层报文收发，IP VLAN则是分配一个IP地址并共享单个MAC，并根据目标IP完成容器报文转发。▪硬件交换：现今市面上有相当数量的NIC都支持SR-IOV（单根I/O虚拟化），SR-IOV是创建虚拟设备的一种实现方式，每个虚拟设备自身表现为一个独立的PCI设备，并有着自己的VLAN及硬件强制关联的QoS；SR-IOV提供了接近硬件级别的性能。 ^36511877-79-7926-8419

  • ⏱ 2021-12-06 13:29:49

• 📌 为Pod配置网络接口是NetPlugin的核心功能之一 ^36511877-79-7500-7527

  • ⏱ 2021-12-06 13:33:04

• 📌 目前，较为注流的实现方式有veth（虚拟以太网）设备、多路复用及硬件交换3种，如图10-6所示。 ^36511877-79-7574-7622

  • ⏱ 2021-12-06 13:33:09

• 📌 NetPlugin目前常用的实现方案有Overlay网络（Overlay Network）和Underlay网络（Underlay Network）两类。▪Overlay网络借助VXLAN、UDP、IPIP或GRE等隧道协议，通过隧道协议报文封装Pod间的通信报文（IP报文或以太网帧）来构建虚拟网络。▪Underlay网络通常使用direct routing（直接路由）技术在Pod的各子网间路由Pod的IP报文，或使用Bridge、MAC VLAN或IP VLAN等技术直接将容器暴露给外部网络。 ^36511877-79-6979-7283

  • ⏱ 2021-12-06 13:34:40

• 📌 若能够直接连接宿主机上的虚拟网桥形成一个大的局域网，就能在数据链路层打通各宿主机上的内部网络，让容器可通过自有IP地址直接通信。 ^36511877-79-9998-10062

  • ⏱ 2021-12-06 13:46:59

• 📌 借助宿主机间的通信网络构建的通信“隧道”进行数据帧转发 ^36511877-79-10213-10240

  • ⏱ 2021-12-06 13:50:51

• 📌 隧道转发的本质是将容器双方的通信报文分别封装成各自宿主机之间的报文，借助宿主机的网络“隧道”完成数据交换。这种虚拟网络的基本要求是各宿主机只需支持隧道协议即可，对于底层网络没有特殊要求。 ^36511877-79-10622-10715

  • ⏱ 2021-12-06 13:52:51

• 📌 VXLAN协议是目前最流行的Overlay网络隧道协议之一 ^36511877-79-10741-10770

  • ⏱ 2021-12-06 13:53:34

• 📌 采用L2 over L4（MAC-in-UDP）的报文封装模式 ^36511877-79-10830-10861

  • ⏱ 2021-12-06 13:57:49

• 📌 为了确保VXLAN机制通信过程的正确性，涉及VXLAN通信的IP报文一律不能分片，这就要求物理网络的链路层实现中必须提供足够大的MTU值，或修改其MTU值以保证VXLAN报文的顺利传输。 ^36511877-79-11031-11124

  • ⏱ 2021-12-06 14:00:48

• 📌 VTEP代表着一类支持VXLAN协议的交换机，而支持VXLAN协议的操作系统也可将一台主机模拟为VTEP ^36511877-79-11366-11418

  • ⏱ 2021-12-06 14:02:18

• 📌 VXLAN网络中的容器在首次通信之前，源VTEP又如何得知目标服务器在哪一个VTEP，并选择正确的路径传输通信报文呢？常见的解决思路一般有两种：多播和控制中心。 ^36511877-79-12206-12286

  • ⏱ 2021-12-06 14:32:58

• 📌 控制中心则在某个共享的存储服务上保存所有容器子网及相关VTEP的映射信息，各主机上运行着相关的守护进程，并通过与控制中心的通信获取相关的映射信息 ^36511877-79-12335-12407

  • ⏱ 2021-12-06 14:33:11

• 📌 MAC VLAN允许传输广播和多播流量，但它要求物理接口工作于混杂模式 ^36511877-79-14073-14108

  • ⏱ 2021-12-06 14:57:24

• 📌 在较大规模的主机集群中，问题的关键便转向如何更好地为每个主机维护路由表信息 ^36511877-79-16607-16644

  • ⏱ 2021-12-06 15:38:11

• 📌 Flannel不过是借助delegate向Bridge插件传递部分配置参数，例如网络地址10.244.0.0/16等信息 ^36511877-79-22669-22729

  • ⏱ 2021-12-06 16:12:02

• 📌 发夹模式，在容器中的应用通过宿主机的端口映射（NAT）访问自己提供的服务时，此模式必须要置于启用状态，因为默认情况下，网桥设备不允许一个数据报文从同一端口进行收发操作，而发夹模式正是用于取消限制 ^36511877-79-22793-22890

  • ⏱ 2021-12-06 16:15:25

• 📌 CNI的基本思想是为容器运行时环境在创建容器时，先创建好netns，然后调用CNI插件为这个netns配置网络，而后启动容器内的进程。 ^36511877-79-23157-23224

  • ⏱ 2021-12-06 16:21:09

• 📌 本地虚拟网桥（cni0） ^36511877-79-23575-23587

  • ⏱ 2021-12-06 16:21:56

10.2 Flannel网络插件 §

• 📌 VXLAN Overlay网络可正常运行在任何能够传输常规UDP报文的环境中，包括存在很多底层限制的公有云环境。 ^36511877-80-8708-8764
  • ⏱ 2021-12-06 17:07:07

10.3 Calico网络插件 §

• 📌 Flannel相比，Calico的一个显著优势是对网络策略的支持，它允许用户动态定义访问控制规则以管控进出容器的数据报文，从而为Pod间通信按需施加安全策略。 ^36511877-81-491-570

  • ⏱ 2021-12-06 17:33:49

• 📌 Calico把Kubernetes集群环境中的每个节点上的Pod所组成的网络视为一个自治系统，而每个节点也就自然由各自的Pod对象组成虚拟网络，进而形成自治系统的边界网关。各节点间通过BGP协议交换路由信息并生成路由规则。 ^36511877-81-1194-1305

  • ⏱ 2021-12-06 17:40:20

• 📌 配置所有节点作为BGP对等节点（BGPPeer）向路由反射器发送路由信息 ^36511877-81-19517-19553

  • ⏱ 2021-12-06 21:16:36

10.4 网络策略 §

• 📌 NetworkPolicy就是定义在一组Pod资源上的Ingress规则或Egress规则，或二者的组合定义 ^36511877-82-1670-1724

  • ⏱ 2021-12-06 21:26:31

• 📌 即便Egress规则拒绝了所有流量，但由Ingress规则放行的请求流量的响应报文依然能够正常出站，它并不受限于Egress规则的定义，反之亦然。 ^36511877-82-4513-4586

  • ⏱ 2021-12-06 21:33:46

11.1 Kubernetes调度器 §

• 📌 过滤掉那些无法满足Pod运行条件的节点，而后对满足过滤条件的各个节点进行打分，并按综合得分进行排序，最后从优先级排序结果中挑选出得分最高节点作为适合目标Pod的最佳节点 ^36511877-86-1538-1622
  • ⏱ 2021-12-06 22:23:10

11.2 节点亲和调度 §

• 📌 节点亲和调度机制支持Pod资源定义自身对期望运行的某类节点的倾向性，倾向于运行指定类型的节点即为“亲和”关系，否则即为“反亲和”关系。 ^36511877-87-499-566

  • ⏱ 2021-12-06 22:24:40

• 📌 Pod上定义节点亲和规则时有两种类型的节点亲和关系：强制（required）亲和和首选（preferred）亲和，或分别称为硬亲和与软亲和 ^36511877-87-593-662

  • ⏱ 2021-12-06 22:25:25

11.3 Pod亲和调度 §

• 📌 出于高效通信等需求，偶尔需要把一些Pod对象组织在相近的位置（同一节点、机架、区域或地区等），例如应用程序的Pod及其后端提供数据服务的Pod等，我们可以认为这是一类具有亲和关系的Pod对象。偶尔，出于安全或分布式容灾等原因，也会需要把一些Pod对象与其所运行的位置隔离开来，例如在IDC中的区域运行某应用的单个代理Pod对象等，我们可把这类Pod对象间的关系称为反亲和。 ^36511877-88-386-572
  • ⏱ 2021-12-06 22:32:04

11.4 节点污点与Pod容忍度 §

• 📌 污点是定义在节点之上的键值型属性数据，用于让节点有能力主动拒绝调度器将Pod调度运行到节点上，除非该Pod对象具有接纳节点污点的容忍度。容忍度（tolerations）则是定义在Pod对象上的键值型属性数据，用于配置该Pod可容忍的节点污点。 ^36511877-89-390-511

  • ⏱ 2021-12-06 22:41:36

• 📌 支持使用污点自动标识问题节点，它通过节点控制器在特定条件下自动为节点添加污点信息 ^36511877-89-7449-7489

  • ⏱ 2021-12-06 22:53:07

12.3 控制器与Operator §

• 📌 封装了相关资源复杂运维逻辑的控制器通常被称为Operator ^36511877-96-587-617

  • ⏱ 2021-12-07 13:25:01

• 📌 同一对象有多次变动事件待处理时，控制器仅需要处理其最新一次变动 ^36511877-96-1562-1593

  • ⏱ 2021-12-07 13:44:35

• 📌 client-go组件其实就是一个带有本地缓存和索引机制的API Server客户端，是自定义控制器同API Server进行数据同步的重要组件。 ^36511877-96-2906-2979

  • ⏱ 2021-12-07 14:00:54

12.4 Kubernetes集群高可用 §

• 📌 堆叠式etcd ^36511877-97-2330-2337

  • ⏱ 2021-12-07 14:44:55

• 📌 外部etcd集群 ^36511877-97-2599-2607

  • ⏱ 2021-12-07 14:44:58

• 📌 同一控制平面中，多个协同的kube-controller-manager实例要同时启用—leader-elect=true选项以自动实现leader选举。选举过程完成后，仅leader实例处于活动状态，余下的其他实例均转入等待模式，它们会在探测到leader故障时触发新一轮的选举操作。 ^36511877-97-3650-3794

  • ⏱ 2021-12-07 14:57:18

• 📌 kube-controller-manager集群各自的选举操作仅是通过在kube-system名称空间中创建一个与程序同名的Endpoint资源对象实现。 ^36511877-97-3824-3902

  • ⏱ 2021-12-07 14:57:43

• 📌 这种leader选举操作是分布式锁机制的一种应用 ^36511877-97-4181-4205

  • ⏱ 2021-12-07 15:02:12

13.1 Ingress资源 §

• 📌 从本质上来说，Ingress资源基于HTTP虚拟主机或URL路径的流量转发规则，它把需要暴露给集群外部的每个Service对象，并映射为Ingress控制器上的一个虚拟主机或某虚拟主机上的一个PATH路径（例如/auth等） ^36511877-100-858-970

  • ⏱ 2021-12-07 15:37:27

• 📌 一个含有私钥和证书的Secret对象 ^36511877-100-12402-12420

  • ⏱ 2021-12-07 16:30:19

13.2 Ingress控制器部署与应用 §

• 📌 Ingress控制器自身也是运行在Pod中的容器应用，它们是一类具有代理及负载均衡功能的守护进程，而注册监视API Server上的Ingress资源，可根据这些资源上定义的流量路由规则生成相应应用程序专有格式的配置文件，并通过重载或重启守护进程而生效新配置。 ^36511877-101-399-529

  • ⏱ 2021-12-07 16:42:36

• 📌 在Kubernetes上，Ingress才是发布HTTP应用的更好的方式 ^36511877-101-12665-12701

  • ⏱ 2021-12-07 16:48:31

13.3 Contour控制器 §

• 📌 构建在单个Envoy API提供的数据平面服务之上的多个管理API（例如Istio、Linkerd等） ^36511877-102-4019-4070

  • ⏱ 2021-12-07 17:27:29

• 📌 具体到应用层面，Envoy既可以工作于微服务基础设施内部，作为面向服务架构内部的流量通信总线（仅负责系统内部各服务间的通信），为服务管控Ingress或（和）Engress流量，也能够作为整个微服务系统的边缘代理管控系统与外部交互的流量。 ^36511877-102-4483-4602

  • ⏱ 2021-12-07 17:31:42

• 📌 Contour提供的CRD资源类型HTTPProxy能够提供更为完整的路由功能集，大大丰富了Ingress的特性表现 ^36511877-102-9257-9315

  • ⏱ 2021-12-07 17:40:41

• 📌 HTTPProxy也允许用户为每个后端服务使用weight字段指定一个特定流量百分比，从而将流量以指定的比例在不同的后端服务间进行分发 ^36511877-102-18297-18364

  • ⏱ 2021-12-07 17:49:08

• 📌 流量镜像用于百分百地在两个服务间复制流量。在支持蓝绿部署的场景中，流量镜像常用于将当前服务上的真实流量引入到未发布的新版本上进行测试。但流量镜像工作于“只读”模式，因为其响应报文会被全部丢弃。 ^36511877-102-20700-20796

  • ⏱ 2021-12-07 17:53:11

• 📌 粘性会话调度机制，把来自某客户端的所有请求始终调度给同一个后端端点。 ^36511877-102-21778-21812

  • ⏱ 2021-12-07 17:54:09

• 📌 等待一定的时间后自动超时 ^36511877-102-24418-24430

  • ⏱ 2021-12-07 17:59:11

• 📌 瞬态故障 ^36511877-102-23851-23855

  • ⏱ 2021-12-07 18:00:26

• 📌 HTTPConnectionManager是最著名的过滤器之一，它是Envoy处理HTTP协议报文的核心框架，并引入了众多相关的7层（L7）过滤器 ^36511877-102-27409-27482

  • ⏱ 2021-12-07 18:07:48

14.1 Kustomize声明式应用管理 §

• 📌 Kustomize实现了一种非模板式的应用管理能力，它允许用户以一个应用描述文件为基础，而后将保存了具体需求的“补丁”文件以“叠加”的方式在基础文件之上添加、删除或更新应用配置，进而生成最终的应用版本。 ^36511877-106-648-749
  • ⏱ 2021-12-07 18:17:01

14.3 Helm Chart §

• 📌 从物理的角度来描述，Chart就是一个遵循特定规范的目录结构，它能够打包成一个可用于部署的版本化归档文件。 ^36511877-108-532-585
  • ⏱ 2021-12-07 20:56:39

14.4 Helm实践：部署Harbor注册中心 §

• 📌 Harbor项目是用于存储和分发容器镜像的企业级Registry（注册中心）开源解决方案 ^36511877-109-398-442
  • ⏱ 2021-12-07 21:31:06

15.1 资源监控与资源指标 §

• 📌 核心指标管道中的指标主要包括CPU累计使用、内存即时利用率、Pod资源占用率及容器的磁盘占用率等。 ^36511877-112-5560-5609

  • ⏱ 2021-12-07 22:58:23

• 📌 Kubernetes系统上能同时使用资源指标API和自定义指标API的代表组件是HPA v2控制器（HorizontalPodAutoscaler），它能够基于观察到的指标自动缩放Deployment或ReplicaSet一类控制器编排的应用程序的规模。 ^36511877-112-6007-6134

  • ⏱ 2021-12-07 23:06:35

15.2 资源指标与应用 §

• 📌 Metrics Server基于内存存储，重启后数据将全部丢失，而且它仅能留存最近收集到的指标数据，因此，如果用户希望访问历史数据，就不得不借助第三方的监控系统（例如Prometheus等）或自行开发实现这样的功能。 ^36511877-113-1705-1813
  • ⏱ 2021-12-07 23:23:12

15.3 自定义指标与Prometheus §

• 📌 k8s-prometheus-adapter ^36511877-114-673-695

  • ⏱ 2021-12-08 15:12:14

• 📌 主要基于Prometheus收集和存储指标数据，并借助k8s-prometheus-adapter或kube-metrics-adapter等适配器项目将这些指标数据查询接口转换为标准的Kubernetes自定义指标API是较为流行的解决方案。 ^36511877-114-1178-1300

  • ⏱ 2021-12-08 15:12:45

• 📌 为了避免Prometheus程序崩溃或重启时丢失数据，它使用预写日志（write ahead log）对当前窗口中的数据进行持久化。 ^36511877-114-5373-5439

  • ⏱ 2021-12-08 15:30:06

• 📌 最为常用的通用可视化接口是Grafana，它是一款开源的度量分析与可视化套件，通过访问时序数据库（Prometheus就是其中一种）获取数据，并以较美观的形式展示自定义报表和图形等。 ^36511877-114-6098-6189

  • ⏱ 2021-12-08 15:38:54

• 📌 记录规则通过把那些使用频繁或者计算量较大的表达式预先进行周期性计算，并将其结果保存为一组新的时间序列，以结果直接响应客户端查询，从而大大提升其响应速度。 ^36511877-114-6417-6493

  • ⏱ 2021-12-08 15:41:37

• 📌 告警规则也是一种预先定义在配置文件中的表达式，只不过它定义的是告警触发条件，Prometheus周期性地评估这些条件表达式，并在满足触发条件时根据用户指定的配置将告警通知发送至外部的告警服务以作出进一步处理。 ^36511877-114-6519-6623

  • ⏱ 2021-12-08 15:42:39

• 📌 Prometheus Pushgateway的设计目标是为了允许临时任务或批处理作业向Prometheus暴露其指标。由于这类的工作任务可能只存活较短的时间，可能会错过Prometheus Server的抓取周期，因此需要将这些指标推送到Pushgateway，并由Prometheus通过Pushgateway进行抓取。 ^36511877-114-7218-7379

  • ⏱ 2021-12-08 15:46:17

• 📌 Counter代表一个随着时间而不断累积的数据 ^36511877-114-9078-9101

  • ⏱ 2021-12-08 15:53:30

• 📌 Gauge表示可增可减的数据量，一般代表采样那个时间点的瞬时值 ^36511877-114-9281-9312

  • ⏱ 2021-12-08 15:53:39

• 📌 Histogram事先将特定测度可能的取值范围分隔为多个样本空间，并通过对落入bucket内的观测值进行计数以及求和等操作。但Prometheus取值间隔的划分方式与前述通用方式略有不同，它采用的是累积区间间隔机制，即每个bucket中的样本均包含了前面所有bucket中的样本。 ^36511877-114-9725-9865

  • ⏱ 2021-12-08 15:57:23

• 📌 Summary是一种类似于Histogram的指标类型，但它在客户端一段时间内（默认为10分钟）的每个采样点直接进行统计计算并存储了分位数数值，Server端直接抓取相应值即可。但Summary不支持sum或avg一类的聚合运算，而且其分位数由客户端计算并生成，Server端无法获取客户端未定义的分位数，而Histogram可通过PromQL任意定义，有着较好的灵活性。 ^36511877-114-10677-10863

  • ⏱ 2021-12-08 16:01:24

• 📌 事实上，k8s-prometheus-adapter适配器自身就是客户端与Prometheus Server之间的代理网关，它将Kubernetes自定义指标API（custom.metrics.k8s.io）中的每一个指标与一个特定的PromQL表达式建立起对应关系，客户端对该自定义指标的查询请求也将由适配器相应转换为PromQL语句，转发给后端的Prometheus Server，Prometheus Server的响应报文再以适配器指标格式响应给客户端。 ^36511877-114-33824-34056

  • ⏱ 2021-12-08 16:26:06

15.4 自动弹性缩放 §

• 📌 HPA：一种支持控制器对象下Pod规模弹性缩放的工具 ^36511877-115-591-617

  • ⏱ 2021-12-08 09:24:26

• 📌 VPA：是Pod应用垂直缩放工具，它通过调整Pod对象的CPU和内存资源需求量完成扩展或收缩。 ^36511877-115-1146-1193

  • ⏱ 2021-12-08 09:24:50

• 📌 每个指标单独计算其所需的副本数，所有指标计算结果中的最大值为最终采用的副本数量 ^36511877-115-9668-9707

  • ⏱ 2021-12-08 11:53:31

16.1 集群日志系统基础 §

• 📌 Fluentd、Fluent Bit或Filebeat是在Kubernetes中收集并汇总日志的最常用解决方案 ^36511877-118-2705-2760

  • ⏱ 2021-12-08 12:37:35

• 📌 考虑托管到Kubernetes集群本地的日志管理系统在集群本身出现问题时将难以获取到日志信息，我们强烈建议将日志存储在Kubernetes集群外运行的日志工具上。 ^36511877-118-3439-3520

  • ⏱ 2021-12-08 12:38:23

• 📌 Elasticsearch支持把索引切分为一到多个“分片”，各个分片还可拥有1个或以上的副本以实现冗余功能 ^36511877-118-4414-4467

  • ⏱ 2021-12-08 12:44:32

• 📌 索引分片数量在创建后将不能够再改变，除非重新索引数据。 ^36511877-118-5053-5080

  • ⏱ 2021-12-08 12:50:19

• 📌 集群中的每个节点都可以处理HTTP和Transport流量，它们都知道任一文档的具体位置，可完成请求路由，因而都有处理任意请求的能力，这其实是“协调节点”的角色职能。施加在文档之上的所有写操作（例如创建、修改和删除等）只能先由主分片完成后再复制给副本分片，但读请求（例如搜索操作等）将由协调节点轮询给该索引的所有副本分片，以分散负载。 ^36511877-118-5191-5358

  • ⏱ 2021-12-08 12:51:09

• 📌 Kibana是一个开源的分析和可视化平台，旨在与Elasticsearch合作。Kibana提供搜索、查看和与存储在Elasticsearch索引中的数据进行交互的功能。开发者或运维人员可以轻松地进行高级数据分析，并在各种图表、表格和地图中将数据可视化。 ^36511877-118-7912-8039

  • ⏱ 2021-12-08 14:04:08

16.2 EFK日志管理系统 §

• 📌 EFK是Kubernetes系统上流行的日志管理系统解决方案之一，它通过Fluentd、Fluent Bit或Filebeat一类的节点级代理程序进行日志采集，实时推送给Elasticsearch集群进行存储和分析，而后再经由Kibana进行数据可视化。这种组合通常简称为EFK。 ^36511877-119-388-528

  • ⏱ 2021-12-08 14:06:51

• 📌 Fluent Bit常作为日志转发器（forwarder）使用，而Fluentd则是日志聚合器（aggregator） ^36511877-119-10248-10307

  • ⏱ 2021-12-08 14:22:52

读书笔记 §

1.3 应用的运行与互联互通 §

划线评论 §

• 📌 UTS名称空 ^3533118-7vcmpQ6my
  • 💭 UTS名称空间是关于隔离主机名的
  • ⏱ 2021-11-30 14:15:31

3.1 资源对象与API群组 §

划线评论 §

• 📌 Service是Kubernetes标准的资源类型之一，用于为工作负载实例提供固定的访问入口及负载均衡服务 ^3533118-7vczLV3gy
  • 💭 比如azure的静态ip地址就是一种sercice
  • ⏱ 2021-11-30 17:39:27

本书评论 §