主持人 > 博客 > 管理 > Knative - 基于 k8s 的平台即服务，具有无服务器支持

Knative - 基于 k8s 的平台即服务，具有无服务器支持

Knative - 基于 k8s 的平台即服务，具有无服务器支持

Kubernetes 无疑已成为容器部署的主导平台。 它提供了使用其 API 和自定义控制器控制几乎所有事物的能力，这些控制器通过自定义资源扩展其 API。

然而，用户仍然必须就如何部署、配置、管理和扩展应用程序做出详细的决定。 应用程序扩展、保护和流量问题仍由用户自行决定。 这使得 Kubernetes 有别于传统的平台即服务 (PaaS)，例如 Cloud Foundry 和 Heroku。

这些平台具有简化的用户界面，面向最常参与设置个人应用程序的应用程序开发人员。 路由、部署和指标由底层 PaaS 系统对用户透明地进行管理。

从源到发货的工作流程由 PaaS 处理，方法是创建自定义容器映像、部署它、为传入流量设置新的路由和 DNS 子域。 所有这一切都是根据命令启动的 git push.

Kubernetes（有意）只为此类平台提供核心构建块，让社区可以自由地自行完成工作。 如何 凯尔西·海塔尔说:

Kubernetes 是一个构建平台的平台。 这是开始的最佳位置，但不是结束的位置。

因此，我们看到了许多 Kubernetes 构建，以及尝试为 Kubernetes 创建 PaaS 的托管公司，例如 OpenShift 和 Rancher。 在不断增长的 Kube-PaaS 市场中，由 Google 和 Pivotal 于 2018 年 XNUMX 月创立的 Knative 正在进入这一领域。

Knative 是 Google 和 Pivotal 之间的合作成果，并得到了 IBM、RedHat 和 Solo.im 等其他公司的帮助。 它提供与 Kubernetes 类似的 PaaS 功能，并对基于无服务器计算的应用程序提供一流的支持。 与 Kubernetes 构建不同，Knative 作为附加组件安装在任何兼容的 Kubernetes 集群上，并通过用户资源进行配置。

什么是 Knative？

Knative 被描述为“一个基于 Kubernetes 的平台，用于使用现代无服务器计算交付和管理工作负载。” Knative 在标榜自己是这样一个平台的同时，还根据并发 HTTP 请求的比例主动自动缩放容器。 未使用的服务最终会缩减到零，从而提供无服务器式的按需扩展。

Knative 由一组安装在任何 Kubernetes 集群中的控制器组成，并提供以下功能：

  • 从源代码构建容器化应用程序（由组件提供） 建立),
  • 提供对应用程序传入流量的访问（由组件提供） 服务),
  • 按需交付和自动扩展应用程序（也由组件提供） 服务),
  • 识别导致应用程序启动的事件源（由组件提供） 三项赛).

一个关键组件是服务，它为托管应用程序提供配置、自动扩展和流量管理。 安装 Knative 后，您仍然拥有对 Kubernetes API 的完全访问权限，允许用户管理应用程序 通常的 方式，还用于调试 Knative 服务，使用这些服务使用的相同 API 原语（模块、服务等）。

在Serving的帮助下，蓝绿流量路由也实现了自动化，确保当用户交付更新版本的应用程序时，新旧版本应用程序之间的流量分离。

Knative 本身依赖于安装兼容的入口控制器。 在撰写本文时，支持 Gloo API 网关 и Istio 服务网格。 它将配置可用的入口以将流量路由到 Knative 管理的应用程序。

对于想要在不安装 Istio 控制面板的情况下尝试的 Knative 用户来说，Istio Service Mesh 可能是一个很大的依赖项，因为 Knative 仅依赖于网关。

因此，大多数用户更喜欢将 Gloo 作为 Knative 的网关，提供与 Istio 类似的功能集（为了仅使用 Knative），同时使用的资源也少得多，运营成本也更低。

让我们在展台上实际测试 Knative。 我将使用在 GKE 中运行的新安装的集群：

kubectl get namespace
NAME          STATUS   AGE
default       Active   21h
kube-public   Active   21h
kube-system   Active   21h

让我们开始安装 Knative 和 Gloo。 这可以按任何顺序完成：

# ставим Knative-Serving
kubectl apply -f 
 https://github.com/knative/serving/releases/download/v0.8.0/serving-core.yaml
namespace/knative-serving created
# ...
# ставим Gloo
kubectl apply -f 
  https://github.com/solo-io/gloo/releases/download/v0.18.22/gloo-knative.yaml
namespace/gloo-system created
# ...

我们检查所有 Pod 是否都处于“Running”状态：

kubectl get pod -n knative-serving
NAME                              READY   STATUS    RESTARTS   AGE
activator-5dd55958cc-fkp7r        1/1     Running   0          7m32s
autoscaler-fd66459b7-7d5s2        1/1     Running   0          7m31s
autoscaler-hpa-85b5667df4-mdjch   1/1     Running   0          7m32s
controller-85c8bb7ffd-nj9cs       1/1     Running   0          7m29s
webhook-5bd79b5c8b-7czrm          1/1     Running   0          7m29s
kubectl get pod -n gloo-system
NAME                                      READY   STATUS    RESTARTS   AGE
discovery-69548c8475-fvh7q                1/1     Running   0          44s
gloo-5b6954d7c7-7rfk9                     1/1     Running   0          45s
ingress-6c46cdf6f6-jwj7m                  1/1     Running   0          44s
knative-external-proxy-7dd7665869-x9xkg   1/1     Running   0          44s
knative-internal-proxy-7775476875-9xvdg   1/1     Running   0          44s

Gloo 已准备好进行路由，让我们创建一个自动扩展的 Knative 服务（我们称之为 kservice）并将流量路由到它。

与传统的 Deployment+Service+Ingress 模型相比，Knative 服务提供了一种更简单的方式将应用程序交付到 Kubernetes。 我们将使用这个例子：

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
 name: helloworld-go
 namespace: default
spec:
 template:
   spec:
     containers:
       - image: gcr.io/knative-samples/helloworld-go
         env:
           - name: TARGET
             Value: Knative user

我将其复制到一个文件中，然后通过以下方式将其应用到我的 Kubernetes 集群：

kubectl apply -f ksvc.yaml -n default

交付“helloworld-go”后，我们可以在集群中查看 Knative 创建的资源 服务:

kubectl get pod -n default
NAME                                              READY   STATUS    RESTARTS   AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8   2/2     Running   0          68s

部署 kservice 时，会启动带有“helloworld-go”映像的 pod。 如果没有流量，Pod 数量将减少到零。 反之亦然，如果同时请求的数量超过某个可配置的阈值，Pod 的数量就会增加。

kubectl get ingresses.networking.internal.knative.dev -n default
NAME            READY   REASON
helloworld-go   True

Knative 使用内部 Knative API 中的特殊“入口”资源来配置其入口。 Gloo 使用此 API 作为其配置来提供类似 PaaS 的功能，包括蓝绿部署模型、自动 TLS 实施、超时和其他高级路由功能。

一段时间后，我们看到我们的 Pod 消失了（因为没有传入流量）：

kubectl get pod -n default

No resources found.
kubectl get deployment -n default
NAME                             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

最后我们将尝试联系他们。 您可以使用以下方式轻松轻松地获取 Knative Proxy 的 URL glooctl:

glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80

未安装 glooctl 在kube服务中可以看到地址和端口：

kubectl get svc -n gloo-system knative-external-proxy
NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      AGE
knative-external-proxy   LoadBalancer   10.16.11.157   35.190.151.188   80:32168/TCP,443:30729/TCP   77m

让我们使用 cURL 运行一些数据：

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!

Knative 使用 Gloo 的高性能、全栈 API 网关，在开箱即用的 Kubernetes 之上为开发人员提供了一个近乎 PaaS 的平台。 这篇文章仅触及 Knative 广泛的自定义选项和附加功能的表面。 格鲁也一样！

尽管 Knative 仍然是一个年轻的项目，但其团队每六周就会发布新版本，并且高级功能的实现已经开始，例如自动 TLS 部署、控制面板自动缩放等。 作为多个云公司之间合作的结果，并且作为 Google 新 Cloud Run 产品的基础，Knative 很有可能成为 Kubernetes 上无服务器计算和 PaaS 的主要选择。 关注新闻！

来自南桥编辑
读者的意见对我们很重要，因此我们邀请您参与一项与未来有关 Knative、Kubernetes、无服务器计算的文章相关的简短调查：

只有注册用户才能参与调查。 登录拜托

我应该继续撰写有关 Knative 和无服务器计算的文章和指南吗？

  • 是的，请。

  • 谢谢，不要。

28 位用户投票。 4 名用户弃权。

来源： habr.com

添加评论