容器技术的前生今世(插图片已经画完)

容器技术概述

应用虚拟化的历史

1. 1979，Unix v7 支持为应用构建一个独立的虚拟文件系统
2. 2004-2008, Google 内部大规模使用 Cgroups 虚拟化技术
3. 2008, Cgroups 进入了 Linux 内核主线
4. 2008, LXC（Linux Container）项目发布，具备了 Linux 容器的雏型
5. 2013, Docker 项目正式发布
6. 2014, Kubernetes 项目正式发布
7. 2016, 容器生态开始模块化、规范化，容器服务商业化

容器是什么

一句话总结就是：容器是应用虚拟化，虚拟机是操作系统虚拟化

容器与虚拟化

kubernetes

容器的价值

1. 容器实例更轻量，更弹性，更容易流动
2. 容器技术是面向应用，比操作系统虚拟化效率更高
3. 容器可以更好的和微服务融合，更容易与DevOPS理念结合
4. 容器技术做到了运行环境与操作系统解耦，一处构建的标准镜像，无需修改的处处运行

容器的形态

从计算提供的方式演进方向来看，先后经历了

12. 机房IDC托管
13. 软件定义计算，网络，存储(IaaS)
14. 平台即服务(PaaS), 后端即服务 (BaaS)
15. 函数即服务(FaaS), 和Serverless架构

容器的形态

16. 面向应用，融合在了PaaS, BaaS, FaaS,Serverless之中
17. 面向操作系统，具备资源强隔离的MicroVM和高效，弹性的Container互相结合
18. 面向基础设施，统一容器编排的Kubernetes正在下沉，成为分布式OS的组成部分

云原生的世界

容器应用部署架构的演进

传统应用完成容器化方式运行演进过程如下：

第一阶段, 应用容器化

非容器应用 → 编写 DockerFile，构建成镜像 ，以容器方式运行

应用容器化

第二阶段, 单一集群模式:

开发，测试，生产环境，集群内命名空间隔离

使用k8s调度

第三阶段,多集群模式

开发，测试，生产集群，公共基础服务(日志，监控，CICD服务)独立部署

多集群模式

• 集群的管理模式，需要更强的DevOPS能力
• 微服务可用性，性能观测
• 引入APM分布式应用链路追踪

第四阶段, 超大规模模式

超大规模容器服务面临的问题，数以千计的微服务，数万量级的POD,以及不可预估的业务流量。。。，这个使用 ServiceMesh,ClusterMesh 模式就是会提上日程了

1. 需要更快的发布，更强的微服务治理能力
2. 需要更强可观测性能，容器网络流量分析
3. 需要更低延迟，更大带宽的容器网络

ServiceMesh,ClusterMesh 模式

典型的容器应用部署方式

集群视角

单集群/多命名空间

单集群部署模式

多集群

开发，测试，生产环境使用独立集群，数据，基础服务(日志，监控，注册中心，CICD等)拆分独立集群

多集群拆分

集群Mesh模式

将多个集群组建成一个逻辑集群，提升跨集群间服务互通能力，可以实现业务容灾，多活等

cillium multicluster mesh

cillium multicluster arch

cmulticluster service connect

应用视角

通用容器应用

ingress+容器服务

ingress与容器服务

微服务

ingress+注册中心+微服务+分布式应用调用链

微服务部署模式

常见的微服务框架，比如 SpringCloud / SpringBoot，Dubbo，Go-Micro

以一个典型的微服务框架具备如下功能：

Spring Boot 是 Spring 的脚手架，快速开发单个微服务; SpringCloud 是基于Spring Boot的分布式系统基础设施，提供如服务发现注册、配置中心、消息总线、负载均衡、流量控制(断路，熔断，重试等）、数据监控的微服务治理功能

第一代微服务局限性如下：

服务治理 SDK 化，需要入侵业务代码

语言绑定，特定的微服务框架仅支持特定的语言

服务网格

服务网格部署模式

ingress+服务网格控制层面+微服务应用+分布式应用调用链+ServiceMesh

Service Mesh解决了如下问题：

• 屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等)，服务只用关注业务逻辑；
• 语言无关，服务可以用任何语言编写，只需和Service Mesh通信即可；
• 对应用透明，Service Mesh组件可以单独升级；

Service Mesh 局限性如下：

• 复杂性增加，Service Mesh 通过 Sidecar 侵入到业务数据流
• Service Mesh，更多的解决的是服务间通信，对于分布式系统的状态管理，绑定外部数据存储、事件驱动

UCloud 容器服务

容器平台能力矩阵

支撑程度/类别	Cube实例	Uk8s集群	监控	日志	链路追踪	服务网格	微服务	应用网关	DevOPS
产品支持	√	√	√	√			--
方案支持			√	√	√	√	--	√	√

容器产品能力矩阵

功能	ucloud	cube	备注
集群网络	vpc cni (underlay)
负载均衡	支持
Ingress	需要部署开源软件
块存储卷(storage-class)	支持
NFS 动态存储卷(storage-class)	支持
对象存储(storage-class)	支持
弹性伸缩CA HPA VPA	支持
GPU节点	支持
高性能计算节点	支持
混合云/托管区节点	支持
需要打通托管区网络，只能添加托管区节点作为node节点
制品库	uhub,支持外部registry
多集群管理	仅限创建，删除

产品与解决方案架构图

image.png

面向销售

目前已经大量的客户在容器化管理应用，并且客户是需要花更多类型的容器产品和服务，容器可以带来大量云资源消费的

24. 什么值得买，UC最大的容器服务消费客户，双十一期间，峰值可达近千台节点，万核量级的计算资源
25. 核桃编程 平台百台两集的计算资源，十余个高配节点K8S集群
26. 百望客户 云主机运行容器化应用，部分业务 rancher+uk8s
27. 天天用车，混合云容器集群，深度学习模型训练
28. 盖娅客户，探探客户 ，尝试测试cube的使用
29. 快准车服 容器多活方案
30. 风电客户，uk8s 集群扩展高性能计算节点

容器技术卖点

31. 扩展容器服务客户的能力，除了常规的云主机资源的的消费，可以带来更多的消费
32. 容器技术方案：镜像仓库，CICD，日志，监控系统，告警能带来US3，短信的消费，
33. 弹性计算资源容器化，job+ uk8s+高性能node
34. AI训练计算资源容器化+ GPU主机

面向架构师

基础的产品，ULB，Uhost ，UDisk，UFS，US3，Uk8s, Cube

DevOPS

Gitlab，jenkins，jenkinX

截屏2021-09-08 下午2.17.22.png

镜像仓库

image.png

为什么需要镜像同步

image.png

由于对镜像的访问是一个核心的容器概念，在实际使用过程中，一个镜像库可能是不够用的，下例情况下，我们可能会需要部署多个镜像仓库：

• 国外的公有镜像下载过慢，需要一个中转仓库进行加速

• 容器规模较大，一个镜像仓库不堪重负

• 对系统稳定性要求高，需要多个仓库保证高可用性

• 镜像仓库有多级规划，下级仓库依赖上级仓库

更常用的场景是，在企业级软件环境中，会在软件开发的不同阶段存在不同的镜像仓库，

• 在开发环境库，开发人员频繁修改镜像，一旦代码完成，生成稳定的镜像即需要同步到测试环境。

• 在测试环境库，测试人员对镜像是只读操作，测试完成后，将镜像同步到预上线环境库。

• 在预上线环境库，运维人员对镜像也是只读操作，一旦运行正常，即将镜像同步到生产环境库。

• 在这个流程中，各环境的镜像库之间都需要镜像的同步和复制。

Harbor的镜像同步机制

有了多个镜像仓库，在多个仓库之间进行镜像同步马上就成为了一个普遍的需求。比较传统的镜像同步方式，有两种：

• 第一种方案，使用Linux提供的RSYNC服务来定义两个仓库之间的镜像数据同步。

• 第二种方案，对于使用IaaS服务进行镜像存储的场景，利用IaaS的配置工具来对镜像的同步进行配置。

image.png

这两种方案都依赖于仓库所在的存储环境，而需要采用不同的工具策略。Harbor则提供了更加灵活的方案来处理镜像的同步，其核心是三个概念：

• 用Harbor自己的API来进行镜像下载和传输，作到与底层存储环境解耦。

• 利用任务调度和监控机制进行复制任务的管理，保障复制任务的健壮性。在同步过程中，如果源镜像已删除，Harbor会自动同步删除远端的镜像。在镜像同步复制的过程中，Harbor会监控整个复制过程，遇到网络等错误，会自动重试。

• 提供复制策略机制保证项目级的复制需求。在Harbor中，可以在项目中创建复制策略，来实现对镜像的同步。与Docker Registry的不同之处在于，Harbor的复制是推（PUSH）的策略，由源端发起，而Docker Registry的复制是拉（PULL）的策略，由目标端发起。

日志方案

传统的filebeat +ELK

image.png

新兴的Vector+Loki+ Grafana

image.png

监控方案

promethus+cortex++Grafana

image.png

https://cortexmetrics.io/docs/architecture/

链路追踪

jaeger+Tempo+Grafana

image.png

服务网格

linkerd2

image.png

image.png

流量调度

1. linkerd2 流量调度

使用linkerd2实现灰度发布

使用linkerd2实现多集群流量调度

image.png

2. DNS权重+Ingress

DNS负载均衡实现流量调度

跨集群服务调用

3. Ingress+LB

使用Ingress+LB实现跨集群服务调用

4. Cilium Mesh

Cilium Mesh实现跨集群服务调用

Cilium multi-cluster 原理示意图

多集群应用管理

98181ad8-0675-41e8-b24e-32ddc1b5bc7b.png

image.png

高性能容器网络

开源的 Cilium (ebpf/Ipvlan)

image.png