Knative

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Knative 中提供了自动扩缩容灵活的实现机制，本文从 三横两纵 的维度带你深入了解 KPA 自动扩缩容的实现机制。让你轻松驾驭 Knative 自动扩缩容。 注：本文基于最新 Knative v0.11.0 版本代码解读 KPA 实现流程图 在 Knative 中，创建一个 Revision 会相应的创建 PodAutoScaler 资源。在KPA中通过操作 PodAutoScaler 资源，对当前的 Revision 中的 POD 进行扩缩容。 针对上面的流程实现，我们从 三横两纵 的维度进行剖析其实现机制。 三横 KPA 控制器 根据指标定时计算 POD 数 指标采集 KPA 控制器 通过Revision 创建PodAutoScaler, 在 KPA 控制器中主要包括两个资源（Decider 和 Metric）和一个操作（Scale）。主要代码如下 func (c *Reconciler) reconcile(ctx context.Context, pa *pav1alpha1.PodAutoscaler) error { ...... decider, err := c.reconcileDecider(ctx, pa, pa.Status.MetricsServiceName) if err !=

【推荐】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(吐血整理) >>> 作者 | 丁海洋 陈有坤 李鹏 孙健波 业界要闻 阿里巴巴 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(吐血整理) >>> 点击下载《Knative 云原生应用开发指南》 自 2018 年 Knative 项目开源后，就得到了广大开发者的密切关注。Knative 在 Kubernetes 之上提供了一套完整的应用 Serverless 编排服务，让应用开发者可以不用为底层的基础设施分心，把更多的精力投入到业务逻辑上。 Knative 的一个很重要的目标就是制定云原生、跨平台的 Serverless 编排标准。它的优势在于： 基于 Kubernetes 实现 Serverless 编排； 基于 Istio 实现服务的接入、服务路由的管理以及灰度发布等功能。 今年 5 月份，我们推出了 Knative 系列文章，由阿里云容器平台技术专家牛秋霖（冬岛）及阿里云容器平台高级开发工程师李鹏（元毅）结合自身的实践经验，由浅入深的介绍了 Knative 的使用、剖析其内部实现。 为了进一步方便大家理解 Knative，我们整理了系列文章中的 25 篇重点内容编排成书《Knative 云原生应用开发指南》，并开放分享给大家，希望能够帮助更多技术爱好者快速掌握 Knative 的应用 Serverless 编排技能，揭开 Knative 的神秘面纱。 为什么你要读这本书？ 对于开发者而言，本书可以让你快速掌握 Knative 的应用

作者 | 牛秋霖（冬岛） 阿里云容器平台技术专家 关注“阿里巴巴云原生”公众号，回复关键词 “1205” 即可观看 Knative-Demo 演示视频。 导读 ：Serverless 无疑是当前最热的云原生话题，那么作为业务的开发人员或者运维人员咱们应该怎么看待这个事情？云原生和 Serverless 到底有什么关系？通过本次分享咱们将逐一揭开这些神秘的面纱。 通过本文您将了解到： Knative 是如何让普通的应用具备 Serverless 能力的？ 为什么说 Knative 是云原生的应用 Serverless 编排引擎？ Knative 为什么是由 Tekton 、Eventing 和 Serving 三个模块组成，以及这三个模块的协作方式。 本文共有四部分内容：首先咱们一起来看一下云的核心驱动力是什么，接着从这个核心驱动力出发看一下云原生应用是什么样子。然后咱们再一起来看看 Knative 到底给应用的云原生化带来了什么价值，最后咱们通过一个 Demo 亲身感受一下 Knative 带来的这些能力。 云的核心驱动力 在讨论云原生之前我们先来思考一下：为什么企业要上云、为什么技术人员要学习面向云的编程思维以及咱们应该怎么看待云这件事儿。 咱们先来剖析一下发生这些事情的核心驱动力，然后通过这个核心驱动力出发看看整个云原生技术栈是什么样子。 社会分工 我们先从一顿火锅谈起

本文整理自阿里云容器平台技术专家冬岛和阿里云高级工程师草谷的直播分享。 微服务注册中心治理的难点 微服务架构的一个核心理念就是让微服务之间解耦，每一个微服务都可以独立的横向扩展，但这也带来了一定的复杂性。 例如，当业务达到一定的规模之后，微服务的数量和单个微服务实例的数就会变的很多，从而导致微服务注册中心需要管理很多服务地址，同时还需要给所有的上下游提供服务注册和服务发现的能力。这无疑增加了微服务注册中心的维护难度。同时，微服务架构对注册中心的性能和稳定性提出了更高的要求，这给注册中心的运维开发人员，带来了不少的挑战。 此外，在服务升级的过程中需要手动的做灰度的迭代。而传统的部署模式存在一个很大的弊端，就是需要提前准备好资源并部署好应用，传统的部署模式不能很好的根据业务的实时请求做自动弹性，那么这部分提前准备的冗余资源就是极大的浪费。 可见，托管一个基于微服务架构的业务需要解决注册中心的问题，还需要解决应用实例弹性和流量管理的问题，最好还能让资源按需使用、按量付费。 针对上面的这些问题，今天我们给大家带来两款云产品：阿里云微服务引擎 MSE 和 阿里云容器服务 Knative。MSE 给您带来稳定可靠的注册中心服务，让您免去运维注册中心的烦恼。Knative 给您带来云原生应用 Serverless 编排的能力，让您的应用可以按需使用、按量付费，节省您的 IaaS 成本。

提到天气预报服务，我们第一反应是很简单的一个服务啊，目前网上有大把的天气预报 API 可以直接使用，有必要去使用 Knative 搞一套吗？杀鸡用牛刀？先不要着急，我们先看一下实际的几个场景需求： 场景需求 1：根据当地历年的天气信息，预测明年大致的高温到来的时间 场景需求 2：近来天气多变，如果明天下雨，能否在早上上班前，给我一个带伞提醒通知 场景需求 3：领导发话“最近经济不景气，公司财务紧张，那个服务器，你们提供天气、路况等服务的那几个小程序一起用吧，但要保证正常提供服务”。 从上面的需求，我们其实发现，要做好一个天气预报的服务，也面临内忧（资源紧缺）外患（需求增加），并不是那么简单的。不过现在更不要着急，我们可以使用 Knative 帮你解决上面的问题。 关键词 ：天气查询、表格存储，通道服务，事件通知 场景需求 首先我们来描述一下我们要做的天气服务场景需求： 1. 提供对外的天气预报 RESTful API 根据城市、日期查询（支持未来 3 天）国内城市天气信息 不限制查询次数，支持较大并发查询（1000） 2. 天气提醒 订阅国内城市天气信息，根据实际订阅城市区域，提醒明天下雨带伞 使用钉钉进行通知 整体架构 有了需求，那我们就开始如何基于 Knative 实现天气服务。我们先看一下整体架构： 通过 CronJob 事件源，每隔 3 个小时定时发送定时事件

上一期我们介绍了如何 基于 Knative Serverless 技术实现天气服务-上篇 ，首先我们先来回顾一下上篇介绍的内容： 通过高德天气 API 接口，每隔 3 个小时定时发送定时事件，将国内城市未来 3 天的天气信息，存储更新到表格存储 提供 RESTful API 查询天气信息 接下来我们介绍如何通过表格存储提供的通道服务，实现 Knative 对接表格存储事件源，订阅并通过钉钉发送天气提醒通知。 整体架构 回顾一下整体架构： 通过 CronJob 事件源，每隔 3 个小时定时发送定时事件，将国内城市未来 3 天的天气信息，存储更新到表格存储 提供 RESTful API 查询天气信息 通过表格存储提供的通道服务，实现 TableStore 事件源 通过 Borker/Trigger 事件驱动模型，订阅天气信息 根据订阅收到的天气信息进行钉钉消息通知。如明天下雨，提示带伞等 基于 Knative 实现天气服务-下篇 首先我们介绍一下表格存储提供的通道服务。通道服务（Tunnel Service）是基于表格存储数据接口之上的全增量一体化服务。通道服务为您提供了增量、全量、增量加全量三种类型的分布式数据实时消费通道。通过为数据表建立数据通道，您可以简单地实现对表中历史存量和新增数据的消费处理。通过数据通道可以进行数据同步、事件驱动、流式数据处理以及数据搬迁

Knative（发音为 kay-nay-tiv）是谷歌开源的一套 Serverless 架构方案，它扩展了 Kubernetes，提供了一组中间件，提高了构建可在本地、云和第三方数据中心等地方运行的现代化、以源为中心且基于容器的应用的能力。 Knative资源： 源码， https://github.com/knative 文档， https://github.com/knative/docs 教程，《 Knative 入门中文版 》 其他Serverless方案与参考： Spring Cloud Function - 基于 Spring Boot 的函数计算框架 Kubeless - Kubernetes 原生 Serverless 框架 VMware-Dispatch - 开源 Serverless 框架 Fn project - ServerLess 容器原生平台 OpenFaaS - 构建 Serverless 功能的框架 Serverless - 无服务器架构 1、knative架构简介 目前已经提供了以下组件： Build - 源到容器的构建编排 Eventing - 事件管理和交付 Serving - 请求驱动的计算 Knative 专注于解决容器为核心的 Serverless 应用的构建、部署和运行的问题，它构建在 Kubernetes 和 Istio 平台之上