Kubernetes 实战 （一） -- 泛 kubernates 导论

Kubernetes 是谷歌推出的一个工业级的容器编排平台,允许自动化部署、管理和扩容容器化应用，它现在已成为容器编排的事实标准。 仓库地址

目录

k8s 由来

是什么 -- 分布式集群自动（自助）化运维舵手

需求驱动 -- 微服务化后的分布式部署集群

技术驱动 -- 轻量级容器化技术

高动态集群运维抽象模型 DCOM

应用集群化部署、运维的一般流程

抽象 高动态集群运维模型 DCOM

开源实现

---

k8s 由来

Kubernetes 是希腊语，中文翻译是“舵手”或者“飞行员”，其实最常用的是其简称 k8s，即将收尾k和s之间的8个字母“ubernete ”替换为“8”而导致的一个缩写，和编程界最常用的另一个缩写 i18s - internationalization（国际化）类似。

是什么 -- 分布式集群自动（自助）化运维舵手

k8s 是分布式集群、自动（自助）化运维 舵手，在轻量级容器（如docker）上，实现分布式集群的高动态运维和服务治理功能，完善DevOps体系，模糊了Dev和Ops的界限。诞生于以下2大重要背景

• 需求驱动 -- 微服务化后的分布式部署集群

SOA以及微服务流行的背景下，单体应用被拆分为数十微服务、多机部署数百实例，人工部署和管理既繁重、亦冗余，甚至不可能，因此诞生了以 k8s 为代表的分布式集群自动化运维工具。反之，传统单体应用、单机部署、运维的场景下，是不会产生、也不需要的k8s等复杂编排工具，无需过度设计，形而上学。

• 技术驱动 -- 轻量级容器化技术

以 Docker 为代表的轻量级容器化技术，实现了单机百/千级数量容器秒级的部署速度和高扩展的api，为上层分布式集群下的容器编排提供了可能。

• Docker本质是什么？

Docker等轻量级容器技术是虚拟化方案，提升虚拟机的有效载荷比和性能，从而榨干 单机部署多服务 的极限，但并不是为了解决多机（分布式集群）运维的，所以才有 k8s、Apache Mesos 等集群容器编排工具的必要。

高动态集群运维抽象模型 DCOM

应用集群化部署、运维的一般流程

在通常的生产场景中，新迭代业务需求经开发、测试后即交由运维，进入部署、上线流程，大致包括以下环节：

•  交付指定运维人员

一个项目团队的运维人员往往是固定、关联的，且其所有的运维工作都需满足审计要求，标准、安全、留痕，因此运维人员通常由自己的固定账户，且最小化权限，降低风险。

• 评估、申请资源

业务团队根据自身应用的特点，是IO密集型、还是CPU密集型，评估所需的CPU、内存、网络、存储等资源，从而支持应用健康、持续、高效运行。

• 提交配置

各类配置是往往是应用运行的起步依赖，多套环境往往意味着多套配置，因此需要交付给运维人员正确的配置，避免混淆、错误运行。

• 部署应用集群

现在的业务应用大多是无状态的，适合对等集群化部署，既解决了单点故障问题，又可以均衡分担负载。

• 部署守护任务

监控、日志等提高应用可观察性的周边管理类服务往往以 Sidecar 的方式独立部署，避免挤占核心服务的资源，保障核心服务的稳定。

• 部署负载均衡LB(VIP)

应用的多实例的对等集群，需要使用负载均衡器LB如Nginx统一代理请求、定制负载均衡策略，而非直接的、显式的某一个具体的实例，否则失去了集群化的价值。同时为了保证LB的高可用，通常会部署多个LB代理，并使用VIP技术实现同一的对外标识，屏蔽内部故障切换细节。

• DNS绑定域名

虽然通过 IP:Port 可以静态访问到暴露出来的服务（VIP），但 IP 并不是友好的语义化符号，且无法动态适用应用迁移等导致的IP改变情况，因此通常亦需要通过DNS协议绑定语义化、识记友好的短符号，并解耦客户端与服务端的静态绑定关系。

抽象 高动态集群运维模型 DCOM

高动态集群运维模型是对上述应用集群化部署、运维的一般流程抽象，以标准化、程序化的方式准确界定每一个环节，从而为可编程的分布式集群自助化部署和运维提供了理论支撑，主流开源的 kubernates、Apache Mesos 等均可看作其实现。

• Namespace （应用）命名空间

应用部署的第一步，本质是为某些应用或项目从整个集群上划分、隔离出的子集群。一套庞大的分布式集群并不是为了部署某一个应用，而是多个应用共享的，因此进行应用级的划分，让应用安全、稳定运行在逻辑沙箱中，对应用本身、以及整个集群来说都是必须的。

• Authentication 认证 与 Authentization 鉴权

是对运维人员以及各类管理进程的抽象，以安全、受控的方式去实现审计要求的操作留痕、最小权限等原则。

• Resource 一切皆资源

分布式集群本身是由cpu、内存、网络、存储等软硬件资源的集合，而应用集群化部署和运维的本质是对集群各类资源如CPU、内存的动态规划和治理，因此非常适合将各类资源抽象化，并使用REST风格API管理。

• Config 配置中心

常规的配置适合应用本身静态相关的，并不具备集群化管理的特征，也无法动态关联多个相关应用。集群化的动态配置Config，要求部署配置和应用配置解耦，从而实跨应用、跨实例的动态配置共享，即微服务中的 配置中心。

• Deploy 部署

部署的本质是在集群上安装和运行一个需要占用一定集群资源（如cpu、内存）、提供某种服务的应用进程，也是最核心的环节。

部署本身不仅仅是应用进程本身，更包括和集群关联的各类资源和策略，因此不能狭义的将部署与具体的应用形式对等。

部署应该屏蔽具体的应用形式，无论是各类程序包，如Java jar/war包，还是各类轻量级容器（如docker），甚至是虚拟机，对集群来说都是上层的、一致化的部署Deploy。

• Service 服务发现 & Gateway 服务网关

        服务化 Service

          分布式/微服务流行的背景下，服务化 Service 已是标准和共识，Service的本质是为一组动态的对等或相关进程集合提供对外一致的服务标记（服务名），从而在集群内天然实现服务发现（微服务的核心）的能力。

• 服务网关 Gateway

           应用服务化、动态化后，需要一个统一的基于服务名的对外暴露能力，即服务网关 Gateway，该组件也是微服务的基础设置。单个服务 Service 不应该直接通过暴露主机端口的形式暴露出去，既会挤占公共集群的主机端口，造成不必要的污染与浪费，也增加了直接对外暴露的风险。通过应用级的服务网关统一管理和暴露服务，内部规则透明、动态切换，更符合微服务动态化、而非静态关联的特征。

总结：从 Service 和 Gateway 可以看出 DCOM 天然是面向微服务的、高动态集群，而尽量避免上游生产和下游消费的直接关联，中间增加动态的解耦机制，即 命名服务

开源实现

kubernates 并非唯一、也非最早的分布式集群应用编排工具，在整个应用架构的第四层容器编排层有众多开源的实现，但都可以抽象看做 高动态集群运维模型 DCOM 的实现。

• Apache Mesos – 全而杂

最早、也是最强大的集群容器编排系统，为后面 Docker Swarm、甚至 kubernates 等后期之秀提供了集群应用编排的有效解决方案。但本身由Mesos 和 Marathon 两套独立 API，学习复杂，难于推广和流行，2019年 Twitter 宣布不再支持。

• Docker Swarm - 简陋

由 Docker 官方推出的容器编排系统，特征是开箱即用，可以满足小规模集群、简单部署场景。但本身功能过于简陋，且不支持超大规模集群，因此并未在企业级市场成为主流，同样是2019 年阿里云宣布不再支持。

• Kubernates - 事实标准 👍

Google 出品，必属精品。 kubernates 作为谷歌推出的后起之秀，吸收了 Apache Mesos 和 Docker Swarm 优点，客服了其缺点，并完美实现了 高动态集群运维模型 DCOM ，从市占率看已成为分布式集群容器编排工具的事实标准，并以成为 DevOps 趋势下的必备技术栈。