Container周报第138期：德国铁路公司拥抱GitOps关键大公开，OCI容器映像档分散规格1.0出炉最新消息

图片来源:

德国铁路公司

4/16~5/16 精选容器新闻

#GitOps #德国铁路
德国铁路公司如何拥抱GitOps，靠单一K8s命名空间结合自动化工具来实现维运免手动

德国铁路集团旗下DB Systel公司是德铁集团的IT团队，负责所有全集团数位转型和IT战略。最近在KubeCon欧洲场研讨会中，DB Systel云端首席架构师Schlomo Schapiro首度公开了德铁集团拥抱GitOps，让IT战略更高度自动化的经验。他强调，走向GitOps是DevOps实践中自然演化的结果。

为了数位转型，许多企业将流程自动化列入IT的重要战略之一，例如想要建立更多标准化流程、减少不必要流程、减少维运和变动的成本、拥抱云端运算，全面都自动化等。他坦言，但要做到这些目标，实务上有很多挑战，因为IT需求暴增，所有流程都要整合API、IT复杂的成长超过IT人力的成长，更多IT人力投入业务部门的优化（BizDevOps）、但对IT法遵要求却越来越多，又要求要善用云端来创新。“不管IT团队怎么努力，似乎永远都无法跟上需求。”他表示。

对IT部门来说，他指出，IT的期待是，聚焦在产品和服务，打造最好的服务，使用最好的工具，更容易实现法遵，和其他团队没有相依性而被拖累。“这不是无解难题，必须同时考量组织面和技术面，将所有的问题，都视为自动化挑战。”他指出。

德铁IT整合组织框架和技术框架，以人为核心来聚焦6大目标，简化政策、法遵可接受的作法、工具标准化、法遵自动化预算、政策程式码化（Policy as Code）以及免手动维运（Hands-Off Operations）。“这其中最关键的IT策略就是免手动维运，”他强调。这一项正是德铁发展GitOps的核心原则。

为何不讲维运自动化而要讲免手动维运，他强调，因为这不只是技术议题，而且还是组织文化的议题，就像敏捷不只是工具，也要养成文化面的风气。许多企业发展各种持续整合、派送自动化，“这只是CI维运，需要结合GitOps，进一步来建免手动维运的文化。”

他指出，免手动维运思维包括了正式环境禁止人工介入，不论开发或维运团队都预设零产品权限（不能插手线上环境），全力发展自动化（法遵治理、更新升级、复原等都自动化）、测试驱动所有事、工具标准化，“GitOps工具就是为了实现免手动维运。”实务上，德铁利用K8s来执行各种应用，透过单一K8s命名空间，来管理本地端K8s丛集和云端基础架构环境，再搭配ArgoCD、Flux第二版来落实GitOps。

#K8s开发 #除错工具
K8s应用除错工具Pixi宣布开源，可快速建立效能追踪机制

知名美国云端监控服务商New Relic最近宣布开源释出了一款K8s应用除错工具Pixi，采Apache 2.0授权。Pixi提供了一套建立应用程序效能追踪，监测矩阵、网络层资料搜集的仪表板工具，也定义了一套自动搜集各种效能数据的基础设计，可以完全透过脚本程式来存取所搜集的各种资料。运作架构上，采取丛集内边缘运算架构，可将远端监测所需的各种资料储存在K8s丛集内而不用回传来避免遭拦截。主要元件包括了丛集内资料搜集和查询引擎Vizier，应用程序和用户管理后台Pixie Cloud平台。

#Anthos #跨云平台
GCP混合云平台Anthos推出1.7版，终于支援Windows容器也可整合跨公云日志

日前GCP推出新版混合云平台Anthos 1.7版，主要增加了三大特性，第一是云端日志机制Cloud Logging可以支援Anthos on AWS，等于监测矩阵可以跨本地端、GCP环境和AWS环境来追踪了。另一个新特色是终于支援Windows容器，可派送Windows容器到vSphere环境中。Anthos配置管理机制ACM也支援更多种丛集类型，包括EKS 1.19、AKS 1.19、OpenShift 4.5、KIND 0.10和Rancher 1.2.4的丛集。第三项新特色是工作量身份识别机制（Workload Identity）可以支援本地端部署或AWS环境的工作量识别管理了，可以用来确保在不同混合云环境中执行服务时，能有适当的权限控管。

#GitOps #OpenShift
瞄准开发部署自动化风潮，红帽OpenShift正式推出CI整合机制和GitOps功能

最近红帽宣布旗下企业级K8s平台OpenShift正式推出CI整合机制OpenShift Pipelines，以及用于应用程序部署与配置自动化的OpenShift GitOps功能。OpenShift Pipelines功能使用了开源的持续派送基础专案Tekton，可自动派送云端K8s原生应用，到K8s丛集上的POD环境上部署。因此也可以支援可使用Tekton CLI命令列的IDE开发工具，例如Visual Studio Code和IntelliJ的Tekton外挂。而OpenShift GitOps功能则源自另一个CNCF开源专案Argo CD，可建立一个以Git PR指令来驱动的自动化流程，可跨不同K8s丛集来部署和配置应用程序。

#容器交换 #OCI
OCI容器映像档分散规格1.0正式出炉，跨平台交换容器映像档也有标准作法

容器标准推动组织OCI最近正式宣布，容器分散规格OCI Distribution Specification正式释出1.0版。这是一个源自Docker Registry HTTP API V2的容器映像档交换协定，用来规范不同容器储存库上推和下拉映象档的方式。
OCI技术监督委员会主席Phil Estes指出，先前定义的runtime规格界定了容器的定义和执行方式，容器映像档规格定义了封装的方式，而现在这个分散规格的订定，有助于建立一个在各种储存库和runtimePhil Estes工具间传递容器的标准作法。Docker技术长Justin Cormack更直言这是另一个里程碑的重大进展。

#IaaS #Pulumi
基础设施即程式码工具Pulumi大改版，3.0也能原生支援Azure和GCP

基础设施即程式码工具Pulumi 3.0带来非常多的功能更新，包括了正式加入Pulumi自动化API，让开发者可以在应用程序中嵌入Pulumi功能，而且除了AWS，Pulumi也开始原生支援Azure和Google云端平台，在语言的支援上，Pulumi试图整合多语言元件，让各种语言的套件能够互通。开发者可透过自动化API将Pulumi功能，嵌入到自己的应用程序中，因此可以不使用命令列工具或是撰写脚本来操作CI/CD，改用Pulumi部署引擎，更多元的方式控制工作流程。Pulumi自动化API支援多种语言，包括TypeScript/JavaScript、Python、Go以及C#。

#K8s开发 #OpenShift
为简化K8s开发，红帽发布OpenShift开发者沙盒

红帽推出了一款新开发工具称为OpenShift开发者沙盒，可以在有预配置开发者工具的多租户丛集中，提供私密的OpenShift环境，由于基础设施和工具紧密整合，因此能让开发人员安全地设计和建构新应用程序、添加新服务，还能从程式码创建容器或Dockerfiles等。沙盒中的预设工具，包括了一组Helm Chart以及红帽建置映像档、s2i建置工具以及CodeReady Workspaces。红帽也更新了一系列工具，这些更新建立在OpenShift GitOps和OpenShift Pipelines之上，因此IT团队可以利用GitOps工作流程，来配置丛集和交付应用程序，并完全控制开发团队的交付工作管线、套件和存取控制。

#生命周期管理 #云端原生应用
云端生命周期管理系统Airship大进展，2.0新推更方便的命令列新工具

新版Airship 2.0提供了宣告式的命令列工具Airshipctl，让用户组合和调度云端原生建置模组，来供应或是管理Kubernetes，以及其衍生的软件堆叠。透过直觉且简单易用的界面，方便地操作其他开源专案，包括Cluster API、Metal Kubed、Kustomize和kubeadm等。Airshipctl可以从版本化的Git存储库，以Kubernetes资源档案的形式，撷取宣告式意图，并且透过与Kustomize的整合，Airshipctl能将行动（Action）的任意部分，转出为文件包。新版能支援各种基础设施后端和操作系统，从Azure、Google等公有云，到虚拟机器Openstack，甚至是裸机环境。

#GCP #Azure #AWS
GCP容器相关服务的竞争产品是什么？一张表快速比较三大云端容器服务

GCP、AWS和Azure大比对公有云的容器相关服务越来越多，种类也很杂，不只是纯容器服务，有些列在资安服务，有的则属于无服务器服务，不同业者对于类似功能的服务，也各有不同的命名，更难比较同样功能的服务有何差异，最近Google更新了一份与其他两家公有云服务竞争对手的产品对照表，虽然这是Google观点的产品表，意味着会完整列出GCP自家功能，但不一定会列出对手的服务，对手可能也不见得同意GCP的分类，不过，这倒是一份可以一窥GCP自家产品有哪些竞争服务，可供有意采用的企业产品评估之用，Azure也有类似的产品比较表可参考。整体来看，Google与容器应用相关的服务，近来以容器资安和无服务器应用类型上的新增服务较多，这也是GCP近来的产品发展重点。

#GPU #GKE
GKE现让多执行个体共享单一GPU

Google更新其Kubernetes服务GKE，提供多执行个体可共用单一Nvidia GPU的功能。Nvidia A100 GPU最多可以划分成7个执行个体，每个执行个体都有独立的高带宽内存、快取和运算核心，每个执行个体可以分配给1个容器，每个A100 GPU最多可以分配7个容器，另外，多执行个体GPU间由于采用硬件隔离来增加了安全性，也替所有GPU上执行的容器提供一致且可预测的QoS。

责任编辑：王宏仁