update title levels
Jimmy Song
parent
efca2855d9
commit
2b44617487
|
|
@ -1,4 +1,4 @@
|
||||||
## Kubernetes 相关问题记录
|
# Kubernetes 相关问题记录
|
||||||
|
|
||||||
安装、使用kubernetes的过程中遇到的所有问题的记录。
|
安装、使用kubernetes的过程中遇到的所有问题的记录。
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
## CNCF Ambassador
|
# CNCF Ambassador
|
||||||
|
|
||||||
CNCF Ambassador（CNCF 大使），人员名单详见 <https://www.cncf.io/people/ambassadors/>，笔者很荣幸作为第二位成为 CNCF Ambassador 的中国人。
|
CNCF Ambassador（CNCF 大使），人员名单详见 <https://www.cncf.io/people/ambassadors/>，笔者很荣幸作为第二位成为 CNCF Ambassador 的中国人。
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
## CNCF中的项目治理
|
# CNCF中的项目治理
|
||||||
|
|
||||||
CNCF 根据“[鸿沟理论](https://www.jianshu.com/p/a305fa93580b)”将其托管的项目分成三个成熟阶段，并设置了项目晋级到更高阶段的标准。
|
CNCF 根据“[鸿沟理论](https://www.jianshu.com/p/a305fa93580b)”将其托管的项目分成三个成熟阶段，并设置了项目晋级到更高阶段的标准。
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
## 开源项目加入CNCF Sandbox的要求
|
# 开源项目加入CNCF Sandbox的要求
|
||||||
|
|
||||||
[CNCF Project Proposal Process](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc) 中指出开源项目要想加入 CNCF 必须满足以下条件：
|
[CNCF Project Proposal Process](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc) 中指出开源项目要想加入 CNCF 必须满足以下条件：
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
## ConfigMap
|
# ConfigMap
|
||||||
|
|
||||||
其实 ConfigMap 功能在 Kubernetes1.2 版本的时候就有了，许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。这些配置信息需要与 docker image 解耦，你总不能每修改一个配置就重做一个 image 吧？ConfigMap API 给我们提供了向容器中注入配置信息的机制，ConfigMap 可以被用来保存单个属性，也可以用来保存整个配置文件或者 JSON 二进制大对象。
|
其实 ConfigMap 功能在 Kubernetes1.2 版本的时候就有了，许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。这些配置信息需要与 docker image 解耦，你总不能每修改一个配置就重做一个 image 吧？ConfigMap API 给我们提供了向容器中注入配置信息的机制，ConfigMap 可以被用来保存单个属性，也可以用来保存整个配置文件或者 JSON 二进制大对象。
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
## 使用 kubeconfig 或 token 进行用户身份认证
|
# 使用 kubeconfig 或 token 进行用户身份认证
|
||||||
|
|
||||||
在开启了 TLS 的集群中，每当与集群交互的时候少不了的是身份认证，使用 kubeconfig（即证书） 和 token 两种认证方式是最简单也最通用的认证方式，在 dashboard 的登录功能就可以使用这两种登录功能。
|
在开启了 TLS 的集群中，每当与集群交互的时候少不了的是身份认证，使用 kubeconfig（即证书） 和 token 两种认证方式是最简单也最通用的认证方式，在 dashboard 的登录功能就可以使用这两种登录功能。
|
||||||
|
|
||||||
|
|
@ -7,7 +7,7 @@
|
||||||
- 为 brand 命名空间下的 brand 用户创建 kubeconfig 文件
|
- 为 brand 命名空间下的 brand 用户创建 kubeconfig 文件
|
||||||
- 为集群的管理员（拥有所有命名空间的 amdin 权限）创建 token
|
- 为集群的管理员（拥有所有命名空间的 amdin 权限）创建 token
|
||||||
|
|
||||||
### 使用 kubeconfig
|
## 使用 kubeconfig
|
||||||
|
|
||||||
如何生成`kubeconfig`文件请参考[创建用户认证授权的kubeconfig文件](../guide/kubectl-user-authentication-authorization.md)。
|
如何生成`kubeconfig`文件请参考[创建用户认证授权的kubeconfig文件](../guide/kubectl-user-authentication-authorization.md)。
|
||||||
|
|
||||||
|
|
@ -19,11 +19,11 @@
|
||||||
|
|
||||||
对于访问 dashboard 时候的使用 kubeconfig 文件如`brand.kubeconfig` 必须追到 `token` 字段，否则认证不会通过。而使用 kubectl 命令时的用的 kubeconfig 文件则不需要包含 `token` 字段。
|
对于访问 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)。
|
需要创建一个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
|
```yaml
|
||||||
kind: ClusterRoleBinding
|
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
|
kubectl describe secret admin-token-nwphb
|
||||||
```
|
```
|
||||||
|
|
||||||
#### 为普通用户生成token
|
### 为普通用户生成token
|
||||||
|
|
||||||
为指定namespace分配该namespace的最高权限，这通常是在为某个用户（组织或者个人）划分了namespace之后，需要给该用户创建token登陆kubernetes dashboard或者调用kubernetes API的时候使用。
|
为指定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/)
|
- [JSONPath 手册 - kubernetes.io](https://kubernetes.io/docs/user-guide/jsonpath/)
|
||||||
- [Kubernetes 中的认证](https://kubernetes.io/docs/admin/authentication/)
|
- [Kubernetes 中的认证 - kubernetes.io](https://kubernetes.io/docs/admin/authentication/)
|
||||||
|
|
|
||||||
|
|
@ -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) 。
|
该教程描述如何在 [Kubernetes](https://kubernetes.io/) 中进行分布式负载均衡测试，包括一个 web 应用、docker 镜像和 Kubernetes controllers/services。关于分布式负载测试的更多资料请查看 [Distributed Load Testing Using Kubernetes](https://cloud.google.com/solutions/distributed-load-testing-using-kubernetes) 。
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
## Kubernetes中的RBAC 支持
|
# Kubernetes中的RBAC 支持
|
||||||
|
|
||||||
> 在Kubernetes1.6版本中新增角色访问控制机制（Role-Based Access，RBAC）让集群管理员可以针对特定使用者或服务账号的角色，进行更精确的资源访问控制。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。
|
> 在Kubernetes1.6版本中新增角色访问控制机制（Role-Based Access，RBAC）让集群管理员可以针对特定使用者或服务账号的角色，进行更精确的资源访问控制。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
## 使用 Istio 前需要考虑的问题
|
# 使用 Istio 前需要考虑的问题
|
||||||
|
|
||||||
在使用 Istio 之前，请先考虑下以下因素：
|
在使用 Istio 之前，请先考虑下以下因素：
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
## KubeEdge
|
# KubeEdge
|
||||||
|
|
||||||
以 Kubernetes 为基础的开源项目：[KubeEdge](https://kubeedge.io/zh/)。
|
以 Kubernetes 为基础的开源项目：[KubeEdge](https://kubeedge.io/zh/)。
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
## 采纳和演进
|
# 采纳和演进
|
||||||
|
|
||||||
没有人会一下子采纳Service Mesh架构的所有组件，或者一次性将所有的应用都改造成Service Mesh的，都是渐渐式采纳，从非核心系统开始改造。采纳Service Mesh就两种路径：
|
没有人会一下子采纳Service Mesh架构的所有组件，或者一次性将所有的应用都改造成Service Mesh的，都是渐渐式采纳，从非核心系统开始改造。采纳Service Mesh就两种路径：
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue