本文档记录了dashboard安装流程，点击下载：k8s-dashboard安装.docx 。
正文
以下内容由word文档直接导入，虽然排版差劲一点，但是可以方便大家可以在线查阅。
K8s dashboard安装
安装参考官方文档：
https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/
下载yaml
在node01上下载Yaml：
分析yaml
在yaml文件中，官方写好了部署dashboard需要用到的yaml文件，里面包含了deployment，service，service account。
观察一下Yaml文件。
# ——————- Dashboard Secret ——————- #
apiVersion: v1
kind: Secret
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-certs
namespace: kube-system
type: Opaque
secret是用来配置一些保密的kv的，然后可以mount到Pod中访问，但是这个secret啥data也没配置，感觉是没用得。
# ——————- Dashboard Service Account ——————- #
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kube-system
service account是k8s的内部帐号，这里建立了一个kubernetes-dashboard的账号，系统会自动给它分配一套client cert证书。稍后，我们会看到dashboard pod会关联这个账号，k8s会把client cert和apiserver的ca给mount到容器里，供dashboard使用。其中client cert用于apiserver验证dashboard身份合法，ca用于dashboard验证apiserver真实。
# ——————- Dashboard Role & Role Binding ——————- #
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: kubernetes-dashboard-minimal
namespace: kube-system
Role太长了，这就是RBAC中的角色，可以给角色授权不同apiGroup下不同resource的操作权限。
我们要查看k8s有哪些apiGroup以及每个apiGroup包含了哪些resource（比如pod，deployment），可以这样查看：kubectl api-resources，里面会列出所有的资源，我们的Role就是授予不同资源的访问权限，Role可以指定授予这些资源的一些操作权限类型： verbs: [“get”, “list”, “watch”, “create”, “update”, “patch”, “delete”]，我看大概就是这些，具体情况具体分析吧。
稍后会通过RoleBinding把service account和role做绑定，就相当于赋予角色给帐号，帐号就拥有了一些权限，绑定如下：
—
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: kubernetes-dashboard-minimal
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: kubernetes-dashboard-minimal
subjects:
– kind: ServiceAccount
name: kubernetes-dashboard
namespace: kube-system
接下来是deployment部署dashboard：
# ——————- Dashboard Deployment ——————- #
kind: Deployment
apiVersion: apps/v1beta2
volumeMounts:
– name: kubernetes-dashboard-certs
mountPath: /certs
# Create on-disk volume to store exec logs
– mountPath: /tmp
name: tmp-volume
livenessProbe:
httpGet:
scheme: HTTPS
path: /
port: 8443
initialDelaySeconds: 30
timeoutSeconds: 30
volumes:
– name: kubernetes-dashboard-certs
secret:
secretName: kubernetes-dashboard-certs
– name: tmp-volume
emptyDir: {}
serviceAccountName: kubernetes-dashboard
注意到serviceAccountName控制了serviceAccount帐号cert注入到容器供dashboard访问apiserver使用。 那个没数据的secret也注入进去了，过会到容器里看看里面有什么。
最后绑了个service：
# ——————- Dashboard Service ——————- #
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kube-system
spec:
ports:
– port: 443
targetPort: 8443
selector:
k8s-app: kubernetes-dashboard
暴露访问
为了dashboard暴露到k8s集群外可以访问，可以直接让上述service改为nodePort模式暴露端口到宿主机。
# ——————- Dashboard Service ——————- #
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kube-system
spec:
type: NodePort
ports:
– port: 443
targetPort: 8443
selector:
k8s-app: kubernetes-dashboard
添加红色部分即可，一会启动时会分配一个port给 service供集群外访问，即占用所有机器上的该端口。（暂时就这样吧，以后用ingress机制统一接入比较好，省端口）
下载镜像
Yaml中的dashboard镜像会被墙，我在node01上手动下载。
下载：
docker pull anjia0532/google-containers.kubernetes-dashboard-amd64:v1.10.0
然后改名：
docker tag anjia0532/google-containers.kubernetes-dashboard-amd64:v1.10.0 k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.0
然后删除anjia0532的镜像：
docker rmi anjia0532/google-containers.kubernetes-dashboard-amd64:v1.10.0
dashboard的deployment没有写nodeSelector，所以会部署到任意机器上，因为我只有3个node，所以干脆把镜像下载到各个节点上把。
启动dashboard
把刚才的yaml生效：
kubectl apply -f kubernetes-dashboard.yaml
k8s@node01:~$ kubectl get deployments -n kube-system
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
coredns 2 2 2 2 4d5h
kubernetes-dashboard 1 1 1 1 3h36m
可以看到dashboard运行在kube-system命名空间下了。
k8s@node01:~$ kubectl get service -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 4d5h
kubernetes-dashboard NodePort 10.97.151.44 <none> 443:30292/TCP 3h37m
可以看到service暴露的nodePort是30292，而443的意思是基于cluster ip访问时的端口。
随便传一个k8s节点IP，用https协议就可以访问到dashboard。
创建登录账号
登录界面有3个按钮：
1，点击跳过，可以进入dashboard界面，但基本没有权限。
2，上传.kube/config文件，这是kubectl使用的文件，里面配置了一个kubernetes-admin账号与cert，这个是api server信得过的一套证书，所以可以直接用，是超级特权。
3，自建帐号并赋予权限，下面具体说一下这种。
之前yaml中给dashboard配的serviceAccount只是一些支持dashboard工作的基本权限，而我们想真的操作集群数据得把有权限的serviceAccount密钥交给dashboard，由dashboard代为与api server交互，这就是我理解的登录。
所以我们就建一个帐号，因为K8S有现成的超级权限Role存在，所以我们直接把这个Role赋予帐号即可。
（当然也可以建只读权限的账号，但意义不大。）
过程参考：https://github.com/kubernetes/dashboard/wiki/Creating-sample-user
新建一个service account，这是k8s集群的账号概念。
apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-user
namespace: kube-system
放文件里apply一下，就会得到一个kube-system命名空间里的admin-user账号，其对应的密钥是一个token形式的，可以查的到：
Tokens就是帐号对应的密钥，就是一个secret类型的东西，相当于现在我们的账号是admin-user，密码就是这个secret。
我们继续看一下secret：
这个token通过annotation关联到了用户admin-user，一一对应关系。
现在我们可以拿着这个账号登录dashboard，但依旧会提示没权限操作各种资源：
授权
K8s遵循RBAC模型，给帐号赋予权限需要通过赋予角色实现。
然而k8s系统中默认是有一个Role，它具备所有权限，所以我们就不用再建Role了，不过我们看一下这个Role也就大概知道如何定义超级权限了：
可见，所有的apiGroups（我理解就是各种apiVersion）下的所有资源（比如pod,node,label）的所有verbs（资源操作，比如create,update,delete），都有权限。
所有其他的（nonResourceURLS）有所有操作权限。
我理解本质上RBAC控制就是基于URL的，k8s中所有资源都是URL表达的。
所以绑定帐号与角色即可：
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: admin-user
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
– kind: ServiceAccount
name: admin-user
namespace: kube-system
apply一下，再用刚才的token登录就权限都充足了，这个token只能管理员用，因为权限是无敌的。
如果文章帮助您解决了工作难题，您可以帮我点击屏幕上的任意广告，或者赞助少量费用来支持我的持续创作，谢谢~
1