容器技术概述
应用虚拟化的历史
- 1979，Unix v7 支持为应用构建一个独立的虚拟文件系统
- 2004-2008, Google 内部大规模使用 Cgroups 虚拟化技术
- 2008, Cgroups 进入了 Linux 内核主线
- 2008, LXC（Linux Container）项目发布，具备了 Linux 容器的雏型
- 2013, Docker 项目正式发布
- 2014, Kubernetes 项目正式发布
- 2016, 容器生态开始模块化、规范化，容器服务商业化
容器是什么
一句话总结就是：容器是应用虚拟化，虚拟机是操作系统虚拟化
容器与虚拟化
kubernetes
容器的价值
- 容器实例更轻量，更弹性，更容易流动
- 容器技术是面向应用，比操作系统虚拟化效率更高
- 容器可以更好的和微服务融合，更容易与DevOPS理念结合
- 容器技术做到了运行环境与操作系统解耦，一处构建的标准镜像，无需修改的处处运行
容器的形态
从计算提供的方式演进方向来看，先后经历了
- 机房IDC托管
- 软件定义计算，网络，存储(IaaS)
- 平台即服务(PaaS), 后端即服务 (BaaS)
- 函数即服务(FaaS), 和Serverless架构
容器的形态
- 面向应用，融合在了PaaS, BaaS, FaaS,Serverless之中
- 面向操作系统，具备资源强隔离的MicroVM和高效，弹性的Container互相结合
- 面向基础设施，统一容器编排的Kubernetes正在下沉，成为分布式OS的组成部分
云原生的世界
容器应用部署架构的演进
传统应用完成容器化方式运行演进过程如下：
第一阶段, 应用容器化
非容器应用 → 编写 DockerFile，构建成镜像 ，以容器方式运行
应用容器化
第二阶段, 单一集群模式:
开发，测试，生产环境，集群内命名空间隔离
使用k8s调度
第三阶段,多集群模式
开发，测试，生产集群，公共基础服务(日志，监控，CICD服务)独立部署
多集群模式
- 集群的管理模式，需要更强的DevOPS能力
- 微服务可用性，性能观测
- 引入APM分布式应用链路追踪
第四阶段, 超大规模模式
超大规模容器服务面临的问题，数以千计的微服务，数万量级的POD,以及不可预估的业务流量。。。，这个使用 ServiceMesh,ClusterMesh 模式就是会提上日程了
- 需要更快的发布，更强的微服务治理能力
- 需要更强可观测性能，容器网络流量分析
- 需要更低延迟，更大带宽的容器网络
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
面向销售
目前已经大量的客户在容器化管理应用，并且客户是需要花更多类型的容器产品和服务，容器可以带来大量云资源消费的
- 什么值得买，UC最大的容器服务消费客户，双十一期间，峰值可达近千台节点，万核量级的计算资源
- 核桃编程 平台百台两集的计算资源，十余个高配节点K8S集群
- 百望客户 云主机运行容器化应用，部分业务 rancher+uk8s
- 天天用车，混合云容器集群，深度学习模型训练
- 盖娅客户，探探客户 ，尝试测试cube的使用
- 快准车服 容器多活方案
- 风电客户，uk8s 集群扩展高性能计算节点
容器技术卖点
- 扩展容器服务客户的能力，除了常规的云主机资源的的消费，可以带来更多的消费
- 容器技术方案：镜像仓库，CICD，日志，监控系统，告警能带来US3，短信的消费，
- 弹性计算资源容器化，job+ uk8s+高性能node
- 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
流量调度
- linkerd2 流量调度
使用linkerd2实现灰度发布
使用linkerd2实现多集群流量调度
image.png
- DNS权重+Ingress
DNS负载均衡实现流量调度
跨集群服务调用
- Ingress+LB
使用Ingress+LB实现跨集群服务调用
- Cilium Mesh
Cilium Mesh实现跨集群服务调用
Cilium multi-cluster 原理示意图
多集群应用管理
98181ad8-0675-41e8-b24e-32ddc1b5bc7b.png
image.png
高性能容器网络
开源的 Cilium (ebpf/Ipvlan)
image.png
网友评论