导语
DevOps能否在Kubernetes世界中生存？最简洁的答案是不，但是暂时还没有敲响DevOps的丧钟。
正文
Kubernetes（K8s）是容器化平台即服务（PaaS）的核心引擎。当企业使用PaaS时，他们会将操作（ops）功能转移给PaaS提供者，作为自动化重复任务的一种方式。Kubernetes引入了更大的灵活性和自动化性。但是，K8s的优化需要声明和配置工作。
那么，哪里让DevOps成为我们所知道的呢？
Kubernetes的采用
当今，所有企业都在拥抱数字化转型，以实现持续增长并获得竞争优势。Kubernetes等云原生技术可提供必要的自动化，可视性和控制能力，以大规模和高创新速度管理应用程序。
Kubernetes提供了构建功能，其中包括管理、监视、更新和升级集群等操作功能，管理资源处理现在通过代码完成。
Kubernetes允许用户配置其所需的部署状态。Kubernetes控制器不断检查部署的状态，并尝试将其从当前状态变为所需状态。现在，诸如发布和回滚，按比例放大和按比例缩小等任务已实现自动化，可以指定资源限制和条件。此外，污点和公差可在运行时优化部署。
Istio等技术与Kubernetes集成在一起，以进一步简化和自动化复杂的操作任务，例如发现、流量管理、监视和服务推出。
传统上，DevOps是绑定应用程序开发和IT基础架构的“胶水”。使用Kubernetes，企业现在可以使用声明性API动作来完全控制应用程序的开发基础架构。那么，Kubernetes是“新的基础设施粘合剂”吗？如果是，那会使DevOps变得多余吗？不完全的。
DevOps的演变
DevOps不再仅仅是持续集成和持续交付（CI/CD）。基于Kubernetes的云原生应用程序部署，为DevOps的角色发展和扩展提供了巨大的机会。机会是从单纯的“开灯的人”发展为建筑师，从而实现战略业务成果。
对于一个观察者来说，在部署管道中以及在部署和操作过程中，由Kubernetes领导的自动化似乎可以最大程度地减少操作任务。更深入地了解揭示了为什么不是这样。尽管可以使用Kubernetes配置灵活地部署应用程序，但是了解副本、规模、污点和容忍度并不是许多开发人员的首要考虑。
好的配置需要平衡关键因素，例如更快的部署时间，优化的资源使用，更高的可靠性和更快的故障解决方案，这些都是推动DevOps演进的催化剂。此外，DevOps的作用还将扩大，以包括与团队（例如负责安全性的团队）进行复杂的跨功能协作，以帮助在Kubernetes环境中提供更好的安全性。
DevOps向DevSecOps的过渡
在Kubernetes环境中，安全性不能成为孤岛。实际上，如今，DevOps和安全性越来越受到重视。安全实践正逐渐成为软件开发生命周期的一部分。DevSecOps打破了Security和DevOps团队之间的传统孤岛。在Kubernetes环境中，DevSecOps现在将在操作部署之前对配置进行认证，确保安全性并实现合规性。换句话说，“对工厂进行认证，而不是对工厂建造的每个组件进行认证。”
例如，这可能包括在构建映像后立即对其进行漏洞评估，确保仅部署经过认证的映像，完全在部署容器映像之前自动检查部署清单（即，在检查代码后立即针对已知的错误配置对基础架构即代码（IaC）模板）。
企业必须解决以下五个用例，为Kubernetes环境中运行的云原生应用程序提供全面的安全性：
1.丰富的发现和基于风险的分类：这是发现所有服务并帮助确定优先级和分类的能力，以使组织更加意识到风险。这是至关重要的，因为有大量的资源，其中许多是临时资源。
2.防止配置漂移和开源软件漏洞：能够检测容器生态系统组件中的所有漏洞，包括容器映像，注册表和K8s控制面板本身。这也与管理K8控制平面和运行中的容器集群的安全状态的能力有关。
3.最小化攻击面并防止升级：这是一种在基于资源使用情况的环境中执行基于应用程序或服务的分段的能力。这将在容器级别创建一个安全区域，其权限基于所学行为。
4.将Security Operations Center（SOC）扩展到云本机应用程序：这是驱动对云本机威胁进行检测和修复的能力。
5.访问治理和合规性：这是管理所有用户和应用程序组件的身份和访问权限的能力，以创建和管理最低特权的模型。
除上述用例外，该系统还允许持续监控和快速反馈，这使DevSecOps能够更快地交付安全代码。
Kubernetes为DevOps环境带来了显着的敏捷性、自动化和优化。这将是DevOps打破现有孤岛并发展为实现业务成果的战略功能催化剂。
渠道激活专题文章推荐：
01
进入2020年，新冠状病毒疫情突发，云计算市场渠道招募和拓展工作也受到了一些影响，甚至在业界，已经很少人再谈及渠道一词了。但，绝不会永远这样。
02
从开源云计算厂商此前进行的渠道拓展来看：首先，整个渠道拓展体系从不是随意建立，而是需要根据不同区域市场情况，以及渠道伙伴拥有的不同技术能力来进行内容宣导。其次，渠道内容的设计和组织也不是自由的，要根据行业客户实际场景需求来做相应输出。
03
开源云计算厂商通常会构建大量的产品线和复杂的解决方案体系，这就需要借助渠道伙伴的力量面向最终用户输出，以此保障最佳客户体验和售后支持。因此，渠道伙伴在开源云计算市场拓展方面的能力强弱，关系到厂商整体的市场战略实施效果。
04
在近几年，很多开源云计算厂商携手渠道伙伴共同应对云化时代的变化与挑战，加速行业云计算转型。实际上，这一调整意味着开源云计算厂商将更加重视与伙伴的生态合作，并鼓励合作伙伴发挥各自优势，协同为客户传递价值。但开源村也发现，也还有很多开源云计算厂商没有成功建立起自己的渠道体系。
05
云化时代到来之际，行业客户业务场景会根据云化转型的节奏进行调整。开源云计算服务提供商在此时的作用是帮助渠道伙伴学会借助平台之力，满足行业客户的真实需求。这是相比友商而言，更具竞争优势之处。优质的平台，会助力渠道伙伴获得更多行业用户的信任。
06
对于开源云计算厂商而言，如果希望在抢滩新基建上构建差异化竞争优势，具备高超的售前技能、售后体验，并拥有创新的技术服务能力与解决方案构建能力是实有必要的。巧了，这些都与渠道构建息息相关。
07
私有云凉了么？当然没有！连当事人都出来辟谣了！私有云需不需要渠道？当然需要！没有渠道，开源云厂商怎么为私有云产品、营销和销售提供售前支持？没有渠道，开源云厂商怎么能够既少花钱，又能实现高效、便捷、快速的售后服务？
08
开源云计算市场竞争激烈、用户需求多变，对于怎样带货，怎样推动市场增长，也成为让很多厂商头疼的事。开源村觉得，开源云计算渠道虽不比网红，但此时应当勇于站出，全面激发和表现出自身的“带货”实力。
09
有报道称，一名开发者用两年的业余时间开发并维护了一个开源项目因为微软的剽窃而被迫中止。有网友评论说，这也是很多大公司的通用策略，比如组织技术人员与之交流，然后套取有用信息，然后发展自己的产品，这在中国叫做“偷艺”。事实上，设想一下，如果这个项目能够早日产品化，并且建构好了一套成熟的市场分发渠道，或许形势就会完全不同。
本文分享自微信公众号 - 开源村OSV（osvosvosv）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
