每种选择都有优点和缺点,但是在现代的云原生方法中,趋势是将那些常见任务与应用程序核心功能代码分离。这种脱钩的原理是在应用程序堆栈常见任务中创建一致性,这在大型分布式应用程序中至关重要。它还消除了对每种语言的依赖和维护专用库的需要,从而使编程语言的选择更加灵活。
专为微服务而设计的容器架构是单独维护的,并用不同的语言编写,从而使开发人员无需重写相似的开发代码来实现单个功能。
例如,如果开发团队正在用Go编写主应用程序,并且存在用Python编写的现有功能来收集日志和指标,那么将Python代码卸载到Sidecar中的效率要比要求开发团队将其重写为走。通用任务与部署在任何核心应用程序服务旁边的独立统一服务的解耦称为“ sidecar”架构。
边车在很大程度上取决于主要应用。附加在sidecar中的外围任务只有在附加到主应用程序后才能实现,因此对于应用程序的每个实例,sidecar实例都与它并排部署。装载在Sidecar上的每个外围任务都是单独的功能,可以独立添加或删除,以任何语言编写和单独更新,而不会影响主应用程序代码。
它们独立于运行时和编程语言运行,并且可以访问与主应用程序相同的资源。在Kubernetes集群中,可以将sidecar部署为Kubernetes DaemonSet或sidecar代理。这些选项各有利弊。
守护程序集
Kubernetes中的经典方法是使用DaemonSet。DaemonSet是Pod的副本,群集中的所有节点都在此Pod上运行。创建包含共享功能(例如日志记录指标,性能或配置)的容器或容器时,它将在群集中的每个节点上运行,并将这些功能提供给共享该节点的其他容器。
实际上,例如,在收集度量标准时,一个DaemonSet Pod会为共享同一节点的所有Pod提供服务,而不管它们的类型,功能以及它们是否正在运行副本集或彼此独立。
Sidecar代理
Sidecar代理提供了更精细的方法。Sidecar代理中的功能在每个Pod中分别提供微服务。代理容器在包含微服务的Pod内部运行,并且仅承载该微服务所需的功能,从而使代理保持轻量级。
DaemonSet与Sidecar代理
结构上的考虑:在高度分隔杂物箱的环境中(例如,一个用于日志记录的容器,另一个用于度量收集的容器和另一个用于性能的容器),每个吊舱必须携带三个杂物容器。这导致资源利用效率低下,因为大部分资源正在完成相同的常见任务,而不是为核心应用程序提供服务。在这种情况下,使用DaemonSet而不是每个吊舱使用多个容器更为有效。
可用性:部署新的Sidecar容器需要重新启动整个Pod。每个吊舱中都有多个容器,要保持交付效率,就需要专注于核心服务的DevOps团队与从事常见任务以及此类同步的DevOps团队之间保持紧密的同步。实现这种同步无疑是很难实现的。
如果开发周期不同步,则在部署新的DaemonSet或更新现有的DaemonSet时会导致潜在的停机时间。
DaemonSets的安全性
使用DaemonSet,可以在容器级别配置安全设置,其中包含特权定义,卷访问权限,资源分配,二进制授权以及与容器部署相关的任何内容的详细信息。
但是,在DaemonSet环境中,容器作为特权容器运行。尽管它简化了容器部署或容器的主机保护的验证,但它对容器行为的监视提出了挑战,因为相同的容器(也称为副本集)可能在不同的节点上运行。
当对多个容器应用类似的策略时,恶意行为者在容器之间横向移动将构成永久风险。它还无法解决用于节点间通信的基于网络的隔离和隧道加密。
Sidecar代理的安全性
为了保护网络层,sidecar代理是理想的。从主应用程序卸载后,它们:
与语言无关,因此无需使加密适应库中的每种语言。
支持创建统一和/或目标特定策略和特权访问。
管理隧道加密。
管理内部集群通信。
但是,这些代理没有DaemonSet功能来监视和验证容器级别的安全设置。
最大化容器安全
为了充分利用Sidecar代理和DaemonSet安全功能的优势,可以使用Kubernetes本机机制,称为准入控制器。将专用的准入控制器与Sidecar代理结合使用,可以创建解决所有潜在容器威胁选项的整体安全套件。
使用Kubernetes,准入控制器用户可以为Pod创建和部署设置细粒度的授权。在容器级别,可以利用它来阻止容器作为根容器运行,或者确保容器的根文件系统被锁定为只读模式。它可以限制仅从批准的特定注册表中提取图像,并拒绝未知的图像注册表。
使用Kubernetes准入控制器和服务网格控制器
为了增强运行时安全性,使用专用的准入控制器可以管理关键的安全功能,例如:
二进制授权:策略执行的瓶颈,将您环境中的部署限制为已签名和授权的映像
连续漏洞扫描:在部署之前和之后,连续扫描检查是否存在超出预定义阈值的漏洞
在Pod部署设置中配置Pod安全策略(PSP)
使用Selinux,Seccom和AppArmor管理Pod部署
下一代Kubernetes工作负载保护解决方案从CI / CD管道的上游启动,自动识别合法工作负载。运行时策略确保仅将这些工作负载部署到群集。
这样,通过使用与网络基础架构分离的基于身份的自动工作负载安全性替换多个碎片化的防火墙,安全组和ACL,可以简化和加速应用程序的安全性。
- 赞助本站
- 微信扫一扫
- 加入Q群
- QQ扫一扫
评论