2017-12-20 19:26:13 +08:00
# 云原生应用之路——从Kubernetes到Cloud Native
2018-02-22 13:24:35 +08:00
**从Kubernetes到Cloud Native——云原生应用之路**，这是我最近在 [ArchSummit2017北京站 ](http://bj2017.archsummit.com/presentation/306 ) 和 [数人云&TalkingData合办的Service Mesh is coming meetup ](https://www.kubernetes.org.cn/3211.html ) 中分享的话题。
2017-12-20 19:26:13 +08:00
本文简要介绍了容器技术发展的路径， ，
我的分享按照这样的主线展开：容器->Kubernetes->微服务->Cloud Native（ ） （ ） （ ）
## 容器
> 容器——Cloud Native的基石
容器最初是通过开发者工具而流行， ， ， ， ，
随着容器的在开发者中的普及， ， ， ， ， ：
该生态涵盖了容器应用中从镜像仓库、服务编排、安全管理、持续集成与发布、存储和网络管理等各个方面，随着在单主机中运行容器的成熟，集群管理和容器编排成为容器技术亟待解决的问题。譬如化学家在实验室中研究出来的新产品，如何推向市场，进行大规模生产，成了新的议题。
## 为什么使用Kubernetes
> Kubernetes——让容器应用进入大规模工业生产。
**Kubernetes是容器编排系统的事实标准**
2018-06-29 15:25:48 +08:00
在单机上运行容器， ， ， ， ， ，
2017-12-20 19:26:13 +08:00
下面这张图是Kubernetes的架构图（ ） ， ， ， ，
随着Kubernetes的日趋成熟， ， ， ， ， ， ， ，
**云原生的核心目标**
云已经可以为我们提供稳定可以唾手可得的基础设施， ， ， （ ）
包括微服务和FaaS/Serverless架构，
但就2017年为止， ，
另外基于Kubernetes的构建PaaS平台和Serverless也处于爆发的准备的阶段， ：
当前各大公有云如Google GKE、微软Azure ACS、亚马逊EKS（ ）
## 微服务
> 微服务——Cloud Native的应用架构。
下图是[Bilgin Ibryam](https://developers.redhat.com/blog/author/bibryam/)给出的微服务中应该关心的主题，图片来自[RedHat Developers](https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/)。
微服务带给我们很多开发和部署上的灵活性和技术多样性，但是也增加了服务调用的开销、分布式系统管理、调试与服务治理方面的难题。
当前最成熟最完整的微服务框架可以说非[Spring](https://spring.io/)莫属， ， ，
就拿微服务中最基础的**服务注册发现**功能来说，其方式分为**客户端服务发现**和**服务端服务发现**两种， ， ， ， ，
## Cloud Native
> DevOps——通向云原生的云梯
CNCF（ ） ：
- **容器化包装**：软件应用的进程应该包装在容器中独立运行。
- **动态管理**：通过集中式的编排调度系统来动态的管理和调度。
- **微服务化**：明确服务间的依赖，互相解耦。
下图是我整理的关于云原生所需要的能力和特征。
[CNCF ](https://cncf.io )所托管的应用（ ） ， ，
**使用Kubernetes构建云原生应用**
我们都是知道Heroku推出了适用于PaaS的[12 factor app](https://12factor.net/)的规范，包括如下要素：
1. 基准代码
2. 依赖管理
3. 配置
4. 后端服务
5. 构建，发布，运行
6. 无状态进程
7. 端口绑定
8. 并发
9. 易处理
10. 开发环境与线上环境等价
11. 日志作为事件流
12. 管理进程
另外还有补充的三点：
- API声明管理
- 认证和授权
- 监控与告警
如果落实的具体的工具， ， ：
结合这12因素对开发或者改造后的应用适合部署到Kubernetes之上， ：
**迁移到云架构**
迁移到云端架构，相对单体架构来说会带来很多挑战。比如自动的持续集成与发布、服务监控的变革、服务暴露、权限的管控等。这些具体细节请参考**Kubernetes-handbook**中的说明：< https: / / jimmysong . io / kubernetes-handbook > ， ， < https: / / jimmysong . io / migrating-to-cloud-native-application-architectures / > 。
## Service Mesh
> Services for show, meshes for a pro.
Kubernetes中的应用将作为微服务运行， ，
**Service mesh可以用来做什么**
- Traffic Management：
- Observability：
- Policy Enforcment：
- Service Identity and Security：
**Service mesh的特点**
- 专用的基础设施层
- 轻量级高性能网络代理
- 提供安全的、快速的、可靠地服务间通讯
- 扩展kubernetes的应用负载均衡机制，
- 完全解耦于应用，应用可以无感知，加速应用的微服务和云原生转型
使用Service Mesh将可以有效的治理Kuberentes中运行的服务， ：
- Linkderd： < https: // linkerd . io > ， ，
- Envoy： < https: // www . envoyproxy . io /> ， ，
- Istio： < https: // istio . io > ，
- Conduit： < https: // conduit . io > ，
此外还有很多其它的Service Mesh鱼贯而出，
**Istio VS Linkerd**
Linkerd和Istio是最早开源的Service Mesh， ，
| **Feature** | **Istio** | **Linkerd** |
| ----------- | ------------- | ---------------------------- |
| 部署架构 | Envoy/Sidecar | DaemonSets |
| 易用性 | 复杂 | 简单 |
| 支持平台 | kuberentes | kubernetes/mesos/Istio/local |
| 当前版本 | 0.3.0 | 1.3.3 |
| 是否已有生产部署 | 否 | 是 |
关于两者的架构可以参考各自的官方文档，
Istio的组件复杂， ， ，
Linker的部署十分简单， ，
更多信息请参考[kubernetes-handbook](https://jimmysong.io/kubernetes-handbook)。
## 使用场景
> Cloud Native的大规模工业生产
**GitOps**
给开发者带来最大配置和上线的灵活性， ， ，
我们知道Kubernetes中的所有应用的部署都是基于YAML文件的， ，
**Big Data**
Spark现在已经非官方支持了基于Kuberentes的原生调度， ：
- Kubernetes原生调度：
- 资源隔离， ：
- 监控的变革：单次任务资源计量
- 日志的变革：
| **Feature** | **Yarn** | **Kubernetes** |
| ------------- | ---------------- | -------------- |
| queue | queue | namespace |
| instance | ExcutorContainer | Executor Pod |
| network | host | plugin |
| heterogeneous | no | yes |
| security | RBAC | ACL |
下图是在Kubernetes上运行三种调度方式的spark的单个节点的应用部分对比：
从上图中可以看到在Kubernetes上使用YARN调度、standalone调度和kubernetes原生调度的方式， ， ，
提交任务的语句看起来会像是这样的：
```bash
./spark-submit \
--deploy-mode cluster \
--class com.talkingdata.alluxio.hadooptest \
--master k8s://https://172.20.0.113:6443 \
--kubernetes-namespace spark-cluster \
--conf spark.kubernetes.driverEnv.SPARK_USER=hadoop \
--conf spark.kubernetes.driverEnv.HADOOP_USER_NAME=hadoop \
--conf spark.executorEnv.HADOOP_USER_NAME=hadoop \
--conf spark.executorEnv.SPARK_USER=hadoop \
--conf spark.kubernetes.authenticate.driver.serviceAccountName=spark \
--conf spark.driver.memory=100G \
--conf spark.executor.memory=10G \
--conf spark.driver.cores=30 \
--conf spark.executor.cores=2 \
--conf spark.driver.maxResultSize=10240m \
--conf spark.kubernetes.driver.limit.cores=32 \
--conf spark.kubernetes.executor.limit.cores=3 \
--conf spark.kubernetes.executor.memoryOverhead=2g \
--conf spark.executor.instances=5 \
--conf spark.app.name=spark-pi \
--conf spark.kubernetes.driver.docker.image=spark-driver:v2.1.0-kubernetes-0.3.1-1 \
--conf spark.kubernetes.executor.docker.image=spark-executor:v2.1.0-kubernetes-0.3.1-1 \
--conf spark.kubernetes.initcontainer.docker.image=spark-init:v2.1.0-kubernetes-0.3.1-1 \
--conf spark.kubernetes.resourceStagingServer.uri=http://172.20.0.114:31000 \
~/Downloads/tendcloud_2.10-1.0.jar
```
关于支持Kubernetes原生调度的Spark请参考：
## Open Source
> Contributing is Not only about code, it is about helping a community.
下图是我们刚调研准备使用Kubernetes时候的调研方案选择。
对于一个初次接触Kubernetes的人来说， ，
我组建了**K8S& Cloud Native实战**微信群，
**有用的资料和链接**
- 我的博客： < https: // jimmysong . io >
- 微信群： & cloud native实战群（ ： < https: // jimmysong . io / about > ）
- Meetup：
- Cloud Native Go - 基于Go和React云原生Web应用开发：
- Gitbook： < https: // jimmysong . io / kubernetes-handbook >
- Cloud native开源生态： < https: // jimmysong . io / awesome-cloud-native />
- 资料分享整理：< https: // github . com / rootsongjc / cloud-native-slides-share >
- 迁移到云原生架构：< https: // jimmysong . io / migrating-to-cloud-native-application-architectures />
2018-02-22 13:24:35 +08:00
- KubeCon + CloudNativeCon 2018年11月14-15日 上海
