2019 年 CNCF 中国云原生调查

CNCF 会定期调研社区,以更好地了解开源和云原生技术的采用。这是 CNCF 第三次使用中文进行“中国云原生调查”,以更深入地了解中国采用云原生的速度,以及如何在庞大且不断发展的中国社区中增强开发人员的能力并促进其发展。

中国云原生调查的重点

  • 49% 的受访者在生产中使用容器,32% 的人计划使用。与 2018 年 11 月相比,涨幅明显,当时生产中仅有 20% 使用容器。
  • 72% 的受访者在生产中使用 Kubernetes,高于 2018 年 11 月的 40%。
  • 公共云的使用率从 2018 年 11 月的 51% 下降到了 36%,有近 39% 的受访者选择了混合云。
  • CNCF 项目的使用呈指数增长。CNCF 现在主持了四个在中国诞生并广泛使用的项目:正在孵化的 Dragonfly 和 KubeEdge,以及刚毕业的 Harbor 和 TiKV。
《2019 年中国云原生调查》包含 300 人的反馈意见,其中 97% 来自亚洲,主要是中国。

容器使用率

对中国的调查表明,尽管中国容器使用率落后于全球采用率,但其势头正在增强。在调查中,将近一半(49%)的受访者在生产中使用了容器,这比 2018 年 3 月调查的 32% 和 2018 年 11 月的 20% 有所增长。计划在生产中使用容器的数量变少,在 2018 年 3 月的调查中为 57%,在 11 月为 40%。这意味着许多组织已将容器计划付诸实施,而不再是计划阶段。

Kubernetes 增长

Kubernetes 在行业中正在成为容器编排的通用平台,其在中国 CNCF 社区的普及率已达到峰值。72% 的受访者表示在生产中使用 Kubernetes,这与 2018 年 11 月的 40% 相比大幅增长。

云原生项目

CNCF 管理着大量的开源项目,这些项目对于云本机的开发,部署和生命周期管理至关重要。CNCF 项目在中国的使用率呈指数级增长,例如,有 57% 的受访者使用了 Prometheus 监控和警报系统,比 2018 年 3 月的 16% 有显着增加。现在,CoreDNS 的使用率为 35%,高于 2018 年 3 月的 10%。

CNCF还主持了在中国创建的四个项目,这些项目在该地区得到了更广泛的应用。Dragonfly(生产中使用率占 17%)和 KubeEdge(生产中使用率占 11%)是最常用的两个 Sandbox 项目,现在这两个都是孵化项目。Harbor 和 TiKV 是毕业项目,分别在生产中占 27% 和 5%。

完整调查地址:https://www.cncf.io/blog/2020/10/13/cncf-cloud-native-survey-china-2019/

容器技术发展简史

聊容器技术避不开云原生,聊云原生也避不开容器技术。容器技术和云原生就是一对双螺旋体,容器技术催生了云原生思潮,云原生生态推动了容器技术发展。从 2013 年 docker(container)技术诞生,到 2015 年 CNCF 这个云原生领域重量级联盟的成立,这不是历史的巧合而是历史的必然。借用一张业界广泛引用的云原生容器技术进阶图来了解一下容器技术和云原生诞生的历史背景。

  • 1979 年,Unix v7 系统支持 chroot,为应用构建一个独立的虚拟文件系统视图。
  • 1999 年,FreeBSD 4.0 支持 jail,第一个商用化的 OS 虚拟化技术。
  • 2004 年,Solaris 10 支持 Solaris Zone,第二个商用化的 OS 虚拟化技术。
  • 2005 年,OpenVZ 发布,是非常重要的 Linux OS 虚拟化技术先行者。
  • 2004 年至 2007 年,Google 内部大规模使用 Cgroups 等的OS虚拟化技术。
  • 2006 年,Google 开源内部使用的 process container 技术,后续更名为 cgroup。
  • 2008 年,Cgroups 进入了 Linux 内核主线。
  • 2008 年,LXC(Linux Container)项目具备了 Linux 容器的雏型。
  • 2011 年,CloudFoundry 开发 Warden 系统,一个完整的容器管理系统雏型。
  • 2013 年,Google 通过 Let Me Contain That For You (LMCTFY) 开源内部容器系统。
  • 2013 年,Docker 项目正式发布,让 Linux 容器技术逐步席卷天下。
  • 2014 年,Kubernetes 项目正式发布,容器技术开始和编排系统起头并进。
  • 2015 年,由 Google、Redhat、Microsoft 及一些大型云厂商共同创立了 CNCF,云原生浪潮启动。
  • 2016 年至 2017 年,容器生态开始模块化、规范化。CNCF 接受 Containerd、rkt 项目,OCI 发布 1.0,CRI/CNI 得到广泛支持。
  • 2017 年至 20xx 年,容器引擎技术飞速发展,不断技术升级,新技术不断涌现...

https://mp.weixin.qq.com/s/ccFkJJz97KcuXdO3r5zdXA

4 个 Kubernetes 安全用例

组织正在将其 Kubernetes 应用程序快速转移到生产中,以加快功能速度并推动数字化转型和业务增长。以下分享了 4 个 Kubernetes 安全用例,希望帮助组织步入正确轨道。

Runtime 威胁检测和响应

Runtime 是客户最担心的生命周期阶段,很多的人认为 Runtime 检测是“必不可少的”。此阶段的安全目标是以自动化和可扩展的方式检测并响应恶意活动,同时最大程度地减少误报。Kubernetes 提供了有关镜像和 Deployment 的丰富声明性数据,在评估 Runtime 时提供了上下文。利用此上下文可以更准确地区分简单异常和真实威胁,并使用 Kubernetes 本地执行功能以自动化和可扩展的方式缓解 Runtime 威胁。

合规

DevOps 依靠自动化来进行持续改进,组织需要遵守行业合规性要求,要能够从框架(包括 Docker 和 Kubernetes 的 CIS 基准测试、PCI、HIPAA 和 NIST SP 800-190)中显示哪些集群、节点、命名空间与容器和 Kubernetes 环境中相关的所有单个控件兼容。

配置管理

配置错误会给容器和 Kubernetes 带来最大的安全风险,在过去 12 个月中,有 67% 的调查受访者经历过 K8s 配置错误。在当今由 DevOps 驱动的环境中,配置管理必须尽可能自动化和简化,以免减慢应用程序开发和部署的速度。它应该是全面的,涵盖容器、Kubernetes 及其所有可配置组件,包括:

  • RBAC
  • secret
  • 网络策略
  • 权限等级
  • 资源限制、要求
  • 只读根文件系统
  • 注释、标签
  • 灵敏的主机安装和访问
  • 镜像配置

网络细分

容器带来了独特的网络挑战,因为容器在节点和群集(东西流量)和外部端点(南北流量)之间相互通信。Kubernetes 提供了启用网络分段的内置功能。使用 Kubernetes 的分段功能可确保安全性和 DevOps 能够查看一致信息来源并采取行动,以限制访问并减小影响范围。

为什么要内部 Kubernetes 平台

内部 Kubernetes 平台为工程师提供了直接访问他们可以在预生产阶段使用的 Kubernetes 开发环境的权限。

企业为什么要建立内部平台

Kubernetes 内部平台涵盖了许多方面,为工程师构建内部 Kubernetes 平台非常具有挑战性。这样做有很多价值,也需要面临许多压力:

对于本地环境,应用程序过于繁重

在许多情况下,应用程序会变得太大而无法在本地运行,因此从本地开发环境迁移到云中的 Kubernetes 开发环境非常有必要。

将自主与重点相结合

使用内部 Kubernetes 平台,开发人员可以自由、自主地工作,同时不必在乎集中解决的操作任务。管理团队可以从中受益,他们专注于平台并为其他工程师提供支持,而不必关心每个单独的环境。

简化 Kubernetes 工作流程

内部 Kubernetes 平台还包含一些开发工具,有助于标准化 Kubernetes 工作流,因此一些没有 Kubernetes 经验的工程师也可以使用它。这有助于平台的采用过程,并支持开发人员更多地了解 Kubernetes。

节省成本

内部 Kubernetes 平台是一种非常经济高效的解决方案,可以为工程师提供 Kubernetes 环境,因为可以充分利用计算资源,并且工程师也提高了工作效率。

内部 Kubernetes 平台的重要因素

  • 提供出色的开发人员体验:即使平台供内部使用,但仍然拥有“客户”,而这些客户就是组织中的开发人员。
  • 衡量参与度并与用户沟通:了解用户非常重要,因此我们必须不断与开发人员进行交流。
  • 衡量成本和平台性能:我们还应该衡量平台是否可靠运行,并确保可以快速解决问题。进行备份和全面测试对此非常有帮助。
  • 改善平台和开发人员的经验:从前面的因素可以看出,构建内部平台是一项持续的工作。
  • 开发经验比技术细节更重要:对于开发人员而言,最重要的是他们可以有效地使用该平台,因此提供平台的工程师应该以用户为中心。

云原生开源软件的威胁

开源的使用已成为现代发展过程的关键部分。它可以帮助每个人以前所未有的速度构建软件,但同时也使开发人员面临在不知不觉中将安全漏洞引入其开发的应用程序的风险,并使自己的组织或客户处于危险之中。

开源的兴起

在过去的几年中,开源取得了巨大的增长。如今,超过 250 万开发人员在 GitHub 等平台上为开源做出了贡献,GitHub 是世界上最大的开源社区。它托管着数百万个开源项目,其中一些项目不仅具有成千上万的贡献者,而且还充当着许多其他存储库的依赖项。开源带来了很多好处,但同时也给组织带来了新的潜在的严重安全威胁。

为什么开源会带来安全风险?

开源软件是免费的,任何人都可以使用、探索和增强。它由大量贡献者开发和维护,它提供了源代码的无限访问,以便用户可以根据需要对其进行修改。像任何软件一样,开放源代码是由人类编写的,因此存在错误。

开源漏洞的主要原因在于其公开性质。许多开发人员几乎不需要参与审核。开源是开放的,有时是一些不负责任的贡献者构建的。他们经常没有用于处理新更新和修补程序的标准化流程,并且开放源代码项目通常缺少查找和修补错误的资源。

在云原生环境中,容器在开源问题之外又增加了另一层风险。例如,发现来自 Docker Hub 的 86% 镜像被配置为以 root 特权作为默认值运行。这扩大了攻击面,并为特权升级提供了一种简便的方法。如果攻击者设法利用以 root 用户身份运行的容器中的一个开源组件中的漏洞,那他们可以完全访问主机和在其上运行的应用程序。

我们镜像看到有针对云原生环境软件供应链的攻击,将隐藏的恶意软件放置在可公开获得的容器镜像中。就在不久前,Aqua 网络安全研究团队 Team Nautilus 发现,容器开发人员使用的 SaaS 服务、GitHub、Docker Hub 等,被攻击者利用进行加密货币挖掘。

本周 K8s 开源项目推荐

pomerium

  • 这是一种身份识别代理,提供了跨云和本地部署一致的身份验证、授权、工具和审核。
  • github.com/pomerium/pomerium

porter

  • 这是为 Kubernetes 裸机集群设计的开源负载均衡器。
  • github.com/kubesphere/porter

kdo

  • 它是一个命令行工具,使开发人员可以在实际的部署环境中运行、开发和测试代码更改。
  • github.com/stepro/kdo

checkov

  • 它是用于基础结构即代码的静态代码分析工具。
  • github.com/bridgecrewio/checkov

version-checker

  • 它可以用于观察集群中运行的镜像的当前版本以及上游可用的最新版本。
  • github.com/jetstack/version-checker

ipvs-node-controller

  • 这是 kubernetes 控制器,可解决IPVS代理模式下的外部 IP 问题。
  • github.com/kakao/ipvs-node-controller