Fix typo (#418)
n374
GitHub
parent
dd4031be7e
commit
064e630d1c
|
|
@ -129,7 +129,7 @@ Kubernetes 并不直接对外提供业务能力，而是作为应用运行的底
|
||||||
- Service Mesh 解决服务间的流量治理，最小的治理单元是 Service（可以类比为 Kubernetes 中 Service 资源）；
|
- Service Mesh 解决服务间的流量治理，最小的治理单元是 Service（可以类比为 Kubernetes 中 Service 资源）；
|
||||||
- 而 Serviceless 是更高一层的抽象，最小的治理单元是 APP；
|
- 而 Serviceless 是更高一层的抽象，最小的治理单元是 APP；
|
||||||
|
|
||||||
越向上层就越不关心应用的底层实现，到了 Serverless 开发者只需要关心代码逻辑，其他的一起都是配置，因此 Google 联合 Pivotal 等其他公司于2018年7月创建了 [knative](https://github.com/knative) 这个基于 Kubernetes 和 Istio 的 Serverless 的开源项目。
|
越向上层就越不关心应用的底层实现，到了 Serverless 开发者只需要关心代码逻辑，其他的一切都是配置，因此 Google 联合 Pivotal 等其他公司于2018年7月创建了 [knative](https://github.com/knative) 这个基于 Kubernetes 和 Istio 的 Serverless 的开源项目。
|
||||||
|
|
||||||
## 出版物
|
## 出版物
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -68,7 +68,7 @@ Kubernetes细化的应用程序的分解粒度，同时将服务发现、配置
|
||||||
5. 使用Deployment history来回滚到历史版本。
|
5. 使用Deployment history来回滚到历史版本。
|
||||||
6. 使用ConfigMap和Secret来存储配置。
|
6. 使用ConfigMap和Secret来存储配置。
|
||||||
7. 在Pod里增加Readiness和Liveness探针。
|
7. 在Pod里增加Readiness和Liveness探针。
|
||||||
8. 给Pod这只CPU和内存资源限额。
|
8. 给Pod设置CPU和内存资源限额。
|
||||||
9. 定义多个namespace来限制默认service范围的可视性。
|
9. 定义多个namespace来限制默认service范围的可视性。
|
||||||
10. 配置HPA来动态扩展无状态工作负载。
|
10. 配置HPA来动态扩展无状态工作负载。
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -16,7 +16,7 @@
|
||||||
|
|
||||||
## Side-effect
|
## Side-effect
|
||||||
|
|
||||||
1. 首先kubernetes本身就提供了数据持久化的解决方案statefulset，不过需要用到公有云的存储货其他分布式存储，这一点在我们的私有云环境里被否定了。
|
1. 首先kubernetes本身就提供了数据持久化的解决方案statefulset，不过需要用到公有云的存储或其他分布式存储，这一点在我们的私有云环境里被否定了。
|
||||||
2. 需要管理主机的label，增加运维复杂度，但是具体问题具体对待
|
2. 需要管理主机的label，增加运维复杂度，但是具体问题具体对待
|
||||||
3. 必须保证应用启动顺序，需要先启动logstash
|
3. 必须保证应用启动顺序，需要先启动logstash
|
||||||
4. 为主机打label使用nodeSelector的方式限制了资源调度的范围
|
4. 为主机打label使用nodeSelector的方式限制了资源调度的范围
|
||||||
|
|
|
||||||
|
|
@ -18,7 +18,7 @@
|
||||||
| 配置和秘钥管理 | 配额管理 |
|
| 配置和秘钥管理 | 配额管理 |
|
||||||
| / | 协议转换（REST、gRPC） |
|
| / | 协议转换（REST、gRPC） |
|
||||||
|
|
||||||
以上是容器编排中缺少的服务级别的能力，当让类似Kubernetes这样的容器编排系统中也有服务管理的能力，如Ingress Controller，但是它仅仅负责集群内的服务对外暴露的反向代理，每个Ingress Controller的能力受限于Kubernetes的编程模型。对服务进行管理还可以通过例如Kong、基于云的负载均衡器、API Gateway和API管理来实现，在没有Service Mesh的时候还需要如[Finagle](https://finagle.github.io/blog/)、[Hystrix](https://github.com/Netflix/Hystrix)、[Ribbon](https://github.com/Netflix/ribbon)客户端库的加持。
|
以上是容器编排中缺少的服务级别的能力，当然类似Kubernetes这样的容器编排系统中也有服务管理的能力，如Ingress Controller，但是它仅仅负责集群内的服务对外暴露的反向代理，每个Ingress Controller的能力受限于Kubernetes的编程模型。对服务进行管理还可以通过例如Kong、基于云的负载均衡器、API Gateway和API管理来实现，在没有Service Mesh的时候还需要如[Finagle](https://finagle.github.io/blog/)、[Hystrix](https://github.com/Netflix/Hystrix)、[Ribbon](https://github.com/Netflix/ribbon)客户端库的加持。
|
||||||
|
|
||||||
下图是一个使用**客户端库**将应用与服务治理紧耦合的示意图。
|
下图是一个使用**客户端库**将应用与服务治理紧耦合的示意图。
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -77,7 +77,7 @@ Service Mesh中服务是一等公民，它提供L5的网络流量管理，并提
|
||||||
|
|
||||||
**延迟和故障注入**
|
**延迟和故障注入**
|
||||||
|
|
||||||
这个功能对于荣宰容灾和故障演练特别有用。通过人为的向系统中注入故障，如HTTP 500错误，通过分析分布式应用的行为，检验系统的健壮性。
|
这个功能对于容灾和故障演练特别有用。通过人为的向系统中注入故障，如HTTP 500错误，通过分析分布式应用的行为，检验系统的健壮性。
|
||||||
|
|
||||||
### 在L5解耦
|
### 在L5解耦
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue