k8s Dashboard 运维维护记录(一) k8s开发和运维的划分

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列表不在证书范围内