From cae9cc34d8caa89c7bda2ac1a8116692630ace70 Mon Sep 17 00:00:00 2001 From: Jimmy Song Date: Fri, 25 Dec 2020 20:55:28 +0800 Subject: [PATCH] remove broken links --- appendix/cncf-annual-report-2018.md | 6 +++--- appendix/cncf-annual-report.md | 2 +- appendix/kubernetes-1.7-changelog.md | 2 +- cloud-native/cncf-charter.md | 3 +-- cloud-native/component.md | 2 +- concepts/calico.md | 1 - concepts/crd.md | 2 +- concepts/horizontal-pod-autoscaling.md | 4 ++-- concepts/ingress.md | 2 +- concepts/pod-disruption-budget.md | 2 +- concepts/volume.md | 2 +- develop/advance-developer.md | 2 +- practice/configuration-best-practice.md | 2 +- practice/configuring-dns.md | 2 +- practice/service-rolling-update.md | 2 -- usecases/istio-community-tips.md | 2 +- 16 files changed, 17 insertions(+), 21 deletions(-) diff --git a/appendix/cncf-annual-report-2018.md b/appendix/cncf-annual-report-2018.md index 4e33eca1e..d08ba6769 100644 --- a/appendix/cncf-annual-report-2018.md +++ b/appendix/cncf-annual-report-2018.md @@ -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) diff --git a/appendix/cncf-annual-report.md b/appendix/cncf-annual-report.md index eaf1c7ef8..0dec84c7f 100644 --- a/appendix/cncf-annual-report.md +++ b/appendix/cncf-annual-report.md @@ -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) diff --git a/appendix/kubernetes-1.7-changelog.md b/appendix/kubernetes-1.7-changelog.md index a631d6cd8..7ffde2df5 100644 --- a/appendix/kubernetes-1.7-changelog.md +++ b/appendix/kubernetes-1.7-changelog.md @@ -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）集群提供布局策略。 **弃用** diff --git a/cloud-native/cncf-charter.md b/cloud-native/cncf-charter.md index b6f806df7..aa7bc1bd4 100644 --- a/cloud-native/cncf-charter.md +++ b/cloud-native/cncf-charter.md @@ -2,7 +2,7 @@ CNCF（云原生计算基金会）是 Linux 基金会旗下的一个基金会，加入 CNCF 等于同时加入 Linux 基金会（也意味着你还要交 Linux 基金会的份子钱），对于想加入 CNCF 基金会的企业或者组织首先要做的事情就是要了解 CNCF 的章程（charter），就像是作为一个国家的公民，必须遵守该国家的宪法一样。CNCF 之所以能在短短三年的时间内发展壮大到如此规模，很大程度上是与它出色的社区治理和运作模式有关。了解该章程可以帮助我们理解 CNCF 是如何运作的，当我们自己进行开源项目治理时也可以派上用场。 -该章程最后更新于 2018 年 5 月 15 日，详见 。下文中关于 CNCF 章程的介绍部分引用自 [CNCF 是如何工作的](http://www.ocselected.org/posts/foundation_introduce/how_cncf_works/)，有改动。 +该章程最后更新于 2018 年 5 月 15 日，详见 。下文中关于 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/ diff --git a/cloud-native/component.md b/cloud-native/component.md index ee58a8cf9..53c069238 100644 --- a/cloud-native/component.md +++ b/cloud-native/component.md @@ -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` 发布。 diff --git a/concepts/calico.md b/concepts/calico.md index c6c0973d7..4ab7e8100 100644 --- a/concepts/calico.md +++ b/concepts/calico.md @@ -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/) diff --git a/concepts/crd.md b/concepts/crd.md index d6ceaf995..3a91ec724 100644 --- a/concepts/crd.md +++ b/concepts/crd.md @@ -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/)。 ## 高级主题 diff --git a/concepts/horizontal-pod-autoscaling.md b/concepts/horizontal-pod-autoscaling.md index 3ce49f697..3ce0e0eb4 100644 --- a/concepts/horizontal-pod-autoscaling.md +++ b/concepts/horizontal-pod-autoscaling.md @@ -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 的大小。 diff --git a/concepts/ingress.md b/concepts/ingress.md index 71ed3a45c..ca088b4e2 100644 --- a/concepts/ingress.md +++ b/concepts/ingress.md @@ -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/)。 diff --git a/concepts/pod-disruption-budget.md b/concepts/pod-disruption-budget.md index 79dfce9a3..c929c1b37 100644 --- a/concepts/pod-disruption-budget.md +++ b/concepts/pod-disruption-budget.md @@ -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 使用该节点。 这些操作可能由集群管理员直接执行，也可能由集群管理员或集群托管提供商自动执行。 diff --git a/concepts/volume.md b/concepts/volume.md index 116f41b76..5fdce67d2 100644 --- a/concepts/volume.md +++ b/concepts/volume.md @@ -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。 diff --git a/develop/advance-developer.md b/develop/advance-developer.md index e7daa12a6..15cd06c86 100644 --- a/develop/advance-developer.md +++ b/develop/advance-developer.md @@ -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 对象 diff --git a/practice/configuration-best-practice.md b/practice/configuration-best-practice.md index 87579418b..5fb1bf8de 100644 --- a/practice/configuration-best-practice.md +++ b/practice/configuration-best-practice.md @@ -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)。 diff --git a/practice/configuring-dns.md b/practice/configuring-dns.md index d87c74d44..1d07883e1 100644 --- a/practice/configuring-dns.md +++ b/practice/configuring-dns.md @@ -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 集群）。 ## 参考 diff --git a/practice/service-rolling-update.md b/practice/service-rolling-update.md index 174e297fa..c1c24de4a 100644 --- a/practice/service-rolling-update.md +++ b/practice/service-rolling-update.md @@ -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)中的部分内容如下，详细区别请查看原文。 diff --git a/usecases/istio-community-tips.md b/usecases/istio-community-tips.md index a22f71cc2..0d396a308 100644 --- a/usecases/istio-community-tips.md +++ b/usecases/istio-community-tips.md @@ -72,4 +72,4 @@ Istio 的 feature 分为四大类： - 安全性：各种 checker 和安全性配置 - Core：核心功能 -功能划分与各种功能的状态详情请见： +功能划分与各种功能的状态详情请见：