Jimmy Song
GitHub
commit
43f221487c
|
|
@ -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（开源）。
|
||||
|
||||
|
|
@ -28,11 +28,11 @@
|
|||
|
||||
**Kubernetes是容器编排系统的事实标准**
|
||||
|
||||
在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势，而对于容器的编排管理，Swarm、Mesos和Kubernetes的大战已经基本宣告结束，kubernetes成为了无可争议的赢家。
|
||||
在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势，而对于容器的编排管理，Swarm、Mesos和Kubernetes的大战已经基本宣告结束，Kubernetes成为了无可争议的赢家。
|
||||
|
||||
下面这张图是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任务才是最节省资源的。
|
||||
|
||||
提交任务的语句看起来会像是这样的：
|
||||
|
||||
|
|
|
|||
|
|
@ -247,7 +247,7 @@ Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载
|
|||
1. 用户向Gitlab提交代码，代码中必须包含`Dockerfile`
|
||||
2. 将代码提交到远程仓库
|
||||
3. 用户在发布应用时需要填写git仓库地址和分支、服务类型、服务名称、资源数量、实例个数，确定后触发Jenkins自动构建
|
||||
4. Jenkins的CI流水线自动编译代码并打包成docker镜像推送到Harbor镜像仓库
|
||||
4. Jenkins的CI流水线自动编译代码并打包成Docker镜像推送到Harbor镜像仓库
|
||||
5. Jenkins的CI流水线中包括了自定义脚本，根据我们已准备好的Kubernetes的YAML模板，将其中的变量替换成用户输入的选项
|
||||
6. 生成应用的Kubernetes YAML配置文件
|
||||
7. 更新Ingress的配置，根据新部署的应用的名称，在Ingress的配置文件中增加一条路由信息
|
||||
|
|
@ -266,20 +266,20 @@ Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载
|
|||
|
||||
Kubernetes是一个多租户的云平台，因此必须对用户的权限加以限制，对用户空间进行隔离。Kubernetes中的隔离主要包括这几种：
|
||||
|
||||
* 网络隔离：需要使用网络插件，比如[calico](https://www.projectcalico.org/)。
|
||||
* 网络隔离：需要使用网络插件，比如[flannel](https://coreos.com/flannel/), [calico](https://www.projectcalico.org/)。
|
||||
* 资源隔离：kubernetes原生支持资源隔离，pod就是资源就是隔离和调度的最小单位，同时使用[namespace](https://jimmysong.io/kubernetes-handbook/concepts/namespace.html)限制用户空间和资源限额。
|
||||
* 身份隔离：使用[RBAC-基于角色的访问控制](https://jimmysong.io/kubernetes-handbook/guide/rbac.html)，多租户的身份认证和权限控制。
|
||||
|
||||
## 如何开发Kubernetes原生应用步骤介绍
|
||||
|
||||
当我们有了一个kubernetes集群后，如何在上面开发和部署应用，应该遵循怎样的流程？下面我将展示如何使用go语言开发和部署一个kubernetes native应用，使用wercker进行持续集成与持续发布，我将以一个很简单的前后端访问，获取伪造数据并展示的例子来说明。
|
||||
当我们有了一个kubernetes集群后，如何在上面开发和部署应用，应该遵循怎样的流程？下面我将展示如何使用go语言开发和部署一个Kubernetes native应用，使用wercker进行持续集成与持续发布，我将以一个很简单的前后端访问，获取伪造数据并展示的例子来说明。
|
||||
|
||||
### 云原生应用开发示例
|
||||
|
||||
我们将按照如下步骤来开发部署一个kubernetes原生应用并将它部署到kubernetes集群上开放给集群外访问：
|
||||
我们将按照如下步骤来开发部署一个Kubernetes原生应用并将它部署到Kubernetes集群上开放给集群外访问：
|
||||
|
||||
1. 服务API的定义
|
||||
2. 使用Go语言开发kubernetes原生应用
|
||||
2. 使用Go语言开发Kubernetes原生应用
|
||||
3. 一个持续构建与发布工具与环境
|
||||
4. 使用traefik和VIP做边缘节点提供外部访问路由
|
||||
|
||||
|
|
@ -294,7 +294,7 @@ Kubernetes是一个多租户的云平台，因此必须对用户的权限加以
|
|||
|
||||
|
||||
|
||||
详见：[如何开发部署kubernetes native应用](https://jimmysong.io/posts/creating-cloud-native-app-with-kubernetes/)。
|
||||
详见：[如何开发部署Kubernetes Native应用](https://jimmysong.io/posts/creating-cloud-native-app-with-kubernetes/)。
|
||||
|
||||
## 如何迁移到云原生应用架构
|
||||
|
||||
|
|
@ -327,33 +327,37 @@ Kubernetes是一个多租户的云平台，因此必须对用户的权限加以
|
|||
1. 将原有应用拆解为服务
|
||||
2. 容器化、制作镜像
|
||||
3. 准备应用配置文件
|
||||
4. 准备kubernetes YAML文件
|
||||
4. 准备Kubernetes YAML文件
|
||||
5. 编写bootstarp脚本
|
||||
6. 创建ConfigMaps
|
||||
|
||||
详见：[迁移传统应用到Kubernetes步骤详解——以Hadoop YARN为例](https://jimmysong.io/posts/migrating-hadoop-yarn-to-kubernetes/)。
|
||||
|
||||
## Service mesh基本原理和示例介绍
|
||||
## Service Mesh基本原理和示例介绍
|
||||
|
||||
Service mesh现在一般被翻译作服务网格，目前主流的Service mesh有如下两款：
|
||||
Service Mesh现在一般被翻译作服务网格，目前主流的Service Mesh有如下几款：
|
||||
|
||||
* [Istio](https://istio.io)：IBM、Google、Lyft共同开源，详细文档见[Istio官方文档中文版](http://istio.doczh.cn/)
|
||||
* [Linkerd](https://linkerd.io)：原Twitter工程师开发，现为[CNCF](https://cncf.io)中的项目之一
|
||||
* [Envoy](https://www.envoyproxy.io/)：Lyft开源的，可以在Istio中使用Sidecar模式运行
|
||||
* [Conduit](https://conduit.io)：同样由Buoyant开源的轻量级的基于Kubernetes的Service Mesh
|
||||
|
||||
### 什么是Service mesh
|
||||
此外还有很多其它的Service Mesh鱼贯而出，请参考[awesome-cloud-native](https://jimmysong.io/awesome-cloud-native)。
|
||||
|
||||
### 什么是Service Mesh
|
||||
|
||||
如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
|
||||
|
||||
|
||||
|
||||
详见[什么是 service mesh - jimmysong.io](https://jimmysong.io/posts/what-is-a-service-mesh/)。
|
||||
详见[什么是 Service Mesh - jimmysong.io](https://jimmysong.io/posts/what-is-a-service-mesh/)。
|
||||
|
||||
### Service mesh使用指南
|
||||
### Service Mesh使用指南
|
||||
|
||||
两款Service mesh各有千秋，我分别写了他们的使用案例指南：
|
||||
两款Service Mesh各有千秋，我分别写了他们的使用案例指南：
|
||||
|
||||
* [微服务管理框架service mesh——Linkerd安装试用笔记](https://jimmysong.io/posts/linkerd-user-guide/)
|
||||
* [微服务管理框架service mesh——Istio安装试用笔记](https://jimmysong.io/posts/istio-installation/)
|
||||
* [微服务管理框架Service Mesh——Linkerd安装试用笔记](https://jimmysong.io/posts/linkerd-user-guide/)
|
||||
* [微服务管理框架Service Mesh——Istio安装试用笔记](https://jimmysong.io/posts/istio-installation/)
|
||||
|
||||
更多关于 Service Mesh 的内容请访问 [Service Mesh 中文网](http://www.servicemesh.cn)。
|
||||
|
||||
|
|
@ -365,15 +369,15 @@ Kubernetes作为云原生计算的基本组件之一，开源2年时间以来热
|
|||
|
||||
### DevOps
|
||||
|
||||
下面是社区中kubernetes开源爱好者的分享内容，我觉得是对kubernetes在DevOps中应用的很好的形式值得大家借鉴。
|
||||
下面是社区中Kubernetes开源爱好者的分享内容，我觉得是对Kubernetes在DevOps中应用的很好的形式值得大家借鉴。
|
||||
|
||||
真正践行DevOps，让开发人员在掌握自己的开发和测试环境，让环境一致，让开发效率提升，让运维没有堆积如山的tickets，让监控更加精准，从kubernetes平台开始。
|
||||
真正践行DevOps，让开发人员在掌握自己的开发和测试环境，让环境一致，让开发效率提升，让运维没有堆积如山的tickets，让监控更加精准，从Kubernetes平台开始。
|
||||
|
||||
**行动指南**
|
||||
|
||||
1. 根据环境（比如开发、测试、生产）划分`namespace`，也可以根据项目来划分
|
||||
2. 再为每个用户划分一个`namespace`、创建一个`serviceaccount`和`kubeconfig`文件，不同`namespace`间的资源隔离，目前不隔离网络，不同`namespace`间的服务可以互相访问
|
||||
3. 创建yaml模板，降低编写kubernetes yaml文件编写难度
|
||||
3. 创建yaml模板，降低编写Kubernetes yaml文件编写难度
|
||||
4. 在`kubectl`命令上再封装一层，增加用户身份设置和环境初始化操作，简化`kubectl`命令和常用功能
|
||||
5. 管理员通过dashboard查看不同`namespace`的状态，也可以使用它来使操作更便捷
|
||||
6. 所有应用的日志统一收集到ElasticSearch中，统一日志访问入口
|
||||
|
|
@ -410,13 +414,13 @@ Kubernetes全局监控图2
|
|||
|
||||
TL;DR [https://jimmysong.io/spark-on-k8s](https://jimmysong.io/spark-on-k8s)
|
||||
|
||||
Spark原生支持standalone、mesos和YARN资源调度，现已支持Kubernetes原生调度，详见[运行支持kubernetes原生调度的spark程序-Spark on Kubernetes](https://jimmysong.io/posts/running-spark-with-kubernetes-native-scheduler/)。
|
||||
Spark原生支持standalone、mesos和YARN资源调度，现已支持Kubernetes原生调度，详见[运行支持Kubernetes原生调度的spark程序-Spark on Kubernetes](https://jimmysong.io/posts/running-spark-with-kubernetes-native-scheduler/)。
|
||||
|
||||
**为何要使用spark on kubernetes**
|
||||
|
||||
使用kubernetes原生调度的spark on kubernetes是对原先的spark on yarn和yarn on docker的改变是革命性的，主要表现在以下几点：
|
||||
使用Kubernetes原生调度的spark on kubernetes是对原先的spark on yarn和yarn on docker的改变是革命性的，主要表现在以下几点：
|
||||
|
||||
1. **Kubernetes原生调度**：不再需要二层调度，直接使用kubernetes的资源调度功能，跟其他应用共用整个kubernetes管理的资源池；
|
||||
1. **Kubernetes原生调度**：不再需要二层调度，直接使用Kubernetes的资源调度功能，跟其他应用共用整个kubernetes管理的资源池；
|
||||
2. **资源隔离，粒度更细**：原先yarn中的queue在spark on kubernetes中已不存在，取而代之的是kubernetes中原生的namespace，可以为每个用户分别指定一个namespace，限制用户的资源quota；
|
||||
3. **细粒度的资源分配**：可以给每个spark任务指定资源限制，实际指定多少资源就使用多少资源，因为没有了像yarn那样的二层调度（圈地式的），所以可以更高效和细粒度的使用资源；
|
||||
4. **监控的变革**：因为做到了细粒度的资源分配，所以可以对用户提交的每一个任务做到资源使用的监控，从而判断用户的资源使用情况，所有的metric都记录在数据库中，甚至可以为每个用户的每次任务提交计量；
|
||||
|
|
@ -424,7 +428,7 @@ Spark原生支持standalone、mesos和YARN资源调度，现已支持Kubernetes
|
|||
|
||||
**如何提交任务**
|
||||
|
||||
仍然使用`spark-submit`提交spark任务，可以直接指定kubernetes API server地址，下面的命令提交本地jar包到kubernetes集群上运行，同时指定了运行任务的用户、提交命名的用户、运行的excutor实例数、driver和executor的资源限制、使用的spark版本等信息。
|
||||
仍然使用`spark-submit`提交spark任务，可以直接指定Kubernetes API server地址，下面的命令提交本地jar包到Kubernetes集群上运行，同时指定了运行任务的用户、提交命名的用户、运行的excutor实例数、driver和executor的资源限制、使用的spark版本等信息。
|
||||
|
||||
详细使用说明见[Apache Spark on Kubernetes用户指南 - jimmysong.io](https://jimmysong.io/spark-on-k8s/user-guide.html)。
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@
|
|||
|
||||
也可以有平台提供以上所有功能，还可以有提供可观测性、分析和扩展应用。
|
||||
|
||||
看到这个景观图，大家觉得kubernetes真的还只做了容器编排吗？实际上它是制定了一个标准。就像一个系统一样，所有的应用和插件都是基于它来构建的。
|
||||
看到这个景观图，大家觉得Kubernetes真的还只做了容器编排吗？实际上它是制定了一个标准。就像一个系统一样，所有的应用和插件都是基于它来构建的。
|
||||
|
||||
## Kubernetes的现状与未来
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ Kubernetes发展已经有3年多的时间了，它已经基本成为了容器编
|
|||
|
||||
|
||||
|
||||
我们看到图中有两个是kubernetes原生的组件，API server和kubelet，我们创建了virt-controller就是为了创建CRD的controller，它扩展了kube-controller的功能，用于管理虚拟机的生命周期，同时在每个节点上都用DaemonSet的方式运行一个virt-handler，这个handler是用于创建虚拟机的处理器，每个节点上即可用运行虚拟机也可以运行容器，只要这个节点上有virt-handler就可以运行和调度虚拟机。
|
||||
我们看到图中有两个是Kubernetes原生的组件，API server和kubelet，我们创建了virt-controller就是为了创建CRD的controller，它扩展了kube-controller的功能，用于管理虚拟机的生命周期，同时在每个节点上都用DaemonSet的方式运行一个virt-handler，这个handler是用于创建虚拟机的处理器，每个节点上即可用运行虚拟机也可以运行容器，只要这个节点上有virt-handler就可以运行和调度虚拟机。
|
||||
|
||||
### Kubernetes做了什么？
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ Kubernetes的资源隔离也能保证对集群资源的最大化和最优利用
|
|||
|
||||
Kubernetes中的基本资源类型分成了三类：
|
||||
|
||||
- 部署：Deploymnt、StatefulSet、DaemonSet、Job、CronJob
|
||||
- 部署：Deploymnt、ReplicaSet、StatefulSet、DaemonSet、Job、CronJob
|
||||
- 服务：Service、Ingress
|
||||
- 存储：PV、PVC、ConfigMap、Secret
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ Kubernetes始于12因素应用的PaaS平台，它是微服务的绝佳部署管
|
|||
|
||||
为了实现上述的各种能力，急需解决的就是基于Kubernetes的持续集成和发布问题。
|
||||
|
||||
当前出现了一系列的基于Kubernetes的CI/CD工具，如Jenkins-x、Gitkube，它提供了从代码提交、自动编译、打包镜像、配置注入、发布部署到kubernetes平台的一系列自动化流程。
|
||||
当前出现了一系列的基于Kubernetes的CI/CD工具，如Jenkins-x、Gitkube，它提供了从代码提交、自动编译、打包镜像、配置注入、发布部署到Kubernetes平台的一系列自动化流程。
|
||||
|
||||
甚至出现了像ballerina这样的云原生编程语言，它的出现就是为了解决应用开发到服务集成之间的鸿沟的。它有以下几个特点。
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ Pilot和控制平面是为了运维人员准备的。
|
|||
|
||||
数据平面是为开发人员准备的。
|
||||
|
||||
Isito在每个上下游服务之间部署一个Envoy，Envoy中有几个基本的服务发现服务，监听器即Envoy要转发的流量端口，Endpoint是要转发的目的地，Cluster是一些列Endpoint用来做负载均衡，Route是定义各种路由规则，每个Envoy进程里可以设置多个Listener。
|
||||
Isito在每个上下游服务之间部署一个Envoy，Envoy中有几个基本的服务发现服务，监听器即Envoy要转发的流量端口，Endpoint是要转发的目的地，Cluster是一系列Endpoint用来做负载均衡，Route是定义各种路由规则，每个Envoy进程里可以设置多个Listener。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue