身世酒杯中
万事皆空
概念
云计算技术基本原理
- 云计算:是一种动态拓展的计算模式,通过网络将虚拟化资源作为服务提供,模式有LaaS、PAAS、SaaS
- 云计算发展路线:并行计算->集群计算->网络计算->云计算
- 云计算优势
- 节省费用/所付即所用
- 即时升级
- 安全
- 可靠
- APIs
- 主流云平台
- Kubernetes/Mesos/Swarm
- Google Cloud Engine
- Docker
- …
- Docker优点
- 更低的资源损耗
- 更快的启动速度
- 更好的应用耦合
- 更强的弹性伸缩
- Docker三要素
- Docker Containers
负责程序运行,包括操作系统、用户添加的文件和元数据 - Docker Images
只读模版,运行容器 - DockerFile
文件指令集,说明如何自动创建Docker镜像
- Docker Containers
- PaaS平台最基本问题
- 封装
- 标准
Docker技术原理与实践
- 对比虚拟机
- Docker应用场景
- web应用的自动化打包和发布
- 自动化测试和持续集成、发布
- 在服务环境中部署和调整数据库和其他后台应用
- 从头编译或拓展现有平台来搭建自己的PaaS平台
-
命名空间和PID
命名空间六种隔离:
- UTS(系统标识,让一个容器拥有属于自己的独立于宿主机的hostname)
- IPC(隔离进程间通信)
- PID(对进程PID进行重新标号,不同namespace下面的PID具有相同的编号)
- Network(实现网络资源隔离,包括网络设备)
- Mount(通过隔离文件系统挂载点实现对文件系统的隔离)
- 共享,双向传播
- 从属,单向传播
- User(隔离安全相关的标志符和属性)
除了命名空间,PID也可以被虚拟化,命名空间建立系统的不同视图,对每一个命名空间来说,从用户看来,就跟一台单独的Linux一样,有自己的init进程(PID=1),虽然在宿主机中它可能PID=3 命名空间的目标是为了实现轻量级虚拟化服务
-
CGroups
是linux内核功能,限制、计算和隔离一组进程的资源使用情况,docker利用cgroups来控制和隔离资源限制作用:
- 资源限制
- 优先级分配
- 资源统计
- 任务控制
相关术语:
- task(系统的一个进程或线程)
- cgroup(以cgroup为单位,以某种资源控制标准划分的任务组,包括一个或多个子系统)
- subsystem(资源调度控制器)
- hierarchy(cgroup以树状结构排列,每个层级绑定对应子系统进行资源控制)
组织结构与基本原则:
- 同一个层级可以附加一个或多个子系统
- 一个系统可以附加到多个层级,当且仅当目标层级只有唯一一个子系统时
- 新建一个层级时,默认加入这个新建层级的初始化cgroup,任务只能存在于同一个层级的一个cgroup,但可以存在不同层级的多个cgroup
- fork/clone自身时创建的子任务默认与原任务在同一个cgroup,但子任务允许被移动到不同cgroup中
cgroup子系统:
- blkio
- cpu
- cpuacct
- cpuset
- devices
- freezer
- memory
- pref_event
- net_cls
工作原理:
- 给任务挂上钩子,任务涉及某种资源时,出发钩子所带的子系统进行检查
- 任务超过资源上限时,新申请资源如内存,会被拒绝甚至将任务挂起
- cgroup通过中间结构task_struct与任务关联
- Docker架构也是客户度啊-服务器结构
- Docker client
- Docker Deamon
- 最核心后台进程,负责响应来自Docker client的请求,然后翻译成系统调用完成容器管理操作。后台启动API Server, 负责接收请求,分发调度给相关函数执行
- execdriver(对Linux封装)
- volumedriver(数据)
- graphdriver(镜像)
- 数据卷
- 数据卷不受存储驱动程序控制
- 可将任意数量的数据卷加入容器中
- 多个容器可以共享数据卷
- 容器被删除,其未写入数据卷的数据一并删除
- Docker网络
当 Docker 启动时,会自动在主机上创建一个 docker0 虚拟网桥,实际上是Linux 的一个 bridge,可以理解为一个软件交换机。它会在挂载到它的网口之间进行转发。 - Docker命令
容器编排与Kubernetes原理
- K8S优势
- 更灵活的容器编排策略
- 更丰富的主机管理和调度策略和类型
- 更多的工具链集成
- 更好的微服务支持
- 更活跃和更开放的开源社区
- 开箱即用的滚动升级、服务回滚等等
- K8S概念
基于容器技术的分布式架构设计方案 - Sevice(分布式架构集群的核心)
- 唯一指定的服务名称
- 虚拟IP和端口号
- 能提供远程服务能力
- 被映射到能提供服务的一组容器应用上
- 核心组件
- master
- 集群控制节点,负责集群控制与管理,通常运行在独立物理节点或虚拟机上
- 运行各类关键进程
- API Server(提供REST接口)
- 整个集群管理的API接口
- 集群内部各模块之间的通讯枢纽
- 集群安全控制
- Controller Manager(所有资源自动化控制中心)
- 副本控制
- 端点控制
- 命名空间控制
- 服务账号控制
- Scheduler(Pod资源调度)
- Etcd Server(所有资源对象数据保存)
- API Server(提供REST接口)
- node
- 工作节点
- 动态增减
- 运行的进程
- kubelet(pod启动、停止及和master节点协作)
- 节点管理
- 容器管理
- 健康检查
- 资源监控
- kube-proxy(通信和负载均衡)
- docker engine(本机容器创建和管理)
- kubelet(pod启动、停止及和master节点协作)
- master
- Pod
- 一组紧耦合的容器组合
- 一个Pod内部的容器享有共同的生命周期:共同产生、调度和消亡
- 共享存储系统
- 共享命名空间
- 同一个IP和localhost
- 共享IPC
- 采用Label来建立Service和Pod之间的关系
- Pod运行在节点node上,node可以是物理机或虚拟机
- 每个Pod运行一个Init容器和多个业务容器,这些业务容器共享Init容器的网络栈和存储卷,数据交换效率更高
为什么引入Pod:
- Init作为根容器,代表整个容器组状态,避免个别容器导致Pod失效的情况
- 业务容器共享Init容器和Volume,解决容器之间的文件共享问题
- K8S中所有资源对象都可以采用yaml或json描述
使用场景:
- 数据同步服务
- 日志数据收集
- 监控数据收集
- 网络数据收集
调度机制:
- 全自动调度(rc)
- 定向调度
通过一系列复杂调度算法,选定目标节点,可以通过定向调度迁移pod - 亲和性调度
通过一系列逻辑运算,更加灵活选取node
- 定向调度
- 特定场景调度(deployment)
每个node上只运行一个pod副本实例 - 批处理调度(job)
通过job资源支持批处理任务
- 灰度发布
删除旧RS,创建新RS - Replication Controller
- 申明pod副本数量在任何时候都符合某个预期值
- 定义pod期待副本数
- 筛选目标pod的label selector
- 新pod模版
- HPA
- 资源对象,支持pod横向自动扩容
- pod负载度量指标
- cpu利用率
- tps、qps
- 存储卷
- pod中多个容器共享的存储目录
- 定义在pod上,可以被一个pod的多个容器挂载到具体目录下
- 与pod生命周期相同,但与容器不同,容器终止时,数据不会丢失
- 支持多种类型volumn
- 类型
- EmptyDir
- hostPath
- pod中多个容器共享的存储目录
- 网络方案
- CNM(container network model)
- docker自带
- docker命令行之间支持
- 插件化,灵活度不高
- CNI(container network interfa)
- 非docker原生支持
- 需要主动激活
- 插件化,灵活度高
- CNM(container network model)
- kubelet
集群管理的最重要的组件进程,负责管理和维护这台主机上所有的容器,使得pod运行状态与期望值一致 -
CRI(container runtime interf)
容器运行时接口,符合这个接口的容器运行时都可以和K8S进行集成设计模型:
kubelet-shim-runtime
K8S设计实践
- 容器化改造过程
- 简单容器化,应用无改造
- 应用去状态
- 微服务,可重用
- 微服务
- 模块可独立开发上线运维,边界清晰
- 允许不同语言编写,易于引入新技术
- 微服务商店模式,快速组合与重构
- 模块解耦
- 更高的拓展性和可用性
- CSI(container storage interface)
- 多租户管理
- 通过namespace,实现一定程度的多租户资源逻辑分离
- 提供多类型认证授权机制
- 提供可扩展的多维度资源管控机制
- namesapce是多用户隔离的主要手段,是对资源对象进行细分的DNS子域名概念
- 简单易用,对资源对象进行逻辑隔离
- 逻辑对象和物理结合,用户只关注namespace
- 与k8s认证授权机制结合
- 进行资源归类,使APIserver能够建立一套资源请求机制
- 用户认证机制
- 客户端证书
- token
- OpenID
- Basic
- Keystone
- 授权机制模式
- AlwaysDeny(测试)
- AlwaysAllow
- ABAC
- Webhook
- Federation
- 为用户分配最近的集群
- 高可用
- 弹性拓展
- 避免供应商锁定
- 混合云支持
- 提升规模化
- 跨集群间的资源和任务管理
- DevOps
- 分布式环境管理能力(微服务架构)
- 上云能力(基础设施、资源云化)
- DevOps作业能力(自动化持续交付流水线、自动化运维平台、开发运维一体化)
云平台智能监控
- Fluentd(免费、完全开源的日志管理工具)
- Kafka(高吞吐量分布式发布订阅消息系统)
- Heapster(容器集群监控和性能分析工具)
- influxdb(时间序列数据库)
- Prometheus(开源监控报警系统和时间序列数据库)
- 多维度数据模型
- 具有一个灵活的查询语言来利用这些维度(promSQL)
- 不依赖分布式存储,单个服务节点工作
- 时间序列采集通过http pull形式
- 通过中介网关支持短时间序列数据的收集
- 监控目标是通过服务发现或静态配置
- 多种数据展示面板支持
-
全链路监控
有利于快速交付和排查- TraceID
识别用户一次请求,所有全链路上的节点公用一个TraceID - SpanID
正在处理用户请求的节点 - ParentSpanID
正在处理用户请求的节点的上一个节点
机制:
- 调用链的第一个节点生成TraceID
- SpanID使用UUID随机数生成即可,保障唯一性,每次请求都有唯一spanid
- ParentSpanID使用上一个节点SpanID代替
- TraceID
- APM(深入应用代码的性能监控)
- 数据永远只会插入,没有更新与删除
- 数据需要快速读取,快速聚合,接近实时
- 数据需要复制,不能因为一台宕机损失数据
- 数据节点需要支持简单拓展,能够被添加进存储区
容器云平台应用
- 微服务概念
- 一种架构风格、架构模式
- 服务能够独立构建、独立部署、独立拓展
- 需要团队组织、文化调整和完善自动化工具
- 高内聚,低耦合
- 基于DevOps,面向运维的架构
- 受业务驱动,不断迭代
- 常见微服务相关框架
- Dubbo
- Spring Cloud
- Linkerd
- Istio
- 微服务拆分原则
- 遵循“DDD”(领域驱动模型)原则进行拆分
- 微服务应用设计原则
- 前后端分离
- 无状态服务
- 无状态通信
- 微服务要解决的问题
- 服务通信
- 路由寻址
- 服务监控
- 服务治理
- 多语言