这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

安装到 Kubernetes

在 Kubernetes 集群上部署 Drycc。

1 - 要求

要在 Kubernetes 集群上运行 Drycc Workflow,需要记住一些要求。

Kubernetes 版本

Drycc Workflow 需要 Kubernetes v1.16.15 或更高版本。

组件要求

Drycc 使用网关作为路由实现,因此您必须选择一个网关。我们推荐使用 istiokong

Workflow 支持使用 ACME 来管理自动证书,cert-manager 也是必要组件之一,如果您使用 cert-manager EAB,您需要将 clusterResourceNamespace 设置为 drycc 的命名空间。

Workflow 支持有状态应用。您可以通过 ‘drycc volumes’ 命令创建和使用它们。如果您想使用此功能,您必须有一个支持 ReadWriteManyStorageClass

Workflow 还通过 ‘drycc resources’ 命令支持 OSB API。如果您想使用此功能,需要安装 service-catalog

存储要求

各种 Drycc Workflow 组件依赖对象存储系统来完成工作,包括存储应用程序 slugs、容器镜像和数据库日志。

Drycc Workflow 默认附带 drycc 存储,它提供集群内存储。

Workflow 支持 Amazon Simple Storage Service (S3)、Google Cloud Storage (GCS)、OpenShift Swift 和 Azure Blob Storage。请参阅配置对象存储以获取设置说明。

资源要求

部署 Drycc Workflow 时,为机器提供充足资源很重要。Drycc 是一个高可用分布式系统,这意味着 Drycc 组件和您部署的应用程序会随着主机因各种原因(故障、重启、自动缩放器等)离开集群而移动到集群中的健康主机上。因此,您应该在集群中的任何机器上都有充足的备用资源,以承受运行失败机器服务的额外负载。

Drycc Workflow 组件在集群中使用大约 2.5GB 内存,并需要大约 30GB 硬盘空间。因为如果另一个失败,它可能需要处理额外负载,所以每台机器的最低要求是:

  • 至少 4GB RAM(越多越好)
  • 至少 40GB 硬盘空间

请注意,这些估计仅适用于 Drycc Workflow 和 Kubernetes。确保为您的应用程序占用空间留出足够的备用容量。

运行较小的机器可能会导致系统负载增加,并已知会导致组件故障和不稳定。

2 - 安装 Drycc Workflow

本文档面向那些已经配置了 Kubernetes 集群并想要安装 Drycc Workflow 的人。

如果需要有关 Kubernetes 和 Drycc Workflow 入门的帮助,请遵循快速入门指南以获取帮助。

先决条件

  1. 验证 Kubernetes 系统要求
  2. 安装 Helm 和 Drycc Workflow CLI 工具

检查您的设置

检查 helm 命令是否可用且版本为 v2.5.0 或更新版本。

$ helm version
Client: &version.Version{SemVer:"v2.5.0", GitCommit:"012cb0ac1a1b2f888144ef5a67b8dab6c2d45be6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.5.0", GitCommit:"012cb0ac1a1b2f888144ef5a67b8dab6c2d45be6", GitTreeState:"clean"}

选择您的部署策略

Drycc Workflow 包含运行所需的一切。然而,这些默认设置旨在简单而不是生产就绪。Workflow 的生产和暂存部署至少应该使用集群外存储,Workflow 组件使用它来存储和备份关键数据。如果操作员需要完全重新安装 Workflow,所需组件可以从集群外存储恢复。有关更多详细信息,请参阅配置对象存储的文档。

更严格的安装将受益于对以下内容使用外部来源:

网关

现在,workflow 要求必须安装网关和 cert-manager。可以使用任何兼容的 Kubernetes 入口控制器。

安装 Drycc Workflow

如果 helm 版本为 3.0+;您需要提前创建命名空间:

kubectl create ns drycc

如果您想更改它,请在使用 helm 时设置变量。

$ helm install drycc oci://registry.drycc.cc/charts/workflow \
    --namespace drycc \
    --set builder.imageRegistry=quay.io \
    --set imagebuilder.imageRegistry=quay.io \
    --set controller.imageRegistry=quay.io \
    --set database.imageRegistry=quay.io \
    --set fluentbit.imageRegistry=quay.io \
    --set valkey.imageRegistry=quay.io \
    --set storage.imageRegistry=quay.io \
    --set grafana.imageRegistry=quay.io \
    --set registry.imageRegistry=quay.io \
    --set global.platformDomain=drycc.cc

Helm 将在 drycc 命名空间中安装各种 Kubernetes 资源。 等待 Helm 启动的 pod 准备就绪。通过运行以下命令监控其状态:

$ kubectl --namespace=drycc get pods

如果希望 kubectl 在 pod 状态更改时自动更新,请运行(键入 Ctrl-C 停止监视):

$ kubectl --namespace=drycc get pods -w

根据 Workflow 组件初始化的顺序,一些 pod 可能会重新启动。这在安装期间很常见:如果组件的依赖项尚不可用,该组件将退出,Kubernetes 将自动重新启动它。

在这里,可以看到控制器、构建器和注册表都花了几次循环才能启动:

$ kubectl --namespace=drycc get pods
NAME                                     READY     STATUS    RESTARTS   AGE
drycc-builder-574483744-l15zj             1/1       Running   0          4m
drycc-controller-3953262871-pncgq         1/1       Running   2          4m
drycc-controller-celery-cmxxn             3/3       Running   0          4m
drycc-database-83844344-47ld6             1/1       Running   0          4m
drycc-fluentbit-zxnqb                     1/1       Running   0          4m
drycc-valkey-304849759-1f35p              1/1       Running   0          4m
drycc-storage-676004970-nxqgt             1/1       Running   0          4m
drycc-monitor-grafana-432627134-lnl2h     1/1       Running   0          4m
drycc-monitor-telegraf-wmcmn              1/1       Running   1          4m
drycc-registry-756475849-lwc6b            1/1       Running   1          4m
drycc-registry-proxy-96c4p                1/1       Running   0          4m

一旦所有 pod 都处于 READY 状态,Drycc Workflow 就启动并运行了!

有关更多安装参数,请检查 workflow 的 values.yaml 文件。

安装 Workflow 后,注册用户并部署应用程序

配置 DNS

用户必须设置主机名,并采用 drycc-builder.$host 约定。

我们需要将 drycc-builder.$host 记录指向您的构建器的公共 IP 地址。您可以使用以下命令获取公共 IP。这里需要通配符条目,因为应用程序在部署后将使用相同的规则。

$ kubectl get svc drycc-builder --namespace drycc
NAME              CLUSTER-IP   EXTERNAL-IP      PORT(S)                      AGE
drycc-builder     10.0.25.3    138.91.243.152   2222:31625/TCP               33m

如果我们使用 drycc.cc 作为主机名,我们需要创建以下 A DNS 记录。

名称 类型
drycc-builder.drycc.cc A 138.91.243.152

一旦所有 pod 都处于 READY 状态,并且 drycc-builder.$host 解析为上面找到的外部 IP,Workflow 就启动并运行了!

安装 Workflow 后,注册用户并部署应用程序

如果您的 k8s 不提供公共网络负载均衡器,您需要在可以访问内部和外部网络的机器上安装 haproxy 等 TCP 代理服务,然后公开 80443

3 - 指定网关

选择最适合您需求和平台的网关提供商。

安装 Drycc Workflow(指定网关)

现在 Helm 已安装并添加了仓库,通过运行以下命令使用原生网关安装 Workflow:

$ helm install drycc oci://registry.drycc.cc/charts/workflow \
    --namespace drycc \
    --set gateway.gatewayClass=istio \
    --set controller.appGatewayClass=istio \
    --set global.platformDomain=drycc.cc \
    --set builder.service.type=LoadBalancer

当然,如果您在裸机上部署,您可能没有负载均衡器。您需要使用 NodePort:

$ helm install drycc oci://registry.drycc.cc/charts/workflow \
    --namespace drycc \
    --set gateway.gatewayClass=istio \
    --set controller.appGatewayClass=istio \
    --set global.platformDomain=drycc.cc \
    --set builder.service.type=NodePort \
    --set builder.service.nodePort=32222

如果您想在裸机上使用负载均衡器,您可以查看 metallb

其中 global.platformDomain 是一个必需参数,对于 Workflow 传统上不是必需的,这在下一节中解释。在此示例中,我们使用 drycc.cc 作为 $hostname

Helm 将在 drycc 命名空间中安装各种 Kubernetes 资源。 等待 Helm 启动的 pod 准备就绪。通过运行以下命令监控其状态:

$ kubectl --namespace=drycc get pods

您还应该注意到您的集群上已安装了几个 Kubernetes gatewayclass。您可以通过运行以下命令查看它:

$ kubectl get gatewayclass

根据 Workflow 组件初始化的顺序,一些 pod 可能会重新启动。这在安装期间很常见:如果组件的依赖项尚不可用,该组件将退出,Kubernetes 将自动重新启动它。

在这里,可以看到控制器、构建器和注册表都花了几次循环等待存储才能启动:

$ kubectl --namespace=drycc get pods
NAME                          READY     STATUS    RESTARTS   AGE
drycc-builder-hy3xv            1/1       Running   5          5m
drycc-controller-g3cu8         1/1       Running   5          5m
drycc-controller-celery-cmxxn  3/3       Running   0          5m
drycc-database-rad1o           1/1       Running   0          5m
drycc-fluentbit-1v8uk          1/1       Running   0          5m
drycc-fluentbit-esm60          1/1       Running   0          5m
drycc-storage-4ww3t            1/1       Running   0          5m
drycc-registry-asozo           1/1       Running   1          5m

安装 Kubernetes 网关

现在 Workflow 已使用 gatewayClass 部署,我们需要安装 Kubernetes 网关来开始路由流量。

以下是如何使用 istio 作为 Workflow 网关的示例。当然,您可以随意使用任何您希望的控制器。

$ helm repo add istio https://istio-release.storage.googleapis.com/charts
$ helm repo update
$ kubectl create namespace istio-system
$ helm install istio-base istio/base -n istio-system
$ helm install istiod istio/istiod -n istio-system --wait
$ kubectl create namespace istio-ingress
$ helm install istio-ingress istio/gateway -n istio-ingress --wait

配置 DNS

用户必须安装 drycc 然后设置主机名,并采用 *.$host 约定。

我们需要将 *.$host 记录指向您的网关的公共 IP 地址。您可以使用以下命令获取公共 IP。这里需要通配符条目,因为应用程序在部署后将使用相同的规则。

$ kubectl get gateway --namespace drycc
NAME      CLASS   ADDRESS         PROGRAMMED   AGE
gateway   istio   138.91.243.152  True         36d

如果我们使用 drycc.cc 作为主机名,我们需要创建以下 A DNS 记录。

名称 类型
*.drycc.cc A 138.91.243.152

一旦所有 pod 都处于 READY 状态,并且 *.$host 解析为上面找到的外部 IP,网关的准备就完成了!

安装 Workflow 后,注册用户并部署应用程序

如果您的 k8s 不提供公共网络负载均衡器,您需要在可以访问内部和外部网络的机器上安装 haproxy 等 TCP 代理服务,然后公开 80443

4 - 配置 Postgres

Drycc Workflow 的控制器和护照组件依赖 PostgreSQL 数据库来存储平台状态。

配置 Postgres

默认情况下,Drycc Workflow 附带 database 组件,它提供集群内 PostgreSQL 数据库,并备份到集群内或集群外 object storage。目前,对于对象存储(由_多个_ Workflow 组件使用),在生产环境中仅推荐集群外解决方案,如 S3 或 GCS。经验表明,许多操作员已经选择集群外对象存储,同样更喜欢在集群外托管 Postgres,使用 Amazon RDS 或类似服务。当同时行使这两个选项时,Workflow 安装变得完全无状态,因此在需要时可以更容易地恢复或重建。

提供集群外 Postgres

首先,使用您选择的云提供商或其他基础设施提供 PostgreSQL RDBMS。请注意确保安全组或其他防火墙规则将允许从您的 Kubernetes 工作节点连接,任何节点都可能托管 Workflow 控制器组件。

记下以下内容:

  1. 您的 PostgreSQL RDBMS 的主机名或公共 IP
  2. 您的 PostgreSQL RDBMS 运行的端口 - 通常为 5432

在集群外 RDBMS 中,手动提供以下内容:

  1. 数据库用户(记下用户名和密码)
  2. 该用户拥有的数据库(记下其名称)

如果您能够以超级用户或具有适当权限的用户身份登录 RDBMS,此过程通常如下所示:

$ psql -h <host> -p <port> -d postgres -U <"postgres" 或您自己的用户名>
> create user <drycc 用户名;通常为 "drycc"> with password '<password>';
> create database <数据库名称;通常为 "drycc"> with owner <drycc 用户名>;
> \q

配置 Workflow

Drycc Workflow 的 Helm chart 可以轻松配置以将 Workflow 控制器组件连接到集群外 PostgreSQL 数据库。

  • 步骤 1: 如果您尚未获取 values,请使用 helm inspect values drycc/workflow > values.yaml 获取
  • 步骤 2: 通过修改 values.yaml 更新数据库连接详细信息:
    • database.enabled 参数更新为 false
    • 更新 [database] 配置部分中的值以正确反映所有连接详细信息。
    • 更新 [controller] 配置部分中的值以正确反映 platformDomain 详细信息。
    • 保存您的更改。
    • 注意:您不需要(也不必须)对任何值进行 base64 编码,因为 Helm chart 将根据需要自动处理编码。

现在您可以使用 helm install drycc oci://registry.drycc.cc/charts/workflow --namespace drycc -f values.yaml 照常安装。

5 - 配置注册表

Drycc Workflow 的构建器组件依赖注册表来存储应用程序容器镜像。

Drycc Workflow 默认附带 registry 组件,它提供集群内容器注册表,由平台配置的 object storage 支持。操作员可能出于性能或安全原因想要使用集群外注册表。

配置集群外私有注册表

每个依赖注册表的组件使用两个输入进行配置:

  1. 名为 DRYCC_REGISTRY_LOCATION 的注册表位置环境变量
  2. 访问凭据存储为名为 registry-secret 的 Kubernetes secret

Drycc Workflow 的 Helm chart 可以轻松配置以将 Workflow 组件连接到集群外注册表。Drycc Workflow 支持外部注册表,这些注册表提供仅在指定时间内有效的短期令牌或永久有效的长期令牌(基本用户名/密码)来进行身份验证。对于那些提供短期令牌进行身份验证的注册表,Drycc Workflow 将生成并刷新它们,以便部署的应用程序只能访问短期令牌,而不是注册表的实际凭据。

使用私有注册表时,容器镜像不再由 Drycc Workflow Controller 拉取,而是由 Kubernetes 管理。这将提高安全性和整体速度,但是 port 信息不再能够被发现。相反,可以通过在部署应用程序之前使用 drycc config set PORT=<port> 设置 port 信息。

Drycc Workflow 目前支持:

  1. 集群外:任何支持长期用户名/密码身份验证的提供商,如 Azure Container RegistryDocker Hubquay.io 或自托管容器注册表。

配置

  1. 如果您尚未获取 values 文件,请使用 helm inspect values drycc/workflow > values.yaml 获取
  2. 通过修改 values 文件更新注册表位置详细信息: * 将 registry.enabled 参数更新为引用您使用的注册表位置:truefalse * 更新与您的注册表位置类型对应的部分中的值。

现在您可以使用所需的注册表运行 helm install drycc oci://registry.drycc.cc/charts/workflow --namespace drycc -f values.yaml

示例

在这里,我们展示了获取的 values.yaml 文件的相关部分在为特定集群外注册表配置后可能的样子:

Azure Container Registry (ACR)

按照 docs 创建注册表后,例如 myregistry,其对应的登录服务器为 myregistry.azurecr.io,应提供以下值:

builder:
  registryHost: "myregistry.azurecr.io"
  registryUsername: "xxxx"
  registryPassword: "xxxx"
  registryOrganization: "xxxx"
registry:
  enabled: false

注意: 强制性组织字段(此处为 myorg)将在 ACR 仓库中创建,如果它尚不存在。

Quay.io

builder:
  registryHost: "quay.io"
  registryUsername: "xxxx"
  registryPassword: "xxxx"
  registryOrganization: "xxxx"
registry:
  enabled: false

6 - 配置对象存储

各种 Drycc Workflow 组件依赖对象存储系统来完成工作,包括存储应用程序、容器镜像

Drycc Workflow 默认附带 Storage,它提供集群内存储。

配置集群外对象存储

每个依赖对象存储的组件使用两个输入进行配置:

  1. 您必须使用与 S3 API 兼容的对象存储服务。
  2. 访问凭据存储在Kubernetes secret之中以保证安全。

Drycc Workflow 的 helm chart 可以轻松配置以将 Workflow 组件连接到集群外对象存储。Drycc Workflow 目前支持 Google Compute Storage、Amazon S3、Azure Blob Storage 和 OpenStack Swift Storage。

步骤 1:创建存储桶

为每个 Workflow 子系统创建存储桶:builderregistry

根据您选择的对象存储,您可能需要提供全局唯一的桶名称。如果您使用 S3,请在桶名称中使用连字符而不是句点。在桶名称中使用句点会导致 S3 的 ssl 证书验证问题

如果您提供对底层存储有足够访问权限的凭据,Workflow 组件将在桶不存在时创建它们。

步骤 2:生成存储凭据

如果适用,生成对步骤 1 中创建的存储桶具有创建和写入访问权限的凭据。

如果您使用 AWS S3 并且您的 Kubernetes 节点通过 InstanceRoles 配置了适当的 IAM API 密钥,您不需要创建 API 凭据。但是,请验证 InstanceRole 对配置的桶具有适当的权限!

步骤 3:配置 Workflow Chart

操作员应该在运行 helm install 之前通过编辑 Helm values 文件来配置对象存储。为此:

  • 通过运行 helm inspect values oci://registry.drycc.cc/charts/workflow > values.yaml 获取 Helm values
  • 更新 builder/storageregistry/storage 参数以引用您使用的平台。
  • 找到您的存储类型的相应部分,并提供适当的值,包括区域、桶名称和访问凭据。
  • 保存您的更改。

现在您可以使用所需的集群外对象存储运行 helm install drycc oci://registry.drycc.cc/charts/workflow --namespace drycc -f values.yaml