Container周报第113期：德国快时尚商大谈如何管140座云端K8s丛集而Google的Knative决定引起两位K8s创办人不满

10/4~10/16精选容器新闻#大规模K8s管理 #KaaS #企业实例
德国快时尚网站Zalando如何管理140个K8s丛集？

德国快时尚网站Zalando内部有200个开发团队，为了支援上千名内部开发者所需的基础架构资源调度，他们的K8s团队自行打造了一套KaaS服务（Kubernetes as a Service），来管理目前部署在AWS上的140多个K8s丛集。

Zalando建置这套KaaS有几个目标，全面自动化维运、不养宠物丛集、高可靠度、自动缩放。在架构上，Zalando採取了成对调度策略（provision in pairs），一次都会同时部署线上环境和非线上环境的丛集。每个丛集都有一个专属、独立的AWS帐号（意味着目前有140多个帐号），可建立独立网路环境的K8s丛集，但是所有帐号的配置工作，都统一由一套客製化Python工具来执行。Zalando也将整套线上环境的丛集配置放上GitHub来进行版本控管，并尽量使用AWS提供的CloufFormation範本快速建立应用程式建置架构。

另外，不论Master节点或Worker节点都用同一套自製AMI映像档，採用Ubuntu和一套内建了Zalando所有在K8s需要的Docker映像档。预先定义AMI有助于缩短开机时间来加快丛集扩充工作。另有一个利用PostgreSQL来基础所建立的集中式Cluster Registry，所有工具都可以透过这个Registry的REST API来查询。

＃CNCF #Knative #开源专案经营
Google决定不将Knative专案捐给CNCF或任何基金会，引起K8s创办人不满！

由Google发起的开源无伺服器专案Knative将不会捐给CNCF基金会。Google Cloud Run产品经理Donna Malayeri在十月初时，在Knative社群宣布了这项消息。她指出，Knative专案成立之初，就一直在讨论是否将专案捐出去给基金会，例如像是负责管理K8s的CNCF。不过，Google最近决定，Knative专案将不会捐给任何基金会，仍会继续开源，但将由指导委员会继续负责管理。这也意味着，Google将继续主导Knative未来的发展大权。目前Knative指导委员会成员有7人，其中4人来自Google，另有来自Pivotal、IBM和红帽各一人。

不过，Google这项宣布后续也引起其他科技业者或社群领袖的批评。例如任职于微软Azure的Kubernetes专案创办人Brendan Burns和任职于VMware的K8s另一位创办人Joe Beda都跳出来大表失望，质疑此举将有损于Knative的开放性。Joe Beda甚至直指，Istio也有同样的情况。Donna Malayeri表示，未来几周将会公布指导委员会的参加办法，让更多社群和业者可以参与，另外也会公布更详细的指导委员会职务和分工。

#CI/CD #K8s导入经验 #GitLab
GitLab经验：导入K8s前最好先做CI/CD，釐清自家应用程式的架构

GitLab派送工程经理Marin Jankovski最近一场演讲中，分享了他们刚把Registry服务搬上K8s平台上，过程中体会的经验。他认为，拥抱K8s时，不只需要调整线上正式系统，也需要改变工程师的思维。他建议，拥抱K8s之前，工程师必须要具备CI/CD观念，更聚焦程式码的品质管理和更严格的功能规画，甚至，他认为，与其花时间导入一套完善的CI/CD平台，不如先利用现成简单的工具，快速建立一个CD系统，快速找出现有应用程式的基础架构。他解释，CI自动化会让应用程式的任何弱点都更凸显，若先改善应用程式的架构体质，有助系统全套迁移到K8s。

而在GitLab的经验上，Marin指出，拥抱K8s前先导入CI/CD，可以带来另一个好处是，开发者对「完成」的定义改变了，过去开发人员只要通过程式码审查就是完成，但这没有考虑到程式码部署到不同环境中随时间变化的情况。「既然现在可以快速完成部署，就没有理由忽视新异动在测试和正式环境的运作。」所以，像GitLab开发团队每次部署后，会多等一天观察，程式码合併后的影响。

#HANA #K8s #SAP
SAP要让HANA资料库未来能原生支援K8s丛集，年底前推出

SAP在年度TechED技术大会上宣布，SAP HANA记忆体式资料库将可以原生支援K8s丛集，预计最快今年圣诞节年正式推出。SAP技术长Juergen Mueller表示，SAP的HANA云已经演化成微服务架构的服务，这也让SAP HANA更容易缩放规模，下一步就是在HANA资料库上也採用微服务来强化扩充性。为了让SAP产品更容易跨多云部署，SAP宣布，当HANA资料库原生支援K8s之后，企业将可以在这个基础上来部署SAP所有的软体。不过，因为另外，SAP也表示，将继续强化对Cloud Foundry的PaaS框架的支援和贡献。

#应用程式部署 #云端原生 #CI/CD
Puppet推出Nebula专案简化云端原生应用程式部署工作流程

老牌自动化组态管理软体供应商Puppet推出了新专案Nebula，用来简化云端应用程式的部署工作，其提供了一个工作流程建置器，可以让管理员定义部署应用程式的每个步骤，管理软体元件的载入顺序到硬体的配置等工作。Nebula提供了建置、配置和部署云端原生应用程式的单一平台，目前在公开测试的阶段，专注可改善生产力的功能，内建範例工作流程，可以帮助开发者开始部署工作，并支援超过20种热门的云端部署工具，包括Terraform、CloudFormation、Helm以及Kubectl等。Puppet强调，使用Nebula可以简单地编写部署工作流程，Nebula与原始码控制储存库深度整合在一起，开发者不再需要编写混乱的bash脚本。

#EKS #Windows容器 #Kubernetes
Amazon EKS现在正式支援Windows容器

AWS在其Kubernetes服务正式推出支援Windows容器功能，使用者现在可以在Windows伺服器上安装应用程式，并且与其他Linux应用程式一同部署在Kubernetes上，这项功能同时提供系统日誌、效能监控以及程式码部署工作管线。Kubernetes在今年3月底发布1.14版本时，开始支援Windows容器，让使用者可以将Windows节点加入工作节点（Worker Node）或是进行Windows容器调度。AWS提到，目前在丛集中至少需要有一个Linux节点来支援Windows节点和Pod网路，AWS建议用户可以使用两个Linux节点来实现高可用性。另外，Windows容器通常比Linux容器大，因此下载和启动的时间都会更久。

#容器管理平台 #Rancher #Istio
Rancher释出2.3新版，也开始支援Windows容器

随着Kubernetes 1.14版支援Windows容器格式后，越来越多通用型容器管理平台正式支援1.14版，也同时支援了Windows容器。例如容器管理平台业者Rancher Labs最近宣布旗下K8s管理平台也开始支援Windows容器，而也可整合到服务网格软体Istio，新版更提供了更多K8s丛集建置範本，例如可重複使用的Kubernetes配置範本。目前Rancher 2.3版可支援到Kubernetes 1.15版和Docker 19.03版。

责任编辑：王宏仁

更多容器新闻

抢攻企业DevOps小团队，HashiCorp推出5人免费版Carbon Relay推出靠K8s跑AI应用的优化工具Red Sky Ops