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持久化存储体系

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

• 每个数据卷可以拥有独立的生命周期，不再跟随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的流程

本课总结

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支持如下三种探测机制：

8.3 应用弹性伸缩原理详解

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

小结

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

9.1 集群可观测性

云原生应用特点：

云原生可观测性

9.2 指标监控与prometheus

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

目前，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应用管理深度剖析

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

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

Sidecar基本介绍

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

流量治理基本API

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

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

14.1 Istio流量治理基本介绍

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

14.2 Istio流量治理深度剖析

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