Python应用,DDD领域设计,Service Mesh以及自动化测试社会化营销移动个人终端社交电商精益创业

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

2021-08-29  本文已影响0人  行者深蓝

容器技术概述

应用虚拟化的历史

  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. 容器技术做到了运行环境与操作系统解耦,一处构建的标准镜像,无需修改的处处运行

容器的形态

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

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

容器的形态

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

云原生的世界

容器应用部署架构的演进

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

第一阶段, 应用容器化

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


应用容器化

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

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

使用k8s调度

第三阶段,多集群模式

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


多集群模式

第四阶段, 超大规模模式

超大规模容器服务面临的问题,数以千计的微服务,数万量级的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 局限性如下:

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

面向销售

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

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

容器技术卖点

  1. 扩展容器服务客户的能力,除了常规的云主机资源的的消费,可以带来更多的消费
  2. 容器技术方案:镜像仓库,CICD,日志,监控系统,告警能带来US3,短信的消费,
  3. 弹性计算资源容器化,job+ uk8s+高性能node
  4. 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的镜像同步机制

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

image.png

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

日志方案

传统的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
  1. DNS权重+Ingress
DNS负载均衡实现流量调度

跨集群服务调用

  1. Ingress+LB
使用Ingress+LB实现跨集群服务调用
  1. Cilium Mesh
Cilium Mesh实现跨集群服务调用 Cilium multi-cluster 原理示意图

多集群应用管理

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

高性能容器网络

开源的 Cilium (ebpf/Ipvlan)

image.png
上一篇 下一篇

猜你喜欢

热点阅读