DashBoard
Kubernetes Dashboard是一个通用的基于WebUI的kubernetes集群管理工具。用户管理运行在集群中的应用并对这些运行的应用进行快速的故障排查,同时也可以用于管理集群本身。
重要信息:在执行任何后续步骤之前,请阅读“访问控制”指南。默认的
Dashboard部署包含运行所需的最小RBAC权限集。
执行以下命令部署Dashboard:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yamlYAML文件参考这里。
要从本地工作站访问Dashboard,必须为Kubernetes集群创建安全通道。运行以下命令:
kubectl proxy通过以下地址访问Dashboard:http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
创建一个认证令牌(RBAC)
要了解如何创建示例用户并登录,请按照创建示例用户指南进行操作。
注意:
Kubeconfig身份验证方法不支持外部身份提供程序或基于证书的身份验证。Dashboard只能通过HTTPS访问。Heapster必须在集群中运行才能获取指标并以提醒方式展示。在“集成”指南中阅读更多相关信息。
访问控制
当Dashboard安装完成并且能够正常访问后,将专注于为用户配置对群集资源的访问控制。从版本1.7开始:
Dashboard不再具有默认授予的完全管理员权限。所有权限都被撤销,并且只授予了使
Dashboard工作所需的最小权限。
重要信息:本说明仅针对使用
Dashboard 1.7及更高版本的用户。如果Dashboard只能由受信任的人员访问,所有人员都具有完全管理员权限,那么可以授予他们集群的管理员权限。请注意,其他应用程序不应直接访问Dashboard,因为它可能会导致权限提升。确保集群内流量仅限于命名空间,或者只是撤消对集群内其他应用程序的Dashboard访问权限。
简介
Kubernetes支持几种验证和授权用户的方法。可以在这里和这里阅读它们。授权由Kubernetes API Server处理。Dashboard仅充当代理并将所有身份验证信息传递给它。在禁止访问的情况下,相应的警告将显示在Dashboard中。
Dashboard默认权限
v1.7
create和watch在kube-system命名空间中secret的权限,以创建和监视kubernetes-dashboard-key-holdersecret的更改。get,update和delete在kube-system命名空间中名为kubernetes-dashboard-key-holder和kubernetes-dashboard-certs的secret的权限。对
kube-system命名空间中的heapster服务的代理权限,以允许从heapster获取指标。
v1.8
为
kube-system命名空间中的secret创建权限以使其能够创建kubernetes-dashboard-key-holder的secret。get,update和delete在kube-system命名空间中名为kubernetes-dashboard-key-holder和kubernetes-dashboard-certs的secret的权限。get并update在kube-system命名空间中名为kubernetes-dashboard-settings的configmap的权限。对
kube-system命名空间中的heapster服务的代理权限,以允许从heapster获取指标。
认证
从版本1.7开始,Dashboard支持基于以下内容的用户身份验证:
Authorization: Bearer <token>:在每次向Dashboard发出请求时传递请求头。从1.6版开始支持。具有最高优先级。如果存在,则不会显示登录界面。Bearer Token:在Dashboard登录界面中使用。用户名/密码:在
Dashboard登录界面中使用。kubeconfig:在Dashboard登录界面中使用。
登录界面
登录界面在1.7版中引入。如果使用的是最新推荐的安装,则默认情况下将启用登录功能。在任何其他情况下,如果更喜欢手动配置证书,则需要将--tls-cert-file和--tls-cert-key标志传递给Dashboard。HTTPS端点将在Dashboard容器的端口8443上公开。可以通过提供--port标志来更改它。
使用“跳过”选项将使Dashboard使用Dashboard Service Account的权限。默认情况下,跳过按钮自1.10.1起禁用。使用--enable-skip-login dashboard标志显示它。

Authorization header
在通过HTTP访问Dashboard时,使用Authorization header是使Dashboard充当用户的唯一方法。请注意,由于普通HTTP流量容易受到MITM攻击(中间人攻击),因此存在一些风险。
要使Dashboard使用Authorization header,只需将每个请求中的Authorization:Bearer <token>传递给Dashboard。这可以通过在Dashboard前配置反向代理来实现。代理服务器将负责身份提供者的身份验证,并将请求头中生成的令牌传递给Dashboard。请注意,需要正确配置Kubernetes API Server才能接受这些令牌。
要快速测试它,请查看允许手动修改请求头的Requestly浏览器插件。
重要信息:如果通过
API Server代理访问Dashboard,则Authorization header将不起作用。访问Dashboard指南中描述的kubectl proxy和API Server访问Dashboard的方式都不起作用。这是因为一旦请求到达API Server`,所有其他标头都将被删除。
Bearer Token
建议首先熟悉Kubernetes身份验证文档,以了解如何获取可用于登录的令牌。例如,每个Service Account都有一个具有有效Bearer Token的secret,可用于登录Dashboard。
Bearer Token 样例

使用kubectl获取token
默认情况下,在Kubernetes中创建了许多Service Account,它们都具有不同的访问权限。为了找到任何可用于登录的令牌,使用kubectl:
现在可以使用显示的令牌登录Dashboard。要了解有关如何配置和使用Bearer Token的更多信息,请阅读“简介”部分。
Basic
Basic认证默认是关闭的,原因是Kubernetes API Server需要配置授权模式ABAC和--basic-auth-file标志。如果API Server没有自动回退到匿名用户,那么无法检查提供的凭据是否有效。
为了在Dashboard中启用Basic认证,必须提供authentication-mode=basic标志。默认情况下,它设置为--authentication-mode=token。
Kubeconfig
为方便起见,提供了这种登录方法。kubeconfig文件仅支持-authentication-mode标志指定的身份验证选项。如果它配置为使用任何其他方式,错误将显示在Dashboard中。目前不支持外部身份提供程序或基于证书的身份验证。
管理员权限
重要提示:在继续操作之前,请确保知道自己在做什么。向
Dashboard的Service Account授予管理员权限可能存在安全风险。
可以通过创建以下ClusterRoleBinding来授予Dashboard的Service Accout完全管理员权限。根据所选的安装方法复制YAML文件并另存为,如dashboard-admin.yaml。使用kubectl create -f dashboard-admin.yaml进行部署。之后,可以使用登录页面上的“跳过”选项来访问Dashboard。
官方版
开发版
访问 Dashboard
1.7.x及以上版本
重要信息:HTTPS endpoints仅在使用推荐安装程序时可用,按照入门指南部署Dashboard或手动提供--tls-key-file和--tls-cert-file标志。如果没有,并且想通过HTTP访问Dashboard,则可以使用与旧版本相同的方式访问。
注意:不应通过HTTP公开
Dashboard。对于通过HTTP访问的域,将无法登录。单击登录页面上的登录按钮后不会发生任何事情。
kubectl proxy
kubectl proxy在本地主机和Kubernetes API Server之间创建代理服务器。默认情况下,它只能在本地(从启动它的计算机)访问。
首先让检查kubectl是否已正确配置并且是否可以访问群集。如果出现错误,请按照本指南安装和设置kubectl。
启动本地代理服务器:
启动代理服务器后,可以从浏览器访问Dashboard。
要访问Dashboard的HTTPS endpoints,请转到:http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
注意:不应使用kubectl proxy命令公开暴露Dashboard,因为它只允许HTTP连接。对于localhost和127.0.0.1以外的域,将无法登录。单击登录页面上的登录按钮后不会发生任何事情。
NodePort
这种访问Dashboard的方式仅建议用于单节点设置中的开发环境。
编辑kubernetes-dashboard service:
可以看到服务的yaml表示,将type:ClusterIP修改为type:NodePort并保存文件。如果已经更改,请转到下一步。
接下来,检查Dashboard暴露的端口。
Dashboard已在端口31707(HTTPS)上公开。现在,可以从以下浏览器访问它:https://<master-ip>:31707。通过执行kubectl cluster-info可以找到master-ip。通常它是机器的127.0.0.1或IP,假设集群直接在服务器上运行,执行这些命令。
如果尝试在多节点群集上使用NodePort公开Dashboard,则必须找到运行Dashboard的节点的IP才能访问它。应该访问https://<node-ip>:<nodePort>,而不是访问https://<master-ip>:<nodePort>。
API Server
如果Kubernetes API Server公开并可从外部访问,可以直接访问Dashboard: https://<master-ip>:<apiserver-port>/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
注意:只有选择在浏览器中安装用户证书时,才能使用这种访问
Dashboard的方式。在示例中,可以使用kubeconfig文件用于联系API Server的证书。
Ingress
Dashboard也可以使用Ingress资源公开。有关更多信息,请查看这里:
https://kubernetes.io/docs/concepts/services-networking/ingress
创建简单用户
在本指南中,将了解如何使用Kubernetes的Service Account机制创建新用户,授予此用户管理员权限并使用与此用户关联的Bearer Token登录仪表板。
将下面提供的的代码片段复制到某个dashboard-adminuser.yaml文件,并使用kubectl apply -f dashboard-adminuser.yaml创建它们。
创建 Service Account
首先在kube-system命名空间中创建名为admin-user的Service Account。
创建 ClusterRoleBinding
在大多数情况下,使用kops或kubeadm或任何其他流行工具配置集群,ClusterRole admin-Role已存在于集群中。可以使用它并为ServiceAccount仅创建ClusterRoleBinding。
注意:
ClusterRoleBinding资源的apiVersion可能在Kubernetes版本之间有所不同。在Kubernetes v1.8之前,apiVersion是rbac.authorization.k8s.io/v1beta1。
Bearer Token
现在需要找到可以用来登录的令牌。执行以下命令:
现在复制令牌并将其粘贴到登录屏幕上的Enter token字段中。

单击登录按钮就可以了。现在以管理员身份登录。

要了解有关如何在Kubernetes中授予/拒绝权限的更多信息,请阅读官方认证和授权文档。
集成
目前只支持Heapster集成,但是有计划将集成框架引入Dashboard。它将允许支持和集成更多指标采集器以及其他应用程序,如[Weave Scope](https://github.com/weaveworks/scope)或[Grafana](https://github.com/grafana/grafana)等。
指标集成
指标集成允许Dashboard显示cpu/内存使用情况图以及在集群内运行的资源的迷你图。为了使Dashboard能够适应度量标准提供程序的崩溃,引入了--metric-client-check-period标志。默认情况下,将检查度量标准提供程序每30秒的运行状况,如果崩溃,则将禁用度量标准。
Heapster
要在Dashboard中显示迷你图和使用情况图,需要在群集上运行Heapster。我们要求将heapster与名为heapster的Service一起部署在kube-system命名空间中。如果无法从群集内部访问heapster,则可以提供heapster url作为Dashboard容器的标志--heapster-host=<heapster_url>。
注意:目前
--heapster-host标志不支持HTTPS连接。只应使用HTTP网址。
FQA
如何在开发环境使用HTTPS?
开发环境以
gulp serve或gulp serve:prod开始。要使其在HTTPS上运行,需要传递证书。为此,需要对所提到的命令使用以下标志:tlsCert:
.crt文件的路径tlsKey:
.key文件的路径serveHttps:启动HTTPS模式的标识
Dashboard显示
open /certs/dashboard.crt: no such file or directoty错误。它已在1.8.0版本中修复,不应该再发生了。
这种情况时有发生。用于创建自签名证书的
Init容器尚未完成其工作,并且已启动主Dashboard容器而没有所需的证书。尝试重新部署Dashboard,它应该解决问题。在
Dashboard中无法看到图片,如何启动它?确保
Heapster已启动并正在运行,Dashboard能够与之连接。首先,必须使用Dashboard或kubectl命令验证Heapster状态。然后,应该检查Dashboard日志并查找度量标准和Heapster关键字。 可以在此处找到有关Dashboard集成的更多信息。在开发过程中,在浏览器的控制台中收到了很多奇怪的错误。可能有什么不对?
可能需要更新npm依赖项。从
Dashboard的根目录运行以下命令:rm -rf node_modules && npm i为何显示
Go is not in the path?遇到这样的错误可能意味着需要重新运行以下命令:
export PATH=$PATH:/usr/local/go/bin如下报错:
linux mounts: Path /var/lib/kubelet is mounted on / but it is not a shared mount尝试执行如下命令:
sudo mount --bind /var/lib/kubelet /var/lib/kubelet && sudo mount --make-shared /var/lib/kubelet在这里获取更多信息。
尝试访问
Dashboard时看到404错误。无法加载仪表板资源。重要提示:有一个与
Kubernetes 1.7.6相关的已知问题,其中/ui重定向不起作用。尝试在/ui重定向url的末尾添加尾部斜杠:http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/如果这没有帮助,那么这意味着集群存在问题,或者尝试以错误的方式访问
Dashboard。通常,当尝试以错误的方式使用kubectl proxy公开Dashboard`时(即缺少权限),会发生这种情况。您可以快速检查是否访问
http://localhost:8001/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard/而不是http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy。检查问题是否与
Dashboard相关的其他方法是使用“访问Dashboard”指南中描述的NodePort方法公开和访问它。这将允许直接访问Dashboard而不涉及任何代理。如果任何描述的方法都有效,那么这意味着它不是
Dashboard问题,应该在核心存储库上寻求帮助,或者更好地阅读Kubernetes文档以了解它的工作原理。使用Kubernetes GCE集群,但获取禁止的访问错误。
默认情况下,GCE上的
Dashboard安装的权限很小。这不是问题。 应该授予kubernetes-dashboardService Account更多权限,以便能够访问群集资源。阅读Kubernetes文档以了解如何执行此操作。您还可以查看#2326和#2415(评论)了解更多详情。/ui重定向不起作用或显示Error: 'malformed HTTP response基于部署和访问
Dashboard(HTTPS或HTTP)的方式,存在不同的问题。通过HTTP访问Dashboard:有一个与
Kubernetes 1.7.X相关的已知问题,其中/ui重定向不起作用。尝试在/ui重定向url的末尾添加尾部斜杠:http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/通过HTTPS访问Dashboard:
/ui重定向不适用于HTTPS的原因是它尚未在核心存储库中更新。查看这里了解什么时候合并。可能在K8S 1.8.3+之前不可用。
kubectl-proxy
在localhost和Kubernetes API Server之间创建一个服务端代理或者应用级别的网关。它还允许通过指定的HTTP路径提供静态内容。所有传入的数据都通过一个端口进入并转发到远程kubernetes API Server端口,不包含静态内容匹配的路径。
例如
代理全部kubernetes api:
代理部分kubernetes api和一些静态文件:
代理整个kubernetes api到另一个根目录:
代理端口修改为8011,静态内容的路径为./local/www/:
在任意本地端口上运行kubernetes apiserver的代理。服务器的选定端口将输出到stdout:
运行kubernetes apiserver的代理,将api前缀更改为k8s-api 这使得例如,获取pods的api运行在localhost:8001/k8s-api/v1/pods/
options
短参数
长参数
解释
--accept-hosts='^localhost$,^127\.0\.0\.1$,^\[::1\]$'
代理接受的主机的正则表达式
--accept-paths='^.*'
代理接受的路径的正则表达式
--address='127.0.0.1'
要服务的IP地址
--api-prefix='/'
用于提供代理API的前缀
--disable-filter=false
如果为true,则在代理中禁用请求筛选。 这很危险,当与可访问端口一起使用时,可能会使容易受到XSRF攻击
--keepalive=0s
keepalive指定活动网络连接的保持活动期。 设置为0以禁用keepalive
-p
--port=8001
运行代理的端口。 设置为0以选择随机端口
--reject-methods='^$'
代理应拒绝的HTTP方法的正则表达式(例如--reject-methods ='POST,PUT,PATCH')
--reject-paths='^/api/.*/pods/.*/exec,^/api/.*/pods/.*/attach'
代理应拒绝的路径的正则表达式。此处指定的路径即使被--accept-paths接受也将被拒绝。
-u
--unix-socket=''
运行代理的Unix套接字
-w
--www=''
在指定前缀下提供给定目录中的静态文件
-P
--www-prefix='/static/'
如果指定了静态文件目录,则在下面提供静态文件的前缀
最后更新于