Track 1 files into repository.
- modified cloud-native/from-kubernetes-to-cloud-native.md Auto commit by GitBook Editorpull/245/head
Zhang Zhenhua
parent
9d189de682
commit
0371974ae8
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
**从Kubernetes到Cloud Native——云原生应用之路**，这是我最近在 [ArchSummit2017北京站](http://bj2017.archsummit.com/presentation/306) 和 [数人云&TalkingData合办的Service Mesh is coming meetup](https://www.kubernetes.org.cn/3211.html) 中分享的话题。
|
||||
|
||||
本文简要介绍了容器技术发展的路径，为何Kubernetes的出现是容器技术发展到这一步的必然选择，而为何Kuberentes又将成为云原生应用的基石。
|
||||
本文简要介绍了容器技术发展的路径，为何Kubernetes的出现是容器技术发展到这一步的必然选择，而为何Kubernetes又将成为云原生应用的基石。
|
||||
|
||||
我的分享按照这样的主线展开：容器->Kubernetes->微服务->Cloud Native（云原生）->Service Mesh（服务网格）->使用场景->Open Source（开源）。
|
||||
|
||||
|
|
@ -32,7 +32,7 @@
|
|||
|
||||
下面这张图是Kubernetes的架构图（图片来自网络），其中显示了组件之间交互的接口CNI、CRI、OCI等，这些将Kubernetes与某款具体产品解耦，给用户最大的定制程度，使得Kubernetes有机会成为跨云的真正的云原生应用的操作系统。
|
||||
|
||||
|
||||
|
||||
|
||||
随着Kubernetes的日趋成熟，“Kubernetes is becoming boring”，基于该“操作系统”之上构建的适用于不同场景的应用将成为新的发展方向，就像我们将石油开采出来后，提炼出汽油、柴油、沥青等等，所有的材料都将找到自己的用途，Kubernetes也是，毕竟我们谁也不是为了部署和管理容器而用Kubernetes，承载其上的应用才是价值之所在。
|
||||
|
||||
|
|
@ -46,7 +46,7 @@
|
|||
|
||||
|
||||
|
||||
但就2017年为止，kubernetes的主要使用场景也主要作为应用开发测试环境、CI/CD和运行Web应用这几个领域，如下图[TheNewStack](http://thenewstack.io)的Kubernetes生态状况调查报告所示。
|
||||
但就2017年为止，Kubernetes的主要使用场景也主要作为应用开发测试环境、CI/CD和运行Web应用这几个领域，如下图[TheNewStack](http://thenewstack.io)的Kubernetes生态状况调查报告所示。
|
||||
|
||||
|
||||
|
||||
|
|
@ -54,7 +54,7 @@
|
|||
|
||||
|
||||
|
||||
当前各大公有云如Google GKE、微软Azure ACS、亚马逊EKS（2018年上线）、VmWare、Pivotal、腾讯云、阿里云等都提供了Kuberentes服务。
|
||||
当前各大公有云如Google GKE、微软Azure ACS、亚马逊EKS（2018年上线）、VMWare、Pivotal、腾讯云、阿里云等都提供了Kubernetes服务。
|
||||
|
||||
## 微服务
|
||||
|
||||
|
|
@ -133,16 +133,16 @@ CNCF（云原生计算基金会）给出了云原生应用的三大特征：
|
|||
|
||||
|
||||
|
||||
Kubernetes中的应用将作为微服务运行，但是Kuberentes本身并没有给出微服务治理的解决方案，比如服务的限流、熔断、良好的灰度发布支持等。
|
||||
Kubernetes中的应用将作为微服务运行，但是Kubernetes本身并没有给出微服务治理的解决方案，比如服务的限流、熔断、良好的灰度发布支持等。
|
||||
|
||||
**Service mesh可以用来做什么**
|
||||
**Service Mesh可以用来做什么**
|
||||
|
||||
- Traffic Management：API网关
|
||||
- Observability：服务调用和性能分析
|
||||
- Policy Enforcment：控制服务访问策略
|
||||
- Service Identity and Security：安全保护
|
||||
|
||||
**Service mesh的特点**
|
||||
**Service Mesh的特点**
|
||||
|
||||
- 专用的基础设施层
|
||||
- 轻量级高性能网络代理
|
||||
|
|
@ -150,7 +150,7 @@ Kubernetes中的应用将作为微服务运行，但是Kuberentes本身并没有
|
|||
- 扩展kubernetes的应用负载均衡机制，实现灰度发布
|
||||
- 完全解耦于应用，应用可以无感知，加速应用的微服务和云原生转型
|
||||
|
||||
使用Service Mesh将可以有效的治理Kuberentes中运行的服务，当前开源的Service Mesh有：
|
||||
使用Service Mesh将可以有效的治理Kubernetes中运行的服务，当前开源的Service Mesh有：
|
||||
|
||||
- Linkderd：<https://linkerd.io>，由最早提出Service Mesh的公司[Buoyant](https://buoyant.io)开源，创始人来自Twitter
|
||||
- Envoy：<https://www.envoyproxy.io/>，Lyft开源的，可以在Istio中使用Sidecar模式运行
|
||||
|
|
@ -167,15 +167,15 @@ Linkerd和Istio是最早开源的Service Mesh，它们都支持Kubernetes，下
|
|||
| ----------- | ------------- | ---------------------------- |
|
||||
| 部署架构 | Envoy/Sidecar | DaemonSets |
|
||||
| 易用性 | 复杂 | 简单 |
|
||||
| 支持平台 | kuberentes | kubernetes/mesos/Istio/local |
|
||||
| 当前版本 | 0.3.0 | 1.3.3 |
|
||||
| 支持平台 | Kubernetes | Kubernetes/Mesos/Istio/Local |
|
||||
| 当前版本 | 0.8 | 1.4.3 |
|
||||
| 是否已有生产部署 | 否 | 是 |
|
||||
|
||||
关于两者的架构可以参考各自的官方文档，我只从其在kubernetes上的部署结构来说明其区别。
|
||||
关于两者的架构可以参考各自的官方文档，我只从其在Kubernetes上的部署结构来说明其区别。
|
||||
|
||||
|
||||
|
||||
Istio的组件复杂，可以分别部署的kubernetes集群中，但是作为核心路由组件**Envoy**是以**Sidecar**形式与应用运行在同一个Pod中的，所有进入该Pod中的流量都需要先经过Envoy。
|
||||
Istio的组件复杂，可以分别部署在Kubernetes集群中，但是作为核心路由组件**Envoy**是以**Sidecar**形式与应用运行在同一个Pod中的，所有进入该Pod中的流量都需要先经过Envoy。
|
||||
|
||||
Linker的部署十分简单，本身就是一个镜像，使用Kubernetes的[DaemonSet](https://jimmysong.io/kubernetes-handbook/concepts/daemonset.html)方式在每个node节点上运行。
|
||||
|
||||
|
|
@ -189,7 +189,7 @@ Linker的部署十分简单，本身就是一个镜像，使用Kubernetes的[Dae
|
|||
|
||||
**GitOps**
|
||||
|
||||
给开发者带来最大配置和上线的灵活性，践行DevOps流程，改善研发效率，下图这样的情况将更少发生。
|
||||
给开发者带来最大的配置和上线的灵活性，践行DevOps流程，改善研发效率，下图这样的情况将更少发生。
|
||||
|
||||
|
||||
|
||||
|
|
@ -197,7 +197,7 @@ Linker的部署十分简单，本身就是一个镜像，使用Kubernetes的[Dae
|
|||
|
||||
**Big Data**
|
||||
|
||||
Spark现在已经非官方支持了基于Kuberentes的原生调度，其具有以下特点：
|
||||
Spark现在已经非官方支持了基于Kubernetes的原生调度，其具有以下特点：
|
||||
|
||||
- Kubernetes原生调度：与yarn、mesos同级
|
||||
- 资源隔离，粒度更细：以namespace来划分用户
|
||||
|
|
@ -216,7 +216,7 @@ Spark现在已经非官方支持了基于Kuberentes的原生调度，其具有
|
|||
|
||||
|
||||
|
||||
从上图中可以看到在Kubernetes上使用YARN调度、standalone调度和kubernetes原生调度的方式，每个node节点上的Pod内的spark Executor分布，毫无疑问，使用kubernetes原生调度的spark任务才是最节省资源的。
|
||||
从上图中可以看到在Kubernetes上使用YARN调度、standalone调度和Kubernetes原生调度的方式，每个node节点上的Pod内的Spark Executor分布，毫无疑问，使用Kubernetes原生调度的Spark任务才是最节省资源的。
|
||||
|
||||
提交任务的语句看起来会像是这样的：
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue