如果你需要大规模的容器编排，想必Kubernetes毋庸置疑是你的首要选择，这一由谷歌推出的开源容器编排系统近年来发展飞速，大受业界及广大用户好评。
尽管如此，对于大多数用户而言，Kubernetes存在着学习曲线陡峭、难以设置和配置的问题，导致终端用户需要承担繁重的管理工作。基于此，最佳的解决办法并非单枪匹马学习并直接上手Kubernetes，而是寻找一个完善的容器技术解决方案，这种方案通常将Kubernetes纳为其支持和维护的组件之一，使用起来通常更直观和简洁，如此一来便极大程度降低了Kubernetes的上手门槛。
在本文中，我列出了10个业界最流行的Kubernetes相关产品，包括了Kubernetes发行版、容器工具、不同的供应商提供的Linux内核等等。
本文的列表不包括Amazon EKS或者Google Kubernetes Engine（GKE）这样的云服务，仅仅列出了可以在本地运行或作为云托管的软件发行版。
目 录
Rancher 2.0
CoreOS Tectonic/Red Hat CoreOS
Canonical Distribution of Kubernetes（CDK）
Docker 社区版 / Docker 企业版
Heptio Kubernetes 订阅
Kontena Pharos
Pivotal 容器服务 (PKS)
Red Hat OpenShift
SUSE 容器服务平台
Telekube
十大Kubernetes发行版
Rancher 2.0
https://rancher.com/kubernetes/
严格来说，Rancher 2.0并不是一个单纯的Kubernetes发行版，而是一个开源的Kubernetes管理平台。Rancher 2.0 为企业用户提供Kubernetes-as-a-Service (Kubernetes即服务)，且能够实现多Kubernetes集群的统一纳管，不论这些Kubernetes集群在何处、以何种方式部署。这解决了生产环境中企业用户可能面临的基础设施不同的困境。Rancher 2.0能统一纳管来自Google（GKE）、Amazon（EKS）和Azure（AKS）等公有云上托管的Kubernetes服务的平台。
Rancher Labs公司在2019年发布了提供轻量级的Kubernetes发行版，K3s。这款产品专为在资源有限的环境中运行Kubernetes的研发和运维人员设计。其每个服务器实例仅需512MB RAM以及200MB的磁盘空间。它删除了旧的、非必须的代码，整合正在运行的打包进程，使用containerd代替Docker作为运行时的容器引擎，并在除etcd之外引入了SQLite 作为可选的数据存储，通过这些变化极大地减少了运行所需的空间和资源。
CoreOS Tectonic/Red Hat CoreOS
https://coreos.com/tectonic/
CoreOS提供以容器为中心的Linux发行版，它兼容Docker，但又有固定的镜像格式、它自己的runtime、以及一个“企业级Kubernetes发行版”。上述这些共同构成了CoreOS Tectonic堆栈的基础。
CoreOS操作系统Container Linux是业界的一大流行产品，它的亮点之一在于它就像一组容器化组件，用户无需关闭正在运行的应用程序，即可将操作系统的自动更新整合到生产环境中。CoreOS还可以对Kubernetes进行“一键式”更新。此外，CoreOS Tectonic可以在Amazon Web Services、Microsoft Azure以及裸机上运行。
Red Hat收购了CoreOS之后，计划将其集成到Red Hat OpenShift中。Container Linux将被重新命名为Red Hat CoreOS。此举预计将在2020年之前完成，在此之前Container Linux将继续得到支持。根据Red Hat的说法，过渡后将提供“几乎所有”CoreOS Tectonic的功能。
Canonical Distribution of Kubernetes（CDK）
https://www.rhyL158.com ubuntu.com/kubernetes
Canonical，Ubuntu Linux的制造商，也拥有自己的Kubernetes发行版，即Canonical Distribution of Kubernetes（CDK）。该发行版的一大卖点是它是一款广泛受到支持、易于理解且普遍部署的Ubuntu Linux发行版。Canonical声称其堆栈既可以在任何云上运行，也可以在本地部署，并支持CPU和GPU驱动的工作负载。付费客户还能享受Canonical的工程师远程管理他们的Kubernetes集群的服务。
Canonical的Kubernetes发行版也有轻量级版本的，叫Microk8s。开发人员以及Kubernetes新手可以在笔记本或者台式机上安装Microk8s，将其用于测试、实验，甚至在那些硬件配置低的生产环境中使用。
此外，Canonical和Rancher Labs共同开发了一个产品叫做“云原生平台（Cloud Native Platform，简称CNP）”，它将Canonical的Kubernetes发行版和Rancher的容器管理平台相匹配。如此，就可以使用Kubernetes管理运行在每个集群上的容器并且用Rancher管理多Kubernetes集群。目前，CNP已经在Rancher 2.x的版本中可以使用。
Docker 社区版 / Docker 企业版
https://www.docker.com/products/kubernetes
对于很多人来说，Docker仅仅是容器。但实际上，2014年之后Docker也有它自己的集群和编排系统，Docker Swarm，而这一系统曾是Kubernetes的竞争对手。直到2017年10月，Docker宣布将在其未经修改的、永久标准的状态中添加Kubernetes作为标准打包方式，这一调整涵盖了Docker Community Edition和Docker Enterprise 2.0及以后的版本。
Docker Enterprise 3.0添加了Docker Kubernetes服务，这一Kubernetes集成可以保持开发人员桌面和生产部署环境中Kubernetes版本一致。
简而言之，Docker公司已经意识到Kubernetes比Swarm更适合管理庞大、复杂的容器环境。然而，Docker依然包括其原始的集群系统“swarm 模式”，它更适用于那些不太复杂的工作，例如部署一个无需扩展太多的本地的、受保护的应用程序或者维护不需要修改的现有swarm模式集群。
Heptio Kubernetes 订阅版
https://heptio.cloud.vmware.com/
Kubernetes的两位创始人Craig McLuckie和Joe Beda，创办了Heptio，主要围绕Kubernetes提供服务和产品。他们第一个主打产品是一个付费的Kubernetes部署服务， Heptio Kubernetes Subscription（HKS）。Heptio提供全天候的技术支持，收费是每月2000美元及以上。
Heptio的主要优势在于它是企业级的Kubernetes，又不害怕厂商锁定。它可以在公有云或者私有硬件上运行部署。所有Heptio提供的用于管理Kubernetes配置的工具都是开源的，并且修复程序可以直接交付到支持的集群。
2018年VMware收购了Heptio，不过此次收购目前暂未影响Heptio的产品计划。
Kontena Pharos
https://www.yishenpt3.com /pharos/
Kontena Pharos的定位是“Kubernetes that just works”，它与Red Hat的Linux产品拥有大致相同的“剧本”。底层架构是经过CNCF认证的Kubernetes发行版，可以在Apache 2许可下使用（和Fedora或CentOS一样）。付费客户可以获得专业级功能、技术咨询、支持服务和特定固定价格的产品，比如迁移到云原生基础设施。
核心Pharos发行版默认配置了自动安全更新和多个容器运行时等基本功能。付费的版本则添加了企业工具，比如Kontena Lens面板、Kontena Storage分布式存储系统、备份、负载均衡以及在内网隔离环境中部署集群。
专业版有30天的试用期，订阅的费用为每月近3000美元起。而开源的版本则没有时间的限制也不需要许可费用。
Pivotal 容器服务 (PKS)
https://pivotal.io/cn/platform/pivotal-container-service
Pivotal，以其在Cloud Foundry上的表现而为人熟知，它拥有企业级Kubernetes服务，即Pivotal Container Service（PKS）。PKS吸取了许多其他Pivotal项目的灵感，例如，它使用曾经用于Pivotal的Cloud Foundry的Kubo项目来启动和管理Kubernetes集群。
PKS一个最突出的特性是与VMware虚拟机堆栈紧密集成，事实上，PKS是VMware-Pivotal的联合项目。运行在PKS上的容器可以访问在vSphere上运行的虚拟机可用的服务，譬如VMware VSAN中的持久存储。此外，PKS可以通过用于在公有云和私有云环境中管理VMware基础设施的VMware Cloud Foundation进行管理。
简而言之，任何使用VMware并且对Kubernetes越来越感兴趣的企业可能希望研究PKS以充分利用他们现有的VMware设置。
Red Hat OpenShift
https://www.redhat.com/en/technologies/cloud-computing/openshift
OpenShift是红帽的PaaS产品，最初使用与Heroku buildpack类似的“盒式磁带”打包应用程序，然后将其部署在称为“齿轮”的容器中。然后Docker出现了，OpenShift经过了重新设计，使用新的容器镜像和运行时标准。不可避免地，Red Hat采用了Kubernetes作为OpenShift中的编排技术。
OpenShift还为PaaS中的所有组件提供抽象化和自动化。这种抽象和自动化扩展到Kubernetes，会带来相当大的管理负担，因此OpenShift可以用来缓解这一过程，作为部署PaaS的更为重要的一部分。
如上文所提到的，CoreOS Tectonic正在合并到Red Hat OpenShift中，虽然技术合并预计要到2020年才能完成。
SUSE 容器服务平台
#!/bin/bash
URL="https://www.yacuangyl.com
HTTP_CODE=`curl -o /dev/null -s -w "%{http_code}" "${URL}"`
#echo $HTTP_CODE
if [ $HTTP_CODE != '200' ];then
curl 'https://oapi.dingtalk.com/robot/send?access_token=xx' \
-H 'Content-Type: application/json' \
-d '{"msgtype": "text",
"text": {
"content": "百度平台状态不正常，请注意！"
},
"isAtAll": true
}'
fi
功能实现
使用spring task
@Scheduled(cron =www.xcdeyiju.com "0 0 0/1 * * ? ")
public void startSchedule() {
log.info("开始执行定时任务 ，检测百度网站连通性");
try {
HttpResponse response = HttpRequest.get("").execute();
if (HttpStatus.HTTP_OK != response.getStatus()) {
this.send2DingTalk(response.getStatus());
}
log.info("请求百度成功，返回报文:{}",response.body());
} catch (HttpException e) {
log.error("请求异常百度:{}", e);
this.send2DingTalk(e.getMessage(www.hengxuangyul.com));
}
log.info("执行检测百度网站连通任务完毕");
}
问题描述
部署在服务器上，我的*io本 都已经呼叫任务状态不正常了,可是小弟的Java 代码还是没有执行通知
去翻生产日志，只输入了开始并没有输出定时任务结束，感觉是哪里卡死，想当然以为如果超时总会到catch 逻辑，排查无果
由于任务是一小时一次，如何快速触发一下这个异常，还原事故现场
由于使用简单的Spring Task 没有图形化界面和API接口
Arthas 还原事故现场，重新触发任务
核心拿到 spring context 然后执行它的 startSchedule 方法
确定监控点
SpringMVC 的请求会通过 RequestMappingHandlerAdapter 执行invokeHandlerMethod 到达目标接口上进行处理
而在 RequestMappingHandlerAdapter类中有 getApplicationContext（）
@Nullable
public final ApplicationContext getApplicationContext() throws IllegalStateException {
if (this.applicationContext =www.hxyl1618.com= null && this.isContextRequired()) {
throw new IllegalStateException("ApplicationObjectSupport instance [" + this + "] does not run in an ApplicationContext");
} else {
return this.applicationContext;
}
}
任意执行一次请求获取到 RequestMappingHandlerAdapter target 目标，然后执行 getApplicationContext
tt命令 获取到ApplicationContext
arthas 执行 tt
tt -t org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter invokeHandlerMethod
任意执行一次web 请求，tt 即可捕获
根据目标的索引，执行自定义 OGNL 表达式即可
tt -i 1019 -w 'target.getApplicationContext()'
使用ApplicationContext获取 定时任务bean 执行 startSchedule
tt -i 1000 -w 'target.getApplicationContext().getBean("baiduSchedule").startSchedule()'
ok 任务重新触发了
事故原因调查清楚，由于使用hutool 的工具类 没有设置timeout 导致无限等待，所以没有执行catch 逻辑
总结
以上吓哭实习僧的操作禁止生产操作，只是提供个思路 ，当然可以衍生其他业务场景的操作
核心是通过Arthas 来抓取Spring ApplicationContext 对象，然后获取bean 进行执行方法
关于Arthas 是Alibaba开源的Java诊断工具，深受开发者喜爱
欢迎关注我们获得更多的好玩JavaEE 实践
因Linux 发行版而在欧洲广为人知的SUSE也拥有 SUSE CaaS平台。概念上，SUSE CaaS平台让人想起CoreOS Tectonic，它结合了运行容器的裸机“微型”操作系统、Kubernetes、内置的镜像仓库和集群配置工具。
SUSE CaaS Platform3于2018年发布，在这一版本中添加了多主机功能以使集群更能适应主节点崩溃和内核调整功能，以便对包含的Linux内核进行自定义调整。
SUSE CaaS平台可以在公有云和本地裸机上运行，但需注意SUSE目前无法支持任何与底层云基础架构的集成。这意味着SUSE CaaS平台不是为了补充Amazon EKS或Google Kubernetes Engine而设计的，而是为了规避他们，让您可以跨多个云和数据中心运行容器。
Telekube
https://gravitational.com/gravity/
Teleport SSH服务器的所属公司Gravitational开发了Gravity，这是一种在本地或远程集群上运行的“强化生产”Kubernetes发行版。Gravity的定位是私有SaaS平台的解决方案或在多个区域及托管提供商中运行Kubernetes-as-a-service。
Gravity上的应用程序要想在Kubernetes上的容器中运行，必须做一些前提准备。它们必须首先被打包成“Bundles”，这些“Bundles”之后会被发布到Kubernetes集群进行分发。这些“绑定”属于额外工作，除此之外我们常见的部署容器应用程序所需的准备工作也仍然需要做，不过Bundle清单也是Gravity唯一需要的额外工作了。
Gravity包含拍摄整个Kubernetes集群的快照的功能，其中包括所有的应用程序和配置，并且用户可以部署快照到任意其他Kubernetes环境中。
结 语
Kubernetes和容器正在改变应用程序的创建、部署以及管理的方式。而本文列出的这些Kubernetes发行版，正在引领着这场变革。