rootsongjc
/
kubernetes-handbook
mirror of https://github.com/rootsongjc/kubernetes-handbook.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
appendix/cncf-annual-report-2018.md
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)

2
appendix/cncf-annual-report.md
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)

2
appendix/kubernetes-1.7-changelog.md
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）集群提供布局策略。
**弃用**

3
cloud-native/cncf-charter.md
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/

2
cloud-native/component.md
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` 发布。

1
concepts/calico.md
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/)

2
concepts/crd.md
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/)。
## 高级主题

4
concepts/horizontal-pod-autoscaling.md
View File

@ -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 的大小。

2
concepts/ingress.md
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([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/)。

2
concepts/pod-disruption-budget.md
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 使用该节点。
这些操作可能由集群管理员直接执行，也可能由集群管理员或集群托管提供商自动执行。

2
concepts/volume.md
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。

2
develop/advance-developer.md
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 对象

2
practice/configuration-best-practice.md
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)。

2
practice/configuring-dns.md
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 集群）。
## 参考

2
practice/service-rolling-update.md
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)中的部分内容如下，详细区别请查看原文。

2
usecases/istio-community-tips.md
View File

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