云原生|Kubernetes技术架构

01：容器运行时技术深度剖析

1.1 容器引擎和运行时机制原理解析

• kubernetes定义的容器运行时接口：CRI，当前较为主流的实现包括dockershim、cri-containerd、cri-o
• OCI runtime spec 定义了运行时实现中，文件格式和命令行格式，runc、kata、gVisor等运行时都符合这个标准
• Containerd定义了一套trrpc接口，方便运行时实现者更好地进行容器状态管理

1.2 业界主流容器运行时技术架构剖析

• Runc: 基于linux的namespace、cgroup和capability等技术实现隔离的容器实现
• Kata containers：基于虚拟化隔离技术的容器实现
• gVisor：一种基于拦截系统调用的实现隔离的容器实现

1.3 华为云容器运行时技术架构剖析

• 基于EulerOS和自研的qumu-microvm对安全容器进行了轻量化改造
• 支持GPU、nvlink等各种硬件设备
• 安全容器和华为云的VPC网络等服务无缝对接

1.4 容器运行时技术的发展方向

• 通过rust改写，减少host进程，进一步轻量化hypervisor等方式实现更加轻量级的安全容器
• 结合机密计算技术，实现更加安全的容器技术

02：Kubernetes技术架构深度剖析

2.1 Kubernetes系统架构详解

• K8S是谷歌开源的容器集群管理系统；他构建在容器之上，为容器化的应用提供资源调度，部署运行，服务发现，扩容缩容等一整套功能。
• 将容器宿主机组成集群，统一进行资源调度，自动管理容器生命周期，提供跨节点服务发现和负载均衡；更好的支持服务概念、划分、细分服务之间的边界，比如label，pod等概念的引入
• 轻量，迁移方便，部署快捷，插件化，可扩展

Kubernetes核心组件

2.2 controller控制器原理详解

Controller Manager主要提供了一个分发事件的能力，而不同的Controller只需要注册对应的Handler来等待接受和处理事件。
在Controller Manager的帮助下， Controller的逻辑可以做的非常纯粹，只需要实现相应的EventHandler即可，以Deployment controller为例。

• List & Watch
• Controller manager与api-server的通信主要有两种方式：List和Watch

• List是短连接实现，用于获取该资源的所有Object
• Watch是长连接实现，用于监听在List中获取的资源的变换
• api-server检测到资源产生变更时，会主动通知到Controller manager(利用分块传输编码)

• client-go
• 实现统一管理每种Controller的List和Watch
• 将收到的event事件放到缓存中，异步分发给每个Controller的注册的eventHandler

2.3 list-watch机制详解

3：Kubernetes高级调度原理

3.1 Kubernetes的调度流程原理与算法

Kubernetes default scheduler的特点：基于队列的调度器；一次调度一个Pod；调度时刻全局最优。

Kubernetes scheduler架构和调度流程

• Informer list/watch资源变化，更新queue和cache;
• NextPod() 从待调度队列获取队首的Pod;
• 从cache中获取Node列表
• 针对Pod和Nodelist执行Predicate算法，过滤掉不合适的节点，避免资源冲突，节点超载等
• 针对Pod和Nodelist执行Priority算法，给节点打分，优化资源分配，应用分布
• 根据打分，计算出得分最高的节点
• 当高优先级的Pod没有找到合适的节点时，调度器尝试为其抢占优先级低的Pod
• 当调度器为Pod选择了一个合适的节点时，通过Bind将Pod和节点进行绑定

3.2 Kubernetes高级调度算法

• Kubernetes中的Label通常用来标记“身份”、Selector机制查询过滤
• Node Affinity让Pod在一组指定的Node上运行

3.3 华为云CCE Volcano批量调度算法与应用场景

云计算批量计算面临的挑战：1、作业管理缺失；2、调度策略局限；3、领域计算框架支持不足；4、资源规划复用、异构计算支持不足

4：Kubernetes存储架构原理剖析（上）

4.1 K8s容器存储发展历程

容器存储能力

4.2 K8S持久化存储体系

名称	简介
PresistVolumn	简称pv,持久化存储，是k8s为云原生应用提一种拥有独立生命周期的、用户可管理的存储抽象设计
PresistVolumnClaim	简称pvc，吃计划存储声明，是K8S为解耦云原生应用和数据存储设计的，通过PVC可以让资源管控更加细致灵活、团队职责分离、应用模板更通用，进一步解除了用户被云平台锁定的顾虑
StorageClass	简称sc，存储类，是K8S平台为存储提供商提供存储接入的一种声明，通过sc和相应的存储插件
Deiver Plugin	存储驱动插件，由存储提供商提供，能够对接网络存储，并管理持久存储卷的生命周期

与临时存储相比，持久化存储的优势：

• 每个数据卷可以拥有独立的生命周期，不再跟随pod常见和销毁
• 使能计算+数据的迁移：存储卷中的数据可以随着pod在集群中迁移
• 多个不同的pod可以共享同一个存储卷

引入PV/SC之后带来更大的效益：

• 1 资源管控更加灵活，可适应资源管控严格、宽松的不同场景
• 2 团队职责更加明确，开发人员只需要考虑存储需求，不需要关注存储类型，升值品牌
• 3 灵活的扩展一些增强功能，比如：扩容、快照能力
• 4 应用模板更加通用，可通过配置参数，适应不同类型的K8S平台
• 5 进一步消除用户被存储提供商、云平台锁定的顾虑

4.3 PV/PVC的工作原理剖析

两种pv/pvc的工作方式

pv/pvc适合在资源管理比较严格的场景

• 1 开发人员向集群管理员申请存储需求
• 2 存储管理员按需求分配存储
• 3 集群管理员按照分配的存储创建pv
• 4 开发人员创建pvc, pvc关联合适的pv
• 5 开发人员创建pod，并且pod使用pvc

pvc绑定pv的流程

本课总结

名称	简介
StatefulSet	简称sts，有状态应用，一种K8S为用户提供一组有序、唯一、稳定的应用实例集合
Volumn	卷，K8S为存算分离所做的解耦设计，让用户更加专注于业务功能设计。它在K8S中是依托于Pod而使用的
PresistVolumn	简称pv,持久化存储，是k8s为云原生应用提一种拥有独立生命周期的、用户可管理的存储抽象设计
PresistVolumnClaim	简称pvc，吃计划存储声明，是K8S为解耦云原生应用和数据存储设计的，通过PVC可以让资源管控更加细致灵活、团队职责分离、应用模板更通用，进一步解除了用户被云平台锁定的顾虑
StorageClass	简称sc，存储类，是K8S平台为存储提供商提供存储接入的一种声明，通过sc和相应的存储插件（csi/flexvolumn）为容器应用提供动态分配存储卷的能力

05: Kubernetes存储架构原理剖析（下）

5.1 StorageClass工作原理分析

无论在资源管控严格还是资源管控敏捷的场景，资源管理员都希望通过创建K8S的存储接口来管理容器存储资源
K8S通过存储声明（PVC）、存储类（SC）和存储插件（driver）联合工作，满足用户一键式定义，创建存储。

• 1 用户在StatefulSet模板中定义对存储的需要
• 2 StatefulSet控制器负责将Claim模板转换为pvc
• 3 结合自定的sc和sc中指定的driver,创建应用苏需要的pv卷

5.2 CSI容器存储接口架构解读

什么是云原生存储

云原生的理解

• 1 从技术角度看：一种还在不断演进中的设计思想，它主要是为了充分利用云计算的优势，促进云计算技术发展而构建和运行应用的设计思想
• 2 从用户角度看：一种让用户从迭代慢、运维重、升级难得包袱中解脱出来，聚焦业务开展的设计思想

云原生应用的理解：基于云原生技术构建、运行的应用程序，它具有：

• 行为可预测，快速弹性扩缩容
• 持续交付，是研发流程更敏捷
• 基于API构建，团队协作更流畅
• 独立性强，促进DevOps的开展
• 依赖少，轻量，故障恢复快速

云原生存储的理解

• 1 从技术角度看：符合以应用为中心，可被声明和组合实现、是API驱动和服务自治、具有敏捷等特性的存储系统
• 2 从用户角度看：最大的利用云原生应用特性的存储系统

以CSI存储架构为例，解读容器存储架构

• 1 控制接口A:K8S平台通过控制接口调用存储提供商发布的控制API
• 2 控制接口B：K8S平台通过sideCar（external-provisioner/attacher等）调用存储提供商发布的控制API

• 3 数据接口C: 数据面，存储通过文件系统、块设备等方式为K8S平台中运行的workload提供存储读写等能力

  
  容器存储架构

5.3 云原生存储最佳实践：从FlexVolumn插件向CSI插件迁移

两种插件的对比

CSI架构：部署简单、功能强大、扩展灵活、容器存储接口的标准

08：Kubernetes运维管理详解（上）

8.1工作负载更新和回滚机制详解

无状态工作负载（deployment）更新

• Recreate: 停止所有旧版本然后部署新版本
• RollingUpdate: 滚动升级，即逐步创建新Pod再删除旧Pod，为默认策略
  可以通过maxSurge和maxUnavailable两个参数控制升级过程中重新创建Pod的比例
  在更新出现问题之后，可能需要对应用进行回滚。K8S支持根据deployment的历史版本进行回滚。
  有状态工作负载（StatefulSet）更新
• OnDelete：用户必须手动删除Pod以便让控制器创建新的Pod
• RollingUpdate：滚动更新过程也和Deployment大致相同，区别在于滚动更新的过程是有序的，支持部分实例滚动更新，部分不更新。
  有状态工作负载回滚：因为statefulset的使用对象是有状态服务，大部分有状态副本集都会用到持久化存储，statefulset下的每个pod正常情况下都会关联一个pv对象，对stateful对象回滚非常容易，但其使用的pv中保存的数据无法回滚，所以在生产环境下进行回滚时需要谨慎操作。

8.2 应用探针健康检查机制详解

容器健康检查使用liveness probe(工作负载存活探针)和readiness probe(工作负载业务探针)。
Kubernetes支持如下三种探测机制：

机制	原理
HTTP GET	向容器发送HTTP GET请求，如果probe收到2xx或3xx，说明容器是健康的
TCP Socket	尝试与容器指定端口建立TCP连接，如果连接成功，说明容器是健康的
Exec	Probe执行容器中的命令并检查命令退出的状态码，如果状态码为0则说明容器是健康的

8.3 应用弹性伸缩原理详解

弹性伸缩是根据业务需求和策略，经济地自动调整弹性计算资源的管理服务。包括工作负载弹性收缩和节点弹性收缩。

小结

名称	简介
liveness probe	工作负载存活探针，指示容器是否正在运行。如果存活态探测失败，则kubelet会杀死容器，并且容器将根据重启策略进行重启。如果容器不提供存活探针，则默认为Success
readiness probe	工作负载业务探针，指示容器是否准备好为请求提供服务。只有当Pod中的容器都处于就绪状态时kubelet才会认定该Pod处于就绪态。该信号的作用是控制哪些Pod应该作为service的后端。如果Pod处于非就绪状态，那么他们将会被从service的load balancer中移除
Cluster AutoScaler	简称CA，Autoscaler是Kubernetes提供的集群节点弹性伸缩组件，根据Pod调度状态及资源使用情况对集群的节点进行自动扩容和缩容
Horizontal Pod Autoscaler	简称HPA，是用来控制Pod水平伸缩的控制器，HPA周期性检查Pod的度量数据，计算满足HPA资源所配置的目标数值所需的副本数量，进而调整目标资源（如Deployment）的replices字段

09：Kubernetes运维管理详解（下）

9.1 集群可观测性

云原生应用特点：

设施	特点
应用架构	从单体应用向微服务过渡，应用架构过渡为松耦合系统，应用版本迭代更快、周期更短
基础设施层	容器化、应用自身快、轻、微，Kubernetes成为运行容器的默认平台，IaaS、PaaS平台底层来承载Kubernetes平台
软件生命周期	服务通过DevOps流水线持续部署，服务变更低成本和低风险，呈现高频率和全自动变更

云原生可观测性

数据类型	具体情况
Metrics	收集并存储海量指标，通过指标阈值等手段实现告警通知，从而告知有没有问题发生
Traces	通过告警指标发现问题后，依据调用追踪分析，进一步明确是什么问题
Logs	明确了问题发生的对象或者位置之后，通过日志分析等手段实现为什么问题会发生，即找到问题的根因

9.2 指标监控与prometheus

指标（Metrics）是在许多个连续的时间周期里度量的KPI数值，一般将指标进行如下分类：

指标	描述
系统指标	集群CPU使用率、磁盘使用率以及网络带宽等情况
应用指标	QPS、出错率、平均延时
业务指标	用户会话、订单数量和营业额等

目前，Prometheus已经成为云原生监控领域的事实标准

9.3常见集群故障排错分析

• 查看Kubernetes对象的当前运行时信息，特别是与对象关联的Event事件。这些事件记录了相关主题、发生时间、最近发生的时间、发生次数及事件原因等，对排查故障非常有价值
• 对于服务、容器方面的问题，可能需要深入容器内部进行故障诊断，此时可以通过查看容器日志来定位具体问题
• 对于某些复杂问题，例如Pod调度这种全局性问题，可能需要结合集群中的每个节点上的Kubernetes服务日志来排查。

10：Kubernetes安全权限管理深度剖析

Kubernetes本身并没有用户管理能力，无法像操作Pod一样，通过API的方式创建/删除一个用户实例，也无法在etcd中找到用户对应的存储对象
在Kubernetes的访问控制流程中，用户模型是通过请求方的访问控制凭证（如Kubectl使用的kube-config中的证书、Pod中引入的ServerAccount）产生

10.1 Kubernetes API 访问控制

认证

• 集群创建脚本或者集群管理员配置API服务器，使之运行一个或多个身份认证组件
• 认证步骤输入整个HTTP请求，主要检查头部和客户端证书
• 认证模块包含客户端证书、密码、普通令牌、引导令牌和JSON Web令牌，API server依次尝试每个验证模块，直到有一个成功。
• 如果请求认证不通过，服务器将以HTTP状态码401拒绝该请求

鉴权

• 认证通过后，可以识别具体的客户信息，并根据用户和请求信息进行鉴权。
• Kubernetes鉴权要求通过使用公共REST属性与现有的组织范围或云提供商范围的访问控制系统进行交互。请求必须包含请求者的用户名，请求的行为以及受该操作影响的对象。
• 如果现有策略声明用户有权完成请求的操作，那么该请求被鉴权通过

11：Kubernetes应用管理深度剖析

名称	总结
Helm	可以将Helm看作Kubernetes下的apt-get/yum。Helm是Deis(https://deis.com)开发的一个用于kubernetes的包管理器：1、对于应用发布者而言，可以通过Helm打包应用，管理应用依赖关系，管理应用版本并发布到软件仓库；2、对于使用者而言，使用Helm后不需要了解Kubernetes的Yaml语法并编写应用部署文件，可以通过Helm下载并在Kubernetes上安装需要的应用；3、除此之外，Helm还提供了kubenetes上的软件部署，删除，升级，回滚应用的能力
operator	kubernetes operator 是一种封装、部署和管理Kubernetes应用的方法。kubernetes operator 是一种特定于应用的控制器可扩展Kubernetes API的功能，来代表kubernetes用户创建、配置和管理复杂应用的实例；它基于基本kubernetes资源和控制器概念构建，但又涵盖了特定于域或应用的知识，用于实现其所管理软件的整个生命周期的自动化

12：Istio控制面架构深度剖析

Istio架构分层主要分为：控制面Istiod(Pilot Citadel Galley Sidecar-Injector)和数据面(Envoy Pilot-Agent)

模块	功能
Pilot	xDS服务器，为数据代理提供各种配置
Citadel	为数据面签发证书
Gallery	Admission Webhook, 校验Istio API配置
Sidecar-Injector	自动注入Sidecar

Sidecar基本介绍

• Sidecar自动注入，由Sidecar Injector负责，支持按照Namespace以及按照应用注入
• 业务代码不感知Sidecar的存在
• Sidecar负责拦截应用的流量，并且提供流量治理、安全、监控三大功能

流量治理基本API

API	意义
ServiceEntry	定义Kubernetes集群外部服务，提供非K8S服务发现或者跨集群的服务发现
VirtualService	定义一些路由匹配、灰度、故障注入等功能
DestinationRule	提供目标服务的负载均衡策略以及连接管理，熔断等策略
Gateway	为服务网格边缘提供基本的流量转发策略

13：Istio数据面（Envoy）架构深度解析

名称	简介
Enovy	基于C++11，14的高性能服务网格数据面代理
xDS	Enovy与上层控制面如istiod使用的基于gRPC的应用层协议，用于传输配置变更
自动注入及流量拦截	Pod创建时，由Istiod进行自动修改deployment，并将istio-proxy容器注入到新创建的pod内；当发生调用时，iptables规则将自动拦截出入流量进入Enovy代理
线程模型	Enovy采用每个工作线程独立处理网格及定时器事件，线程间无数据共享，提升性能
过滤器架构	Enovy采用可扩展插件架构实现监听过滤器、L4网络过滤器、L7 HTTP过滤器；同时支持基于L4/L7 WASM及L7 Lua过滤器的二次扩展

14：Istio流量治理与监控管理深度剖析

14.1 Istio流量治理基本介绍

简化服务治理配置：熔断、降级，超时，重试，A/B测试，金丝雀发布，基于权重的流量切分，故障检测与恢复

14.2 Istio流量治理深度剖析

名称	功能
VirtualService	允许您配置如何将请求路由到Istio服务网格中的服务，构建在Istio和您的平台提供基本连接和发现之上。without VS,请求将按照基本的负载均衡策略分发到所有的服务实例。with VS,可以将请求按照百分比（weight）分发到一组或者多组后端实例，或者根据请求属性（Match）,将请求路由到不同的服务实例组。典型的使用场景是灰度发布
DestinationRule	常常与VS配合使用，VS定义一些策略将流量路由到某些目标服务，而DestinationRule允许用户针对目标服务配置一些负载均衡，异常检测，连接池以及证书。特别是利用DR Subset定义特定服务的实力分组，结合VitualService可以实现完整的蓝绿部署，金丝雀发布等功能
Gateway	类似Ingress，看s gateway API,应用于网格边缘独立运行的Enovy代理，配置L4-L6的负载均衡，比如端口、证书，L7层的路由能力需要与VirtualService绑定
Sidecar	限制负载可访问的服务，精确控制部分端口可被访问，大规模场景下，降低控制面和数据面开销（内存，CPU,带宽）

14.3 Istio监控深度剖析

Istio提供以下可观测能力（非侵入）：

• Metrics，应用流量粒度的监控统计
• Distributed Traces：调用链上报
• Access Logs：访问日志

课程链接：https://edu.huaweicloud.com/activity/Cloud-native2.html
打卡链接：https://bbs.huaweicloud.com/forum/thread-136621-1-1.html