云原生|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

你可能感兴趣的:(云原生|Kubernetes技术架构)