k8s系列 – k8s-dashboard安装
本文档记录了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