diff --git a/appendix/issues.md b/appendix/issues.md index 03447d8a5..74443decd 100644 --- a/appendix/issues.md +++ b/appendix/issues.md @@ -1,4 +1,4 @@ -## Kubernetes 相关问题记录 +# Kubernetes 相关问题记录 安装、使用kubernetes的过程中遇到的所有问题的记录。 diff --git a/cloud-native/cncf-ambassador.md b/cloud-native/cncf-ambassador.md index 001eaf6f5..a21ea0bc5 100644 --- a/cloud-native/cncf-ambassador.md +++ b/cloud-native/cncf-ambassador.md @@ -1,4 +1,4 @@ -## CNCF Ambassador +# CNCF Ambassador CNCF Ambassador（CNCF 大使），人员名单详见 ，笔者很荣幸作为第二位成为 CNCF Ambassador 的中国人。 diff --git a/cloud-native/cncf-project-governing.md b/cloud-native/cncf-project-governing.md index 668784df2..ca9d8a06f 100644 --- a/cloud-native/cncf-project-governing.md +++ b/cloud-native/cncf-project-governing.md @@ -1,4 +1,4 @@ -## CNCF中的项目治理 +# CNCF中的项目治理 CNCF 根据“[鸿沟理论](https://www.jianshu.com/p/a305fa93580b)”将其托管的项目分成三个成熟阶段，并设置了项目晋级到更高阶段的标准。 diff --git a/cloud-native/cncf-sandbox-criteria.md b/cloud-native/cncf-sandbox-criteria.md index 3cd97113b..a31980d21 100644 --- a/cloud-native/cncf-sandbox-criteria.md +++ b/cloud-native/cncf-sandbox-criteria.md @@ -1,4 +1,4 @@ -## 开源项目加入CNCF Sandbox的要求 +# 开源项目加入CNCF Sandbox的要求 [CNCF Project Proposal Process](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc) 中指出开源项目要想加入 CNCF 必须满足以下条件： diff --git a/concepts/configmap.md b/concepts/configmap.md index 3129dd84a..355e261c4 100644 --- a/concepts/configmap.md +++ b/concepts/configmap.md @@ -1,4 +1,4 @@ -## ConfigMap +# ConfigMap 其实 ConfigMap 功能在 Kubernetes1.2 版本的时候就有了，许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。这些配置信息需要与 docker image 解耦，你总不能每修改一个配置就重做一个 image 吧？ConfigMap API 给我们提供了向容器中注入配置信息的机制，ConfigMap 可以被用来保存单个属性，也可以用来保存整个配置文件或者 JSON 二进制大对象。 diff --git a/guide/auth-with-kubeconfig-or-token.md b/guide/auth-with-kubeconfig-or-token.md index 226bf0cd9..5ba35fa7d 100644 --- a/guide/auth-with-kubeconfig-or-token.md +++ b/guide/auth-with-kubeconfig-or-token.md @@ -1,4 +1,4 @@ -## 使用 kubeconfig 或 token 进行用户身份认证 +# 使用 kubeconfig 或 token 进行用户身份认证 在开启了 TLS 的集群中，每当与集群交互的时候少不了的是身份认证，使用 kubeconfig（即证书） 和 token 两种认证方式是最简单也最通用的认证方式，在 dashboard 的登录功能就可以使用这两种登录功能。 @@ -7,7 +7,7 @@ - 为 brand 命名空间下的 brand 用户创建 kubeconfig 文件 - 为集群的管理员（拥有所有命名空间的 amdin 权限）创建 token -### 使用 kubeconfig +## 使用 kubeconfig 如何生成`kubeconfig`文件请参考[创建用户认证授权的kubeconfig文件](../guide/kubectl-user-authentication-authorization.md)。 @@ -19,11 +19,11 @@ 对于访问 dashboard 时候的使用 kubeconfig 文件如`brand.kubeconfig` 必须追到 `token` 字段，否则认证不会通过。而使用 kubectl 命令时的用的 kubeconfig 文件则不需要包含 `token` 字段。 -### 生成 token +## 生成 token 需要创建一个admin用户并授予admin角色绑定，使用下面的yaml文件创建admin用户并赋予他管理员权限，然后可以通过token访问kubernetes，该文件见[admin-role.yaml](https://github.com/rootsongjc/kubernetes-handbook/tree/master/manifests/dashboard-1.7.1/admin-role.yaml)。 -#### 生成kubernetes集群最高权限admin用户的token +### 生成kubernetes集群最高权限admin用户的token ```yaml kind: ClusterRoleBinding @@ -96,7 +96,7 @@ kubectl -n kube-system get secret admin-token-nwphb -o jsonpath={.data.token}|ba kubectl describe secret admin-token-nwphb ``` -#### 为普通用户生成token +### 为普通用户生成token 为指定namespace分配该namespace的最高权限，这通常是在为某个用户（组织或者个人）划分了namespace之后，需要给该用户创建token登陆kubernetes dashboard或者调用kubernetes API的时候使用。 @@ -112,5 +112,5 @@ kubectl create rolebinding $ROLEBINDING_NAME --clusterrole=admin --serviceaccoun ## 参考 -- [JSONPath 手册](https://kubernetes.io/docs/user-guide/jsonpath/) -- [Kubernetes 中的认证](https://kubernetes.io/docs/admin/authentication/) +- [JSONPath 手册 - kubernetes.io](https://kubernetes.io/docs/user-guide/jsonpath/) +- [Kubernetes 中的认证 - kubernetes.io](https://kubernetes.io/docs/admin/authentication/) diff --git a/practice/distributed-load-test.md b/practice/distributed-load-test.md index 7cb643bad..f63832faf 100644 --- a/practice/distributed-load-test.md +++ b/practice/distributed-load-test.md @@ -1,4 +1,4 @@ -## 分布式负载测试 +# 分布式负载测试 该教程描述如何在 [Kubernetes](https://kubernetes.io/) 中进行分布式负载均衡测试，包括一个 web 应用、docker 镜像和 Kubernetes controllers/services。关于分布式负载测试的更多资料请查看 [Distributed Load Testing Using Kubernetes](https://cloud.google.com/solutions/distributed-load-testing-using-kubernetes) 。 diff --git a/practice/rbac-support-in-kubernetes.md b/practice/rbac-support-in-kubernetes.md index 785f43f9a..452eabb93 100644 --- a/practice/rbac-support-in-kubernetes.md +++ b/practice/rbac-support-in-kubernetes.md @@ -1,4 +1,4 @@ -## Kubernetes中的RBAC 支持 +# Kubernetes中的RBAC 支持 > 在Kubernetes1.6版本中新增角色访问控制机制（Role-Based Access，RBAC）让集群管理员可以针对特定使用者或服务账号的角色，进行更精确的资源访问控制。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。 diff --git a/usecases/before-using-istio.md b/usecases/before-using-istio.md index c75dd14b1..c5d924778 100644 --- a/usecases/before-using-istio.md +++ b/usecases/before-using-istio.md @@ -1,4 +1,4 @@ -## 使用 Istio 前需要考虑的问题 +# 使用 Istio 前需要考虑的问题 在使用 Istio 之前，请先考虑下以下因素： diff --git a/usecases/kubeedge.md b/usecases/kubeedge.md index a0e4dd133..17823105f 100644 --- a/usecases/kubeedge.md +++ b/usecases/kubeedge.md @@ -1,4 +1,4 @@ -## KubeEdge +# KubeEdge 以 Kubernetes 为基础的开源项目：[KubeEdge](https://kubeedge.io/zh/)。 diff --git a/usecases/service-mesh-adoption-and-evolution.md b/usecases/service-mesh-adoption-and-evolution.md index cc809b20f..b4263e2f4 100644 --- a/usecases/service-mesh-adoption-and-evolution.md +++ b/usecases/service-mesh-adoption-and-evolution.md @@ -1,4 +1,4 @@ -## 采纳和演进 +# 采纳和演进 没有人会一下子采纳Service Mesh架构的所有组件，或者一次性将所有的应用都改造成Service Mesh的，都是渐渐式采纳，从非核心系统开始改造。采纳Service Mesh就两种路径：