Update gitbook
- Add CNCF Chapter - Delete broken links - Move some pages to cloud-native folder - Add GFW website lists to skip lint progress - Update READMEpull/357/head
parent
8f94d22465
commit
87aad82985
2
Makefile
2
Makefile
|
@ -8,7 +8,7 @@ build:
|
|||
|
||||
.PHONY: lint
|
||||
lint:
|
||||
htmlproofer --url-ignore "/localhost/,/172.17.8.101/,/172.20.0.113/,/slideshare.net/,/grpc.io/,/kiali.io/,/condiut.io/,/twitter.com/,/facebook.com/,/medium.com/,/google.com/,/jimmysong.io/,/openfaas.com/,/linkerd.io/,/layer5.io/,/thenewstack.io/,/blog.envoyproxy.io/,/blog.openebs.io/,/k8smeetup.github.io/,/blog.heptio.com/,/apigee.com/,/speakerdeck.com/,/download.svcat.sh/,/blog.fabric8.io/,/blog.heptio.com/,/blog.containership.io/,/blog.mobyproject.org/,/blog.spinnaker.io/,/coscale.com/,/zh.wikipedia.org/" $(BOOK_OUTPUT)
|
||||
htmlproofer --url-ignore "/localhost/,/172.17.8.101/,/172.20.0.113/,/slideshare.net/,/grpc.io/,/kiali.io/,/condiut.io/,/twitter.com/,/facebook.com/,/medium.com/,/google.com/,/jimmysong.io/,/openfaas.com/,/linkerd.io/,/layer5.io/,/thenewstack.io/,/blog.envoyproxy.io/,/blog.openebs.io/,/k8smeetup.github.io/,/blog.heptio.com/,/apigee.com/,/speakerdeck.com/,/download.svcat.sh/,/blog.fabric8.io/,/blog.heptio.com/,/blog.containership.io/,/blog.mobyproject.org/,/blog.spinnaker.io/,/coscale.com/,/zh.wikipedia.org/,/labs.play-with-k8s.com/,/cilium.readthedocs.io/,/azure.microsoft.com/,/storageos.com/,/openid.net/,/prometheus.io/,/coreos.com/,/openwhisk.incubator.apache.org/" $(BOOK_OUTPUT)
|
||||
|
||||
.PHONY: serve
|
||||
serve:
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Kubernetes Handbook——Kubernetes中文指南/云原生应用架构实践手册
|
||||
|
||||
[Kubernetes](http://kubernetes.io)是Google基于[Borg](https://research.google.com/pubs/pub43438.html)开源的容器编排调度引擎,作为[CNCF](http://cncf.io)(Cloud Native Computing Foundation)最重要的组件之一,它的目标不仅仅是一个编排系统,而是提供一个规范,可以让你来描述集群的架构,定义服务的最终状态,Kubernetes可以帮你将系统自动地达到和维持在这个状态。Kubernetes作为云原生应用的基石,相当于一个云操作系统,其重要性不言而喻。
|
||||
[Kubernetes](http://kubernetes.io)是Google基于[Borg](https://research.google.com/pubs/pub43438.html)开源的容器编排调度引擎,作为[CNCF](https://cncf.io)(Cloud Native Computing Foundation)最重要的组件之一,它的目标不仅仅是一个编排系统,而是提供一个规范,可以让你来描述集群的架构,定义服务的最终状态,Kubernetes可以帮你将系统自动地达到和维持在这个状态。Kubernetes作为云原生应用的基石,相当于一个云操作系统,其重要性不言而喻。
|
||||
|
||||
## 关于本书
|
||||
|
||||
|
@ -43,7 +43,7 @@
|
|||
- 按照[说明](https://github.com/rootsongjc/kubernetes-handbook/blob/master/CODE_OF_CONDUCT.md)自行编译成离线版本
|
||||
- Fork 一份添加你自己的笔记自行维护,有余力者可以一起参与进来
|
||||
|
||||
**注意:本书中的 Service Mesh 相关内容已不再维护,请转至 [istio-handbook](https://jimmysong.io/istio-handbook) 浏览。**
|
||||
**注意:本书中的 Service Mesh 相关内容已不再维护,请转至 [istio-handbook](http://www.servicemesher.com/istio-handbook) 浏览。**
|
||||
|
||||
## 快速开始
|
||||
|
||||
|
@ -66,7 +66,7 @@
|
|||
- **微信群**:K8S&Cloud Native实战,扫描我的微信二维码,[Jimmy Song](http://jimmysong.io/about),或直接搜索微信号*jimmysong*后拉您入群,请增加备注(姓名-公司/学校/博客/社区/研究所/机构等)。
|
||||
- **Slack**:全球中文用户可以加入[Kubernetes官方Slack](http://slack.k8s.io)中文频道**cn-users channel**
|
||||
- **知乎专栏**:[云原生应用架构](https://zhuanlan.zhihu.com/cloud-native)
|
||||
- **微信公众号**:扫描下面的二维码关注Jimmy Song 的<u>个人微信公众号</u>CloudNativeGo(云原生应用架构)
|
||||
- **与我联系**:扫描下面的二维码关注Jimmy Song 的<u>个人微信公众号</u>CloudNativeGo(云原生应用架构)
|
||||
|
||||
<p align="center">
|
||||
<img src="https://github.com/rootsongjc/kubernetes-handbook/blob/master/images/cloud-native-go-wechat-qr-code.jpg?raw=true" alt="云原生应用架构微信公众号二维码"/>
|
||||
|
|
10
SUMMARY.md
10
SUMMARY.md
|
@ -7,8 +7,6 @@
|
|||
## 云原生
|
||||
|
||||
* [云原生(Cloud Native)的定义](cloud-native/cloud-native-definition.md)
|
||||
* [CNCF - 云原生计算基金会简介](cloud-native/cncf.md)
|
||||
* [CNCF章程](cloud-native/cncf-charter.md)
|
||||
* [云原生的设计哲学](cloud-native/cloud-native-philosophy.md)
|
||||
* [Play with Kubernetes](cloud-native/play-with-kubernetes.md)
|
||||
* [快速部署一个云原生本地实验环境](cloud-native/cloud-native-local-quick-start.md)
|
||||
|
@ -254,6 +252,13 @@
|
|||
* [社区贡献](develop/contribute.md)
|
||||
* [Minikube](develop/minikube.md)
|
||||
|
||||
## CNCF
|
||||
|
||||
* [CNCF - 云原生计算基金会简介](cloud-native/cncf.md)
|
||||
* [CNCF章程](cloud-native/cncf-charter.md)
|
||||
* [CNCF特别兴趣小组(SIG)说明](cloud-native/cncf-sig.md)
|
||||
* [CNCF中的项目治理](cloud-native/cncf-project-governing.md)
|
||||
|
||||
## 附录
|
||||
|
||||
* [附录说明](appendix/index.md)
|
||||
|
@ -278,4 +283,3 @@
|
|||
* [CNCF 2018年年度报告解读](appendix/cncf-annual-report-2018.md)
|
||||
* [Kubernetes认证服务提供商(KCSP)说明](appendix/about-kcsp.md)
|
||||
* [认证Kubernetes管理员(CKA)说明](appendix/about-cka-candidate.md)
|
||||
* [CNCF特别兴趣小组(SIG)说明](appendix/cncf-sig.md)
|
||||
|
|
|
@ -38,6 +38,6 @@
|
|||
|
||||
**弃用**
|
||||
|
||||
- 第三方资源(TPR)已被自定义资源定义(Custom Resource Definitions,CRD)取代,后者提供了一个更清晰的API,并解决了TPR测试期间引发的问题和案例。如果您使用TPR测试版功能,则建议您[迁移](https://kubernetes.io/docs/tasks/access-kubernetes-api/migrate-third-party-resource/),因为它将在Kubernetes 1.8中被移除。
|
||||
- 第三方资源(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)。
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
## Workloads API GA
|
||||
|
||||
[apps/v1 Workloads API](https://kubernetes.io/docs/reference/workloads-18-19/)成为GA(General Availability),且默认启用。 Apps Workloads API将**DaemonSet**、**Deployment**、**ReplicaSet**和**StatefulSet** API组合在一起,作为Kubernetes中长时间运行的无状态和有状态工作负载的基础。
|
||||
apps/v1 Workloads API成为GA(General Availability),且默认启用。 Apps Workloads API将**DaemonSet**、**Deployment**、**ReplicaSet**和**StatefulSet** API组合在一起,作为Kubernetes中长时间运行的无状态和有状态工作负载的基础。
|
||||
|
||||
Deployment和ReplicaSet是Kubernetes中最常用的两个对象,经过一年多的实际使用和反馈后,现在已经趋于稳定。[SIG apps](https://github.com/kubernetes/community/tree/master/sig-apps)同时将这些经验应用到另外的两个对象上,使得DaemonSet和StatefulSet也能顺利毕业走向成熟。v1(GA)意味着已经生产可用,并保证长期的向后兼容。
|
||||
|
||||
|
|
|
@ -44,7 +44,6 @@ Kubernetes和Cloud Native相关网站、专栏、博客等。
|
|||
### 网站与专栏
|
||||
|
||||
- [thenewstack.io](https://thenewstack.io/)
|
||||
- [k8sport.org](http://k8sport.org/)
|
||||
- [giantswarm blog](https://blog.giantswarm.io/)
|
||||
- [k8smeetup.com](http://www.k8smeetup.com)
|
||||
- [dockone.io](http://www.dockone.io)
|
||||
|
|
|
@ -0,0 +1,101 @@
|
|||
## CNCF中的项目治理
|
||||
|
||||
CNCF 根据“[鸿沟理论](https://www.jianshu.com/p/a305fa93580b)”将其托管的项目分成三个成熟阶段,并设置了项目晋级到更高阶段的标准。
|
||||
|
||||
> “[鸿沟理论](https://www.jianshu.com/p/a305fa93580b)”是由Geoffrey A. Moore提出的高科技产品的市场营销理论。新技术要想跨越鸿沟,必须能够实现一些跨越式的发展,**拥有某一些以前不可能实现的功能**,具有某种内在价值并能够**赢得非技术人员的**青睐。
|
||||
|
||||
![CNCF 项目的成熟度分类](https://ws1.sinaimg.cn/large/006tNc79ly1g1yzc5xre6j30o20a8q3t.jpg)
|
||||
|
||||
目前处于沙箱、孵化中、已毕业项目的数量比例为5:16:13,详见 <https://cncf.io/projects>。其中沙箱(sandbox)项目因为其处于早期阶段并没有直接在上面的链接页面中列出,而是一个单独的 [Sandbox](https://www.cncf.io/sandbox-projects/) 页面,因为 CNCF 为 sandbox 阶段的项目会谨慎背书。
|
||||
|
||||
## 纳入CNCF开源版图的项目需要符合其对云原生的定义
|
||||
|
||||
CNCF 中托管的开源项目要符合云原生定义:
|
||||
|
||||
- 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。**云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API**。
|
||||
- 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
|
||||
- 云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。
|
||||
|
||||
## 项目运作流程
|
||||
|
||||
下图演示了开源项目加入 CNCF 后的整个运作流程。
|
||||
|
||||
![CNCF中的项目运作](https://ws4.sinaimg.cn/large/006tNc79ly1g1yz80ag98j31cs0n2gr7.jpg)
|
||||
|
||||
## 开源项目如何加入 CNCF
|
||||
|
||||
1. 开源项目所支持的公司成为 CNCF 会员
|
||||
2. 开源项目满足 CNCF 的要求(见后文)
|
||||
3. 在 GitHub 上提交[proposal](https://github.com/cncf/toc/issues/113)(GitHub Issue)列举项目介绍、现状、目标、license、用户与社区等
|
||||
4. 由 Chris Aniszczyk 安排该项目在某个TOC双月会议上介绍给 TOC 成员
|
||||
5. 1.TOC 会将开源项目指定到某个 [SIG](cncf-sig.md) 中
|
||||
6. 项目获得两个TOC成员的赞成可进入[sandbox](https://github.com/cncf/toc/blob/master/process/sandbox.md)(也可以直接获得2/3多数TOC 投票进入Incubating状态)
|
||||
7. 知识产权转移给 CNCF
|
||||
8. CNCF 安排博客撰写、PR等
|
||||
9. 每年一次评审,晋升到 incubating需要2/3的 TOC 成员投票赞成;至少3家用户成功在生产上使用;通过TOC的尽职调查;贡献者数量健康稳定
|
||||
10. Sandbox 中的项目没有时效性质,可能永远都无法进入incubating 状态,被CNCF谨慎宣传
|
||||
|
||||
## CNCF 开源项目成熟度演进
|
||||
|
||||
CNCF 的开源项目遵循如下图所示的成熟度演进。
|
||||
|
||||
![CNCF项目成熟度级别](../images/cncf-graduation-criteria-v2.jpg)
|
||||
|
||||
- 加入Sandbox只需要2个TOC成员赞成
|
||||
- 成熟一点的项目可以直接进入incubating阶段,但是 CNCF 会控制不同阶段的项目比例
|
||||
- 晋级到Incubating或Graduated 需要至少2/3的 TOC成员(6名或以上)投票赞成
|
||||
- 每年将评审一次
|
||||
|
||||
## 开源项目加入 CNCF 的最低要求(Sandbox)
|
||||
|
||||
一个开源项目要想加入 CNCF 必须满足以下要求:
|
||||
|
||||
- 项目名称必须在 CNCF 中唯一
|
||||
|
||||
- 项目描述(用途、价值、起源、历史)
|
||||
|
||||
- 与 CNCF 章程一致的声明
|
||||
|
||||
- 来自 TOC 的 sponsor(项目辅导)
|
||||
|
||||
- license(默认为 Apache 2)
|
||||
|
||||
- 源码控制(Github)
|
||||
|
||||
- 网站(英文)
|
||||
|
||||
- 外部依赖(包括 license)
|
||||
|
||||
- 成熟度模型评估(参考 [CNCF Graduation Criteria](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc))
|
||||
- 创始 committer(贡献项目的时长)
|
||||
- 基础设施需求(CI/CNCF集群)
|
||||
- 沟通渠道(slack、irc、邮件列表)
|
||||
- issue 追踪(GitHub)
|
||||
- 发布方法和机制
|
||||
- 社交媒体账号
|
||||
- 社区规模和已有的赞助商
|
||||
- svg 格式的项目 logo
|
||||
|
||||
## 由 Sandbox 升级到 Incubating 的要求
|
||||
|
||||
- 通过 TOC 的[尽职调查](https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md)
|
||||
- 至少有 3 个独立的终端用户在在生产上使用该项目:一般在项目的官网列举实际用户
|
||||
- 足够健康数量的贡献者:项目的 GitHub 上有明确的 committer 权限划分、职责说明及成员列表,TOC 将根据项目大小来确认多少committer才算健康
|
||||
- **展示项目在持续进行、良好的发布节奏、贡献频率十分重要**
|
||||
|
||||
|
||||
## 由Incubating升级到Graduated的要求
|
||||
|
||||
- 满足 Sandbox 和 Incubating 的所有要求
|
||||
- **至少有来自两个组织的贡献者**
|
||||
- 明确定义的项目治理及 committer 身份、权限管理
|
||||
- 接受 CNCF 的[行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md),参考[Prometheus](https://bestpractices.coreinfrastructure.org/en/projects/486)
|
||||
- 获得CII 最佳实践徽章
|
||||
- 在项目主库或项目官网有公开的采用者的 logo
|
||||
|
||||
参考归档的 Review:https://github.com/cncf/toc/tree/master/reviews
|
||||
|
||||
## 参考
|
||||
|
||||
- [鸿沟理论 - jianshu.com](https://www.jianshu.com/p/a305fa93580b)
|
||||
- [CNCF Graduation Criteria v1.2 - github.com](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc)
|
|
@ -11,7 +11,7 @@
|
|||
## 具体目标
|
||||
|
||||
- 加强项目生态系统建设以满足最终用户和项目贡献者的需求。
|
||||
- 识别CNCF项目组合中的空白(gap),寻找并吸引项目填补这些空白。
|
||||
- 识别CNCF项目组合中的鸿沟(gap),寻找并吸引项目填补这些鸿沟。
|
||||
- 教育和指导用户,为用户提供无偏见、有效且实用的信息。
|
||||
- 将注意力和资源集中在促进CNCF项目的成熟度上。
|
||||
- 明确项目、CNCF项目人员和社区志愿者之间的关系。
|
||||
|
@ -32,7 +32,7 @@ CNCF SIG以Kubernetes SIG为模型,旨在最小化差异以避免混淆——[
|
|||
|
||||
CNCF SIG在TOC的指导下,提供高质量的专业技术知识、无偏见的信息及其领域内的领导力。TOC作为知情方和高效的执行委员会,利用这一输入来选择和推广适当的CNCF项目与实践,并向最终用户和云原生社区传播高质量的信息。可以很明确的说,SIG对CNCF项目没有直接的权力。特别是,CNCF SIG的创建并没有改变现有已成功实施的[章程](https://github.com/cncf/foundation/blob/master/charter.md)目标,即“项目......轻松地受技术监督委员会管辖”。
|
||||
|
||||
SIG应努力向TOC提供易于理解和可投票的“提议(proposition)”,提议需要有明确的书面证据支持。这些提议可以是:“基于此[书面尽职调查](https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.mdguidelines.md)“或”根据明确的目标和证据来批准这个landscape文件“。SIG提供给TOC的信息和建议必须高度准确和公正,这一点至关重要,这也是受整体上改进CNCF的目标所驱动,而不是使一个项目或公司受益于其他项目或公司。我们相信涨潮会抬升所有船只,这是我们的目标。
|
||||
SIG应努力向TOC提供易于理解和可投票的“提议(proposition)”,提议需要有明确的书面证据支持。这些提议可以是:“基于此[书面尽职调查](https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md)“或”根据明确的目标和证据来批准这个landscape文件“。SIG提供给TOC的信息和建议必须高度准确和公正,这一点至关重要,这也是受整体上改进CNCF的目标所驱动,而不是使一个项目或公司受益于其他项目或公司。我们相信涨潮会抬升所有船只,这是我们的目标。
|
||||
|
||||
之所以这样设计是考虑到:
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# CRI - Container Runtime Interface(容器运行时接口)
|
||||
|
||||
CRI中定义了**容器**和**镜像**的服务的接口,因为容器运行时与镜像的生命周期是彼此隔离的,因此需要定义两个服务。该接口使用[Protocol Buffer](https://developers.google.com/protocol-buffers/),基于[gRPC](https://grpc.io/),在Kubernetes v1.10+版本中是在[pkg/kubelet/apis/cri/runtime/v1alpha2](https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/apis/cri/runtime/v1alpha2)的`api.proto`中定义的。
|
||||
CRI中定义了**容器**和**镜像**的服务的接口,因为容器运行时与镜像的生命周期是彼此隔离的,因此需要定义两个服务。该接口使用[Protocol Buffer](https://developers.google.com/protocol-buffers/),基于[gRPC](https://grpc.io/),在Kubernetes v1.10+版本中是在`pkg/kubelet/apis/cri/runtime/v1alpha2`的`api.proto`中定义的。
|
||||
|
||||
## CRI架构
|
||||
|
||||
|
|
|
@ -33,7 +33,7 @@
|
|||
在设置以下资源之前,请检查这是否属于您组织的集群管理员的责任。
|
||||
|
||||
- **Horizontal Pod Autoscaler (HPA)** :这些资源是在CPU使用率或其他[自定义度量](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md)标准“秒杀”时自动化扩展应用程序的好方法。*[查看示例](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)*以了解如何设置HPA。
|
||||
- **联合集群对象**:如果使用 *federation* 在多个 Kubernetes 集群上运行应用程序,则需要部署标准 Kubernetes API 对象的联合版本。有关参考,请查看设置 [联合 ConfigMap](https://kubernetes.io/docs/tasks/administer-federation/configmap/) 和[联合 Deployment](https://kubernetes.io/docs/tasks/administer-federation/deployment/) 的指南。
|
||||
- **联合集群对象**:如果使用 *federation* 在多个 Kubernetes 集群上运行应用程序,则需要部署标准 Kubernetes API 对象的联合版本。
|
||||
|
||||
## 扩展 Kubernetes API
|
||||
|
||||
|
|
|
@ -288,5 +288,4 @@ rm -rf .vagrant
|
|||
- [Kubernetes handbook - jimmysong.io](https://jimmysong.io/kubernetes-handbook)
|
||||
- [duffqiu/centos-vagrant](https://github.com/duffqiu/centos-vagrant)
|
||||
- [kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)
|
||||
- [vagrant网络配置](https://blog.hedzr.com/2017/05/02/vagrant-%E7%BD%91%E7%BB%9C%E9%85%8D%E7%BD%AE/)
|
||||
- [Kubernetes 1.8 kube-proxy 开启 ipvs](https://mritd.me/2017/10/10/kube-proxy-use-ipvs-on-kubernetes-1.8/#%E4%B8%80%E7%8E%AF%E5%A2%83%E5%87%86%E5%A4%87)
|
|
@ -39,25 +39,6 @@ Kubernetes 集群 federation 可以包含运行在不同云服务提供商(例
|
|||
|
||||
为了能够联合(federate)多个集群,首先需要建立一个 federation 控制平面。请按照 [设置指南](https://kubernetes.io/docs/tutorials/federation/set-up-cluster-federation-kubefed) 设置 federation 控制平面。
|
||||
|
||||
## API 资源
|
||||
|
||||
一旦设置了控制平面,您就可以开始创建 federation API 资源。 以下指南详细介绍了一些资源:
|
||||
|
||||
- [Cluster](https://kubernetes.io/docs/tasks/administer-federation/cluster)
|
||||
- [ConfigMap](https://kubernetes.io/docs/tasks/administer-federation/configmap)
|
||||
- [DaemonSets](https://kubernetes.io/docs/tasks/administer-federation/daemonset)
|
||||
- [Deployment](https://kubernetes.io/docs/tasks/administer-federation/deployment)
|
||||
- [Events](https://kubernetes.io/docs/tasks/administer-federation/events)
|
||||
- [Hpa](https://kubernetes.io/docs/tasks/administer-federation/hpa)
|
||||
- [Ingress](https://kubernetes.io/docs/tasks/administer-federation/ingress)
|
||||
- [Jobs](https://kubernetes.io/docs/tasks/administer-federation/job)
|
||||
- [Namespaces](https://kubernetes.io/docs/tasks/administer-federation/namespaces)
|
||||
- [ReplicaSets](https://kubernetes.io/docs/tasks/administer-federation/replicaset)
|
||||
- [Secrets](https://kubernetes.io/docs/tasks/administer-federation/secret)
|
||||
- [Services](https://kubernetes.io/docs/concepts/cluster-administration/federation-service-discovery)
|
||||
|
||||
[API 参考文档](https://kubernetes.io/docs/reference/federation) 列举了 federation apiserver 支持的所有资源。
|
||||
|
||||
## 级联删除
|
||||
|
||||
Kubernetes 1.6 版本包括了对联邦资源(federated resources)级联删除的支持。通过级联删除,当您从 federation 控制平面删除一个资源时,会同时删除所有底层集群中对应的资源。
|
||||
|
|
|
@ -9,8 +9,6 @@
|
|||
|
||||
目前kubernetes的官方文档上并没有详细的手动安装的集群如何升级的参考资料,只有两篇关于kubernetes集群升级的文档。
|
||||
|
||||
- 在ubuntu上如何使用juju升级:https://kubernetes.io/docs/getting-started-guides/ubuntu/upgrades/
|
||||
|
||||
手动升级的还没有详细的方案,大多是基于管理工具部署和升级,比如juju、kubeadm、kops、kubespray等。
|
||||
|
||||
[manual upgrade/downgrade testing for Kubernetes 1.6 - google group](https://groups.google.com/forum/#!topic/kubernetes-dev/jDbGKAsfo4Q),在这个Google group中讨论了kubernetes手动升级的问题,并给出了参考建议。
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
[OpenEBS](https://github.com/openebs/openebs)是一款使用Go语言编写的基于容器的块存储开源软件。OpenEBS使得在容器中运行关键性任务和需要数据持久化的负载变得更可靠。
|
||||
|
||||
OpenEBS由[CloudByte](http://www.cloudbyte.com/)研发,这是一家专业做容器化存储的公司,OpenEBS是其一款开源产品,CloudByte将其在企业级容器存储的经验付诸到该项目中。这个项目的愿景也很简单,就是让需要持久化存储的工作负载中的存储服务能够直接集成在环境中,存储服务可以自动管理,将存储的细节隐藏起来,就像存储系统是另一套基础架构一样。
|
||||
OpenEBS由CloudByte研发,这是一家专业做容器化存储的公司,OpenEBS是其一款开源产品,CloudByte将其在企业级容器存储的经验付诸到该项目中。这个项目的愿景也很简单,就是让需要持久化存储的工作负载中的存储服务能够直接集成在环境中,存储服务可以自动管理,将存储的细节隐藏起来,就像存储系统是另一套基础架构一样。
|
||||
|
||||
我们知道AWS中提供了[EBS](https://amazonaws-china.com/cn/ebs/)(Elastic Block Storage),适用于 Amazon EC2 的持久性块存储,可以满足要求最苛刻的应用程序在功能和性能方面的要求,OpenEBS即其开源实现。
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Prometheus 查询语言 PromQL 使用说明
|
||||
|
||||
目前很多云原生应用使用了 Prometheus 作为监控,例如在 [Istio 中查询 Prometheus 指标](https://istio.io/zh/docs/tasks/telemetry/querying-metrics/)。
|
||||
目前很多云原生应用使用了 Prometheus 作为监控,例如在 Istio 中查询 Prometheus 指标。
|
||||
|
||||
Prometheus 提供了一种功能表达式语言,允许用户实时选择和汇总时间序列数据。表达式的结果可以显示为图形、表格数据或者由外部系统通过 [RESTful API](https://prometheus.io/docs/prometheus/latest/querying/api/) 消费。
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# 大数据
|
||||
|
||||
Kubernetes community中已经有了一个[Big data SIG](https://github.com/kubernetes/community/tree/master/sig-big-data),大家可以通过这个SIG了解kubernetes结合大数据的应用。
|
||||
Kubernetes community中已经有了一个Big data SIG,大家可以通过这个SIG了解kubernetes结合大数据的应用。
|
||||
|
||||
在Swarm、Mesos、kubernetes这三种流行的容器编排调度架构中,Mesos对于大数据应用支持是最好的,spark原生就是运行在mesos上的,当然也可以容器化运行在kubernetes上。当前在kubernetes上运行大数据应用主要是spark应用。
|
||||
|
||||
|
|
|
@ -287,8 +287,6 @@ SOFAMesh Github 地址:https://github.com/alipay/sofa-mesh
|
|||
## 参考文档
|
||||
|
||||
- [蚂蚁金服开源的 SOFAMesh 的通用协议扩展解析 - servicemesher.com](http://www.servicemesher.com/blog/ant-financial-sofamesh-common-protocol-extension/)
|
||||
- [在 Kubernetes 中快速开始 - istio.io](https://preliminary.istio.io/zh/docs/setup/kubernetes/quick-start/)
|
||||
- [注入 Istio sidecar - istio.io](https://preliminary.istio.io/zh/docs/setup/kubernetes/sidecar-injection/)
|
||||
- [Dubbo quick start - dubbo.incubator.apache.org](https://dubbo.incubator.apache.org/en-us/docs/user/quick-start.html)
|
||||
|
||||
- 关于SOFAMesh的更多信息请访问 http://www.sofastack.tech
|
||||
- 关于SOFAMesh的更多信息请访问 https://www.sofastack.tech
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
- 按照 [安装指南](https://istio.io/zh/docs/setup/kubernetes/) 上的步骤部署 Istio。
|
||||
- 部署 [BookInfo](https://istio.io/zh/docs/examples/bookinfo/) 示例应用程序(在 `bookinfo` namespace 下)。
|
||||
- 在 Istio 集群相同的项目下创建名为 `vm-1` 的虚拟机,并 [加入到 Mesh](https://istio.io/zh/docs/setup/kubernetes/mesh-expansion/)。
|
||||
- 在 Istio 集群相同的项目下创建名为 `vm-1` 的虚拟机,并加入到 Mesh。
|
||||
|
||||
## 在虚拟机上运行 mysql
|
||||
|
||||
|
|
|
@ -17,8 +17,6 @@ OpenFaaS的架构如下图:
|
|||
|
||||
## 部署
|
||||
|
||||
参考[Deployment guide for Kubernetes](https://github.com/openfaas/faas/blob/master/guide/deployment_k8s.md)部署OpenFaaS。
|
||||
|
||||
如果您的Kuberentes集群可以访问DockerHub那么直接使用官方提供的YAML文件即可。
|
||||
|
||||
YAML文件见官方仓库:https://github.com/openfaas/faas-netes
|
||||
|
|
|
@ -59,4 +59,4 @@ Ingress或者边缘代理可以处理进出集群的流量,为了应对集群
|
|||
|
||||
### 多集群部署和扩展
|
||||
|
||||
以上都是单个服务网格集群的架构,所有的服务都位于同一个集群中,服务网格管理进出集群和集群内部的流量,当我们需要管理多个集群或者是引入外部的服务时就需要[网格扩展](https://preliminary.istio.io/zh/docs/setup/kubernetes/mesh-expansion/)和[多集群配置](https://preliminary.istio.io/zh/docs/setup/kubernetes/multicluster-install/)。
|
||||
以上都是单个服务网格集群的架构,所有的服务都位于同一个集群中,服务网格管理进出集群和集群内部的流量,当我们需要管理多个集群或者是引入外部的服务时就需要网格扩展和多集群配置。
|
|
@ -368,8 +368,6 @@ Init 容器中使用的的 iptables 版本是 `v1.6.0`,共包含 5 张表:
|
|||
|
||||
![iptables 调用链](https://ws1.sinaimg.cn/large/0069RVTdgy1fv5dq2bptdj31110begnl.jpg)
|
||||
|
||||
关于 iptables 的详细介绍请参考[常见 iptables 使用规则场景整理](https://www.aliang.org/Linux/iptables.html)。
|
||||
|
||||
### iptables 命令
|
||||
|
||||
`iptables` 命令的主要用途是修改这些表中的规则。`iptables` 命令格式如下:
|
||||
|
@ -420,8 +418,6 @@ Chain OUTPUT (policy ACCEPT 18M packets, 1916M bytes)
|
|||
|
||||
还有一列没有表头,显示在最后,表示规则的选项,作为规则的扩展匹配条件,用来补充前面的几列中的配置。`prot`、`opt`、`in`、`out`、`source` 和 `destination` 和显示在 `destination` 后面的没有表头的一列扩展条件共同组成匹配规则。当流量匹配这些规则后就会执行 `target`。
|
||||
|
||||
关于 iptables 规则请参考[常见iptables使用规则场景整理](https://www.aliang.org/Linux/iptables.html)。
|
||||
|
||||
**target 支持的类型**
|
||||
|
||||
`target` 类型包括 ACCEPT`、REJECT`、`DROP`、`LOG` 、`SNAT`、`MASQUERADE`、`DNAT`、`REDIRECT`、`RETURN` 或者跳转到其他规则等。只要执行到某一条链中只有按照顺序有一条规则匹配后就可以确定报文的去向了,除了 `RETURN` 类型,类似编程语言中的 `return` 语句,返回到它的调用点,继续执行下一条规则。`target` 支持的配置详解请参考 [iptables 详解(1):iptables 概念](http://www.zsythink.net/archives/1199)。
|
||||
|
|
Loading…
Reference in New Issue