云原生应用之路 —— 从 Kubernetes 到云原生
注:本文根据笔 者在 ArchSummit 2017 北京站 和 数人云 & TalkingData 合办的 Service Mesh is coming meetup 中分享的话题《从 Kubernetes 到云原生—— 云原生应用之路》改写而成。
本文简要介绍了容器技术发展的路径,为何 Kubernetes 的出现是容器技术发展到这一步的必然选择,而为何 Kubernetes 又将成为云原生应用的基石。
我的分享按照这样的主线展开:容器 -> Kubernetes -> 微服务 ->云原生 -> 服务网格 -> 使用场景 -> 开源。
容器 ——云原生的基石
容器最初是通过开发者工具而流行,可以使用它来做隔离的开发测试环境和持续集成环境,这些都是因为容器轻量级,易于配置和使用带来的优势,docker 和 docker-compose 这样的工具极大的方便的了应用开发环境的搭建,开发者就像是化学家一样在其中小心翼翼的进行各种调试和开发。
随着容器的在开发者中的普及,已经大家对 CI 流程的熟悉,容器周边的各种工具蓬勃发展,俨然形成了一个小生态,在 2016 年达到顶峰,下面这张是我画的容器生态图。

容器生态图
该生态涵盖了容器应用中从镜像仓库、服务编排、安全管理、持续集成与发布、存储和网络管理等各个方面,随着在单主机中运行容器的成熟,集群管理和容器编排成为容器技术亟待解决的问题。譬如化学家在实验室中研究出来的新产品,如何推向市场,进行大规模生产,成了新的议题。
Kubernetes—— 让容器应用进入大规模工业生产。
Kubernetes 是容器编排系统的事实标准
在单机上运行容器,无法发挥它的最大效能,只有形成集群,才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势,而对于容器的编排管理,Swarm、Mesos 和 Kubernetes 的大战已经基本宣告结束,Kubernetes 成为了无可争议的赢家。
下面这张图是 Kubernetes 的架构图(图片来自网络),其中显示了组件之间交互的接口 CNI、CRI、OCI 等,这些将 Kubernetes 与某款具体产品解耦,给用户最大的定制程度,使得 Kubernetes 有机会成为跨云的真正的云原生应用的操作系统。

Kubernetes架构
随着 Kubernetes 的日趋成熟,“Kubernetes is becoming boring”,基于该 “操作系统” 之上构建的适用于不同场景的应用将成为新的发展方向,就像我们将石油开采出来后,提炼出汽油、柴油、沥青等等,所有的材料都将找到自己的用途,Kubernetes 也是,毕竟我们谁也不是为了部署和管理容器而用 Kubernetes,承载其上的应用才是价值之所在。
云原生的核心目标

云原生的核心目标
云已经可以为我们提供稳定可以唾手可得的基础设施,但是业务上云成了一个难题,Kubernetes 的出现与其说是从最初的容器编排解决方案,倒不如说是为了解决应用上云(即云原生应用)这个难题。
包括微服务和 FaaS/Serverless 架构,都可以作为云原生应用的架构。

FaaS Landscape
但就 2017 年为止,Kubernetes 的主要使用场景也主要作为应用开发测试环境、CI/CD 和运行 Web 应用这几个领域,如下图 TheNewStack 的 Kubernetes 生态状况调查报告所示。

运行在 Kubernetes 上的负载(2017 年)
另外基于 Kubernetes 的构建 PaaS 平台和 Serverless 也处于爆发的准备的阶段,如下图中 Gartner 的报告中所示:

Gartner 技术爆发趋势图(2017 年)
2017 年时各大公有云如 Google GKE、微软 Azure ACS、亚马逊 EKS(2018 年上线)、VMware、Pivotal(后被VMware 收购)、腾讯云、阿里云等都提供了 Kubernetes 服务。
微服务——Cloud Native 的应用架构。

微服务的关注点
微服务带给我们很多开发和部署上的灵活性和技术多样性,但是也增加了服务调用的开销、分布式系统管理、调试与服务治理方面的难题。
当前最成熟最完整的微服务框架可以说非 Spring 莫属,而 Spring 又仅限于 Java 语言开发,其架构本身又跟 Kubernetes 存在很多重合的部分,如何探索将 Kubernetes 作为微服务架构平台就成为一个热点话题。
就拿微服务中最基础的服务注册发现功能来说,其方式分为客户端服务发现和服务端服务发现两种,Java 应用中常用的方式是使用 Eureka 和 Ribbon 做服务注册发现和负载均衡,这属于客户端服务发现,而在 Kubernetes 中则可以使用 DNS、Service 和 Ingress 来实现,不需要修改应用代码,直接从网络层面来实现。

微服务中的两种服务发现方式
DevOps——通向云原生的云梯
CNCF(云原生计算基金会)给出了云原生应用的三大特征:
- 容器化包装:软件应用的进程应该包装在容器中独立运行。
- 动态管理:通过集中式的编排调度系统来动态的管理和调度。
- 微服务化:明确服务间的依赖,互相解耦。
下图是我整理的关于云原生所需要的能力和特征。

Cloud Native Features

Cloud Native Landscape v1.0
使用 Kubernetes 构建云原生应用
- 1.基准代码
- 2.依赖管理
- 3.配置
- 4.后端服务
- 5.构建,发布,运行
- 6.无状态进程
- 7.端口绑定
- 8.并发
- 9.