身世酒杯中
万事皆空
概念
云计算技术基本原理
- 云计算：是一种动态拓展的计算模式，通过网络将虚拟化资源作为服务提供，模式有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”（领域驱动模型）原则进行拆分
- 微服务应用设计原则
- 前后端分离
- 无状态服务
- 无状态通信
- 微服务要解决的问题
- 服务通信
- 路由寻址
- 服务监控
- 服务治理
- 多语言
