Update CNCF sandbox citeria
parent
f3dd60e6be
commit
c029237207
|
@ -13,5 +13,3 @@
|
|||
## 参考
|
||||
|
||||
- [Kubernetes 1.15: Extensibility and Continuous Improvement](https://kubernetes.io/blog/2019/06/19/kubernetes-1-15-release-announcement/)
|
||||
|
||||
- [Kubernetes 1.15 Changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md)
|
|
@ -39,5 +39,3 @@
|
|||
**弃用**
|
||||
|
||||
- 第三方资源(TPR)已被自定义资源定义(Custom Resource Definitions,CRD)取代,后者提供了一个更清晰的API,并解决了TPR测试期间引发的问题和案例。如果您使用TPR测试版功能,则建议您迁移,因为它将在Kubernetes 1.8中被移除。
|
||||
|
||||
以上是Kubernetes1.7中的主要新特性,详细更新文档请查看[Changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.7.md)。
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
## 开源项目加入CNCF Sandbox的要求
|
||||
|
||||
[CNCF Project Proposal Process v1.2][CNCF Project Proposal Process v1.2]中指出开源项目要想加入 CNCF 必须满足以下条件:
|
||||
[CNCF Project Proposal Process](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc) 中指出开源项目要想加入 CNCF 必须满足以下条件:
|
||||
|
||||
1. 项目名称必须在 CNCF 中唯一
|
||||
2. 项目描述(用途、价值、起源、历史)
|
||||
|
@ -18,13 +18,24 @@
|
|||
14. 发布方法和机制
|
||||
15. 社交媒体账号
|
||||
16. 社区规模和已有的赞助商
|
||||
17. svg 格式的项目 logo
|
||||
17. 用户、使用规模、是否用在生产环境,要有证据说明
|
||||
18. svg 格式的项目 logo
|
||||
|
||||
### 项目接纳过程
|
||||
|
||||
1. 在 TOC 会议上展示提议
|
||||
2. 项目获得 TOC 2/3 多数投票同意
|
||||
整个流程比较复杂,持续时间也不比较久,如 CNCF 提供的这张图所示。
|
||||
|
||||
![sandbox 流程](../images/sandbox-process.png)
|
||||
|
||||
大体流程如下:
|
||||
|
||||
1. 通过 [GitHub Issue](https://github.com/cncf/toc/issues) 提交 proposal
|
||||
1. TOC 确认项目分类,归类到一个 [CNCF SIG](https://github.com/cncf/toc/blob/master/sigs/cncf-sigs.md) 中(两周)
|
||||
1. SIG 评估(1到 2 个月)
|
||||
1. TOC review
|
||||
1. TOC 拉票,至少 3 票(2 个月)
|
||||
1. 治理和法律问题(CNCF 来处理)
|
||||
|
||||
## 参考
|
||||
|
||||
- [CNCF Project Proposal Process v1.2 - github.com](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc)
|
||||
- [CNCF Project Proposal Process - github.com](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc)
|
||||
|
|
|
@ -312,4 +312,3 @@ test - 178.91.123.132
|
|||
- [Kubernetes Ingress Resource](https://kubernetes.io/docs/concepts/services-networking/ingress/)
|
||||
- [使用NGINX Plus负载均衡Kubernetes服务](http://dockone.io/article/957)
|
||||
- [使用 NGINX 和 NGINX Plus 的 Ingress Controller 进行 Kubernetes 的负载均衡](http://www.cnblogs.com/276815076/p/6407101.html)
|
||||
- [Kubernetes : Træfɪk and Let's Encrypt at scale](https://blog.osones.com/en/kubernetes-traefik-and-lets-encrypt-at-scale.html)
|
||||
|
|
Binary file not shown.
After Width: | Height: | Size: 42 KiB |
|
@ -4,7 +4,7 @@ Heapster作为kubernetes安装过程中默认安装的一个插件,见[安装h
|
|||
|
||||
Heapster可以收集Node节点上的cAdvisor数据,还可以按照kubernetes的资源类型来集合资源,比如Pod、Namespace域,可以分别获取它们的CPU、内存、网络和磁盘的metric。默认的metric数据聚合时间间隔是1分钟。
|
||||
|
||||
**注意** :Kubernetes 1.11 不建议使用 Heapster,就 SIG Instrumentation 而言,这是为了转向新的 Kubernetes 监控模型的持续努力的一部分。仍使用 Heapster 进行自动扩展的集群应迁移到 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 和自定义指标 API。有关详细信息,请参阅 [Kubernetes 1.11 版本日志](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md)。
|
||||
**注意** :Kubernetes 1.11 不建议使用 Heapster,就 SIG Instrumentation 而言,这是为了转向新的 Kubernetes 监控模型的持续努力的一部分。仍使用 Heapster 进行自动扩展的集群应迁移到 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 和自定义指标 API。
|
||||
|
||||
## 参考
|
||||
|
||||
|
|
|
@ -35,7 +35,7 @@
|
|||
### 准备
|
||||
|
||||
1. 备份kubernetes原先的二进制文件和配置文件。
|
||||
2. 下载最新版本的kubernetes二进制包,如1.8.5版本,查看[changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.8.md),下载二进制包,我们使用的是[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.8.5/kubernetes-server-linux-amd64.tar.gz),分发到集群的每个节点上。
|
||||
2. 下载最新版本的kubernetes二进制包,如1.8.5版本,下载二进制包,我们使用的是[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.8.5/kubernetes-server-linux-amd64.tar.gz),分发到集群的每个节点上。
|
||||
|
||||
### 升级master节点
|
||||
|
||||
|
|
|
@ -238,7 +238,7 @@ iperf -c ${server-ip} -p 12345 -i 1 -t 10 -w 20K
|
|||
|
||||
使用Flannel的**vxlan**模式实现每个pod一个IP的方式,会比宿主机直接互联的网络性能损耗30%~40%,符合网上流传的测试结论。而flannel的host-gw模式比起宿主机互连的网络性能损耗大约是10%。
|
||||
|
||||
Vxlan会有一个封包解包的过程,所以会对网络性能造成较大的损耗,而host-gw模式是直接使用路由信息,网络损耗小,关于host-gw的架构请访问[Flannel host-gw architecture](https://docs.openshift.com/container-platform/3.4/architecture/additional_concepts/flannel.html)。
|
||||
Vxlan会有一个封包解包的过程,所以会对网络性能造成较大的损耗,而host-gw模式是直接使用路由信息,网络损耗小。
|
||||
|
||||
## Kubernete的性能测试
|
||||
|
||||
|
@ -390,4 +390,3 @@ Locust模拟10万用户,每秒增长100个。
|
|||
- [Kubernetes集群性能测试](https://supereagle.github.io/2017/03/09/kubemark/)
|
||||
- [CoreOS是如何将Kubernetes的性能提高10倍的](http://dockone.io/article/1050)
|
||||
- [运用Kubernetes进行分布式负载测试](http://www.csdn.net/article/2015-07-07/2825155)
|
||||
- [Flannel host-gw architecture](https://docs.openshift.com/container-platform/3.4/architecture/additional_concepts/flannel.html)
|
||||
|
|
Loading…
Reference in New Issue