k8s Dashboard 运维维护记录

发布于:2024-04-29 ⋅ 阅读:(21) ⋅ 点赞:(0)

k8s Dashboard 运维维护记录

k8s Dashboard 运维维护记录

Q1:需要使用firefox浏览器访问

提示了证书错误NET::ERR_CERT_INVALID,原因是由于物理机的浏览器证书不可用

需要注意的是,若提示“连接不安全”的警告时,点击“高级”,点击“添加例外”后即可:

Q2:使用低权限登录dashboard界面

bootstrap.kubeconfig

配置Dashboard

Dashboard的配置是难点,尤其是涉及到安全权限相关,相当复杂,坑也比较多。

进入Dashboard的登录界面后,认证方式有Kubeconfig和令牌两种方式(实际上还有账号密码的方式,默认不开启不显示)。看到Kubeconfig和令牌,估计头都大了。是否有简便的方法,让我们能直接访问Dashboard?当然有,选择跳过,会出现如上页面:

我们看到了很多权限错误提示,主要是
system:serviceaccount:kube-system:kubernetes-dashboard的权限不足引起的

因此,我们可以更改RoleBinding修改为ClusterRoleBinding,并且修改roleRef中的kind和name,使用cluster-admin这个非常牛逼的CusterRole(超级用户权限,其拥有访问kube-apiserver的所有权限)。如下:

#源文件

---
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

#修改后

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubernetes-dashboard-minimal
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kube-system

修改后,重新创建kubernetes-dashboard.yaml,Dashboard就可以拥有访问整个K8S 集群API的权限。我们重新访问Dashboard

还可以安装Dashboard的Heapster插件

Q3:dashboard -v2.7.0 创建admin账号

用户文件admin-user.yml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kubernetes-dashboard

---
apiVersion: v1
kind: Secret
metadata:
  name: admin-user
  namespace: kubernetes-dashboard
  annotations:
    kubernetes.io/service-account.name: "admin-user"   
type: kubernetes.io/service-account-token

#获取token

#方法1
kubectl get secret admin-user -n kubernetes-dashboard -o jsonpath={".data.token"} | base64 -d
#方法2
kubectl describe serviceaccounts -n kubernetes-dashboard  admin-user| grep Tokens
kubectl -n kubernetes-dashboard  describe secrets  admin-user

Q4:安装部署dashboard

出现登录界面

创建一个cluster-admin角色的service account , 和一个clusterrolebinding, 以便访问所有的k8s资源

>kubectl create serviceaccount cluster-admin-dashboard-sa

>kubectl create clusterrolebinding cluster-admin-dashboard-sa \

--clusterrole=cluster-admin \

--serviceaccount=default:cluster-admin-dashboard-sa

Copy产生的Token,并使用此Token登录到dashboard中

>kubectl get secret | grep cluster-admin-dashboard-sa

>kubectl describe secrets/cluster-admin-dashboard-sa-token-cp4th

方法2获取token

kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')

Q5:SecurityContext.RunAsUser is forbidden

kube-controller-manager: I1225 10:38:50.459168 92029 event.go:255] Event(v1.ObjectReference{Kind:"ReplicaSet", Namespace:"kubernetes-d

ashboard", Name:"kubernetes-dashboard-5996555fd8", UID:"ea499098-0f62-4d57-a6c6-604923a24333", APIVersion:"apps/v1", ResourceVersion:"2478690", FieldPath:"

"}): type: 'Warning' reason: 'FailedCreate' Error creating: pods "kubernetes-dashboard-5996555fd8-mvmht" is forbidden: SecurityContext.RunAsUser is forbidden

因为Pods需要设置安全策略

securityContext:

allowPrivilegeEscalation: false

readOnlyRootFilesystem: true

runAsUser: 1001

runAsGroup: 2001

去掉SecurityContextDeny,降低安全配置

vi /etc/kubernetes/apiserver.conf

vi /usr/lib/systemd/system/kube-apiserver.service

systemctl daemon-reload

systemctl restart kube-apiserver.service

重启服务

systemctl restart kube-apiserver

SecurityContextDeny:此准入控制器将拒绝任何试图设置某些升级的SecurityContext字段的pod

systemctl status etcd -l

查看项

kube-apiserver -h | grep enable-admission-plugins

配置点

/etc/kubernetes/apiserver.conf

Q6:SecurityContextDeny介绍

禁止创建设置了 Security Context 的 pod。这个插件将会将使用了 SecurityContext的pod中定义的选项全部失效。关于 SecurityContext的描述:SecurityContext 在container中定义了操作系统级别的安全设定(uid, gid, capabilities, SELinux等等)

Security Context时运用于容器的操作系统安全设置(uid、gid、capabilities、SELinux role等),Admission Control的SecurityContextDeny插件的作用是,禁止创建设置了Security Context的Pod,例如包含以下配置项的Pod:

  • spec.containers.securityContext.seLinuxOptions
  • spec.containers.securityContext.runAsUser

解析

LimitRanger:此准入控制器将确保所有资源请求不会超过 namespace 的 LimitRange

SecurityContextDeny:此准入控制器将拒绝任何试图设置某些升级的SecurityContext字段的pod

ServiceAccount:此准入控制器实现serviceAccounts的自动化

ResourceQuota:此准入控制器将观察传入请求并确保它不违反命名空间的ResourceQuota对象中列举的任何约束

NodeRestriction:该准入控制器限制了 kubelet 可以修改的Node和Pod对象

NamespaceExists:此许可控制器检查除 Namespace 其自身之外的命名空间资源上的所有请求。如果请求引用的命名空间不存在,则拒绝该请求

NamespaceLifecycle:此准入控制器强制执行正在终止的命令空间中不能创建新对象,并确保Namespace拒绝不存在的请求。此准入控制器还防止缺失三个系统保留的命名空间default、kube-system、kube-public

Q7:or the --apiserver-host param points to a server that does not exist. Reason: Get https://192.168.10.20:6443/version?timeout=32s: x509: certificate signed by unknown authority

证书格式不对

Q8:docker logs contain_id

2021/07/12 03:36:05 Initializing csrf token from kubernetes-dashboard-csrf secret

panic: Get "https://10.0.0.1:443/api/v1/namespaces/kubernetes-dashboard/secrets/kubernetes-dashboard-csrf": x509: certificate is valid for 127.0.0.1, 192.168.10.20, 192.168.10.21, 192.168.10.22, not 10.0.0.1

IP列表不在证书范围内


网站公告

今日签到

点亮在社区的每一天
去签到