OAM

作者 | 高相林、陈俊、陈有坤、敖小剑 业界要闻 国内首个 Kubernetes SIG-Cloud-Provider 子项目揭秘 阿里云作为坚定的云原生计算推动者，贡献了阿里云上运行 Kubernetes 的最佳开源组件，成为 SIG Cloud Provider 子项目的国内首个云厂商。2020 年 2 月 12 日上午 10：00，阿里云 Kubernetes 团队召开了首次线上网络研讨会。 什么技术，让阿里拿下国家技术发明奖？ 新年伊始，国家科学技术奖励大会在北京人民大会堂隆重举行。阿里云获得国家技术发明奖、国家科技进步奖两项国家大奖。这是互联网公司首次同时荣获两大国家科技奖，也实现了互联网公司在国家技术发明奖上零的突破。 CNCF 发布 containerd 旅程报告 该报告对 containerd 发展过程进行了总结和分析。 上游重要进展 Kubenetes Build Kubelet without Docker 该 KEP 旨在提出一个方案，使得编译 Kubelet 不再依赖 Docker 相关的代码。 Fix statefulset conversion 修复了 statefulset 相关资源转换中的 bug，该 bug 会导致无法多次 apply 同一个 statefulset。 Add code to fix kubelet/metrics memory

导读 ： OAM 是阿里巴巴联合微软在社区推出的一款用于构建和交付云原生应用的标准规范，旨在通过全新的应用定义、运维、分发与交付模型，推动应用管理技术向“轻运维”的方向迈进，全力开启下一代云原生 DevOps 的技术革命。 背景 OAM 是阿里巴巴联合微软在社区推出的一款用于构建和交付云原生应用的标准规范，之前我们已经发布过一系列介绍文章，为方便大家查阅，链接和介绍如下： 《4 个概念，1 个动作，让应用管理变得更简单》 ：具体而详实的介绍了 OAM 方方面面的细节； 《给 K8s API “做减法”：阿里巴巴云原生应用管理的挑战和实践》 ：介绍了我们在探索出 OAM 之前的一些实践背景以及为什么会自然而然地设计出 OAM 这样的应用模型； 《OAM 加持下的 Kubernetes PaaS 应用管理实践》 ：围绕目前常见的基于 Kubernetes 构建 PaaS 的各类解决方案，介绍了 OAM 如何将这些方案有机结合并最终统一，然后进一步的通过标准化模块化的组织，发挥生态的力量，使得彼此协作互惠互利成为可能； 《开放应用模型操作指南（一）：云服务“一键接入” OAM 体系》 ：以云资源为例，介绍了如何介入 OAM 体系的方法和实践。 在上面的几篇文章中，我们介绍了为什么云原生应用需要标准定义，以及 OAM 模型到底是什么样子的。今天则为大家介绍 OAM 本身有哪些价值

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者丨孙健波（天元） 阿里巴巴技术专家 导读 ： DevOps 这个概念 最早是在 2007 年提出 的，那时云计算基础设施的概念也才刚刚提出没多久，而随着互联网的逐渐普及，应用软件的需求爆发式增长，软件开发的理念也逐渐从瀑布模型（waterfall）转向敏捷开发（agile）。 传统的软件交付模式（应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行），再也无法满足互联网软件快速迭代的需求。于是， DevOps 作为一种打破研发和运维之间隔阂、加快软件交付流程、提高软件交付质量的文化理念和最佳实践 逐渐普及至今。 DevOps 的现状 DevOps 的流行得益于业界对于应用软件敏捷开发、高质量交付的诉求，所以为开发和运维开辟了一块“公共的空间”，让双方可以在这里紧密合作。那时软件研发依旧属于一个新兴行业，人们习惯于向成熟的制造业学习，制造业解决大规模生产的方式，就是构建流水线，通过流水线规范化每个步骤对接的内容，而流水线上的工人们则只需要各司其职，快速熟练的完成自己这部分生产内容。 所以，DevOps 借鉴了制造业的经验，开始构建持续集成/持续交付（CI/CD）的流水线，催生出了一系列自动化/半自动化工具（如puppet、chef、ansible等），结合编写脚本的可扩展能力

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 划重点 2019 年公众号发布的文章共有 1452870 字，相当于 2 本《新华字典》 2019 年这些历程我们一起走过 1月 阿里巴巴李响入选 CNCF 技术监督委员会 9 人名单 阿里云成国内唯一入选 Gartner 公布《公有云容器服务竞争格局》报告企业 2月 阿里云开源 GPU Sharing，首次解决行业 GPU 资源共享调度痛点 3月 阿里云云原生产品家族公布，国内最全 蚂蚁金服加入阿里中间件开源分布式事务项目 Fescar，并贡献了 TCC 模式，Fescar 随即品牌升级为 Seata 4月 阿里云与 CNCF 共同开发的《CNCF x Alibaba 云原生技术公开课》正式上线 分布式任务调度平台 SchedulerX 2.0 公有云全面上线 阿里云链路追踪云产品正式商业化，提供基于 OpenTracing 规范的全链路追踪解决方案 阿里云消息队列 RabbitMQ 版正式商业化发布 5月 KubeCon EU 2019 在巴塞罗那举办，阿里巴巴共有 10 个技术演讲入选 Apache Dubbo 从 Apache 基金会孵化器毕业，成为顶级项目 阿里云 ARMS 云产品上线 Prometheus 监控云服务，国内首次推出云原生及周边生态的可观测性解决方案 阿里巴巴张乎兴成为 Apache

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者 | 邓洪超 阿里云容器平台软件工程师 导读 ： Open Application Model（OAM） 是阿里云联合微软等国际顶级技术团队联合发布的开放应用模型技术。旨在通过全新的应用定义、运维、分发与交付模型，推动应用管理技术向“轻运维”的方向迈进，全力开启下一代云原生 DevOps 的技术革命。本《开放应用模型操作指南》系列文章，将为广大技术人员（研发、运维、基础设施工程师）提供接地气的、体系化的 OAM 操作和接入指南。 前言 自 OAM 标准推出以来，越来越多的平台和服务开始接入 OAM 标准，朝着 BaaS (Backend as a service) 化的方向迈进。在阿里巴巴集团，我们见证了 EDAS、内部中间件交付平台等以 OAM 的方式打造和推出应用交付和运维产品。并且，ROS、PolarDB 等以开放的姿态逐步接入 OAM 作为跨平台集成方案。 随着跟终端用户和平台提供方的交流日益增多，我们也同时更加清楚地了解到在 OAM 集成各个平台和服务的时候还是有一些不一致、不标准的地方。举些例子，DB 等资源创建起来后连接信息该如何暴露，已有的资源定义该如何模型化成 OAM，什么应该作为 Workload？什么应该作为 Trait 等等。这些问题在不同团队的解决方式是类似却有些许差异的

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者 | 孙健波、汪萌海、陈有坤、李鹏 业界要闻 CNCF 宣布 TUF 毕业 CNCF 宣布 TUF（The update Framework）项目正式毕业，成为继 Kubernetes、Premetheus、Envoy、CoreDNS、containerd、Fluentd Jaeger 以及 Vitess 之后，第九个正式毕业的项目。TUF 是一项用于保护软件更新系统的开源安全技术，也是从云原生计算基金会毕业的第一个以规范与安全性为重点的项目。与此同时，TUF 还是首个源自高校的 CNCF 毕业项目。 Istio 发布安全公告 CVE-2019-18801：该漏洞通过向下游发送 HTTP/2 大 header 请求影响 Envoy 的 HTTP/1 编解码器，利用此漏洞可能导致拒绝服务、权限逃逸或信息泄露； CVE-2019-18802：HTTP/1 编解码器没有修剪掉 header 值之后的空格，使攻击者可以绕开 Istio 的策略，最终导致信息泄露或特权升级； CVE-2019-18838：收到不带 "Host" header HTTP 请求后， Envoy 路由管理器会由于空指针导致 Envoy 进程异常终止。 解决方案 对于 Istio 1.2.x 版本：升级到 Istio 1.2.10 或以上；

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文整理自孙健波在 ArchSummit 大会 2019 北京站演讲稿记录。首先介绍了阿里巴巴基于 Kubernetes 项目进行大规模应用实践过程中遇到的问题；随后会逐一介绍解决这些问题的现有实践及其本身存在的局限性；最后会介绍阿里巴巴目前正在进行的尝试和社区在这一领域的发展方向。 如今，阿里巴巴内部维护了数十个大规模的 K8s 集群，其中最大的集群约 1 万个节点，每个集群会服务上万个应用；在阿里云的 Kubernetes 服务 ACK 上，我们还维护了上万个用户的 K8s 集群。我们在一定程度上解决了规模和稳定性问题之后，发现其实在 K8s 上管理应用还有很大的挑战等着我们。 应用管理的两大难题 今天我们主要讨论这两个方面的挑战： 对应用研发而言，K8s API 针对简单应用过于复杂，针对复杂应用难以上手； 对应用运维而言，K8s 的扩展能力难以管理；K8s 原生的 API 没有对云资源全部涵盖。 总体而言，我们面临的挑战就是：如何基于 K8s 提供真正意义上的应用管理平台，让研发和运维只需关注到应用本身。 研发对应用管理的诉求 1. K8s all in one 的 YAML 文件 让我们来看一下这样一个 K8s 的 yaml 文件，这个 yaml 文件已经是被简化过的，但是我们可以看到它仍然还是比较长

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者 | 丁海洋 陈有坤 李鹏 孙健波 业界要闻 阿里巴巴 Kubernetes 技术能力再获 CNCF 认可 CNCF 官网发布博文《Demystifying Kubernetes as a Service – How Alibaba Cloud Manages 10,000s of Kubernetes Clusters》。这篇长文从为什么需要超大数量的 K8s 集群，以及如何高效的管理这些集群出发，系统介绍了 Alibaba 在 Kubernetes 上取得的成绩。 GitHub 欲在中国设立子公司 今年早些时候传出多起 Github 封锁伊朗、叙利亚、克里米亚等地区的 Github 账号，加上目前中美贸易战的大背景，Github 背后的微软需要为很多可能性进行准备。一个问题是：中国子公司真的可以在贸易战白热化的时候帮助微软和中国开发者吗？无论如何，多年来开源运动对当前 IT 技术的贡献大家有目共睹，而 Github（依然）是聚集开发者最好的平台，我想每一个负责任的开发者，无论国籍，都应该好好思考未来可能会如何，做好应对。 上游重要进展 Kubernetes Support external signing of service account keys 目前 K8s apiserver 还是从硬盘读取

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 导读 ：本文整理自孙健波在 ArchSummit 大会 2019 北京站演讲稿记录。首先介绍了阿里巴巴基于 Kubernetes 项目进行大规模应用实践过程中遇到的问题；随后会逐一介绍解决这些问题的现有实践及其本身存在的局限性；最后会介绍阿里巴巴目前正在进行的尝试和社区在这一领域的发展方向。 如今，阿里巴巴内部维护了数十个大规模的 K8s 集群，其中最大的集群约 1 万个节点，每个集群会服务上万个应用；在阿里云的 Kubernetes 服务 ACK 上，我们还维护了上万个用户的 K8s 集群。我们在一定程度上解决了规模和稳定性问题之后，发现其实在 K8s 上管理应用还有很大的挑战等着我们。 应用管理的两大难题 今天我们主要讨论这两个方面的挑战： 对应用研发而言，K8s API 针对简单应用过于复杂，针对复杂应用难以上手； 对应用运维而言，K8s 的扩展能力难以管理；K8s 原生的 API 没有对云资源全部涵盖。 总体而言，我们面临的挑战就是：如何基于 K8s 提供真正意义上的应用管理平台，让研发和运维只需关注到应用本身。 研发对应用管理的诉求 K8s all in one 的 YAML 文件 让我们来看一下这样一个 K8s 的 yaml 文件，这个 yaml 文件已经是被简化过的