本文档记录了dashboard安装流程，点击下载：k8s-dashboard安装.docx 。

正文

以下内容由word文档直接导入，虽然排版差劲一点，但是可以方便大家可以在线查阅。

K8s dashboard安装

安装参考官方文档：

https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/

下载yaml

在node01上下载Yaml：

wget https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.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只能管理员用，因为权限是无敌的。