mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-14 13:04:31 +00:00
Merge pull request #1262 from smallteeths/main-wsy-2.6
update missing Chinese translation for v2.6
This commit is contained in:
+11
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: 高级用户指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides"/>
|
||||
</head>
|
||||
|
||||
高级用户指南是“问题导向”的文档,用户可以从中学习如何解决问题。高级用于指南与新用户指南的主要区别在于,高级用户指南面向更有经验或更高级的用户,这些用户对文档有更多的技术需求,而且已经了解 Rancher 及其功能。他们知道自己需要做什么,只是需要额外的指导来完成更复杂的任务。
|
||||
|
||||
应该注意的是,新用户指南和高级用户指南都没有提供详细的解释或讨论(这些文档不包括在本部分)。操作指南侧重于引导用户通过可重复、有效的步骤来学习新技能、掌握某些操作或解决某些问题。
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: 项目资源配额
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas"/>
|
||||
</head>
|
||||
|
||||
如果多个团队共享一个集群,某个团队可能会使用过多的可用资源,例如 CPU、内存、存储、服务、Kubernetes 对象(如 Pod 或 Secret)等。你可以应用 _资源配额_ 来防止过度消耗资源。资源配额是 Rancher 用来限制项目或命名空间可用资源的功能。
|
||||
|
||||
本文介绍如何在现有项目中创建资源配额。
|
||||
|
||||
你也可以在创建新项目时设置资源配额。有关详细信息,请参阅[创建新项目](../../../new-user-guides/manage-clusters/projects-and-namespaces.md#创建项目)。
|
||||
|
||||
Rancher 中的资源配额包含与 [Kubernetes 原生版本](https://kubernetes.io/docs/concepts/policy/resource-quotas/)相同的功能。Rancher 还扩展了资源配额的功能,从而让你将资源配额应用于项目。有关资源配额如何与 Rancher 中的项目一起使用的详细信息,请参阅[此页面](about-project-resource-quotas.md)。
|
||||
|
||||
### 将资源配额应用于现有项目
|
||||
|
||||
修改资源配额的使用场景如下:
|
||||
|
||||
- 限制某个项目和项目下的命名空间能使用的资源
|
||||
- 在资源配额已生效的情况下,对项目可用的资源进行扩容或缩容
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面,进入要应用资源配额的集群,然后单击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 确保 **Projects/Namespaces** 页面处于 **Group by Project** 视图模式。
|
||||

|
||||
|
||||
1. 找到要添加资源配额的项目,选择与项目名称同行的 **⋮**。
|
||||

|
||||
|
||||
1. 选择**编辑配置**。
|
||||
|
||||
1. 展开**资源限额**并单击**添加资源**。你也可以编辑现有配额。
|
||||
|
||||
1. 选择资源类型。有关类型的更多信息,请参阅[配额类型参考](resource-quota-types.md)。
|
||||
|
||||
1. 输入**项目限制**和**命名空间默认限制**的值。
|
||||
|
||||
| 字段 | 描述 |
|
||||
| ----------------------- | -------------------------------------------------------------------------------------------------------- |
|
||||
| 项目限制 | 项目的总资源限制。 |
|
||||
| 命名空间默认限制 | 每个命名空间的默认资源限制。此限制会沿用到项目中的每个命名空间。项目中所有命名空间的限制之和不应超过项目限制。 |
|
||||
|
||||
1. **可选**:添加更多配额。
|
||||
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**:资源配额已应用到你的项目和命名空间。如果你后续需要添加更多命名空间,Rancher 会验证项目是否可以容纳该命名空间。如果项目无法分配资源,你仍然可以创建命名空间,但命名空间将获得的资源配额为 0。然后 Rancher 将不允许你创建任何受此配额限制的资源。
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: 项目管理
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides/manage-projects"/>
|
||||
</head>
|
||||
|
||||
_项目_ 是 Rancher 中引入的对象,可帮助你更有组织地管理 Kubernetes 集群中的命名空间。你可以使用项目创建多租户集群,这种集群允许一组用户共享相同的底层资源来创建应用,而应用之间不会相互影响。
|
||||
|
||||
在层次结构方面:
|
||||
|
||||
- 集群包含项目
|
||||
- 项目包含命名空间
|
||||
|
||||
在 Rancher 中,你可以使用项目将多个命名空间作为一个实体进行管理。在原生 Kubernetes(没有项目这个概念)中,RBAC 或集群资源等功能被分配给了各个命名空间。如果集群中的多个命名空间需要分配同样的访问权限,分配权限会变得非常繁琐。即使所有命名空间都需要相同的权限,但也无法使用一个操作中将这些权限应用于所有命名空间。你必须重复地将这些权限分配给每个命名空间。
|
||||
|
||||
而 Rancher 通过引入项目的概念,通过允许你在项目级别应用资源和访问权限。然后,项目中的每个命名空间都会继承这些资源和策略。因此你只需将资源和策略分配给项目即可,不需要将它们分配给每个单独的命名空间。
|
||||
|
||||
你可以使用项目执行以下操作:
|
||||
|
||||
- [为用户分配一组命名空间的访问权限](../../new-user-guides/add-users-to-projects.md)
|
||||
- 为用户分配[项目中的特定角色](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#项目角色)。角色可以是所有者、成员、只读或[自定义](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md)
|
||||
- [设置资源配额](manage-project-resource-quotas/manage-project-resource-quotas.md)
|
||||
- [管理命名空间](../../new-user-guides/manage-namespaces.md)
|
||||
- [配置工具](../../../reference-guides/rancher-project-tools.md)
|
||||
- [持续集成和部署设置流水线](ci-cd-pipelines.md)
|
||||
- [配置 Pod 安全策略](manage-pod-security-policies.md)
|
||||
|
||||
### 授权
|
||||
|
||||
非管理者用户只有在[管理员](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)、[集群所有者或成员](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#集群角色)或[项目所有者](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#项目角色)将非管理员用户添加到项目的**成员**选项卡后,才能获取项目的访问权限。
|
||||
|
||||
创建项目的人自动成为[项目所有者](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#项目角色)。
|
||||
|
||||
## 在项目之间切换
|
||||
|
||||
要在项目之间切换,请使用导航栏中的下拉菜单。你也可以直接在导航栏中切换项目:
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面,进入要切换项目的集群然后点击 **Explore**。
|
||||
1. 在顶部导航栏中,选择要打开的项目。
|
||||
+117
@@ -0,0 +1,117 @@
|
||||
---
|
||||
title: 备份和灾难恢复
|
||||
keywords: [rancher v2.6 备份还原, rancher v2.6 备份与还原, 备份恢复 rancher v2.6, rancher v2.6 备份与恢复]
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery"/>
|
||||
</head>
|
||||
|
||||
在本节中,你将学习如何创建 Rancher 的备份,如何从备份中恢复 Rancher,以及如何将 Rancher 迁移到新的 Kubernetes 集群。
|
||||
|
||||
`rancher-backup` operator 可以用来备份和恢复任何 Kubernetes 集群上的 Rancher。这个应用是一个 Helm Chart,可以通过 Rancher 的 **Apps & Marketplace** (Rancher v2.6.5 之前的版本) 或者 **Apps** (Rancher v2.6.5+) 页面,或使用 Helm CLI 部署。你可以访问[本页面](https://github.com/rancher/charts/tree/release-v2.6/charts/rancher-backup)获取 `rancher-backup` Helm Chart。
|
||||
|
||||
backup-restore operator 需要安装在 local 集群上,并且只对 Rancher 应用进行备份。备份和恢复操作仅在本地 Kubernetes 集群中执行。
|
||||
|
||||
|
||||
## 备份和恢复 Docker 安装的 Rancher
|
||||
|
||||
对于使用 Docker 安装的 Rancher,请参见[备份](back-up-docker-installed-rancher.md)和[恢复](restore-docker-installed-rancher.md)对 Rancher 进行备份和恢复。
|
||||
|
||||
## 备份和恢复原理
|
||||
|
||||
`rancher-backup` operator 引入了三个自定义资源,分别是 Backups、Restores 和 ResourceSets。将以下集群范围的自定义资源定义添加到集群中:
|
||||
|
||||
- `backups.resources.cattle.io`
|
||||
- `resourcesets.resources.cattle.io`
|
||||
- `restores.resources.cattle.io`
|
||||
|
||||
ResourceSet 定义了需要备份哪些 Kubernetes 资源。由于备份 Rancher 所需的值是预设的,因此 ResourceSet 无法通过 Rancher UI 进行配置。请不要修改此 ResourceSet。
|
||||
|
||||
在创建 Backup 自定义资源时,`rancher-backup` operator 调用 `kube-apiserver` 来获取 Backup 自定义资源引用的 ResourceSet(即预设的 `rancher-resource-set`)资源。
|
||||
|
||||
然后,operator 以 .tar.gz 格式创建备份文件,并将其存储在 Backup 资源中配置的位置。
|
||||
|
||||
在创建 Restore 自定义资源时,operator 访问 Restore 指定的 tar.gz 备份文件,并从该文件恢复应用。
|
||||
|
||||
你可以使用 Rancher UI 或 `kubectl apply` 来创建 Backup 和 Restore 自定义资源。
|
||||
|
||||
:::note
|
||||
|
||||
请参见[此处](migrate-rancher-to-new-cluster.md#2-使用-restore-自定义资源来还原备份)获取在 Rancher 2.6.3 中将现有备份文件恢复到 v1.22 集群的帮助。
|
||||
|
||||
:::
|
||||
|
||||
## 安装 rancher-backup operator
|
||||
|
||||
你可以使用 Rancher UI 或 Helm CLI 来安装 `rancher-backup` operator。两种安装方法都将 `rancher-backup` Helm Chart 安装在运行 Rancher Server 的 Kubernetes 集群上。它是集群管理员独有的功能,仅适用于 **local** 集群。(*如果你在 Rancher UI 中没有看到 `rancher-backup`,你可能选择了错误的集群。*)
|
||||
|
||||
:::note
|
||||
|
||||
使用 backup-restore-operator 执行恢复后,Fleet 中会出现一个已知问题:用于 clientSecretName 和 helmSecretName 的密文不包含在 Fleet 的 Git 仓库中。请参见[此处](../../../integrations-in-rancher/fleet-gitops-at-scale/fleet-gitops-at-scale.md#故障排除)获得解决方法。
|
||||
|
||||
:::
|
||||
|
||||
### 使用 Rancher UI 安装 rancher-backup
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.6.5+">
|
||||
|
||||
1. 在左上角,单击 **☰ > Cluster Management**。
|
||||
1. 在 **Clusters** 页面上,转到 `local` 集群并单击 **Explore**。
|
||||
1. 在左侧导航栏中,单击 **Apps > Charts**。
|
||||
1. 点击 **Rancher 备份**。
|
||||
1. 单击**安装**。
|
||||
1. 可选:配置默认存储位置。如需获取帮助,请参见[配置](../../../reference-guides/backup-restore-configuration/storage-configuration.md)。
|
||||
1. 单击**安装**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.6.5">
|
||||
|
||||
1. 在左上角,点击 **☰ > Cluster Management**。
|
||||
1. 在 **Clusters** 页面, 转到 `local` 集群并点击 **Explore**。
|
||||
1. 在左侧导航栏中,选择, **Apps & Marketplace > Charts**。
|
||||
1. 点击 **Rancher Backups**。
|
||||
1. 点击 **Install**。
|
||||
1. 可选:配置默认存储位置。需要帮助,请参阅 [configuration 章节。](../../../reference-guides/backup-restore-configuration/storage-configuration.md)
|
||||
1. 点击 **Install**。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**结果**:`rancher-backup` operator 已安装。
|
||||
|
||||
在**集群仪表板**中,你可以看到列在 **Deployments** 下的 `rancher-backup` operator。
|
||||
|
||||
如果需要在 Rancher 中配置备份应用,在左侧导航栏中单击 **Rancher 备份**。
|
||||
|
||||
### RBAC
|
||||
|
||||
只有 Rancher 管理员和本地集群的所有者可以:
|
||||
|
||||
* 安装 Chart
|
||||
* 看到 Backup 和 Restore CRD 的导航链接
|
||||
* 通过分别创建 Backup CR 和 Restore CR 执行备份和恢复
|
||||
* 列出目前已执行的备份和恢复操作
|
||||
|
||||
## 备份 Rancher
|
||||
|
||||
备份是通过创建 Backup 自定义资源实现的。如需查看教程,请参见[本页面](back-up-rancher.md)。
|
||||
|
||||
## 还原 Rancher
|
||||
|
||||
还原是通过创建 Restore 自定义资源实现的。如需查看教程,请参见[本页面](restore-rancher.md)。
|
||||
|
||||
## 将 Rancher 迁移到新集群
|
||||
|
||||
你可以按照[这些步骤](migrate-rancher-to-new-cluster.md)执行迁移。
|
||||
|
||||
## 默认存储位置配置
|
||||
|
||||
配置一个默认存储位置,所有备份都将保存在其中。您将可以选择在每个备份中覆盖此选项,但仅限于使用与 S3 兼容或 Minio 对象存储。
|
||||
|
||||
如需了解各个选项的配置,请参见[本页面](../../../reference-guides/backup-restore-configuration/storage-configuration.md)。
|
||||
|
||||
### rancher-backup Helm Chart 的示例 values.yaml
|
||||
|
||||
当使用 Helm CLI 安装时,可以使用示例 [values.yaml 文件](../../../reference-guides/backup-restore-configuration/storage-configuration.md#rancher-backup-helm-chart-的示例-valuesyaml) 来配置 `rancher-backup` operator 。
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: 跨集群部署应用
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/deploy-apps-across-clusters"/>
|
||||
</head>
|
||||
|
||||
不同版本的 Rancher 提供了几种不同的方式来部署跨集群应用。
|
||||
|
||||
## Fleet
|
||||
|
||||
Rancher v2.5 及更高版本使用 Fleet 跨集群部署应用
|
||||
|
||||
使用 Fleet 的持续交付是大规模的 GitOps。如需更多信息,请参阅 [Fleet](fleet.md)。
|
||||
|
||||
### 多集群应用
|
||||
|
||||
在 v2.5 之前的 Rancher 中,多集群应用功能用于跨集群部署应用。多集群应用功能已弃用,但仍可作为旧版功能使用。
|
||||
|
||||
详情请参阅[此文档](multi-cluster-apps.md)。
|
||||
+188
@@ -0,0 +1,188 @@
|
||||
---
|
||||
title: Helm Charts 和 Apps
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/helm-charts-in-rancher"/>
|
||||
</head>
|
||||
|
||||
在本节中,你将学习如何在 Rancher 中管理 Helm Chart 仓库和应用。
|
||||
|
||||
## Helm Charts 在 Rancher 中的工作原理
|
||||
|
||||
Rancher 使用应用商店系统导入一系列的 charts 包到仓库里,然后使用这些 charts 来部署自定义的 Kubernetes 应用程序或 Rancher 的工具,如监控(Monitoring)或 Istio。Rancher 工具预先集成进了仓库,并通过独立的 Helm chart 进行部署。如果你有自己的额外仓库只需要添加到当前的集群中就可以正常部署。
|
||||
|
||||
### Catalogs, Apps, Rancher UI
|
||||
|
||||
[在 Rancher v2.4 及更早版本中](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), 存储部署的应用程序的仓库被称为 "catalogs"。这些仓库是通过 UI 的 **Catalogs** 进行管理的。
|
||||
|
||||
Helm chart 仓库现在使用 **Apps & Marketplace**(Rancher v2.6.5之前)或 **Apps**(Rancher v2.6.5及以后版本)进行管理。
|
||||
|
||||
### Rancher v2.6 中的版本变更
|
||||
|
||||
从 Rancher v2.6.0 开始,为 Rancher chart 实施了新的版本设计方案。方案主要围绕 charts 的主要版本以及与上游 charts 相关的 `+up` 注释进行设计。
|
||||
|
||||
**主要版本:** charts 的主要版本与 Rancher 的次要版本相关联。当你升级到新的 Rancher 次要版本时,你应该确保所有的 charts 也被升级对应的主版本。
|
||||
|
||||
**基于上游的 Charts:** 在升级时,确保上游 chart 的版本与你的 Rancher 版本兼容。chart 的 `+up` 注释指示 Rancher chart 正在跟踪的上游版本。例如,`100.x.x+up16.6.0` 的监控(Monitoring)跟踪上游的 kube-prometheus-stack `16.6.0` 并附带一些额外的 Rancher 补丁。
|
||||
|
||||
在升级 Rancher 版本时,不要降级你正在使用的 chart 版本。例如,如果你在 Rancher v2.5 中使用的监控版本比 `16.6.0` 还要高,你不应该升级到 `100.x.x+up16.6.0`,而是应该在下一个发布中升级到适当的版本。
|
||||
|
||||
:::note
|
||||
|
||||
下表中提及的主要版本之下的任何版本均仅适用于 2.5 及以下版本。例如,在 2.6.x 及以上版本中,建议您不要使用 <100.x.x 版本的监控。
|
||||
|
||||
:::
|
||||
|
||||
### 版本控制方案
|
||||
|
||||
| **Name** | **支持的最低版本** | **支持的最高版本** |
|
||||
| ---------------- | ------------ | ------------ |
|
||||
| external-ip-webhook | 100.0.0+up1.0.0 | 100.0.1+up1.0.1 |
|
||||
| harvester-cloud-provider | 100.0.2+up0.1.12 | 100.0.2+up0.1.12 |
|
||||
| harvester-csi-driver | 100.0.2+up0.1.11 | 100.0.2+up0.1.11 |
|
||||
| neuvector | 100.0.0+up2.2.0 | 100.0.0+up2.2.0 |
|
||||
| rancher-alerting-drivers | 100.0.0 | 100.0.2 |
|
||||
| rancher-backup | 2.0.1 | 2.1.2 |
|
||||
| rancher-cis-benchmark | 2.0.1 | 2.0.4 |
|
||||
| rancher-gatekeeper | 100.0.0+up3.6.0 | 100.1.0+up3.7.1 |
|
||||
| rancher-istio | 100.0.0+up1.10.4 | 100.3.0+up1.13.3 |
|
||||
| rancher-logging | 100.0.0+up3.12.0 | 100.1.2+up3.17.4 |
|
||||
| rancher-longhorn | 100.0.0+up1.1.2 | 100.1.2+up1.2.4 |
|
||||
| rancher-monitoring | 100.0.0+up16.6.0 | 100.1.2+up19.0.3 |
|
||||
| rancher-sriov (experimental) | 100.0.0+up0.1.0 | 100.0.3+up0.1.0 |
|
||||
| rancher-vsphere-cpi | 100.3.0+up1.2.1 | 100.3.0+up1.2.1 |
|
||||
| rancher-vsphere-csi | 100.3.0+up2.5.1-rancher1 | 100.3.0+up2.5.1-rancher1 |
|
||||
| rancher-wins-upgrader | 0.0.100 | 100.0.1+up0.0.1 |
|
||||
|
||||
## 访问 Charts
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.6.5+">
|
||||
|
||||
从左上角菜单中选择 **Apps** 然后您将进入 **Charts** 页面。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.6.5">
|
||||
|
||||
从左上角菜单中选择 **Apps & Marketplace** 然后您将进入 **Charts** 页面。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Charts** 页面包含所有 Rancher、Rancher 合作伙伴和自定义 Chart。你可以通过选择左侧的下拉菜单来筛选 Chart:
|
||||
|
||||
* Rancher 工具(例如 Logging 或 Monitoring)包含在 **Rancher** 标签下
|
||||
* Partner Chart 位于 **Partner** 标签下
|
||||
* 自定义 Chart 将显示在仓库的名称下
|
||||
|
||||
所有这三种类型都以相同的方式部署和管理。
|
||||
|
||||
:::note
|
||||
|
||||
在传统的 Rancher UI 中由集群管理器管理的应用程序(全局视图)应继续只由集群管理器管理,在新 UI 中使用 **Apps & Marketplace** (Rancher v2.6.5 之前)或 **Apps**(Rancher v2.6.5+)管理的应用程序必须仅由 **Apps & Marketplace** 或 **Apps** 管理。
|
||||
|
||||
:::
|
||||
|
||||
### 管理仓库
|
||||
|
||||
**Repositories** 页面列出了你的 Helm 仓库。 这包括传统的具有 index.yaml 的 Helm 端点,以及克隆并指向特定分支的 Git 仓库。要使用自定义 Charts,在这里可以添加你的仓库。添加仓库后,你可以在 **Charts** 页面中访问自定义 Charts,这些 Charts 将列在仓库的名称下。
|
||||
|
||||
访问 **Repositories**,从左侧导航菜单中选择 **Repositories** 。
|
||||
|
||||
### 添加自定义 Git 仓库
|
||||
|
||||
要添加一个包含你的 Helm Charts 或集群模板定义的自定义 Git 仓库:
|
||||
|
||||
1. 从左侧导航菜单中选择 **Repositories**。
|
||||
2. 点击 **Create**。
|
||||
3. 选择 **Git repository containing Helm chart...**。
|
||||
4. 您必须输入一个名称和一个 Git仓 库 URL。 其他字段,包括描述,都是可选的。如果您不想从仓库所有者设置为默认的分支中拉取,请输入一个备用分支名称。通常,默认分支命名为 `main` 或 `master`。
|
||||
5. 点击 **Create** 添加仓库。
|
||||
|
||||
在 Rancher 中添加 Charts 仓库后,它将立即生效。
|
||||
|
||||
### 添加自定义 Helm Chart 仓库
|
||||
|
||||
你可以将自己的 Helm chart 仓库添加到 Rancher。为了能正确添加 http 的 Helm Chart 仓库,你需要提供 chart 的服务器并能够响应 GET 请求并提供 YAML 文件和 tar 包。
|
||||
|
||||
有关 Helm chart 仓库的更多信息,请参阅 [官方 Helm 文档](https://helm.sh/docs/topics/chart_repository/)。
|
||||
|
||||
1. 从左侧导航菜单中选择 **Repositories** 。
|
||||
1. 点击 **Create**。
|
||||
1. 选择 **http(s) URL to an index generated by Helm**。
|
||||
1. 输入一个仓库名称和 chart repository 的 index URL 地址。
|
||||
|
||||
### 添加私有 Git/Helm Chart 仓库
|
||||
|
||||
你可以使用 SSH 密钥凭据或 HTTP 基础认证秘密(如用户名和密码)添加私有 Git 或 Helm chart 仓库。
|
||||
|
||||
### 向仓库添加私有 CA
|
||||
|
||||
将私有 CA 添加到 Helm chart 仓库:
|
||||
|
||||
1. 从左侧导航菜单中选择 **Repositories**。
|
||||
2. 找到你想要向其添加私有 CA 证书的 Git 或 HTTP 的仓库。点击 **⋮ > Edit YAML**。
|
||||
3. 设置 `caBundle` 值,如以下示例:
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
spec:
|
||||
caBundle:
|
||||
MIIFXzCCA0egAwIBAgIUWNy8WrvSkgNzV0zdWRP79j9cVcEwDQYJKoZIhvcNAQELBQAwPzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRQwEgYDVQQKDAtNeU9yZywgSW5jLjENMAsGA1UEAwwEcm9vdDAeFw0yMTEyMTQwODMyMTdaFw0yNDEwMDMwODMyMT
|
||||
...
|
||||
nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
|
||||
[...]
|
||||
```
|
||||
|
||||
:::note 带有认证的 Helm chart 仓库
|
||||
|
||||
从 Rancher v2.6.3 开始,Repo.Spec 中添加了一个新值 `disableSameOriginCheck` ,这允许用户绕过同源检查,在所有 API 调用中以 Basic Auth Header 的形式发送仓库身份验证信息。这并不推荐,但在非标准 Helm chart 仓库的情况下,例如具有重定向到不同源 URL 的仓库,可以作为临时解决方案使用。
|
||||
|
||||
要将此功能用于现有 Helm Chart,点击 **⋮ > Edit YAML**。在 YAML 文件的 `spec` 部分,添加 `disableSameOriginCheck` 并将其设置为 `true`:
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
spec:
|
||||
disableSameOriginCheck: true
|
||||
[...]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### Helm 兼容性
|
||||
|
||||
仅支持 Helm 3 兼容 Chart 。
|
||||
|
||||
### 部署和升级 Chart
|
||||
|
||||
从 **Charts** 标签页中选择要安装的 chart。Rancher 和合作伙伴 chart 可能通过自定义页面或 questions.yaml 文件提供额外的配置,但所有chart 安装都可以修改 values.yaml 和其他基本设置。点击安装后,将部署一个 Helm 操作作业,并显示作业的控制台。
|
||||
|
||||
要查看所有最近的更改,请转到 **Recent Operations** 标签页。从那里,您可以查看所进行的调用、条件、事件和日志。
|
||||
|
||||
安装 chart 后,您可以在 **Installed Apps** 标签页中找到它。在本节中,你可以升级或删除安装,并查看更多详细信息。选择升级时,呈现的形式和数值与安装相同。
|
||||
|
||||
大多数 Rancher 工具在 **Apps & Marketplace** 下方的工具栏中都有额外的页面,以帮助你管理和使用这些功能。这些页面包括指向仪表板的链接、可轻松添加自定义资源的表单以及其他信息。
|
||||
|
||||
:::caution
|
||||
|
||||
如果在升级前使 **自定义 Helm 选项**,并且你的 Chart 中包含不可更改的字段,请注意使用 `--force` 选项可能会导致错误,如果您的 Chart 具有不可变字段。这是因为 Kubernetes 中的某些对象一旦创建就无法更改。要避免该错误,你可以:
|
||||
|
||||
* 使用默认升级选项(即不要使用 `--force` 选项)
|
||||
* 卸载现有 Chart 并安装升级后的 Chart
|
||||
* 在执行 `--force` 升级之前,从集群中删除具有不可变字段的资源。
|
||||
|
||||
:::
|
||||
|
||||
#### Rancher v2.6.3 的变更
|
||||
|
||||
在 **Apps > Installed Apps** 页面上,旧版应用没有升级按钮。
|
||||
|
||||
如果你想升级已安装的旧版应用, 必须启用[旧版功能](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。 如果你在升级 Rancher 之前已经运行了旧版应用,此标志会自动启用。
|
||||
|
||||
- 您可以从集群资源管理器中,从左侧导航栏的 **Legacy > Project > Apps** 部分升级该应用。
|
||||
- 对于多集群应用程序,您可以跳转到 **≡ > Multi-cluster Apps** 并从那里升级应用程序。
|
||||
|
||||
### 限制
|
||||
|
||||
Rancher CLI 不能用于安装仪表板应用程序或 Rancher 功能 Chart。
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: Horizontal Pod Autoscaler
|
||||
description: 了解 Pod 水平自动扩缩 (HPA)。如何管理 HPA 以及如何使用服务部署来进行测试
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler"/>
|
||||
</head>
|
||||
|
||||
[Horizontal Pod Autoscaler(HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)是一项 Kubernetes 功能,用于将集群配置为自动扩缩其运行的服务。
|
||||
|
||||
Rancher 提供了一些附加功能来帮助管理 HPA,具体取决于 Rancher 的版本。
|
||||
|
||||
你可以使用 Rancher UI 创建、管理和删除 HPA。仅在 `autoscaling/v2beta2` API 中支持 HPA。
|
||||
|
||||
## 管理 HPA
|
||||
|
||||
管理 HPA 的方式因你的 Kubernetes API 版本而异:
|
||||
|
||||
- **Kubernetes API 版本 autoscaling/V2beta1**:允许根据应用程序的 CPU 和内存利用率自动扩缩 pod。
|
||||
- **Kubernetes API 版本 autoscaling/V2beta2**:允许根据 CPU 和内存利用率以及自定义指标自动扩缩 pod。
|
||||
|
||||
你可以使用 Rancher UI 创建、管理和删除 HPA。在 Rancher UI 中,你可以将 HPA 配置为根据 CPU 和内存利用率进行扩缩。有关详细信息,请参阅[使用 Rancher UI 管理 HPA](manage-hpas-with-ui.md)。如需根据自定义指标进行 HPA,你仍然需要使用 `kubectl`。有关详细信息,请参阅[配置 HPA 以使用 Prometheus 自定义指标进行扩缩](manage-hpas-with-kubectl.md#使用资源指标cpu-和内存配置-hpa-以进行扩缩)。
|
||||
|
||||
在 Rancher 2.0.7 及更高版本中创建的集群自动满足使用 HPA 的所有要求(metrics-server 和 Kubernetes 集群配置)。
|
||||
## 使用服务部署测试 HPA
|
||||
|
||||
你可以转到你的项目并单击 **资源 > HPA** 来查看 HPA 当前的副本数。有关详细信息,请参阅[获取 HPA 指标和状态](manage-hpas-with-ui.md)。
|
||||
|
||||
你还可以使用 `kubectl` 来获取你使用负载测试工具测试的 HPA 的状态。有关详细信息,请参阅[使用 kubectl 测试 HPA](test-hpas-with-kubectl.md)。
|
||||
+73
@@ -0,0 +1,73 @@
|
||||
---
|
||||
title: Kubernetes 资源
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/kubernetes-resources-setup"/>
|
||||
</head>
|
||||
|
||||
你可以在 Rancher UI 中查看和操作 Kubernetes 集群中的所有自定义资源和 CRD。
|
||||
|
||||
## 工作负载
|
||||
|
||||
使用[工作负载](workloads-and-pods/workloads-and-pods.md)将应用部署到集群节点,工作负载是包含用于运行应用的 pod 的对象,以及为部署行为设置规则的元数据。工作负载可以部署在集群范围内,也可以部署在一个命名空间内。
|
||||
|
||||
部署工作负载时,你可以使用任何镜像进行部署。可供选择的[工作负载类型](workloads-and-pods/workloads-and-pods.md#工作负载类型)有多种,工作负载类型决定了你的应用程序的运行方式。
|
||||
|
||||
在工作负载部署之后,你可以继续使用它。你可以:
|
||||
|
||||
- 将工作负载[升级](workloads-and-pods/upgrade-workloads.md)到它运行的应用的更新版本。
|
||||
- 如果升级出现问题,将工作负载[回滚](workloads-and-pods/roll-back-workloads.md)到以前的版本。
|
||||
- [添加一个 sidecar](workloads-and-pods/add-a-sidecar.md),这是一个支持主要工作负载的工作负载。
|
||||
|
||||
## 负载均衡和 Ingress
|
||||
|
||||
### 负载均衡器
|
||||
|
||||
启动应用程序后,它仅在集群中可用。无法从外部访问它。
|
||||
|
||||
如果你希望你的应用程序可以从外部访问,则必须向集群添加负载均衡器。如果用户知道负载均衡器的 IP 地址和应用的端口号,负载均衡器可以为外部连接创建一个访问集群的网关。
|
||||
|
||||
Rancher 支持两种类型的负载均衡器:
|
||||
|
||||
- [Layer-4 负载均衡器](load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing.md#layer-4-load-balancer#四层负载均衡器)
|
||||
- [Layer-7 负载均衡器](load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing.md#七层负载均衡器)
|
||||
|
||||
有关详细信息,请参阅[负载均衡器](load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing.md)。
|
||||
|
||||
#### Ingress
|
||||
|
||||
负载均衡器只能处理每个 service 的一个 IP 地址。换言之,如果你在集群中运行了多个 service,则必须为每个 service 配备一个负载均衡器。运行多个负载均衡器的花费可能非常高昂。因此,你可以使用 Ingress 来解决此问题。
|
||||
|
||||
Ingress 是一组充当负载均衡器的规则。Ingress 与一个或多个 Ingress Controller 一起动态路由 service 的请求。Ingress 收到请求时,集群中的 Ingress Controller 会对负载均衡器进行配置,从而根据你配置的 service 子域或路径规则将请求定向到正确的 service。
|
||||
|
||||
有关详细信息,请参阅 [Ingress](load-balancer-and-ingress-controller/add-ingresses.md)。
|
||||
|
||||
在项目中使用 Ingress 时,你可以通过设置全局 DNS 条目来将 Ingress 主机名编程到外部 DNS。
|
||||
|
||||
## 服务发现
|
||||
|
||||
使用负载均衡器和/或 Ingress 将集群公开给外部请求后,你只能通过 IP 地址访问集群。要创建可解析的主机名,你必须创建服务记录,该记录将 IP 地址、外部主机名、DNS 记录别名、工作负载或标记的 pod 映射到特定主机名。
|
||||
|
||||
有关详细信息,请参阅[服务发现](create-services.md)。
|
||||
|
||||
## 流水线
|
||||
|
||||
在将您的项目[配置到版本控制提供商](../../../reference-guides/pipelines/pipelines.md#1-配置版本控制提供程序)之后,您可以添加仓库并开始为每个仓库配置流水线。
|
||||
|
||||
更多信息,请[参阅](../../../reference-guides/pipelines/pipelines.md)。
|
||||
|
||||
## 应用程序
|
||||
|
||||
除了启动应用程序的各个组件外,你还可以使用 Rancher 应用商店来启动应用,即 Helm Chart。
|
||||
|
||||
## Kubernetes 资源
|
||||
|
||||
在 Rancher 项目或命名空间的上下文中,_资源_ 是支持 Pod 操作的文件和数据。在 Rancher 中,证书、镜像仓库和密文都被视为资源。但是,Kubernetes 将资源划分为不同类型的[密文(secret)](https://kubernetes.io/docs/concepts/configuration/secret/)。因此,在单个项目或命名空间中,各个资源必须具有唯一的名称以避免冲突。资源主要用于承载敏感信息,但也有其他用途。
|
||||
|
||||
资源包括:
|
||||
|
||||
- [证书](encrypt-http-communication.md):用于加密/解密进入或离开集群的数据的文件。
|
||||
- [ConfigMap](configmaps.md):存储一般配置信息的文件,例如一组配置文件。
|
||||
- [密文](secrets.md):存储密码、token 或密钥等敏感数据的文件。
|
||||
- [镜像仓库](kubernetes-and-docker-registries.md):携带用于验证私有镜像仓库的凭证的文件。
|
||||
+65
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: 在 Rancher 中设置负载均衡器和 Ingress Controller
|
||||
description: 了解如何设置负载均衡器和 Ingress Controller 以在 Rancher 中重定向服务请求,并了解负载均衡器的限制
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller"/>
|
||||
</head>
|
||||
|
||||
在 Rancher 中,你可以通过设置负载均衡器和 Ingress Controller 来重定向服务请求。
|
||||
|
||||
## 负载均衡器
|
||||
|
||||
启动应用程序后,该应用程序仅在集群内可用。你无法从集群外部访问它。
|
||||
|
||||
如果你希望从外部访问应用程序,则必须向集群添加负载均衡器或 Ingress。如果用户知道负载均衡器的 IP 地址和应用的端口号,负载均衡器可以为外部连接创建一个访问集群的网关。
|
||||
|
||||
Rancher 支持两种类型的负载均衡器:
|
||||
|
||||
- [Layer-4 负载均衡器](layer-4-and-layer-7-load-balancing.md#四层负载均衡器)
|
||||
- [Layer-7 负载均衡器](layer-4-and-layer-7-load-balancing.md#七层负载均衡器)
|
||||
|
||||
有关详细信息,请参阅[负载均衡器](layer-4-and-layer-7-load-balancing.md)。
|
||||
|
||||
### 负载均衡器限制
|
||||
|
||||
负载均衡器有几个需要注意的限制:
|
||||
|
||||
- 负载均衡器只能处理每个 service 的一个 IP 地址。换言之,如果你在集群中运行了多个 service,则必须为每个 service 配备一个负载均衡器。运行多个负载均衡器的花费可能非常高昂。
|
||||
|
||||
- 如果你想将负载均衡器与托管的 Kubernetes 集群(即托管在 GKE、EKS 或 AKS 中的集群)一起使用,则负载均衡器必须运行在该云提供商的基础设施上。请根据你配置集群的方式查看负载均衡器的兼容列表:
|
||||
|
||||
- [支持 Layer-4 负载均衡](layer-4-and-layer-7-load-balancing.md#四层负载均衡支持)
|
||||
|
||||
- [支持 Layer-7 负载均衡](layer-4-and-layer-7-load-balancing.md#七层负载均衡支持)
|
||||
|
||||
## Ingress
|
||||
|
||||
如上所述,使用负载均衡器的缺点是:
|
||||
|
||||
- 每个服务负载均衡器只能处理一个 IP 地址。
|
||||
- 如果你在集群中运行多个服务,则每个服务都必须配备一个负载均衡器。
|
||||
- 为每个服务配备负载均衡器的花费可能非常高昂。
|
||||
|
||||
相反,如果将某个 Ingress 用作集群的入口点,Ingress 可以更灵活地将流量路由到多个 service。它可以将多个 HTTP 请求映射到 service,而无需为每个 service 提供单独的 IP 地址。
|
||||
|
||||
因此,如果你需要使用相同的 IP 地址、Layer 7 协议或特权节点端口(80 和 443)来公开多个 service,你可以使用一个 Ingress。
|
||||
|
||||
Ingress 与一个或多个 Ingress Controller 一起动态路由 service 的请求。Ingress 收到请求时,集群中的 Ingress Controller 会根据你配置的 service 子域或路径规则将请求定向到正确的 service。
|
||||
|
||||
每个 Kubernetes Ingress 资源都对应一个 `/etc/nginx/sites-available/` 中的文件,其中包含一个配置对特定文件和文件夹的请求的 `server{}` 配置块。
|
||||
|
||||
Ingress 能为你的集群创建一个入口端口(与负载均衡器类似),可以位于集群的内部或外部。RKE 启动的集群中的 Ingress 和 Ingress Controller 由 [Nginx](https://www.nginx.com/) 提供支持。
|
||||
|
||||
Ingress 还支持其他功能,例如 SSL 终止、基于名称的虚拟主机等。
|
||||
|
||||
:::note 在高可用性配置中使用 Rancher:
|
||||
|
||||
请避免将 Ingress 添加到 `local` 集群。Rancher 将 Nginx Ingress Controller 作为 Rancher 管理的 _所有_ 集群的全局入口点,其中包括 `local` 集群。因此,当用户尝试访问应用程序时,Rancher 可能会由于重新加载 Nginx 配置而断开连接。要解决这个问题,我们建议你仅在通过 Rancher 启动的集群中部署应用程序。
|
||||
|
||||
:::
|
||||
|
||||
- 有关如何在 Rancher 中设置 Ingress 的更多信息,请参阅 [Ingress](add-ingresses.md)。
|
||||
- 有关 Ingress 和 Ingress Controller 的完整信息,请参阅 [Kubernetes Ingress 文档](https://kubernetes.io/docs/concepts/services-networking/ingress/)。
|
||||
- 在项目中使用 Ingress 时,你可以通过设置全局 DNS 条目来将 Ingress 主机名编程到外部 DNS。
|
||||
+82
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: "Kubernetes 工作负载和 Pod"
|
||||
description: "了解在 Kubernetes 中构建复杂容器化应用程序的两种结构:Kubernetes 工作负载和 Pod"
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods"/>
|
||||
</head>
|
||||
|
||||
你可以使用两种基本结构(pod 和工作负载)在 Kubernetes 中构建复杂的容器化应用程序。构建应用程序后,你可以使用第三种结构(service)在集群中或互联网上公开应用程序。
|
||||
|
||||
### Pod
|
||||
|
||||
[_Pod_](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) 是一个或多个共享网络命名空间和存储卷的容器。大多数 pod 只有一个容器。因此,我们讨论的 _pod_ 通常等同于 _容器_。扩展 pod 的方式与扩展容器的方式相同,即配置实现服务的同一 pod 的多个实例。通常,Pod 会根据工作负载进行扩展和管理。
|
||||
|
||||
### 工作负载
|
||||
|
||||
_工作负载_ 是为 pod 设置部署规则的对象。Kubernetes 基于这些规则执行部署,并根据应用程序的当前状态来更新工作负载。
|
||||
工作负载让你可以定义应用程序调度、扩展和升级的规则。
|
||||
|
||||
#### 工作负载类型
|
||||
|
||||
Kubernetes 将工作负载分为不同的类型。Kubernetes 支持的最流行的类型是:
|
||||
|
||||
- [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
|
||||
|
||||
_Deployment_ 最适合用于无状态应用程序(即不需要维护工作负载的状态)。由 Deployment 类型工作负载管理的 Pod 是独立且一次性的。如果 pod 中断了,Kubernetes 会删除该 pod 然后重新创建它。一个示例应用程序是 Nginx Web 服务器。
|
||||
|
||||
- [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
|
||||
|
||||
与 Deployment 相比,_StatefulSet_ 最适合在需要维护身份和存储数据的应用程序中使用。适用的应用程序类似于 Zookeeper(一个需要数据库进行存储的应用程序)。
|
||||
|
||||
- [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
_Daemonset_ 确保集群中的每个节点都运行 pod 的副本。如果你需要收集日志或监控节点性能,这种类似 daemon 的工作负载效果是最好的。
|
||||
|
||||
- [Job](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
||||
|
||||
_Job_ 启动一个或多个 Pod 并确保指定数量的 Pod 能成功终止。Job 最好用于运行有限任务至完成状态,而不是管理正在进行的应用程序的所需状态。
|
||||
|
||||
- [CronJob](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/)
|
||||
|
||||
_CronJobs_ 与 Job 类似。但是,CronJob 会基于 cron 的计划运行到完成状态。
|
||||
|
||||
### Services
|
||||
|
||||
在许多用例中,工作负载必须:
|
||||
|
||||
- 由集群中的其他工作负载访问。
|
||||
- 暴露给外部。
|
||||
|
||||
你可以通过创建一个 _Service_ 实现这些目的。Service 使用[选择器/标签(查看代码示例)](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#service-and-replicationcontroller)来映射到底层工作负载的 pod。Rancher UI 使用你选择的服务端口和类型来自动创建 service 以及工作负载,从而简化此映射过程。
|
||||
|
||||
#### Service 类型
|
||||
|
||||
Rancher 中有几种可用的 Service 类型。以下描述来自 [Kubernetes 文档](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types)。
|
||||
|
||||
- **ClusterIP**
|
||||
|
||||
> 在集群内部 IP 上公开 Service。如果你选择此值,Service 只能从集群内访问。这是默认的 `ServiceType`。
|
||||
|
||||
- **NodePort**
|
||||
|
||||
> 在每个节点 IP 上的静态端口(`NodePort`)上暴露 Service。`ClusterIP` service 是自动创建的,而 `NodePort` service 会路由到 ClusterIP service。你可以通过请求 `<NodeIP>:<NodePort>` 在集群外部联系 `NodePort` service。
|
||||
|
||||
- **LoadBalancer**
|
||||
|
||||
> 使用云提供商的负载均衡器向外部公开服务。`NodePort` 和 `ClusterIP` service 是自动创建的,外部负载均衡器会路由到这些 service。
|
||||
|
||||
## 工作负载选项
|
||||
|
||||
以下文档介绍了如何部署工作负载和使用工作负载选项。
|
||||
|
||||
- [部署工作负载](deploy-workloads.md)
|
||||
- [升级工作负载](upgrade-workloads.md)
|
||||
- [回滚工作负载](roll-back-workloads.md)
|
||||
|
||||
## 相关链接
|
||||
|
||||
### 外部链接
|
||||
|
||||
- [Service](https://kubernetes.io/docs/concepts/services-networking/service/)
|
||||
+84
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: 使用 Rancher 启动 Kubernetes
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/launch-kubernetes-with-rancher"/>
|
||||
</head>
|
||||
|
||||
Rancher 可以使用任意节点启动 Kubernetes 集群。在 Rancher 中将 Kubernetes 部署到这些节点上时,你可以选择 [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/) (RKE) 或 [RKE2](https://docs.rke2.io) 发行版。Rancher 可以在任何计算机上启动 Kubernetes,包括:
|
||||
|
||||
- 裸金属服务器
|
||||
- 本地虚拟机
|
||||
- 由云厂商托管的虚拟机
|
||||
|
||||
Rancher 可以在现有节点上安装 Kubernetes,也可以在云厂商中动态配置节点并安装 Kubernetes。
|
||||
|
||||
Rancher 还可以创建节点池。在托管在云厂商的节点池上安装 Kubernetes 的一个好处是,如果一个节点与集群断开连接,Rancher 可以自动创建另一个节点并将其加入集群,从而确保节点池的数量符合要求。
|
||||
|
||||
## RKE
|
||||
|
||||
### 要求
|
||||
|
||||
如果你使用 RKE 建立集群,节点必须满足下游集群的[节点要求](../kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)。
|
||||
|
||||
### 在云厂商的新节点上启动 Kubernetes
|
||||
|
||||
使用 Rancher,你可以基于[节点模板](use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#节点模板)创建节点池。此节点模板定义了要用于在云厂商中启动节点的参数。
|
||||
|
||||
在托管在云厂商的节点池上安装 Kubernetes 的一个好处是,如果一个节点与集群断开连接,Rancher 可以自动创建另一个节点并将其加入集群,从而确保节点池的数量符合要求。
|
||||
|
||||
有关详细信息,请参阅[在新节点上启动 Kubernetes](use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)。
|
||||
|
||||
### 在现有自定义节点上启动 Kubernetes
|
||||
|
||||
在这种情况下,你希望将 Kubernetes 安装到裸机服务器、本地虚拟机或云厂商中已存在的虚拟机上。使用此选项,你将在主机上运行 Rancher Agent Docker 容器。
|
||||
|
||||
如果要重复使用之前的自定义集群中的节点,请在复用之前[清理节点](../manage-clusters/clean-cluster-nodes.md)。如果你重复使用尚未清理的节点,则集群配置可能会失败。
|
||||
|
||||
有关详细信息,请参阅[自定义节点](../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md)。
|
||||
|
||||
### 以编程方式创建 RKE 集群
|
||||
|
||||
通过 Rancher 以编程方式部署 RKE 集群的最常见方法是使用 Rancher 2 Terraform Provider。详情请参见[使用 Terraform 创建集群](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)。
|
||||
|
||||
## RKE2
|
||||
|
||||
Rancher 2.6 支持直接使用 Rancher UI 配置 [RKE2](https://docs.rke2.io/) 集群。RKE2,也称为 RKE Government,是一个完全符合标准的 Kubernetes 发行版,它专注于安全性和合规性。在 Rancher 2.6.4 及更早版本中,RKE2 配置还处于技术预览阶段。
|
||||
|
||||
在 Rancher 2.6.5 中,RKE2 已经 GA。
|
||||
|
||||
### 要求
|
||||
|
||||
如果你使用 RKE2 建立集群,节点必须满足下游集群的[节点要求](https://docs.rke2.io/install/requirements)。
|
||||
|
||||
### 在云厂商的新节点上启动 Kubernetes
|
||||
|
||||
RKE2 基于使用上游[集群 API](https://github.com/kubernetes-sigs/cluster-api) 项目的新配置框架。这个新配置框架支持:
|
||||
|
||||
- 将 RKE2 集群配置到 Rancher 具有主机驱动的任何提供商上
|
||||
- 完全在 Rancher 中配置 RKE2 集群
|
||||
- 除了 Canal 之外,还可以选择 CNI 选项, Calico、Cilium 和 Multus
|
||||
|
||||
RKE2 配置还包括在具有 Windows 节点的集群上安装 RKE2。
|
||||
|
||||
RKE2 的 Windows 功能包括:
|
||||
|
||||
- Windows 支持 vSphere 主机驱动
|
||||
- 用于 Windows RKE2 自定义集群的 Calico CNI
|
||||
- Calico 的项目网络隔离 (PNI)
|
||||
- 由 containerd 提供支持的使用 RKE2 的 Windows 容器
|
||||
- 通过 Terraform 配置 Windows RKE2 集群
|
||||
- 直接从 Rancher UI 配置 Windows RKE2 自定义集群
|
||||
|
||||
要使 Windows 支持 RKE2 自定义集群,请选择 Calico 作为 CNI。
|
||||
|
||||
### 在现有自定义节点上启动 Kubernetes
|
||||
|
||||
RKE2 还支持在预配置的虚拟机或裸机节点上安装自定义集群。
|
||||
|
||||
如果要重复使用之前的自定义集群中的节点,请在复用之前清理节点。如果你重复使用尚未清理的节点,则集群配置可能会失败。
|
||||
|
||||
### 以编程方式创建 RKE2 集群
|
||||
|
||||
通过 Rancher 以编程方式部署 RKE2 集群的最常见方法是使用 Rancher 2 Terraform Provider。详情请参见[使用 Terraform 创建集群](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster_v2)。
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: 创建 Nutanix AOS 集群
|
||||
description: 使用 Rancher 创建 Nutanix AOS (AHV) 集群。集群可能包括具有不同属性的 VM 组,这些属性可用于细粒度控制节点的大小。
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/nutanix"/>
|
||||
</head>
|
||||
|
||||
[Nutanix Acropolis 操作系统](https://www.nutanix.com/products/acropolis) (Nutanix AOS) 是适用于 Nutanix 超融合基础架构平台的操作系统。AOS 带有一个名为 [Acropolis Hypervisor(AHV)](https://www.nutanix.com/products/ahv)的内置虚拟机监控程序。你可以结合使用 Rancher 与 Nutanix AOS (AHV),从而在本地体验云环境的操作。
|
||||
|
||||
Rancher 可以在 AOS (AHV) 中配置节点并在其上安装 Kubernetes。在 AOS 中创建 Kubernetes 集群时,Rancher 首先与 Prism Central API 通信来配置指定数量的虚拟机。然后在虚拟机上安装 Kubernetes。
|
||||
|
||||
Nutanix 集群可能由多组具有不同属性(例如内存或 vCPU 数量)的 VM 组成。这种分组允许对每个 Kubernetes 角色的节点大小进行细粒度控制。
|
||||
|
||||
- [创建 Nutanix 集群](provision-kubernetes-clusters-in-aos.md#creating-a-nutanix-aos-cluster)
|
||||
- [配置存储](provision-kubernetes-clusters-in-aos.md)
|
||||
|
||||
## 创建 Nutanix 集群
|
||||
|
||||
在[本节](provision-kubernetes-clusters-in-aos.md)中,你将学习如何使用 Rancher 在 Nutanix AOS 中安装 [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes 集群。
|
||||
+156
@@ -0,0 +1,156 @@
|
||||
---
|
||||
title: 在云厂商的新节点上启动 Kubernetes
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider"/>
|
||||
</head>
|
||||
|
||||
在 Rancher 中使用节点模板来创建 RKE 或 RKE2 集群时,每个生成的节点池都会显示在新的**主机池**选项卡中。你可以通过执行以下操作来查看主机池:
|
||||
|
||||
1. 点击**☰ > 集群管理**。
|
||||
1. 单击 RKE 或 RKE2 集群的名称。
|
||||
|
||||
## RKE 集群
|
||||
|
||||
使用 Rancher,你可以基于[节点模板](use-new-nodes-in-an-infra-provider.md#节点模板)创建节点池。此节点模板定义了要用于在基础设施提供商或云厂商中启动节点的参数。
|
||||
|
||||
在托管在云厂商的节点池上安装 Kubernetes 的一个好处是,如果一个节点与集群断开连接,Rancher 可以自动创建另一个节点并将其加入集群,从而确保节点池的数量符合要求。
|
||||
|
||||
可用于创建节点模板的云提供商是由[主机驱动](use-new-nodes-in-an-infra-provider.md#主机驱动)决定的。
|
||||
|
||||
### 节点模板
|
||||
|
||||
节点模板保存了用于在特定云提供商中配置节点时要使用的参数。这些节点可以从 UI 启动。Rancher 使用 [Docker Machine](https://docs.docker.com/machine/) 来配置这些节点。可用于创建节点模板的云提供商取决于 Rancher 中状态是 Active 的主机驱动。
|
||||
|
||||
在 Rancher 中创建节点模板后,模板会被保存,以便你可以再次使用该模板来创建节点池。节点模板绑定到你的登录名。添加模板后,你可以将其从用户配置文件中删除。
|
||||
|
||||
#### 节点标签
|
||||
|
||||
你可以为每个节点模板添加[标签](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/),这样,使用节点模板创建的节点都会自动带有这些标签。
|
||||
|
||||
无效标签会阻止升级,或阻止 Rancher 启动。有关标签语法的详细信息,请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。
|
||||
|
||||
#### 节点污点
|
||||
|
||||
你可以为每个节点模板添加[污点](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/),这样,使用节点模板创建的节点都会自动带有这些污点。
|
||||
|
||||
由于污点可以同时添加到节点模板和节点池中,因此如果添加了相同键的污点效果没有冲突,则所有污点都将添加到节点中。如果存在具有相同键但不同效果的污点,则节点池中的污点将覆盖节点模板中的污点。
|
||||
|
||||
#### 节点模板的管理员控制
|
||||
|
||||
管理员可以控制所有节点模板。现在,管理员可以维护 Rancher 中的所有节点模板。当节点模板所有者不再使用 Rancher 时,他们创建的节点模板可以由管理员管理,以便继续更新和维护集群。
|
||||
|
||||
要访问所有节点模板,管理员需要执行以下操作:
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 单击 **RKE1 配置 > 节点模板**。
|
||||
|
||||
**结果**:列出所有节点模板。你可以通过单击 **⋮** 来编辑或克隆模板。
|
||||
|
||||
### 节点池
|
||||
|
||||
使用 Rancher,你可以基于[节点模板](#节点模板)创建节点池。
|
||||
|
||||
节点模板定义了节点的配置,例如要使用的操作系统、CPU 数量和内存量。
|
||||
|
||||
使用节点池的好处是,如果一个节点被销毁或删除,你可以增加 Active 节点的数量来补偿丢失的节点。节点池可以帮助你确保节点池的计数符合要求。
|
||||
|
||||
每个节点池必须分配一个或多个节点角色。
|
||||
|
||||
每个节点角色(即 etcd、controlplane 和 worker)都应分配给不同的节点池。虽然你可以将多个节点角色分配给同一个节点池,但不要在生产集群中执行此操作。
|
||||
|
||||
推荐的设置:
|
||||
|
||||
- 具有 etcd 角色且计数为 3 的节点池
|
||||
- 具有 controlplane 角色且计数至少为 2 的节点池
|
||||
- 具有 worker 角色且计数至少为 2 的节点池
|
||||
|
||||
**离线环境中的 RKE1 下游集群节点**:
|
||||
|
||||
默认情况下,在配置 RKE1 下游集群节点时(例如在 vSphere 中),Rancher 会尝试运行 Docker 安装脚本。但是,Rancher Docker 安装脚本在离线环境中会运行失败。要解决此问题,如果 Docker 已预安装到 VM 镜像上,你可以选择在创建节点模板时跳过安装 Docker。为此,你可以在 Rancher UI **引擎选项**下的 `Docker 安装 URL` 下拉列表中选择 **无**。
|
||||
|
||||
<figcaption>**引擎选项下拉列表**</figcaption>
|
||||
|
||||

|
||||
|
||||
#### 节点池污点
|
||||
|
||||
如果你没有在节点模板上定义[污点](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/),在节点池上添加污点的好处比在节点模板上添加污点更有利,因为您可以在不担心污点是否存在于节点模板上的情况下更换节点模板。
|
||||
|
||||
每个污点都将自动添加到节点池中已创建的节点。因此,如果你在已有节点的节点池中添加污点,污点不会应用到已有的节点,但是添加到该节点池中的新节点都将获得该污点。
|
||||
|
||||
如果污点同时添加到节点模板和节点池中,且添加了相同键的污点效果没有冲突,则所有污点都将添加到节点中。如果存在具有相同键但不同效果的污点,则节点池中的污点将覆盖节点模板中的污点。
|
||||
|
||||
#### 节点自动替换
|
||||
|
||||
Rancher 可以自动替换节点池中无法访问的节点。如果节点在指定的时间中处于 Inactive 状态,Rancher 将使用该节点池的节点模板来重新创建节点。
|
||||
|
||||
:::caution
|
||||
|
||||
自我修复节点池的功能帮助你替换<b>无状态</b>应用的 worker 节点。不建议在 master 节点或连接了持久卷的节点的节点池上启用节点自动替换,因为虚拟机会被临时处理。节点池中的节点与集群断开连接时,其持久卷将被破坏,从而导致有状态应用的数据丢失。
|
||||
|
||||
:::
|
||||
|
||||
节点自动替换基于 Kubernetes 节点控制器工作。节点控制器定期检查所有节点的状态(可通过 `kube-controller` 的 `--node-monitor-period` 标志配置)。一个节点不可访问时,节点控制器将污染该节点。发生这种情况时,Rancher 将开始其删除倒计时。你可以配置 Rancher 等待删除节点的时间。如果在删除倒计时结束前污点没有被删除,Rancher 将继续删除该节点。Rancher 会根据节点池设置的数量来创建新的节点。
|
||||
|
||||
#### 启用节点自动替换
|
||||
|
||||
创建节点池时,你可以指定 Rancher 替换无响应节点的等待时间(以分钟为单位)。
|
||||
|
||||
1. 在创建或编辑集群的表单中,转到**节点池**。
|
||||
1. 转到要启用节点自动替换的节点池。在 **Recreate Unreachable After** 字段中,输入 Rancher 在替换节点之前应该等待节点响应的分钟数。
|
||||
1. 填写表单的其余部分以创建或编辑集群。
|
||||
|
||||
**结果** :已为节点池启用节点自动替换。
|
||||
|
||||
#### 禁用节点自动替换
|
||||
|
||||
你可以执行以下步骤从 Rancher UI 禁用节点自动替换:
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要禁用节点自动替换的集群,然后单击 **⋮ > 编辑配置**。
|
||||
1. 在**节点池**部分中,转到要启用节点自动替换的节点池。在 **Recreate Unreachable After** 字段中,输入 0。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**:已禁用节点池的节点自动替换。
|
||||
|
||||
### 云凭证
|
||||
|
||||
节点模板可以使用云凭证,来存储用于在云提供商中启动节点的凭证,其优点是:
|
||||
|
||||
- 凭证会存储为更安全的 Kubernetes 密文,而且你无需每次都输入凭证便可编辑节点模板。
|
||||
|
||||
- 创建云凭证后,你可以重新使用该凭证来创建其他节点模板。
|
||||
|
||||
- 多个节点模板可以使用相同的云凭证来创建节点池。如果你的密钥被泄露或过期,则可以在一个位置更新云凭证,从而一次更新所有使用该凭证的节点模板。
|
||||
|
||||
创建云凭证后,用户可以[管理创建的云凭证](../../../../reference-guides/user-settings/manage-cloud-credentials.md)。
|
||||
|
||||
### 主机驱动
|
||||
|
||||
如果你找不到想要的主机驱动,你可以在 Rancher 的[内置主机驱动](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#激活停用主机驱动)中查看并激活它,也可以[添加自定义主机驱动](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#添加自定义主机驱动)。
|
||||
|
||||
## RKE2 集群
|
||||
|
||||
Rancher 2.6 支持直接使用 Rancher UI 配置 [RKE2](https://docs.rke2.io/) 集群。RKE2,也称为 RKE Government,是一个完全符合标准的 Kubernetes 发行版,它专注于安全性和合规性。
|
||||
|
||||
:::note
|
||||
|
||||
对于 RKE2 集群模板,请参阅[此页面](../../manage-clusters/manage-cluster-templates.md#rke2-集群模板)了解更多信息。
|
||||
|
||||
:::
|
||||
|
||||
### 节点角色
|
||||
|
||||
RKE2 CLI 公开了 `server` 和 `agent` 两个角色,它们分别代表 Kubernetes 节点角色 `etcd` + `controlplane` 和 `worker`。通过 Rancher 2.6 中的 RKE2 集成,RKE2 节点池可以分配更细粒度的角色,例如 `etcd` 和 `controlplane`。
|
||||
|
||||
你可以在 RKE2 CLI 中使用标志和节点污染,来控制调度工作负载和 Kubernetes master 节点的位置,从而使用 `etcd`,`controlplane` 和 `worker` 节点功能。这些角色没有在 RKE2 CLI 中实现为第一级角色的原因是,RKE2 被概念化为一组原始构建块,使用 Rancher 等编排系统得到最佳利用。
|
||||
|
||||
在 Rancher 中实现这三个节点角色,表示 Rancher 管理的 RKE2 集群能够轻松使用为 RKE 集群推荐的相同架构的所有最佳实践。
|
||||
|
||||
在[推荐的集群架构](../../kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md)中,我们概述了每个角色集群应该有多少节点:
|
||||
|
||||
- 至少拥有三个角色为 etcd 的节点,来确保失去一个节点时仍能存活。
|
||||
- 至少两个节点具有 controlplane 角色,以实现主组件高可用性。
|
||||
- 至少两个具有 worker 角色的节点,用于在节点故障时重新安排工作负载。
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: 创建 vSphere 集群
|
||||
description: 使用 Rancher 创建 vSphere 集群。集群可能包括具有不同属性的 VM 组,这些属性可用于细粒度控制节点的大小。
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere"/>
|
||||
</head>
|
||||
|
||||
import YouTube from '@site/src/components/YouTube'
|
||||
|
||||
你可以结合使用 Rancher 与 vSphere,从而在本地体验云环境的操作。
|
||||
|
||||
Rancher 可以在 vSphere 中配置节点并在其上安装 Kubernetes。在 vSphere 中创建 Kubernetes 集群时,Rancher 首先与 vCenter API 通信来配置指定数量的虚拟机。然后在它们之上安装 Kubernetes。
|
||||
|
||||
vSphere 集群可能由多组具有不同属性(例如内存或 vCPU 数量)的 VM 组成。这种分组允许对每个 Kubernetes 角色的节点大小进行细粒度控制。
|
||||
|
||||
## Rancher v2.3 中的 vSphere 增强功能
|
||||
|
||||
我们更新了 vSphere 节点模板,使你可以通过以下增强功能在本地体验云操作:
|
||||
|
||||
### 自我修复的节点池
|
||||
|
||||
使用 Rancher 配置 vSphere 节点的最大优势之一,是允许你在本地集群中使用 Rancher 的自我修复节点池(也称为[节点自动替换功能](../use-new-nodes-in-an-infra-provider.md#节点自动替换))。自我修复节点池的功能帮助你替换无状态应用的 worker 节点。当 Rancher 使用节点模板配置节点时,Rancher 可以自动替换无法访问的节点。
|
||||
|
||||
:::caution
|
||||
|
||||
不建议在 master 节点或连接了持久卷的节点的节点池上启用节点自动替换,因为虚拟机会被临时处理。节点池中的节点与集群断开连接时,其持久卷将被破坏,从而导致有状态应用的数据丢失。
|
||||
|
||||
:::
|
||||
|
||||
### 实例和调度的动态填充选项
|
||||
|
||||
vSphere 的节点模板已更新。当你使用 vSphere 凭证创建节点模板时,该模板会自动填充你在 vSphere 控制台中可以访问的相同的虚拟机配置选项。
|
||||
|
||||
要填充的字段设置需要满足[先决条件](provision-kubernetes-clusters-in-vsphere.md#vsphere-中的准备工作)。
|
||||
|
||||
### 更多支持的操作系统
|
||||
|
||||
你可以使用任何支持 `cloud-init` 的操作系统来配置 VM。[cloud config](https://cloudinit.readthedocs.io/en/latest/topics/examples.html) 仅支持 YAML 格式。
|
||||
|
||||
### v2.3.3 节点模板功能的视频介绍
|
||||
|
||||
在这段 YouTube 视频中,我们演示了如何使用新的节点模板在本地环境体验云环境一样的操作。
|
||||
|
||||
<YouTube id="dPIwg6x1AlU"/>
|
||||
|
||||
## 创建 vSphere 集群
|
||||
|
||||
在[本节](provision-kubernetes-clusters-in-vsphere.md)中,你将学习如何使用 Rancher 在 vSphere 中安装 [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes 集群。
|
||||
|
||||
## 配置存储
|
||||
|
||||
有关如何使用 Rancher 在 vSphere 中配置存储的示例,请参阅[本节](../../../manage-clusters/provisioning-storage-examples/vsphere-storage.md)。要在 vSphere 中动态配置存储,你必须启用 vSphere 云提供商。请参阅[树内 vSphere 配置](../../../kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-in-tree-vsphere.md)和[树外 vSphere 配置](../../../kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-out-of-tree-vsphere.md)。
|
||||
|
||||
## 启用 vSphere 云提供商
|
||||
|
||||
在 Rancher 中设置云提供商时,Rancher Server 可以自动为集群配置新的基础设施,包括新节点或持久存储设备。
|
||||
|
||||
有关启用 vSphere 云提供商的详细信息,请参阅[树内 vSphere 配置](../../../kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-in-tree-vsphere.md)和[树外 vSphere 配置](../../../kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-out-of-tree-vsphere.md)。
|
||||
Reference in New Issue
Block a user