Azure/AWS等云环境部署Kubernetes Dashboard相关问题咨询

针对问题1的答复 #

官方没有提供Azure、AWS等单个公有云环境的专属部署教程——Kubernetes Dashboard本身是标准的Kubernetes原生应用，部署流程在所有符合标准的K8s集群上完全一致，和底层跑在本地IDC还是公有云没有关系。
默认执行完部署操作后，Dashboard对应的Service是ClusterIP类型，仅支持集群内部访问，如果你需要在云环境对外提供访问入口，确实需要手动配置暴露规则，常用的两种方案如下：

• 配置Load Balancer类型服务：直接将Dashboard对应的Service修改为LoadBalancer类型，AWS、Azure等公有云的集群控制组件会自动配套创建公网负载均衡实例、分配公网IP，配置完成后即可通过LB地址访问Dashboard。这种方式配置步骤最少，但公网暴露风险高，必须强制开启HTTPS、配置严格的身份认证规则，禁止开启免登录配置。
• 配置Ingress规则：这是更推荐的生产环境使用方案，你可以使用云平台提供的托管Ingress控制器（比如AWS应用负载均衡控制器、Azure应用网关Ingress控制器），为Dashboard绑定独立访问域名、配置SSL证书，还可以额外叠加WAF防护、访问源IP白名单等安全规则，整体安全性比直接挂载负载均衡更高。

针对问题2的答复 #

云环境部署Dashboard完全不需要将kubectl proxy作为后台常驻进程运行。
首先需要明确kubectl proxy的作用：这个命令本质是在执行命令的本地设备上启动一个临时代理端口，将本地发往该端口的请求转发到集群API Server，再由API Server代理转发到集群内的Dashboard服务，是给开发者本地临时测试访问用的工具，不是Dashboard运行的必需依赖。
如果你已经通过Load Balancer或者Ingress将Dashboard服务对外暴露，访问流量会直接到达Dashboard服务，完全不经过kubectl proxy链路，不需要执行这个命令。
如果你出于安全考虑不想把Dashboard直接暴露到公网，也不要采用常驻运行kubectl proxy的方案——这种方案稳定性差、权限管控粒度粗，更稳妥的做法是需要访问Dashboard时，在本地临时执行kubectl port-forward命令将Dashboard的服务端口转发到本地，访问完成后终止进程即可，既安全也不会产生额外的常驻资源开销。

注意：无论采用哪种暴露方式，都不要为了省事关闭Dashboard的身份认证模块，公网暴露未配置认证的Dashboard会导致集群完全失陷。

内容的提问来源于stack exchange，提问作者HelmBurger