k8s系列 – k8s-dashboard安装

本文档记录了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只能管理员用,因为权限是无敌的。

如果文章帮助到你,那么帮我点一下广告 or 打赏1元钱,服务器费用需要大家的支持。

发表评论

电子邮件地址不会被公开。