近日，好雨科技与龙芯中科共同进行了好雨科技旗下云帮（Rainbond）PaaS平台与龙芯中科最新龙芯3B3000芯片的测试认证。
好雨科技作为云计算时代的PaaS服务商，立足于“数字化业务驱动企业价值增长”，打造“以应用为中心”的PaaS平台，管理企业数字化业务的“开发、架构、交付、运维”应用全生命周期。
龙芯中科定位于面向国家信息化建设的需求，面向国际信息技术前沿，以创新发展为主题，以产业发展为主线，以体系建设为目标，坚持自主创新，掌握计算机软硬件的核心技术，为信息产业及工业信息化的创新发展提供高性能、低成本、低功耗的处理器。
持续改进：
项目可持续性不仅仅与功能有关。许多SIG一直致力于提高测试覆盖率，确保基础功能持续可靠，核心功能持续稳定。
可扩展性：
Kubernetes社区一直致力于支持可扩展性。1.15版本发布周期中包含更多关于CRD和API Machinery的工作。此次周期中的大多数增强功能来自SIG API Machinery及相关领域。
更深入了解此次版本主要功能：
在CRD新开发的主题是围绕者数据一致性和原生性。用户考虑重点不会放在是CustomResource还是使用Golang原生资源。在下个版本或后续版本中，将会升级CRD和admissio webhooks 到GA版本。
在这个方向上，社区重新考虑了CRD中基于OpenAPI的验证模式，并且从1.15开始，我们根据称为“structural schema”的限制检查每个资源。这基本上强制执行CustomResource中每个字段的非多态和完整类型。未来需要定义structural schema，尤其是所有新功能，
更多信息可以在这里了解：
https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#specifying-a-structural-schema
beta: CustomResourceDefinition Webhook Conversion
从 1.14版本起，CRD持续在多个小版本中作为beta存在。使用Kubernetes 1.15，他们可以即时在不同版本之间进行转换，就像用户长期使用原生资源一样。CRD的转换是通过集群管理员在集群内部署的webhook实现的。此功能在Kubernetes 1.15中被升级为beta版，将CRD提升到一个全新水平。
beta：CustomResourceDefinition OpenAPI Publishing
kube-apiserver在openAPI/V2上已经为原生类型提供了OpenAPI规范很长一段时间了，它们被许多组件使用，特别是kubectl客户端验证，kubectl解释和基于OpenAPI的客户端生成器。
用于CRD的OpenAPI发布将以Kubernetes 1.15作为测试版提供，但仅适用于structural schemas。
beta: CustomResourceDefinitions Pruning
Pruning是自动删除发送到Kubernetes API的对象中的未知字段。如果未在OpenAPI验证模式中指定字段，则该字段是未知的。这既是数据一致性又是一个和安全相关功能。它强制只将CRD开发人员指定的数据结构持久保存到etcd。这是kubernetes原生资源的行为，也可用于CRD，从Kubernetes 1.15开始为beta。
alpha: CustomResourceDefinition Defaulting
CustomResourceDefinitions默认值支持许可。使用defaultOpenAPI验证模式中的关键字指定默认值。在发送到API的对象中以及从etcd读取时，为未指定的字段设置默认值。
对于structural schemas，从Kubernetes 1.15开始，默认值为alpha。
SIG Cluster Lifecycle在1.15版本周期中，主要任务是加强Kubernetes安装、升级、配置稳定，在1.15版本中对生产环境使用，bug修复等高可用性被优先考虑。
kubeadm是集群生命周期构建工具，它的功能稳定性得到进一步提升。kubeadm高可用性（HA）升级到beta版本，允许用户使用熟悉的kubeadm init和kubeadm join命令来配置和部署HA控制平面。社区专门设计了一个全新的测试套件，以确保这些功能随着时间的推移保持稳定。
证书管理在1.15版本中变得更加强大，kubeadm现在可以在证书到期之前，无缝升级所有证书（升级时）。有关如何管理证书的信息，请查看kubeadm文档。
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha/
kubeadm配置文件API在1.15中从v1beta1升级到v1beta2。
最后，kubeadm 喜提单独 logo，祝贺！
在Kubernetes v1.15中，SIG Storage继续致力于将内部的卷插件迁移到Container Storage Interface（CSI）。SIG Storage致力于将CSI与树内功能进行校验，包括调整大小，内联卷等功能。SIG Storage在CSI中引入了新的alpha功能，这在之前版本Kubernetes Storage子系统中尚不存在，如卷克隆。
卷克隆使用户可以在配置新卷时将另一个PVC指定为“DataSource”。如果底层存储系统支持此功能并在其CSI驱动程序中实现“CLONE_VOLUME”功能，则新卷将成为源卷的克隆。
其他值得注意的新功能：
lKubernetes Core中支持go模块
l继续准备云提供程序提取和代码组织。云提供商代码已移至kubernetes / legacy-cloud-providers，以便以后更容易删除和外部使用。
lKubectl get和describe现在适用扩展
lNode节点现在支持第三方监控插件。
l用于计划插件的新计划框架现在是Alpha
l钩子命令的 ExecutionHook API 现在是Alpha。
l对extensions / v1beta1，apps / v1beta1和apps / v1beta2 API的持续弃用; 这些扩展将在1.16退出！
更多内容可查看：
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#kubernetes-v115-release-notes
新版下载地址：
Kubernetes 1.15可从GitHub下载。
https://github.com/kubernetes/kubernetes/releases/tag/v1.15.0
开始使用Kubernetes，请查看这些交互式教程。
https://kubernetes.io/docs/tutorials/
您也可以使用kubeadm轻松安装1.15 。
https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/
发布团队
新版的发布，是数百名技术和非技术个人共同努力结果，特别感谢Pivotal Software高级技术项目经理Claire Laurence领导的发布团队。发布团队中的38个人协调了发布项目的各个方面，从文档到测试，以及验证和功能完整性。
随着Kubernetes社区的发展，我们的发布过程代表了开源软件开发协作的一个惊人演示。Kubernetes社区持续有新用户加入。这种增长创造了一个积极的社区生态，更多的贡献者提交代码，创建一个更有活力社区， 迄今为止，Kubernetes拥有超过32,000名贡献者，并拥有超过66,000人的活跃社区。
作者：1.15 发布团队
译者：曹辉
原文地址：
https://kubernetes.io/blog/2019/06/19/kubernetes-1-15-release-announcement/
五年前Kubernetes诞生，当时它还很小，功能有限，只有少数人参与到它的创建。现在，五年之后，kubernetes已经获得了长足的发展，如果是孩子的话，五岁的时候可能才刚上幼儿园，但是kubernetes已经作为工作负载的核心为从初创公司到全球金融机构各种各样的领域提供服务。
kubernetes的成功离不开成千上万贡献者的帮助，kubernetes社区从诞生之初的少数开发者到如今数千名贡献者，只用了短短五年的时间。而如果我们将meetup，文档，版本管理，以及更广泛的社区支持囊括进来的话，贡献者会更多。当然，随着项目的迅速发展壮大，社区也在积极的变更组织方式，以支持其继续取得成功。一个项目能够达到这样的规模并且能继续成功运作，这是一项了不起的成就。
五年后，值得思考kubernetes取得的成就，它是最大的开源项目之一，它在数千名来自不同公司的工程师团队中保持快速发展，它已经合并了成千上万的commit且依旧保持高质量版本的定期发布。能做到这一点，对一个公司来说也是不小的成就，更难能可贵的是，这是由来在来自不同公司的成千上万开发者（其中许多人甚至还在学校）的驱动下完成的。这是社区所有人努力的结果，他们每天辛苦工作，以确保所有ci都是绿色的，版本能够得到修补，安全能够得到维护。对于很多人来说，这项工作通常是乏味的，有时是情绪化的工作，每一位贡献者都应该得到我们最深切的敬意。
当然，kubernetes的故事不只是一个社区的故事，它还是一个技术的故事。kubernetes已经成为组织向云原生技术进行数字化转型的催化剂。它已经成为整个项目和产品生态系统开发的关键点和支撑平台，为开发人员和运营商提供了强大的云原生功能。通过为应用开发提供通用的可扩展的控制平面，Kubernetes成功地提供了一整类更高级别的抽象接口和工具。
kubernetes最重要的一个方面就是知道它的边界在哪里，这从一开始就是该项目的核心原则。虽然kubernetes仍在继续增长，但是它已经接近极限，正因为如此，在核心api之上之外还有一个繁荣的生态系统。从包管理到自动化运维，从workflow到ai，kubernetes api已经成为一个充满活力的云原生生态的基础。
随着kubernetes年满五岁，我们自然会展望未来，并思考如何让它继续蓬勃发展。在庆祝所取得的成果的同时，还必须指出，总有改进的余地。虽然我们的社区庞大而令人惊叹，但是多元化和包容性的社区是一个旅程，而不是目的，我们仍需不断的投入。同时，虽然有云原生技术的承诺，构建可靠的，可扩展的服务仍是一件很困难的事情，在将来，这些是必须进行持续投入以确保持续成功的核心领域。
这是惊人的五年，在你的帮助下，接下来的五年会更加惊人，谢谢。
文章作者：Edison/Lion
来源：容器魔方
赵昕演讲的题目为《微服务治理平台产品化与应用微服务化》。随着微服务被越来越多的企业所了解和认识，针对微服务治理平台的需求和应用微服务化的需求也变得越来越强烈。因此，目前各厂商面临的问题是如何提供符合客户需求的微服务治理平台产品，以及如何协助客户来进行应用微服务化的问题。
针对微服务治理平台产品，目前在市场上有三种主要的形态：
以上各形态的微服务治理平台，都有其优缺点。适合传统方式搭建的微服务治理平台，其组件都需要单独的虚拟机或物理机部署，部署过程相对复杂。此外，其组件若要实现高可用，要按照传统方式采用多机热备部署，占用大量的主机资源。而且在此种方式下，微服务治理平台组件与应用的部署环境分离，加大了运维的工作量与运维难度。
以容器化方式部署的微服务治理平台，其组件可以运行在具备 Docker 环境的虚拟机或物理机上。与容器 PaaS 平台解耦，可以在不同厂家的平台上部署。但是其问题是微服务治理平台作为一个应用，其访问入口与 PaaS 入口割裂，不方便使用。
时速云的微服务治理平台是与时速云的 PaaS 平台结合成为一个整体交付给用户。首先，微服务治理平台组件作为应用部署，能够接受 PaaS 平台统一调度管理。同时，用户的微服务应用代码能够与时速云 PaaS 平台的 Devops 功能结合起来，通过流水线，自动的将开发代码项目构建成容器镜像，并在 PaaS 平台上部署起来。同时 PaaS 平台可以管理多个集群，用以将测试环境与生产环境进行分离管理。
服务治理平台，不是单一技术路线的产品，目前支持 spring cloud、service mesh、dubbo，可以为用户提供丰富的选择。同时，针对分布式部署的微服务，时速云的微服务治理平台还提供分布式事务组件，来保证事务的一致性。此外，为了满足容器集群内的应用与外部应用能够进行互相调用，我们还专门定制了 CSB 云服务总线，通过服务订阅的形式，将集群内外的应用 API 开放打通。
我们不仅仅提供治理平台，还希望针对不同的用户能更好与微服务开发结合起来，因此，平台还提供了微服务开发的模板，用户可以自行选择java版本、依赖等来创建自己的代码模板，实现快速上手开发微服务。
当提供了相对完毕的微服务治理平台之后，用户所面临的问题是如何将应用进行微服务化。针对此问题，赵昕进行了六个方面的阐述：
目前用户的主要需求在于构建全新的微服务应用及现有的应用改造。但现况是用户的技术程度参差不齐，比如相当一部分用户并没有Docker使用的经验，或者用户有Docker 的使用经验也有应用微服务化的需求，再有用户已有应用微服务化的经验，但形态比较简单。因此，时速云认为应用的微服务化应用需要一套循序渐进的流程来实现：熟悉Docker、Kubernetes->选取试点应用进行容器化->迁移应用至云平台->微服务改造
赵昕表示应用微服务化的价值在于，与传统应用相比，微服务化的应用有诸多优点。
传统单体应用主要缺点有：
相比直线，微服务应用的主要优点有：
因此，应用的微服务化必定会作为应用所演进的方向，为更多的用户接受与使用。
当用户面临微服务改造的时候，必然会经历微服务的拆分，赵昕认为主要有四种拆分方法：
基于业务逻辑拆分
将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。
基于可扩展拆分
将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。
基于可靠性拆分
将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。
基于性能拆分
基于性能拆分和基于可靠性拆分类似，将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。
但单纯的提出拆分方法，并不能很好满足用户各类应用微服务拆分的需求，因此，赵昕指出，平台提供商在提供治理平台的同时，还需要提供相应的咨询服务，结合微服务产品的实现，以及在项目落地过程中所遇到的问题，有针对性的提出微服务化的解决方案，这样才能实现产品更好的落地，也能帮助客户快速的实现应用的微服务化，达到平台提供商与客户在技术、经济层面的双赢。
Kubernetes以运行可扩展工作负载而闻名。它根据资源使用情况调整工作负载。扩展工作负载时，会创建更多应用程序实例。当应用程序对你的产品至关重要时，你希望确保即使在你的群集受资源压力下也会安排这些新实例。解决此问题的一个显而易见的解决方案是过度配置群集资源，以便为扩展情况提供一些闲置资源。这种方法通常有效，但成本更高，因为你必须为大多数时间闲置的资源付费。
Pod优先级和抢占是Kubernetes 1.14里一般可用的调度程序功能，它允许你在不过度配置群集的情况下为关键工作负载实现高水平的调度可信度。它还提供了一种方法来提高群集中的资源利用率，而不会牺牲基本工作负载的可靠性。
保证调度，控制成本
Kubernetes Cluster Autoscaler是K8s生态系统中的一款出色工具，可在你的应用程序需要时为你的群集添加更多节点。但是，群集自动缩放器有一些限制，可能不适用于所有用户：
另一种选择是Pod优先级（Priority）和抢占（Preemption）。在此方法中，你将多个工作负载组合在一个群集中。例如，你可以在同一群集中运行CI/CD管道，ML工作负载和关键服务。当多个工作负载在同一群集中运行时，群集的大小大于用于仅运行关键服务的群集。如果你为关键服务提供最高优先级，并且CI/CD和ML工作负载的优先级较低，则当你的服务需要更多计算资源时，调度程序会抢占（驱逐）较低优先级工作负载的足够容量，例如ML工作负载，以允许所有你要安排的优先级较高的pod。
使用pod优先级和抢占，你可以在Autoscaler配置中为群集设置最大大小，以确保在不牺牲服务可用性的情况下控制成本。此外，抢占比向群集添加新节点要快得多。在几秒钟内就可以安排高优先级的pod，这对延迟敏感的服务至关重要。
提高集群资源利用率
运行关键服务的集群运营商会随着时间，粗略估计他们在集群中需要的节点数量，以实现高服务可用性。估计通常是保守的。此类估计会考虑流量突发以查找所需节点的数量。可以配置群集自动缩放器永远不会将群集的大小减小到此级别以下。唯一的问题是这种估计通常是保守的，而且大多数时候集群资源可能仍未得到充分利用。Pod优先级和抢占允许你通过在群集中运行非关键工作负载来显着提高资源利用率。
非关键工作负载可能具有多于群集可以运行的pod数量。如果对非关键工作负载给予负数优先级，则当非关键容器挂起时，Cluster Autoscaler不会向群集添加更多节点。因此，你不会产生更高的费用。当你的关键工作负载需要更多计算资源时，调度程序会抢占非关键容器并安排关键容器。
非关键pod填充了群集资源中的“空隙”，可在不增加成本的情况下提高资源利用率。
参与其中
如果你对此功能有反馈意见或有兴趣参与设计和开发，请加入Scheduling特别兴趣小组。
https://github.com/kubernetes/community/tree/master/sig-scheduling
来源：CNCF官微
来源：K8sMeetup社区
作者：bot、小君君
技术校对：星空下的文仔
Kubernetes 在过去几年中一直是云计算领域最著名的开源项目之一。
2018 年，Kubernetes 度过了自己的 4 岁生日。从 2014 年开源，到如今成功从 CNCF 孵化，它已成为容器编排的事实标准。虽然 Kubernetes 还很年轻，但它正如初升的朝阳，在过去几年中一往直前，为组织设计和部署应用程序带来全新定义。本文将回顾 2018 年 Kubernetes 的发展情况，同时展望它在 2019 年的前行之路。
当容器于 2008 年首次推出时，虚拟机（VM）还是云提供商和内部数据中心寻求优化数据中心资产的最佳选择。
在那时，VM 确实提供了良好的灵活性，但它也存在一些缺陷，如每个 VM 都需要在整个层（管理程序）中模拟完全可操作的系统，并大幅占用物理 CPU 资源。即使采用 Intel VT-x 和 AMD-V 等技术，使用 VM 的性能也远不如裸机运行。
在这个背景下，容器技术通过在所有镜像中共享相同的内核来解决这些缺陷。换句话说，来自不同镜像的流程可以在同一空间中运行，而内核负责保证它们之间的正确隔离，我们也可以设置限制镜像资源利用，对计算资源进行合理调配。占用内存更少，又不存在硬件仿真层，因此容器一经提出就迅速走红。
但随着容器广泛进入生产领域，人们很快也意识到一个事实，就是尽管在同一台计算机上部署容器很容易，但它在高可用性管理、灾难恢复和可伸缩性方面仍存在不少问题，优秀的编排层才是在生产中大规模部署容器的必要前提。
这些问题催生了一种名为容器编排系统的新型软件，这种软件也在过去五年中得到了普及。它们负责进行集群操作，协调调度、内存分配、安全性和网络，目的是确保所有镜像按规定工作。
经过激烈竞争，最后，于 2014 年开源的 Kubernetes 力克 Docker Swarm 和 Apache Mesos，成了容器编排领域当之无愧的胜者。它背靠 Google 多年实践，实现了对即时部署、弹性伸缩、健康检查与高可用性（HA）系统的全部覆盖，能为生产完整生命周期保驾护航。
在刚开源的前两年，Kubernetes 只有五个主要版本。从 2017 年起，它相继推出 1.6、1.7、1.8、1.9，围绕稳定性、性能和平台的 cloud availability 做了改进。而在 2018 年，Kubernetes 更进一步，又进行了 4 次重大更新，在企业最关注的安全性和可扩展性上做了显著改善：
功能方面，Kubernetes 在 1.10 版本中对接了 kubectl 凭证，从此云服务供应商、企业可以发布二进制插件以处理特定云供应商 IAM 服务的身价验证，可扩展性更强。
在 1.13 版本中，CoreDNS 被声明为通过所有规模/资源使用测试的默认集群 DNS。CoreDNS 解决了 kube-dns 存在的安全性和扩展性问题，把 Service 放在一个容器中完成，并用不同插件来复制（并增强）kube-dns 功能，为 Kubernetes 在网络安全方面的长期发展铺好了路。
CNCF 是一个随容器编排和微服务发展起来的新一代基金会，它的设立初衷是在开源社区基础上对现代分布式系统环境进行不断优化。而在 Google 把 Kubernetes 捐献给它后，CNCF 就把管理、支持 Kubernetes 推广发展作为自己的使命。
2018 年，作为 Kubernetes 最强大的支持者，CNCF 为繁荣社区做了许多事，其中又以 3 个孵化项目的成功毕业最为典型：
而在不久前刚举办的云容器领域最大的峰会之一 KubeCon + CloudNativeCon North America 2018 上，基金会宣布接受 etcd 分布式键值存储作为孵化项目，发挥它在 Kubernetes 集群管理软件设计中的重要作用；2019 年 1 月 24 日，CNCF 宣布 CoreDNS 毕业，为新一年 Kubernetes 的蓬勃发展打响第一炮。
在 GitHub 上，由于 Kubernetes 在稳定性和成熟性上已经上升到一个新高度，这一年提交数量有所降低，但 Kubernetes 的代码行数还在保持持续增长，且已突破 200 万大关。
尽管谷歌这些年来是 Kubernetes 的主要贡献者，但现在其他技术人员在这个项目上的贡献量已经几乎和谷歌持平了。此外，包括 IBM、Microsoft 等主要云提供商在内的 600 余个组织也为社区发展提供了的重要支持。在国内，华为、才云等组织和机构的贡献也名列前茅。
在 Kubernetes 代码库中导出的 API 端点数量已经稳定在 16,000，这也从侧面印证了 Kubernetes 的成熟度和复杂性水平。
Kubernetes 所处的时间点是传统和现代软件开发日益高流量的交叉点。根据 CNCF 统计数据，2018 年，云原生技术增长了 200％，全球有近三分之一的企业正在运营多达 50 个容器，运营 50 至 249 个容器地企业占比也超过 25%，有超过 80％ 的受访者把 Kubernetes 作为容器管理的首选。
这些数据都在说明这样一个事实：谁掌握了 Kubernetes，谁就能进一步扩大在云计算市场的竞争力，在风云诡谲的市场上抢占先机。结合这个背景，2018 年同样也是谷歌、亚马逊、微软等大型云提供商围绕 Kubernetes 奋勇争先的一年：
这些举动都在表明云计算市场的战火将继续蔓延，Kubernetes 已经成为兵家必争之地。而根据招聘网站 Dice 的报告，2018 年，Kubernetes 也是最受互联网公司青睐的 IT 技能之一，发展前景不可估量。
这两年，AI 发展得如火如荼，越来越多的企业正在寻求把它用于降低成本和业务创新，同时结合大数据实现企业整体的数字化升级。但再强的算法也需强大的架构和工程作为支撑。
从开发到测试再到生产，容器为流程运行提供了紧凑的环境，它们易于扩展，能将大型完整应用程序分解为有针对性、易于维护的微服务，完美契合 AI 应用开发的各个阶段。因此，Kubernetes 和 AI 的结合也被业界视为大势所趋。
但是，AI 在产品化过程中仍会遇到部署复杂、指令繁冗等种种问题。为了解决这些问题，智能且易于操作的 Kubeflow 应运而生。它可以使机器学习的工作负载分布在多个节点上，极大提高开发人员的工作效率，让 Kubernetes 上的机器学习、深度学习堆栈变得简单、快速、可扩展。
2018 年 11 月 8 日，Google Cloud 宣布推出 Kubeflow Pipelines。它部分基于并利用来自 TensorFlow Extended 的库，允许开发人员利用该工作并将其投入生产，促进了企业内部协作，并进一步实现了访问民主化。
近日，英特尔推出 Kubernetes-Native 深度学习平台 Nauta，这是一个企业级堆栈，适用于需要运行 DL 的工作负载，训练那些将在生产中部署的模型。用户可以在单个或多个工作节点上使用 Kubernetes 定义，安排容器化深度学习实验，并检查这些实验的状态和结果。
“Kubeflow 在简易化 Kubernetes 上配置和生产化机器学习工作负载上取得了重大进步，我们认为这会极大程度上让更多企业接受该平台。”
—— Reza Shafii，CoreOS 产品副总裁
新的一年，Kubernetes 和 AI 在融合之路上还有很长的一段路需要走，而除了简化整个流程，它们仍将面临在带宽上做出更多突破。
然而，随着 Kubernetes 被更广泛采用，它也为容器带来了挑战，这涉及从安全性到复杂性再到可扩展性的各个方面。
可扩展性包括两部分：基础架构的可扩展性和 API 的可扩展性。
谈到它，首先我们要理解一个概念：微服务。微服务是一项在云中部署应用和服务的技术，它允许公司将其应用程序分解为更小的专用代码包，根据需要进行独立调整和更新。虽然可用性很强，但与之俱来的是网络复杂性，企业难以管理用于构建应用程序的微服务之间的流量，也难以提高这些应用程序执行方式的安全性和可视性。
为了解决这个问题，现在许多供应商开始纷纷采用谷歌、IBM 和 Lyft 开发的开源项目 Istio，以帮助改进云原生网络。
近日，Nirmata （一家增强企业 DevOps 能力的容器初创公司）的一项研究显示，虽然 Kubernetes 未来可期，但它的复杂性已经成为项目继续发展的一个不可忽视的障碍。根据他们的调查报告，有超过 50% 的开发人员表示曾因 Kubernetes 的复杂操作有过不同程度的困扰。
对简单小型业务来说，Kubernetes 的体量太大了，不如直接用 shell 脚本来得高效直接。因此如果 Kubernetes 想要取得真正的成功，它还要在轻量级和化繁为简上做出更多努力。
同样的，安全性问题也不容小觑。去年，Kubernetes 出现的严重安全漏洞，攻击者可以利用该漏洞通过 Kubernetes API 服务器连接到后端服务器，利用 API 服务器的 TLS 凭证进行身份验证并发送任意请求，从企业防火墙内破坏应用和服务。
而同样是 2018 年，包括特斯拉、Weight Watchers 在内的多家公司也曾遭受 Kubernetes 环境的攻击，原因是他们把 Kubernetes 仪表板打开并暴露在互联网上。这些事故无疑会打击企业对 Kubernetes 的信心。
Kubernetes 的安全性问题是多维度的。一方面，对于一个运行在 Kubernetes 上的普通应用，真正业务代码只占 0.1%，不同的组件都可能存在不同的安全隐患；另一方面，企业的广泛使用和网络安全意识缺失也加剧了问题的严重性。
可喜的是，随着问题的暴露，社区中围绕 Kubernetes 安全的技术项目（如 Notary、TUF 以及谷歌 gVisor）在日益增多，开发者们也正积极地针对漏洞进行补丁和建议。
随着越来越多的公司将 Kubernetes 视为转向现代化 IT 企业的路标，再结合 2018 年的发展情况，新的一年，我们可以对 Kubernetes 有以下展望：
至于屏幕前的你 —— Kubernetes 最亲密的开发者，2019 年，你希望它将在哪些方面实现巨大突破呢？Kubernetes 有你，社区有你，让我们一起期待 Kubernetes 的成长！
在进行具体问题定位和处理之前，最好和最简单直观的方式是先看看docker引擎是否能够正常运行。有以下几种方法可以确认docker是否处于正常运行状态：
1）通过执行docker info命令可以直接确认docker是否正常运行：
$ sudo docker info
2）也可以使用操作系统的命令来检查docker是否正常运行：
$ sudo systemctl is-active docker # 或者 $ sudo service docker status
3）可以使用ps或top等命令检查进程的进程是否有正常运行的dockerd。
在Docker中，守护程序会将所有数据都保存在一个根目录中。通过此目录，将能够跟踪到与Docker相关的所有内容，包括容器(containers)，镜像(images)，存储卷(volumes)，服务定义(service definition)和机密(secrets)。默认情况下，此根目录为：
可以使用data-root配置选项将Docker守护程序的配置为使用其他目录 。由于Docker守护程序的状态保留在此根目录中，因此需要确保每个守护程序使用专用的目录。如果两个守护程序共享同一根目录（例如，NFS共享），将可能会导致故障的无法处理的情况。
在docker引擎中，如果使用了daemon.json文件，同时通过手动或使用启动脚本将选项传递给dockerd命令，并且这些选项间存在冲突，则会导致Docker无法启动，例如：
unable to configure the Docker daemon with file /etc/docker/daemon.json: the following directives are specified both as a flag and in the configuration file: hosts: (from flag: [unix:///var/run/docker.sock], from file: [tcp://127.0.0.1:2376])
如果看到类似于上述内容的错误，并且使用此标志手动启动守护程序，则可能需要调整命令字段或daemon.json以解决冲突。如果使用操作系统的初始脚本启动Docker，则可能需要以特定于操作系统的方式覆盖这些脚本中的默认值。
默认情况下，Docker会监听套接字(socket)。在Debian和Ubuntu操作系统中使用启动docker时，-H字段会一直被使用。如果在daemon.json指定了一个 hosts条目，则会导致配置冲突，从而导致Docker无法启动。为了解决此问题，请/etc/systemd/system/docker.service.d/docker.conf使用以下内容创建一个新文件，以删除默认情况下启动守护程序时使用的-H参数。
[Service] ExecStart= ExecStart=/usr/bin/dockerd
守护程序的日志可以帮助诊断问题，docker守护程序日志的具体存储位置取决于操作系统配置和使用的日志记录子系统：
| 操作系统 | 目录 |
|---|---|
| RHEL，Oracle Linux | /var/log/messages |
| Debian | /var/log/daemon.log |
| Ubuntu 16.04+，CentOS | 使用journalctl -u docker.service命令检查日志 |
| Ubuntu 14.10- | /var/log/upstart/docker.log |
| macOS（Docker 18.01+） | ~/Library/Containers/com.docker.docker/Data/vms/0/console-ring |
| macOS（Docker <18.01） | ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/console-ring |
| Windows | AppData\Local |
在daemon.json文件中将 debug键的值设置为true就可以启用docker的调试模式，此方法适用于每个Docker平台。
Kubernetes中文社区{
"debug": true
}
如果文件中已经包含JSON，则只需添加键值对”debug”: true，如果它不是文件中的最后最后一行，请在行尾添加“；”。同时需要确认log-level是否已设置为info或debug。默认值为info，可能的值包括debug，info，warn，error，fatal。
$ sudo kill -SIGHUP $(pidof dockerd)
也可以手动停止Docker守护程序，并使用debug的-D字段标志重新启动它。
如果守护程序没有响应，则可以通过向SIGUSR1守护程序发送信号来强制记录完整堆栈跟踪。
$ sudo kill -SIGUSR1 $(pidof dockerd)
这会强制记录堆栈跟踪，但不会停止守护程序。守护程序日志显示堆栈跟踪或包含堆栈跟踪的文件的路径（如果已记录到文件）。处理完SIGUSR1信号并将堆栈跟踪转储到日志后，守护程序继续运行。堆栈跟踪可用于确定守护程序中所有goroutine和线程的状态。
可以使用以下方法之一查看Docker守护程序日志：
在Docker日志中查找如下消息：
...goroutine stacks written to /var/run/docker/goroutine-stacks-2017-06-02T193336z.log ...daemon datastructure dump written to /var/run/docker/daemon-data-2017-06-02T193336z.log
Docker保存这些堆栈跟踪和转储的位置取决于操作系统和配置，有时可以直接从堆栈跟踪和转储中获取有用的诊断信息。
1.《Configure and troubleshoot the Docker daemon》地址：https://docs.docker.com/config/daemon/
作者简介：
季向远，本文版权归原作者所有。
一年两次的 CNCF 调查让社区紧跟时代脉搏，更好地了解云原生技术的采用情况。这是 CNCF 第二次用普通话进行云原生调查，以更好地衡量亚洲公司如何采用开源和云原生技术。之前的普通话调查已于 2018 年 3 月进行。本文还将与 2018 年 8 月以来北美/欧洲最新的同文调查版本进行比较。
重要结论
300 人回复了中文版调查，其中 83% 来自亚洲，相比之下，我们 2018 年 3 月的调查中有 187 人回复。
CNCF 在中国, 日本和韩国共有 42 位会员，其中包括 4 位白金会员：阿里云, 富士通, 华为和京东 (JD.com)。其中 某些成员也是终端用户，包括：
容器的增长
在开发周期的所有阶段均使用容器已经成为常态利用容器进行测试的人数大幅增加，从 2018 年 3 月的 24% 增加到 42%，另外 27% 的受访者提到未来计划采用。用于概念验证的容器使用也有所增加（从 8% 上升到 14%）。
随着容器的使用在所有开发阶段日益普遍，容器管理工具的使用也越来越多。自 2018 年 3 月以来，几乎所有容器管理工具的使用都大幅增加。
自 2018 年 3 月以来， Kubernetes 的使用量增长 11%。其他工具的使用也有所增加：
也有 2018 年 3 月的调查中没有提及的两个新工具。16% 的受访者使用 Mesos，另外 8% 使用 Noman 进行容器管理。
现成的商业解决方案（Kubernetes, Docker Swarm, Mesos 等）总体增长 58%，而本土管理（Shell Scripts 和 CAPS）增长 690%，这表明本土解决方案在亚洲仍然很受欢迎，而北美和欧洲市场则不再青睐 COTS 解决方案。
云与本地部署
虽然北美和欧洲市场广泛使用本地解决方案 (64%)，但在亚洲市场，这一数字似乎在下降。在本次调查中，只有 31% 的受访者报告了使用本地解决方案，相比之下，2018 年 3 月这一比例为 60%。云使用率正在增长，43% 的受访者使用私有云（从 24% 上升，51% 的受访者使用公共云（从 16% 上升。
Kubernetes
至于在何处运营 Kubernetes，阿里巴巴仍是第一，38% 的受访者报告正在使用，但低于 2018 年 3 月的 52%。紧随阿里巴巴之后的是亚马逊网络服务 (AWS)，24% 的受访者提到使用，略低于 26%。
以前未报告过，但正在占据额外市场份额的新环境是华为云 (13%), VMware (6%), 百度云 (21%), 腾讯云 (7%)，IBM 云 (8%) 和 Packet (5%)。
这些回应中也显示，本地使用量下降，24% 的受访者报告说，他们在本地运行 Kubernetes，而 2018 年 3 月这一比例为 38%。OpenStack 的使用率也大幅下降，从 2018 年 3 月的 26% 降至 9%。
对于运行 Kubernetes 的组织而言，生产集群的数量也在增加。运行 1-5 个生产集群的受访者减少 37%，而运行 11-50 个集群的受访者增加 154%。尽管如此，受访者大多运营 6-10 个生产容器，29% 的受访者报告这一数字。
我们还向受访者询问了他们用于管理应用程序各个方面的工具：
封装
封装 Kubernetes 应用程序最流行的方法是 Managed Kubernetes Offerings (37%)，其次是 Ksonnet (27%) 和 Helm (24%)。
自动扩展
受访者主要对任务和队列处理应用程序 (44%) 和 Java 应用程序 (44%) 使用自动扩展。其次是无状态应用程序 (33%) 和有状态数据库 (29%)。
受访者未使用 Kubernetes 自动扩展功能的最大原因是因为，其使用第三方自动扩展解决方案 (32%)，不知道这些功能存在 (30%)，或者已经构建了自己的自动扩展解决方案 (26%)。
入口提供商 (Ingress Providers)
据报告，Kubernetes 最大的入口提供商是 F5 (36%), nginx (34 %) 和 GCP (22%)。
公开集群外部服务 (Cluster External Services)
公开集群外部服务最流行的方式是负载平衡器服务 (43%), 与第三方负载平衡器的集成 (37%)和 L7 入口 (35%)。
在拥有多个团队的组织中分离 Kubernetes
受访者使用命名空间 (49%), 单独集群 (42%)和仅使用标签 (34 %)，将组织内的多个团队分开。
分离 Kubernetes 应用程序
受访者主要使用单独的集群 (45%), 命名空间 (46%) 和标签 (33%)，分离他们的 Kubenetes 应用程序。
云原生项目
云原生项目在生产中有什么优点？受访者列举了前四个原因：
与北美和欧洲市场相比，提高可用性和开发人员工作效率在亚洲市场更为重要，而更快的部署时间则不那么重要（只有 38% 的受访者提到了这一点，而在本调查的英文版本中这一比例为 50%。
至于生产和评估中使用的云原生项目：
自 2018 年 3 月以来，许多云原生项目的生产使用率有所增长。生产使用率最高的项目是：gRPC（从 13% 上升至 22%, Fluentd（从 7% 上升至 11%, Linkerd（从 7% 上升至 11%，OpenTracing（从 20% 上升至 27%。
评估云原生项目的受访者数量也在增长：gRPC（从 11% 上升到 20%), OpenTracing（从 18% 上升到 27%）和 Zipkin（从 9% 上升到 12%。
未来的挑战
随着云原生技术不断被采用，尤其是在生产中，仍然有挑战需要解决。受访者面临的最大挑战是：
我们注意到一个有趣的现象，自 2018 年 3 月的上一次调查以来，随着更多资源用于解决这些问题，许多挑战已经显著减少。出现的一个新挑战是缺乏培训。虽然 CNCF 在过去的一年中在Kubernetes 培训方面投入了大量资金，包括 Kubernetes 管理员和应用程序开发人员的课程和认证，但我们仍在积极努力使这些课程和认证的翻译版本在亚洲更容易访问。CNCF 还与 Kubernetes 培训合作伙伴的全球网络合作，以扩展这些资源，并与Kubernetes 认证服务提供商]合作，帮助支持复杂的组织踏上云原生之旅。
无服务
无服务器技术的使用在使用此技术的组织中激增 50%，而 2018 年 3 月这一比例为 25%。在这 50% 中，29% 使用可安装软件，21% 使用托管平台。另外 17% 的受访者计划在未来 12-18 个月内采用这项技术。
对于可安装的无服务器平台，Apache openshill 最受欢迎，有 11% 的受访者提到正在使用。其次是 Dispatch (6%), FN (5%) 和 OpenFaaS, Kubeless，和 Fission，并列 4%。
对于托管式无服务器平台，AWS Lambda 最受欢迎，有 11% 的受访者提到正在使用。其次是 Azure Functions (8%)，阿里云 Compute Functions, 谷歌云 Functions 和Cloudflare Functions 并列 7%。
亚洲的无服务器使用量高于北美和欧洲市场，其中，38% 的组织使用无服务器技术。与可安装软件 (6%) 相比，托管平台 (32%) 也更受欢迎，而在亚洲，这两种选择的使用更均匀。使用的解决方案也多种多样，而 AWS Lambda 和 kubeness 显然是北美和欧洲的领导者。
关于回到 CNCF 项目，一小部分受访者现在正在评估 (3%)或在生产中使用 CloudEvents(2%)。CloudEvents 是由 CNCF 无服务器工作组 组织的一项工作，旨在创建以一种通用方式描述事件数据的规范。
云原生在中国生根发芽
随着云原生在中国的持续增长，学习有关这些技术的方法变得越来越重要。以下是受访者了解云原生技术的主要方式：
文档
50% 的受访者通过文档学习。 每个 CNCF 项目在网站上都有大量文档，可以在此处找到。尤其是 Kubernetes，目前正致力于采用多种语言翻译其文档和网站，包括日语, 韩语, 挪威语和汉语。
技术播客
48% 的受访者通过技术播客学习。有各种各样的云原生播客可供学习，例如，谷歌的 Kubernetes 播课和 Red Hat 的PodCTL b。此外，可以查看 您应当留意的 10 个中国技术播客。
技术网络研讨会
29% 的受访者通过技术网络研讨会学习。CNCF 每周星期二上午 10 点到 11 点举办一次网络研讨会系列。您可以查看即将到来的时间表，或查看 之前网络研讨会的录音和幻灯片。
商业案例研究
27% 的受访者通过商业案例学习。CNCF 收集了终端用户案例研究 ，而 Kubernetes 也保留了大量的Kubernetes 特定用户案例研究列表。
中国的云原生社区
随着云原生技术在亚洲的持续增长，CNCF 很期待本周在上海举办首届 KubeCon + CloudNativeCon 年会。有 1,500 多名与会者参加开幕式，我们期待看到云原生技术在全球范围内的持续增长。
若要了解最新的新闻和项目，请参加我们在亚洲举办的 22 场云原生交流会。我们期待着在即将举行的会议上与您见面！
衷心感谢每一位调查参与人员！
您也可以在这里查看过去调查的结果：
关于调查方法和受访者
受访者代表各种公司规模，其中大多数在 50-499 名员工范围内 (48%)。至于工作职能，受访者大多数为开发人员 (22%), 开发经理 (15%) 和 IT 经理 (12%)。
受访者代表了 31 个不同的行业，主要为软件 (13%) 和金融服务 (11%) 行业。
此项调查采用普通话进行。下列为其他人口学统计数据：
来源：CNCF官微，https://mp.weixin.qq.com/s/GtGICwYzvCJEuMDv5YDKBQ
近日，阿里巴巴揭露了内部架构全面容器化的历程，目前阿里巴巴和蚂蚁金服集团多数事业部门，都已经采用了阿里巴巴去年11月开源的企业级容器平台PouchContainer，这套平台也遵循开源容器标准OCI，可与Docker兼容。阿里巴巴透露，去年双11购物节也是靠PouchContainer才撑过爆量交易的需求，高峰期启动了超过百万个容器来执行交易程序。PouchContainer也针对不同应用场景所需的容器配置进行优化，包括了电商平台、数据库、串流计算、大数据分析等。目前PouchContainer也刚于9月正式发布了1.0版。
阿里巴巴指出，PouchContainer和其他容器平台最大不同是，特别考虑了后续维运的需求，在隔离、镜像推送优化、丰富容器模式、扩充性和核心兼容性（兼容于Docker、Kubernetes等）都有强化。
微软新版企业级操作系统Windows Server 2019正式版正式在10月出炉，主打四大特色，包括了混合云、安全、应用程序平台及超融合基础架构。还新增了以浏览器为基础的服务器管理套件Windows Admin Center（1809版），可支持私有云和Azure的混合云应用架构，更容易将既有的Windows Server部署，连结至云端的Azure服务。而System Center 2019则要等到明年上半年才问世。
另外，在应用平台功能上，Windows Server 2019也将Server Core的容器镜像大小，也从5GB缩减了三分之一，以加速镜像的下载，并改善程序的兼容性，也支持Service Fabric、Kubernetes与Linux容器。另外在超融合基础架构部署上，新版也从过去只支持2个节点，增加到可部署到100个服务器的规模。微软也同时宣布将在2020年终止支持旧版的Windows Server 2008和Windows Server 2008 R2。
参考：https://www.ithome.com.tw/news/126430
https://www.ithome.com.tw/news/126431
在容器商用化市场竞赛上，Docker以简单易用的封装设计，掀起了容器技术的浪潮，相继成为了容器技术的标准，也带动了IT架构下个十年的变革。
虽然早在2006年就开始发展容器技术的Google慢了一步，但每周至少启用20亿个容器的大规模部署经验，让Google走上了另一条容器发展之路，也就是以提供大规模容器调度和集群管理为主的Kubernetes计划。
4年过去了，Docker和Kubernetes的地位显然互换，过去Docker是最多人琅琅上口的容器技术名词，现在主角则变成了Kubernetes。云端教父AWS云端架构策略副总裁Adrian Cockcroft曾指出，两者虽然都是运用容器技术，但最大的差异是，Docker是要解决应用程序开发（Developing）问题，而Kubernetes是要解决更上层的应用程序运维问题（Operation）。开发问题是早期的痛点，但随着企业越来越依赖容器技术，内部应用越来越多是云原生应用时，运维会是企业IT的新痛点。
因为云原生应用大多采用微服务架构设计，结合容器技术，一支应用程序往往需要数十，甚至复杂者要上百个容器化微服务程序组成，企业若有1百支应用，就得管上数千，甚至上万个容器化微服务，运维管理就成了最大的挑战。这正是后来主打大规模容器集群管理的Kubernetes后来胜出的关键。
企业商软大厂也纷纷加入Kubernetes平台战局，不论是在云端服务或是私有PaaS平台上，来发展自己的Kubernetes产品。像微软更直接找来Kubernetes共同创办人Brendan Burns，负责率领Azure容器服务团队，自己混合云产品Azure Stack也大力支持Kubernetes。IBM同样也靠以Kubernetes为核心的PaaS软件IBM Cloud Private，要来抢攻企业私有云容器平台市场，尤其是微服务管理需求。
很早就支持Kubernetes的红帽，在2015年推出的OpenShift 3.0版中，不惜放弃自己的容器调度工具，开始支持Kubernetes，现在更成为了要通吃跨多云、混合云架构，又能通吃裸机、容器和VM的企业级通用应用管理平台。而虚拟化龙头VMware也不落人后，近来也改力推主打通吃多家IaaS公云和Kubernetes集群管理的容器服务PKS软件。连甲骨文都在旗下云端服务支持Kubernetes。
而云端容器托管服务这两年更进入了新的竞争阶段，不少云端业者相继将自己容器托管服务中的Container，改由Kubernetes取代，例如Azure的ACS早在去年就换成了AKS， IBM则是今年5月将Cloud Container Service更名为Cloud Kubernetes Service，简称IKS。Kubernetes取代了Container，成了容器服务的新代名词。
但是，Google的Kubernetes布局，迟迟没有跨出云端，除了积极参与Kubernetes开源项目之外，就是全力发展GKE，试图打造出云端容器代管服务领导者的地位。直到今年Next云端产品大会举办前一周，Google低调地发布了一个消息，将原本GCP的服务快速安装入口网站（Cloud Launcher）更名为Google Cloud应用市场，开始卖起来各种第三方软件厂商开发的商业软件。
其中最特别的是，这个App市场中设置了企业级Kubernetes App类型，也就是Kubernetes App市场。使用GCP的企业，可以直接在这个App市场，购买想要用的Kubernetes App。Nginx、Spark、Elasticsearch、WordPress、Cassandra等13家软件公司，开始透过Kubernetes App的形式销售企业级软件。
Google还预告要制订一个Kubernetes App的标准，就像OCI容器镜像那样的容器应用打包形式，Google试图要让通过Kubernetes封装管理套件Helm打包的Kubernetes App也能成为一种流通用的封装格式。
不同Docker容器化应用，得将所有程序封装到单一个镜像中，Helm可以将组合一支应用系统的多个微服务程序各自的镜像，打包到一套应用程序包中封装，更符合大型企业应用或复杂云端原生应用的需求。
和Helm封装形式的通用化和专用市场形式的出现，让Kubernetes App成了容器化应用的新格式，这是Google新一代AP层的成形，打下第一个基础。
到了Next大会第一天开场演讲中，正当Google现场示范如何管理部署在两地的GKE容器集群时，突然秀出其中一套GKE的部署地点，竟然就在Next大会举办地点Moscone Center。随即，舞台上也出现了这台GKE主机，Google Cloud云端基础架构资深副总裁Urs Hölzle当场宣布，云端GKE服务将推出软件版本GKE On-Prem，可安装于企业内部机房服务器中。
Urs Hölzle宣布，Google将以GKE On-Prem软件，搭配开源微服务管理平台Istio，组成一套混合云软件称为Cloud Services Platform。GKE On-Prem的管理接口和云端GKE服务完全相同，企业可以将云端GKE上的服务，搬到自己机房，而不用改变管理运维方法。企业运维人员通过Google Cloud Console就可以同时管理云端的GKE服务和部署于自己机房的GKE On-Prem环境。
而Istio则是一套采取服务网格（Service Mesh）架构，来管理大量微服务的软件，可以将多个Kubernetes集群，集中到单一套服务网格中，来管理，并能支持跨Kubernetes集群联机，也能确保每个集群都套用一致的管理政策。不只Google，红帽同样也在自己的OpenShift上要支持Istio，同样都是看上企业未来大量微服务管理的需求。
不只如此，GKE On-Prem软件也强化了多项混合云整合机制，如企业可使用也可和云端GKE整合，不用建立复杂VPN。另外也可通用云端身份或自己的身份验证服务来登入GKE On-Prem。
运算工作可以跨不同GKE云端集群或自家的GKE集群间移动。企业可自建一个本地端Prometheus来监控GKE On-Prem，也可用云端的Stackdriver服务来监控本地端的GKE On-Prem集群。
不同于云端GKE，本地端GKE软件可存取持久性储存服务来部署大型应用，例如复杂的数据库。Google云端部署工具Cloud Build也可用来部署本地端GKE On-Prem上的容器应用。而Kubernetes应用市场上的Kubernetes应用，果不其然，也可部署到本地端的GKE On-Prem环境中。
Google的Cloud Services Platform战略布局，不只是涵盖了混合云、企业私有云、Kubernetes App市场，还要让自家无服务器服务，能部署到GKE On-Prem上，来进入企业内部。
Urs Hölzle表示，Kubernetes已经成为企业基础架构的部署标准之一，也因此，Google现在更进一步要用GKE On-Prem软件来补齐企业混合云架构的最后一块拼图。Google新策略是将云带到你身边。要让企业内部环境（on premise）到云端环境的管理工具能一致化，从网络到应用程序都能用同样的管理方式。
而他没说出口的是，如此一来，借助GKE On-Prem软件和Cloud Services Platform布局，Kubernetes已经成为了企业全新的应用层，甚至可以说是新一代的应用服务器层，未来的Kubernetes云原生应用，可以在这一层快速部署，任意调度扩充和迁移，就像是新一代的通用AP层基础架构。
原文：https://www.ithome.com.tw/news/125469
对于Docker来说，存在镜像、容器、存储卷和网络这些对象。因此，也就会生产相对应的这些对象，这些对象会占据磁盘空间。当这些对象不在被使用时，为了不占据额外的磁盘空间，就需要对这些对象进行清理，即进行垃圾清理。在docker 1.13版本之后，提供了对各种对象的prune命令，也提供了清理所有对象类型的docker system prune命令。但在docker 1.13之前的版本，则需要提供其他方式进行垃圾清理。
在停止容器时，系统并不会知道删除这个容器，除非在运行此容器时设置了–rm字段。停止后的容器仍然会占据磁盘的存储空间，通过docker container prune能够删除这些被停止后的容器。
$ docker container prune WARNING! This will remove all stopped containers. Are you sure you want to continue? [y/N] y
执行此命令时，默认会提示是否继续。如果在执行命令是设置了-f或–force字段，则会直接删除已所有已停止的容器。默认情况下，此命令执行时会删除所有的已停止的容器，也可以通过设置–filter字段，来过滤所要删除的容器。例如，下面的命令仅仅删除停止超过24小时的容器。
$ docker container prune --filter "until=24h"
通过执行docker images prune命令可以清除所有不再使用的镜像，默认情况下此命令仅仅清除状态为dangling的镜像。状态为dangling的镜像为未被打标签和没有被任何容器引用的镜像。
$ docker image prune WARNING! This will remove all dangling images. Are you sure you want to continue? [y/N] y
如果要移除所有未被使用的镜像，则通过设置-a字段来实现：
$ docker image prune -a WARNING! This will remove all images without at least one container associated to them. Are you sure you want to continue? [y/N] y
执行此命令时，默认会提示是否继续。如果在执行命令是设置了-f或–force字段，则会直接进行删除操作。可以通过设置–filter字段，来过滤所要删除的镜像。例如，下面的命令仅仅删除停止创建超过24小时的镜像。
$ docker image prune -a --filter "until=24h"
存储卷可以被一个或者多个容器使用，也会占据磁盘空间。为保持数据，存储卷永远都不会自动被删除。
$ docker volume prune WARNING! This will remove all volumes not used by at least one container. Are you sure you want to continue? [y/N] y
执行此命令时，默认会提示是否继续。如果在执行命令是设置了-f或–force字段，则会直接进行删除操作。默认情况下，此命令执行时会删除所有的未被使用的存储卷，也可以通过设置–filter字段，来过滤所要删除的存储卷。例如，下面的命令仅仅删除label值为keep的存储卷。
$ docker volume prune --filter "label!=keep"
docker网络并不会占据磁盘空间，但是会创建iptables规则，桥网络设备和路由表。因此，但如何不再使用这些资源时，应该对其进行清理。
$ docker network prune WARNING! This will remove all networks not used by at least one container. Are you sure you want to continue? [y/N] y
执行此命令时，默认会提示是否继续。如果在执行命令是设置了-f或–force字段，则会直接进行删除操作。默认情况下，此命令执行时会删除所有的未被使用的网络，也可以通过设置–filter字段，来过滤所要删除的网络。例如，下面的命令仅仅为被使用超过24小时的网络。
$ docker network prune --filter "until=24h"
通过docker system prune命令能够快速的删除所有的未被使用的对象，包括镜像、容器、网络和存储卷。在docker 17.06.0之前，存储卷会同时被清理。在docker 17.06.1之后，需要通过设置–volumes字段，才会同时清理存储卷。
$ docker system prune
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all build cache
Are you sure you want to continue? [y/N] y
如果所使用的docker 17.06.1之后的版本，则需要在命令后添加–volumes字段来清理存储卷的内容。
$ docker system prune --volumes
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all volumes not used by at least one container
- all dangling images
- all build cache
Are you sure you want to continue? [y/N] y
在停止容器时，系统并不会知道删除这个容器，除非在运行此容器时设置了–rm字段。停止后的容器仍然会占据磁盘的存储空间，通过docker rm能够删除这些被停止后的容器。通过下面的命令能够清除所有已停止的容器。
$ docker rm $(docker ps -a -q)
通过执行docker rmi命令可以清除所有不再使用的镜像，一般情况下仅仅清除状态为dangling的镜像。状态为dangling的镜像为未被打标签和没有被任何容器引用的镜像。
$ docker rmi $(docker images -q -f "dangling=true")
存储卷可以被一个或者多个容器使用，也会占据磁盘空间。为了保持数据，存储卷永远都不会自动被删除。
$ docker volume rm $(docker volume ls -q -f dangling=true)
1.《docker container prune》地址：https://docs.docker.com/engine/reference/commandline/container_prune/
2.《Prune unused Docker objects》地址：https://docs.docker.com/config/pruning/
3.《docker image prune》地址：https://docs.docker.com/engine/reference/commandline/image_prune/
4.《docker volume prune》地址：https://docs.docker.com/engine/reference/commandline/volume_prune/
5.《docker network prune》地址：https://docs.docker.com/engine/reference/commandline/network_prune/
作者简介：
季向远，北京神舟航天软件技术有限公司。本文版权归原作者所有。
京东首席架构师刘海锋与云原生计算基金会（CNCF）坐下来谈论云原生、京东的Kubernetes实施，以及对其它考虑开始采用开源的公司分享一些技巧和心得。以下是他们的采访。
CNCF：您如何看待您的CNCF成员资格和云原生技术，帮助京东实现“零售即服务”的愿景？
海锋：我们零售即服务（RaaS）战略的目标是开放我们的能力和资源，以增强我们的合作伙伴、供应商和其他行业的能力。这非常符合我们对开源技术的承诺。我们已经从参与的CNCF项目中获益匪浅，我们对CNCF的新承诺使我们能够与行业顶级开发商、最终用户和供应商建立更强大的合作关系，并最终使我们能够为开源社区贡献更多。我们正开发新的容器原生技术以实现我们的RaaS愿景，加入CNCF是我们迈出的重要一步。
CNCF：Kubernetes对您的公司和/或开发团队有何影响？
海锋：京东是Kubernetes最早期采用者之一。公司目前管理世界上最大的Kubernetes集群，多集群超过20,000多个裸机服务分布在多个地区的数据中心。
CNCF：Kubernetes如何帮助京东进行人工智能或大数据分析以彻底改变电子商务？
海锋：JDOS是我们定制和优化的Kubernetes版本，支持广泛的工作负载和应用程序，包括大数据和AI。JDOS提供了一个统一平台管理物理机和虚拟机，包括容器化GPU，并支持大数据和深度学习框架，如Flink、Spark、Storm和TensorFlow即服务。通过共同调度在线服务以及大数据和AI计算任务，我们显著地提高资源利用率并降低IT成本。
CNCF：京东运行的Kubernetes集群有多大？请描述一下您的团队使用Kubernetes。
海锋：JD目前管理世界上最大的Kubernetes集群，多集群超过20,000多个裸机服务分布在多个地区的数据中心
CNCF：Kubernetes和云原生如何赋能京东的开发者？哪些是他们现在能做而以前做不到的？
海锋：旧的部署工具对不同环境需要不同的流程，包括应用程序打包、容器应用程序、部署、配置和缩放。整个过程既复杂又耗时。Kubernetes的引入大大简化了流程。现在，应用程序自动打包成镜像并近乎实时地部署到容器中。缩放现在是一个简单的一键操作，可以在几秒内完成。
CNCF：京东运营世界上最大的Kubernetes集群之一，公司是如何克服障碍？
海锋：我们一直监控系统的性能。过去，为解决性能的问题，我们收集并分析了几个关键绩效指标，并生成了详细的瓶颈分析报告。然后，我们通过删除不必要的函数和优化默认的调度程序来定制Kubernetes。我们还增强了多个控制器以避免级联故障。此外，我们还开发了用于检查、监控、报警和故障处理的操作工具包，帮助操作员排除故障并快速解决可能出现的任何问题。
CNCF：京东刚刚庆祝大名鼎鼎的6月18日全民年中购物节（“618”），在18天期间交易量超过247亿美元。这是很大量的订单。您能谈谈您的系统如何处理这么多的订单吗？
海锋：JDOS使用基于预测的算法，主动分配资源以满足预测需求，提高资源利用率。它还提供毫秒级弹性扩展，处理极端工作负载。我们每年举办的618全民年中购物节，今年的交易量达到了247亿美元。我们的平台有超过3亿客户，在此期间我们看到显着的流量高峰。我们调度了大约460,000个容器（Pod）和3,000,000个CPU核心，以支持大量订单。
CNCF：告诉我们您的Vitess使用情况。有什么影响？
海锋：我们的弹性数据库是世界上规模最大、最复杂的Vitess部署之一。我们已经成功地扩展了Vitess，在JD的Kubernetes平台上管理大量复杂的交易数据。显著的功能包括支持RocksDB和TokuDB作为新的存储引擎、自动重新分片、自动负载平衡和迁移。我们的系统目前管理2,600个MySQL集群、9,000个MySQL实例、350,000个表、1,600亿条记录和65T数据，支持京东的各种业务应用程序和服务。Vitess的使用使我们能够更灵活、更有效地管理资源，从而显著降低运营和维护成本。我们正积极与CNCF社区合作，向Vitess添加子查询支持和全域交易等新功能。
CNCF：您公司对Kubernetes和其它云原生技术（GitLab、Jenkins、Logstash、HarbourElasticsearch和Prometheus）的下一步是什么？
海锋：我们的容器化平台通过在Kubernetes上部署DevOps堆栈来分离应用程序和基础架构层，包括Vitess、Prometheus、GitLab、Jenkins、Logstash、Harbour和Elasticsearch等。我们贡献了代码到其中一些项目。我们希望将来能够做出更多贡献。我们认为可以真正增加价值的一个例子是Vitess，CNCF的可扩展MySQL集群管理项目。我们不仅是Vitess的最大最终用户，也是一个非常活跃和重要的贡献者。我们期待与CNCF社区的其他人一起为Vitess添加新功能，包括子查询支持、全域交易等。另外，我们正在扩展Prometheus以创建实时和高性能的监控系统。我们希望改进Kubernetes以支持多种不同的工作负载，并希望为Kubernetes贡献代码。
我们也计划发布我们的内部自研项目。在github.com/tiglabs上能找到很多。我们还计划提出新的CNCF项目。其中一个项目是ContainerFS。它是一个与Kubernetes无缝集成的大规模容器原生集群文件系统。
CNCF：您目前也正在评估哪些技术或实践（DevOps，CI / CD）？
海锋：我们正在积极开发以云原生或容器原生软件和技术为中心的开源项目，从计算、存储和中间件到应用程序。其中一个重点是用于各种工作负载的容器平台，包括在线服务、数据分析、边缘计算和物联网。另一个重点是容器平台的可扩展和高性能数据存储。
CNCF：对于刚刚开始使用云原生的其他中国公司，最重要的事情是什么？
海锋：借助Docker、Kubernetes和微服务，您可以从云原生获得很多价值而无需承受高额成本。云原生解决方案不仅可以在云中运行。它非常灵活，可以部署在内部环境、私有云、公共云和混合环境中。重要的是要密切关注新技术和行业趋势，利用开源技术并积极参与开源社区。
CNCF：对于希望部署云原生基础架构的其他公司，您有什么建议？
海锋：从生态系统的角度考虑如何满足您的业务需求，包括容器化基础设施、数据存储、微服务平台、消息传递和监控系统等。在容器编排和管理方面，Kubernetes是事实上的标准，是肯定的能押注的。您还应该利用新兴的无服务器架构来简化应用程序开发、打包、部署和管理的过程。
CNCF：为什么云原生对京东的商业是如此势在必行？
海锋：除了我们的商家外，我们拥有超过3亿客户，我们的基础设施必须具有可扩展性和极高的效率。五年前，我们的产品图像系统中有大约20亿个图像。今天，有超过一万亿，这个数字每天增加1亿。此外，作为中国最大的在线或离线零售商，同时也是中国最大的电子商务物流基础设施的运营商，完全由内部自力开发，我们的业务复杂且日新月异。因此，我们的基础架构必须非常灵活，并支持广泛的工作负载和应用场景，如在线服务、数据分析、AI、供应链、财务、物联网或边缘计算等。云原生技术非常适合处理我们不断变化的需求。
CNCF：这是京东加入的第一个开源基金会吗？
海锋：对。我们坚定地相信开源，并且与我们自己的战略密切配合。通过CNCF，我们的目标是与开源社区建立更多更强大的交流互动，并充分发现为开源社区做出贡献的潜在互利。作为全球以收入计算第三大互联网公司，京东已经开发了许多领先的技术创新，我们认识到我们有责任在开源社区中发挥领导作用。
CNCF：您打算如何与CNCF携手合作？
海锋：我们可以合作的领域是无限的。当我们推进一些新项目，加入CNCF并与其他成员合作将非常有帮助。此外，CNCF为我们提供了平台，提高我们某些项目的推广认识，招募领先的开发者，进行协作并为我们的工作做出贡献。
CNCF：您对KubeCon + CloudNativeCon中国论坛的内容感到兴奋吗？
海锋：我们期待与行业顶级开发商、最终用户和供应商会面，并继续了解最新的技术发展。我们还计划展示自己的工作，并确定与公司、最终用户和独立开发者的潜在合作机会。
想更多地了解中国的技术领导者如何利用云原生技术？11月14日至15日，参与我们在上海举办的首届KubeCon + CloudNativeCon中国论坛。希望能在那里见到您！