容器生态的入门笔记：为什么需要编排工具、DevOps 到底指什么、K8S 集群内部是怎么组织的。
服务编排的演进
早期应用直接部署在操作系统里，运维靠 Ansible 这类工具。Docker 出现后应用被封装进容器，容器的接口和传统应用的管理接口完全不同，编排对象从应用变成了容器。
微服务化后一个系统可能拆出数以万计的服务，传统运维方式管不过来，必须用容器编排工具。
常见的容器编排工具
Docker compose：只面向一台 Docker 主机，适合单机编排。Docker swarm：把多台主机整合成一个资源池，编排只面向这个池，不关心底层有几台主机。Docker machine：把主机快速初始化到满足加入 swarm 集群的先决条件。mesos：相当于整个 IDC 的操作系统，统一调度机房硬件资源，但它分配的是资源不是容器，托管容器要再架一层marathon。kubernetes：容器编排领域 80% 以上的份额。
DevOps、CI 与 CD
DevOps 不是一种技术，是文化和工作方式：把以往靠人工解决的问题工具化、自动化，让 Dev 和 Ops 协同。链路是计划、设计、开发、构建、测试、运维、发布上线，部署常见蓝绿部署、灰度发布、金丝雀发布。两点关系要拎清：容器让 DevOps 落地、持续部署成为现实，DevOps 的流行又让编排工具成了重要的底层基础；编排工具本身不提供 DevOps 环境，是先掌握平台，再把 DevOps 落上去。
- CI 持续集成：代码提交后自动构建、自动测试，通过就交付运维，不通过打回开发者修复重来，循环到通过。
- CD 持续交付（Delivery）：测试通过的包放到运维能直接取到的地方。
- CD 持续部署（Deployment）：测试通过的包直接发线上。传统异构平台打包方式各不相同，做不到；容器只要目标系统跑着容器引擎就能跑，不关心底下什么平台。
微服务是把应用拆成多个小服务，现在的微服务架构大多构建在容器之上。
Kubernetes：简介与特性
Kubernetes 意为“舵手”，由谷歌几位工程师创立，2014 年公布，深受谷歌内部用了多年的 Borg 影响；1.0 发布于 2015 年 7 月，一年四个版本，项目地址 https://github.com/kubernetes/kubernetes 。2017 年 10 月，Docker 宣布同时支持 swarm 和 k8s。
特性：自动装箱、自我修复（容器出问题秒级重启新容器，前提是镜像已在本地、程序初始化快）、水平扩展、服务发现、负载均衡、自动发布和回滚、秘钥和配置管理、存储编排、任务批处理。配置单独说：云原生应用基于环境变量取配置，传统应用要读配置文件；再进一步是配置中心，配置存在第三方服务器上，容器启动时去加载，以后改配置只改中心那一份。
架构、组件与 Pod
集群模型分两种：无中心节点（P2P）和有中心节点（如 MySQL 主从、HDFS）。K8S 是后者，Master-Node 模型：请求交给 Master，调度器分析各节点可用资源选出最合适节点，由该节点本地的容器引擎启动容器；Node 启动前先查本地镜像，没有就去仓库拉取。访问只能走 API 接口，要么编程访问，要么用 kubectl 这类客户端。
Master 组件：API Server 接收、解析、处理请求；Scheduler 做两级调度，先预选过滤出符合条件的节点，再优选挑最优；Controller-Manager 维护集群状态。Node 组件：kubelet 执行下发命令（它不创建容器，创建由 Docker 引擎完成）、Docker 容器引擎运行 Pod 内容器、kube-proxy 为 Service 提供集群内服务发现和负载均衡。Node 宕机，上面的 Pod 随之消失，由自愈机制在其他节点重新拉起。
Pod 是最小调度单元，把多个容器放进同一个网络名称空间，共享存储卷；一般一个 Pod 只放一个容器，关系特别紧密才多容器。Pod 名称不固定，靠标签（key=value）识别，控制器用标签选择器过滤。
自主式 Pod 节点故障后无法全局重建；控制器管理的 Pod 才有完整生命周期。常见控制器：ReplicationController（副本不足自动补、多了剔除，支持滚动更新和回滚）、ReplicaSet、Deployment（无状态）、StatefulSet（有状态）、DaemonSet（每节点固定一个副本）、Job、CronJob。每种控制器对应一种特定的应用管理场景。
暂无评论内容