Github：https://github.com/kubernetes/dashboard
参考Kubernetes-dashboard文档，README里面Get Start部分： 使用如下命令下载下配置文件：
wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.4/aio/deploy/recommended.yaml使用如下命令，为k8s创建Kubernetes-dashboard
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.4/aio/deploy/recommended.yaml事实上就是对上面下载下的文件调用kubectl apply -f <文件名>命令。进行到这一步，其实你的kubernetes-dashboard已经安装好了，只是你无法看到界面罢了。
如果你是本地测试，可以按照Kubernetes-dashboard的README如下步骤测试一下：
但是如果你想要将kubernetes-dashboard暴露到外网，则需要修改Kubernetes-dashboard的证书并整合Ingress。
修改Kubernetes-dashboard的证书。继续查看文档，可以看到这部分： 即该链接。进入该页面可以查看到下面这部分文档： 这部分文档告诉我们，如果需要集成自己的证书，需要执行如下两部操作：
使用自己的证书在k8s中创建一个secret，你可以采用文档中的方式，或者采用如下方式： kubectl create secret tls kubernetes-dashboard-certs --key=XXX.key --cert=XXX.pem(或者是xxx.crt)这条命令不需要死记，由于k8s的API都是restful风格，这里是操作secret，因此前半段是很简单的，如果后半段忘记了很简单，可以利用--help嘛：
# kubectl create secret --help Create a secret using specified subcommand. Available Commands: docker-registry Create a secret for use with a Docker registry generic Create a secret from a local file, directory or literal value tls Create a TLS secret Usage: kubectl create secret [flags] [options] Use "kubectl <command> --help" for more information about a given command. Use "kubectl options" for a list of global command-line options (applies to all commands).这里就可以知道是使用tls命令了，后面如果忘记了则继续使用--help：
# kubectl create secret tls <name> --help Create a TLS secret from the given public/private key pair. The public/private key pair must exist before hand. The public key certificate must be .PEM encoded and match the given private key. Examples: # Create a new TLS secret named tls-secret with the given key pair: kubectl create secret tls tls-secret --cert=path/to/tls.cert --key=path/to/tls.key Options: --allow-missing-template-keys=true: If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. --append-hash=false: Append a hash of the secret to its name. --cert='': Path to PEM encoded public key certificate. --dry-run='none': Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. --key='': Path to private key associated with given certificate. -o, --output='': Output format. One of: json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-file. --save-config=false: If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. --template='': Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview]. --validate=true: If true, use a schema to validate the input before sending it Usage: kubectl create secret tls NAME --cert=path/to/cert/file --key=path/to/key/file [--dry-run=server|client|none] [options] Use "kubectl options" for a list of global command-line options (applies to all commands).到这里就可以知道使用的是--key和--cert参数了吧。
注意，此处生成的secret必须要在kubernetes-dashboard命名空间中，因为k8s的资源是通过命名空间隔离的，如果不采用特殊方式，两个命名空间是无法互相访问的。而且secret的名字务必是kubernetes-dashboard-certs，否则在安装完成后，证书仍然会是不受信任的，具体为什么现在还不清楚，感兴趣的读者可以试一下。
将创建好的证书配置到kubernetes-dashboard中。此时需要执行如下命令： kubectl edit deployments kubernetes-dashboard -n kubernetes-dashboard该命令可以修改当前配置并进行应用。查找到容器启动参数，然后加入如下几个参数即可：
containers: - args: - --tls-cert-file=/tls.crt - --tls-key-file=/tls.key至此，kubernetes-dashboard的证书配置完毕了，之后，我们需要配置Ingress，将kubernetes-dashboard暴露到外网。
配置Ingress。参考如下配置文件：
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: # ingress名称 name: ingress-name annotations: # 注意，以下的注解都需要配置,详情请考察https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/ kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/ssl-redirect: "true" nginx.ingress.kubernetes.io/rewrite-target: / nginx.ingress.kubernetes.io/secure-backends: "true" nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" nginx.ingress.kubernetes.io/use-regex: "true" namespace: kubernetes-dashboard spec: tls: # 域名 - hosts: - xxxx.xxxx.com secretName: kubernetes-dashboard-certs rules: # 域名 - host: xxxx.xxxx.com http: paths: - path: / backend: serviceName: kubernetes-dashboard servicePort: 443然后通过kubectl apply -f应用上你的配置文件，k8s相关的配置就完成了，此时你需要将域名解析到你的IngressCrontoller所对应的IP上，就可以正常访问k8s-dashboard了。
截止到这里，kubernetes-dashboard虽然搭建完成了，但是需要token才可以登录使用，那么接下来让我们创建token，以便我们可以登录到k8s-dashboard中。
这里需要简单介绍一下K8s的RBAC（Role-Based Access Control，基于角色的控制访问），从名字就可以看出，RBAC最起码应该包含两部分：
角色用户在RBAC授权模式中，角色分为两类，一类是Role，另一类是ClusterRole，两者的区别是，前者属于某个特定的命名空间，它的作用范围也只是该命名空间，而后者则不属于特定命名空间，它的作用范围是整个集群。
先给出一个Role的声明：
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default name: pod-viewer rules: - apiGroups: [""] resources: ["pods", "deployments", "services"] verbs: ["get", "list", "watch"]上面的Role规定，拥有该角色的人，在default命名空间中，对pod、deployments、service拥有get、list、watch权限。
接下来给出一个ClusterRole的声明：
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: developer rules: - apiGroups: - '*' resources: - '*' verbs: ["get", "list", "watch"]可以看到ClusterRole并不要求namespace，拥有该ClusterRole角色的人，对于K8s集群中的任何资源都有get、list、watch权限。
说完了Role，接下来介绍用户，在RBAC中用户也有两类：
User：k8s运维人员、开发人员等人使用的token，业务性更强ServiceAccount：k8s Service使用的token两者还有一个最大的区别，就是k8s不会为前者生成token，但是会为后者生成。具体原因是因为，K8s的API Server可能会被pod中的服务访问，而这种访问是以Service进行访问的，为保证安全，才创造了ServiceAccount。这里我们主要讨论ServiceAccount的创建，因为User没有Token。
apiVersion: v1 kind: ServiceAccount metadata: name: developer namespace: kubernetes-dashboard创建一个ServiceAccount很简单，仅仅指定一下namespace就好了，然而现在已经为这个名为developer的ServiceAccount创建了一个Token，我们可以使用如下命令查询一下：
kubectl -n kubernetes-dashboard describe secret $(kubectl -n kubernetes-dashboard get secret | grep developer | awk '{print $1}')你可以尝试使用这个Token去登录一下Kubernetes-dashboard，你会什么都看不到的，因为我们还没有为这个ServiceAccount绑定角色权限。
K8s为绑定角色权限提供了两类资源：
RoleBindingClusterRoleBinding相信光看名字你就知道他们的功能是什么了。这里我们分别给出一个例子：
kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: developer subjects: - kind: ServiceAccount name: developer namespace: kubernetes-dashboard roleRef: kind: ClusterRole name: developer apiGroup: rbac.authorization.k8s.io首先是ClusterRoleBinding的例子，通过应用这一配置，你的developer的ServiceAccount便对k8s集群的资源拥有了读权限，此时，可以再次尝试登陆，你就能看到资源了。
而对于RoleBinding，只是将资源换个名字罢了。
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: developer2 subjects: - kind: User name: Jane apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: developer apiGroup: rbac.authorization.k8s.io这里我们便不再详述。
通过这种方式，我们就可以对Kubernetes-dashboard进行权限管理了。
感谢观看！
