12个高价值Kubernetes健康指标
|
在操作上，重点是Kubernetes和它运行的工作负载，这本该如此，但这会导致一个在Kubernetes部署上常见的问题。虽然Kubernetes会定期打补丁和升级，但是关于底层操作系统的维护，更新，安全和操作往往被遗忘或忽视，至少在安全审计之前是这样的。我经常听SRE和系统管理员说，要同时管理Linux和Kubernetes，这导致额外的工作。就像一般的Linux操作系统一样，Kubernetes也需要打补丁、更新、保护和控制用户访问等等。但是，仅仅因为这些任务是在Kubernetes级别上完成的，并不意味着它们在操作系统级别上可被忽略。不过，选择合适的底层操作系统发行版，可以在很大程度上减少维护操作系统的工作量，减轻不及时更新的影响。 因此，考虑到你需要先安装Linux才能在其上运行Kubernetes，这将涉及底层的操作系统，你应该选择运行哪个Linux发行版呢?可选的方案有很多，但它们通常分为两种，即容器优化的操作系统，或通用的操作系统。 通用Linux操作系统 这些是正常类型的Linux。 大部分人都熟悉运行通用类型Linux操作系统，例如Ubuntu、Debian、CentOS、RHEL或是Fedora。这是在Kubernetes集群中运行通用操作系统的主要优势之一，你的系统管理员将熟悉如何安装、更新和加固你的Linux发行版。可以使用现有的工具集来启动服务器，安装操作系统，并将其配置为基本的安全级别。现有的补丁管理和安全检测工具应该可以在这些系统上正常运行，即使在其上运行Kubernetes。 然而…… 使用通用类型Linux系统，随之而来的是常见的Linux管理开销。这意味着用户账号管理，补丁管理，内核更新，服务防火墙，SSH安全，禁止root登陆，禁用未使用的守护进程，内核调优等等，都需要完成并保持最新。如前所述，这些任务中的大部分可以使用现有的工具例如Ansible，Chef，Puppet来完成，然而，更新清单或控制文件，使服务器配置文件适合Kubernetes主节点和工作节点，可以说并非易事。 另一个问题是操作系统更改与Kubernetes维护的协调。经常会出现不协调的情况，以至于在安装后操作系统仍保持原样。随着时间的推移，Kubernetes会(希望)升级，但底层的操作系统仍可能保持原样，慢慢地在各种包和已安装的内核中积累了已知的CVE(常见的漏洞和暴露)的负担。 理想情况下，你希望自动化平台(如Ansible或Puppet)与Kubernetes进行协调，以便可以在不影响Kubernetes操作的情况下升级节点的操作系统。这意味着操作系统需要：
当然，该系统需要保证在同一时刻不会有过多的节点在更新，以保证集群的工作负载能力不会受到负面影响(节点也不要太少，以免大型集群的更新速度慢于补丁和更新的发布速度)。你可能希望协调操作系统更新与Kubernetes更新，以减少重启和中断，但你仍然需要在短时间内支持更关键的操作系统更新。 通用类型Linux操作系统的最大优势是工作人员对它的熟悉程度。这意味着他们将熟悉部署，同时也具备排障技术。他们可以安装并使用常用的操作系统工具例如tcpdump、strace、lsof等等。配置可以很轻易地更改，以纠正错误和测试替代方案(这既是好事，同时也是坏事!)缺点是需要保持系统管理的开销，以及需要与Kubernetes基础设施和操作协调更新。 容器专用操作系统 美国国家标准与技术研究所(NIST)关于定义容器专用的操作系统有一个很好的总结，列出了一些优点。 “容器专用主机操作系统是一种明确设计为只运行容器的极简主义操作系统，其禁用了所有其他服务和功能，并采用只读文件系统和其他加固做法。当采用容器专用操作系统，攻击面通常要比通用类型操作系统小得多，因此攻击和破坏容器专用主机操作系统的机会较少。综上，如果可以，各个组织都应尽可能使用容器专用主机操作系统。”引自“NIST Special Publication 800-190 Application Container Security Guide” 总结一下，显而易见的一点就是，操作系统运行的软件和包越少，攻击面越小，漏洞也越少。这让容器专用操作系统从一开始就明显更安全，即使缺少频繁打补丁。
容器专用操作系统也可以采用其他的安全方式，例如将根文件系统(最好是所有文件系统)设为只读，减轻任何漏洞可能带来的影响。 （编辑：唐山站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
