取消
显示结果 
搜索替代 
您的意思是: 
cancel
1651
查看次数
10
有帮助
1
评论
julianchen
Spotlight
Spotlight
4. 提供端到端的安全性
对于容器和Kubernetes的安全性,我们需要考虑如下方面:
镜像扫描:在容器镜像运行之前,我们必须进行各种漏洞的扫描。因此,在允许镜像进入企业的专用存储表之前,该步骤可以作为持续交付(Continuous Delivery)管道的一部分予以实施。
镜像来源:除了对镜像进行漏洞扫描之外,我们还应当只允许那些“受信任”的镜像进入正在运行的群集环境之中。
主机与群集扫描:除了对镜像实施安全控制,我们也应对群集节点执行扫描。通过运用CISCenter for Internet Security)的各种安全基线(https://www.cisecurity.org/benchmark/kubernetes/),对Kubernetes进行例行安全加固就是一种最佳的实践。
分割与隔离:虽说多租户环境并非是硬性要求,但是通过在多个异构的工作负载之间共享群集,着实能够提高效率并节省成本。Kubernetes为隔离(如:命名空间和网络策略)和管理资源的开销(如:资源配额)提供了相应的构造。
身份管理:在典型的企业部署中,用户标识由一个集中式目录所提供。因此,无论我们在何处部署群集,都应当通过联合用户标识的控制,以方便实现一致性的管控与应用。
访问控制:虽然Kubernetes并没有用户的概念,但是它对指定的角色和权限能够提供丰富的控制。群集可以用到各种默认的角色、以及指定了权限集的自定义角色。重要的是:同一个企业内部的所有群集都应当使用通用的角色定义,和跨集群的管理方法。
虽然上述每一项安全实践都可以被单独地使用,但是我们还是应该全面地审查和规划那些跨多种云供应商时的安全策略。我们可以通过使用诸如AquaSecTwistlock等安全解决方案,以及其他与NirmataOpenShift等平台相结合的措施来实现。
5. 集中应用管理
与安全性相同,在Kubernetes的群集上管理各种应用也需要具有集中且一致性的方案。Kubernetes提供了一整套可用于定义和操作不同应用程序的构造。由于确实具有一些应用程序的内置理念,因此它能够灵活地支持不同的应用类型,并允许在Kubernetes上以不同的方式构建出不同的应用平台。
当然,Kubernetes的应用管理平台也提供了一些通用的属性和功能。下面列举了对Kubernetes工作负载予以集中式应用管理所需要考虑的方面:
应用程序建模与定义
用户需要通过定义其应用的组件,从而在现有组件的基础上撰写出新的应用。用户可以通过Kubernetes的声明性,来定义系统的目标状态。Kubernetes的工作负载API提供了几种构造,来定义所需的资源状态。例如:我们可以使用部署来建模出无状态的工作负载组件。这些定义通常被写成一组YAMLJSON的清单。当然,开发人员也可以运用诸如Git之类的版本控制系统(Version Control SystemVCS)来组织和管理这些清单。
开发人员只需定义和管理应用清单中的一些部分,而其他部分则可以由运营团队来指定操作的策略和特定的运行环境。因此,我们可以将应用清单理解为在部署和更新之前所动态地生成的一个管道。
Helm是一款辅助Kubernetes进行包管理的工具。它能够方便地对应用进行分组、版本控制、部署和更新。Kubernetes应用平台必须分别从开发和运营的不同关注点出发,提供简单的方法来建模、组织和构造应用清单、以及Helm Charts。而平台还必须提供对不同定义的验证,以便尽早捕获各种常见的错误,同时还能以简单方法重用那些应用的定义。
应用程序运行环境管理
应用程序在完成建模与验证之后,就需要被部署到群集之中。由于我们的最终目标是在不同的工作负载中重用这些群集,以提高效率和节约成本。因此,我们最好将应用程序的运行环境与群集进行解耦,并将通用的策略和控制应用到环境之中。
由于Kubernetes允许使用命名空间和网络策略来创建虚拟群集,因此Kubernetes的应用平台应当能够方便地利用这些构造,来创建具有逻辑分割与隔离、以及资源控制的环境。
变更管理
在多数情况下,运行环境具有持久性,因此我们需要以可控方式对其进行变更。而这些变更往往源自编译系统或交付管道中的上游环境。
Kubernetes应用平台需要为CI/CD(持续集成和持续交付)工具提供各种集成,并监控外部存储库的更改。一旦检测到变更,它们就应当根据不同环境下变更管理的策略,对其进行验证和处理。当然,用户也可审查变更、接受更改、或完全依赖自动化的更新进程。
应用程序监视
不同的应用程序会被运行在多个环境、和多种群集之中。从监控的角度而言,我们需要设法给传递的消息去噪,从而能聚焦到应用程序的实例之上。因此,我们需要将应用程序的指标、状态和事件关联到运行环境的构造上。同时,Kubernetes应用平台还须将监控与自动化的细粒度标签相集成,以便用户深入地查看到任何环境中的应用实例。
应用程序日志记录
与监控类似,日志数据也需要将应用的定义和运行环境信息相关联,并且能够被任何应用组件所访问到。Kubernetes应用平台必须能够对不同运行组件上的日志进行流转和聚合。如果您用到了集中式日志系统,那么就必须对应用予以必要的标记,以便将日志从不同的应用与环境中分离出来,同时也能实现跨团队与用户的访问管理。
警报与通知
为了实现服务级别的管理,我们必须能够根据任何指标数值、状态变更或不同条件,来自定义警报。同样,我们可以根据相关性来区分出需要立即采取行动与可以延迟处置的警报。例如:如果同一应用程序被部署运行在多个环境(如开发测试、暂存和生产环境)中,我们就必须能定义只在生产工作负载上被触发的警报规则。Kubernetes应用平台必须具备环境和应用的感知能力,从而提供对细粒度警报规则的定义和管理。
远程访问
由于云服务环境是动态的,而容器又将这种动态提升到了新的水平。因此,一旦有问题被检测和报告,我们就必须能够快速地访问到系统中那些受到影响的组件。而Kubernetes应用平台则必须提供一种方法,能在运行的容器中启动shell,访问容器运行环境的详细信息,而不必通过VPNSSH去访问各种云服务的实例。
事件管理
通常在Kubernetes的应用中,有可能会出现容器的退出和重启。这种退出可能是正常工作流(如升级)的一部分,也可能是由于内存不足等错误所造成的。Kubernetes应用平台必须能够识别故障,并捕获故障的所有详细信息,进而采取离线的分析与排障。
总结
容器和Kubernetes使得企业能够利用一组通用的行业最佳实践,来对跨多种云服务的应用程序进行操作和管理。所有主流的云服务供应商和应用平台,都相继承诺可以支持Kubernetes了。在他们之中,有以“开发人员提供代码工件,平台负责其余部分”为模式的平台即服务(Platform-as-a-ServicePaaS)方案;也有以“开发人员提供容器镜像,平台负责其余部分”为模式的容器即服务(Container-as-a-ServiceCaaS)方案;还有以“开发人员只需提供功能函数,平台负责其余部分”为模式的功能即服务(Functions-as-a-ServiceFaaS)方案。可以说,Kubernetes已成为了新的云原生操作系统。
因此,在开发多种云服务模式的Kubernetes策略时,企业必须周全地考虑到:他们希望如何去使用基础架构服务、如何管理Kubernetes的组件版本、如何设计与管理Kubernetes群集、如何定义公共安全层、以及如何管理好应用。
【原标题】 Best Practices forMulti-CloudKubernetes(作者:Jim Bugwadia )
原文链接:https://dzone.com/articles/best-practices-for-multi-cloud-Kubernetes
评论
one-time
Level 13
Level 13
感谢楼主分享,在此把此篇相关链接贴出来,方便大家阅读
【原创翻译】多种云服务模式下Kubernetes的最佳实践(1)
入门指南

使用上面的搜索栏输入关键字、短语或问题,搜索问题的答案。

我们希望您在这里的旅程尽可能顺利,因此这里有一些链接可以帮助您快速熟悉思科社区:









快捷链接