导读
红帽正式敲响了下一阶段混合云布局，将借助Knative无伺服器与Istio微服务开源新技术，来扩大混合云战场，抢进边缘运算
在今年红帽高峰会上，红帽开始加强对于两大新兴开源技术Knative与Istio的支援，让Kubernetes也可以在OpenShift平台上调度和管理无伺服器（Serverless）与微服务（Microservices）应用，但红帽没说的是，藏在Kubernetes背后的更大企图，直到活动第二天的一场亚太媒体记者会上，红帽产品与技术总裁Paul Cormier才亲口告诉iThome记者：「不只是抢攻混合云，OpenShift还要落地成为一个边缘运算平台。」而Knative与Istio正是用来加速Kubernetes落地边缘的两大关键开源技术。
红帽扩大混合云战地，要靠Kubernetes通吃云端与边缘
早在今年2月，红帽技术长Chris Wright在自家官网发布的一篇文章就可看出端倪，他在这篇文章中，不只提出未来两年新兴开源技术的最新观察，甚至也揭露该公司将大力推动发展两大新兴开源技术专案，正是Knative与Istio，并将这两者视为是Kubernetes容器平台推动的下一个技术发展方向。
虽然与AWS、Azure、Google同样是从云端切进边缘运算，但不同的地方是，红帽是专攻Kubernetes层管理需求，要把混合云上容器管理与调度能力，更进一步延伸到边缘端，要让Kubernetes也开始具备有边缘运算装置应用的管理能力，不只管云端，也能向下更扩大延伸至边缘端，未来除了可提供各种Serverless边缘应用管理，也能将大量微服务纳管，甚至是管更复杂AI或ML推论模型等。
Knative是由Google去年7月开源释出的一项无伺服器管理专案，该专案目的，是要方便开发者在Kubernetes上建立、部署和管理Serverless函数应用程式。不只Google、GitLab先后采用，甚至连红帽、SAP 、Pivotal以及IBM都力拱，要将它打造新一代开源无伺服器应用框架，未来更有机会成为业界采用的开源Serverless商用标准。不只有科技厂商先后投入，Knative也与开源FaaS框架社群合作，如OpenWhisk、riff和Kyma等，来加快Knative的发展步伐，推出至今，不到半年，Knative已经发行4个版本，持续提高对Serverless技术支援与增加丛集扩充力。
Knative包含3个部分，建立（Build）、事件（Eventing），以及服务（Serving）。Build 主要提供事件来源到容器建立的整体资源调度；Eventing 则是提供Serverless管理与事件交付，最后的Serving，则是依据事件请求提供可立即扩充的运算力，并在事件结束后，迅速自动移除，如此一来，便能更快速地在Kubernetes上开发出基于容器的Serverless功能或应用。
OpenShift新版现在可以调度和管理Azure无伺服器应用了
红帽去年就开始布局Serverless，但是直到今年的红帽用户大会上，正式支援Knative后，对于Serverless布局才开始有了更具体的战略，就是抢攻边缘运算，而用来切进边缘运算的关键利器，就是当家主力混合云平台OpenShift 。
尽管Knative仍在发展初期，但红帽相当看好Knative未来应用发展的潜力，因此，该公司在推出新版OpenShift 4时，也开始支援了Knative，虽然仅是开发者预览，但OpenShift结合Serverless后，现在已能透过Knative将Serverless以容器打包后，并在Kubernetes平台上，部署和管理Serverless应用程式，或是FaaS应用服务功能，Knative不只支援公有云，也能用于多云、混合云环境上，再利用Kubernetes来提供Serverless丛集的管理。
借助Knative，红帽表示，使用者能在OpenShift 4上，以随需扩充的方式，动态建立Serverless丛集，并在Kubernetes环境执行这些无伺服器应用，而透过Knative上的事件框架，可以轻易在Kubernetes上开发以Serverless事件触发为主的原生容器应用。
Knative还整合了服务网格技术的Istio和Kiali，来帮助管理容器化的Serverless丛集架构，另外还加入Strimzi，可以更容易地在OpenShift或Kubernetes上使用开源分散式串流分析工具Apache Kafka，还可通过Red Hat AMQ Streams来提供更可靠的事件处理机制。新增的Apache Camel轻量级框架Camel-K，也能让开发者以编写Serverless函数的方式，自行定义事件触发条件，此后程式便会在条件满足时自动执行无伺服器应用程式，并且自动水平扩展。
Paul Cormier解释，OpenShift开始支援Serverless有两个主因，一来这是开发者最想用来开发原生容器应用的一大功能；二来，则是要解决Serverless技术容易被特定厂商所绑定的棘手难题。他进一步说明，虽然现在许多云端厂商，都有提供无伺服器运算服务，如AWS Lambda或微软Azure Functions等，「但是，这些无伺服器运算平台，彼此并不相通，因此，只能在单一云端厂商所提供的云端环境来执行Serverless应用程式，在其他家就会没办法用，因为彼此无法相容，得先重新编写成符合其他云端环境能够运作的Serverless执行程式，才能拿来用，也增加了开发人员应用开发的一大负担。
因为Knative本身具备相容多异质云端平台的特性，所以，红帽的第一步，就是开始支援Knative，一方面，可以减少企业用户被特定厂商绑定的情况，让Serverless应用可以在不同云端环境中执行相关运算与事件触发任务；另一方面，也简化Serverless开发与部署，开发者现在只须编写一次程式，就能搬上不同云端平台上，不需要每换一朵云，就要对Serverless丛集重新编写，才能加以执行，也因此，大大加快Serverless应用程式的开发、部署的工作。
红帽这次还与微软联手推出Azure Functions in OpenShift服务，通过两家合推的KEDA无伺服器应用专案，让Azure Functions无伺服器服务也能在红帽OpenShift容器平台上执行，可以做为Azure 、混合云、本地端管理，或是可用来实现云端FaaS服务。不过目前仍是开发者预览版。
透过支援Istio服务网格技术，让K8s也可管大量容器化的微服务
除了Knative以外，另一个同样值得关注的技术则是更早一年，由Google、IBM及Lyft主推的微服务平台Istio，在新版OpenShift 4推出时，已经可以透过Istio服务网格技术，在Kubernetes上来管理微服务丛集，用以解决大量容器化应用网路沟通问题。
而且不只公有云或混合云能用，Istio同样适用于边缘运算的应用情境，让应用程式可以小规模方式，部署在运算能力普通的硬体装置上执行，以微服务化架构建立边缘运算丛集。红帽不只在OpenShift开始支援Istio，还整合开源分散式追踪工具Jaeger与红帽自行开发的服务网格管理工具Kial，可以透过服务网格的架构，来管理庞大的微服务群，让开发团队可以专注在开发执行商业逻辑的应用程式。
红帽今年在进行混合云技术展示时，也首次示范以OpenShift平台、OpenStack技术，以及RHEL OS自行打造一个边缘运算平台，就近在裸机上执行环境监测与状态更新回报等功能。
