Cloud-Native

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。Kubernetes ingress-nginx v1.1.2 公布就在明天 Kubernetes ingress-nginx 我的项目公布了 v1.1.2 版本。我是这个版本的 release manager 。 间隔上个版本公布有将近两个月了，咱们来看看这个版本中值得关注的一些变更。 在 #8221 中，咱们对 ingress-nginx 的 Admission controller 的逻辑做了一些调整，次要是能够用来修改 自 v1.0 版本后，如果 Kubernetes 集群中同时运行多个 ingress-nginx 的话，在创立 Ingress 资源的时候，可能导致每个 ingres-nginx 的 Admission 都会去进行查看的问题。而该问题最大的影响是，如果创立的 Ingress 配置雷同的话，则会被间接回绝掉。 在 #8253 中则是为 ingress-nginx 减少了一个 ssl_certificate_info 的 metric， 间接公开以后被加载的证书的信息。这个性能的最大的益处就是能够防止 Ingress controller Pod 加载了旧证书，进而导致客户端连贯失败的问题。 此外 #8256 是为了修改在 nginx.ingress.kubernetes.io/auth-url 中传递有效 URL 的问题，倡议降级 。 此外还有一些小的 bugfix 和优化，更多详细信息请参考 ReleaseNote 。 在这次公布过程中还有一些比拟乏味的事件，本次公布过程从工夫线看，从我开始公布流程，到最初实现公布，共继续了一周的工夫，由几个人异步合作实现。这跟平常差异还是比拟大的，平常咱们可能会约某个工夫，同时在线一起来实现。这次各种起因吧，也比较忙，往后兴许就会放弃这种模式了 （对多时区的合作比拟敌对）。 Istio 1.13.1 公布在之前的 《K8S 生态周报| Istio 行将公布重大安全更新，多个版本受影响》 中，我曾介绍过 Istio v1.13 的次要性能，以及 Istio 会在 v1.13.1 中修复一个重大安全漏洞 CVE-2022-23635。 ...

在金融行业数字化转型的驱动下，国有银行、股份制银行和各级商业银行也纷纷步入容器化的过程。 如果以容器云上生产为指标，那么整个容器云平台的设计、建设和优化对于银行来说是一个微小的挑战。如何更好地利用云原生技术，帮忙银行实现麻利、轻量、疾速、高效地进行开发、测试、交付和运维一体化，从而重构业务，推动金融科技的倒退，是个长期课题。 因而，twt社区主办了主题为“银行高并发交易类场景下，容器云架构如何保障高性能、高可靠性“的线上交流活动，吸引了泛滥来自银行一线的技术大咖参加交换。咱们将干货整理出来，以“金融云原生漫谈”系列文章的模式陆续出现。 很多银行会抉择自建容器云平台，或者间接采纳成熟的K8s发行版，不论是哪种计划，容器云如何与银行本身的继续集成系统、测试服务零碎，或者DevOps流水线进行无效对接，更好地晋升IT零碎产品研发效力和交付效率，是值得咱们去深刻思考的问题。 家喻户晓，传统瀑布式开发动辄耗时数月甚至数年，无奈满足业务疾速变动和竞争的需要，只有引入继续交付和 DevOps，掌控从开发、测试到运维的利用全生命周期，能力打造出疾速迭代、与业务同频的利用，为企业发明盈利的价值链。 云原生技术的呈现，为DevOps插上了翅膀，能够更加充沛地利用云原生基础设施，基于微服务架构体系和开源规范，晋升继续交付和智能自运维的能力，从而做到比传统DevOps更高的服务质量、更低的开发运维老本，让研发专一于业务的疾速迭代。 过来的几年间，灵雀云有幸服务了超过半数的全国性股份制银行和泛滥商业银行，在这些银行业的云原生实际中发现，银行在设计容器云平台的时候，能够通过以下几点无效地晋升各类利用产品的研发效力和交付效率： 如何利用容器云晋升研发效力首先，银行本身的继续集成系统、测试服务零碎或者DevOps流水线工具，咱们倡议尽可能应用开源工具来建设，目标次要是让整个产品研发的工具链体系和开发流程更加灵便，目前咱们看到有大量中小银行都在采纳开源工具链来进行DevOps工具体系的建设。 同时，倡议引入一些凋谢的能够整合这些开源工具链的产品，例如灵雀云的DevOps开放平台，充沛尊重银行原来应用的开源工具链，通过工具链集成的模式简化银行DevOps工具体系建设的复杂性，对立DevOps工具链全链路管理能力。 其次，扭转利用的交付形式。原来传统的以二进制Jar包、War包为制品的交付形式，最好对立成以规范容器镜像包为制品的交付形式进行交付，须要留神的是，要严格标准业务利用运行的中间件版本或者利用运行环境等，例如限定JDK的某几个罕用版本，Tomcat的某几个罕用版本等，同时尽可能应用轻量化、可容器化的中间件作为业务利用的运行环境，例如tomcat、nginx等，不倡议应用websphere、weblogic这种比拟重的并且对于容器化不够敌对的中间件产品。 最初，倡议引入Service Mesh这种下一代微服务网格技术，简化产品研发的人力资源投入，晋升整个产品的服务治理和全局可视化治理的能力。 如何利用容器云晋升交付效率首先，容器云平台肯定要提供凋谢的API对接能力，目前市面上支流的容器云平台都是基于Kubernetes技术倒退进去的，所以Kubernetes的原生对接能力是十分重要的； 其次，银行本身的继续集成系统、测试服务零碎或者DevOps流水线须要具备和容器云平台对接的能力，例如这些麻利开发工具能够间接调用Kubernetes的API来主动进行利用的继续公布； 另外，倡议容器云平台最好能够提供一部分DevOps CD的性能，在银行现有麻利开发工具无奈进行容器云平台API对接的状况下，能够通过例如基于制品更新为触发条件的自动化继续公布能力。 灵雀云在银行的云原生转型实际上曾经有了很多胜利的落地案例，银行能够通过灵雀云的银行业容器PaaS解决方案，搭建自主可控、自下而上的云治理技术平台，实现IT基础设施从硬件化IT到软件化IT的转变，更好地晋升产品研发效力和交付效率。

大家好，我是张晋涛。 本篇我来为你介绍一个我集体很喜爱的，通用策略引擎，名叫 OPA，全称是 Open Policy Agent。 在具体聊 OPA 之前，咱们先来聊一下为什么须要一个通用策略引擎，以及 OPA 解决了什么问题。 OPA 解决了什么问题在理论的生产环境中很多场景中都须要策略管制，比方： 须要策略管制用户是否可登陆服务器或者做一些操作；须要策略管制哪些项目/哪些组件可进行部署；须要策略管制如何拜访数据库；须要策略管制哪些资源可部署到 Kubernetes 中； 然而对于这些场景或者软件来说，配置它们的策略是须要与该软件进行耦合的，彼此是不对立，不通用的。治理起来也会比拟凌乱，带来了不小的保护老本。 OPA 的呈现能够将各处配置的策略进行对立，极大的升高了保护老本。以及将策略与对应的软件/服务进行解耦，不便进行移植/复用。 OPA 的倒退过程OPA 最后是由 Styra 公司在 2016 年创立并开源的我的项目，目前该公司的次要产品就是提供可视化策略管制及策略执行的可视化 Dashboard 服务的。 OPA 首次进入 CNCF 并成为 sandbox 级别的我的项目是在 2018 年， 在 2021 年的 2 月份便曾经从 CNCF 毕业，这个过程相对来说还是比拟快的，由此也能够看出 OPA 是一个比拟沉闷且利用宽泛的我的项目。 OPA 是什么后面咱们曾经介绍过 Open Policy Agent (OPA) 是一种开源的通用策略引擎，可在整个堆栈中实现对立、上下文感知的策略管制。 OPA 可将策略决策与应用程序的业务逻辑拆散（解耦），透过景象看实质，策略就是一组规定，申请发送到引擎，引擎依据规定来进行决策。 图 3 ，OPA 的策略解耦示例 OPA 并不负责具体任务的执行，它仅负责决策，须要决策的申请通过 JSON 的形式传递给 OPA ，在 OPA 决策后，也会将后果以 JSON 的模式返回。 ...

大家好，我是张晋涛。 在前两篇内容中，我别离为大家介绍了 GitOps 的概念，以及用于施行 GitOps 的工具 Argo CD。本篇咱们将以一个示例我的项目为大家介绍 Argo CD 的实际。 创立集群咱们通过 KIND（Kubernetes in Docker）工具创立一个用于本地测试的 Kubernetes 集群。应用如下的配置文件，创立一个蕴含一个 control plane 和三个 work 的集群。 kind: ClusterapiVersion: kind.x-k8s.io/v1alpha4nodes:- role: control-plane- role: worker- role: worker- role: worker应用如下命令进行集群的创立： ➜ (MoeLove) kind create cluster --config=kind-config.yaml Creating cluster "kind" ... ✓ Ensuring node image (kindest/node:v1.20.2) ✓ Preparing nodes ✓ Writing configuration ✓ Starting control-plane ️ ✓ Installing CNI ✓ Installing StorageClass ✓ Joining worker nodes Set kubectl context to "kind-kind"You can now use your cluster with:kubectl cluster-info --context kind-kindHave a nice day! 执行如下命令期待集群齐全 Ready： ...

大家好，我是张晋涛。 接下来会为大家带来一个 GitOps 的利用实际系列文章，这是第一篇。 什么是 GitOps首先咱们来理解下 GitOps： GitOps 最早是在2017年由 Weaveworks 创建提出，它是一种进行 Kubernetes 集群治理和应用程序交付的形式。 GitOps 应用 Git 作为申明性基础设施和应用程序的繁多事实起源。 GitOps 的核心思想是领有一个 Git repository，蕴含指标环境中以后所需基础设施的申明性形容，以及使指标环境与 Git repository 中形容的状态相匹配的自动化过程。借助 GitOps，能够针对 Git repository 与集群中运行的内容之间的任何差别收回警报，如果存在差别，Kubernetes reconcilers会依据状况自动更新或回滚集群。 以 Git 作为 pipeline 的核心，开发人员能够应用本人相熟的工具收回PR，以减速和简化 Kubernetes 中应用程序部署和操作工作。 这使得 GitOps 在 Twitter 和 KubeCon 上引起了不小的轰动。 这里说一下Weaveworks 这家公司，这是一家为开发人员提供最高效的形式来连贯、察看和管制 Docker 容器的公司。在官网上，咱们能看到，GitOps 工作流的准则和模式，如何实现它们在生产中大规模运行 Kubernetes， 以及GitOps 和基础设施即代码 (IAC) 配置管理工具之间的区别和最佳实际等等。https://www.weave.works/techn... K8S的创始人之一：Kelsey Hightower 曾发推文评论过 GitOps是基于申明式基础设施的版本化 CI/CD， 进行脚本化操作，开始（自动化）散发。 GitOps 是如何工作的呢？把环境配置作为 Git repositoryGitOps 以代码库为外围来组织部署。 咱们须要至多有两个仓库：利用程序库和环境配置库。 利用程序库蕴含应用程序的源代码和部署应用程序的 manifests。 环境配置库蕴含部署环境以后所需基础架构的所有部署manifests。 它形容了哪些应用程序和基础设施服务（音讯代理、服务网格、监控工具等）应该在部署环境中以何种配置和版本运行等内容。 ...

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。KIND v0.11.0 正式公布KIND (Kubernetes In Docker) 关注我的小伙伴想必曾经都很相熟了，这是我始终都在参加也用的十分多的一个我的项目，它能够很不便的应用 Docker 容器作为 Kubernetes 的 Node ，疾速的启动一个/或多个测试集群。自上个版本公布以来曾经过了 4 个月，咱们一起来看看这个版本中有哪些值得注意的变更吧！ 破坏性变更在这个版本中默认的 k8s 版本为 v1.21.1;移除掉了应用 bazel 构建镜像的形式，kind build node-image 的 --type 参数已废除；kind build node-image 的 --kube-root 参数已废除，将会依照规范模式寻找 k8s 的代码目录的地位；新个性kind build node-image 新增了一个 --arch 的参数，可反对构建多架构的镜像了；KIND 以后公布的预构建镜像，曾经都是 multi-arch 的了，可运行在 amd64 和 arm64 架构上；以后 KIND 曾经能够运行在 rootless 模式下的 Docker 和 rootless 模式下的 Podman 中了，具体指南请参考 KIND 运行在 rootless 模式 ;KIND 默认的 CNI kindnetd 曾经反对了双栈网络, 并在 v1.21 版本的 k8s 中默认启用 ;你能够通过以下任意形式装置最新版的 KIND ： ...

作者 | 肖长军（穹谷）阿里云智能事业群技术专家   导读：随着云原生系统的演进，如何保障系统的稳定性受到很大的挑战，混沌工程通过反脆弱思想，对系统注入故障，提前发现系统问题，提升系统的容错能力。ChaosBlade 工具可以通过声明式配置执行混沌实验，简单高效。本文将会重点介绍 ChaosBlade 以及云原生相关的实验场景实践。ChaosBlade 介绍ChaosBlade 是阿里巴巴开源的一款遵循混沌实验模型的混沌实验执行工具，具有场景丰富度高、简单易用等特点，而且可以很方便的扩展实验场景，开源后不久就被加入到 CNCF Landspace 中，成为主流的一款混沌工具。 实验场景目前支持的实验场景如下： 基础资源场景：CPU 负载、内存占用、磁盘 IO 负载、磁盘占用、网络延迟、网络丢包、网络屏蔽、域名不可访问、shell 脚本篡改、杀进程、进程 Hang、机器重启等；应用服务场景：支持 Java 应用和 C++ 应用内的实验场景。Java 的场景组件丰富，例如支持 Dubbo、RocketMQ、HttpClient、Servlet、Druid等，而且支持编写 Java 或 Groovy 脚本实现复杂的实验场景；容器服务场景：支持 Kubernetes 和 Docker 服务，包含 node、pod 和 container 三种资源的实验场景，例如 Pod 网络延迟、丢包等。混沌实验模型 以上所有的实验场景都遵循混沌实验模型，此模型共分为四层，包含： Target：实验靶点。指实验发生的组件，如容器、应用框架（Dubbo、Redis）等；Scope：实验实施的范围。指具体触发实验的机器或者集群等；Matcher：实验规则匹配器。根据所配置的 Target，定义相关的实验匹配规则，可以配置多个。由于每个 Target 可能有各自特殊的匹配条件，比如 RPC 领域的 Dubbo，可以根据服务提供者提供的服务和服务消费者调用的服务进行匹配，缓存领域的 Redis，可以根据 set、get 操作进行匹配；Action：指实验模拟的具体场景，Target 不同，实施的场景也不一样，比如磁盘，可以演练磁盘满，磁盘 IO 读写高等。如果是应用，可以抽象出延迟、异常、返回指定值（错误码、大对象等）、参数篡改、重复调用等实验场景。比如一台 IP 是 10.0.0.1 机器上的应用，调用 com.example.HelloService[@1.0.0 ]() Dubbo 服务延迟 3s，基于此模型可以描述为对 Dubbo 组件（Target）进行实验，实验实施的范围是 10.0.0.1 主机（Scope），调用 com.example.HelloService[@1.0.0 ]() （Matcher）服务延迟 3s（Action），对应的 chaosblade 命令为： ...

作者 | 阿里巴巴高级技术专家  叶磊 一、Kubernetes 基本网络模型本文来介绍一下 Kubernetes 对网络模型的一些想法。大家知道 Kubernetes 对于网络具体实现方案，没有什么限制，也没有给出特别好的参考案例。Kubernetes 对一个容器网络是否合格做出了限制，也就是 Kubernetes 的容器网络模型。可以把它归结为约法三章和四大目标。 约法三章的意思是：在评价一个容器网络或者设计容器网络的时候，它的准入条件。它需要满足哪三条？ 才能认为它是一个合格的网络方案。四大目标意思是在设计这个网络的拓扑，设计网络的具体功能的实现的时候，要去想清楚，能不能达成连通性等这几大指标。约法三章先来看下约法三章： 第一条：任意两个 pod 之间其实是可以直接通信的，无需经过显式地使用 NAT 来接收数据和地址的转换；第二条：node 与 pod 之间是可以直接通信的，无需使用明显的地址转换；第三条：pod 看到自己的 IP 跟别人看见它所用的IP是一样的，中间不能经过转换。后文中会讲一下我个人的理解，为什么 Kubernetes 对容器网络会有一些看起来武断的模型和要求。 四大目标四大目标其实是在设计一个 K8s 的系统为外部世界提供服务的时候，从网络的角度要想清楚，外部世界如何一步一步连接到容器内部的应用？ 外部世界和 service 之间是怎么通信的？就是有一个互联网或者是公司外部的一个用户，怎么用到 service？service 特指 K8s 里面的服务概念。service 如何与它后端的 pod 通讯？pod 和 pod 之间调用是怎么做到通信的？最后就是 pod 内部容器与容器之间的通信？最终要达到目标，就是外部世界可以连接到最里面，对容器提供服务。 对基本约束的解释对基本约束，可以做出这样一些解读：因为容器的网络发展复杂性就在于它其实是寄生在 Host 网络之上的。从这个角度讲，可以把容器网络方案大体分为 Underlay/Overlay 两大派别： Underlay 的标准是它与 Host 网络是同层的，从外在可见的一个特征就是它是不是使用了 Host 网络同样的网段、输入输出基础设备、容器的 IP 地址是不是需要与 Host 网络取得协同（来自同一个中心分配或统一划分）。这就是 Underlay；Overlay 不一样的地方就在于它并不需要从 Host 网络的 IPM 的管理的组件去申请 IP，一般来说，它只需要跟 Host 网络不冲突，这个 IP 可以自由分配的。为什么社区会提出 perPodperIP 这种简单武断的模型呢？我个人是觉得这样为后面的 service 管理一些服务的跟踪性能监控，带来了非常多的好处。因为一个 IP 一贯到底，对 case 或者各种不大的事情都会有很大的好处。 ...

作者： OAM 项目负责人 导读：2019 年 10 月 17 日，阿里巴巴合伙人、阿里云智能基础产品事业部总经理蒋江伟（花名：小邪）在 Qcon 上海重磅宣布，阿里云与微软联合推出开放应用模型 Open Application Model （OAM）开源项目。OAM的愿景是以标准化的方式沟通和连接应用开发者、运维人员、应用基础设施，让云原生应用管理与交付变得更加简洁，高效，并且可控。 OAM 为什么值得关注？ 关注点分离：开发者关注应用本身，运维人员关注模块化运维能力，让应用管理变得更轻松、应用交付变得更可控。平台无关与高可扩展：应用定义与平台层实现解耦，应用描述支持任意扩展和跨环境实现模块化应用运维特征：可以自由组合和支持模块化实现的运维特征描述Kubernetes 项目作为容器编排领域的事实标准， 成功推动了诸如阿里云 Kubernetes （ACK）等云原生服务的迅速增长。但同时我们也关注到，Kubernetes 的核心 API 资源比如 Service、Deployment 等，实际上只是应用中的不同组成部分，并不能代表一个应用的全部。也许我们可以通过像 Helm charts 这样的方式来尝试表达一个可部署的应用，可一旦部署起来，实际运行的应用中却依旧缺乏以应用为中心的约束模型。这些问题都反映出，Kubernetes 以及云原生技术栈需要一种以应用为中心的 API 资源来提供一个专注于应用管理的、标准的、高度一致的模型，这个 API 资源可以代表完整运行的应用本身，而不仅仅是应用模板或者一个应用的几个组成部分，这就是今天阿里云与微软联合宣布推出开放应用模型 Open Application Model （OAM）的原因。项目地址：https://openappmodel.io OAM 项目目前由规范和实现两部分组成 什么是 Open Application Model？OAM 是一个专注于描述应用的标准规范。有了这个规范，应用描述就可以彻底与基础设施部署和管理应用的细节分开。这种关注点分离（Seperation of Conerns）的设计好处是非常明显的。 举个例子，在实际生产环境中，无论是 Ingress ，CNI，还是 Service Mesh，这些表面看起来一致的运维概念，在不同的 Kubernetes 集群中可谓千差万别。 通过将应用定义与集群的运维能力分离，我们就可以让应用开发者更专注于应用本身的价值点，而不是”应用部署在哪“这样的运维细节。 此外，关注点的分离让平台架构师可以轻松地把平台的运维能力封装成可被复用的组件，从而让应用开发者能够专注于将这些运维组件与代码进行集成，从而快速、轻松地构建可信赖的应用。 Open Application Model 的目标是让简单的应用管理变得更加轻松，让复杂的应用交付变得更加可控。 一、应用组件（Components） 在 OAM 中，“应用”是由多个概念共同组合而成的。 第一个概念是：应用组件（Components），它是整个应用的重要组成部分。 所以说，应用组件既可以包括应用运行所依赖的服务：比如 MySQL 数据库，也包括应用服务本身：比如拥有多个副本的 PHP 服务器。 开发者可以把他们写的代码“打包”成一个应用组件，然后编写配置文件来描述该组件与其他服务之间的关系。 应用组件的概念，让平台架构师能够将应用分解成一个个可被复用的模块，这种模块化封装应用组成部分的思想，代表了一种构建安全、高可扩展性应用的最佳实践：它通过一个完全分布式的架构模型，实现了应用组件描述和实现的解耦。 ...

作者 | 张振 阿里巴巴高级技术专家 一、资源元信息1. Kubernetes 资源对象我们知道，Kubernetes 的资源对象组成：主要包括了 Spec、Status 两部分。其中 Spec 部分用来描述期望的状态，Status 部分用来描述观测到的状态。 今天我们将为大家介绍 K8s 的另外一个部分，即元数据部分。该部分主要包括了用来识别资源的标签：Labels， 用来描述资源的注解；Annotations， 用来描述多个资源之间相互关系的 OwnerReference。这些元数据在 K8s 运行中有非常重要的作用。 2. labels第一个元数据，也是最重要的一个元数据——资源标签。资源标签是一种具有标识型的 Key：Value 元数据，如下图所示，展示了几个常见的标签。 前三个标签都打在了 Pod 对象上，分别标识了对应的应用环境、发布的成熟度和应用的版本。从应用标签的例子可以看到，标签的名字包括了一个域名的前缀，用来描述打标签的系统和工具， 最后一个标签打在 Node 对象上，还在域名前增加了版本的标识 beta 字符串。 标签主要用来筛选资源和组合资源，可以使用类似于 SQL 查询 select，来根据 Label 查询相关的资源。 3. Selector最常见的 Selector 就是相等型 Selector。现在举一个简单的例子： 假设系统中有四个 Pod，每个 Pod 都有标识系统层级和环境的标签，我们通过 Tie：front 这个标签，可以匹配左边栏的 Pod，相等型 Selector 还可以包括多个相等条件，多个相等条件之间是逻辑”与“的关系。 在刚才的例子中，通过 Tie=front,Env=dev 的 Selector，我们可以筛选出所有 Tie=front，而且 Env=dev 的 Pod，也就是下图中左上角的 Pod。另外一种 Selector 是集合型 Selector，在例子中，Selector 筛选所有环境是 test 或者 gray 的 Pod。 ...

作者|张磊 阿里云容器平台高级技术专家，CNCF 官方大使 一、为什么需要 Pod容器的基本概念我们知道 Pod 是 Kubernetes 项目里面一个非常重要的概念，也是非常重要的一个原子调度单位，但是为什么我们会需要这样一个概念呢？在使用容器 Docker 的时候，也没有这个说法。其实，如果想要理解 Pod，首先要理解容器，所以来回顾一下容器的概念：容器的本质实际上是一个进程，是一个视图被隔离，资源受限的进程。容器里面 PID=1 的进程就是应用本身，这意味着管理虚拟机等于管理基础设施，因为我们是在管理机器，但管理容器却等于直接管理应用本身。这也是之前说过的不可变基础设施的一个最佳体现，这个时候，你的应用就等于你的基础设施，它一定是不可变的。在以上面的例子为前提的情况下，Kubernetes 又是什么呢？很多人都说 Kubernetes 是云时代的操作系统，这个非常有意思，因为如果以此类推，容器镜像就是这个操作系统的软件安装包，它们之间是这样的一个类比关系。 真实操作系统里的例子如果说 Kubernetes 就是操作系统的话，那么不妨看一下真实的操作系统的例子。例子里面有一个程序叫做 Helloworld，这个 Helloworld 程序实际上是由一组进程组成的，需要注意一下，这里说的进程实际上等同于 Linux 中的线程。因为 Linux 中的线程是轻量级进程，所以如果从 Linux 系统中去查看 Helloworld 中的 pstree，将会看到这个 Helloworld 实际上是由四个线程组成的，分别是 {api、main、log、compute}。也就是说，四个这样的线程共同协作，共享 Helloworld 程序的资源，组成了 Helloworld 程序的真实工作情况。这是操作系统里面进程组或者线程组中一个非常真实的例子，以上就是进程组的一个概念。 那么大家不妨思考一下，在真实的操作系统里面，一个程序往往是根据进程组来进行管理的。Kubernetes 把它类比为一个操作系统，比如说 Linux。针对于容器我们前面提到可以类比为进程，就是前面的 Linux 线程。那么 Pod 又是什么呢？实际上 Pod 就是我们刚刚提到的进程组，也就是 Linux 里的线程组。 进程组概念说到进程组，首先建议大家至少有个概念上的理解，然后我们再详细的解释一下。还是前面那个例子：Helloworld 程序由四个进程组成，这些进程之间会共享一些资源和文件。那么现在有一个问题：假如说现在把 Helloworld 程序用容器跑起来，你会怎么去做？当然，最自然的一个解法就是，我现在就启动一个 Docker 容器，里面运行四个进程。可是这样会有一个问题，这种情况下容器里面 PID=1 的进程该是谁? 比如说，它应该是我的 main 进程，那么问题来了，“谁”又负责去管理剩余的 3 个进程呢？这个核心问题在于，容器的设计本身是一种“单进程”模型，不是说容器里只能起一个进程，由于容器的应用等于进程，所以只能去管理 PID=1 的这个进程，其他再起来的进程其实是一个托管状态。 所以说服务应用进程本身就具有“进程管理”的能力。比如说 Helloworld 的程序有 system 的能力，或者直接把容器里 PID=1 的进程直接改成 systemd，否则这个应用，或者是容器是没有办法去管理很多个进程的。因为 PID=1 进程是应用本身，如果现在把这个 PID=1 的进程给 kill 了，或者它自己运行过程中死掉了，那么剩下三个进程的资源就没有人回收了，这个是非常严重的一个问题。反过来，如果真的把这个应用本身改成了 systemd，或者在容器里面运行了一个 systemd，将会导致另外一个问题：使得管理容器不再是管理应用本身了，而等于是管理 systemd，这里的问题就非常明显了。比如说我这个容器里面 run 的程序或者进程是 systemd，那么接下来，这个应用是不是退出了？是不是 fail 了？是不是出现异常失败了？实际上是没办法直接知道的，因为容器管理的是 systemd。这就是为什么在容器里面运行一个复杂程序往往比较困难的一个原因。这里再帮大家梳理一下：由于容器实际上是一个“单进程”模型，所以如果你在容器里启动多个进程，只有一个可以作为 PID=1 的进程，而这时候，如果这个 PID=1 的进程挂了，或者说失败退出了，那么其他三个进程就会自然而然的成为孤儿，没有人能够管理它们，没有人能够回收它们的资源，这是一个非常不好的情况。 ...

作者 | 阿里巴巴资深技术专家  雷卷，GitHub ID @linux-china 导读：在 Python、JavaScript 等一众编程语言崛起风靡之际，一代霸主 Java 风采虽不及当年，但仍横扫了各大编程语言排行榜，依旧是各大企业级应用开发语言中的 NO.1。从 Java 8 之后，Java 引入了很多有用的新语言特性，以及新工具和性能改善。但是仍有非常多的同学在日常开发中没有切换到 Java 8 的后续版本。本篇文章将侧重开发方向，为大家介绍后 Java 8 时代的特性。首先我们必须承认，Java 8 是一个里程碑式的版本，这个相信大多数Java程序员都认同，其中最知名的是 Streams & Lambda ，这让 Functional Programming 成为可能，让 Java 焕发新的活力。这也是即便 Oracle 不在支持 Java 8 的更新，各个云厂商还是积极支持，站点为https://adoptopenjdk.net/，可以让 Java 8 能继续保留非常长的时间。 目前非常多的同学日常开发并没有切换到 Java 8 后续的版本，所以这篇文章，我们打算写一个后 Java 8 时代的特性，主要是偏向于开发的，不涉及 GC , Compiler , Java Module , Platform 等，如果一一解释，估计非常长的文章，当然后续可以写另外文章介绍。下面的这些特性会影响到我们日常的代码编写。 考虑到 Java 13 马上发布，所以版本覆盖从 9 到 13 ，与此同时 Java Release 的方式调整，一些特性是在某一版本引入(preview)，后续收到反馈后做了非常多的增强和完善，这里就不一一说明特性是哪个版本的，你可以理解为后Java 8版本后的特性大杂烩。参考资料来源于官方 features 和 pluralsight 上每一个版本的 Java 特性介绍。 ...

文章来源：云原生实验室，点击查看原文。 导读：Kubernetes 作为云原生时代的“操作系统”，熟悉和使用它是每名用户（User）的必备技能。如果你正在 Kubernetes 上工作，你需要正确的工具和技巧来确保 Kubernetes 集群的高可用以及工作负载的稳定运行。本篇文章将为你详细介绍 6 个实用的 Kubernetes 开源工具，千万不要错过。前言随着 Kubernetes 的发展和演变，人们可以从内部来驯服它的无节制行为。但有些人并不情愿干等 Kubernetes 变得易于使用，并且为已投入生产的 Kubernetes 中遇到的很多常见问题制定了自己的解决方案。 这里我们将介绍一些提高操作效率的技巧，同时列举几个比较有用的开源 Kubernetes 工具，这些工具以各种方式简化 Kubernetes，包括简化命令行交互，简化应用程序部署语法等。 kubectl 自动补全kubectl 这个命令行工具非常重要，与之相关的命令也很多，我们也记不住那么多的命令，而且也会经常写错，所以命令自动补全是很有必要的，kubectl 工具本身就支持自动补全，只需简单设置一下即可。 bash 用户大多数用户的 shell 使用的是 bash，Linux 系统可以通过下面的命令来设置： $ echo "source <(kubectl completion bash)" >> ~/.bashrc$ source ~/.bashrc如果发现不能自动补全，可以尝试安装 bash-completion 然后刷新即可！ zsh 用户如果你使用的 shell 是 zsh，可以通过下面的命令来设置： $ echo "source <(kubectl completion zsh)" >> ~/.zshrc$ source ~/.zshrc自定义 kubectl get 输出kubectl get 相关资源，默认输出为 kubectl 内置，一般我们也可以使用 -o json 或者 -o yaml 查看其完整的资源信息。但是很多时候，我们需要关心的信息并不全面，因此我们需要自定义输出的列，那么可以使用 go-template 来进行实现。 go-template 是 golang 的一种模板，可以参考 template 的相关说明。 比如仅仅想要查看获取的 pods 中的各个 pod 的 uid，则可以使用以下命令： ...

作者 | 易立 阿里云资深技术专家 导读：从十余年前的各种分布式系统研发到现在的容器云，从支撑原有业务到孵化各个新业务，企业的发展离不开统一的、与时俱进的技术架构。本篇文章从企业分布式应用架构层面介绍了云原生计算架构带来的变化，希望能够帮助更多企业的 IT 转型，利用云计算技术推动其成为市场竞争中的敏捷力量。 进入 21 世纪以来，我们见证了企业分布式应用架构从 SOA(Service-oriented Architecture)，到微服务架构，再到云原生应用架构的演化。 为了说明企业架构演化背后的思考，我们先谈一些玄学。 第一，企业 IT 系统的复杂性（熵）符合热力学第二定律。随着时间的推演，业务的变化，企业 IT 系统的复杂度会越来越高。第二，在计算机交互设计中有一个著名的复杂性守恒定律。应用交互的复杂性不会消失，只会换一种方式存在。这个原理也同样适用于软件架构。引入新的软件架构，不会降低IT系统的整体复杂性。听到这里，是否让生命不息、折腾不止的我们感到一丝凉凉？:-) 现代软件架构的核心任务之一就是定义基础设施与应用的边界，合理切分复杂性，减少应用开发者需要面对的复杂性。换句话说，就是让开发者专注在核心价值创新上，而把一些问题交给更合适的人和系统来解决。 我们就从下面这张图开始，探究企业分布式应用架构演进背后的逻辑。 本图来自 Bilgin Ibryam 的 twitter 蜕变之痛 - SOA2004 年，IBM 建立 SOA 全球设计中心，我作为研发 TL 和架构师参与了一系列全球客户的 pilot 项目，帮助 Pepboys, Office Depot 等国际企业利用 SOA 优化企业内部和企业间的业务流程，提升业务敏捷性。 当时的大背景是：随着经济全球化逐渐深入，企业面对的竞争加剧，商业变革也开始提速。在大型企业内部的 IT 系统已经经过了数十年的演化。整个的技术体系变得异常复杂，并存着诸如主机系统上的 CISC/COBOL 交易应用，小型机 AS400 中的 RPG 业务系统，和 X86/Power 等分布式系统的 C/JEE/.Net 应用。 大量应用系统由三方供应商提供，一些系统甚至已经无人维护。而且随着业务迭代，一些新的业务系统被持续构建出来，由于缺乏合理的方法论指导，系统之间缺乏有机的链接，形成了若干的孤岛，持续加剧了 IT 架构的复杂性，无法支撑业务的发展诉求。这就仿佛各派高手为了帮助受伤的令狐冲，把异种真气输入体中，虽然短时间可以缓解伤势。可是多道真气无法融合，互相激荡，长时间下来会伤上加伤。 因此，企业 IT 所面临的首要挑战就是整合企业中大量竖桶型（silo-ed）的 IT 系统，支撑日益复杂的业务流程，进行高效的业务决策和支撑业务快速变化。在这种背景下，IBM 等公司提出了 SOA（面向服务的架构）理念，将应用系统抽象成一个个粗粒度的服务，构建松耦合服务架构，可以通过业务流程对服务进行灵活组合，提升企业 IT 资产复用，提高了系统的适应性、灵活性和扩展性，解决“信息孤岛”问题。 ...

业界要闻1.CNCF 公布 Kubernetes 的安全审计报告 报告收集了社区对 Kubernetes、CoreDNS、Envoy、Prometheus 等项目的安全问题反馈，包含从一般弱点到关键漏洞。报告帮项目维护人员解决已识别的漏洞，并给出了一系列最佳实践。 2.技术监督委员会（TOC）投票决定将 rkt 项目归档 尽管 rkt 在 2014 年 12 月创建最初很受欢迎，并在 2017 年 3 月贡献给 CNCF，但其采纳程度已严重下降，很多用户已经从 rkt 转向了如 containerd、CRI-O 等其它项目。 上游重要进展 Kubernetes 项目1.支持 readonly 的接口指定不同的网卡； https://github.com/kubernetes/enhancements/issues/1208 2.在 Kubectl 中进行 pod 问题定位分析；https://github.com/kubernetes/enhancements/pull/1204/fileshttps://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190212-ephemeral-containers.md#alternatives 方式：在运行时对已有的 pod，新增一个 ephemeral container 挂载到这个 pod 的 spec 下面，然后 status 中也会有一个 EphemeralContainers 的 debug 容器信息： a. Debug Container Namingb. Container Namespace Targeting：shared process namespacec. Interactive Troubleshooting and Automatic Attaching: ...

【编者的话】“人间四月芳菲尽，山寺桃花始盛开。” 越来越多专门给 Kubernetes 做应用发布的工具开始缤纷呈现，帮助大家管理和发布不断增多的 Kubernetes 应用。在做技术选型的时候，我们需要给业务选择一个最好的工具、最稳的底座。那我们又该如何比较和衡量这些工具的呢？在这篇文章中阿里一线工程师给大家分享自己独特的体验。洗尽铅华，一起品味这“山寺桃花”。 背景近年来，伴随着云原生社区（CNCF Community）的迅猛发展，越来越多的应用跑在了 Kubernetes 上。慢慢地，大家的关注点也逐渐从资源层转移到应用层。一方面，我们看到在有越来越多新的 Kubernetes Operators 出现，用来自动化应用的部署和运维。另一方面，随着各路大型云厂商入场，Kubernetes 服务以后就会像家里的水和电一样随心所欲可用，自己再去动手搭建已经没有了意义。于是人们提出了“Kubernetes 将会消失”，这其实指的是以 Kubernetes 为底座来面向全世界任何一个云以及数据中心交付应用，会是接下来的必然趋势。关于这个趋势，我们团队的同学专门写过一篇关于《云原生时代， Kubernetes 多集群架构初探》的文章，欢迎大家进一步阅读。 Tekton 项目有什么特殊之处？基于 Kubernetes 做应用发布的工具，我们有着许多选择，其中不乏业界知名项目 Jenkins X、Spinnaker，也有创业公司出来的小工具比如 Argo Rollout。不过在这其中，我们团队现在主要使用的是 Tekton。这里也有个重要的背景，那就是我们团队要面向多云/多集群交付的，是复杂有状态的阿里巴巴中间件应用。这因素我马上会详细介绍到。 可能还有部分同学还不了解 Tekton 项目是什么？这里我先简单介绍下。Tekton 是一款 Kubernetes 原生的应用发布框架，主要用来构建 CI/CD 系统。它原本是 Knative 项目里面一个叫做 build-pipeline 的子项目，用来作为 knative-build 的下一代引擎。然而，随着 Kubernetes 社区里各种各样的需求涌入，这个子项目慢慢成长为一个通用的框架，能够提供灵活强大的能力去做基于 Kubernetes 的构建发布。 可能不少同学会感到疑惑，有这么多功能丰富、声名远扬的项目，为什么我们选择了灰姑娘般的 Tekton？客官别急，容我们先来梳理一下这个平台底座的要求： Kubernetes 原生：流程和概念，尤其是面向用户的部分，需要融入到 Kubernetes 体系中。此外，最好能跟生态里的其他工具互相连通，成为生态的一环。举个例子：Spinnaker 这个项目是很强大的，但它的设计初衷，是面向公有云进行应用交付用的（以虚拟机为运行时），Kubernetes 只是它所支持的一种 Provider，并且 Provider 还得用 Groovy 写集成插件。这就使得它跟 Kubernetes 的协作是比较别扭的。灵活扩展：基本上所有工具都不能够满足我们复杂多变的业务需求。这些工具架构本身需要提供足够灵活的扩展性，来快速定制实现所需功能。举个例子：Argo Rollout 本身的应用发布，是跟 Kubernetes 的 Workload （比如 Deployment ）耦合在一起的。这就不是一个很具备扩展性的做法。最简单的例子：对于复杂有状态应用来说，大多都是用 Operator 或者 OpenKruise 管理的，这时候 Argo Rollout 该怎么办呢？轻量级：工具本身不能做得“太重”，即不能有太多的组件或太多的概念。小而轻的项目初期易上手、中期易交付、后期易维护。 举个例子：Spinnaker 虽然功能强大，但是这也就意味着它把所有的事情都帮你做了。而我们团队要发布的应用是复杂有状态的中间件应用， 是需要我们写自己的 Rollout Controller 来控制发布流程的。这个要基于 Spinnaker 来做，还得大量做二次开发了，于是原有的众多功能和组件反而成了负担。白盒化：运行中的管道、步骤等需要“白盒化”，即对外暴露状态。这样才能跟前端工具联通，给用户展示实时状态信息。举个例子：Tekton 其实只提供 Pipeline 这个一个功能，Pipeline 会被直接映射成 Kubernetes Pod 等 API 资源。而比如应用发布过程的控制，灰度和上线策略，都是我们自己编写 Kubernetes Controller 来实现的，这个可控度其实是我们比较喜欢的。另外，这种设计，也就意味着 Tekton 不会在 Kubernetes 上盖一个“大帽子”，比如我们想看发布状态、日志，就等是直接通过 Kubernetes 查看这个 Pipeline 对应的 Pod 的状态和日志，不需要再面对另外一个 API。接下来我们在几个候选项目之间做比较： ...

为什么我们需要多集群？近年来，多集群架构已经成为“老生常谈”。我们喜欢高可用，喜欢异地多可用区，而多集群架构天生就具备了这样的能力。另一方面我们也希望通过多集群混合云来降低成本，利用到不同集群各自的优势和特性，以便使用不同集群的最新技术（如 AI、GPU 集群等）。 就是因为这种种原因，多集群几乎成为了云计算的新潮流，而被谈及最多并且落地的多集群场景主要有这三类： 一类用于应对“云突发”。如下图 1 所示，正常情况下用户使用自己的 IDC 集群提供服务，当应对突发大流量时，迅速将应用扩容到云上集群共同提供服务，将多集群作为备用资源池。该模式一般针对无状态的服务，可以快速弹性扩展，主要针对使用 CPU、内存较为密集的服务，如搜索、查询、计算等类型的服务。图 1：多集群“云突发”场景 第二类用于“云容灾”。如下图 2 所示，通常主要服务的集群为一个，另一个集群周期性备份。或者一个集群主要负责读写，其他备份集群只读。在主集群所在的云出现问题时可以快速切换到备份集群。该模式可用于数据量较大的存储服务。图 2：多集群“云容灾”场景 第三类则用于“异地多活”。如图 3 所示，与“云容灾”的主要区别是数据是实时同步的，多集群都可以同时读写。这种模式通常针对极其重要的数据，如全局统一的用户账号信息等。图 3：多集群，异地多活场景 但是多集群同时也带来了巨大的复杂性，一方面如何让应用可以面向多集群部署分发，另一方面是希望应用真正能做到多集群之间灵活切换，想到传统应用迁移的难度可能就已经让我们望而却步了。面向多集群，我们依然缺乏足够成熟的应用交付和管理的能力。 多集群的最后一公里早在 2013 年，不少老牌云计算厂商就已经在聊“为什么要多集群”，并开始倡导多集群是“Next Big Thing”。 然而残酷的现实却是，每一个不同的云、每一个数据中心都是一套自己的 API 与设计方式，所谓“多集群”多数情况下只是厂商 A 主动集成不同类型集群的一套接入层。 这种背景下的多集群一直以来都以架构复杂著称，具体表现就是各个厂商发布会上令人眼花缭乱的多集群 / 混合云解决方案架构图，如下 图 4 就是一个传统的多集群企业级解决方案架构图，不得不说，我们很难完全理解图中的所有细节。图 4：传统的多集群企业级解决方案架构图 这种背景下的多集群技术，其实更像是厂商对一个封闭产品的代名词。不同厂商的云有不同的 API、不同的能力特性，厂商们在这之上架构的多集群、混合云解决方案，大量的精力都是在适配和整合不同集群平台上的各类能力。 而对于用户，最终的结果又会是另一种形式的绑定。这样的多集群无法形成生态，也许这就是我们迟迟无法面向这种多集群构建统一的应用交付、构建真正多集群能力的原因。 Kubernetes：全世界数据中心的统一 API不过，伴随着云原生理念的迅速普及，“步履蹒跚”的多集群理念却迎来了一个非常关键的契机。 从 2015 年 CNCF 成立到现在，短短四年多的时间，其组织下就孵化了数十个项目，吸引了近四百位企业级会员的加入，项目贡献人数达到六万三千多人，而每年参与 CNCF 官方活动的人数也早已超过了十万人， CNCF Lanscape 下符合云原生标准的项目已经达到了上千个。 这种 Kubernetes 以及云原生技术体系迅速崛起的直接结果，就是在所有公有云之上， Kubernetes 服务都已经成为了毋庸置疑的一等公民；而全世界几乎所有的科技公司和大量的企业终端用户，也都已经在自己的数据中心里使用 K8s 来进行容器化应用的编排与管理。 不难看到，Kubernetes 正在迅速成为全世界数据中心的统一 API。 图 5：云原生的曙光 这层统一而标准的 API 之下，多集群和混合云的能力才开始真正体现价值。 ...

业界要闻 IBM 以总价 340 亿美元完成里程碑意义的红帽收购：这是这家拥有 107 年历史的公司史上规模最大的一笔收购，该收购金额在整个科技行业的并购史上也能排到前三。在当天公布的声明中，IBM 与 Red Hat 联合表示，双方合作将重点推进“混合云”业务，即让公司客户自身服务器上的数据与云服务进行对接，这一方案兼顾了传统企业IT服务解决方案以及新兴的基于云服务的解决方案，是最现实可行的一种路径选择。 Garnter 发布 2018 年全球云计算市场数据：据 Gartner 统计，2018 年全球云计算市场向头部进一步集中， 3A (亚马逊 AWS、微软 Azure、阿里云)占据七成市场份额。亚马逊依旧领跑，但市场份额已经见顶回撤。微软和阿里云均有市场份额增长，其中阿里云保持 3A 军团中最快增长，市场份额增长近一倍。而在另外 Gartner 一份《数据库的未来就是云》报告中，3A 同样位列前三。阿里云的市场份额在 DBMS 供应商中排名第三，同比增长 116%。目前阿里云云原生产品家族已经纳入了数据库核心产品，阿里云 Kubernetes 服务 （ACK） 通过与阿里云旗舰数据库产品 PolarDB 深度结合，正在帮助用户同时实现应用层面的快速弹性和数据层面无限扩容。 上游重要进展 Kubernetes 项目Kubernetes 设计增强（KEP）:（a）  如何开发 K8s 自定义调度器插件？上周，上游 Scheduler Framework 插件开发的第一个指导性文档发布， 其中列出了几种开发调度插件方式的利弊: 直接 Vendor 上游 Scheduler 代码库，然后基于其中的 Framework 库开发插件 （推荐）通过 Golang Plugin 机制: 这个方法对 Golang 版本依赖严重，跨版本无法使用；对启动和部署也带来很多挑战；通过 hashicorp/go-plugin 机制: 使用方式不友好，复杂；性能较前两种方案差（b） Sidecar KEP（Pod 中允许声明某些容器为 Sidecar，从而更精细化的管理这些容器的生命周期）详细解读： ...

作者|元毅 阿里云智能事业群高级开发工程师 相信通过前面几个章节的内容，大家对 Knative 有了初步的体感，那么在云原生时代如何在云上玩转 Knative？本篇内容就给你带来了 Knative 应用在阿里云容器服务上的最佳实践。 何为最佳实践，就是按照生产可用的方式部署服务，提供服务监控告警以及链路追踪。我们按照如下 3 个部分内容进行： Knative Service 服务部署Knative Service 服务日志、监控告警Knative Service 服务分布式链路追踪 准备参考在阿里云容器服务上部署Knative。 这里注意在部署 Istio 时需要开启 Tracing 分布式追踪。 Knative Service 服务部署执行 kubectl 命令：$kubectl apply -f helloworld-go.yaml其中 helloworld-go.yaml 示例内容： apiVersion: serving.knative.dev/v1alpha1kind: Servicemetadata: name: helloworld-go namespace: defaultspec: template: spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4db7 env: - name: TARGET value: "Knative"查看 istio-ingressgateway 服务。[root@iZbp11kx5d8so7gb07fbtkZ samples]# kubectl -n istio-system get svc istio-ingressgatewayNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEistio-ingressgateway LoadBalancer 172.21.5.96 101.37.100.85 15020:30816/TCP,80:31380/TCP,443:31390/TCP,15443:31412/TCP 19d执行 kubectl 如下命令，获取 Domin 信息[root@iZbp11kx5d8so7gb07fbtkZ samples]# kubectl get ksvc helloworld-go NAME URL LATESTCREATED LATESTREADY READY REASONhelloworld-go http://helloworld-go.default.example.com helloworld-go-skcpl helloworld-go-skcpl True最后执行 curl -H "Host: helloworld-go.default.example.com" http://101.37.100.85 可以获取执行的结果[root@iZbp11kx5d8so7gb07fbtkZ samples]# curl -H "Host: helloworld-go.default.example.com" http://101.37.100.85Hello Knative! ...

以容器、服务网格、微服务、Serverless 为代表的云原生技术，带来一种全新的方式来构建应用。同时，云原生也在拓展云计算的边界，一方面是多云、混合云推动无边界云计算，一方面云边端的协同。在云的趋势下，越来越多的企业开始将业务与技术向“云原生”演进。 在这个演进过程中，企业都或多或少都面对一些困惑与挑战，其中如何将应用和软件向 Kubernetes 体系进行迁移、交付和持续发布是一个普遍的难题。 阿里巴巴从 2011 年开始通过容器实践云原生技术体系，在整个业界都还没有任何范例可供参考的大背境下，从最初独自摸索到拥抱开源回馈社区，阿里巴巴逐渐摸索出了一套比肩全球一线技术公司并且服务于整个阿里集团的容器化基础设施架构。九年的前行，让阿里巴巴在交流互动中不断吸收和贡献好的理念、技术、思想，也积累了最为丰富和宝贵的实践经验。 2019 年 6 月 24 日至 6 月 26 日，由 Cloud Native Computing Foundation (CNCF) 主办的云原生技术大会 KubeCon + CloudNativeCon + Open Source Summit（上海 ），阿里巴巴在大会上为全球企业和开发者分享了 26 场实践经验、行业趋势和技术演讲，我们筛选了其中 15 场有代表性的演讲进行重新编排成书，旨在全面揭秘阿里巴巴云原生之路上的探索与实践，为准备踏上云原生之旅的开发者，提供一些实践参考。 如何下载电子书的专页链接：https://developer.aliyun.com/special/mvp/cloudnative 你为什么要读这本书在云原生领域，开发者的诉求和使用方法永远是丰富的、复杂的、多样的。在这种背景下，短时间内很难有技术能够大一统地解决开发者面临的所有问题，阿里巴巴内部对云原生的探索也一直在进行中。从外向内引入社区技术，让阿里巴巴的基础设施完成了一次自我升级，并变得更加开放标准；从内向外的输出，对社区提出有价值的代码，推动整个云原生社区向更大规模的方向演进。 本书整合阿里巴巴九年云原生技术沉淀，分析真实的技术案例，发现问题，理清思路，解决问题，总结方法，把自我成长和专业精进的技术养料，回馈给广大云原生开发者。本书包含 3 个系列，阿里云原生实践，阿里新技术方案及阿里开源贡献，共 16 篇文章。每篇文章都凝结着阿里巴巴云原生落地实践的宝贵经验和面对困惑的解决方法，相信能够在最短的时间内，帮助你全面了解阿里巴巴云原生实践经验，踏上最适合自己的云原生之路。 本书目录 书中精彩干货集合 《坚持探索与落地开源，阿里巴巴云原生之路全景揭秘》阿里云已经成功地规模化落地云原生，本文将分享阿里巴巴具体的云原生实践经验分享给各位观众，涉及规模扩展、可靠性、开发效率、迁移策略等方面，并探讨针对大规模场景进行优化。 Cloud native works for Alibaba. Cloud native  works for (almost) everyone. 《1-5-10：如何快速恢复大规模容器故障》在云时代，企业中基于容器的应用激增，由于人工操作、硬件故障等，发生容器故障的可能性大幅增加。因此，如何在不增加资源投入的情况下保证大规模容器的可靠性成为云平台面临的一个巨大挑战。阿里巴巴运行着数百万个容器，为恢复容器相关故障提出了 1-5-10 理论：MTTD（平均检测时间）为 1 分钟，MTTI（平均识别时间）为 5 分钟，MTTR（平均解决时间）为 10 分钟。我们将讨论如何利用 1-5-10 提高大规模容器的可靠性： ...

继上月KubeCon SH之后，阿里云峰会上海站 开发者大会也为大家准备了一场云原生盛宴。2019年7月24日下午13:30，上海世博中心，云原生场景实战分论坛即将开启！ 云原生不但可以很好的支持互联网应用，也在深刻影响着新的计算架构、新的智能数据应用。以容器、服务网格、微服务、Serverless为代表的云原生技术，带来一种全新的方式来构建应用。我们认为以容器为主的云原生技术会继续发展，被应用于“新的计算形态”，“新的应用负载”和“新的物理边界”，在此将相关观察和新思考分享给大家。 本场分论坛将围绕阿里云云原生新产品动态，与当下最前沿的技术应用趋势相结合，与各位开发者及用户分享实战场景新的。

系列介绍：这个系列是介绍如何用云原生技术来构建、测试、部署、和管理应用的内容专辑。做这个系列的初衷是为了推广云原生应用管理的最佳实践，以及传播开源标准和知识。在这个系列文章的开篇初探云原生应用管理（一）: Helm 与 App Hub中，我们介绍了如何用 Helm 来快速部署 K8s 应用。在本篇文章我们将跟你聊聊，为什么要尽快转向 Helm V3。 在研究了一番“开放云原生应用中心（AppHub）”之后，程序员小张似乎已经明白了“云原生应用”到底是怎么一回事情。 “不就是 Helm 嘛！” 说话间，小张就准备把自己开发多年的“图书馆管理系统”通过 Helm 打包成 Charts ，提交到 AppHub上个线试试。 “这样，全中国的开发者就都能使用到我开发的图书馆管理系统了！” 想想还有点小激动呢！ 然而，还没等编译完，小张就发现 Helm 官方文档上有这么一句提示非常辣眼睛： 这，到底是咋回事儿？ Helm 项目的缘起Helm 是目前云原生技术体系中进行应用管理最被广泛使用的开源项目，没有之一。根据 CNCF 刚刚发布的 KubeCon EU 2019 的总结报告，Kubernetes（ k8s ），Prometheus 和 Helm 这三个项目，再次蝉联 KubeCon 上最被关注的开源项目前三名。 Helm 项目本身的发布，则要追述到 Deis 还是一家独立创业公司的时代。  2016 年，容器 PaaS （所谓的 CaaS ）创业方兴未艾，但也开始呈现出同质化竞争和低附加值的种种苗头，而在这片红海当中，当时已经委身卖给 Engine Yard 的 Deis 尤其步履维艰。幸运的是，敏锐的技术嗅觉最终还是“拯救”了这个的团队。 2016 年底，Deis 开始全面转向 K8s 体系，很快就发布了一系列专门为 k8s 进行应用管理的开源项目。这其中，定位为“ k8s 应用包管理器”的 Helm ，是最受欢迎的一个。 ...

系列介绍：初探云原生应用管理系列是介绍如何用云原生技术来构建、测试、部署、和管理应用的内容专辑。做这个系列的初衷是为了推广云原生应用管理的最佳实践，以及传播开源标准和知识。通过这个系列，希望帮助大家学到 Kubernetes、Helm、Gitops、Kustomize 等新知识。 这是大厂程序员小张普普通通的一个早晨，大家好像在讨论着什么： “什么？听说隔壁公司在用 K8s 发布应用了？” “据说在用 Helm ！” 像往常，小张根本不关心这些无聊的讨论。他稳稳的坐在办公桌前，打开公司内部自研的、魔改 Gitlab  打造的项目管理系统，点击了好几个 Button 之后，开始一天辛勤的劳作。 但这一次不知道为何，小张的内心居然有点慌：“ Helm？啥是 Helm ?” ------ 分割线 ------ Helm:  K8s 应用部署与打包工具如果一个用户想要部署起来一个K8s 应用，最快捷的方法是什么呢？ 我们知道，Kubernetes (简称 k8s ) 是一个能够部署和管理容器的平台。然而，在 k8s 里还没有抽象到“应用”这一层概念。一个应用往往由多个 k8s 资源 ( Deployment、Service、ConfigMap ）组成。所以，我们需要一个工具在 k8s 之上来部署和管理一个应用所包含的资源（ K8s API Resource ），这就是 Helm 所做的事情。 除此以外，Helm 定义了一套 Chart 格式来描述一个应用。怎么理解 Chart 呢？打个比方，一个安卓程序打包成 APK 格式，就可以安装到任意一台运行安卓系统的手机上。如果我们把 k8s 比做安卓系统，K8s 应用比做安卓程序，那么 Chart 就可以比做 APK。这也意味着，K8s 应用只要打包成 Chart ，就可以通过 Helm 部署到任意一个 k8s 集群上。 ...

本周作者 | 衷源、心贵 业界要闻1、Kubernetes Release v1.15 版本发布，新版本的两个主题是持续性改进和可扩展性。（https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#kubernetes-v115-release-notes）2、Helm 这款包管理工具, 作为业界 Kubernetes 上应用分发的事实标准，其 v3.0.0-alpha.1 正式发布，这是 Helm 3 的第一个  Alpha 版本。（https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1）3、Google 的 Dropout 专利生效，有效期 15 年。Dropout 是深度学习的一种基础算法，对人工智能行业影响巨大。4、Rancher 2.3 Preview 发布，通过一个简单以及友好的界面，用户即可使用 istio。(https://github.com/rancher/rancher/releases/tag/v2.3.0-alpha5)5、Talos 发布。Talos 是一款专门用于部署Kubernetes的操作系统。相对于 CoreOS，RancherOS 或者 LinuxKit 这些容器操作系统，Talos 更为精简。(https://github.com/talos-systems/talos)6、 Google 推出深度学习容器，包括 TensorFlow 1.13，TensorFlow 2.0，PyTorch 和 R 语言容器。 上游重要进展Kubernetes v1.15 版本发布Kubernetes Release v1.15 版本，新版本的两个主题是持续性改进和可扩展性。其中持续性改进着重于提高核心组件的可靠性和稳定性，同时修复一些遗留的问题；而可扩展性关注着重关注在 CRD 和 Webhook 的改进和优化上。我们就这两个主题讲述一些值得关注的特性和改进。v1.15 版本的发布意味着不仅我们可以更加便捷的管理集群和扩展集群，同时新版本的集群的稳定性更加坚固。 可靠性和稳定性 新引入 WatchBookmark 特性。该特性能大大提高 Kube-Apiserver 的 List/Watch 性能，大家都知道，大规模集群下各个组件的 List/Watch 会消耗 Kube-Apiserver 巨大的性能开销，有了该特性，我们可以展望未来的集群规模又可以上升一个台阶。 (#74074, @wojtek-t)Admission 默认开启 StorageObjectInUseProtection。StorageObjectInUseProtection 能保护正在使用的 PV/PVC 被误删除。这对手速太快的开发和 SRE 同学是一个很大的福音。(#74610, @oomichi)蚂蚁金服在大规模实践中，发现 Daemonset 有各种发布和部署 Pod 被卡住的问题，蚂蚁同学对 Daemonset Controller 可能发生的一系列死锁问题做了修复。参考：https://github.com/kubernetes/kubernetes/pull/78974https://github.com/kubernetes/kubernetes/pull/77773https://github.com/kubernetes/kubernetes/pull/77208https://github.com/kubernetes/kubernetes/pull/78170 ...

2019年6月24日，KubeCon+CloudNativeCon+Open Source Summit再次登陆中国，在上海世博中心拉开了帷幕。来自亚洲各国的逾3500名研发专家、架构师和技术领袖共同参与了本次盛会，现场分享、普及、探讨和推动Kubernetes生态及云原生技术的发展。 业界领先的容器管理软件提供商Rancher Labs（以下简称Rancher）作为本届活动的铂金赞助商深度参与了此次盛会。大会期间，Rancher展台持续爆满，挤满了前来交流的Kubernetes爱好者及云原生技术领军者。 那么，在本次KubeCon+CloudNativeCon+Open Source Summit，Rancher为现场的Kubernetes爱好者、云原生技术领军者带来了哪些惊喜呢？让我们一起来快速回顾一下吧！ 关注边缘技术创新，拓宽K8S发展新边界 为了更好地向现场的Kubernetes爱好者及云原生技术领军者展示如何通过Rancher推动K8S在云端、数据中心和边缘落地，Rancher大中华区技术总监江鹏在Demo Theater（展示剧场）进行了题为《如何在云端、数据中心和边缘统一管理K8S集群》的Demo演示，内容包括： 如何安装k3s集群：一个仅40MB的轻量级开源Kubernetes发行版在数据中心和边缘管理Kubernetes集群多集群应用程序部署Global DNS集成2019年，Rancher一连发布三个重磅的轻量级新品——史上最轻量级Kubernetes发行版k3s、业内首个Kubernetes操作系统k3OS以及Kubernetes极简MicroPaaS平台Rio，获得了业界的高度关注和一致好评。这些项目均专注于轻量级、简单且灵活的Kubernetes项目，为Kubernetes提供更为广泛的使用场景，真正做到Kubernetes Everywhere。 “多集群Kubernetes管理已经逐渐成为被大众所接受的一个概念，这是Rancher在Kubernetes层面上的创新和尝试。接下来，我们希望更多地去关注边缘节点的技术创新，真正地把K8S带到所有的地方，为边缘计算创造价值。”Rancher联合创始人及CEO梁胜表示：“k3s是Rancher目前比较成功的一个开源项目，但我们非常清楚，在边缘计算这个方向，我们还有很多的工作要做。” 推动企业级K8S落地，深度赋能行业生态 容器技术的发展存在周期性，Kubernetes正从初创期走向成熟期，变成一个被云计算服务提供商及数据中心广泛应用的商品。除了k3s之外，在本次活动，Rancher还为现场的Kubernetes爱好者及云原生技术领军者带来企业级多集群K8S管理平台Rancher的演示。 2019年3月，Rancher发布了Rancher 2.2 GA版本，Rancher 2.2 GA版本是Rancher Labs迄今为止最重要的产品版本，在先前发布过的2.2技术预览版本中，已经释出了诸如支持多集群应用程序、集成的Prometheus高级监控等功能。Rancher 2.2 GA的主要新功能亮点包括： Rancher Global DNS集群的灾备与恢复多集群、多租户的进阶版监控功能单一应用跨多Kubernetes集群的部署与管理多租户应用程序目录“随着Kubernetes的采用呈指数级增长，企业IT人员一直在寻求一种简单、可靠和可重复的方式来配置、管理和支持企业级Kubernetes集群，且越来越多企业的Kubernetes集群是跨本地环境与云环境混合部署的。”梁胜表示：“Rancher 2.2中创造性的新功能，将极大简化IT运维人员对企业级Kubernetes的配置与管理工作，同时让企业IT开发人员对其应用程序拥有更强把控。” 持续创新，一切开源 一直以来，Rancher都是Kubernetes和容器领域的领导者玩家，在Kubernetes和容器生态领域具备相当高的认可度和强大的影响力。Rancher是CNCF的核心成员，也是CNCF的元老级会员。Rancher Labs联合创始人Shannon Williams是CNCF管理委员会的委员。除此之外，Rancher还是全球首批获得CNCF Kubernetes一致性认证的平台。 本届KubeCon+CloudNativeCon+Open Source Summit已圆满落下帷幕，但在未来，Rancher将秉承“只有在企业生产环境中落地的技术和产品才是好技术和好产品”的产品理念，持续为用户提供领先的容器技术和产品，让企业在生产环境中更简单而稳妥地落地。

越来越多的读者在和我交流关于Spring Cloud Alibaba的种种事宜，甚至于在一次面试中，一半时间都在聊这个话题。所以，本着对技术钻研的热情，对Spring Cloud Alibaba进行了一番研究。 在这里，并不想高谈阔论，也不想预言未来，只是挑选了几个从阿里巴巴中间件团队内脱胎出来的开源组件，对于解决实际业务问题有所裨益。 一、背景先来说说大背景。 现在，很明显的一个趋势就是：微服务。 这个趋势的底层驱动力就来源于分布式系统的普及，而微服务的各个特性是如今大大小小的企业无法拒绝的诱惑。 然后，用上了微服务的架构风格，用Spring Cloud，或者Dubbo搭了一套脚手架，就开始干起来了。 接下来，一众小公司画完了大饼之后，发现自己根本吃不下。这就是典型的落后劳动力与先进生产力的尖锐矛盾。这个时候，返璞归真的想法是不能有了，重构代价太大。 当然，哪里有问题，哪里就有商机。各大XX云厂商经过一系列包装之后，用“云原生(Cloud Native)”的新概念粉墨登场。 Spring Cloud Alibaba就是其中之一。 这个概念的一个核心价值就是：平滑上云，赋能运维。最明显的业务表象就是，会提供一套Open API，甚至是贴心的提供一个可视化控制台，傻瓜式的那种。 二、从NACOS说起这是一颗耀眼的掌上明珠，迅速引起了我的注意。 按照套路，分为两讲。其一讲述NACOS的功能特性，及其使用，再者就是更深入一步，看看大厂的攻城狮们写的代码。 本文所使用的版本是NACOS 1.0.0，由于此版本还是第一个NACOS正式版，NACOS正处在飞速发展阶段，本文的一些内容可能会不适用于以后的版本，请读者自行辨别。 NACOS解决两个核心问题：动态配置管理，服务注册发现。 兼容性方面，除了支持自家的Dubbo，还对Spring Cloud，Kubernetes，Istio有所兼容。 对照以上的全景图，现在的NACOS还有一段距离，但是并不遥远。 至此，不说道说道Eureka，都有点过意不去了。 我用下来的体验是：NACOS完全可以替代Eureka了。 江山代有才人出，这是必然的结果。 在“云原生”的大背景之下，NACOS顺利成章的推出了Console，将触角进一步延伸至服务的精细化管理。 当然，不排除Eureka也在憋大招。 再说说动态配置的特性。 当然，NACOS略胜一筹，可替代Spring Cloud Config了。 原先在Git/SVN上托管的配置项，都可以在Console上统一管理了。 如果想先睹为快，可以接下着往下读。如果想再多了解一些，可以直接跳过这部分，阅读下一个小节。 可以把NACOS理解成是一个中心化的服务，这在阿里系的架构中屡见不鲜。所以，必须得先启动这个服务。 有两个办法：其一是直接clone源码，使用maven打包。第二个办法是直接下载GitHub release出来的压缩包。 推荐后者。 方法1：主要运行以下命令： git clone https://github.com/alibaba/nacos.git cd nacos/ mvn -Prelease-nacos clean install -U经过一段时间的构建过程，在./distribution/target目录下有我们想要的压缩包。 方法2：进入https://github.com/alibaba/nacos/releases，找到压缩包，下载。 为了演示，我们先用单机模式启动。 Windows环境下： startup.cmd -m standalone一切就绪的话，访问http://127.0.0.1:8848/nacos/index.html，使用nacos/nacos登录。 接下来，随便逛逛。 三、重要的概念为了避免在Console中迷失自我，有必要先阐述几个重要的概念。 这张图很重要。表述了namespace、group和service/dataId的包含关系。 NACOS给的最佳实践表明，最外层的namespace是可以用于区分部署环境的，比如test，uat，product等。同时，也有一个商业利用价值：多租户。以namespace为单位，给用户开辟使用空间。 其它两个领域模型不用多解释了，见名知意。其目的也非常明显，就是为了能够逻辑上区分两个目标对象。 默认情况下，namespace=public，group=DEFAULT_GROUP。 明白了这个数据模型后，可以稍微玩转一下Console了，比如新建若干个namespace： ...

原文链接：Service Mesh 时代，Dubbo 架构该怎么跟进？，来自于微信公众号：次灵均阁作为 Duboo 核心开发者，请先简单介绍下自己答：大家好，我是小马哥（mercyblitz），一名学习当爸爸的父亲，Java 劝退师，Apache Dubbo PMC、Spring Cloud Alibaba项目架构师，《Spring Boot 编程思想》的作者。目前主要负责集团中间件开源项目、微服务技术实施、架构衍进、基础设施构建等。 Spring Cloud 和 Duboo 在微服务方面的优劣分别是什么？答：在 Java 生态中，Spring Cloud 和 Dubbo 都是微服务框架。前者被业界常作为 Java 微服务的首选框架，而后者有时被错误地解读为服务治理的 RPC 框架。实际上，两者在微服务架构中并没有本质的差异，均是分布式应用服务治理的框架。 在开发体验方面，Spring Cloud 开箱即用的组件让人印象深刻。在 API 抽象和设计方面，流淌着 Spring 家族血液的 Spring Cloud 延续了父辈的荣耀。由此观之，Dubbo 与其存在差距。 然而随着实践的不断深入，Spring Cloud 功能的稳定性以及版本的兼容性等问题较为突出。当应用集群达到一定规模时，其分布式经验上的短板也随之暴露，尤其是 Spring Cloud Netflix 套件，比如 Eureka 与 Ribbon 之间的 90 秒延迟会影响服务调用的成功率，以及负载均衡算法缺少权重无法帮助 JVM 预热。简言之，在服务治理方面，Spring Cloud 相较于 Dubbo 而言，并不算太成熟。如果大家有兴趣了解更多的话，可参考「小马哥技术周报」。 总之，Spring Cloud 和 Dubbo 各有特色，过度地关注彼此优劣并不可取。为此，Spring Cloud Alibaba 项目综合两家之长，提供了一套名为 Dubbo Spring Cloud 的整容实现，使得 Dubbo 与 Spring Cloud 不再是互斥性选项。 ...