remove broken links
parent
114746855e
commit
cae9cc34d8
|
@ -6,7 +6,7 @@
|
|||
|
||||
## CNCF 年度报告涵盖的范围
|
||||
|
||||
在解读 CNCF 的2018年度报告之前,我们先简单回顾下[2017年度的报告](https://www.cncf.io/wp-content/uploads/2018/03/CNCF-Annual-Report-2017.pdf),因为2017年度报告是 CNCF 的首份年度报告,这样我们也能更好的了解 CNCF 的来龙去脉。
|
||||
在解读 CNCF 的2018年度报告之前,我们先简单回顾下2017年度的报告,因为2017年度报告是 CNCF 的首份年度报告,这样我们也能更好的了解 CNCF 的来龙去脉。
|
||||
|
||||
2017年度报告已经基本确定了 CNCF 每个年度报告所包含的主题:
|
||||
|
||||
|
@ -51,7 +51,7 @@ CNCF(云原生计算基金会)成立于2015年12月11日,每届年度报
|
|||
|
||||
### CNCF 的2017年度定位
|
||||
|
||||
[2017年度报告](https://www.cncf.io/wp-content/uploads/2018/03/CNCF-Annual-Report-2017.pdf)中是这样正式介绍自己的:
|
||||
2017年度报告中是这样正式介绍自己的:
|
||||
|
||||
The Cloud Native Computing Foundation (CNCF) is an open source software foundation dedicated to making cloud-native computing universal and sustainable. Cloud-native computing uses an **open source** software stack to deploy applications as **microservices**, packaging each part into its own **container**, and **dynamically orchestrating** those containers to optimize resource utilization. Cloud-native technologies enable software developers to build great products faster.
|
||||
|
||||
|
@ -180,7 +180,7 @@ CNCF 在2019年的战略将更聚焦于开发者社区,协助尤其是来自
|
|||
|
||||
## 参考
|
||||
|
||||
- [CNCF Annual Report 2017 pdf](https://www.cncf.io/wp-content/uploads/2018/03/CNCF-Annual-Report-2017.pdf)
|
||||
- CNCF Annual Report 2017 pdf
|
||||
- [CNCF Annual Report 2018 pdf](https://www.cncf.io/wp-content/uploads/2019/02/CNCF_Annual_Report_2018_FInal.pdf)
|
||||
- [CNCF Projects](https://www.cncf.io/projects/)
|
||||
- [CNCF Landscape](https://landscape.cncf.io)
|
||||
|
|
|
@ -4,6 +4,6 @@ CNCF成立于2015年12月11日,自2018年开始每年年初都会发布一次
|
|||
|
||||
## 参考
|
||||
|
||||
- [CNCF Annual Report 2017 pdf](https://www.cncf.io/wp-content/uploads/2018/03/CNCF-Annual-Report-2017.pdf)
|
||||
- CNCF Annual Report 2017 pdf
|
||||
- [CNCF Annual Report 2018 pdf](https://www.cncf.io/wp-content/uploads/2019/02/CNCF_Annual_Report_2018_FInal.pdf)
|
||||
- [CNCF Annual Report 2019 pdf](https://www.cncf.io/wp-content/uploads/2020/02/CNCF-Annual-Report-2019.pdf)
|
||||
|
|
|
@ -34,7 +34,7 @@
|
|||
**其它功能**
|
||||
|
||||
- 引入了对[外部准入控制器](https://kubernetes.io/docs/admin/extensible-admission-controllers/)的Alpha支持,提供了两个选项,用于向API server添加自定义业务逻辑,以便在创建对象和验证策略时对其进行修改。
|
||||
- [基于策略的联合资源布局](https://kubernetes.io/docs/tasks/federation/set-up-placement-policies-federation/)提供Alpha版本,用于根据自定义需求(如法规、定价或性能)为联合(federated)集群提供布局策略。
|
||||
- 基于策略的联合资源布局提供Alpha版本,用于根据自定义需求(如法规、定价或性能)为联合(federated)集群提供布局策略。
|
||||
|
||||
**弃用**
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
CNCF(云原生计算基金会)是 Linux 基金会旗下的一个基金会,加入 CNCF 等于同时加入 Linux 基金会(也意味着你还要交 Linux 基金会的份子钱),对于想加入 CNCF 基金会的企业或者组织首先要做的事情就是要了解 CNCF 的章程(charter),就像是作为一个国家的公民,必须遵守该国家的宪法一样。CNCF 之所以能在短短三年的时间内发展壮大到如此规模,很大程度上是与它出色的社区治理和运作模式有关。了解该章程可以帮助我们理解 CNCF 是如何运作的,当我们自己进行开源项目治理时也可以派上用场。
|
||||
|
||||
该章程最后更新于 2018 年 5 月 15 日,详见 <https://www.cncf.io/about/charter/>。下文中关于 CNCF 章程的介绍部分引用自 [CNCF 是如何工作的](http://www.ocselected.org/posts/foundation_introduce/how_cncf_works/),有改动。
|
||||
该章程最后更新于 2018 年 5 月 15 日,详见 <https://www.cncf.io/about/charter/>。下文中关于 CNCF 章程的介绍部分引用自 CNCF 是如何工作的,有改动。
|
||||
|
||||
下图是我根据 CNCF 章程绘制的组织架构图。
|
||||
|
||||
|
@ -347,5 +347,4 @@ CNCF 社区坚信云原生计算包含三个核心属性:
|
|||
|
||||
## 参考
|
||||
|
||||
- [CNCF 是如何工作的](http://www.ocselected.org/posts/foundation_introduce/how_cncf_works/)
|
||||
- https://www.cncf.io/about/charter/
|
||||
|
|
|
@ -30,7 +30,7 @@ spec:
|
|||
`Component` 定义由以下几个部分组成:
|
||||
|
||||
- `metadata`:关于 Component 的信息,主要是针对应用运维的信息。
|
||||
- `workload`:该 Component 的实际工作负载。具体有哪些负载类型可用可以咨询平台提供商,平台运维也可以根据 [Workload 规范](https://github.com/oam-dev/spec/blob/master/3.workload.md) 来扩展负载类型,比如 `Containers`、`Functions`、`VirtualMachine`、[`VirtualService `](https://istio.io/docs/reference/config/networking/virtual-service/) 等。OAM 目前定义的核心负载类型有 [ContainerizedWorkload](https://github.com/oam-dev/spec/blob/master/core/workloads/containerized_workload/containerized_workload.md)(与 Kubernetes 中的 [Pod 定义](https://kubernetes.io/zh/docs/concepts/workloads/pods/pod/)类似,同样支持定义多个容器,但是缺少了 Pod 中的一些属性 )。
|
||||
- `workload`:该 Component 的实际工作负载。具体有哪些负载类型可用可以咨询平台提供商,平台运维也可以根据 [Workload 规范](https://github.com/oam-dev/spec/blob/master/3.workload.md) 来扩展负载类型,比如 `Containers`、`Functions`、`VirtualMachine`、[`VirtualService `](https://istio.io/docs/reference/config/networking/virtual-service/) 等。OAM 目前定义的核心负载类型有 [ContainerizedWorkload](https://github.com/oam-dev/spec/blob/master/core/workloads/containerized_workload/containerized_workload.md)(与 Kubernetes 中的 Pod 定义类似,同样支持定义多个容器,但是缺少了 Pod 中的一些属性 )。
|
||||
- `parameters`:在应用程序运行时可以调整的参数,即应用开发者在 `Component` 中的原有定义可以在运行时被应用运维人员覆盖。`parameters` 使用 [JSONPath](https://kubernetes.io/zh/docs/reference/kubectl/jsonpath/) 的方式引用 `spec` 中的字段。
|
||||
|
||||
> `Component` 的配置在应用后是**可更改的(Mutable)**, 有的 [`Trait`](trait.md) 可能会监听 `Component` 的变更并作出相应的操作,每次变更都会导致新的 `ApplicationConfiguration` 发布。
|
||||
|
|
|
@ -55,6 +55,5 @@ calicoctl get node
|
|||
|
||||
## 参考
|
||||
|
||||
- [安装Calico - docs.projectcalico.org](https://docs.projectcalico.org/v3.4/usage/calicoctl/install)
|
||||
- [calicoctl命令参考 - docs.projectcalico.org](https://docs.projectcalico.org/v3.4/reference/calicoctl/commands/)
|
||||
- [Calico架构 - docs.projectcalico.org](https://docs.projectcalico.org/v3.4/reference/architecture/)
|
||||
|
|
|
@ -154,7 +154,7 @@ Error from server (NotFound): Unable to list "crontabs": the server could not fi
|
|||
|
||||
## 提供 CRD 的多个版本
|
||||
|
||||
有关提供 CustomResourceDefinition 的多个版本以及将对象从一个版本迁移到另一个[版本](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/)的详细信息,请参阅[自定义资源定义版本控制](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/)。
|
||||
有关提供 CustomResourceDefinition 的多个版本以及将对象从一个版本迁移到另一个版本的详细信息,请参阅[自定义资源定义版本控制](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/)。
|
||||
|
||||
## 高级主题
|
||||
|
||||
|
|
|
@ -9,7 +9,7 @@ HPA属于Kubernetes中的**autoscaling** SIG(Special Interest Group),其
|
|||
|
||||
Kubernetes自1.2版本引入HPA机制,到1.6版本之前一直是通过kubelet来获取监控指标来判断是否需要扩缩容,1.6版本之后必须通过API server、Heapseter或者kube-aggregator来获取监控指标。
|
||||
|
||||
对于1.6以前版本中开启自定义HPA请参考[Kubernetes autoscaling based on custom metrics without using a host port](https://medium.com/@marko.luksa/kubernetes-autoscaling-based-on-custom-metrics-without-using-a-host-port-b783ed6241ac),对于1.7及以上版本请参考[Configure Kubernetes Autoscaling With Custom Metrics in Kubernetes 1.7 - Bitnami](https://docs.bitnami.com/kubernetes/how-to/configure-autoscaling-custom-metrics/)。
|
||||
对于1.6以前版本中开启自定义HPA请参考[Kubernetes autoscaling based on custom metrics without using a host port](https://medium.com/@marko.luksa/kubernetes-autoscaling-based-on-custom-metrics-without-using-a-host-port-b783ed6241ac)。
|
||||
|
||||
## HPA解析
|
||||
|
||||
|
@ -112,7 +112,7 @@ Horizontal Pod Autoscaler 和其他的所有 API 资源一样,通过 `kubectl`
|
|||
|
||||
## 滚动更新期间的自动扩缩容
|
||||
|
||||
目前在Kubernetes中,可以通过直接管理 replication controller 或使用 deployment 对象来执行 [滚动更新](https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller),该 deployment 对象为您管理基础 replication controller。
|
||||
目前在Kubernetes中,可以通过直接管理 replication controller 或使用 deployment 对象来执行 滚动更新,该 deployment 对象为您管理基础 replication controller。
|
||||
|
||||
Horizontal Pod Autoscaler 仅支持后一种方法:Horizontal Pod Autoscaler 被绑定到 deployment 对象,它设置 deployment 对象的大小,deployment 负责设置底层 replication controller 的大小。
|
||||
|
||||
|
|
|
@ -82,7 +82,7 @@ GCE/GKE会在master节点上部署一个ingress controller。你可以在一个p
|
|||
- kubernetes当前支持并维护[GCE](https://git.k8s.io/ingress-gce/README.md)和[nginx](https://git.k8s.io/ingress-nginx/README.md)两种controller.
|
||||
- F5(公司)[支持并维护](https://support.f5.com/csp/article/K86859508) [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
|
||||
- [Kong](https://konghq.com/) 同时支持并维护[社区版](https://discuss.konghq.com/c/kubernetes)与[企业版](https://konghq.com/api-customer-success/)的 [Kong Ingress Controller for Kubernetes](https://konghq.com/blog/kubernetes-ingress-controller-for-kong/).
|
||||
- [Traefik](https://github.com/containous/traefik) 是功能齐全的 ingress controller([Let’s Encrypt](https://letsencrypt.org/), secrets, http2, websocket…), [Containous](https://containo.us/services) 也对其提供商业支持。
|
||||
- [Traefik](https://github.com/containous/traefik) 是功能齐全的 ingress controller([Let’s Encrypt](https://letsencrypt.org/), secrets, http2, websocket…), Containous 也对其提供商业支持。
|
||||
- [Istio](https://istio.io) 使用CRD Gateway来[控制Ingress流量](https://istio.io/docs/tasks/traffic-management/ingress/)。
|
||||
|
||||
|
||||
|
|
|
@ -26,7 +26,7 @@ Pod 不会消失,直到有人(人类或控制器)将其销毁,或者当
|
|||
集群管理员操作包括:
|
||||
|
||||
- [排空(drain)节点](https://kubernetes.io/docs//tasks/administer-cluster/safely-drain-node)进行修复或升级。
|
||||
- 从集群中排空节点以缩小集群(了解[集群自动调节](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler))。
|
||||
- 从集群中排空节点以缩小集群。
|
||||
- 从节点中移除一个 pod,以允许其他 pod 使用该节点。
|
||||
|
||||
这些操作可能由集群管理员直接执行,也可能由集群管理员或集群托管提供商自动执行。
|
||||
|
|
|
@ -504,7 +504,7 @@ spec:
|
|||
|
||||
### rbd
|
||||
|
||||
`rbd` 卷允许将 [Rados Block Device](http://ceph.com/docs/master/rbd/rbd/) 卷挂载到容器中。不像 `emptyDir`,删除 Pod 时 `rbd `卷的内容被保留,卷仅仅被卸载。这意味着 RBD 卷可以预先填充数据,并且可以在 pod 之间“切换”数据。
|
||||
`rbd` 卷允许将 Rados Block Device 卷挂载到容器中。不像 `emptyDir`,删除 Pod 时 `rbd `卷的内容被保留,卷仅仅被卸载。这意味着 RBD 卷可以预先填充数据,并且可以在 pod 之间“切换”数据。
|
||||
|
||||
**重要提示**:您必须先自行安装 Ceph,然后才能使用 RBD。
|
||||
|
||||
|
|
|
@ -24,7 +24,7 @@
|
|||
|
||||
- Taint(污点)和 Toleration(容忍):这些为节点“吸引”或“排斥” Pod 提供了一种方法。当需要将应用程序部署到特定硬件(例如用于科学计算的 GPU)时,经常使用它们。[阅读更多](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)。
|
||||
- **向下 API**:这允许您的容器使用有关自己或集群的信息,而不会过度耦合到 Kubernetes API server。这可以通过[环境变量](https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) 或者 [DownwardAPIVolumeFiles](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。
|
||||
- **Pod 预设**:通常,要将运行时需求(例如环境变量、ConfigMap 和 Secret)安装到资源中,可以在资源的配置文件中指定它们。*[PodPresets](https://kubernetes.io/docs/concepts/workloads/pods/podpreset/)允许您在创建资源时动态注入这些需求。例如,这允许团队 A 将任意数量的新Secret 安装到团队 B 和 C 创建的资源中,而不需要 B 和 C 的操作。[请参阅示例](https://kubernetes.io/docs/tasks/inject-data-application/podpreset/)*。
|
||||
- **Pod 预设**:通常,要将运行时需求(例如环境变量、ConfigMap 和 Secret)安装到资源中,可以在资源的配置文件中指定它们。PodPresets 允许您在创建资源时动态注入这些需求。例如,这允许团队 A 将任意数量的新Secret 安装到团队 B 和 C 创建的资源中,而不需要 B 和 C 的操作。[请参阅示例](https://kubernetes.io/docs/tasks/inject-data-application/podpreset/)。
|
||||
|
||||
#### 其他 API 对象
|
||||
|
||||
|
|
|
@ -20,7 +20,7 @@
|
|||
## Services
|
||||
|
||||
- 通常最好在创建相关的[replication controllers](https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/)之前先创建[service](https://kubernetes.io/docs/concepts/services-networking/service/) ,你也可以在创建Replication Controller的时候不指定replica数量(默认是1),创建service后,在通过Replication Controller来扩容。这样可以在扩容很多个replica之前先确认pod是正常的。
|
||||
- 除非十分必要的情况下(如运行一个node daemon),不要使用`hostPort`(用来指定暴露在主机上的端口号)。当你给Pod绑定了一个`hostPort`,该pod可被调度到的主机的受限了,因为端口冲突。如果是为了调试目的来通过端口访问的话,你可以使用 [kubectl proxy and apiserver proxy](https://kubernetes.io/docs/tasks/access-kubernetes-api/http-proxy-access-api/) 或者 [kubectl port-forward](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。你可使用 [Service](https://kubernetes.io/docs/concepts/services-networking/service/) 来对外暴露服务。如果你确实需要将pod的端口暴露到主机上,考虑使用 [NodePort](https://kubernetes.io/docs/user-guide/services/#type-nodeport) service。
|
||||
- 除非十分必要的情况下(如运行一个node daemon),不要使用`hostPort`(用来指定暴露在主机上的端口号)。当你给Pod绑定了一个`hostPort`,该pod可被调度到的主机的受限了,因为端口冲突。如果是为了调试目的来通过端口访问的话,你可以使用 kubectl proxy 和 apiserver proxy 或者 [kubectl port-forward](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。你可使用 [Service](https://kubernetes.io/docs/concepts/services-networking/service/) 来对外暴露服务。如果你确实需要将pod的端口暴露到主机上,考虑使用 [NodePort](https://kubernetes.io/docs/user-guide/services/#type-nodeport) service。
|
||||
- 跟`hostPort`一样的原因,避免使用 `hostNetwork`。
|
||||
- 如果你不需要kube-proxy的负载均衡的话,可以考虑使用使用[headless services](https://kubernetes.io/docs/user-guide/services/#headless-services)。
|
||||
|
||||
|
|
|
@ -322,7 +322,7 @@ Linux 的 libc 不可思议的卡住([查看该2005年起暴出来的bug](http
|
|||
|
||||
## Kubernetes 集群联邦(多可用区支持)
|
||||
|
||||
Kubernetes 1.3 版本起引入了支持多站点 Kubernetes 安装的集群联邦支持。这需要对 Kubernetes 集群 DNS 服务器处理 DNS 查询的方式进行一些小的(向后兼容的)更改,以便于查找联邦服务(跨多个 Kubernetes 集群)。有关集群联邦和多站点支持的更多详细信息,请参阅[集群联邦管理员指南](https://kubernetes.io/docs/concepts/cluster-administration/federation/)。
|
||||
Kubernetes 1.3 版本起引入了支持多站点 Kubernetes 安装的集群联邦支持。这需要对 Kubernetes 集群 DNS 服务器处理 DNS 查询的方式进行一些小的(向后兼容的)更改,以便于查找联邦服务(跨多个 Kubernetes 集群)。
|
||||
|
||||
## 参考
|
||||
|
||||
|
|
|
@ -8,8 +8,6 @@ Deployment已经内置了RollingUpdate strategy,因此不用再调用`kubectl
|
|||
|
||||
Rolling Update适用于`Deployment`、`Replication Controller`,官方推荐使用Deployment而不再使用Replication Controller。
|
||||
|
||||
使用ReplicationController时的滚动升级请参考官网说明:https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/
|
||||
|
||||
## ReplicationController与Deployment的关系
|
||||
|
||||
ReplicationController和Deployment的RollingUpdate命令有些不同,但是实现的机制是一样的,关于这两个kind的关系我引用了[ReplicationController与Deployment的区别](https://segmentfault.com/a/1190000008232770)中的部分内容如下,详细区别请查看原文。
|
||||
|
|
|
@ -72,4 +72,4 @@ Istio 的 feature 分为四大类:
|
|||
- 安全性:各种 checker 和安全性配置
|
||||
- Core:核心功能
|
||||
|
||||
功能划分与各种功能的状态详情请见:<https://istio.io/about/feature-stages.html>
|
||||
功能划分与各种功能的状态详情请见:<https://istio.io/latest/about/feature-stages/>
|
||||
|
|
Loading…
Reference in New Issue