Knative

作者 | 王思宇、汪萌海、李鹏 业界要闻 阿里云引领云原生进化，智能、互联、可信三位一体 阿里巴巴致力于为数字经济构建智能、互联、信任三位一体的创新基础设施，引领云原生进化新阶段。反观阿里云容器服务团队近期在 AI、边缘、机密计算三个领域的开源新动态，与智能、互联、信任的方向一一对应。 Chaos Mesh 项目加入 CNCF sandbox Chaos Mesh提供针对Kubernetes上复杂系统的故障注入方法，并涵盖了Pod，网络，文件系统甚至内核中的故障。 阿里云在 KubeCon 2020 峰会上展示什么大杀器？ KubeCon 2020 中国站，阿里云容器服务负责人易立会在《云原生，数字经济技术创新基石》的演讲中，分享阿里云原生如何助力数字技术抗“疫”，阐述阿里云对云原生操作系统的思考，同时详解阿里云 ACK Pro、ASM、ACR EE、ACK @Edge 四款企业级容器新品。 上游重要进展 make cadvisor metrics set configurable in kubelet Kubelet 支持可配置的 cadvisor metrics set。 Pod resource metrics 为 Pod resource 增加更通用的 metrics 统计。 Add cronjob controller v2 新增 CronJob 控制器 v2 版本。

本文整理自 ServerlessDay · China 大会 - 《从零到一，Serverless 平台在滴滴内部落地》分享，讲师滴滴弹性云平台负责人张健、滴滴资深前端开发工程师陈钦辉。滴滴 Serverless FT成员来自：滴滴基础平台部、车服技术部、金融事业部、普惠产品技术部。 为什么（前端）要推动建设 Serverless 更快地创建一个服务且免运维：大量的 Node.js 服务，创建服务，需要申请节点、申请机器，对接构建、部署、日志、监控，还要持续运维服。我们希望能更快创建一个服务并且免运维。 更灵活的隔离能力：前端 BFF 接口聚合、微前端等业务场景，需要创建大量的接口服务，快速创建服务的同时，还希望可以以不同粒度灵活进行接口间的隔离。 更低的成本：大量低峰期时间cpu/内存利用率很低，服务不再使用了，资源却仍然占用。 我们的方案 我们调研了业界的 Serverless 方案，最终决定了自己的方案： K8s + Knative + Istio 搭建应用级 Serverless。他的优势是： 社区相对繁荣，未来充满希望。 应用级 Serverless, 和传统通过 Docker 镜像开发，部署相近，现有服务迁移成本低。 应用级 Serverless, 通过 Serverless。 路由，可以灵活控制隔离的粒度。 通过 Serverless 升级研发模式 那有了

TCP端口的十一种连接状态∶ CLOSED ∶ 端口默认是关闭状态。 
 LISTEN ∶服务器程序开始监听一个端口，就是LISTEN状态。 
 

 SYN_RCVD ∶三次握手的第二次握手后的端口状态，是收到了客户端发送的SYN_SENT数据包之后的状态，这个状态很短暂，正常在服务器上是很少看到的，除非服务器故意不发送最后一次握手数据包，服务器返回给客户端sYN确认之后就会将在自己的端口置为 sYN_RCvD.
SYN_SENT ∶SYN_SENT状态表示客户端已发送SY=1的满求连接报文，发送之后客户端就会将自己的端口状态置为 SYN_SENT.
ESTABLISHED ∶表示已经连接成功，客户端收到服务器的确认报文会回复服务器，然后就将端口置为ESTABLISHED，服务器第三次收到客户端的Ack确认就会将端口置为ESTABLISHED并开始传输数据。 
 FTN_MAIT_1 ∶出现在主动关闭方，FIN._wAIT_1状态实际上是当soCkEr在ESTABLISHED状态时，当任意一方想主动关闭连接，向对方发送了FIN=1的断开连接请求报文，此时该soCkET即进入到IN_MAIT_1状态。而当对方回应ACK报文后，则进入到FINLMAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马 上回应ACK报文，所以FINMAIT_1状态一般是比较难见到的

格灵深瞳是一家全国领先的人工智能物联网科技企业。专注于把先进的人工智能科技转化为具备低成本、大规模部署能力的产品和服务，并深度结合应用场景，为用户提供高性能、 可靠实用的智慧解决方案。目前，在智慧安防、智能零售、智慧银行和新能源领域，为遍布全国和全世界的客户提供包含智能传感器、 智能识别、智能云计算和服务机器人的综合智能解决方案和服务。 随着业务的快速增长，需求迭代、资源投入、运维压力也随之变的越来越紧迫。怎样提升研发效能、保障业务快速上线，怎样提升资源利用效率、降低成本开销，怎样减少运维的压力、又能保障系统的可靠运转，逐渐成为我们的重点诉求。在此基础上，我们开始考虑引入新的技术，并做了一些调研，最终锁定了 Serverless 技术。 Serverless 想必大家或多或少都有接触，也是最近云计算领域非常火的一个技术方向，核心是帮用户屏蔽了底层的资源、提供按需请求、按需使用、按需付费的一种全新服务，像腾讯云的云函数 SCF 和对象存储等都是 Serverless 化的服务。在这里也和大家分享下，我们业务和 Serverless 是如何结合的。 我们考虑使用 Serverless 技术方案是经过一些调研，结合我们自己的业务需求最终决定的，主要有以下几点： 我们服务的客户与场景流量潮汐现象很明显，Serverless 自动弹性伸缩能力可以为我们解决这个问题，比起普通服务器

格灵深瞳是一家全国领先的人工智能物联网科技企业。专注于把先进的人工智能科技转化为具备低成本、大规模部署能力的产品和服务，并深度结合应用场景，为用户提供高性能、 可靠实用的智慧解决方案。目前，在智慧安防、智能零售、智慧银行和新能源领域，为遍布全国和全世界的客户提供包含智能传感器、 智能识别、智能云计算和服务机器人的综合智能解决方案和服务。 随着业务的快速增长，需求迭代、资源投入、运维压力也随之变的越来越紧迫。怎样提升研发效能、保障业务快速上线，怎样提升资源利用效率、降低成本开销，怎样减少运维的压力、又能保障系统的可靠运转，逐渐成为我们的重点诉求。在此基础上，我们开始考虑引入新的技术，并做了一些调研，最终锁定了 Serverless 技术。 Serverless 想必大家或多或少都有接触，也是最近云计算领域非常火的一个技术方向，核心是帮用户屏蔽了底层的资源、提供按需请求、按需使用、按需付费的一种全新服务，像腾讯云的云函数 SCF 和对象存储等都是 Serverless 化的服务。在这里也和大家分享下，我们业务和 Serverless 是如何结合的。 我们考虑使用 Serverless 技术方案是经过一些调研，结合我们自己的业务需求最终决定的，主要有以下几点： 我们服务的客户与场景流量潮汐现象很明显，Serverless 自动弹性伸缩能力可以为我们解决这个问题，比起普通服务器

前言 Knative Eventing 0.1.15 版本在5月27日已经发布，来看看它的变化。 注意 需要使用迁移工具把存储版本由v1alpha1 更新为 v1beta1，如果使用了Broker.Spec.ChannelTemplateSpec，需要在升级前先更新为兼容的配置。 功能 在Parallel、SequenceAPI增加Delivery字段，用于死信队列，重试等配置。 apiVersion: flows.knative.dev/v1beta1 kind: Sequence metadata: name: sequence-audit spec: channelTemplate: ... spec: delivery: backoffDelay: 3s backoffPolicy: exponential deadLetterSink: apiVersion: serving.knative.dev/v1beta1 kind: Service name: event-display-audit retry: 5 steps: ... 多租户Channel Broker现在是默认的Broker实现了。 现在不允许通过Spec.ChannelTemplate来创建Broker，需要改用Spec.Config来指定ConfigMap来创建。 更新sdk-go到v2.0.0

这几天在客户环境中搞Operatorhub的离线，因为已经安装了OpenShift 4.3的集群，所以目标是只将考核的Service Mesh和Serverless模块安装上去即刻，因为前期工作关系，我曾在离线的4.2环境安装过类似组件，所以稍作准备就出发了，但这几天遇到的问题和坑确实不少，4.3和4.2相比在离线方面有很大的改进，但又埋了另外一些坑，本文算是大致的一个记录。 另外感谢各位前辈及前浪的指引，让我在一片混乱中清晰了思路。 1.制作catalog的镜像 因为网络环境太慢，所以建议大家直接mirror到本地的仓库然后再进行 oc image mirror registry.redhat.io/openshift4/ose- operator -registry:v4. 3 registry.example.com/openshift4/ose- operator -registry 形成本地的catalog镜像 oc adm catalog build --appregistry-org redhat-operators -- from =registry.example.com/openshift4/ose- operator -registry:v4. 3 --to=registry.example.com/olm/redhat-operators:v1 -

本文整理自 ServerlessDay · China 大会 - 《从零到一，Serverless 平台在滴滴内部落地》分享，讲师滴滴弹性云平台负责人张健、滴滴资深前端开发工程师陈钦辉。滴滴 Serverless FT成员来自：滴滴基础平台部、车服技术部、金融事业部、普惠产品技术部。 为什么（前端）要推动建设 Serverless 更快地创建一个服务且免运维：大量的 Node.js 服务，创建服务，需要申请节点、申请机器，对接构建、部署、日志、监控，还要持续运维服。我们希望能更快创建一个服务并且免运维。 更灵活的隔离能力：前端 BFF 接口聚合、微前端等业务场景，需要创建大量的接口服务，快速创建服务的同时，还希望可以以不同粒度灵活进行接口间的隔离。 更低的成本：大量低峰期时间cpu/内存利用率很低，服务不再使用了，资源却仍然占用。 我们的方案 我们调研了业界的 Serverless 方案，最终决定了自己的方案： K8s + Knative + Istio 搭建应用级 Serverless。他的优势是： 社区相对繁荣，未来充满希望。 应用级 Serverless, 和传统通过 Docker 镜像开发，部署相近，现有服务迁移成本低。 应用级 Serverless, 通过 Serverless。 路由，可以灵活控制隔离的粒度。 通过 Serverless 升级研发模式 那有了

本文来自滴滴内部人士观点分享，不代表本机构观点。欢迎大家点评交流！ 本篇由来 如果你是一个程序员，你可能在最近这两年或多或少的听到过一堆莫名其妙的名词，例如CaaS、BaaS、FaaS等类似的以aaS结尾的as-a-service名词，同时也可能听到ServiceMesh、Serverless等名词，对于从事相关工作的同学可能知道每个名词都代表什么，但我相信肯定还是会有部分人听到之后是黑人问号脸，我们不具体介绍每个都是什么意思，因为这些概念也出现很早了已经，不明白的可以自行google，这里我们重点聊一下最近挺火的Serverless是个什么鬼，因为我发现我们在日常探讨过程中好像每个人对其理解不一样，也是在听完一次讨论之后有感而发，并不是在抱怨什么，只是想跟大家探讨一下到底什么是Serverless，在继续开展后续工作之前，我认为有必要再统一一下概念，不谈细节，也不扯什么性能，那都是可以优化的，不是不可逾越的障碍。 什么是Serverless 要说Serverless是什么，直译过来就是无服务器。根据 CNCF 的定义，Serverless 是指构建和运行不需要服务器管理的应用程序的概念。CloudFlare对其定义： Serverless computing is a method of providing backend services on an as-used basis

作者 | 元毅 阿里巴巴高级开发工程师 阿里巴巴云原生公众号后台回复 Knative ，免费下载《Knative 云原生应用开发指南》电子书！ 想必大家都比较了解 RocketMQ 消息服务，那么 RocketMQ 与 Serverless 结合会碰撞出怎样的火花呢？我们今天介绍一下如何基于 RocketMQ + Knative 驱动云原生 Serverless 应用 。本文主要从以下几个方面展开介绍： 云原生与 Serverless Knative 简介 RocketMQSource 餐饮配送场景示例 云原生 先看一下 CNCF 对云原生的定义： 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。 其实云原生旨在以标准化云服务的提供方式衔接云厂商和客户。这种方式对于客户而言降低了上云和跨云迁移的成本，让客户始终保有和云厂商议价的能力；对云厂商而言，因为客户跨云迁移的成本低，所以只要能提供性价比更高的云服务，就能很容易的聚集大量用户。 Serverless Serverless（无服务器架构）是指服务端逻辑由开发者实现