remove broken links

pull/430/head
Jimmy Song 2020-12-25 20:55:28 +08:00
parent 114746855e
commit cae9cc34d8
16 changed files with 17 additions and 21 deletions

View File

@ -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)

View File

@ -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)

View File

@ -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集群提供布局策略。
**弃用**

View File

@ -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/

View File

@ -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` 发布。

View File

@ -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/)

View File

@ -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/)。
## 高级主题

View File

@ -9,7 +9,7 @@ HPA属于Kubernetes中的**autoscaling** SIGSpecial 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 的大小。

View File

@ -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([Lets Encrypt](https://letsencrypt.org/), secrets, http2, websocket…), [Containous](https://containo.us/services) 也对其提供商业支持。
- [Traefik](https://github.com/containous/traefik) 是功能齐全的 ingress controller[Lets Encrypt](https://letsencrypt.org/), secrets, http2, websocket…, Containous 也对其提供商业支持。
- [Istio](https://istio.io) 使用CRD Gateway来[控制Ingress流量](https://istio.io/docs/tasks/traffic-management/ingress/)。

View File

@ -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 使用该节点。
这些操作可能由集群管理员直接执行,也可能由集群管理员或集群托管提供商自动执行。

View File

@ -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。

View File

@ -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 对象

View File

@ -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)。

View File

@ -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 集群)。
## 参考

View File

@ -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)中的部分内容如下,详细区别请查看原文。

View File

@ -72,4 +72,4 @@ Istio 的 feature 分为四大类:
- 安全性:各种 checker 和安全性配置
- Core核心功能
功能划分与各种功能的状态详情请见:<https://istio.io/about/feature-stages.html>
功能划分与各种功能的状态详情请见:<https://istio.io/latest/about/feature-stages/>