DashBoard
Kubernetes Dashboard
是一个通用的基于WebUI
的kubernetes
集群管理工具。用户管理运行在集群中的应用并对这些运行的应用进行快速的故障排查,同时也可以用于管理集群本身。
重要信息:在执行任何后续步骤之前,请阅读“访问控制”指南。默认的
Dashboard
部署包含运行所需的最小RBAC
权限集。
执行以下命令部署Dashboard
:
YAML文件参考这里。
要从本地工作站访问Dashboard
,必须为Kubernetes
集群创建安全通道。运行以下命令:
通过以下地址访问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-holder
secret
的更改。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-dashboard
Service 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/'
如果指定了静态文件目录,则在下面提供静态文件的前缀
最后更新于
这有帮助吗?