Serverless

原文:https://docs.gitlab.com/ee/user/project/clusters/serverless/

Serverless

在 GitLab 11.5 中引入.

警告: Serverless 目前处于alpha 状态 .

Overview

无服务器架构为运营商和开发人员提供了在不配置单个服务器的情况下编写高度可扩展的应用程序的能力.

GitLab 支持在 Kubernetes 环境和主要的云 FAAS 环境中部署无服务器应用程序的几种方法.

目前,我们支持:

  • Knative :在 GKE 和 EKS 上使用 Knative 和gitlabktl构建 Knative 应用程序.
  • AWS Lambda :通过无服务器框架和 GitLab CI / CD 创建无服务器应用程序.

Knative

使用Knative在 Kubernetes 上运行无服务器工作负载.

Knative 扩展了 Kubernetes 以提供一组中间件组件,这些组件对于构建现代的,以源为中心的,基于容器的应用程序很有用. Knative 通过其主要组件带来了一些明显的好处:

有关 Knative 的更多信息,请访问Knative docs 资源库 .

借助 GitLab Serverless,您可以部署功能即服务(FaaS)和无服务器应用程序.

Prerequisites

要在 GitLab 上运行 Knative,您需要:

  1. 现有的 GitLab 项目:您将需要一个 GitLab 项目来关联所有资源. 最简单的入门方法:
  2. Kubernetes 集群:部署 Knative 需要启用 RBAC 的 Kubernetes 集群. 最简单的入门方法是使用 GitLab 的GKE 集成添加集群. 建议的运行 Knative 的最低建议群集规格为 3 个节点,6 个 vCPU 和 22.50 GB 内存.
  3. GitLab 运行程序:运行 CI 作业需要运行程序,该作业会将无服务器的应用程序或功能部署到您的集群上. 您可以将 GitLab Runner 安装到现有的 Kubernetes 集群上. 有关更多信息,请参见安装应用程序 .
  4. 域名: Knative 将使用 Istio 提供自己的负载平衡器. 它将为 Knative 服务的所有应用程序提供一个外部 IP 地址或主机名. 系统将提示您输入一个通配符域,将在其中提供您的应用程序. 配置您的 DNS 服务器以使用该域的外部 IP 地址或主机名.
  5. .gitlab-ci.yml GitLab 使用Kaniko来构建应用程序. 我们还使用GitLab Knative 工具 CLI 来简化向 Knative 部署服务和功能.
  6. serverless.yml适用于功能 ):使用 lessserver 部署功能时, serverless.yml文件将包含存储库中托管的所有功能的信息以及所使用的运行时的引用.
  7. Dockerfile适用于应用程序 ):Knative 需要Dockerfile才能构建您的应用程序. 它应该包含在项目存储库的根目录中,并公开端口8080 . 如果您打算使用我们的运行时来构建无服务器功能,则不需要Dockerfile .
  8. Prometheus (可选):安装 Prometheus 可使您监视无服务器功能/应用程序的规模和流量. 有关更多信息,请参见安装应用程序 .
  9. 日志记录 (可选):配置日志记录可让您查看和搜索无服务器功能/应用程序的请求日志. 有关更多信息,请参见配置日志记录 .

Installing Knative via GitLab’s Kubernetes integration

注意:运行 Knative 的最小建议群集大小是 3 节点,6 vCPU 和 22.50 GB 内存. 必须启用 RBAC.

  1. Add a Kubernetes cluster.
  2. 选择” 应用程序”选项卡,然后向下滚动到” Knative 应用程序”部分. 输入要用于您的应用程序/功能的域(例如example.com ),然后单击Install .

    install-knative

  3. Knative 安装完成后,您可以等待 IP 地址或主机名显示在Knative Endpoint字段中,或手动检索 Istio Ingress 端点 .

    注意:在集群上运行kubectl命令需要首先设置对集群的访问. 对于在 GKE 上创建的集群,请参见GKE 集群访问 ,对于其他平台,请安装 kubectl .

  4. 入口现在在此地址可用,并将基于请求中的 DNS 名称将传入请求路由到适当的服务. 为此,应为所需的域名创建通配符 DNS 记录. 例如,如果您的 Knative 基础域是knative.info则需要创建一个 A 记录或 CNAME 记录,其域*.knative.info指向 Ingress 的 IP 地址或主机名.

    DNS entry

注意:可以在给定项目上部署功能无服务器应用程序 ,但不能两者都部署. 当前实现利用了的serverless.yml文件发信号 FAAS 项目.

Using an existing installation of Knative

Introduced in GitLab 12.0.

注意:添加现有的 Knative 安装时,GitLabless server 的”调用”监视功能将不起作用.

也可以将 GitLab Serverless 与已经安装 Knative 的现有 Kubernetes 集群一起使用.

您必须执行以下操作:

  1. 按照步骤添加现有的 Kubernetes 集群 .

  2. 确保 GitLab 可以管理 Knative:

    • 对于非 GitLab 托管群集,请确保提供的令牌的服务帐户可以管理serving.knative.dev API 组中的资源.
    • 对于 GitLab 托管群集,如果您在GitLab 12.1 或更高版本中添加了群集,则 GitLab 将已经具有所需的访问权限,您可以继续进行下一步.

      否则,您需要手动授权 GitLab 的服务帐户具有管理serving.knative.dev API 组中资源的能力. 由于每个 GitLab 服务帐户都具有edit集群角色,因此最简单的方法是通过将默认规则添加到默认edit集群角色的聚合 ClusterRole :首先,将以下 YAML 保存为knative-serving-only-role.yaml

      1. apiVersion : rbac.authorization.k8s.io/v1 kind : ClusterRole metadata : name : knative-serving-only-role labels : rbac.authorization.k8s.io/aggregate-to-edit : " true" rules : - apiGroups : - serving.knative.dev resources : - configurations - configurationgenerations - routes - revisions - revisionuids - autoscalers - services verbs : - get - list - create - update - delete - patch - watch

      然后运行以下命令:

      1. kubectl apply -f knative-serving-only-role.yaml

      如果您希望基于每个服务帐户授予权限,则可以使用特定于服务帐户和名称空间的RoleRoleBinding来执行此操作.

  3. 请按照以下步骤将功能无服务器应用程序部署到群集上.

Supported runtimes

GitLab 的无服务器功能可以使用以下命令运行:

如果所需的编程语言无法使用运行时,请考虑部署无服务器应用程序 .

GitLab-managed runtimes

当前,以下 GitLab 管理的运行时可用:

  • go (概念证明)
  • nodejs
  • ruby

如果未指定运行时,则必须提供一个Dockerfile来运行无服务器功能.

OpenFaaS runtimes

在 GitLab 12.5 中引入 .

OpenFaaS 经典运行时可与 GitLab 无服务器一起使用.

OpenFaas 运行时可用于以下语言:

  • C#
  • Go
  • NodeJS
  • PHP
  • Python
  • Ruby

使用以下模式指定运行时: openfaas/classic/<template_name> . 下面的示例示出了如何定义一个函数serverless.yml使用 OpenFaaS 运行时:

  1. hello:
  2. source: ./hello
  3. runtime: openfaas/classic/ruby
  4. description: "Ruby function using OpenFaaS classic runtime"

handler is not needed for OpenFaaS functions. The location of the handler is defined by the conventions of the runtime.

有关使用 OpenFaaS 运行时的函数示例,请参见ruby-openfaas-function项目.

Deploying functions

在 GitLab 11.6 中引入.

您可以在功能示例项目中找到并导入此文档中引用的所有文件.

请按照以下步骤将使用 Node.js 运行时的功能部署到您的 Knative 实例(如果您已克隆示例项目,则可以跳过以下步骤):

  1. 创建一个目录来容纳该函数. 在此示例中,我们将在项目的根目录创建一个名为echo的目录.

  2. 创建将包含功能代码的文件. 在此示例中,我们的文件名为echo.js ,位于echo目录中. 如果您的项目是:

  3. .gitlab-ci.yml :这定义了用于部署功能的管道. 它必须包含在存储库的根目录中:

    1. include:
    2. - template: Serverless.gitlab-ci.yml
    3. functions:build:
    4. extends: .serverless:build:functions
    5. environment: production
    6. functions:deploy:
    7. extends: .serverless:deploy:functions
    8. environment: production

    这个.gitlab-ci.yml创建的作业会调用一些预定义的命令来构建功能并将其部署到集群中.

    Serverless.gitlab-ci.yml is a template that allows customization. You can either import it with include parameter and use extends to customize your jobs, or you can inline the entire template by choosing it from 套用范本 dropdown when editing the .gitlab-ci.yml file through the user interface.

  4. serverless.yml :此文件包含您的功能的元数据,例如名称,运行时和环境.

    它必须包含在存储库的根目录中. 下面是一个示例echo函数,它显示了文件所需的结构.

    您可以在功能示例项目中找到该项目的相关文件.

    1. service: functions
    2. description: "GitLab Serverless functions using Knative"
    3. provider:
    4. name: triggermesh
    5. envs:
    6. FOO: value
    7. secrets:
    8. - my-secrets
    9. functions:
    10. echo-js:
    11. handler: echo-js
    12. source: ./echo-js
    13. runtime: gitlab/runtimes/nodejs
    14. description: "node.js runtime function"
    15. envs:
    16. MY_FUNCTION: echo-js
    17. secrets:
    18. - my-secrets

上面使用的字段的说明:

service

Parameter Description
service 服务该功能的 Knative 服务的名称.
description 在的简短描述service .

provider

Parameter Description
name 指示使用哪个提供程序来执行serverless.yml文件. 在这种情况下,使用 TriggerMesh 中间件.
envs 包括要在文件中所有函数的函数执行过程中传递的环境变量,其中FOO是变量名, BAR是变量内容. 您可以将其替换为自己的变量.
secrets 包含 Kubernetes 机密的内容作为环境变量,可访问该变量作为文件中所有函数的函数执行的一部分进行传递. 机密应采用 INI 格式.

functions

在上面的serverless.yml示例中,函数名称为echo ,随后的行包含函数属性.

Parameter Description
handler 函数的名称.
source 具有功能源的目录.
runtime (optional) 用于执行功能的运行时. 这可以是运行时别名(请参阅运行时别名 ),也可以是自定义运行时存储库的完整 URL. 当未指定运行Dockerfile ,我们假定Dockerfile存在于source指定的函数目录中.
description 功能的简短描述.
envs 仅为特定功能设置环境变量.
secrets 将 Kubernetes 机密的内容作为环境变量包含在内,这些变量只能作为特定函数的函数执行的一部分进行传递. 机密应采用 INI 格式.

Deployment

Runtime aliases

可选的runtime参数可以引用以下运行时别名之一(另请参阅受支持的运行时 ):

运行时别名 维护者
gitlab/runtimes/go GitLab
gitlab/runtimes/nodejs GitLab
gitlab/runtimes/ruby GitLab
openfaas/classic/csharp OpenFaaS
openfaas/classic/go OpenFaaS
openfaas/classic/node OpenFaaS
openfaas/classic/php7 OpenFaaS
openfaas/classic/python OpenFaaS
openfaas/classic/python3 OpenFaaS
openfaas/classic/ruby OpenFaaS

经过gitlab-ci.yml模板已添加和serverless.yml文件被创建,推动提交到您的项目将导致 CI 管道被执行,而部署的每个功能的 Knative 服务. 部署阶段完成后,该功能的其他详细信息将显示在” 操作”>”无服务器”下 .

serverless page

该页面包含可用于项目的所有功能,访问功能的描述以及(如果有)功能的运行时信息. 详细信息来自于项目的每个 Kubernetes 集群中的 Knative 安装. 单击每个功能以获得详细的规模和调用数据.

可以从集群上的 Knative 直接检索函数详细信息:

  1. kubectl -n "$KUBE_NAMESPACE" get services.serving.knative.dev

现在可以使用任何简单的POST调用从任何 HTTP 客户端触发示例函数:

  1. 使用 curl(将最后一行的 URL 替换为应用程序的 URL):

    1. curl \
    2. --header "Content-Type: application/json" \
    3. --request POST \
    4. --data '{"GitLab":"FaaS"}' \
    5. http://functions-echo.functions-1.functions.example.com/
  2. 使用基于 Web 的工具(例如 Postman 或 Restlet)

    function execution

Secrets

要从函数内部访问 Kubernetes 机密,应在无服务器部署的名称空间下创建该机密,并在上述serverless.yml文件中指定这些机密. 您可以通过多种方式创建机密. 以下各节显示了一些示例.

CLI example

  1. kubectl create secret generic my-secrets -n "$KUBE_NAMESPACE" --from-literal MY_SECRET=imverysecure

Part of deployment job

您可以扩展.gitlab-ci.yml以在部署期间使用安全存储在 GitLab 项目下的环境变量来创建秘密.

  1. deploy:function:
  2. stage: deploy
  3. environment: production
  4. extends: .serverless:deploy:functions
  5. before_script:
  6. - kubectl create secret generic my-secret
  7. --from-literal MY_SECRET="$GITLAB_SECRET_VARIABLE"
  8. --namespace "$KUBE_NAMESPACE"
  9. --dry-run -o yaml | kubectl apply -f -

Running functions locally

在本地运行功能是在开发过程中快速验证行为的好方法.

在本地运行功能需要:

  • 转到 1.12 或更高版本.
  • Docker Engine 已安装并正在运行.
  • 使用 Go 软件包管理器安装的gitlabktl

    1. GO111MODULE=on go get gitlab.com/gitlab-org/gitlabktl

要在本地运行功能:

  1. 导航到您的 GitLab 无服务器项目的根目录.
  2. 将功能构建到 Docker 映像中:

    1. gitlabktl serverless build
  3. 在 Docker 中运行您的函数:

    1. docker run -itp 8080:8080 <your_function_name>
  4. 调用您的功能:

    1. curl http://localhost:8080

Deploying Serverless applications

在 GitLab 11.5 中引入.

无服务器应用程序是无服务器功能的替代方法 . 它们在现有运行时不能满足应用程序需求的情况下很有用,例如以一种没有可用运行时的语言编写的应用程序. 请注意,尽管无服务器应用程序应该是无状态的!

注意:您可以参考并导入示例Knative Ruby 应用程序以开始使用.

将以下.gitlab-ci.yml添加到存储库的根目录中(如果您先前已经克隆了上述示例Knative Ruby App,则可以跳过此步骤):

  1. include:
  2. - template: Serverless.gitlab-ci.yml
  3. build:
  4. extends: .serverless:build:image
  5. deploy:
  6. extends: .serverless:deploy:image

Serverless.gitlab-ci.yml是允许自定义的模板. 您可以使用include参数导入它,并使用extends来自定义作业,或者可以通过在通过用户界面编辑.gitlab-ci.yml文件时从Apply a template下拉列表中选择它来内联整个模板.

部署无服务器应用程序时,不需要serverless.yml文件.

Deploy the application with Knative

一切就绪后,下次运行 CI 管道时,将部署 Knative 应用程序. 导航到CI / CD>管道 ,然后单击最新的管道.

Function details

转到操作>无服务器页面以查看功能的最终 URL.

function_details

Invocation metrics

On the same page as above, click on one of the function rows to bring up the function details page.

function_details

容器数将为您提供在给定集群上运行无服务器功能实例的容器数.

为了显示 Knative 函数调用, 必须安装 Prometheus .

一旦安装了 Prometheus,可能会出现一条消息,指示度量标准数据正在加载或当前不可用. 它会在首次访问该页面时显示,但应在几秒钟后消失. 如果该消息没有消失,则可能是 GitLab 无法连接到集群上运行的 Prometheus 实例.

Configuring logging

在 GitLab 12.5 中引入 .

Prerequisites

  • 由 GitLab 管理的集群.
  • kubectl已安装并正在运行.

在集群上运行kubectl命令需要首先设置对集群的访问权限. 对于在以下位置创建的集群:

Enable request log template

运行以下命令以启用请求日志:

  1. kubectl edit cm -n knative-serving config-observability

logging.request-log-templatedata._example字段复制到层次结构中上一层的数据字段.

Enable request logs

运行以下命令以将 Elasticsearch,Kibana 和 Filebeat 安装到kube-logging命名空间中,并配置所有节点以使用 Filebeat 转发日志:

  1. kubectl apply -f https://gitlab.com/gitlab-org/serverless/configurations/knative/raw/v0.7.0/kube-logging-filebeat.yaml
  2. kubectl label nodes --all beta.kubernetes.io/filebeat-ready="true"

Viewing request logs

要查看请求日志:

  1. Run kubectl proxy.
  2. 导航到Kibana UI .

Or:

  1. 打开Kibana UI .
  2. 单击” 发现” ,然后从左侧的下拉列表中选择filebeat-* .
  3. 在搜索框中输入kubernetes.container.name:"queue-proxy" AND message:/httpRequest/ .

Enabling TLS for Knative services

默认情况下,将通过http提供 GitLab 无服务器部署. 为了通过https提供服务,您必须手动获取并安装 TLS 证书.

完成此操作的最简单方法是使用Certbot 手动获取 Let’s Encrypt 证书 . Certbot 是一个免费的开源软件工具,可用于在手动管理的网站上自动使用 Let’s Encrypt 证书来启用 HTTPS.

注意:以下说明与在安装了 Python 3 且不能在其他操作系统或其他版本的 Python 上运行的 Linux 服务器上安装和运行 Certbot 有关.

  1. 通过运行certbot-auto wrapper 脚本安装 Certbot. 在服务器的命令行上,运行以下命令:

    1. wget https://dl.eff.org/certbot-auto
    2. sudo mv certbot-auto /usr/local/bin/certbot-auto
    3. sudo chown root /usr/local/bin/certbot-auto
    4. sudo chmod 0755 /usr/local/bin/certbot-auto
    5. /usr/local/bin/certbot-auto --help

    要检查certbot-auto脚本的完整性,请运行:

    1. wget -N https://dl.eff.org/certbot-auto.asc
    2. gpg2 --keyserver ipv4.pool.sks-keyservers.net --recv-key A2CFB51FA275A7286234E7B24D17C995CD9775F2
    3. gpg2 --trusted-key 4D17C995CD9775F2 --verify certbot-auto.asc /usr/local/bin/certbot-auto

    The output of the last command should look something like:

    1. gpg: Signature made Mon 10 Jun 2019 06:24:40 PM EDT
    2. gpg: using RSA key A2CFB51FA275A7286234E7B24D17C995CD9775F2
    3. gpg: key 4D17C995CD9775F2 marked as ultimately trusted
    4. gpg: checking the trustdb
    5. gpg: marginals needed: 3 completes needed: 1 trust model: pgp
    6. gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
    7. gpg: next trustdb check due at 2027-11-22
    8. gpg: Good signature from "Let's Encrypt Client Team <letsencrypt-client@eff.org>" [ultimate]
  2. 运行以下命令以使用 Certbot 在授权过程中使用 DNS 质询来请求证书:

    1. /usr/local/bin/certbot-auto certonly --manual --preferred-challenges dns -d '*.<namespace>.example.com'

    其中<namespace>是 GitLab 为您的无服务器项目创建的名称空间(由<project_name>-<project_id>-<environment> ),而example.com是用于项目的域. 如果不确定项目的名称空间是什么,请导航至项目的” 操作”>”无服务器”页面,然后检查为功能/应用程序提供的端点.

    function_endpoint

    在上图中,项目的名称空间为node-function-11909507 ,域为knative.info ,因此证书申请行如下所示:

    1. ./certbot-auto certonly --manual --preferred-challenges dns -d '*.node-function-11909507.knative.info'

    Certbot 工具将引导您完成通过在这些域中创建 TXT 记录来验证您拥有的每个域的步骤. 此过程完成后,输出应如下所示:

    1. IMPORTANT NOTES:
    2. - Congratulations! Your certificate and chain have been saved at:
    3. /etc/letsencrypt/live/namespace.example.com/fullchain.pem
    4. Your key file has been saved at:
    5. /etc/letsencrypt/live/namespace.example/privkey.pem
    6. Your cert will expire on 2019-09-19\. To obtain a new or tweaked
    7. version of this certificate in the future, simply run certbot-auto
    8. again. To non-interactively renew *all* of your certificates, run
    9. "certbot-auto renew"
    10. -----BEGIN PRIVATE KEY-----
    11. - Your account credentials have been saved in your Certbot
    12. configuration directory at /etc/letsencrypt. You should make a
    13. secure backup of this folder now. This configuration directory will
    14. also contain certificates and private keys obtained by Certbot so
    15. making regular backups of this folder is ideal.
  3. 创建证书和私钥文件. 使用 Certbot 返回的文件的内容,我们将创建两个文件以创建 Kubernetes 机密:

    运行以下命令以查看fullchain.pem的内容:

    1. sudo cat /etc/letsencrypt/live/node-function-11909507.knative.info/fullchain.pem

    输出应如下所示:

    1. -----BEGIN CERTIFICATE-----
    2. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    3. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    4. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    5. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    6. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    7. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    8. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    9. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    10. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    11. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    12. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    13. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    14. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    15. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    16. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    17. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    18. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    19. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    20. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    21. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    22. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    23. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    24. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    25. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    26. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    27. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    28. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    29. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    30. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    31. 04f294d1eaca42b8692017b4ag==
    32. -----END CERTIFICATE-----
    33. -----BEGIN CERTIFICATE-----
    34. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    35. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    36. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    37. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    38. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    39. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    40. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    41. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    42. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    43. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    44. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    45. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    46. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    47. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    48. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    49. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    50. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    51. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    52. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    53. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    54. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    55. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    56. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    57. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    58. K2fcb195768c39e9a94cec2c2e30Qg==
    59. -----END CERTIFICATE-----

    创建一个名称为cert.pem的文件,其中包含整个输出的内容.

    创建cert.pem ,运行以下命令以查看privkey.pem的内容:

    1. sudo cat /etc/letsencrypt/live/namespace.example/privkey.pem

    输出应如下所示:

    1. -----BEGIN PRIVATE KEY-----
    2. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    3. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    4. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    5. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    6. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    7. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    8. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    9. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    10. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    11. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    12. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    13. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    14. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    15. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    16. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    17. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    18. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    19. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    20. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    21. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    22. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    23. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    24. 2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    25. 04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
    26. -----BEGIN CERTIFICATE-----
    27. fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
    28. 4f294d1eaca42b8692017b4262==
    29. -----END PRIVATE KEY-----

    使用整个输出的内容创建一个名称为cert.pk的新文件.

  4. 创建一个 Kubernetes 机密以保存您的 TLS 证书cert.pem和私钥cert.pk

    注意:在集群上运行kubectl命令需要首先设置对集群的访问. 对于在 GKE 上创建的集群,请参阅GKE 集群访问 . 对于其他平台, 请安装kubectl .

    1. kubectl create --namespace istio-system secret tls istio-ingressgateway-certs \
    2. --key cert.pk \
    3. --cert cert.pem

    其中cert.pemcert.pk是您的证书和私钥文件. 请注意, istio-ingressgateway-certs秘密名称是必需的.

  5. 配置 Knative 以使用为 HTTPS 连接创建的新密码. 运行以下命令以编辑方式打开 Knative 共享gateway

    1. kubectl edit gateway knative-ingress-gateway --namespace knative-serving

    更新网关以包括以下 tls:部分和配置:

    1. tls:
    2. mode: SIMPLE
    3. privateKey: /etc/istio/ingressgateway-certs/tls.key
    4. serverCertificate: /etc/istio/ingressgateway-certs/tls.crt

    Example:

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: Gateway
    3. metadata:
    4. # ... skipped ...
    5. spec:
    6. selector:
    7. istio: ingressgateway
    8. servers:
    9. - hosts:
    10. - "*"
    11. port:
    12. name: http
    13. number: 80
    14. protocol: HTTP
    15. - hosts:
    16. - "*"
    17. port:
    18. name: https
    19. number: 443
    20. protocol: HTTPS
    21. tls:
    22. mode: SIMPLE
    23. privateKey: /etc/istio/ingressgateway-certs/tls.key
    24. serverCertificate: /etc/istio/ingressgateway-certs/tls.crt

    After your changes are running on your Knative cluster, you can begin using the HTTPS protocol for secure access your deployed Knative services. In the event a mistake is made during this process and you need to update the cert, you will need to edit the gateway knative-ingress-gateway to switch back to PASSTHROUGH mode. Once corrections are made, edit the file again so the gateway will use the new certificates.

Using an older version of gitlabktl

在某些情况下,您想运行旧版本的gitlabktl . 这需要在.gitlab-ci.yml文件中设置较旧版本的gitlabktl映像.

要设置较旧的版本,请将image:添加到functions:deploy块中. 例如:

  1. functions:deploy:
  2. extends: .serverless:deploy:functions
  3. environment: production
  4. image: registry.gitlab.com/gitlab-org/gitlabktl:0.5.0

通过更改注册表 URL 末尾的版本标签(格式为registry.gitlab.com/gitlab-org/gitlabktl:<version>可以使用不同的版本.

有关可用gitlabktl版本的完整清单,请参见gitlabktl项目的容器注册表 .