mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-04 20:23:24 +00:00
Add version-2.7 docs
This commit is contained in:
Billy Tat
+86
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: API 令牌
|
||||
---
|
||||
|
||||
默认情况下，某些集群级别的 API 令牌是使用无限期 TTL（`ttl=0`）生成的。换言之，除非你让令牌失效，否则 `ttl=0` 的 API 令牌永远不会过期。令牌不会因为更改密码而失效。
|
||||
|
||||
要停用 API 令牌，你可以删除令牌或停用用户账号。
|
||||
|
||||
### 删除令牌
|
||||
要删除令牌：
|
||||
|
||||
1. 转到 `https://<Rancher-Server-IP>/v3/tokens`，在 Rancher API 视图中查看包含所有令牌的列表。
|
||||
|
||||
1. 通过 ID 访问要删除的令牌。例如，`https://<Rancher-Server-IP>/v3/tokens/kubectl-shell-user-vqkqt`。
|
||||
|
||||
1. 单击**删除**。
|
||||
|
||||
以下是使用 `ttl=0` 生成的完整令牌列表：
|
||||
|
||||
| 令牌 | 描述 |
|
||||
| ----------------- | -------------------------------------------------------------------------------------- |
|
||||
| `kubeconfig-*` | Kubeconfig 令牌 |
|
||||
| `kubectl-shell-*` | 在浏览器中访问 `kubectl` shell |
|
||||
| `agent-*` | Agent deployment 令牌 |
|
||||
| `compose-token-*` | compose 令牌 |
|
||||
| `helm-token-*` | Helm Chart deployment 令牌 |
|
||||
| `telemetry-*` | 遥测令牌 |
|
||||
| `drain-node-*` | 用于清空的令牌（由于没有原生 Kubernetes API，我们使用 `kubectl` 来清空） |
|
||||
|
||||
|
||||
### 在 Kubeconfig 令牌上设置 TTL
|
||||
|
||||
管理员可以在 Kubeconfig 令牌上设置全局存活时间 (time-to-live，TTL)。如需更改默认 kubeconfig TTL，你可以导航到全局设置并将 [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) 设置为所需的持续时间（单位：分钟）。[`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) 的默认值为 0，表示令牌永不过期。
|
||||
|
||||
:::note
|
||||
|
||||
除了由 CLI 创建的用于[生成 kubeconfig 令牌](#在生成的-kubeconfig-中禁用令牌)的令牌之外，所有 kubeconfig 令牌都使用此设置。
|
||||
|
||||
:::
|
||||
|
||||
### 在生成的 Kubeconfig 中禁用令牌
|
||||
|
||||
1. 将 `kubeconfig-generate-token` 设置为 `false`。此设置让 Rancher 不再在用户单击下载 kubeconfig 文件时自动生成令牌。如果停用此设置，生成的 kubeconfig 将引用 [Rancher CLI](../cli-with-rancher/kubectl-utility.md#使用-kubectl-和-kubeconfig-令牌-进行-ttl-认证) 来检索集群的短期令牌。当这个 kubeconfig 在客户端（例如 `kubectl`）中使用时，你需要安装 Rancher CLI 来完成登录请求。
|
||||
|
||||
2. 将 `kubeconfig-token-ttl-minutes` 设置为所需的时长（单位：分钟）。`kubeconfig-token-ttl-minutes` 默认设置为 960（即 16 小时）。
|
||||
|
||||
### 令牌哈希
|
||||
|
||||
你可以启用令牌哈希，令牌将使用 SHA256 算法进行单向哈希。这是一个不可逆的操作，一旦启用，此功能将无法禁用。在启用功能或在测试环境中评估之前，建议你先进行备份。
|
||||
|
||||
要启用令牌哈希，请参阅[本节](../../pages-for-subheaders/enable-experimental-features.md)。
|
||||
|
||||
此功能将影响所有令牌，包括但不限于以下内容：
|
||||
|
||||
- Kubeconfig 令牌
|
||||
- 持有者令牌 API 密钥/调用
|
||||
- 内部操作使用的令牌
|
||||
|
||||
### 令牌设置
|
||||
以下全局设置会影响 Rancher 令牌的行为：
|
||||
|
||||
| 设置 | 描述 |
|
||||
| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) | 用户认证会话令牌的 TTL（单位：分钟）。 |
|
||||
| [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) | 默认 TTL，应用于所有 kubeconfig 令牌（除了[由 Rancher CLI 生成的令牌](#在生成的-kubeconfig-中禁用令牌)）。**此设置从 2.6.6 版本开始引入。** |
|
||||
| [`kubeconfig-token-ttl-minutes`](#kubeconfig-token-ttl-minutes) | 在 CLI 中生成的令牌 TTL。**自 2.6.6 起已弃用，并将在 2.8.0 中删除**。请知悉，`kubeconfig-default-token-TTL-minutes` 将用于所有 kubeconfig 令牌。 |
|
||||
| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) | 除了由 [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) 控制的令牌外，所有令牌的最大 TTL。 |
|
||||
| [`kubeconfig-generate-token`](#kubeconfig-generate-token) | 如果为 true，则在用户下载 kubeconfig 时自动生成令牌。 |
|
||||
|
||||
#### auth-user-session-ttl-minutes
|
||||
存活时间（TTL）（单位：分钟），用于确定用户身份验证会话令牌的到期时间。过期后，用户将需要登录并获取新令牌。此设置不受 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的影响。会话令牌是在用户登录 Rancher 时创建的。
|
||||
|
||||
#### kubeconfig-default-token-TTL-minutes
|
||||
存活时间（TTL）（单位：分钟），用于确定 kubeconfig 令牌的到期时间。令牌过期后，API 将拒绝令牌。此设置的值不能大于 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的值。此设置适用于在请求的 kubeconfig 文件中生成的令牌，不包括[由 Rancher CLI 生成的](#在生成的-kubeconfig-中禁用令牌)令牌。
|
||||
**此设置从 2.6.6 版本开始引入**。
|
||||
|
||||
#### kubeconfig-token-ttl-minutes
|
||||
存活时间（TTL）（单位：分钟），用于确定由 CLI 生成的 kubeconfig 令牌的到期时间。当 [`kubeconfig-generate-token`](#kubeconfig-generate-token) 设为 false 时，则由 CLI 生成令牌。令牌过期后，API 将拒绝令牌。此设置的值不能大于 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的值。
|
||||
**自版本 2.6.6 起已弃用，并将在 2.8.0 中删除。请知悉，此设置将被 [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) 的值替换**。
|
||||
|
||||
#### auth-token-max-ttl-minutes
|
||||
身份验证令牌的最大生存时间 (TTL)（单位：分钟）。如果用户尝试创建一个 TTL 大于 `auth-token-max-ttl-minutes` 的令牌，Rancher 会将令牌 TTL 设置为 `auth-token-max-ttl-minutes` 的值。身份验证令牌是为验证 API 请求而创建的。
|
||||
**2.6.6 版本更改：适用于所有 kubeconfig 令牌和 API 令牌。**
|
||||
|
||||
#### kubeconfig-generate-token
|
||||
如果设置为 true，则通过 UI 请求的 kubeconfig 将包含一个有效的令牌。如果设置为 false，kubeconfig 将包含一个使用 Rancher CLI 提示用户登录的命令。然后，[CLI 将为用户检索和缓存令牌](../cli-with-rancher/kubectl-utility.md#使用-kubectl-和-kubeconfig-令牌-进行-ttl-认证)。
|
||||
+182
@@ -0,0 +1,182 @@
|
||||
---
|
||||
title: 备份配置
|
||||
---
|
||||
|
||||
你可以在备份创建页面配置调度，启用加密，并指定备份的存储位置。
|
||||
|
||||
|
||||
## 调度
|
||||
|
||||
选择第一个选项来执行一次性备份，或选择第二个选项来安排定期备份。选择**定期备份**后，你可以配置以下两个字段：
|
||||
|
||||
- **调度**：该字段支持
|
||||
- 标准 [cron 表达式](https://en.wikipedia.org/wiki/Cron)，例如 `"0 * * * *"`
|
||||
- 描述符，例如 `"@midnight"` 或 `"@every 1h30m"`
|
||||
- **保留数量**：指定必须保留的备份文件数量。如果文件数量超过 `retentionCount` 设置的值，最旧的文件将被删除。默认值为 10。
|
||||
|
||||
| YAML 指令名称 | 描述 |
|
||||
| ---------------- | ---------------- |
|
||||
| `schedule` | 提供用于调度定期备份的 cron 字符串。 |
|
||||
| `retentionCount` | 提供要保留的备份文件数量。 |
|
||||
|
||||
## 加密
|
||||
|
||||
rancher-backup 通过调用 kube-apiserver 来收集资源。apiserver 返回的对象会被解密，所以即使启用了[静态加密](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)，备份收集的加密对象也会是明文。
|
||||
|
||||
为避免以明文形式存储资源，你可以使用与静态加密相同的 `EncryptionConfiguration` 文件来加密备份中的特定资源。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
rancher-backup Operator 不会保存 `EncryptionConfiguration`，因此在备份中加密对象时，你必须自行保存该文件。
|
||||
|
||||
例如，[将 Rancher 迁移到新集群](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)时，该文件可用于在新集群中重新创建 secret。
|
||||
|
||||
:::
|
||||
|
||||
Operator 将 `EncryptionConfiguration` 用作 `cattle-resources-system` 命名空间中的 Kubernetes Secret，在 Secret 数据中，它位于名为 `encryption-provider-config.yaml` 的 key 下面。
|
||||
|
||||
对于 `EncryptionConfiguration`，你可以使用 [Kubernetes 文档中提供的示例](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#understanding-the-encryption-at-rest-configuration)。
|
||||
|
||||
为确保在 secret 中使用正确的密钥，加密配置文件必须命名为 `encryption-provider-config.yaml`。下面的命令使用 `--from-file` 标志来创建具有正确密钥名称的 Secret。
|
||||
|
||||
将 `EncryptionConfiguration` 保存到名为 `encryption-provider-config.yaml` 的文件中，并运行以下命令：
|
||||
|
||||
```bash
|
||||
kubectl create secret generic encryptionconfig \
|
||||
--from-file=./encryption-provider-config.yaml \
|
||||
-n cattle-resources-system
|
||||
```
|
||||
|
||||
这将确保密文包含一个名为 `encryption-provider-config.yaml` 的 key，而且 operator 会使用该 key 来获取加密配置。
|
||||
|
||||
`Encryption Config Secret` 下拉菜单将过滤并仅列出拥有这个 key 的密文。
|
||||
|
||||
|
||||
|
||||
在上面的示例命令中，`encryptionconfig` 这个名称可以任意修改。
|
||||
|
||||
|
||||
| YAML 指令名称 | 描述 |
|
||||
| ---------------- | ---------------- |
|
||||
| `encryptionConfigSecretName` | 提供 `cattle-resources-system` 命名空间中包含加密配置文件的密文的名称。 |
|
||||
|
||||
## 存储位置
|
||||
|
||||
如果在备份中指定了 `StorageLocation`，operator 将从该特定的 S3 存储桶中检索备份位置。如果没有指定，operator 将尝试在默认 operator 级别的 S3 存储和 operator 级别的 PVC 存储中查找这个文件。默认存储位置是在部署 `rancher-backup` operator 时配置的。
|
||||
|
||||
如果你选择第一个选项，备份将存储在安装 rancher-backup Chart 时配置的存储位置中。如果你选择第二个选项，你可以配置不同的兼容 S3 的对象存储作为备份存储位置。
|
||||
|
||||
### S3
|
||||
|
||||
S3 存储位置包含以下配置字段：
|
||||
|
||||
1. **凭证密文**（可选）：如果你需要使用 AWS 访问密钥（access key）和密文密钥（secret key）来访问 S3 存储桶，请使用带有密钥和指令 `accessKey` 和 `secretKey` 的凭证来创建密文。它可以是任意一个命名空间。你可以点击[此处](#credentialsecret-示例)查看示例密文。如果运行 operator 的节点在 EC2 中，并且设置了允许它们访问 S3 的 IAM 权限，则此指令是不必要的（如[本节](#ec2-节点访问-s3-的-iam-权限)所述）。凭证密文下拉菜单列出了所有命名空间的密文。
|
||||
1. **存储桶名称**：存储备份文件的 S3 存储桶的名称。
|
||||
1. **区域**（可选）：S3 存储桶所在的 AWS [区域](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)。配置 MinIO 时不需要该字段。
|
||||
1. **文件夹**（可选）：S3 存储桶中存储备份文件的文件夹名称。不支持嵌套文件夹（例如， `rancher/cluster1`）。如果此字段留空，则默认将备份文件存储在 S3 存储桶的根文件夹中。
|
||||
1. **端点**：用于访问存储桶区域中的 S3 的[端点](https://docs.aws.amazon.com/general/latest/gr/s3.html)。
|
||||
1. **端点 CA**（可选）：Base64 编码的 CA 证书。如需获取示例，请参见 [S3 兼容配置示例](#s3-存储配置示例)。
|
||||
1. **跳过 TLS 验证**（可选）：如果你不使用 TLS，则设置为 `true`。
|
||||
|
||||
|
||||
| YAML 指令名称 | 描述 | 必填 |
|
||||
| ---------------- | ---------------- | ------------ |
|
||||
| `credentialSecretName` | 如果你需要使用 AWS 访问密钥（access key）和密文密钥（secret key）来访问 S3 存储桶，请使用带有密钥和指令 `accessKey` 和 `secretKey` 的凭证来创建密文。它可以在任何命名空间中，只要你在 `credentialSecretNamespace` 中提供该命名空间。点击[这里](#credentialsecret-示例)查看示例密文。如果运行 operator 的节点在 EC2 中，并且设置了允许它们访问 S3 的 IAM 权限，则此指令是不必要的（如[本节](#ec2-节点访问-s3-的-iam-权限)所述）。 | |
|
||||
| `credentialSecretNamespace` | 包含访问 S3 的凭证的密文的命名空间。如果运行 operator 的节点在 EC2 中，并且设置了允许它们访问 S3 的 IAM 权限，则此指令是不必要的（如[本节](#ec2-节点访问-s3-的-iam-权限)所述）。 | |
|
||||
| `bucketName` | 存储备份文件的 S3 存储桶的名称。 | ✓ |
|
||||
| `folder` | S3 存储桶中存储备份文件的文件夹名称。不支持嵌套文件夹（例如， `rancher/cluster1`）。如果此字段留空，则默认将备份文件存储在 S3 存储桶的根文件夹中。 | |
|
||||
| `region` | S3 存储桶所在的 AWS [区域](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)。 | ✓ |
|
||||
| `endpoint` | 用于访问存储桶区域中的 S3 的[端点](https://docs.aws.amazon.com/general/latest/gr/s3.html)。 | ✓ |
|
||||
| `endpointCA` | Base64 编码的 CA 证书。如需获取示例，请参见 [S3 兼容配置示例](#s3-存储配置示例)。 | |
|
||||
| `insecureTLSSkipVerify` | 如果你不使用 TLS，则设置为 `true`。 | |
|
||||
|
||||
### S3 存储配置示例
|
||||
|
||||
```yaml
|
||||
s3:
|
||||
credentialSecretName: s3-creds
|
||||
credentialSecretNamespace: default
|
||||
bucketName: rancher-backups
|
||||
folder: rancher
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
```
|
||||
|
||||
### MinIO 配置示例
|
||||
|
||||
```yaml
|
||||
s3:
|
||||
credentialSecretName: minio-creds
|
||||
bucketName: rancherbackups
|
||||
endpoint: minio.35.202.130.254.xip.io
|
||||
endpointCA: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURHakNDQWdLZ0F3SUJBZ0lKQUtpWFZpNEpBb0J5TUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIzUmxjM1F0WTJFd0hoY05NakF3T0RNd01UZ3lOVFE1V2hjTk1qQXhNREk1TVRneU5UUTVXakFTTVJBdwpEZ1lEVlFRRERBZDBaWE4wTFdOaE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBCjA4dnV3Q2Y0SEhtR2Q2azVNTmozRW5NOG00T2RpS3czSGszd1NlOUlXQkwyVzY5WDZxenBhN2I2M3U2L05mMnkKSnZWNDVqeXplRFB6bFJycjlpbEpWaVZ1NFNqWlFjdG9jWmFCaVNsL0xDbEFDdkFaUlYvKzN0TFVTZSs1ZDY0QQpWcUhDQlZObU5xM3E3aVY0TE1aSVpRc3N6K0FxaU1Sd0pOMVVKQTZ6V0tUc2Yzc3ByQ0J2dWxJWmZsVXVETVAyCnRCTCt6cXZEc0pDdWlhNEEvU2JNT29tVmM2WnNtTGkwMjdub3dGRld3MnRpSkM5d0xMRE14NnJoVHQ4a3VvVHYKQXJpUjB4WktiRU45L1Uzb011eUVKbHZyck9YS2ZuUDUwbk8ycGNaQnZCb3pUTStYZnRvQ1d5UnhKUmI5cFNTRApKQjlmUEFtLzNZcFpMMGRKY2sxR1h3SURBUUFCbzNNd2NUQWRCZ05WSFE0RUZnUVU5NHU4WXlMdmE2MTJnT1pyCm44QnlFQ2NucVFjd1FnWURWUjBqQkRzd09ZQVU5NHU4WXlMdmE2MTJnT1pybjhCeUVDY25xUWVoRnFRVU1CSXgKRURBT0JnTlZCQU1NQjNSbGMzUXRZMkdDQ1FDb2wxWXVDUUtBY2pBTUJnTlZIUk1FQlRBREFRSC9NQTBHQ1NxRwpTSWIzRFFFQkN3VUFBNElCQVFER1JRZ1RtdzdVNXRQRHA5Q2psOXlLRW9Vd2pYWWM2UlAwdm1GSHpubXJ3dUVLCjFrTkVJNzhBTUw1MEpuS29CY0ljVDNEeGQ3TGdIbTNCRE5mVVh2anArNnZqaXhJYXR2UWhsSFNVaWIyZjJsSTkKVEMxNzVyNCtROFkzelc1RlFXSDdLK08vY3pJTGh5ei93aHRDUlFkQ29lS1dXZkFiby8wd0VSejZzNkhkVFJzNwpHcWlGNWZtWGp6S0lOcTBjMHRyZ0xtalNKd1hwSnU0ZnNGOEcyZUh4b2pOKzdJQ1FuSkg5cGRIRVpUQUtOL2ppCnIvem04RlZtd1kvdTBndEZneWVQY1ZWbXBqRm03Y0ZOSkc4Y2ZYd0QzcEFwVjhVOGNocTZGeFBHTkVvWFZnclMKY1VRMklaU0RJd1FFY3FvSzFKSGdCUWw2RXBaUVpWMW1DRklrdFBwSQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0t
|
||||
```
|
||||
### credentialSecret 示例
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: creds
|
||||
type: Opaque
|
||||
data:
|
||||
accessKey: <base64-encoded access key>
|
||||
secretKey: <base64-encoded secret key>
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
为避免编码问题，你可以使用以下命令创建 `credentialSecret`，更新 `accessKey` 和 `secretKey` 的值。
|
||||
|
||||
```bash
|
||||
kubectl create secret generic s3-creds \
|
||||
--from-literal=accessKey=<access key> \
|
||||
--from-literal=secretKey=<secret key>
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### EC2 节点访问 S3 的 IAM 权限
|
||||
|
||||
有两种方法可以设置 `rancher-backup` operator 来使用 S3 作为备份存储位置。
|
||||
|
||||
一种方法是在 Backup 自定义资源中配置 `credentialSecretName`（即可以访问 S3 的 AWS 凭证）。
|
||||
|
||||
如果集群节点在 Amazon EC2 中，你也可以给 EC2 节点分配 IAM 权限，使其可以访问 S3。
|
||||
|
||||
要允许节点访问 S3，请按照 [AWS 文档](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-access-s3-bucket/)中的说明，为 EC2 创建一个 IAM 角色。在向角色添加自定义策略时，添加以下权限，并将 `Resource` 替换为你的存储桶名称：
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"s3:ListBucket"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:s3:::rancher-backups"
|
||||
]
|
||||
},
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"s3:PutObject",
|
||||
"s3:GetObject",
|
||||
"s3:DeleteObject",
|
||||
"s3:PutObjectAcl"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:s3:::rancher-backups/*"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
在创建角色并将相应的实例配置文件附加 EC2 实例后，Backup 自定义资源中的 `credentialSecretName` 指令可以留空。
|
||||
|
||||
## 示例
|
||||
|
||||
如需获取 Backup 自定义资源的示例，请参见[本页](examples.md#备份)。
|
||||
+293
@@ -0,0 +1,293 @@
|
||||
---
|
||||
title: 示例
|
||||
---
|
||||
|
||||
本节包含 Backup 和 Restore 自定义资源的示例。
|
||||
|
||||
默认的备份存储位置是在安装或升级 `rancher-backup` operator 时配置的。
|
||||
|
||||
只有 Restore 自定义资源使用创建备份时使用的加密配置密文时，才能还原加密的备份。
|
||||
|
||||
## 备份
|
||||
|
||||
本节包含 Backup 自定义资源的示例。
|
||||
|
||||
> **注意**：有关配置以下选项的更多信息，请参阅[备份配置参考页面](./backup-configuration.md)。
|
||||
|
||||
### 在默认位置进行加密备份
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Backup
|
||||
metadata:
|
||||
name: default-location-encrypted-backup
|
||||
spec:
|
||||
resourceSetName: rancher-resource-set
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
### 在默认位置进行定期备份
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Backup
|
||||
metadata:
|
||||
name: default-location-recurring-backup
|
||||
spec:
|
||||
resourceSetName: rancher-resource-set
|
||||
schedule: "@every 1h"
|
||||
retentionCount: 10
|
||||
```
|
||||
|
||||
### 在默认位置进行加密的定期备份
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Backup
|
||||
metadata:
|
||||
name: default-enc-recurring-backup
|
||||
spec:
|
||||
resourceSetName: rancher-resource-set
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
schedule: "@every 1h"
|
||||
retentionCount: 3
|
||||
```
|
||||
|
||||
### Minio 中的加密备份
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Backup
|
||||
metadata:
|
||||
name: minio-backup
|
||||
spec:
|
||||
storageLocation:
|
||||
s3:
|
||||
credentialSecretName: minio-creds
|
||||
credentialSecretNamespace: default
|
||||
bucketName: rancherbackups
|
||||
endpoint: minio.xip.io
|
||||
endpointCA: <base64-encoded-cert>
|
||||
resourceSetName: rancher-resource-set
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
### 使用 AWS 凭证密文在 S3 中备份
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Backup
|
||||
metadata:
|
||||
name: s3-backup
|
||||
spec:
|
||||
storageLocation:
|
||||
s3:
|
||||
credentialSecretName: s3-creds
|
||||
credentialSecretNamespace: default
|
||||
bucketName: rancher-backups
|
||||
folder: ecm1
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
resourceSetName: rancher-resource-set
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
### 使用 AWS 凭证密文在 S3 中进行定期备份
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Backup
|
||||
metadata:
|
||||
name: s3-recurring-backup
|
||||
spec:
|
||||
storageLocation:
|
||||
s3:
|
||||
credentialSecretName: s3-creds
|
||||
credentialSecretNamespace: default
|
||||
bucketName: rancher-backups
|
||||
folder: ecm1
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
resourceSetName: rancher-resource-set
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
schedule: "@every 1h"
|
||||
retentionCount: 10
|
||||
```
|
||||
|
||||
### 从具有访问 S3 的 IAM 权限的 EC2 节点进行备份
|
||||
|
||||
这个例子表明，如果运行 `rancher-backup` 的节点拥有这些[访问 S3 的权限](backup-configuration.md#ec2-节点访问-s3-的-iam-权限)，就不必提供 AWS 的凭证密文来创建备份。
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Backup
|
||||
metadata:
|
||||
name: s3-iam-backup
|
||||
spec:
|
||||
storageLocation:
|
||||
s3:
|
||||
bucketName: rancher-backups
|
||||
folder: ecm1
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
resourceSetName: rancher-resource-set
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
## 还原
|
||||
|
||||
本节包含 Restore 自定义资源的示例。
|
||||
|
||||
> **注意**：有关配置以下选项的更多信息，请参阅[恢复配置参考页面](./restore-configuration.md)。
|
||||
|
||||
### 使用默认备份文件位置还原
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Restore
|
||||
metadata:
|
||||
name: restore-default
|
||||
spec:
|
||||
backupFilename: default-location-recurring-backup-752ecd87-d958-4d20-8350-072f8d090045-2020-09-26T12-29-54-07-00.tar.gz
|
||||
# encryptionConfigSecretName: test-encryptionconfig
|
||||
```
|
||||
|
||||
### 为 Rancher 迁移进行还原
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Restore
|
||||
metadata:
|
||||
name: restore-migration
|
||||
spec:
|
||||
backupFilename: backup-b0450532-cee1-4aa1-a881-f5f48a007b1c-2020-09-15T07-27-09Z.tar.gz
|
||||
prune: false
|
||||
storageLocation:
|
||||
s3:
|
||||
credentialSecretName: s3-creds
|
||||
credentialSecretNamespace: default
|
||||
bucketName: rancher-backups
|
||||
folder: ecm1
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
```
|
||||
|
||||
### 使用加密的备份还原
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Restore
|
||||
metadata:
|
||||
name: restore-encrypted
|
||||
spec:
|
||||
backupFilename: default-test-s3-def-backup-c583d8f2-6daf-4648-8ead-ed826c591471-2020-08-24T20-47-05Z.tar.gz
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
### 从 Minio 还原加密的备份
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Restore
|
||||
metadata:
|
||||
name: restore-minio
|
||||
spec:
|
||||
backupFilename: default-minio-backup-demo-aa5c04b7-4dba-4c48-9ac4-ab7916812eaa-2020-08-30T13-18-17-07-00.tar.gz
|
||||
storageLocation:
|
||||
s3:
|
||||
credentialSecretName: minio-creds
|
||||
credentialSecretNamespace: default
|
||||
bucketName: rancherbackups
|
||||
endpoint: minio.xip.io
|
||||
endpointCA: <base64-encoded-cert>
|
||||
encryptionConfigSecretName: test-encryptionconfig
|
||||
```
|
||||
|
||||
### 使用 AWS 凭证密文访问 S3 从备份中还原
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Restore
|
||||
metadata:
|
||||
name: restore-s3-demo
|
||||
spec:
|
||||
backupFilename: test-s3-recurring-backup-752ecd87-d958-4d20-8350-072f8d090045-2020-09-26T12-49-34-07-00.tar.gz.enc
|
||||
storageLocation:
|
||||
s3:
|
||||
credentialSecretName: s3-creds
|
||||
credentialSecretNamespace: default
|
||||
bucketName: rancher-backups
|
||||
folder: ecm1
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
encryptionConfigSecretName: test-encryptionconfig
|
||||
```
|
||||
|
||||
### 从具有访问 S3 的 IAM 权限的 EC2 节点进行还原
|
||||
|
||||
这个例子表明，如果运行 `rancher-backup` 的节点拥有这些[访问 S3 的权限](backup-configuration.md#ec2-节点访问-s3-的-iam-权限)，就不必提供 AWS 的凭证密文来从备份中还原。
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Restore
|
||||
metadata:
|
||||
name: restore-s3-demo
|
||||
spec:
|
||||
backupFilename: default-test-s3-recurring-backup-84bf8dd8-0ef3-4240-8ad1-fc7ec308e216-2020-08-24T10#52#44-07#00.tar.gz
|
||||
storageLocation:
|
||||
s3:
|
||||
bucketName: rajashree-backup-test
|
||||
folder: ecm1
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
encryptionConfigSecretName: test-encryptionconfig
|
||||
```
|
||||
|
||||
## 在 S3 中存储备份的凭证密文示例
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: creds
|
||||
type: Opaque
|
||||
data:
|
||||
accessKey: <Enter your base64-encoded access key>
|
||||
secretKey: <Enter your base64-encoded secret key>
|
||||
```
|
||||
|
||||
## EncryptionConfiguration 示例
|
||||
|
||||
以下代码片段演示了两种不同类型的密文及其与自定义资源的备份和还原的相关性。
|
||||
|
||||
第一个示例是用于加密备份文件的密钥。在这种情况下，Backup operator 将无法读取密文加密文件。它只使用密文的内容。
|
||||
|
||||
第二个示例是 Kubernetes 密文加密配置文件，用于加密存储在 etcd 中的密文。**备份 etcd 数据存储时，请务必同时备份 EncryptionConfiguration**。如果你没有这样做，而且备份数据时正在使用密文加密，你将无法使用恢复的数据。
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
providers:
|
||||
- aesgcm:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZQ==
|
||||
- name: key2
|
||||
secret: dGhpcyBpcyBwYXNzd29yZA==
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZQ==
|
||||
- name: key2
|
||||
secret: dGhpcyBpcyBwYXNzd29yZA==
|
||||
- secretbox:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
|
||||
```
|
||||
|
||||
|
||||
|
||||
+81
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: 还原配置
|
||||
---
|
||||
|
||||
你可以在还原创建页面提供还原备份的详细信息。
|
||||
|
||||
|
||||
|
||||
|
||||
## 备份源
|
||||
你需要提供备份文件和备份文件存储位置的详细信息，operator 会使用这些信息执行还原。选择以下其中一个选项来提供这些详细信息。
|
||||
|
||||
|
||||
|
||||
|
||||
### 使用已有的备份配置恢复
|
||||
|
||||
如果你选择这个选项，**目标备份**下拉菜单中会出现集群中可用的备份。从下拉菜单中选择 Backup，选择后**备份文件名**字段会自动填写，而且所选 Backup 的信息会传递给 operator
|
||||
|
||||
|
||||
|
||||
如果 Backup 自定义资源在集群中不存在，你需要获取准确的文件名，并使用默认存储目标或与 S3 兼容的对象存储来提供备份源的详细信息。
|
||||
|
||||
|
||||
### 使用默认存储目标恢复
|
||||
|
||||
如果你要从 operator 级别配置的默认存储位置中的备份文件进行恢复，请选择此选项。operator 级别的配置是指安装或升级 `rancher-backup` operator 时配置的存储位置。在**备份文件名**字段中提供准确的文件名。
|
||||
|
||||
|
||||
|
||||
### 使用与 S3 兼容的对象存储恢复
|
||||
|
||||
如果在 operator 级别没有配置默认存储位置，或者备份文件所在的存储桶与配置的默认存储位置不一样时，请选择此选项。在**备份文件名**字段中提供准确的文件名。请参见[本节](#从-s3-获取备份文件名)了解从 S3 获取备份文件名的具体步骤。填写 S3 兼容对象存储的所有详细信息。它的字段与 [Backup 自定义资源](backup-configuration.md#存储位置)中 `backup.StorageLocation` 配置的字段一样。
|
||||
|
||||
|
||||
|
||||
## 加密
|
||||
|
||||
如果备份是在启用加密的情况下创建的，备份文件的后缀为 `.enc`。如果你选择这类的 Backup，或者提供后缀为 `.enc` 的备份文件名，则会显示另一个名为 **Encryption Config Secret** 的下拉菜单。
|
||||
|
||||
|
||||
|
||||
从该下拉菜单中选择的密文必须与执行备份时用于 Backup 自定义资源的密文内容相同。如果加密配置不匹配，还原将会失败。
|
||||
|
||||
`Encryption Config Secret` 下拉菜单将过滤并仅列出拥有这个 key 的密文。
|
||||
|
||||
| YAML 指令名称 | 描述 |
|
||||
| ---------------- | ---------------- |
|
||||
| `encryptionConfigSecretName` | 提供 `cattle-resources-system` 命名空间中包含加密配置文件的密文的名称。 |
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
此字段仅在备份创建的过程中启用了加密功能时才需要设置。提供错误的加密配置将导致还原失败。
|
||||
|
||||
:::
|
||||
|
||||
## 还原过程中修剪
|
||||
|
||||
* **Prune**：为了从备份中完全恢复 Rancher，并回到备份时的确切状态，我们需要删除 Rancher 在备份后创建的所有额外资源。如果 **Prune** 标志被启用，operator 就会删除这些资源。Prune 是默认启用的，建议保持启用状态。
|
||||
* **删除超时**：在删除资源的时候，operator 编辑资源以删除 Finalizers，并试图再次删除前将等待的时间。
|
||||
|
||||
| YAML 指令名称 | 描述 |
|
||||
| ---------------- | ---------------- |
|
||||
| `prune` | 删除备份中不存在的由 Rancher 管理的资源（推荐）。 |
|
||||
| `deleteTimeoutSeconds` | 在删除资源的时候，operator 编辑资源以删除 Finalizers，并试图再次删除前将等待的时间。 |
|
||||
|
||||
## 从 S3 获取备份文件名
|
||||
|
||||
这是 `rancher-backup` operator 用来执行还原的备份文件的名称。
|
||||
|
||||
要从 S3 获取这个文件名，请进入你的 S3 存储桶（或在执行备份时指定的文件夹）。
|
||||
|
||||
复制文件名并将其存储在你的 Restore 自定义资源中。假设你的备份文件的名字是 `backupfile`：
|
||||
|
||||
- 如果你的存储桶名称是 `s3bucket`，而且你没有指定文件夹，那么要使用的 `backupFilename` 会是 `backupfile`。
|
||||
- 如果你的存储桶名称是 `s3bucket`，而且基础文件夹是 `s3folder`，那么要使用的 `backupFilename` 会是 `backupfile`。
|
||||
- 如果 `s3Folder` 中有一个名为 `s3sub` 的子文件夹，而且你的备份文件存放在该文件夹中，那么要使用的`backupFilename` 会是 `s3sub/backupfile`。
|
||||
|
||||
| YAML 指令名称 | 描述 |
|
||||
| ---------------- | ---------------- |
|
||||
| `backupFilename` | 这是 `rancher-backup` operator 用来执行还原的备份文件的名称。 |
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: 备份存储位置配置
|
||||
---
|
||||
|
||||
配置一个用于保存所有备份的默认存储位置。你可以选择对每个备份进行覆盖，但仅限于使用 S3 对象存储。
|
||||
|
||||
在 operator 级别只能配置一个存储位置。
|
||||
|
||||
|
||||
## 存储位置配置
|
||||
|
||||
### 无默认存储位置
|
||||
|
||||
你可以选择不配置 operator 级别的存储位置。如果选择此选项，你必须配置一个与 S3 兼容的对象存储作为每个备份的存储位置。
|
||||
|
||||
### S3 兼容的对象存储
|
||||
|
||||
| 参数 | 描述 |
|
||||
| -------------- | -------------- |
|
||||
| 凭证密文 | 从 Rancher 的密文中选择 S3 的凭证。[示例](examples.md#在-s3-中存储备份的凭证密文示例)。 |
|
||||
| 存储桶名称 | 存储备份的 [S3 存储桶](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html)的名称。默认值：`rancherbackups`。 |
|
||||
| 区域 | S3 存储桶所在的 [AWS 区域](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)。 |
|
||||
| 文件夹 | 存储备份的 [S3 存储桶中的文件夹](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/using-folders.html)。如果此字段留空，则默认将备份文件存储在 S3 存储桶的根文件夹中。 |
|
||||
| 端点 | [S3 端点](https://docs.aws.amazon.com/general/latest/gr/s3.html)，例如 `s3.us-west-2.amazonaws.com`。 |
|
||||
| Endpoint CA | 用于 S3 端点的 CA 证书。默认值：base64 编码的 CA 证书。 |
|
||||
| insecureTLSSkipVerify | 如果你不使用 TLS，则设置为 `true`。 |
|
||||
|
||||
### 使用现有的 StorageClass
|
||||
|
||||
如果你通过选择 StorageClass 选项来安装 `rancher-backup` Chart，将会创建一个持久卷说明（Persistent Volume Claim，PVC），而且 Kubernetes 会动态配置一个持久卷（Persistent Volume，PV），所有备份都会默认保存到该持久卷中。
|
||||
|
||||
关于创建存储类的信息，请参见[本章节](../../how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/dynamically-provision-new-storage.md)。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
强烈建议使用回收策略为 "Retain" 的 StorageClass。否则，如果 `rancher-backup` Chart 创建的 PVC 在应用升级期间或意外被删除后，PV 也会被删除，也就是说所有保存在其中的备份都会被删除。
|
||||
如果没有这样的 StorageClass 可用，在配置 PV 后，请确保先将其回收策略设置为 "Retain"，然后再存储备份。
|
||||
|
||||
:::
|
||||
|
||||
### 使用现有的持久卷
|
||||
|
||||
选择一个用于存储备份的现有持久卷。有关在 Rancher 中创建 PersistentVolumes 的更多信息，请参见[本节](../../how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/set-up-existing-storage.md#2-添加一个引用持久存储的-persistentvolume)。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
强烈建议使用回收策略为 "Retain" 的 Persistent Volume。否则，如果 `rancher-backup` Chart 创建的 PVC 在应用升级期间或意外被删除后，PV 也会被删除，也就是说所有保存在其中的备份都会被删除。
|
||||
|
||||
:::
|
||||
|
||||
## rancher-backup Helm Chart 的示例 values.yaml
|
||||
|
||||
使用 Helm CLI 时，可用于配置 `rancher-backup` operator 的 `values.yaml` 可以在 [backup-restore-operator](https://github.com/rancher/backup-restore-operator/blob/master/charts/rancher-backup/values.yaml) 仓库中找到。
|
||||
|
||||
有关 `values.yaml` 文件和在安装时配置 Helm Charts 的更多信息，请参见 [Helm 文档](https://helm.sh/docs/intro/using_helm/#customizing-the-chart-before-installing)。
|
||||
|
||||
+88
@@ -0,0 +1,88 @@
|
||||
---
|
||||
title: Logging 最佳实践
|
||||
---
|
||||
|
||||
本指南介绍了集群级别日志和应用日志的最佳实践。
|
||||
|
||||
- [集群级别日志](#集群级别日志)
|
||||
- [应用日志](#应用日志)
|
||||
- [通用最佳实践](#通用最佳实践)
|
||||
|
||||
在 Rancher 2.5 之前，Rancher 的 Logging 是一个静态集成。可供选择的聚合器是固定的（包括 ElasticSearch、Splunk、Kafka、Fluentd 和 Syslog），而且只有两个配置级别可供选择（集群级别和项目级别）。
|
||||
|
||||
现在，Rancher 的日志聚合更加灵活。通过新的 Logging 的功能，管理员和用户都可以部署符合细粒度收集标准的日志记录，同时提供更多的目标和配置选项。
|
||||
|
||||
Rancher Logging 使用的是 [Logging Operator](https://github.com/kube-logging/logging-operator)。我们让你可以管理这个 operator 及其资源，并将它的管理功能和 Rancher 集群管理联系起来。
|
||||
|
||||
## 集群级别日志
|
||||
|
||||
### 抓取集群内日志
|
||||
|
||||
某些用户可能想从集群中运行的每个容器中抓取日志。但是你的安全团队可能要求你从所有执行点收集所有日志。
|
||||
|
||||
在这种情况下，我们建议你至少创建两个 _ClusterOutput_ 对象 - 一个用于安全团队（如果需要），另一个用于你自己，即集群管理员。创建这些对象时，请选择一个可以处理整个集群的大量日志的输出端点。此外，你还需要选择合适的索引来接收这些日志。
|
||||
|
||||
创建这些 _ClusterOutput_ 对象后，创建一个 _ClusterFlow_ 来收集所有日志。不要在此 flow 上定义任何 _Include_ 或 _Exclude_ 规则。这可以确保你能收集整个集群的所有日志。如果你有两个 _ClusterOutputs_，请确保它们都能收到日志。
|
||||
|
||||
### Kubernetes 组件
|
||||
|
||||
_ClusterFlows_ 能够收集 Kubernetes 集群中所有主机上所有容器的日志。如果这些容器包含在 Kubernetes Pod 中，这个方法是适用的。但是，RKE 容器不存在于 Kubernetes 内。
|
||||
|
||||
目前，Rancher 能搜集 RKE 容器的日志，但不能轻易过滤。这是因为这些日志不包含源容器的信息（例如 `etcd` 或 `kube-apiserver`）。
|
||||
|
||||
Rancher 的未来版本将包含源容器名称，来支持过滤这些组件的日志。该功能实现之后，你将能够自定义 _ClusterFlow_ 来**仅**检索 Kubernetes 组件日志，并将日志发送到适当的输出位置。
|
||||
|
||||
## 应用日志
|
||||
|
||||
对于 Kubernetes 和所有基于容器的应用而言，最佳实践是将应用日志引导到 `stdout`/`stderr`。容器运行时将捕获这些日志并用它们进行**某些操作** - 通常是将它们写入文件。根据容器运行时（及其配置），这些日志可以放置在任意数量的位置。
|
||||
|
||||
在将日志写入文件的情况下，Kubernetes 通过在每个主机上创建一个 `/var/log/containers` 目录来提供帮助。这个目录将日志文件符号链接到它们的实际目的地（可能因为配置或容器运行时而有所不同）。
|
||||
|
||||
Rancher 的 Logging 将读取 `/var/log/containers` 中的所有日志条目，确保所有容器的所有日志条目（假设使用默认配置）均能被收集和处理。
|
||||
|
||||
### 特定日志文件
|
||||
|
||||
日志收集仅从 Kubernetes 中的 Pod 中检索 `stdout`/`stderr` 日志。但是，我们也可能想从应用生成的其他文件中收集日志。在这种情况下，你可以使用一个（或两个）日志流 Sidecar。
|
||||
|
||||
设置日志流 Sidecar 的目的是获取写入磁盘的日志文件，并将其内容传输到 `stdout`。这样一来，Logging Operator 就可以接收这些日志，并把日志发送到目标输出位置。
|
||||
|
||||
要进行设置，编辑你的工作负载资源（例如 Deployment）并添加以下 Sidecar 定义：
|
||||
|
||||
```yaml
|
||||
...
|
||||
containers:
|
||||
- args:
|
||||
- -F
|
||||
- /path/to/your/log/file.log
|
||||
command:
|
||||
- tail
|
||||
image: busybox
|
||||
name: stream-log-file-[name]
|
||||
volumeMounts:
|
||||
- mountPath: /path/to/your/log
|
||||
name: mounted-log
|
||||
...
|
||||
```
|
||||
|
||||
这将添加一个容器到你的工作负载定义中，用于将 `/path/to/your/log/file.log` 的内容（在本示例中）传输到 `stdout`。
|
||||
|
||||
然后将根据你设置的 _Flows_ 或 _ClusterFlows_ 自动收集该日志流。你还可以通过使用容器的名称，专门为该日志文件创建一个 _Flow_。示例如下：
|
||||
|
||||
```yaml
|
||||
...
|
||||
spec:
|
||||
match:
|
||||
- select:
|
||||
container_names:
|
||||
- stream-log-file-name
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
## 通用最佳实践
|
||||
|
||||
- 尽量输出结构化日志条目（例如 `syslog`、JSON）。这些格式已经有了解析器，因此你可以更轻松地处理日志条目。
|
||||
- 尽量在日志条目内提供创建该日志条目的应用的名称。这可以使故障排除更容易。这是因为 Kubernetes 并不总是将应用的名称作为对象名称。例如，某个 Pod ID 可能是 `myapp-098kjhsdf098sdf98`，从这个 ID 中我们不能获取运行在容器内的应用的太多信息。
|
||||
- 除了在集群范围内收集所有日志的情况外，尽量严格限定 _Flow_ 和 _ClusterFlow_ 对象的范围。这使得在出现问题时更容易进行故障排除，并且还有助于确保不相关的日志条目不会出现在你的聚合器中。严格限定范围的一个例子是将 _Flow_ 限制在命名空间中的单个 _Deployment_，甚至是 _Pod_ 中的单个容器。
|
||||
- 除非要进行故障排除，否则不要让日志太详细。太详细的日志会带来许多问题，其中最主要的是**带来干扰**，即重要事件可能会淹没在海量 `DEBUG` 信息中。你可以通过使用自动告警和脚本来缓解这种问题，但太详细的日志仍然给日志管理基础设施带来过大的压力。
|
||||
- 如果可能，尽量在日志条目中提供事务或请求 ID。这可以使跨日志源追踪应用活动变得更容易，尤其是在处理分布式应用时。
|
||||
+111
@@ -0,0 +1,111 @@
|
||||
---
|
||||
title: 监控最佳实践
|
||||
---
|
||||
|
||||
配置合理的监控和告警规则对于安全、可靠地运行生产环境中的工作负载至关重要。在使用 Kubernetes 和 Rancher 时也是如此。幸运的是，你可以使用集成的监控和告警功能来简化整个过程。
|
||||
|
||||
[Rancher 监控文档](../../../pages-for-subheaders/monitoring-and-alerting.md)描述了如何设置完整的 Prometheus 和 Grafana。这是开箱即用的功能，它将从集群中的所有系统和 Kubernetes 组件中抓取监控数据，并提供合理的仪表板和告警。但为了实现可靠的设置，你还需要监控你的工作负载并使 Prometheus 和 Grafana 适应你的特定用例和集群规模。本文档将为你提供这方面的最佳实践。
|
||||
|
||||
## 监控内容
|
||||
|
||||
Kubernetes 本身以及运行在其内部的应用构成了一个分布式系统，不同的组件之间能够进行交互。对于整个系统和每个单独的组件，你必须确保其性能、可用性、可靠性和可扩展性。详情请参见 Google 免费的 [Site Reliability Engineering Book](https://sre.google/sre-book/table-of-contents/)，尤其是关于 [Monitoring distributed systems](https://sre.google/sre-book/monitoring-distributed-systems/) 的章节。
|
||||
|
||||
## 配置 Prometheus 资源使用
|
||||
|
||||
在安装集成监控时，Rancher 允许进行一些配置，这些配置取决于你的集群规模和其中运行的工作负载。本章将更详细地介绍这些内容。
|
||||
|
||||
### 存储和数据保留
|
||||
|
||||
Prometheus 所需的存储空间取决于你存储的时间序列和标签的数量，以及你配置的数据保留量。需要注意的是，Prometheus 并不是用来长期存储指标的。数据通常只保留几天，而不是几周或几个月。这是因为 Prometheus 不会对存储的指标进行任何聚合。不聚合的好处是避免稀释数据，但这也意味着不设置保留时长的话，所需的存储空间随着时间的推移线性增长。
|
||||
|
||||
以下是计算所需存储空间的一种方法。首先，通过以下查询来查看 Prometheus 中存储块的平均大小：
|
||||
|
||||
```
|
||||
rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1h]) / rate(prometheus_tsdb_compaction_chunk_samples_sum[1h])
|
||||
```
|
||||
|
||||
接下来，找出每秒的数据引入速率：
|
||||
|
||||
```
|
||||
rate(prometheus_tsdb_head_samples_appended_total[1h])
|
||||
```
|
||||
|
||||
然后与保留时间相乘，并添加几个百分点作为缓冲区：
|
||||
|
||||
```
|
||||
平均块大小（以字节为单位）x 每秒的数据引入速率 x 保留时间（以秒为单位）x 1.1 = 必需的存储空间（以字节为单位）
|
||||
```
|
||||
|
||||
你可以访问[这篇博客](https://www.robustperception.io/how-much-disk-space-do-prometheus-blocks-use)了解关于如何计算必须的存储空间的更多信息。
|
||||
|
||||
你可以参见 [Prometheus 官方文档](https://prometheus.io/docs/prometheus/latest/storage)来进一步了解 Prometheus 的存储概念。
|
||||
|
||||
### CPU 和内存的请求和限制
|
||||
|
||||
在较大的 Kubernetes 集群中，Prometheus 会消耗大量内存。Prometheus 需要的内存与它存储的时间序列和标签的数量以及抓取间隔有关。
|
||||
|
||||
你可以访问[这篇博客](https://www.robustperception.io/how-much-ram-does-prometheus-2-x-need-for-cardinality-and-ingestion)了解关于如何计算必须的内存的更多信息。
|
||||
|
||||
所需的 CPU 数量与你正在执行的查询数量相关。
|
||||
|
||||
### 长期储存
|
||||
|
||||
Prometheus 不是用于长期存储指标的，它只用于短期存储。
|
||||
|
||||
如果想要长时间存储部分或全部指标，你可以利用 Prometheus 的[远程读/写](https://prometheus.io/docs/prometheus/latest/storage/#remote-storage-integrations)功能将其连接到 [Thanos](https://thanos.io/)，[InfluxDB](https://www.influxdata.com/) 或 [M3DB](https://www.m3db.io/) 等存储系统。你可以访问[这篇博客](https://rancher.com/blog/2020/prometheus-metric-federation)找到设置示例。
|
||||
|
||||
## 抓取自定义工作负载
|
||||
|
||||
虽然集成的 Rancher Monitoring 已经可以从集群的节点和系统组件中抓取系统指标，但你也需要为部署在 Kubernetes 上的自定义工作负载抓取数据。为此，你可以配置 Prometheus，让它在一定的时间间隔内对你应用的端点进行 HTTP 请求。然后，这些端点会以 Prometheus 格式返回指标。
|
||||
|
||||
一般来说，你会从集群中运行的所有工作负载中抓取数据，然后将数据用于告警或调试问题。一般情况下，你只有在具体事件发生后才需要某些指标数据。如果数据已经被抓取并存储了，那就好办了。由于 Prometheus 只是短期存储指标，因此抓取和存储大量数据的成本并不是那么高。如果你使用的是 Prometheus 的长期存储方案，那么你也可以决定持久存储哪些数据。
|
||||
|
||||
### 关于 Prometheus Exporters
|
||||
|
||||
许多第三方工作负载（如数据库、队列或 Web 服务器）要么已经支持以 Prometheus 格式公开指标，要么有所谓的 exporter，来对工具的指标格式和 Prometheus 理解的指标格式进行转换。通常，你可以将这些 exporter 作为额外的 Sidecar 容器添加到工作负载的 Pod 中。很多 Helm Chart 已经包含了部署 exporter 的选项。此外，你还可以在 [promcat.io](https://promcat.io/) 和 [ExporterHub](https://exporterhub.io/) 上找到一个由 SysDig 策划的 exporter 列表。
|
||||
|
||||
### Prometheus 的编程语言和框架支持
|
||||
|
||||
要想把你的自定义应用指标放到 Prometheus 中，你必须直接从你的应用代码中收集和暴露这些指标。幸运的是，对于大多数流行的编程语言和框架来说，已经有一些库和集成来帮助解决这个问题。其中一个例子是 [Spring 框架](https://docs.spring.io/spring-metrics/docs/current/public/prometheus)中的 Prometheus 支持。
|
||||
|
||||
### ServiceMonitor 和 PodMonitor
|
||||
|
||||
一旦所有工作负载都以 Prometheus 格式公开了指标后，你必须配置 Prometheus 来抓取数据。Rancher 使用 [prometheus-operator](https://github.com/prometheus-operator/prometheus-operator)，这使得使用 ServiceMonitors 和 PodMonitors 来添加其他抓取目标变得容易。很多 Helm Chart 已经包含直接创建这些监控器的选项。你也可以在 Rancher 文档中找到更多信息。
|
||||
|
||||
### Prometheus 推送网关（Pushgateway）
|
||||
|
||||
有些工作负载的指标很难被 Prometheus 抓取，就像 Jobs 和 CronJobs 这样的短期工作负载，或者是不允许在单个处理的传入请求之间共享数据的应用，如 PHP 应用。
|
||||
|
||||
要想获得这些用例的指标，你可以设置 [prometheus-pushgateways](https://github.com/prometheus/pushgateway)。CronJob 或 PHP 应用将把指标更新推送到 pushgateway。pushgateway 汇总并通过 HTTP 端点暴露它们，然后可以由 Prometheus 抓取。
|
||||
|
||||
### Prometheus Blackbox 监控
|
||||
|
||||
有时，你可能需要从外部监控工作负载。为此，你可以使用 [Prometheus blackbox-exporter](https://github.com/prometheus/blackbox_exporter)，它允许通过 HTTP、HTTPS、DNS、TCP 和 ICMP 探测任何类型的端点。
|
||||
|
||||
## 在（微）服务架构中进行监控
|
||||
|
||||
如果你有一个（微）服务架构，在该架构中集群的多个单独的工作负载相互通信，那么拥有这些流量的详细指标和跟踪是非常重要的，因为这可以帮助你了解所有这些工作负载之间的通信方式，以及问题或瓶颈可能出现的地方。
|
||||
|
||||
当然，你可以监控所有工作负载中的所有内部流量，并将这些指标暴露给 Prometheus，但这相当耗费精力。像 Istio 这样的服务网格（可以通过[单击](https://rancher.com/docs/rancher/v2.6/en/istio/)在 Rancher 中安装）可以自动完成这项工作，并提供所有 Service 之间流量的丰富的遥测数据。
|
||||
|
||||
## 真实用户监控
|
||||
|
||||
监控所有内部工作负载的可用性和性能对于稳定、可靠和快速地运行应用至关重要。但这些指标只能向你展示部分情况。要想获得一个完整的视图，还必须知道你的最终用户是如何实际感知的。为此，你可以研究各种[真实用户监控解决方案](https://en.wikipedia.org/wiki/Real_user_monitoring)。
|
||||
|
||||
## 安全监控
|
||||
|
||||
除了通过监控工作负载来检测性能、可用性或可扩展性之外，你还应该监控集群和运行在集群中的工作负载，来发现潜在的安全问题。一个好的做法是经常运行 [CIS 扫描](../../../pages-for-subheaders/cis-scan-guides.md)并发出告警，来检查集群是否按照安全最佳实践进行配置。
|
||||
|
||||
对于工作负载，你可以查看 Kubernetes 和 Container 安全解决方案，例如 [NeuVector](https://www.suse.com/products/neuvector/)、[Falco](https://falco.org/)、[Aqua Kubernetes Security](https://www.aquasec.com/solutions/kubernetes-container-security/) 和 [SysDig](https://sysdig.com/)。
|
||||
|
||||
## 设置告警
|
||||
|
||||
将所有的指标纳入监控系统并在仪表板中可视化是很好的做法，但你也希望在出现问题时能主动收到提醒。
|
||||
|
||||
集成的 Rancher 监控已经配置了一套合理的告警，这些告警在任何 Kubernetes 集群中都是可用的。你可以扩展告警，来覆盖特定的工作负载和用例。
|
||||
|
||||
在设置告警时，你需要为对你应用非常关键的工作负载配置告警，但同时也要确保告警不会太频繁。理想情况下，你收到的每一个告警都应该是一个你需要关注并解决的问题。如果你一直收到不太关键的告警，你就有可能开始完全忽略告警信息，然后错过真正重要的告警。因此，少量的告警可能会更好。首先，你可以关注真正重要的指标，例如应用离线等。之后，解决出现的所有问题，然后再创建更详细的告警。
|
||||
|
||||
如果告警开始发送，但你暂时无法处理，你也可以将告警静默一定时间，以便以后查看。
|
||||
|
||||
如果需要了解更多关于如何设置告警和通知通道的信息，请访问 [Rancher 文档中心](../../../pages-for-subheaders/monitoring-and-alerting.md)。
|
||||
+58
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: Rancher 管理 vSphere 集群的最佳实践
|
||||
---
|
||||
|
||||
本指南概述了在 vSphere 环境中配置下游 Rancher 集群的参考架构，以及 VMware 记录的标准 vSphere 最佳实践。
|
||||
|
||||
- [1. 虚拟机注意事项](#1-虚拟机注意事项)
|
||||
- [2. 网络注意事项](#2-网络注意事项)
|
||||
- [3. 存储注意事项](#3-存储注意事项)
|
||||
- [4. 备份和灾难恢复](#4-备份和灾难恢复)
|
||||
|
||||
<figcaption>解决方案概述</figcaption>
|
||||
|
||||
|
||||
|
||||
## 1. 虚拟机注意事项
|
||||
|
||||
### 利用虚拟机模板来构建环境
|
||||
|
||||
为了保证跨环境部署的虚拟机的一致性，你可以考虑使用虚拟机模板形式的黄金镜像（golden image）。你可以使用 Packer 来实现，从而增加更多自定义选项。
|
||||
|
||||
### 利用 DRS 反亲和规则（可能的话）在 ESXi 主机上分离下游集群节点
|
||||
|
||||
这样可以确保节点虚拟机分布在多台 ESXi 主机上，从而防止主机级别的单点故障。
|
||||
|
||||
### 利用 DRS 反亲和规则（可能的话）在 Datastore 上分离下游集群节点
|
||||
|
||||
这样可以确保节点虚拟机分布在多个 Datastore 上，从而防止 Datastore 级别的单点故障。
|
||||
|
||||
### 为 Kubernetes 配置合适的虚拟机
|
||||
|
||||
在部署节点时，请遵循 K8s 和 etcd 的最佳实践，其中包括禁用 swap，检查集群中的所有主机之间是否有良好的网络连接，为每个节点使用唯一的主机名、MAC 地址和 `product_uuids`。
|
||||
|
||||
## 2. 网络注意事项
|
||||
|
||||
### 利用 ETCD 节点之间的低延迟和高带宽连接
|
||||
|
||||
尽可能在单个数据中心内部署 etcd 成员，来避免延迟开销并减少网络分区的可能性。大多数情况下，1Gb 的连接就足够了。对于大型集群，10Gb 的连接可以缩短恢复备份所需的时间。
|
||||
|
||||
### 为虚拟机提供固定的 IP 地址
|
||||
|
||||
你可以为使用的所有节点都配置一个静态 IP。如果使用 DHCP，则每个节点都应该有一个 DHCP 预留，以确保节点分配到相同的 IP 地址。
|
||||
|
||||
## 3. 存储注意事项
|
||||
|
||||
### 在 ETCD 节点上使用 SSD 磁盘
|
||||
|
||||
ETCD 对写入延迟非常敏感。因此，你可以尽量使用 SSD 磁盘来提高写入性能。
|
||||
|
||||
## 4. 备份和灾难恢复
|
||||
|
||||
### 定期备份下游集群
|
||||
|
||||
Kubernetes 使用 etcd 来存储其所有数据，包括配置、状态和元数据。在灾难恢复的情况下，备份这些数据是至关重要的。
|
||||
|
||||
### 备份下游节点虚拟机
|
||||
|
||||
将 Rancher 下游节点的虚拟机纳入标准的虚拟机备份策略中。
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: 设置容器的技巧
|
||||
---
|
||||
|
||||
配置良好的容器可以极大地提高环境的整体性能和安全性。
|
||||
|
||||
本文介绍一些设置容器的技巧。
|
||||
|
||||
如果你需要了解容器安全的详细信息，也可以参见 Rancher 的[容器安全指南](https://rancher.com/complete-guide-container-security)。
|
||||
|
||||
### 使用通用容器操作系统
|
||||
|
||||
在可能的情况下，你应该尽量在通用的容器基础操作系统上进行标准化。
|
||||
|
||||
Alpine 和 BusyBox 等较小的发行版减少了容器镜像的大小，并且通常具有较小的漏洞。
|
||||
|
||||
流行的发行版如 Ubuntu、Fedora 和 CentOS 等都经过了大量的测试，并提供了更多的功能。
|
||||
|
||||
### 使用 From scratch 容器
|
||||
如果你的微服务是一个独立的静态二进制，你应该使用 `From scratch` 容器。
|
||||
|
||||
`FROM scratch` 容器是一个[官方 Docker 镜像](https://hub.docker.com/_/scratch)，它是空的，这样你就可以用它来设计最小的镜像。
|
||||
|
||||
这个镜像这将具有最小的攻击层和最小的镜像大小。
|
||||
|
||||
### 以非特权方式运行容器进程
|
||||
在可能的情况下，在容器内运行进程时使用非特权用户。虽然容器运行时提供了隔离，但仍然可能存在漏洞和攻击。如果容器以 root 身份运行，无意中或意外的主机挂载也会受到影响。有关为 Pod 或容器配置安全上下文的详细信息，请参见 [Kubernetes 文档](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)。
|
||||
|
||||
### 定义资源限制
|
||||
你应该将 CPU 和内存限制应用到你的 Pod 上。这可以帮助管理 worker 节点上的资源，并避免发生故障的微服务影响其他微服务。
|
||||
|
||||
在标准 Kubernetes 中，你可以设置命名空间级别的资源限制。在 Rancher 中，你可以设置项目级别的资源限制，项目内的所有命名空间都会继承这些限制。详情请参见 Rancher 官方文档。
|
||||
|
||||
在设置资源配额时，如果你在项目或命名空间上设置了任何与 CPU 或内存相关的内容（即限制或预留），所有容器都需要在创建期间设置各自的 CPU 或内存字段。为了避免在创建工作负载期间对每个容器设置这些限制，可以在命名空间上指定一个默认的容器资源限制。
|
||||
|
||||
有关如何在[容器级别](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container)和命名空间级别设置资源限制的更多信息，请参见 Kubernetes 文档。
|
||||
|
||||
### 定义资源需求
|
||||
你应该将 CPU 和内存要求应用到你的 Pod 上。这对于通知调度器需要将你的 pod 放置在哪种类型的计算节点上，并确保它不会过度配置该节点资源至关重要。在 Kubernetes 中，你可以通过在 pod 的容器规范的资源请求字段中定义 `resources.requests` 来设置资源需求。详情请参见 [Kubernetes 文档](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container)。
|
||||
|
||||
:::note
|
||||
|
||||
如果你为 pod 所部署的命名空间设置了资源限制，而容器没有特定的资源请求，则不允许启动 pod。为了避免在创建工作负载期间对每个容器设置这些字段，可以在命名空间上指定一个默认的容器资源限制。
|
||||
|
||||
:::
|
||||
|
||||
建议在容器级别上定义资源需求，否则，调度器会认为集群加载对你的应用没有帮助。
|
||||
|
||||
### 配置存活和就绪探测器
|
||||
你可以为你的容器配置存活探测器和就绪探测器。如果你的容器不是完全崩溃，Kubernetes 是不会知道它是不健康的，除非你创建一个可以报告容器状态的端点或机制。或者，确保你的容器在不健康的情况下停止并崩溃。
|
||||
|
||||
Kubernetes 文档展示了如何[为容器配置存活和就绪探测器](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)。
|
||||
+84
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: 在 vSphere 环境中安装 Rancher
|
||||
---
|
||||
|
||||
本指南概述了在 vSphere 环境中在 RKE Kubernetes 集群上安装 Rancher 的参考架构，以及 VMware 记录的标准 vSphere 最佳实践。
|
||||
|
||||
|
||||
<figcaption>解决方案概述</figcaption>
|
||||
|
||||
|
||||
|
||||
## 1. 负载均衡器注意事项
|
||||
|
||||
你需要使用一个负载均衡器将流量转发到 RKE 节点上的 Rancher 工作负载。
|
||||
|
||||
### 利用容错和高可用性
|
||||
|
||||
请充分利用具有继承高可用功能的外部（硬件或软件）负载均衡器（如：F5、NSX-T、Keepalived 等）。
|
||||
|
||||
### 备份负载均衡器配置
|
||||
|
||||
在灾难恢复时，可用的负载均衡器配置可以加快恢复过程。
|
||||
|
||||
### 配置健康检查
|
||||
|
||||
让负载均衡器在健康检查失败时自动将节点标记为不可用。例如，NGINX 可以通过以下配置来实现这一功能：
|
||||
|
||||
`max_fails=3 fail_timeout=5s`
|
||||
|
||||
### 利用外部负载均衡器
|
||||
|
||||
避免在管理集群内使用软件负载均衡器。
|
||||
|
||||
### 安全访问 Rancher
|
||||
|
||||
将防火墙/ACL 规则配置为只允许 Rancher 访问。
|
||||
|
||||
## 2. 虚拟机注意事项
|
||||
|
||||
### 根据 Rancher 文档确定虚拟机的大小
|
||||
|
||||
请参阅[安装要求](../../../pages-for-subheaders/installation-requirements.md)。
|
||||
|
||||
### 利用虚拟机模板来构建环境
|
||||
|
||||
为了保证跨环境部署的虚拟机的一致性，你可以考虑使用虚拟机模板形式的黄金镜像（golden image）。你可以使用 Packer 来实现，从而增加更多自定义选项。
|
||||
|
||||
### 利用 DRS 反亲和规则（可能的话）在 ESXi 主机上分离 Rancher 集群节点
|
||||
|
||||
这样可以确保节点虚拟机分布在多台 ESXi 主机上，从而防止主机级别的单点故障。
|
||||
|
||||
### 利用 DRS 反亲和规则（可能的话）在 Datastore 上分离 Rancher 集群节点
|
||||
|
||||
这样可以确保节点虚拟机分布在多个 Datastore 上，从而防止 Datastore 级别的单点故障。
|
||||
|
||||
### 为 Kubernetes 配置合适的虚拟机
|
||||
|
||||
在部署节点时，请遵循 K8s 和 etcd 的最佳实践，其中包括禁用 swap，检查集群中的所有主机之间是否有良好的网络连接，为每个节点使用唯一的主机名、MAC 地址和 `product_uuids`。
|
||||
|
||||
## 3. 网络注意事项
|
||||
|
||||
### 利用 ETCD 节点之间的低延迟和高带宽连接
|
||||
|
||||
尽可能在单个数据中心内部署 etcd 成员，来避免延迟开销并减少网络分区的可能性。大多数情况下，1Gb 的连接就足够了。对于大型集群，10Gb 的连接可以缩短恢复备份所需的时间。
|
||||
|
||||
### 为虚拟机提供固定的 IP 地址
|
||||
|
||||
你可以为使用的所有节点都配置一个静态 IP。如果使用 DHCP，则每个节点都应该有一个 DHCP 预留，以确保节点分配到相同的 IP 地址。
|
||||
|
||||
## 4. 存储注意事项
|
||||
|
||||
### 在 ETCD 节点上使用 SSD 磁盘
|
||||
|
||||
ETCD 对写入延迟非常敏感。因此，你可以尽量使用 SSD 磁盘来提高写入性能。
|
||||
|
||||
## 5. 备份和灾难恢复
|
||||
|
||||
### 定期备份管理集群
|
||||
|
||||
Rancher 将数据存储在它所在的 Kubernetes 集群的 ETCD datastore 中。与其它 Kubernetes 集群一样，你需要对该集群进行频繁且经过测试的备份。
|
||||
|
||||
### 备份 Rancher 集群节点虚拟机
|
||||
|
||||
将 Rancher 管理节点的虚拟机纳入标准的虚拟机备份策略中。
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: Rancher 部署策略
|
||||
---
|
||||
|
||||
本文提供 Rancher 实例的两种部署策略，用于管理下游 Kubernetes 集群。每种策略都有优缺点。请按照你的实际情况选择最适合的部署策略：
|
||||
|
||||
* [中心辐射型策略](#中心辐射型策略)
|
||||
* [区域型策略](#区域型策略)
|
||||
|
||||
## 中心辐射型策略
|
||||
---
|
||||
|
||||
在中心辐射型部署中，一个 Rancher 实例就可以管理遍布全球的 Kubernetes 集群。Rancher 实例运行在高可用 Kubernetes 集群上，并且会受延迟影响。
|
||||
|
||||
### 优点
|
||||
|
||||
* 可以通过一个 controlplane 界面查看所有区域和环境。
|
||||
* Kubernetes 不需要 Rancher 进行操作，并且可以容忍与 Rancher 实例断开连接。
|
||||
|
||||
### 缺点
|
||||
|
||||
* 受限于网络延迟。
|
||||
* 如果 Rancher 出现故障，在恢复之前不可以在全球范围内创建新服务。但是每个 Kubernetes 集群都可以继续单独管理。
|
||||
|
||||
## 区域型策略
|
||||
---
|
||||
在区域型部署模型中，Rancher 实例部署在靠近下游 Kubernetes 集群的位置。
|
||||
|
||||
### 优点
|
||||
|
||||
* 如果某个区域的 Rancher 实例出现故障，其他区域内的 Rancher 功能仍然可以保持正常。
|
||||
* Rancher 和下游集群之间的网络延迟大大降低，提高了 Rancher 的性能。
|
||||
* 你可以在每个区域内独立升级 Rancher。
|
||||
|
||||
### 缺点
|
||||
|
||||
* 管理多个 Rancher 安装的开销较大。
|
||||
* 需要在多个界面中查看不同区域的 Kubernetes 集群。
|
||||
* 在 Rancher 中部署多集群应用时，需要在每个 Rancher Server 中重复部署步骤。
|
||||
+36
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: Rancher 运行技巧
|
||||
---
|
||||
|
||||
本指南适用于使用 Rancher 管理下游 Kubernetes 集群的用例。高可用设置可以防止 Rancher Server 不可用时无法访问下游集群。
|
||||
|
||||
高可用 Rancher 安装指将 Rancher 安装到至少有三个节点的 Kubernetes 集群上，适用于所有生产环境以及重要的安装场景。在多个节点上运行多个 Rancher 实例能够实现单节点安装无法提供的高可用性。
|
||||
|
||||
如果你在 vSphere 环境中安装 Rancher，请参见[最佳实践文档](on-premises-rancher-in-vsphere.md)。
|
||||
|
||||
在设置高可用 Rancher 安装时，请考虑以下事项。
|
||||
|
||||
### 在单独的集群上运行 Rancher
|
||||
不要在安装了 Rancher 的 Kubernetes 集群上运行其他工作负载或微服务。
|
||||
|
||||
### 确保 Kubernetes 节点配置正确
|
||||
在部署节点时，请遵循 K8s 和 etcd 的最佳实践，其中包括禁用 swap，检查集群中的所有主机之间是否有良好的网络连接，为每个节点使用唯一的主机名、MAC 地址和 `product_uuids`，检查所需端口是否已经打开，并使用配置 SSD 的 etcd 进行部署。详情请参见 [kubernetes 官方文档](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin)和 [etcd 性能操作指南](https://etcd.io/docs/v3.4/op-guide/performance/)。
|
||||
|
||||
### 使用 RKE 时：备份状态文件（Statefile）
|
||||
RKE 将集群状态记录在一个名为 `cluster.rkestate` 的文件中，该文件对集群的恢复和/或通过 RKE 维护集群非常重要。由于这个文件包含证书材料，我们强烈建议在备份前对该文件进行加密。请在每次运行 `rke up` 后备份状态文件。
|
||||
|
||||
### 在同一个数据中心运行集群中的所有节点
|
||||
为达到最佳性能，请在同一地理数据中心运行所有三个节点。如果你在云（如 AWS）上运行节点，请在不同的可用区（AZ）中运行这三个节点。例如，在 us-west-2a 中运行节点 1，在 us-west-2b 中运行节点 2，在 us-west-2c 中运行节点 3。
|
||||
|
||||
### 保证开发和生产环境的相似性
|
||||
强烈建议为运行 Rancher 的 Kubernetes 集群配备 “staging” 或 “pre-production” 环境。这个环境的软件和硬件配置应该尽可能接近你的生产环境。
|
||||
|
||||
### 监控集群以规划容量
|
||||
Rancher Server 的 Kubernetes 集群应该尽可能满足[系统和硬件要求](../../../pages-for-subheaders/installation-requirements.md)。越偏离系统和硬件要求，你可能面临的风险就越大。
|
||||
|
||||
但是，已发布的要求已经考虑了各种工作负载类型，因此，基于指标来规划容量应该是扩展 Rancher 的最佳实践。
|
||||
|
||||
你可以将 Rancher 集成业界领先的开源监控解决方案 Prometheus 以及能可视化 Prometheus 指标的 Grafana，来监控集群节点、Kubernetes 组件和软件部署的状态和过程。
|
||||
|
||||
在集群中[启用监控](../../../pages-for-subheaders/monitoring-and-alerting.md)后，你可以通过设置告警通知，来了解集群容量的使用情况。你还可以使用 Prometheus 和 Grafana 监控框架，在你扩容时建立关键指标的基线。
|
||||
|
||||
+61
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: Rancher 扩展技巧
|
||||
---
|
||||
|
||||
本指南介绍了扩展 Rancher 时应该考虑的方法，以及这样做的难度。随着系统的增长，性能自然会降低，但我们可以采取一些措施来最大限度地减少 Rancher 的负载，并优化 Rancher 处理这些大型设置的能力。
|
||||
|
||||
## 优化 Rancher 性能的技巧
|
||||
* 建议及时更新 Rancher 的补丁版本。在次要版本的整个生命周期中，我们都会进行性能改进和错误修复。你可以查看发行说明决定是否需要升级，但在大多数情况下，我们建议你使用最新版本。
|
||||
|
||||
* 性能会受 Rancher 的基础设施和下游集群的基础设施之间的延迟影响（例如，地理距离）。如果用户需要遍布全球或分布在许多地区的集群/节点，最好使用多个 Rancher。
|
||||
|
||||
* 请始终尝试逐渐扩大规模，同时监控和观察变化。通常情况下，性能问题越早解决越好，而且在其他问题出现之前更容易解决。
|
||||
|
||||
## 最小化本地集群的负载
|
||||
扩展 Rancher 最大的瓶颈是本地 Kubernetes 集群中的资源增长。local 集群包含所有下游集群的信息。下游集群的许多操作将在 local 集群中创建新对象，并需要使用 local 集群中运行的处理程序进行计算。
|
||||
|
||||
### 管理对象数量
|
||||
ETCD 最终会遇到存储的 Kubernetes 资源数量超过限制的问题。暂时没有这些数字的确切记录。根据内部观察，一旦单个资源类型的对象数量超过 60k（通常是 Rolebindings），就很有可能遇到性能问题。
|
||||
|
||||
Rolebindings 是在 local 集群中创建的，是许多操作的结果。
|
||||
|
||||
尝试减少 local 集群中的 rolebindings 时需要注意：
|
||||
* 仅在必要时将用户添加到集群和项目中
|
||||
* 删除不需要的集群和项目
|
||||
* 仅在必要时使用自定义角色
|
||||
* 在自定义角色中使用尽可能少的规则
|
||||
* 考虑给用户添加角色是否多余
|
||||
* 使用更少但更强大的集群可能更高效
|
||||
* 检查是否能通过创建新项目或新集群为你的用例减少 rolebindings。
|
||||
|
||||
### 使用新版应用程序而不是旧版应用程序
|
||||
Rancher 使用了两个应用程序 kubernetes 资源，分别是 apps.projects.cattle.io 和 apps.cattle.cattle.io。旧版应用程序 apps.projects.cattle.io 最初是在 Cluster Manager 中引入的，现在已经过时。新版应用程序 apps.catalog.cattle.io 可在其各自集群的 Cluster Explorer 中找到。新版应用程序更受欢迎，因为它们位于下游集群中，而旧版应用程序位于 local 集群中。
|
||||
|
||||
我们建议删除 Cluster Manager 中出现的应用程序，如有必要，可以为目标集群替换为 Cluster Explorer 中的应用程序，并仅在集群的 Cluster Explorer 中创建后续的应用程序。
|
||||
|
||||
### 使用授权集群端点（ACE）
|
||||
Rancher 配置的 RKE1、RKE2 和 K3s 集群有一个 _授权集群端点_ 选项。启用后，会在为集群生成的 kubeconfigs 中添加一个上下文，该上下文使用一个直接到集群的端点，并绕过 Rancher。但是，仅启用此选项是不够的。Kubeconfig 的用户需要使用 `kubectl use-context <ace context name>` 才能开始使用它。
|
||||
|
||||
如果不使用 ACE，所有 kubeconfig 请求都会先通过 Rancher 进行路由。
|
||||
|
||||
### 实验功能：减少事件处理程序执行的选项
|
||||
Rancher 的大部分逻辑都发生在事件处理程序上。每当更新对象以及启动 Rancher 时，这些事件处理程序都会在对象上运行。此外，当缓存同步时，它们每 15 小时会运行一次。在缩放设置中，由于每个处理程序都会在每个适用对象上运行，因此运行这些计划会消耗巨大的性能。但是，你可以使用 `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` 环境变量来禁用处理程序的这些计划执行。如果在大约 15 小时的间隔内看到资源分配峰值，则此设置可能有帮助。
|
||||
|
||||
环境变量的值可以是以下选项的逗号分隔列表。这些值指的是控制器的类型（包含和运行处理程序的 struct）及其处理程序。如果将控制器类型添加到变量中，那么该组控制器将无法在重新同步缓存时运行其处理程序。
|
||||
|
||||
* `mgmt` 指的是只运行在一个 Rancher 节点上的管理控制器。
|
||||
* `user` 指的是为每个集群运行的用户控制器。其中一些运行在与管理控制器相同的节点上，而其他则运行在下游集群中。该选项针对前者。
|
||||
* `scaled` 指的是在每个 Rancher 节点上运行的缩放控制器。由于缩放处理程序负责的关键功能，因此不建议设置。
|
||||
|
||||
简而言之，如果你发现 CPU 使用率每 15 小时出现一次峰值，请将 `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` 环境变量添加到你的 Rancher 部署中，其值为 `mgmt,user`。
|
||||
|
||||
## Rancher 之外的优化
|
||||
影响性能的一个重要因素是 local 集群及其配置方式。该集群可能会在 Rancher 运行之前引入瓶颈。当 Rancher 节点出现资源占用过高的情况时，你可以使用 top 命令来判断是 Rancher 还是 Kubernetes 组件在超额消耗资源。
|
||||
|
||||
### 保持使用最新版本的 Kubernetes
|
||||
与 Rancher 版本类似，我们建议让你的 kubernetes 集群保持使用最新版本。这将确保你的集群能包含可用的性能增强或错误修复。
|
||||
|
||||
### 优化 ETCD
|
||||
[ETCD 性能](https://etcd.io/docs/v3.4/op-guide/performance/)的两个主要瓶颈是磁盘速度和网络速度。对任何一个进行优化都应该能提高性能。有关 ETCD 性能的信息，请参阅 [etcd 性能慢（性能测试和优化）](https://www.suse.com/support/kb/doc/?id=000020100)和[为大型安装调优 etcd](https://docs.ranchermanager.rancher.io/how-to-guides/advanced-user-guides/tune-etcd-for-large-installs)。有关磁盘的信息，你也可以参阅[我们的文档](https://docs.Ranchermanager.Rancher.io/v2.5/pages-for-subheaders/installation-requirements#disks)。
|
||||
|
||||
理论上，ETCD 集群中的节点越多，由于复制要求 [source](https://etcd.io/docs/v3.3/faq)，它就会越慢。这可能与常见的缩放方法相悖。我们还可以推断，ETCD 的性能将受到节点间距离的反面影响，因为这将减慢网络通信。
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: kubectl 实用程序
|
||||
---
|
||||
|
||||
## kubectl
|
||||
|
||||
kubectl 用于与 Rancher 进行交互。
|
||||
|
||||
### kubectl 实用程序
|
||||
|
||||
安装 `kubectl`。详情请参见[安装 kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)。
|
||||
|
||||
要配置 kubectl，通过 Rancher Web UI 访问你的集群，单击 `Kubeconfig`，然后复制内容并将其粘贴到你的 `~/.kube/config` 文件中。
|
||||
|
||||
检查是否可以成功运行 `kubectl cluster-info` 或 `kubectl get pods` 命令。
|
||||
|
||||
### 使用 kubectl 和 kubeconfig 令牌进行 TTL 认证
|
||||
|
||||
_要求_
|
||||
|
||||
如果管理员[关闭了 kubeconfig 令牌生成](../about-the-api/api-tokens.md#在生成的-kubeconfig-中禁用令牌)，当你运行 `kubectl` 时，kubeconfig 文件需要 [Rancher CLI](./rancher-cli.md) 存在于你的 PATH 中。否则，你会看到这样的错误信息：
|
||||
`Unable to connect to the server: getting credentials: exec: exec: "rancher": executable file not found in $PATH`。
|
||||
|
||||
该功能可以让 kubectl 与 Rancher Server 进行身份验证，并在需要时获得新的 kubeconfig token。目前支持以下验证提供程序：
|
||||
|
||||
1. 本地
|
||||
2. Active Directory (仅限 LDAP)
|
||||
3. FreeIPA
|
||||
4. OpenLDAP
|
||||
5. SAML 身份提供商：Ping，Okta，ADFS，Keycloak 和 Shibboleth
|
||||
|
||||
如果你是第一次运行 kubectl（例如，`kubectl get pods`），它会要求你选择一个验证提供程序并使用 Rancher Server 登录。kubeconfig token 会被缓存到 `./.cache/token` 下你运行 kubectl 的路径中。该 Token 在[过期](../about-the-api/api-tokens.md#在生成的-kubeconfig-中禁用令牌)或[从 Rancher Server 删除](../about-the-api/api-tokens.md#删除令牌)之前都是有效的。过期后，下一个 `kubectl get pods` 命令会要求你再次使用 Rancher Server 登录。
|
||||
+87
@@ -0,0 +1,87 @@
|
||||
---
|
||||
title: Rancher CLI
|
||||
description: Rancher CLI 是一个命令行工具，用于在工作站中与 Rancher 进行交互。
|
||||
---
|
||||
|
||||
Rancher CLI（命令行界面）是一个命令行工具，可用于与 Rancher 进行交互。使用此工具，你可以使用命令行而不用通过 GUI 来操作 Rancher。
|
||||
|
||||
### 下载 Rancher CLI
|
||||
|
||||
你可以直接 UI 下载二进制文件。
|
||||
|
||||
1. 点击左上角的 **☰**。
|
||||
1. 单击底部的 **v2.6.x**，**v2.6.x** 是一个超链接文本，表示已安装的 Rancher 版本。
|
||||
1. 在 **CLI 下载**中，有 Windows、Mac 和 Linux 的二进制文件下载链接。你还可以访问我们的 CLI [发布页面](https://github.com/rancher/cli/releases)直接下载二进制文件。
|
||||
|
||||
### 要求
|
||||
|
||||
下载 Rancher CLI 后，你需要进行一些配置。Rancher CLI 需要：
|
||||
|
||||
- 你的 Rancher Server URL，用于连接到 Rancher Server。
|
||||
- API 持有者令牌（Bearer Token），用于向 Rancher 进行身份验证。有关获取持有者令牌的更多信息，请参阅[创建 API 密钥](../user-settings/api-keys.md)。
|
||||
|
||||
### CLI 身份验证
|
||||
|
||||
在使用 Rancher CLI 控制你的 Rancher Server 之前，你必须使用 API 持有者令牌进行身份验证。运行以下命令进行登录（将 `<BEARER_TOKEN>` 和 `<SERVER_URL>` 替换为你的实际信息）：
|
||||
|
||||
```bash
|
||||
$ ./rancher login https://<SERVER_URL> --token <BEARER_TOKEN>
|
||||
```
|
||||
|
||||
如果 Rancher Server 使用自签名证书，Rancher CLI 会提示你继续连接。
|
||||
|
||||
### 项目选择
|
||||
|
||||
在执行命令之前，你必须先选择一个 Rancher 项目来执行这些命令。要选择[项目](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md)，请运行 `./rancher context switch` 命令。输入此命令后，会显示可用项目的列表。输入一个数字以选择项目。
|
||||
|
||||
**示例：`./rancher context switch` 输出**
|
||||
```
|
||||
User:rancher-cli-directory user$ ./rancher context switch
|
||||
NUMBER CLUSTER NAME PROJECT ID PROJECT NAME
|
||||
1 cluster-2 c-7q96s:p-h4tmb project-2
|
||||
2 cluster-2 c-7q96s:project-j6z6d Default
|
||||
3 cluster-1 c-lchzv:p-xbpdt project-1
|
||||
4 cluster-1 c-lchzv:project-s2mch Default
|
||||
Select a Project:
|
||||
```
|
||||
|
||||
输入数字后，控制台会显示你所选项目的消息。
|
||||
|
||||
```
|
||||
INFO[0005] Setting new context to project project-1
|
||||
INFO[0005] Saving config to /Users/markbishop/.ranchcli2.json
|
||||
```
|
||||
|
||||
请确保你可以成功运行 `rancher kubectl get pods`。
|
||||
|
||||
### 命令
|
||||
|
||||
以下命令可用于 Rancher CLI：
|
||||
|
||||
| 命令 | 结果 |
|
||||
|---|---|
|
||||
| `apps, [app]` | 对商店应用（即单个 [Helm Chart](https://docs.helm.sh/developing_charts/)）或 Rancher Chart 执行操作。 |
|
||||
| `catalog` | 对[应用商店](../../pages-for-subheaders/helm-charts-in-rancher.md)执行操作。 |
|
||||
| `clusters, [cluster]` | 对[集群](../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)执行操作。 |
|
||||
| `context` | 在 Rancher [项目](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md)之间切换。有关示例，请参阅[项目选择](#项目选择)。 |
|
||||
| `inspect [OPTIONS] [RESOURCEID RESOURCENAME]` | 显示 [Kubernetes 资源](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#resource-types)或 Rancher 资源（即[项目](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md)和[工作负载](../../pages-for-subheaders/workloads-and-pods.md)）的详细信息。按名称或 ID 指定资源。 |
|
||||
| `kubectl` | 运行 [kubectl 命令](https://kubernetes.io/docs/reference/kubectl/overview/#operations)。 |
|
||||
| `login, [l]` | 登录 Rancher Server。有关示例，请参阅 [CLI 身份验证](#cli-身份验证)。 |
|
||||
| `namespaces, [namespace]` | 执行命名空间操作。 |
|
||||
| `nodes, [node]` | 执行节点空间操作。 |
|
||||
| `projects, [project]` | 执行[项目](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md)操作。 |
|
||||
| `ps` | 显示项目中的[工作负载](../../pages-for-subheaders/workloads-and-pods.md)。 |
|
||||
| `settings, [setting]` | 显示 Rancher Server 的当前设置。 |
|
||||
| `ssh` | 使用 SSH 协议连接到你的某个集群节点。 |
|
||||
| `help, [h]` | 显示命令列表或某个命令的帮助。 |
|
||||
|
||||
|
||||
### Rancher CLI 帮助
|
||||
|
||||
使用 CLI 登录 Rancher Server 后，输入 `./rancher --help` 以获取命令列表。
|
||||
|
||||
所有命令都支持 `--help` 标志，该标志解释了每个命令的用法。
|
||||
|
||||
### 限制
|
||||
|
||||
Rancher CLI **不能**用于安装[仪表板应用程序或 Rancher 功能 Chart](../../pages-for-subheaders/helm-charts-in-rancher.md)。
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: EC2 主机配置参考
|
||||
---
|
||||
|
||||
有关 EC2 和节点的更多详细信息，请参阅 [EC2 管理控制台](https://aws.amazon.com/ec2)的官方文档。
|
||||
|
||||
### 区域
|
||||
|
||||
构建集群的地理[区域](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)。
|
||||
|
||||
### 地区
|
||||
|
||||
[地区](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones)，一个区域内用于构建集群的隔离位置。
|
||||
|
||||
### 实例类型
|
||||
|
||||
[实例类型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)用于配置集群，能确定硬件特性。
|
||||
|
||||
### 根磁盘大小
|
||||
|
||||
配置[根设备](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html)的大小（以 GB 为单位）。
|
||||
|
||||
### VPC/子网
|
||||
|
||||
[VPC](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html) 或特定的[子网](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html)（VPC 中的一个 IP 范围），用于添加你的资源。
|
||||
|
||||
### IAM 实例配置文件名称
|
||||
|
||||
示例配置文件的名称，用于将 IAM 角色传递给 EC2 实例。
|
||||
|
||||
## 高级选项
|
||||
|
||||
### AMI ID
|
||||
|
||||
用于集群中节点的 [Amazon Machine Image（AMI）](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)。
|
||||
|
||||
### 用于 AMI 的 SSH 用户名
|
||||
|
||||
用于连接到你启动的实例的用户名。有关选定 AMI 的默认用户名，请参阅[此处](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connection-prereqs.html)。对于未列出的 AMI，请咨询 AMI 提供商。
|
||||
|
||||
### 安全组
|
||||
|
||||
选择默认安全组或配置安全组。
|
||||
|
||||
请参考[使用主机驱动时的 Amazon EC2 安全组](../../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#rancher-aws-ec2-安全组)，了解 `rancher-nodes` 安全组中创建的规则。
|
||||
|
||||
### EBS 根卷类型
|
||||
|
||||
用于根设备的 [EBS 卷类型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)。
|
||||
|
||||
### 加密 EBS 卷
|
||||
|
||||
启用 [Amazon EBS 加密](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)。
|
||||
|
||||
### 请求 Spot 实例
|
||||
|
||||
开启[请求 Spot 实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html)选项，并指定你愿意支付的最高实例价格（每小时）。
|
||||
|
||||
### 仅使用私有地址
|
||||
|
||||
启用仅使用[私人地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html)的选项。
|
||||
|
||||
### EBS 优化实例
|
||||
|
||||
使用 [EBS 优化实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html)。
|
||||
|
||||
### 允许访问 EC2 元数据
|
||||
|
||||
启用对 [EC2 元数据](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)的访问。
|
||||
|
||||
### 为元数据使用 Token
|
||||
|
||||
使用 [Instance Metadata Service Version 2 (IMDSv2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)，即基于令牌访问元数据的方法。
|
||||
|
||||
### 添加标签
|
||||
|
||||
使用[标签](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)添加元数据，从而对资源进行分类。
|
||||
|
||||
+120
@@ -0,0 +1,120 @@
|
||||
---
|
||||
title: Azure 主机配置
|
||||
---
|
||||
|
||||
有关 Azure 的更多信息，请参阅官方 [Azure 文档](https://docs.microsoft.com/en-us/azure/?product=featured)。
|
||||
|
||||
### 环境
|
||||
|
||||
Microsoft 提供了多个[云](https://docs.microsoft.com/en-us/cli/azure/cloud?view=azure-cli-latest)来满足地区法律的要求：
|
||||
|
||||
- AzurePublicCloud
|
||||
- AzureGermanCloud
|
||||
- AzureChinaCloud
|
||||
- AzureUSGovernmentCloud
|
||||
|
||||
### 位置
|
||||
|
||||
配置集群和节点的[位置](https://docs.microsoft.com/en-us/azure/virtual-machines/regions)。
|
||||
|
||||
### 资源组
|
||||
|
||||
资源组是一个容器，其中包含 Azure 解决方案的相关资源。资源组可以包括解决方案的所有资源，或者仅包括你希望作为一个组来管理的资源。你可以根据组织的需求来决定如何将资源分配给资源组。通常情况下，你可以将生命周期相同的资源添加到同一个资源组，以便轻松地按组进行部署、更新和删除。
|
||||
|
||||
你可以使用现有资源组，也可以输入资源组的名称，然后系统将为你创建一个资源组。
|
||||
|
||||
有关管理资源组的信息，请参阅 [Azure 文档](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal)。
|
||||
|
||||
### 可用性集（非托管）
|
||||
|
||||
要添加 VM 的现有[可用性集](https://docs.microsoft.com/en-us/azure/virtual-machines/availability-set-overview)的名称或 ID。
|
||||
|
||||
### 镜像
|
||||
|
||||
作为 ARM 资源标识符提供的操作系统镜像的名称。需要使用托管磁盘。
|
||||
|
||||
### 虚拟机大小
|
||||
|
||||
为节点池中的每个 VM 选择一个大小。有关每个 VM 大小的详细信息，请参阅[此页面](https://azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/)。
|
||||
|
||||
## 高级选项
|
||||
|
||||
### 容错域数量
|
||||
|
||||
容错域定义了共享公共电源和网络交换机的虚拟机组。如果可用性集已创建，将忽略容错域数量。
|
||||
|
||||
有关容错域的更多信息，请参阅[此处](https://docs.microsoft.com/en-us/azure/virtual-machines/availability-set-overview#how-do-availability-sets-work)。
|
||||
|
||||
### 更新域数量
|
||||
|
||||
更新域表示可以同时重新启动的虚拟机组和底层物理硬件。如果可用性集已创建，将忽略更新域数量。
|
||||
|
||||
有关更新域的更多信息，请参阅[此处](https://docs.microsoft.com/en-us/azure/virtual-machines/availability-set-overview#how-do-availability-sets-work)。
|
||||
|
||||
### 购买计划
|
||||
|
||||
Azure 市场中的某些 VM 镜像需要购买计划。如果适用，请为你选择的镜像选择格式为 `publisher:product:plan` 的购买计划。
|
||||
|
||||
### 子网
|
||||
|
||||
创建新 VNet 或引用现有 VNet 时的子网名称。
|
||||
|
||||
默认值：`docker-machine`
|
||||
|
||||
### 子网前缀
|
||||
|
||||
创建 CIDR 格式的新 VNet 时要使用的子网 IP 地址前缀。
|
||||
|
||||
默认值：`192.168.0.0/16`
|
||||
|
||||
### 虚拟网络
|
||||
|
||||
要使用或创建的[虚拟网络](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview)（如果不存在）。格式为 `[resourcegroup:]name`。
|
||||
|
||||
### 公共 IP 选项
|
||||
|
||||
#### 没有公共 IP
|
||||
|
||||
不要分配公共 IP 地址。
|
||||
|
||||
#### 静态公共 IP
|
||||
|
||||
分配静态公共 IP 地址。
|
||||
|
||||
### 使用私有 IP
|
||||
|
||||
使用静态私有 IP 地址。
|
||||
|
||||
### 私有 IP 地址
|
||||
|
||||
配置要使用的静态私有 IP 地址。
|
||||
|
||||
### 网络安全组
|
||||
|
||||
要使用的[网络安全组（NSG）](https://docs.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview)。使用此模板的所有节点都将使用配置的网络安全组。如果没有配置网络安全组，则为每个节点创建一个新的网络安全组。
|
||||
|
||||
### DNS 标签
|
||||
|
||||
公共 IP 地址的唯一 DNS 名称标签。
|
||||
|
||||
### 储存类型
|
||||
|
||||
用于 VM 的[存储账号](https://docs.microsoft.com/en-us/azure/storage/common/storage-account-overview)类型。可选项包括 Standard LRS、Standard ZRS、Standard GRS、Standard RAGRS 和 Premium LRS。
|
||||
|
||||
### 使用托管磁盘
|
||||
|
||||
[Azure 托管磁盘](https://docs.microsoft.com/en-us/azure/virtual-machines/managed-disks-overview)是由 Azure 管理并与 Azure Virtual Machines 一起使用的块级存储卷。托管磁盘旨在实现 99.999% 的高可用性。托管磁盘通过提供三个数据副本来实现高可用性和高持续性。
|
||||
|
||||
### 托管磁盘大小
|
||||
|
||||
每个节点的磁盘大小（以 GB 为单位）。
|
||||
|
||||
### SSH 用户名
|
||||
|
||||
用于 SSH 连接到节点的用户名。
|
||||
|
||||
### 开放端口
|
||||
|
||||
打开指定端口上的入站流量。如果你使用现有的网络安全组，将忽略开放端口。
|
||||
|
||||
默认值：`2379/tcp, 2380/tcp, 6443/tcp, 9796/tcp, 10250/tcp, 10251/tcp, 10252/tcp, 10256/tcp` 和 `8472/udp, 4789/udp`
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: DigitalOcean 主机配置
|
||||
---
|
||||
|
||||
有关 DigitalOcean、Droplet 的更多详细信息，请参阅[官方文档](https://docs.digitalocean.com/products/compute/)。
|
||||
|
||||
### 区域
|
||||
|
||||
配置创建 Droplet 的[区域](https://docs.digitalocean.com/products/app-platform/concepts/region/)。
|
||||
|
||||
### 大小
|
||||
|
||||
配置 Droplet 的[大小](https://docs.digitalocean.com/products/droplets/resources/choose-plan/)。
|
||||
|
||||
### 操作系统镜像
|
||||
|
||||
配置用于创建 Droplet 的操作系统[镜像](https://docs.digitalocean.com/products/images/)。
|
||||
|
||||
### Monitoring
|
||||
|
||||
启用 DigitalOcean 代理以进行额外的[监控](https://docs.digitalocean.com/products/monitoring/)。
|
||||
|
||||
### IPv6
|
||||
|
||||
为 Droplet 启用 IPv6。
|
||||
|
||||
### 私有网络
|
||||
|
||||
为 Droplet 启用私有网络。
|
||||
|
||||
### Droplet 标签
|
||||
|
||||
将标签（tag, label）应用于 Droplet。标签只能包含字母、数字、冒号、破折号和下划线。例如，`my_server`。
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: EC2 节点模板配置
|
||||
---
|
||||
|
||||
有关 EC2 和节点的更多详细信息，请参阅 [EC2 管理控制台](https://aws.amazon.com/ec2)的官方文档。
|
||||
|
||||
### 区域
|
||||
|
||||
在**区域**字段中，选择创建云凭证时使用的同一区域。
|
||||
|
||||
### 云凭证
|
||||
|
||||
你的 AWS 账户访问信息，存储在[云凭证](../../../user-settings/manage-cloud-credentials.md)中。
|
||||
|
||||
请参阅 [Amazon 文档：创建访问密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)来创建访问密钥和密文密钥。
|
||||
|
||||
请参阅 [Amazon 文档：创建 IAM 策略（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start)来创建 IAM 策略。
|
||||
|
||||
请参阅 [Amazon 文档：为用户添加权限（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)了解如何绑定 IAM。
|
||||
|
||||
参阅下面的三个示例 JSON 策略：
|
||||
|
||||
- [IAM 策略示例](../../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#iam-策略示例)
|
||||
- [带有 PassRole 的 IAM 策略示例](../../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#带有-passrole-的-iam-策略示例)（如果要使用 [Kubernetes 云提供商](../../../../pages-for-subheaders/set-up-cloud-providers.md)，或将 IAM 配置文件传递给实例，则需要）
|
||||
- [允许用户加密 EBS 卷的 IAM 策略示例](../../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#允许加密-ebs-卷的-iam-策略示例)
|
||||
|
||||
### 验证和配置节点
|
||||
|
||||
为集群选择可用区和网络设置。
|
||||
|
||||
### 安全组
|
||||
|
||||
选择默认安全组或配置安全组。
|
||||
|
||||
请参考[使用主机驱动时的 Amazon EC2 安全组](../../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#rancher-aws-ec2-安全组)，了解 `rancher-nodes` 安全组中创建的规则。
|
||||
|
||||
---
|
||||
**_v2.6.4 的新功能_**
|
||||
|
||||
如果你自行为 EC2 实例提供安全组，Rancher 不会对其进行修改。因此，你需要让你的安全组允许 [Rancher 配置实例所需的端口](../../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#rke-上-rancher-server-节点的端口)。有关使用安全组控制 EC2 实例的入站和出站流量的更多信息，请参阅[这里](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#WorkingWithSecurityGroups)。
|
||||
|
||||
### 实例选项
|
||||
|
||||
配置要创建的实例。确保为 AMI 配置正确的 **SSH 用户**。所选的区域可能不支持默认实例类型。在这种情况下，你必须选择一个确实存在的实例类型。否则将出现错误，表示请求的配置不受支持。
|
||||
|
||||
如果需要传递 **IAM 示例配置名称**（不是 ARN），例如要使用 [Kubernetes 云提供商](../../../../pages-for-subheaders/set-up-cloud-providers.md)时，策略则需要其他权限。有关示例策略，请参阅[带有 PassRole 的 IAM 策略示例](#带有-passrole-的-iam-策略示例)。
|
||||
|
||||
### 引擎选项
|
||||
|
||||
在节点模板的**引擎选项**中，你可以配置容器 daemon。你可能需要指定容器版本或容器镜像仓库 Mirror。
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: Azure 节点模板配置
|
||||
---
|
||||
|
||||
有关 Azure 的更多信息，请参阅官方 [Azure 文档](https://docs.microsoft.com/en-us/azure/?product=featured)。
|
||||
|
||||
账户访问信息存储在云凭证中。云凭证存储在 Kubernetes 密文中。多个节点模板可以使用相同的云凭证。你可以使用现有的云凭证或创建新的凭证。
|
||||
|
||||
- **Placement** 设置托管集群的地理区域以及其他位置元数据。
|
||||
- **Network** 配置集群中使用的网络。
|
||||
- **Instance** 自定义你的 VM 配置。
|
||||
|
||||
:::note
|
||||
|
||||
如果在与 VM 不同的资源组中使用 VNet，则 VNet 名称需要以资源组名称作为前缀。例如，`<resource group>:<vnet>`。
|
||||
|
||||
:::
|
||||
|
||||
如果你使用 Docker，[Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-daemon) 配置选项包括：
|
||||
|
||||
- **标签**：有关标签的信息，请参阅 [Docker 对象标签文档](https://docs.docker.com/config/labels-custom-metadata/)。
|
||||
- **Docker 引擎安装 URL**：确定要在实例上安装的 Docker 版本。
|
||||
|
||||
:::note
|
||||
|
||||
如果要配置 Red Hat Enterprise Linux (RHEL) 或 CentOS 节点，请将 **Docker Install URL** 字段保留为默认值，或选择 **none**。由于 Docker 已经安装在这些节点上，因此将绕过 Docker 安装检查。
|
||||
|
||||
如果没有将 **Docker Install URL** 设置为默认值或 **none**，你可能会看到错误消息：`Error creating machine: RHEL ssh command error: command: sudo -E yum install -y curl err: exit status 1 output: Updating Subscription Management repositories`。
|
||||
|
||||
:::
|
||||
|
||||
- **镜像仓库 mirror**：Docker daemon 使用的 Docker 镜像仓库镜像。
|
||||
- **其他高级选项**：参见 [Docker daemon 选项参考](https://docs.docker.com/engine/reference/commandline/dockerd/)。
|
||||
+18
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: DigitalOcean 节点模板配置
|
||||
---
|
||||
|
||||
账户访问信息存储在云凭证中。云凭证存储在 Kubernetes 密文中。多个节点模板可以使用相同的云凭证。你可以使用现有的云凭证或创建新的凭证。
|
||||
|
||||
### Droplet 选项
|
||||
|
||||
**Droplet 选项**用于配置集群的地理区域和规范。
|
||||
|
||||
### Docker Daemon
|
||||
|
||||
如果你使用 Docker，[Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-daemon) 配置选项包括：
|
||||
|
||||
- **标签**：有关标签的信息，请参阅 [Docker 对象标签文档](https://docs.docker.com/config/labels-custom-metadata/)。
|
||||
- **Docker 引擎安装 URL**：确定要在实例上安装的 Docker 版本。
|
||||
- **镜像仓库 mirror**：Docker daemon 使用的 Docker 镜像仓库镜像。
|
||||
- **其他高级选项**：参见 [Docker daemon 选项参考](https://docs.docker.com/engine/reference/commandline/dockerd/)。
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: Nutanix 节点模板配置
|
||||
---
|
||||
|
||||
## 账号访问
|
||||
|
||||
| 参数 | 必填 | 描述 | 默认 |
|
||||
|:-----------------------------|:--------:|:-----------------------------------------------------------------|:-----
|
||||
| 管理端点 | ✓ | Prism Central 的主机名/IP 地址 |
|
||||
| 用户名 | ✓ | Prism Central 用户的用户名 |
|
||||
| 密码 | ✓ | Prism Central 用户的密码 |
|
||||
| 允许不安全的通信 | | 设置为 true 以允许与 Prism Central 进行不安全的 SSL 通信 | False |
|
||||
|
||||
## 调度
|
||||
|
||||
选择虚拟机要调度到哪个 Nutanix 集群。
|
||||
|
||||
| 参数 | 必填 | 描述 |
|
||||
|:----------|:--------:|:----------------------------------------------------------------------------
|
||||
| 集群 | ✓ | 部署虚拟机的 Nutanix 集群的名称（区分大小写） |
|
||||
|
||||
## 实例选项
|
||||
|
||||
在**实例参数**中，配置此模板创建的 VM 的 vCPU 数量、内存和磁盘大小。
|
||||
|
||||
| 参数 | 必填 | 描述 | 默认 |
|
||||
|:---------------------|:--------:|:--------------------------------------------------------------------------------------------|:-------
|
||||
| CPU | | 分配给 VM 的 vCPU 数量（核心） | 2 |
|
||||
| 内存 | | 分配给 VM 的 RAM 量 (MB) | 2 GB |
|
||||
| Template Image | ✓ | 要作为虚拟机主磁盘进行克隆的磁盘镜像模板的名称（必须支持 cloud-init） |
|
||||
| 虚拟机磁盘大小 | | 虚拟机主磁盘的新大小（以 GiB 为单位） |
|
||||
| 其他磁盘大小 | | 要添加到虚拟机的其他磁盘的大小（以 GiB 为单位） |
|
||||
| 储存容器 | | 要配置其他磁盘的存储容器 _UUID_ |
|
||||
| Cloud Config YAML | | 要提供给虚拟机的 cloud-init（将使用 Rancher root 用户修补） |
|
||||
| 网络 | ✓ | 要附加到虚拟机的网络的名称 |
|
||||
| 虚拟机类别 | | 要应用于虚拟机的类别名称 |
|
||||
|
||||
虚拟机支持通过 [Config Drive v2 datasource](https://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html) 来支持 [cloud-init](https://cloudinit.readthedocs.io/en/latest/) 的任何现代 Linux 操作系统。
|
||||
|
||||
## 网络
|
||||
|
||||
节点模板允许你为虚拟机配置多个网络。在**网络**字段中，你可以单击**添加**，然后在 AOS 中添加任何可用的网络。
|
||||
|
||||
## 虚拟机类别
|
||||
|
||||
类别用于将实体分组成键值对。通常会根据某些标准为虚拟机分配一个类别。然后，你可以将策略绑定到分配（分组）了特定类别值的实体。
|
||||
|
||||
## cloud-init
|
||||
|
||||
[Cloud-init](https://cloudinit.readthedocs.io/en/latest/) 允许你在首次启动时应用配置，从而初始化节点。这可能涉及创建用户或授权 SSH 密钥之类的操作。
|
||||
|
||||
要使用 cloud-init 初始化，请将使用有效 YAML 语法的 cloud config 粘贴到 **Cloud Config YAML** 字段中。要获取支持的 cloud config 指令的注释示例集，请参阅 [cloud-init 文档](https://cloudinit.readthedocs.io/en/latest/topics/examples.html)。
|
||||
|
||||
不建议使用基于 cloud-init 的网络配置，仅支持使用用户数据 `runcmd`，不支持 NoCloud 或其他网络配置数据源。
|
||||
|
||||
建议使用 Nutanix IP Address Management（IPAM) 或其他 DHCP 服务。
|
||||
|
||||
## 引擎选项
|
||||
|
||||
在节点模板的**引擎选项**中，你可以配置容器 daemon。你可能需要指定容器版本或容器镜像仓库 Mirror。
|
||||
|
||||
:::note
|
||||
如果要配置 Red Hat Enterprise Linux (RHEL) 或 CentOS 节点，请将 **Docker Install URL** 字段保留为默认值，或选择 **none**。由于 Docker 已经安装在这些节点上，因此将绕过 Docker 安装检查。
|
||||
|
||||
如果没有将 **Docker Install URL** 设置为默认值或 **none**，你可能会看到错误消息：`Error creating machine: RHEL ssh command error: command: sudo -E yum install -y curl err: exit status 1 output: Updating Subscription Management repositories`。
|
||||
:::
|
||||
+95
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: vSphere 节点模板配置
|
||||
---
|
||||
|
||||
## 账号访问
|
||||
|
||||
| 参数 | 必填 | 描述 |
|
||||
|:----------------------|:--------:|:-----|
|
||||
| 云凭证 | * | 你的 vSphere 账号访问信息，存储在[云凭证](../../../user-settings/manage-cloud-credentials.md)中。 |
|
||||
|
||||
你的云凭证具有以下字段：
|
||||
|
||||
| 凭证字段 | 描述 |
|
||||
|-----------------|--------------|
|
||||
| vCenter 或 ESXi Server | 输入 vCenter 或 ESXi 主机名/IP。ESXi 是你创建和运行虚拟机和虚拟设备的虚拟化平台。你可以通过 vCenter Server 服务来管理网络中连接的多个主机并池化主机资源。 |
|
||||
| 端口 | 可选：配置 vCenter 或 ESXi Server 的端口。 |
|
||||
| 用户名和密码 | 你的 vSphere 登录用户名和密码。 |
|
||||
|
||||
## 调度
|
||||
|
||||
选择虚拟机要调度到哪个虚拟机监控程序。
|
||||
|
||||
**调度**中的字段应使用 vSphere 中可用的数据中心和其他计划选项自动填充。
|
||||
|
||||
| 字段 | 必填 | 解释 |
|
||||
|---------|---------------|-----------|
|
||||
| 数据中心 | * | 选择要调度 VM 的数据中心的名称/路径。 |
|
||||
| 资源池 | | 要在其中调度 VM 的资源池名称。资源池可对独立主机或集群的可用 CPU 和内存资源进行分区，也可以嵌套使用。如果是独立 ESXi，请留空。如果未指定，则使用默认资源池。 |
|
||||
| 数据存储 | * | 如果你有数据存储集群，则可以打开**数据存储**字段。此字段允许你选择要将 VM 调度到哪个数据存储集群。如果该字段未打开，你可以选择单个磁盘。 |
|
||||
| 文件夹 | | 数据中心中用于创建 VM 的文件夹的名称。必须已经存在。此下拉菜单中的 VM 文件夹直接对应于 vSphere 中的 VM 文件夹。在 vSphere 配置文件中，文件夹名称应以 `vm/` 开头。 |
|
||||
| 主机 | | 用于调度 VM 的主机系统的 IP。如果是独立 ESXi 或具有 DRS（分布式资源调度器）的集群，将此字段留空。如果指定，将使用主机系统的池，而忽略**资源池**参数。 |
|
||||
|
||||
## 实例选项
|
||||
|
||||
在**实例参数**中，配置此模板创建的 VM 的 vCPU 数量、内存和磁盘大小。
|
||||
|
||||
| 参数 | 必填 | 描述 |
|
||||
|:----------------|:--------:|:-----------|
|
||||
| CPU | * | 要分配给 VM 的 vCPU 数量。 |
|
||||
| 内存 | * | 要分配给 VM 的内存量。 |
|
||||
| 磁盘 | * | 要挂载到 VM 的磁盘大小（以 MB 为单位）。 |
|
||||
| 创建方法 | * | 在节点上设置操作系统的方法。可以使用 ISO 或 VM 模板安装操作系统。根据创建方法，你还必须指定 VM 模板、内容库、现有 VM 或 ISO。有关创建方法的详细信息，请参阅 [VM 创建方法](#vm-创建方法)。 |
|
||||
| Cloud Init | | `cloud-config.yml` 文件的 URL 或用于配置 VM 的 URL。此文件允许进一步定制操作系统，例如网络配置、DNS 服务器或系统守护程序。操作系统必须支持 `cloud-init`。 |
|
||||
| 网络 | | 要挂载 VM 的网络的名称。 |
|
||||
| guestinfo 配置参数 | | VM 的其他配置参数。这些参数对应 vSphere 控制台中的[高级设置](https://kb.vmware.com/s/article/1016098)。示例用例包括提供 RancherOS [guestinfo](https://rancher.com/docs/os/v1.x/en/installation/cloud/vmware-esxi/#vmware-guestinfo) 参数，或为 VM 启用磁盘 UUID (`disk.EnableUUID=TRUE`)。 |
|
||||
|
||||
|
||||
### VM 创建方法
|
||||
|
||||
在**创建方法**字段中，配置用于在 vSphere 中配置 VM 的方法。可用的选项包括创建从 RancherOS ISO 启动的 VM，或通过从现有虚拟机或 [VM 模板](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-F7BF0E6B-7C4F-4E46-8BBF-76229AEA7220.html)克隆来创建 VM。
|
||||
|
||||
现有 VM 或模板可以使用任何现代 Linux 操作系统，该操作系统配置为使用 [NoCloud 数据源](https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html)来支持 [cloud-init](https://cloudinit.readthedocs.io/en/latest/)。
|
||||
|
||||
选择创建 VM 的方式：
|
||||
|
||||
- **使用模板部署：数据中心**：选择存在于所选数据中心的 VM 模板。
|
||||
- **使用模板部署：内容库**：首先选择包含你的模板的[内容库](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-254B2CE8-20A8-43F0-90E8-3F6776C2C896.html)，然后从填充列表**库模板**中选择模板。
|
||||
- **克隆现有的虚拟机**：在**虚拟机**字段中选择一个现有虚拟机，新虚拟机将克隆自该虚拟机。
|
||||
- **使用 boot2docker ISO 安装**：确保 **OS ISO URL** 字段包含 RancherOS 的 VMware ISO 版本的 URL (`rancheros-vmware.iso`)。请注意，运行 Rancher Server 节点必须能访问该 URL。
|
||||
|
||||
## 网络
|
||||
|
||||
节点模板允许你为虚拟机配置多个网络。在**网络**字段中，你可以单击**添加网络**来添加 vSphere 中可用的任何网络。
|
||||
|
||||
## 节点标签和自定义属性
|
||||
|
||||
标签用于向 vSphere 对象清单中的对象添加元数据，以便对对象进行排序和搜索。
|
||||
|
||||
你的所有 vSphere 标签都将显示为节点模板中可供选择的选项。
|
||||
|
||||
在自定义属性中，Rancher 会让你选择你已经在 vSphere 中设置的所有自定义属性。自定义属性是键，你可以为每个属性输入值。
|
||||
|
||||
:::note
|
||||
|
||||
自定义属性是一项旧版功能，最终将从 vSphere 中删除。
|
||||
|
||||
:::
|
||||
|
||||
## cloud-init
|
||||
|
||||
[Cloud-init](https://cloudinit.readthedocs.io/en/latest/) 允许你在首次启动时应用配置，从而初始化节点。这可能涉及创建用户、授权 SSH 密钥或设置网络之类的操作。
|
||||
|
||||
要使用 cloud-init 初始化，请使用有效的 YAML 语法创建一个 cloud config 文件，并将文件内容粘贴到 **Cloud Init** 字段中。要获取支持的 cloud config 指令的注释示例集，请参阅 [cloud-init 文档](https://cloudinit.readthedocs.io/en/latest/topics/examples.html)。
|
||||
|
||||
请注意，使用 ISO 创建方法时不支持 cloud-init。
|
||||
|
||||
## 引擎选项
|
||||
|
||||
在节点模板的**引擎选项**中，你可以配置容器 daemon。你可能需要指定容器版本或容器镜像仓库 Mirror。
|
||||
|
||||
:::note
|
||||
如果要配置 Red Hat Enterprise Linux (RHEL) 或 CentOS 节点，请将 **Docker Install URL** 字段保留为默认值，或选择 **none**。由于 Docker 已经安装在这些节点上，因此将绕过 Docker 安装检查。
|
||||
|
||||
如果没有将 **Docker Install URL** 设置为默认值或 **none**，你可能会看到错误消息：`Error creating machine: RHEL ssh command error: command: sudo -E yum install -y curl err: exit status 1 output: Updating Subscription Management repositories`。
|
||||
:::
|
||||
+224
@@ -0,0 +1,224 @@
|
||||
---
|
||||
title: AKS 集群配置参考
|
||||
---
|
||||
|
||||
## Rancher 2.6 变更
|
||||
|
||||
- 支持添加多个节点池
|
||||
- 支持私有集群
|
||||
- 启用自动缩放节点池
|
||||
- 在云凭证中配置 AKS 权限
|
||||
|
||||
## RBAC
|
||||
|
||||
在 Rancher UI 中配置 AKS 集群时，无法禁用 RBAC。如果在 AKS 中为集群禁用了 RBAC，则无法在 Rancher 中注册或导入集群。
|
||||
|
||||
Rancher 可以使用与其他集群一样的方式为 AKS 集群配置成员角色。有关详细信息，请参阅 [RBAC](../../../pages-for-subheaders/manage-role-based-access-control-rbac.md)。
|
||||
|
||||
## 云凭证
|
||||
|
||||
:::note
|
||||
|
||||
本节中的配置信息假设你已经为 Rancher 设置了服务主体。有关如何设置服务主体的分步说明，请参阅[本节](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/aks.md#microsoft-azure-中的先决条件)。
|
||||
|
||||
:::
|
||||
|
||||
### 订阅 ID
|
||||
|
||||
要获取订阅 ID，请单击左侧导航栏中的 **All Services**。然后单击 **Subscriptions**。转到要与 Kubernetes 集群关联的订阅的名称，然后复制 **Subscription ID**。
|
||||
|
||||
### 客户端 ID
|
||||
|
||||
要获取客户端 ID，请转到 Azure 门户，然后单击 **Azure Active Directory**，单击 **App registrations**，然后单击服务主体的名称。客户端 ID 在 app registration 详细信息页面上列为 **Application (client) ID**。
|
||||
|
||||
### 客户端密码
|
||||
|
||||
在创建客户端密码值后，你无法再获取它的值。因此如果你还没有客户端密码值，则需要创建一个新的客户端密码。
|
||||
|
||||
要获取新的客户端密码，请转到 Azure 门户，然后单击 **Azure Active Directory**，单击 **App registrations**，然后单击服务主体的名称。
|
||||
|
||||
然后点击 **Certificates & secrets** 并点击 **New client secret**。单击 **Add**。然后复制新客户端密码的 **Value**。
|
||||
|
||||
### 环境
|
||||
|
||||
Microsoft 提供了多个[云](https://docs.microsoft.com/en-us/cli/azure/cloud?view=azure-cli-latest)来满足地区法律的要求：
|
||||
|
||||
- AzurePublicCloud
|
||||
- AzureGermanCloud
|
||||
- AzureChinaCloud
|
||||
- AzureUSGovernmentCloud
|
||||
|
||||
## 账号访问
|
||||
|
||||
在本部分中，你需要选择现有的 Azure 云凭证或创建一个新凭证。
|
||||
|
||||
有关配置 Azure 云凭证的帮助，请参阅[本部分](#云凭证)。
|
||||
|
||||
## 集群位置
|
||||
|
||||
配置集群和节点位置。有关 AKS 可用区的详细信息，请参阅 [AKS 文档](https://docs.microsoft.com/en-us/azure/aks/availability-zones)。
|
||||
|
||||
高可用性位置包括多个可用区。
|
||||
|
||||
## 集群选项
|
||||
|
||||
### Kubernetes 版本
|
||||
|
||||
可用的 Kubernetes 版本是从 Azure API 动态获取的。
|
||||
|
||||
### 集群资源组
|
||||
|
||||
资源组是一个容器，其中包含 Azure 解决方案的相关资源。资源组可以包括解决方案的所有资源，或者仅包括你希望作为一个组来管理的资源。你可以根据组织的需求来决定如何将资源分配给资源组。通常情况下，你可以将生命周期相同的资源添加到同一个资源组，以便轻松地按组进行部署、更新和删除。
|
||||
|
||||
你可以使用现有资源组，也可以输入资源组的名称，然后系统将为你创建一个资源组。
|
||||
|
||||
使用包含现有 AKS 集群的资源组将会创建一个新资源组。Azure AKS 仅允许每个资源组对应一个 AKS 集群。
|
||||
|
||||
有关管理资源组的信息，请参阅 [Azure 文档](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal)。
|
||||
|
||||
### Linux 管理员用户名
|
||||
|
||||
用于创建到 Linux 节点的 SSH 连接的用户名。
|
||||
|
||||
AKS 节点的默认用户名是 `azureuser`。
|
||||
|
||||
### SSH 公钥
|
||||
|
||||
用于创建到 Linux 节点的 SSH 连接的密钥。
|
||||
|
||||
### Tags
|
||||
|
||||
如果你的组织使用标签（Tag）来管理多个 Azure 服务的资源，那么集群标签则非常有用。这些标签不适用于集群内的资源。
|
||||
|
||||
## 网络选项
|
||||
|
||||
### 负载均衡器 SKU
|
||||
|
||||
Azure 负载均衡器支持 standard 和 basic SKU（stock keeping units）。
|
||||
|
||||
有关 standard 负载均衡器和 basic 负载均衡器的对比，请参阅官方 [Azure 文档](https://docs.microsoft.com/en-us/azure/load-balancer/skus#skus)。Microsoft 建议使用 standard 负载均衡器。
|
||||
|
||||
如果你选择了一个或多个可用区，或者你有多个节点池，则需要 Standard 负载均衡器。
|
||||
|
||||
### 网络策略
|
||||
|
||||
默认情况下，AKS 集群中的所有 Pod 都可以无限制地发送和接收流量。为了提高安全性，你可以定义控制流量的规则。Kubernetes 中的网络策略功能允许你定义集群中 pod 之间的入口和出口流量规则。
|
||||
|
||||
Azure 提供了两种实现网络策略的方法。创建 AKS 集群时会选择网络策略选项。创建集群后无法更改策略选项：
|
||||
|
||||
- Azure 自己的实现，称为 Azure 网络策略。Azure 网络策略需要 Azure CNI。
|
||||
- Calico Network Policies，一个由 [Tigera](https://www.tigera.io/) 创立的开源网络和网络安全解决方案。
|
||||
|
||||
你也可以选择不使用网络策略。
|
||||
|
||||
有关 Azure 和 Calico 网络策略及其功能之间的差异，请参阅 [AKS 文档](https://docs.microsoft.com/en-us/azure/aks/use-network-policies#differences-between-azure-and-calico-policies-and-their-capabilities)。
|
||||
|
||||
### DNS 前缀
|
||||
为集群的 Kubernetes API server FQDN 输入唯一的 DNS 前缀。
|
||||
|
||||
### 网络插件
|
||||
有两个网络插件，分别是 kubenet 和 Azure CNI。
|
||||
|
||||
[kubenet](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#kubenet) Kubernetes 插件是 AKS 创建的集群的默认配置。使用 kubenet 时，集群中的每个节点都会收到一个可路由的 IP 地址。Pod 使用 NAT 与 AKS 集群外部的其他资源进行通信。这种方法减少了需要在网络空间中保留以供 Pod 使用的 IP 地址数量。
|
||||
|
||||
如果使用 Azure CNI（高级）网络插件，Pod 可以使用完整的虚拟网络连接，并且可以从连接的网络中通过 pod 的私有 IP 地址直接访问。这个插件需要更多的 IP 地址空间。
|
||||
|
||||
有关 kubenet 和 Azure CNI 之间差异的详细信息，请参阅 [AKS 文档](https://docs.microsoft.com/en-us/azure/aks/concepts-network#compare-network-models)。
|
||||
|
||||
### HTTP 应用路由
|
||||
|
||||
启用后，HTTP 应用路由附加组件可以更轻松地访问部署到 AKS 集群的应用。它部署了两个组件，分别是 [Kubernetes Ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress/) 和 [External-DNS](https://github.com/kubernetes-incubator/external-dns) controller。
|
||||
|
||||
有关详细信息，请参阅 [AKS 文档](https://docs.microsoft.com/en-us/azure/aks/http-application-routing)。
|
||||
|
||||
### 设置授权 IP 范围
|
||||
|
||||
你可以使用[授权的 IP 地址范围](https://docs.microsoft.com/en-us/azure/aks/api-server-authorized-ip-ranges#overview-of-api-server-authorized-ip-ranges)来保护对 Kubernetes API server 的访问。
|
||||
|
||||
Kubernetes API server 公开 Kubernetes API。该组件提供管理工具（例如 kubectl）的交互。AKS 提供带有专用 API server 的单租户集群 controlplane。默认情况下，API server 分配了一个公共 IP 地址，你应该使用基于 Kubernetes 或 Azure 的 RBAC 来控制对 API server 的访问。
|
||||
|
||||
要保护对其他可公开的 AKS controlplane 和 API server 的访问，你可以启用并使用授权的 IP 范围。这些授权的 IP 范围只允许定义的 IP 地址范围与 API server 通信。
|
||||
|
||||
但是，即使你使用了授权的 IP 地址范围，你仍应使用 Kubernetes RBAC 或 Azure RBAC 来授权用户及其请求的操作。
|
||||
|
||||
### 容器监控
|
||||
|
||||
容器监控使用 Metrics API 从 Kubernetes 中可用的控制器、节点和容器中收集内存和处理器指标，从而为你可视化性能数据。容器日志也能被收集。启用监控后，系统会通过 Linux 的 Log Analytics 代理的容器化版本自动为你收集指标和日志。指标会被写入指标存储，而日志数据会被写入与你的 [Log Analytics](https://docs.microsoft.com/en-us/azure/azure-monitor/logs/log-query-overview) 工作区关联的日志存储。
|
||||
|
||||
### Log Analytics 工作区资源组
|
||||
|
||||
[资源组](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/overview#resource-groups)包含 Log Analytics 工作区。你必须至少创建一个工作区才能使用 Azure Monitor Logs。
|
||||
|
||||
### Log Analytics 工作区名称
|
||||
|
||||
Azure Monitor Logs 收集的数据存储在一个或多个 [Log Analytics 工作区中](https://docs.microsoft.com/en-us/azure/azure-monitor/logs/design-logs-deployment)。工作区定义了数据的地理位置、访问权限（定义了哪些用户可以访问数据）以及配置设置（定价层和数据保留等）。
|
||||
|
||||
你必须至少创建一个工作区才能使用 Azure Monitor Logs。一个工作区可能就足以满足你的所有监控数据。你也可以根据需求创建多个工作区。例如，你可能有一个工作区用于生产数据，另一个工作区用于测试。
|
||||
|
||||
有关 Azure Monitor Logs 的详细信息，请参阅 [Azure 文档](https://docs.microsoft.com/en-us/azure/azure-monitor/logs/data-platform-logs)。
|
||||
|
||||
### 支持私有 Kubernetes 服务
|
||||
|
||||
通常情况下，无论集群是否为私有，AKS worker 节点都不会获得公共 IP。在私有集群中，controlplane 没有公共端点。
|
||||
|
||||
Rancher 可以通过以下两种方式之一连接到私有 AKS 集群。
|
||||
|
||||
第一种方法是确保 Rancher 运行在与 AKS 节点相同的 [NAT](https://docs.microsoft.com/en-us/azure/virtual-network/nat-overview) 上。
|
||||
|
||||
第二种方法是运行命令向 Rancher 注册集群。配置集群后，你可以在任何能连接到集群的 Kubernetes API 的地方运行显示的命令。配置启用了私有 API 端点的 AKS 集群时，此命令将显示在弹出窗口中。
|
||||
|
||||
:::note
|
||||
|
||||
注册现有 AKS 集群时，集群可能需要一些时间（可能是数小时）才会出现在 `Cluster To register` 下拉列表中。不同区域的结果可能不同。
|
||||
|
||||
:::
|
||||
|
||||
有关连接到 AKS 专用集群的详细信息，请参阅 [AKS 文档](https://docs.microsoft.com/en-us/azure/aks/private-clusters#options-for-connecting-to-the-private-cluster)。
|
||||
|
||||
## 节点池
|
||||
|
||||
### 模式
|
||||
|
||||
在 Azure 界面中，用户能够指定主要节点池（Primary Node Pool）依赖于 `system`（通常用于 controlplane）还是 `user`（Rancher 最常用的）。
|
||||
|
||||
你可以指定主要节点池（Primary Node Pool）的模式、操作系统、数量和大小。
|
||||
|
||||
`system` 节点池总是需要运行节点，因此它们不能缩容到一个节点以下。至少需要一个 `system` 节点池。
|
||||
|
||||
对于后续的节点池，Rancher UI 强制使用默认的 `user`。`user` 节点池允许缩容到零节点。`user` 节点池不运行 Kubernetes controlplane 的任何部分。
|
||||
|
||||
AKS 不会公开运行 Kubernetes controlplane 组件的节点。
|
||||
|
||||
### 可用区
|
||||
|
||||
[可用区](https://docs.microsoft.com/en-us/azure/availability-zones/az-overview)是区域内的唯一物理位置。每个可用区由一个或多个配备独立电源、冷却系统和网络的数据中心组成。
|
||||
|
||||
并非所有区域都支持可用区。有关具有可用区的 Azure 区域列表，请参阅 [Azure 文档](https://docs.microsoft.com/en-us/azure/availability-zones/az-region#azure-regions-with-availability-zones)。
|
||||
|
||||
### 虚拟机大小
|
||||
|
||||
为节点池中的每个 VM 选择一个大小。有关每个 VM 大小的详细信息，请参阅[此页面](https://azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/)。
|
||||
|
||||
### 操作系统磁盘类型
|
||||
|
||||
节点池中的节点可以使用托管磁盘或临时磁盘。
|
||||
|
||||
[临时 OS 磁盘](https://docs.microsoft.com/en-us/azure/virtual-machines/ephemeral-os-disks)在本地虚拟机存储上创建，并不会保存到远程 Azure 存储。临时 OS 磁盘适用于无状态工作负载，其中的应用可以容忍单个 VM 故障，但更容易受 VM 部署时间或重置单个虚拟机实例镜像的影响。使用临时 OS 磁盘，你可以体验更低的 OS 磁盘读/写延迟和更快的 VM 重置镜像过程。
|
||||
|
||||
[Azure 托管磁盘](https://docs.microsoft.com/en-us/azure/virtual-machines/managed-disks-overview)是由 Azure 管理并与 Azure Virtual Machines 一起使用的块级存储卷。托管磁盘旨在实现 99.999% 的高可用性。托管磁盘通过提供三个数据副本来实现高可用性和高持续性。
|
||||
|
||||
### 操作系统磁盘大小
|
||||
|
||||
每个节点的磁盘大小（以 GB 为单位）。
|
||||
|
||||
### 节点数
|
||||
节点池中的节点数。[Azure 订阅](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits)可能会限制最大节点数。
|
||||
|
||||
### 每个节点的最大 Pod 数量
|
||||
每个节点的最大 Pod 数量默认为 110，最大为 250。
|
||||
|
||||
### 启用自动扩缩容
|
||||
|
||||
启用自动扩缩容后，你需要输入最小和最大节点数。
|
||||
|
||||
启用 Auto Scaling 后，你将无法手动对节点池进行扩缩容。扩缩容由 AKS autoscaler 控制。
|
||||
+149
@@ -0,0 +1,149 @@
|
||||
---
|
||||
title: EKS 集群配置参考
|
||||
---
|
||||
|
||||
### 账号访问
|
||||
|
||||
使用获取的信息为 IAM 策略填写每个下拉列表和字段：
|
||||
|
||||
| 设置 | 描述 |
|
||||
| ---------- | -------------------------------------------------------------------------------------------------------------------- |
|
||||
| 区域 | 从下拉列表中选择构建集群的地理区域。 |
|
||||
| 云凭证 | 选择为 IAM 策略创建的云凭证。有关在 Rancher 中创建云凭证的更多信息，请参阅[此页面](../../user-settings/manage-cloud-credentials.md)。 |
|
||||
|
||||
### 服务角色
|
||||
|
||||
选择一个[服务角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)。
|
||||
|
||||
| 服务角色 | 描述 |
|
||||
-------------|---------------------------
|
||||
| Standard：Rancher 生成的服务角色 | 如果选择此角色，Rancher 会自动添加一个服务角色以供集群使用。 |
|
||||
| 自定义：从现有的服务角色中选择 | 如果选择此角色，Rancher 将允许你从已在 AWS 中创建的服务角色中进行选择。有关在 AWS 中创建自定义服务角色的更多信息，请参阅 [Amazon 文档](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)。 |
|
||||
|
||||
### 密文加密
|
||||
|
||||
可选：要加密密文，请选择或输入在 [AWS 密钥管理服务 (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) 中创建的密钥。
|
||||
|
||||
### API Server 端点访问
|
||||
|
||||
配置公共/私有 API 访问是一个高级用例。有关详细信息，请参阅 [EKS 集群端点访问控制文档](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html)。
|
||||
|
||||
### 专用 API 端点
|
||||
|
||||
如果你在创建集群时启用了私有 API 端点访问，并禁用了公共 API 端点访问，那么你必须进行额外的步骤才能使 Rancher 成功连接到集群。在这种情况下，一个弹窗将会显示，其中包含需要在要注册到 Rancher 的集群上运行的命令。配置集群后，你可以在任何能连接到集群的 Kubernetes API 的地方运行显示的命令。
|
||||
|
||||
以下两种方法能避免这个额外的手动步骤：
|
||||
- 在创建集群时，创建具有私有和公共 API 端点访问权限的集群。在集群创建并处于 active 状态后，你可以禁用公共访问，Rancher 将能继续与 EKS 集群通信。
|
||||
- 确保 Rancher 与 EKS 集群共享同一个子网。然后，你可以使用安全组使 Rancher 能够与集群的 API 端点进行通信。在这种情况下，你不需要运行注册集群的命令，Rancher 就能够与你的集群通信。有关配置安全组的更多信息，请参阅[安全组文档](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)。
|
||||
|
||||
### 公共访问端点
|
||||
|
||||
你也可以选择通过显式 CIDR 块来限制对公共端点的访问。
|
||||
|
||||
如果你限制对特定 CIDR 块的访问，那么建议你也启用私有访问，以避免丢失与集群的网络通信。
|
||||
|
||||
启用私有访问需要满足以下条件之一：
|
||||
- Rancher 的 IP 必须是允许的 CIDR 块的一部分。
|
||||
- 应该启用了私有访问。此外，Rancher 必须和集群共享同一个子网，并对集群有网络访问权限。你可以通过安全组来进行配置。
|
||||
|
||||
有关对集群端点的公共和私有访问的更多信息，请参阅 [Amazon EKS 文档](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html)。
|
||||
|
||||
### 子网
|
||||
|
||||
| 选项 | 描述 |
|
||||
| ------- | ------------ |
|
||||
| Standard：Rancher 生成的 VPC 和子网 | 在配置集群时，Rancher 会生成一个具有 3 个公有子网的新 VPC。 |
|
||||
| 自定义：从现有的 VPC 和子网中选择 | 在配置集群时，Rancher 将你的 controlplane 和节点配置为使用你已经[在 AWS 中创建](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)的 VPC 和子网。 |
|
||||
|
||||
有关更多信息，请参阅 AWS 文档以了解[集群 VPC 注意事项](https://docs.aws.amazon.com/eks/latest/userguide/network_reqs.html)。根据你在上一步中的选择，按照以下说明进行操作。
|
||||
|
||||
- [什么是 Amazon VPC？](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
|
||||
- [VPC 和子网](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html)
|
||||
|
||||
### 安全组
|
||||
|
||||
Amazon 文档：
|
||||
|
||||
- [集群安全组注意事项](https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html)
|
||||
- [VPC 的安全组](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)
|
||||
- [创建安全组](https://docs.aws.amazon.com/vpc/latest/userguide/getting-started-ipv4.html#getting-started-create-security-group)
|
||||
|
||||
### Logging
|
||||
|
||||
将 controlplane 日志配置为发送到 Amazon CloudWatch。如果你将集群日志发送到 CloudWatch Logs，你需要按照 standard CloudWatch Logs 支付数据引入和存储费用。
|
||||
|
||||
每个日志类型均对应一个 Kubernetes controlplane 组件。有关这些组件的更多信息，请参阅 Kubernetes 文档中的 [Kubernetes 组件](https://kubernetes.io/docs/concepts/overview/components/)。
|
||||
|
||||
有关 EKS controlplane 日志管理的更多信息，请参阅[官方文档](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)。
|
||||
|
||||
### 托管节点组
|
||||
|
||||
Amazon EKS 托管的节点组自动为 Amazon EKS Kubernetes 集群的节点（Amazon EC2 实例）进行预置和生命周期管理。
|
||||
|
||||
有关节点组如何工作以及如何配置的更多信息，请参阅 [EKS 文档](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)。
|
||||
|
||||
#### 使用你自己的启动模板
|
||||
|
||||
你可以提供启动模板 ID 和版本，以便轻松配置节点组中的 EC2 实例。如果你提供了启动模板，则以下设置都无法在 Rancher 中进行配置。因此，如果你使用启动模板，则需要在启动模板中指定以下列表中的所有必须和所需的设置。另请注意，如果提供了启动模板 ID 和版本，则只能更新模板版本。如果要使用新模板 ID，则需要创建新的托管节点组。
|
||||
|
||||
| 选项 | 描述 | 必填/选填 |
|
||||
| ------ | ----------- | ----------------- |
|
||||
| 实例类型 | 为要配置的实例选择[硬件规格](https://aws.amazon.com/ec2/instance-types/)。 | 必填 |
|
||||
| 镜像 ID | 为节点指定自定义 AMI。与 EKS 一起使用的自定义 AMI 必须[正确配置](https://aws.amazon.com/premiumsupport/knowledge-center/eks-custom-linux-ami/)。 | 选填 |
|
||||
| 节点卷大小 | 启动模板必须指定具有所需大小的 EBS 卷。 | 必填 |
|
||||
| SSH 密钥 | 要添加到实例以对节点进行 SSH 访问的密钥。 | 选填 |
|
||||
| 用户数据 | [MIME 多部分格式](https://docs.aws.amazon.com/eks/latest/userguide/launch-templates.html#launch-template-user-data)的 Cloud init 脚本。 | 选填 |
|
||||
| 实例资源标签 | 标记节点组中的每个 EC2 实例。 | 选填 |
|
||||
|
||||
#### Rancher 管理的启动模板
|
||||
|
||||
如果你不指定启动模板，你将能够在 Rancher UI 中配置上述选项，并且可以在创建后更新所有这些选项。为了利用所有这些选项，Rancher 将为你创建和管理启动模板。Rancher 中的所有集群都将有一个 Rancher 管理的启动模板。此外，每个没有指定启动模板的托管节点组都将具有一个管理的启动模板版本。此启动模板的名称将具有 “rancher-managed-lt-” 前缀，后面是集群的显示名称。此外，Rancher 管理的启动模板将使用 “rancher-managed-template” 键和 “do-not-modify-or-delete” 值来进行标记，以将其识别为 Rancher 管理的启动模板。请注意，不要修改或删除此启动模板，或将此启动模板与其他集群或托管节点组一起使用。因为这可能会使你的节点组“降级”并需要销毁和重新创建。
|
||||
|
||||
#### 自定义 AMI
|
||||
|
||||
如果你在启动模板或 Rancher 中指定了自定义 AMI，则必须[正确配置](https://aws.amazon.com/premiumsupport/knowledge-center/eks-custom-linux-ami/)镜像，并且必须提供用户数据以[引导节点](https://docs.aws.amazon.com/eks/latest/userguide/launch-templates.html#launch-template-custom-ami)。这是一个高级用例，因此你必须要了解其要求。
|
||||
|
||||
如果你指定了不包含自定义 AMI 的启动模板，则 Amazon 将为 Kubernetes 版本和所选区域使用 [EKS 优化的 AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html)。你还可以为能从中受益的工作负载选择[启用 GPU 的实例](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html#gpu-ami)。
|
||||
|
||||
:::note
|
||||
|
||||
如果你在下拉菜单或启动模板中提供了自定义 AMI，则会忽略 Rancher 中设置的启用 GPU 的实例。
|
||||
|
||||
:::
|
||||
|
||||
#### Spot 实例
|
||||
|
||||
Spot 实例现在[受 EKS 支持](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html#managed-node-group-capacity-types-spot)。如果你指定了启动模板，Amazon 建议不要在模板中提供实例类型。相反，Amazon 建议提供多种实例类型。如果你为节点组启用了“请求 Spot 实例”复选框，那么你将有机会提供多种实例类型。
|
||||
|
||||
:::note
|
||||
|
||||
在这种情况下，你在实例类型下拉列表中所选的选项都将被忽略，你必须在“Spot 实例类型”中至少指定一种实例类型。此外，与 EKS 一起使用的启动模板无法请求 Spot 实例。请求 Spot 实例必须是 EKS 配置的一部分。
|
||||
|
||||
:::
|
||||
|
||||
#### 节点组设置
|
||||
|
||||
以下设置也是可配置的。在创建节点组后，除“节点组名称”外的所有选项都是可编辑的。
|
||||
|
||||
| 选项 | 描述 |
|
||||
| ------- | ------------ |
|
||||
| 节点组名称 | 节点组的名称。 |
|
||||
| 期望 ASG 大小 | 期望的实例数量。 |
|
||||
| 最大 ASG 大小 | 最大的实例数量。在安装 [Cluster Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html) 之前，此设置不会生效。 |
|
||||
| 最小 ASG 大小 | 最小的实例数量。在安装 [Cluster Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html) 之前，此设置不会生效。 |
|
||||
| Labels | 应用于管理的节点组中节点的 Kubernetes 标签。 |
|
||||
| Tags | 管理的节点组的标签，这些标签不会传播到任何相关资源。 |
|
||||
|
||||
|
||||
### 配置刷新间隔
|
||||
|
||||
`eks-refresh-cron` 设置已弃用。它已迁移到 `eks-refresh` 设置，这是一个表示秒的整数。
|
||||
|
||||
默认值为 300 秒。
|
||||
|
||||
你可以通过运行 `kubectl edit setting eks-refresh` 来更改同步间隔。
|
||||
|
||||
如果之前设置了 `eks-refresh-cron` 设置，迁移将自动进行。
|
||||
|
||||
刷新窗口越短，争用条件发生的可能性就越小。但这确实增加了遇到 AWS API 可能存在的请求限制的可能性。
|
||||
|
||||
+49
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: 私有集群
|
||||
---
|
||||
|
||||
在 GKE 中，[私有集群](https://cloud.google.com/kubernetes-engine/docs/concepts/private-cluster-concept)是一种集群，其节点仅通过分配内部 IP 地址与入站和出站流量相隔离。GKE 中的私有集群可以选择将 controlplane 端点作为公开访问的地址或作为私有地址。这与其他 Kubernetes 提供商不同，后者可能将具有私有 controlplane 端点的集群称为“私有集群”，但仍允许进出节点的流量。基于你的组织的网络和安全要求，你可能想创建一个有私有节点的集群，其中有或没有公共 controlplane 端点。从 Rancher 配置的 GKE 集群可以通过在**集群选项**中选择**私有集群**（在**显示高级选项**下）来使用隔离的节点。通过选择**启用私有端点**，可以选择将 controlplane 端点设为私有。
|
||||
|
||||
### 私有节点
|
||||
|
||||
由于私有集群中的节点只有内部 IP 地址，它们将无法安装 cluster agent，Rancher 将无法完全管理集群。这可以通过几种方式来处理。
|
||||
|
||||
#### Cloud NAT
|
||||
|
||||
:::caution
|
||||
|
||||
Cloud NAT 将[产生费用](https://cloud.google.com/nat/pricing)。
|
||||
|
||||
:::
|
||||
|
||||
如果限制外出的互联网访问对你的组织来说不是一个问题，可以使用 Google 的 [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) 服务来允许私有网络中的节点访问互联网，使它们能够从 Dockerhub 下载所需的镜像并与 Rancher management server 通信。这是最简单的解决方案。
|
||||
|
||||
#### 私有镜像仓库
|
||||
|
||||
:::caution
|
||||
|
||||
此方案不受官方支持。如果 Cloud NAT 服务不足以满足你的需求，则可以参考此方案。
|
||||
|
||||
:::
|
||||
|
||||
如果要求限制节点的传入和传出流量，请按照离线安装说明，在集群所在的 VPC 上设置一个私有容器[镜像仓库](https://rancher.com/docs/rancher/v2.6/en/installation/other-installation-methods/air-gap/)，从而允许集群节点访问和下载运行 cluster agent 所需的镜像。如果 controlplane 端点也是私有的，Rancher 将需要[直接访问](#直接访问)它。
|
||||
|
||||
### 私有 controlplane 端点
|
||||
|
||||
如果集群暴露了公共端点，Rancher 将能够访问集群，且无需执行额外的步骤。但是，如果集群没有公共端点，则必须确保 Rancher 可以访问集群。
|
||||
|
||||
#### Cloud NAT
|
||||
|
||||
:::caution
|
||||
|
||||
Cloud NAT 将[产生费用](https://cloud.google.com/nat/pricing)。
|
||||
|
||||
:::
|
||||
|
||||
如上所述，如果不考虑限制对节点的传出互联网访问，则可以使用 Google 的 [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) 服务来允许节点访问互联网。当集群进行配置时，Rancher 将提供一个在集群上运行的注册命令。下载新集群的 [kubeconfig](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl) 并在集群上运行提供的 kubectl 命令。如果要通过获取集群访问权来运行此命令，你可以创建临时节点或使用 VPC 中的现有节点，或者登录到某个集群节点或使用某个集群节点创建 SSH 隧道。
|
||||
|
||||
#### 直接访问
|
||||
|
||||
如果 Rancher server 与集群的 controlplane 运行在同一 VPC 上，它将直接访问 controlplane 的私有端点。集群节点将需要访问[私有镜像仓库](#私有镜像仓库)以下载上述的镜像。
|
||||
|
||||
你还可以使用 Google 的服务（例如 [Cloud VPN](https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview) 或 [Cloud Interconnect VLAN](https://cloud.google.com/network-connectivity/docs/interconnect)）来促进组织网络与 Google VPC 之间的连接。
|
||||
+145
@@ -0,0 +1,145 @@
|
||||
---
|
||||
title: K3s 集群配置参考
|
||||
---
|
||||
|
||||
本文介绍 Rancher 中可用于新的或现有的 K3s Kubernetes 集群的配置选项。
|
||||
|
||||
## 概述
|
||||
|
||||
你可以通过以下两种方式之一来配置 Kubernetes 选项：
|
||||
|
||||
- [Rancher UI](#rancher-ui-中的配置选项)：使用 Rancher UI 来选择设置 Kubernetes 集群时常用的自定义选项。
|
||||
- [集群配置文件](#集群配置文件)：高级用户可以创建一个 K3s 配置文件，而不是使用 Rancher UI 来为集群选择 Kubernetes 选项。配置文件允许你设置 K3s 安装中可用的任何[选项](https://rancher.com/docs/k3s/latest/en/installation/install-options/)。
|
||||
|
||||
## Rancher UI 中的配置选项
|
||||
|
||||
:::tip
|
||||
|
||||
一些高级配置选项没有在 Rancher UI 表单中开放，但你可以通过在 YAML 中编辑 K3s 集群配置文件来启用这些选项。有关 YAML 中 K3s 集群的可配置选项的完整参考，请参阅 [K3s 文档](https://rancher.com/docs/k3s/latest/en/installation/install-options/)。
|
||||
|
||||
:::
|
||||
|
||||
### 基本信息
|
||||
#### Kubernetes 版本
|
||||
|
||||
这指的是集群节点上安装的 Kubernetes 版本。Rancher 基于 [hyperkube](https://github.com/rancher/hyperkube) 打包了自己的 Kubernetes 版本。
|
||||
|
||||
有关更多详细信息，请参阅[升级 Kubernetes](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)。
|
||||
|
||||
#### 加密密文
|
||||
|
||||
启用或禁用密文加密的选项。启用后，密文将使用 AES-CBC 密钥进行加密。如果禁用，则在再次启用加密之前无法读取任何以前的密文。有关详细信息，请参阅 [K3s 文档](https://rancher.com/docs/k3s/latest/en/advanced/#secrets-encryption-config-experimental)。
|
||||
|
||||
#### 项目网络隔离
|
||||
|
||||
如果你的网络提供商允许项目网络隔离，你可以选择启用或禁用项目间的通信。
|
||||
|
||||
#### SELinux
|
||||
|
||||
启用或禁用 [SELinux](https://rancher.com/docs/k3s/latest/en/advanced/#selinux-support) 支持的选项。
|
||||
|
||||
#### CoreDNS
|
||||
|
||||
默认情况下，[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS，则必须自己安装备用 DNS 提供程序。有关详细信息，请参阅 [K3s 文档](https://rancher.com/docs/k3s/latest/en/networking/#coredns)。
|
||||
|
||||
#### Klipper Service LB
|
||||
|
||||
启用或禁用 [Klipper](https://github.com/rancher/klipper-lb) 服务负载均衡器的选项。有关详细信息，请参阅 [K3s 文档](https://rancher.com/docs/k3s/latest/en/networking/#service-load-balancer)。
|
||||
|
||||
#### Traefik Ingress
|
||||
|
||||
启用或禁用 [Traefik](https://traefik.io/) HTTP 反向代理和负载均衡器的选项。有关更多详细信息和配置选项，请参阅 [K3s 文档](https://rancher.com/docs/k3s/latest/en/networking/#traefik-ingress-controller)。
|
||||
|
||||
#### Local Storage
|
||||
|
||||
在节点上启用或禁用 [Local Storage](https://rancher.com/docs/k3s/latest/en/storage/) 的选项。
|
||||
|
||||
#### Metrics Server
|
||||
|
||||
启用或禁用 [metrics server](https://github.com/kubernetes-incubator/metrics-server) 的选项。如果启用，请确保为入站 TCP 流量打开 10250 端口。
|
||||
|
||||
### 附加配置
|
||||
|
||||
集群启动时将应用的其他 Kubernetes 清单，会作为[附加组件](https://kubernetes.io/docs/concepts/cluster-administration/addons/)来管理。有关详细信息，请参阅 [K3s 文档](https://rancher.com/docs/k3s/latest/en/helm/#automatically-deploying-manifests-and-helm-charts)。
|
||||
|
||||
### Agent 环境变量
|
||||
|
||||
为 [K3s agent](https://rancher.com/docs/k3s/latest/en/architecture/) 设置环境变量的选项。你可以使用键值对设置环境变量。有关详细信息，请参阅 [K3s 文档](https://rancher.com/docs/k3s/latest/en/installation/install-options/agent-config/)。
|
||||
|
||||
### etcd
|
||||
|
||||
#### 自动快照
|
||||
|
||||
启用或禁用定期 etcd 快照的选项。如果启用，用户可以配置快照的频率。有关详细信息，请参阅 [K3s 文档](https://rancher.com/docs/k3s/latest/en/backup-restore/#creating-snapshots)。
|
||||
|
||||
#### 指标
|
||||
|
||||
选择向公众公开或仅在集群内公开 etcd 指标的选项。
|
||||
|
||||
### 网络
|
||||
|
||||
#### 集群 CIDR
|
||||
|
||||
用于 pod IP 的 IPv4/IPv6 网络 CIDR（默认：10.42.0.0/16）。
|
||||
|
||||
#### Service CIDR
|
||||
|
||||
用于 Service IP 的 IPv4/IPv6 网络 CIDR（默认：10.43.0.0/16）。
|
||||
|
||||
#### 集群 DNS
|
||||
|
||||
用于 coredns 服务的 IPv4 集群 IP。应该在你的 service-cidr 范围内（默认：10.43.0.10）。
|
||||
|
||||
#### 集群域名
|
||||
|
||||
选择集群的域。默认值为 `cluster.local`。
|
||||
|
||||
#### NodePort 服务端口范围
|
||||
|
||||
更改可用于 [NodePort 服务](https://kubernetes.io/docs/concepts/services-networking/service/#nodeport)的端口范围的选项。默认值为 `30000-32767`。
|
||||
|
||||
#### TLS 可选名称
|
||||
|
||||
在服务器 TLS 证书上添加其他主机名或 IPv4/IPv6 地址作为 Subject Alternative Name。
|
||||
|
||||
#### 授权集群端点
|
||||
|
||||
授权集群端点（ACE）可用于直接访问 Kubernetes API server，而无需通过 Rancher 进行通信。
|
||||
|
||||
有关授权集群端点的工作原理以及使用的原因，请参阅[架构介绍](../../../pages-for-subheaders/rancher-manager-architecture.md#4-授权集群端点)。
|
||||
|
||||
我们建议使用具有授权集群端点的负载均衡器。有关详细信息，请参阅[推荐的架构](../../rancher-manager-architecture/architecture-recommendations.md#授权集群端点架构)。
|
||||
|
||||
### 镜像仓库
|
||||
|
||||
选择要从中拉取 Rancher 镜像的镜像仓库。有关更多详细信息和配置选项，请参阅 [K3s 文档](https://rancher.com/docs/k3s/latest/en/installation/private-registry/)。
|
||||
|
||||
### 升级策略
|
||||
|
||||
#### controlplane 并发
|
||||
|
||||
选择可以同时升级多少个节点。可以是固定数字或百分比。
|
||||
|
||||
#### Worker 并发
|
||||
|
||||
选择可以同时升级多少个节点。可以是固定数字或百分比。
|
||||
|
||||
#### 清空节点（controlplane）
|
||||
|
||||
在升级之前从节点中删除所有 pod 的选项。
|
||||
|
||||
#### 清空节点（worker 节点）
|
||||
|
||||
在升级之前从节点中删除所有 pod 的选项。
|
||||
|
||||
### 高级配置
|
||||
|
||||
为不同节点设置 kubelet 选项。有关可用选项，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)。
|
||||
|
||||
## 集群配置文件
|
||||
|
||||
高级用户可以创建一个 K3s 配置文件，而不是使用 Rancher UI 表单来为集群选择 Kubernetes 选项。配置文件允许你设置 K3s 安装中可用的任何[选项](https://rancher.com/docs/k3s/latest/en/installation/install-options/)。
|
||||
|
||||
要直接从 Rancher UI 编辑 K3s 配置文件，单击**以 YAML 文件编辑**。
|
||||
|
||||
|
||||
+344
@@ -0,0 +1,344 @@
|
||||
---
|
||||
title: RKE 集群配置参考
|
||||
---
|
||||
|
||||
Rancher 安装 Kubernetes 时，它使用 [RKE](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 或 [RKE2](https://docs.rke2.io/) 作为 Kubernetes 发行版。
|
||||
|
||||
本文介绍 Rancher 中可用于新的或现有的 RKE Kubernetes 集群的配置选项。
|
||||
|
||||
|
||||
## 概述
|
||||
|
||||
你可以通过以下两种方式之一来配置 Kubernetes 选项：
|
||||
|
||||
- [Rancher UI](#rancher-ui-中的配置选项)：使用 Rancher UI 来选择设置 Kubernetes 集群时常用的自定义选项。
|
||||
- [集群配置文件](#rke-集群配置文件参考)：高级用户可以创建一个 RKE 配置文件，而不是使用 Rancher UI 来为集群选择 Kubernetes 选项。配置文件可以让你使用 YAML 来指定 RKE 安装中可用的任何选项（除了 system_images 配置）。
|
||||
|
||||
RKE 集群配置选项嵌套在 `rancher_kubernetes_engine_config` 参数下。有关详细信息，请参阅[集群配置文件](#rke-集群配置文件参考)。
|
||||
|
||||
在 [RKE 启动的集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)中，你可以编辑任何后续剩余的选项。
|
||||
|
||||
有关 RKE 配置文件语法的示例，请参阅 [RKE 文档](https://rancher.com/docs/rke/latest/en/example-yamls/)。
|
||||
|
||||
Rancher UI 中的表单不包括配置 RKE 的所有高级选项。有关 YAML 中 RKE Kubernetes 集群的可配置选项的完整参考，请参阅 [RKE 文档](https://rancher.com/docs/rke/latest/en/config-options/)。
|
||||
|
||||
## 在 Rancher UI 中使用表单编辑集群
|
||||
|
||||
要编辑你的集群：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置的集群，然后单击 **⋮ > 编辑配置**。
|
||||
|
||||
|
||||
## 使用 YAML 编辑集群
|
||||
|
||||
高级用户可以创建一个 RKE 配置文件，而不是使用 Rancher UI 来为集群选择 Kubernetes 选项。配置文件可以让你使用 YAML 来指定 RKE 安装中可用的任何选项（除了 system_images 配置）。
|
||||
|
||||
RKE 集群（也称为 RKE1 集群）的编辑方式与 RKE2 和 K3s 集群不同。
|
||||
|
||||
要直接从 Rancher UI 编辑 RKE 配置文件：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到要配置的 RKE 集群。单击并单击 **⋮ > 编辑配置**。你将会转到 RKE 配置表单。请注意，由于集群配置在 Rancher 2.6 中发生了变更，**⋮ > 以 YAML 文件编辑**可用于配置 RKE2 集群，但不能用于编辑 RKE1 配置。
|
||||
1. 在配置表单中，向下滚动并单击**以 YAML 文件编辑**。
|
||||
1. 编辑 `rancher_kubernetes_engine_config` 参数下的 RKE 选项。
|
||||
|
||||
## Rancher UI 中的配置选项
|
||||
|
||||
:::tip
|
||||
|
||||
一些高级配置选项没有在 Rancher UI 表单中开放，但你可以通过在 YAML 中编辑 RKE 集群配置文件来启用这些选项。有关 YAML 中 RKE Kubernetes 集群的可配置选项的完整参考，请参阅 [RKE 文档](https://rancher.com/docs/rke/latest/en/config-options/)。
|
||||
|
||||
:::
|
||||
|
||||
### Kubernetes 版本
|
||||
|
||||
这指的是集群节点上安装的 Kubernetes 版本。Rancher 基于 [hyperkube](https://github.com/rancher/hyperkube) 打包了自己的 Kubernetes 版本。
|
||||
|
||||
有关更多详细信息，请参阅[升级 Kubernetes](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)。
|
||||
|
||||
### 网络提供商
|
||||
|
||||
这指的是集群使用的[网络提供商](https://kubernetes.io/docs/concepts/cluster-administration/networking/)。有关不同网络提供商的更多详细信息，请查看我们的[网络常见问题解答](../../../faq/container-network-interface-providers.md)。
|
||||
|
||||
:::caution
|
||||
|
||||
启动集群后，你无法更改网络提供商。由于 Kubernetes 不允许在网络提供商之间切换，因此，请谨慎选择要使用的网络提供商。使用网络提供商创建集群后，如果你需要更改网络提供商，你将需要拆除整个集群以及其中的所有应用。
|
||||
|
||||
:::
|
||||
|
||||
Rancher 与以下开箱即用的网络提供商兼容：
|
||||
|
||||
- [Canal](https://github.com/projectcalico/canal)
|
||||
- [Flannel](https://github.com/coreos/flannel#flannel)
|
||||
- [Calico](https://docs.projectcalico.org/v3.11/introduction/)
|
||||
- [Weave](https://github.com/weaveworks/weave)
|
||||
|
||||
:::note Weave 注意事项：
|
||||
|
||||
选择 Weave 作为网络提供商时，Rancher 将通过生成随机密码来自动启用加密。如果你想手动指定密码，请参阅使用[配置文件](#rke-集群配置文件参考)和 [Weave 网络插件选项](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/#weave-network-plug-in-options)来配置集群。
|
||||
|
||||
:::
|
||||
|
||||
### 项目网络隔离
|
||||
|
||||
如果你的网络提供商允许项目网络隔离，你可以选择启用或禁用项目间的通信。
|
||||
|
||||
如果你使用支持执行 Kubernetes 网络策略的 RKE 网络插件（例如 Canal 或 Cisco ACI 插件），则可以使用项目网络隔离。
|
||||
|
||||
### Kubernetes 云提供商
|
||||
|
||||
你可以配置 [Kubernetes 云提供商](../../../pages-for-subheaders/set-up-cloud-providers.md)。如果你想在 Kubernetes 中使用动态配置的[卷和存储](../../../pages-for-subheaders/create-kubernetes-persistent-storage.md)，你通常需要选择特定的云提供商。例如，如果你想使用 Amazon EBS，则需要选择 `aws` 云提供商。
|
||||
|
||||
:::note
|
||||
|
||||
如果你要使用的云提供商未作为选项列出，你需要使用[配置文件选项](#rke-集群配置文件参考)来配置云提供商。请参考 [RKE 云提供商文档](https://rancher.com/docs/rke/latest/en/config-options/cloud-providers/)来了解如何配置云提供商。
|
||||
|
||||
:::
|
||||
|
||||
### 私有镜像仓库
|
||||
|
||||
集群级别的私有镜像仓库配置仅能用于配置集群。
|
||||
|
||||
在 Rancher 中设置私有镜像仓库的主要方法有两种：通过[全局默认镜像仓库](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md)中的**设置**选项卡设置全局默认镜像仓库，以及在集群级别设置的高级选项中设置私有镜像仓库。全局默认镜像仓库可以用于离线设置，不需要凭证的镜像仓库。而集群级私有镜像仓库用于所有需要凭证的私有镜像仓库。
|
||||
|
||||
如果你的私有镜像仓库需要凭证，为了将凭证传递给 Rancher，你需要编辑每个需要从仓库中拉取镜像的集群的集群选项。
|
||||
|
||||
私有镜像仓库的配置选项能让 Rancher 知道要从哪里拉取用于集群的[系统镜像](https://rancher.com/docs/rke/latest/en/config-options/system-images/)或[附加组件镜像](https://rancher.com/docs/rke/latest/en/config-options/add-ons/)。
|
||||
|
||||
- **系统镜像**是维护 Kubernetes 集群所需的组件。
|
||||
- **附加组件**用于部署多个集群组件，包括网络插件、ingress controller、DNS 提供商或 metrics server。
|
||||
|
||||
有关为集群配置期间应用的组件设置私有镜像仓库的更多信息，请参阅[私有镜像仓库的 RKE 文档](https://rancher.com/docs/rke/latest/en/config-options/private-registries/)。
|
||||
|
||||
Rancher v2.6 引入了[为 RKE 集群配置 ECR 镜像仓库](https://rancher.com/docs/rke/latest/en/config-options/private-registries/#amazon-elastic-container-registry-ecr-private-registry-setup)的功能。
|
||||
|
||||
### 授权集群端点
|
||||
|
||||
授权集群端点（ACE）可用于直接访问 Kubernetes API server，而无需通过 Rancher 进行通信。
|
||||
|
||||
:::note
|
||||
|
||||
授权集群端点仅适用于 Rancher 启动的 Kubernetes 集群，即只适用于 Rancher [使用 RKE](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#配置-kubernetes-集群的工具) 来配置的集群。它不适用于托管在 Kubernetes 提供商中的集群，例如 Amazon 的 EKS。
|
||||
|
||||
:::
|
||||
|
||||
在 Rancher 启动的 Kubernetes 集群中，它默认启用，使用具有 `controlplane` 角色的节点的 IP 和默认的 Kubernetes 自签名证书。
|
||||
|
||||
有关授权集群端点的工作原理以及使用的原因，请参阅[架构介绍](../../../pages-for-subheaders/rancher-manager-architecture.md#4-授权集群端点)。
|
||||
|
||||
我们建议使用具有授权集群端点的负载均衡器。有关详细信息，请参阅[推荐的架构](../../rancher-manager-architecture/architecture-recommendations.md#授权集群端点架构)。
|
||||
|
||||
### 节点池
|
||||
|
||||
有关使用 Rancher UI 在 RKE 集群中设置节点池的信息，请参阅[此页面](../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)。
|
||||
|
||||
### NGINX Ingress
|
||||
|
||||
如果你想使用高可用性配置来发布应用，并且你使用没有原生负载均衡功能的云提供商来托管主机，请启用此选项以在集群中使用 NGINX Ingress。
|
||||
|
||||
### Metrics Server 监控
|
||||
|
||||
这是启用或禁用 [Metrics Server](https://rancher.com/docs/rke/latest/en/config-options/add-ons/metrics-server/) 的选项。
|
||||
|
||||
每个能够使用 RKE 启动集群的云提供商都可以收集指标并监控你的集群节点。如果启用此选项，你可以从你的云提供商门户查看你的节点指标。
|
||||
|
||||
### Pod 安全策略支持
|
||||
|
||||
为集群启用 [pod 安全策略](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)。启用此选项后，使用**默认 Pod 安全策略**下拉菜单选择一个策略。
|
||||
|
||||
你必须有已配置的 Pod 安全策略才能使用此选项。
|
||||
|
||||
### 节点上的 Docker 版本
|
||||
|
||||
表示是否允许节点运行 Rancher 不正式支持的 Docker 版本。
|
||||
|
||||
如果你选择使用支持的 Docker 版本，Rancher 会禁止 pod 运行在安装了不支持的 Docker 版本的节点上。
|
||||
|
||||
如需了解各个 Rancher 版本通过了哪些 Docker 版本测试，请参见[支持和维护条款](https://rancher.com/support-maintenance-terms/)。
|
||||
|
||||
### Docker 根目录
|
||||
|
||||
如果要添加到集群的节点为 Docker 配置了非默认 Docker 根目录（默认为 `/var/lib/docker`），请在此选项中指定正确的 Docker 根目录。
|
||||
|
||||
### 默认 Pod 安全策略
|
||||
|
||||
如果你启用了 **Pod 安全策略支持**，请使用此下拉菜单选择应用于集群的 pod 安全策略。
|
||||
|
||||
### 节点端口范围
|
||||
|
||||
更改可用于 [NodePort 服务](https://kubernetes.io/docs/concepts/services-networking/service/#nodeport)的端口范围的选项。默认为 `30000-32767`。
|
||||
|
||||
### 定期 etcd 快照
|
||||
|
||||
启用或禁用[定期 etcd 快照](https://rancher.com/docs/rke/latest/en/etcd-snapshots/#etcd-recurring-snapshots)的选项。
|
||||
|
||||
### Agent 环境变量
|
||||
|
||||
为 [rancher agent](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md) 设置环境变量的选项。你可以使用键值对设置环境变量。如果 Rancher Agent 需要使用代理与 Rancher Server 通信，则可以使用 Agent 环境变量设置 `HTTP_PROXY`，`HTTPS_PROXY` 和 `NO_PROXY` 环境变量。
|
||||
|
||||
### 更新 ingress-nginx
|
||||
|
||||
使用 Kubernetes 1.16 之前版本创建的集群将具有 `OnDelete`的 `ingress-nginx` `updateStrategy`。使用 Kubernetes 1.16 或更高版本创建的集群将具有 `RollingUpdate`。
|
||||
|
||||
如果 `ingress-nginx` 的 `updateStrategy` 是 `OnDelete`，则需要删除这些 pod 以获得 deployment 正确的版本。
|
||||
|
||||
## RKE 集群配置文件参考
|
||||
|
||||
高级用户可以创建一个 RKE 配置文件，而不是使用 Rancher UI 来为集群选择 Kubernetes 选项。配置文件可以让你在 RKE 安装中设置任何[可用选项](https://rancher.com/docs/rke/latest/en/config-options/)（`system_images` 配置除外）。使用 Rancher UI 或 API 创建集群时，不支持 `system_images` 选项。
|
||||
|
||||
有关 YAML 中 RKE Kubernetes 集群的可配置选项的完整参考，请参阅 [RKE 文档](https://rancher.com/docs/rke/latest/en/config-options/)。
|
||||
|
||||
### Rancher 中的配置文件结构
|
||||
|
||||
RKE（Rancher Kubernetes Engine）是 Rancher 用来配置 Kubernetes 集群的工具。过去，Rancher 的集群配置文件与 [RKE 配置文件](https://rancher.com/docs/rke/latest/en/example-yamls/)的结构是一致的。但由于 Rancher 文件结构发生了变化，因此在 Rancher 中，RKE 集群配置项与非 RKE 配置项是分开的。所以，你的集群配置需要嵌套在集群配置文件中的 `rancher_kubernetes_engine_config` 参数下。使用早期版本的 Rancher 创建的集群配置文件需要针对这种格式进行更新。以下是一个集群配置文件示例：
|
||||
|
||||
<details id="v2.3.0-cluster-config-file">
|
||||
<summary>集群配置文件示例</summary>
|
||||
|
||||
```yaml
|
||||
#
|
||||
# Cluster Config
|
||||
#
|
||||
docker_root_dir: /var/lib/docker
|
||||
enable_cluster_alerting: false
|
||||
enable_cluster_monitoring: false
|
||||
enable_network_policy: false
|
||||
local_cluster_auth_endpoint:
|
||||
enabled: true
|
||||
#
|
||||
# Rancher Config
|
||||
#
|
||||
rancher_kubernetes_engine_config: # Your RKE template config goes here.
|
||||
addon_job_timeout: 30
|
||||
authentication:
|
||||
strategy: x509
|
||||
ignore_docker_version: true
|
||||
#
|
||||
# # 目前仅支持 Nginx ingress provider
|
||||
# # 要禁用 Ingress controller，设置 `provider: none`
|
||||
# # 要在指定节点上禁用 Ingress，使用 node_selector，例如：
|
||||
# provider: nginx
|
||||
# node_selector:
|
||||
# app: ingress
|
||||
#
|
||||
ingress:
|
||||
provider: nginx
|
||||
kubernetes_version: v1.15.3-rancher3-1
|
||||
monitoring:
|
||||
provider: metrics-server
|
||||
#
|
||||
# If you are using calico on AWS
|
||||
#
|
||||
# network:
|
||||
# plugin: calico
|
||||
# calico_network_provider:
|
||||
# cloud_provider: aws
|
||||
#
|
||||
# # To specify flannel interface
|
||||
#
|
||||
# network:
|
||||
# plugin: flannel
|
||||
# flannel_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
# # To specify flannel interface for canal plugin
|
||||
#
|
||||
# network:
|
||||
# plugin: canal
|
||||
# canal_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
network:
|
||||
options:
|
||||
flannel_backend_type: vxlan
|
||||
plugin: canal
|
||||
#
|
||||
# services:
|
||||
# kube-api:
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
# kube-controller:
|
||||
# cluster_cidr: 10.42.0.0/16
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
# kubelet:
|
||||
# cluster_domain: cluster.local
|
||||
# cluster_dns_server: 10.43.0.10
|
||||
#
|
||||
services:
|
||||
etcd:
|
||||
backup_config:
|
||||
enabled: true
|
||||
interval_hours: 12
|
||||
retention: 6
|
||||
safe_timestamp: false
|
||||
creation: 12h
|
||||
extra_args:
|
||||
election-timeout: 5000
|
||||
heartbeat-interval: 500
|
||||
gid: 0
|
||||
retention: 72h
|
||||
snapshot: false
|
||||
uid: 0
|
||||
kube_api:
|
||||
always_pull_images: false
|
||||
pod_security_policy: false
|
||||
service_node_port_range: 30000-32767
|
||||
ssh_agent_auth: false
|
||||
windows_prefered_cluster: false
|
||||
```
|
||||
</details>
|
||||
|
||||
### 默认 DNS 提供商
|
||||
|
||||
下表显示了默认部署的 DNS 提供商。有关如何配置不同 DNS 提供商的更多信息，请参阅 [DNS 提供商相关的 RKE 文档](https://rancher.com/docs/rke/latest/en/config-options/add-ons/dns/)。CoreDNS 只能在 Kubernetes v1.12.0 及更高版本上使用。
|
||||
|
||||
| Rancher 版本 | Kubernetes 版本 | 默认 DNS 提供商 |
|
||||
|-------------|--------------------|----------------------|
|
||||
| v2.2.5 及更高版本 | v1.14.0 及更高版本 | CoreDNS |
|
||||
| v2.2.5 及更高版本 | v1.13.x 及更低版本 | kube-dns |
|
||||
| v2.2.4 及更低版本 | 任意 | kube-dns |
|
||||
|
||||
## YAML 中的 Rancher 特定参数
|
||||
|
||||
除了 RKE 配置文件选项外，还有可以在配置文件 (YAML) 中配置的 Rancher 特定设置如下。
|
||||
|
||||
### docker_root_dir
|
||||
|
||||
请参阅 [Docker 根目录](#docker-根目录)。
|
||||
|
||||
### enable_cluster_monitoring
|
||||
|
||||
启用或禁用[集群监控](../../../pages-for-subheaders/monitoring-and-alerting.md)的选项。
|
||||
|
||||
### enable_network_policy
|
||||
|
||||
启用或禁用项目网络隔离的选项。
|
||||
|
||||
如果你使用支持执行 Kubernetes 网络策略的 RKE 网络插件（例如 Canal 或 Cisco ACI 插件），则可以使用项目网络隔离。
|
||||
|
||||
### local_cluster_auth_endpoint
|
||||
|
||||
请参阅[授权集群端点](#授权集群端点)。
|
||||
|
||||
示例：
|
||||
|
||||
```yaml
|
||||
local_cluster_auth_endpoint:
|
||||
enabled: true
|
||||
fqdn: "FQDN"
|
||||
ca_certs: |-
|
||||
-----BEGIN CERTIFICATE-----
|
||||
...
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
### 自定义网络插件
|
||||
|
||||
你可以使用 RKE 的[用户定义的附加组件功能](https://rancher.com/docs/rke/latest/en/config-options/add-ons/user-defined-add-ons/)来添加自定义网络插件。部署 Kubernetes 集群之后，你可以定义要部署的任何附加组件。
|
||||
|
||||
有两种方法可以指定附加组件：
|
||||
|
||||
- [内嵌附加组件](https://rancher.com/docs/rke/latest/en/config-options/add-ons/user-defined-add-ons/#in-line-add-ons)
|
||||
- [为附加组件引用 YAML 文件](https://rancher.com/docs/rke/latest/en/config-options/add-ons/user-defined-add-ons/#referencing-yaml-files-for-add-ons)
|
||||
|
||||
有关如何通过编辑 `cluster.yml` 来配置自定义网络插件的示例，请参阅 [RKE 文档](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/custom-network-plugin-example)。
|
||||
+352
@@ -0,0 +1,352 @@
|
||||
---
|
||||
title: RKE2 集群配置参考
|
||||
---
|
||||
|
||||
本文介绍 Rancher 中可用于新的或现有的 RKE2 Kubernetes 集群的配置选项。
|
||||
|
||||
## 概述
|
||||
|
||||
你可以通过以下两种方式之一来配置 Kubernetes 选项：
|
||||
|
||||
- [Rancher UI](#rancher-ui-中的配置选项)：使用 Rancher UI 来选择设置 Kubernetes 集群时常用的自定义选项。
|
||||
- [集群配置文件](#集群配置文件参考)：高级用户可以创建一个 RKE2 配置文件，而不是使用 Rancher UI 来为集群选择 Kubernetes 选项。配置文件让你能设置更多可用于 RKE2 的其他[安装选项](https://docs.rke2.io/install/configuration)。
|
||||
|
||||
## 在 Rancher UI 中使用表单编辑集群
|
||||
|
||||
要编辑你的集群：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置的集群，然后单击 **⋮ > 编辑配置**。
|
||||
|
||||
## 使用 YAML 编辑集群
|
||||
|
||||
高级用户可以创建一个 RKE2 配置文件，而不是使用 Rancher UI 来为集群选择 Kubernetes 选项。配置文件可以让你使用 YAML 来指定 RKE2 安装中可用的任何选项。
|
||||
|
||||
要直接从 Rancher UI 中编辑 RKE2 配置文件：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到你要配置的集群，然后单击 **⋮ > 以 YAML 文件编辑**。
|
||||
1. 编辑 `rkeConfig` 参数下的 RKE 选项。
|
||||
|
||||
## Rancher UI 中的配置选项
|
||||
|
||||
:::tip
|
||||
|
||||
一些高级配置选项没有在 Rancher UI 表单中开放，但你可以通过在 YAML 中编辑 RKE2 集群配置文件来启用这些选项。有关 YAML 中 RKE2 Kubernetes 集群的可配置选项的完整参考，请参阅 [RKE2 文档](https://docs.rke2.io/install/configuration)。
|
||||
|
||||
:::
|
||||
|
||||
## 主机池
|
||||
|
||||
本小节介绍了通用的主机池配置。对于针对特定基础设施提供商的配置，请参阅以下页面：
|
||||
|
||||
- [Azure](../downstream-cluster-configuration/machine-configuration/azure.md)
|
||||
- [DigitalOcean](../downstream-cluster-configuration/machine-configuration/digitalocean.md)
|
||||
- [EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
|
||||
|
||||
### 池名称
|
||||
|
||||
主机池的名称。
|
||||
|
||||
### 主机数量
|
||||
|
||||
池中的主机数。
|
||||
|
||||
### 角色
|
||||
|
||||
将 etcd、controlplane 和 worker 角色分配给节点的选项。
|
||||
|
||||
### 高级配置
|
||||
|
||||
#### 自动替换
|
||||
|
||||
如果节点无法访问的持续时间达到该值，则会被自动删除和替换。
|
||||
|
||||
#### 删除前清空
|
||||
|
||||
通过在删除节点之前驱逐所有 pod 来清空节点。
|
||||
|
||||
#### Kubernetes 节点标签
|
||||
|
||||
将[标签](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)（label）添加到节点，让对象选择更加简便。
|
||||
|
||||
有关标签语法的详细信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。
|
||||
|
||||
#### 污点
|
||||
|
||||
将[污点](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)（taint）添加到节点，防止 pod 被调度或在节点上执行（除非 pod 具有匹配的容忍度）。
|
||||
|
||||
## 集群配置
|
||||
|
||||
### 基本信息
|
||||
#### Kubernetes 版本
|
||||
|
||||
这指的是集群节点上安装的 Kubernetes 版本。Rancher 基于 [hyperkube](https://github.com/rancher/hyperkube) 打包了自己的 Kubernetes 版本。
|
||||
|
||||
有关更多详细信息，请参阅[升级 Kubernetes](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)。
|
||||
|
||||
#### 容器网络提供商
|
||||
|
||||
这指的是集群使用的[网络提供商](https://kubernetes.io/docs/concepts/cluster-administration/networking/)。
|
||||
|
||||
:::caution
|
||||
|
||||
启动集群后，你无法更改网络提供商。由于 Kubernetes 不允许在网络提供商之间切换，因此，请谨慎选择要使用的网络提供商。使用网络提供商创建集群后，如果你需要更改网络提供商，你将需要拆除整个集群以及其中的所有应用。
|
||||
|
||||
:::
|
||||
|
||||
Rancher 与以下开箱即用的网络提供商兼容：
|
||||
|
||||
- [Canal](https://github.com/projectcalico/canal)
|
||||
- [Cilium](https://cilium.io/)\*
|
||||
- [Calico](https://docs.projectcalico.org/v3.11/introduction/)
|
||||
- [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)
|
||||
|
||||
\* 在 [Cilium CNI](../../../faq/container-network-interface-providers.md#cilium) 中使用[项目网络隔离](#项目网络隔离)时，你可以开启跨节点入口路由。详情请参见 [CNI 提供商文档](../../../faq/container-network-interface-providers.md#ingress-routing-across-nodes-in-cilium)。
|
||||
|
||||
有关不同网络提供商以及如何配置它们的更多详细信息，请查阅 [RKE2 文档](https://docs.rke2.io/install/network_options)。
|
||||
|
||||
##### 双栈网络
|
||||
|
||||
所有 CNI 网络插件都支持[双栈](https://docs.rke2.io/install/network_options#dual-stack-configuration)网络。要在双栈模式下配置 RKE2，请为你的[集群 CIDR](#集群-cidr) 和/或 [Service CIDR](#service-cidr) 设置有效的 IPv4/IPv6 CIDR。
|
||||
|
||||
###### 额外配置 {#dual-stack-additional-config}
|
||||
|
||||
使用 `cilium` 或 `multus,cilium` 作为容器网络接口提供商时，请确保**启用 IPv6 支持**选项。
|
||||
|
||||
#### 云提供商
|
||||
|
||||
你可以配置 [Kubernetes 云提供商](../../../pages-for-subheaders/set-up-cloud-providers.md)。如果你想在 Kubernetes 中使用动态配置的[卷和存储](../../../pages-for-subheaders/create-kubernetes-persistent-storage.md)，你通常需要选择特定的云提供商。例如，如果你想使用 Amazon EBS，则需要选择 `aws` 云提供商。
|
||||
|
||||
:::note
|
||||
|
||||
如果你要使用的云提供商未作为选项列出，你需要使用[配置文件选项](#集群配置文件参考)来配置云提供商。请参考[本文档](https://rancher.com/docs/rke/latest/en/config-options/cloud-providers/)来了解如何配置云提供商。
|
||||
|
||||
:::
|
||||
|
||||
#### 默认 Pod 安全策略
|
||||
|
||||
为集群选择默认的 [pod 安全策略](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)。请参阅 [RKE2 文档](https://docs.rke2.io/security/pod_security_policies)来了解每个可用策略的规范。
|
||||
|
||||
#### Worker CIS 配置文件
|
||||
|
||||
选择一个 [CIS benchmark](../../../pages-for-subheaders/cis-scan-guides.md) 来验证系统配置。
|
||||
|
||||
#### 项目网络隔离
|
||||
|
||||
如果你的网络提供商允许项目网络隔离，你可以选择启用或禁用项目间的通信。
|
||||
|
||||
如果你使用支持执行 Kubernetes 网络策略的 RKE2 网络插件（例如 Canal），则可以使用项目网络隔离。
|
||||
|
||||
#### CoreDNS
|
||||
|
||||
默认情况下，[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS，则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置，请参阅 [RKE2 文档](https://docs.rke2.io/networking#coredns)。
|
||||
|
||||
#### NGINX Ingress
|
||||
|
||||
如果你想使用高可用性配置来发布应用，并且你使用没有原生负载均衡功能的云提供商来托管主机，请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
|
||||
有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
|
||||
#### Metrics Server
|
||||
|
||||
这是启用或禁用 [Metrics Server](https://rancher.com/docs/rke/latest/en/config-options/add-ons/metrics-server/) 的选项。
|
||||
|
||||
每个能够使用 RKE2 启动集群的云提供商都可以收集指标并监控你的集群节点。如果启用此选项，你可以从你的云提供商门户查看你的节点指标。
|
||||
|
||||
### 附加配置
|
||||
|
||||
集群启动时将应用的其他 Kubernetes 清单，会作为[附加组件](https://kubernetes.io/docs/concepts/cluster-administration/addons/)来管理。有关详细信息，请参阅 [RKE2 文档](https://docs.rke2.io/helm#automatically-deploying-manifests-and-helm-charts)。
|
||||
|
||||
### Agent 环境变量
|
||||
|
||||
为 [Rancher agent](https://rancher.com/docs/rancher/v2.6/en/cluster-provisioning/rke-clusters/rancher-agents/) 设置环境变量的选项。你可以使用键值对设置环境变量。有关详细信息，请参阅 [RKE2 文档](https://docs.rke2.io/reference/linux_agent_config)。
|
||||
|
||||
### etcd
|
||||
|
||||
#### 自动快照
|
||||
|
||||
启用或禁用定期 etcd 快照的选项。如果启用，用户可以配置快照的频率。有关详细信息，请参阅 [RKE2 文档](https://docs.rke2.io/backup_restore#creating-snapshots)。请注意，如果使用 RKE2，快照会存储在每个 etcd 节点上，这与 RKE1 不同（RKE1 每个集群只存储一个快照）。
|
||||
|
||||
#### 指标
|
||||
|
||||
选择向公众公开或仅在集群内公开 etcd 指标的选项。
|
||||
|
||||
### 网络
|
||||
|
||||
#### 集群 CIDR
|
||||
|
||||
用于 pod IP 的 IPv4 和/或 IPv6 网络 CIDR（默认：10.42.0.0/16）。
|
||||
|
||||
##### 双栈网络
|
||||
|
||||
要配置[双栈](https://docs.rke2.io/install/network_options#dual-stack-configuration)模式，请输入有效的 IPv4/IPv6 CIDR。例如 `10.42.0.0/16,2001:cafe:42:0::/56`。
|
||||
|
||||
使用 `cilium` 或 `multus,cilium` 作为[容器网络](#容器网络提供商)接口提供商时，你需要进行[附加配置](#dual-stack-additional-config)。
|
||||
|
||||
#### Service CIDR
|
||||
|
||||
用于 Service IP 的 IPv4/IPv6 网络 CIDR（默认：10.43.0.0/16）。
|
||||
|
||||
##### 双栈网络
|
||||
|
||||
要配置[双栈](https://docs.rke2.io/install/network_options#dual-stack-configuration)模式，请输入有效的 IPv4/IPv6 CIDR。例如 `10.42.0.0/16,2001:cafe:42:0::/56`。
|
||||
|
||||
使用 `cilium` 或 `multus,cilium` 作为[容器网络](#容器网络提供商)接口提供商时，你需要进行[附加配置](#dual-stack-additional-config)。
|
||||
|
||||
#### 集群 DNS
|
||||
|
||||
用于 coredns 服务的 IPv4 集群 IP。应该在你的 service-cidr 范围内（默认：10.43.0.10）。
|
||||
|
||||
#### 集群域名
|
||||
|
||||
选择集群的域。默认值为 `cluster.local`。
|
||||
|
||||
#### NodePort 服务端口范围
|
||||
|
||||
更改可用于 [NodePort 服务](https://kubernetes.io/docs/concepts/services-networking/service/#nodeport)的端口范围的选项。默认值为 `30000-32767`。
|
||||
|
||||
#### TLS 可选名称
|
||||
|
||||
在服务器 TLS 证书上添加其他主机名或 IPv4/IPv6 地址作为 Subject Alternative Name。
|
||||
|
||||
#### 授权集群端点
|
||||
|
||||
授权集群端点（ACE）可用于直接访问 Kubernetes API server，而无需通过 Rancher 进行通信。
|
||||
|
||||
在 Rancher 启动的 Kubernetes 集群中，它默认启用，使用具有 `controlplane` 角色的节点的 IP 和默认的 Kubernetes 自签名证书。
|
||||
|
||||
有关授权集群端点的工作原理以及使用的原因，请参阅[架构介绍](../../../pages-for-subheaders/rancher-manager-architecture.md#4-授权集群端点)。
|
||||
|
||||
我们建议使用具有授权集群端点的负载均衡器。有关详细信息，请参阅[推荐的架构](../../rancher-manager-architecture/architecture-recommendations.md#授权集群端点架构)。
|
||||
|
||||
### 镜像仓库
|
||||
|
||||
选择要从中拉取 Rancher 镜像的镜像仓库。有关更多详细信息和配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/install/containerd_registry_configuration)。
|
||||
|
||||
### 升级策略
|
||||
|
||||
#### controlplane 并发
|
||||
|
||||
选择可以同时升级多少个节点。可以是固定数字或百分比。
|
||||
|
||||
#### Worker 并发
|
||||
|
||||
选择可以同时升级多少个节点。可以是固定数字或百分比。
|
||||
|
||||
#### 清空节点（controlplane）
|
||||
|
||||
在升级之前从节点中删除所有 pod 的选项。
|
||||
|
||||
#### 清空节点（worker 节点）
|
||||
|
||||
在升级之前从节点中删除所有 pod 的选项。
|
||||
|
||||
### 高级配置
|
||||
|
||||
为不同节点设置 kubelet 选项。有关可用选项，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)。
|
||||
|
||||
## 集群配置文件参考
|
||||
|
||||
高级用户可以创建一个配置文件，而不是使用 Rancher UI 来为集群选择 Kubernetes 选项。配置文件允许你为 RKE2 设置[可用的选项](https://docs.rke2.io/install/configuration)，其中包括已经在 [Rancher UI 配置选项](#rancher-ui-中的配置选项)中列出的选项以及 Rancher 特定的参数。
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
<b>集群配置文件片段示例</b>
|
||||
</summary>
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
cloudCredentialSecretName: cattle-global-data:cc-s879v
|
||||
kubernetesVersion: v1.23.6+rke2r2
|
||||
localClusterAuthEndpoint: {}
|
||||
rkeConfig:
|
||||
chartValues:
|
||||
rke2-calico: {}
|
||||
etcd:
|
||||
snapshotRetention: 5
|
||||
snapshotScheduleCron: 0 */5 * * *
|
||||
machineGlobalConfig:
|
||||
cni: calico
|
||||
disable-kube-proxy: false
|
||||
etcd-expose-metrics: false
|
||||
profile: null
|
||||
machinePools:
|
||||
- controlPlaneRole: true
|
||||
etcdRole: true
|
||||
machineConfigRef:
|
||||
kind: Amazonec2Config
|
||||
name: nc-test-pool1-pwl5h
|
||||
name: pool1
|
||||
quantity: 1
|
||||
unhealthyNodeTimeout: 0s
|
||||
workerRole: true
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
protect-kernel-defaults: false
|
||||
registries: {}
|
||||
upgradeStrategy:
|
||||
controlPlaneConcurrency: "1"
|
||||
controlPlaneDrainOptions:
|
||||
deleteEmptyDirData: true
|
||||
enabled: true
|
||||
gracePeriod: -1
|
||||
ignoreDaemonSets: true
|
||||
timeout: 120
|
||||
workerConcurrency: "1"
|
||||
workerDrainOptions:
|
||||
deleteEmptyDirData: true
|
||||
enabled: true
|
||||
gracePeriod: -1
|
||||
ignoreDaemonSets: true
|
||||
timeout: 120
|
||||
```
|
||||
</details>
|
||||
|
||||
### chartValues
|
||||
|
||||
此选项用于为 RKE2/K3s 安装的 System Chart 指定值。
|
||||
|
||||
示例：
|
||||
|
||||
```yaml
|
||||
chartValues:
|
||||
chart-name:
|
||||
key: value
|
||||
```
|
||||
### machineGlobalConfig
|
||||
|
||||
RKE2/K3s 配置嵌套在 `machineGlobalConfig` 参数下。在这里所做的任何配置更改都将应用到每个节点。你可以在此处应用[RKE2 的独立版本](https://docs.rke2.io/reference/server_config)中可用的配置选项。
|
||||
|
||||
示例：
|
||||
|
||||
```yaml
|
||||
machineGlobalConfig:
|
||||
etcd-arg:
|
||||
- key1=value1
|
||||
- key2=value2
|
||||
```
|
||||
|
||||
### machineSelectorConfig
|
||||
|
||||
此参数与 [`machineGlobalConfig`](#machineglobalconfig) 相同，只是可以在配置中指定 [label](#kubernetes-node-labels) 选择器。该配置仅应用于与标签选择器匹配的节点。
|
||||
|
||||
允许多个 `config` 条目，可以为每个条目指定各自的 `machineLabelSelector`。用户可以指定 `matchExpressions`、`matchLabels`、指定二者或都不指定。如果你省略了 `machineLabelSelector`，则与将 config 放入 `machineGlobalConfig` 的效果相同。
|
||||
|
||||
示例：
|
||||
|
||||
```yaml
|
||||
machineSelectorConfig
|
||||
- config:
|
||||
config-key: config-value
|
||||
machineLabelSelector:
|
||||
matchExpressions:
|
||||
- key: example-key
|
||||
operator: string # 有效的运算符：In、NotIn、Exists 和 DoesNotExist
|
||||
values:
|
||||
- example-value1
|
||||
- example-value2
|
||||
matchLabels:
|
||||
key1: value1
|
||||
key2: value2
|
||||
```
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: 同步
|
||||
---
|
||||
|
||||
同步允许 Rancher 更新集群值，以便与托管在 AKS、EKS 或 GKE 中的集群对象保持同步。这使得 Rancher 以外的来源能够获取托管集群的状态。这是 UI 中显示的内容。
|
||||
|
||||
:::caution
|
||||
如果你同时处理来自另一个来源的更新，你可能会不小心覆盖一个来源的状态。如果你在完成一个来源的更新后 5 分钟内处理另一个来源的更新，也可能会发生这种情况。
|
||||
:::
|
||||
|
||||
### 工作原理
|
||||
|
||||
要理解同步是如何工作的，则必须理解 Rancher Cluster 对象上的两个字段：
|
||||
|
||||
1. 集群的 config 对象，位于集群的规范上：
|
||||
|
||||
* 对于 AKS，该字段称为 AKSConfig
|
||||
* 对于 EKS，该字段称为 EKSConfig
|
||||
* 对于 GKE，该字段称为 GKEConfig
|
||||
|
||||
2. UpstreamSpec 对象
|
||||
|
||||
* 对于 AKS，它位于群集状态的 AKSStatus 字段中。
|
||||
* 对于 EKS，它位于集群状态的 EKSStatus 字段中。
|
||||
* 对于 GKE，它位于集群状态的 GKEStatus 字段中。
|
||||
|
||||
定义这些对象的结构类型可以在它们对应的 operator 项目中找到：
|
||||
|
||||
* [aks-operator](https://github.com/rancher/aks-operator/blob/master/pkg/apis/aks.cattle.io/v1/types.go)
|
||||
* [eks-operator](https://github.com/rancher/eks-operator/blob/master/pkg/apis/eks.cattle.io/v1/types.go)
|
||||
* [gke-operator](https://github.com/rancher/gke-operator/blob/master/pkg/apis/gke.cattle.io/v1/types.go)
|
||||
|
||||
除集群名称、位置（区域或地区）、导入和云凭证引用外，所有字段均可为空。
|
||||
|
||||
AKSConfig、EKSConfig 或 GKEConfig 表示所需的状态。零值会被忽略。配置对象中非零的字段可以被认为是“管理的”。在 Rancher 中创建集群时，所有字段都是非零的，因此都是“管理”的。在把一个已存在的集群注册到 Rancher 时，所有可为空字段都是 nil 并且不是“管理”的。一旦 Rancher 更改了这些字段的值，这些字段就会被管理。
|
||||
|
||||
UpstreamSpec 代表集群在托管的 Kubernetes 提供商中的情况。它每 5 分钟刷新一次。刷新 UpstreamSpec 后，Rancher 会检查集群是否正在进行更新。如果它正在更新，则不做任何进一步处理。如果它目前没有更新，AKSConfig、EKSConfig 或 GKEConfig 上的任何 "管理" 字段都会被最近更新的 UpstreamSpec 上的相应值覆盖。
|
||||
|
||||
有效的期望状态可以被认为是 UpstreamSpec，加上 AKSConfig、EKSConfig 或 GKEConfig 中的所有非零字段。这是 UI 中显示的内容。
|
||||
|
||||
如果 Rancher 和另一个来源试图在同一时间或在更新完成后的 5 分钟尝试更新集群，任何管理字段都可能陷入竞争状态。以 EKS 为例，集群可能将 PrivateAccess 作为管理字段。如果 PrivateAccess 为 false，在 11:01 在 EKS 控制台中启用，然后 Rancher 在 11:05 之前更新标签，那么该值很可能被覆盖。如果在集群处理更新时更新了标签，也会发生这种情况。如果集群已注册并且 PrivateAccess 字段为 nil，则不应发生此示例中描述的问题。
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: Rancher Agent 选项
|
||||
---
|
||||
|
||||
Rancher 在每个节点上部署一个 Agent 来与节点通信。本文描述了可以传递给 Agent 的选项。要使用这些选项，你需要[使用自定义节点创建集群](../../../../pages-for-subheaders/use-existing-nodes.md)，并在添加节点时将选项添加到生成的 `docker run` 命令。
|
||||
|
||||
有关 Rancher 如何使用 Node Agent 与下游集群通信的概述，请参阅[产品架构](../../../rancher-manager-architecture/communicating-with-downstream-user-clusters.md#3-node-agents)。
|
||||
|
||||
## 通用选项
|
||||
|
||||
| 参数 | 环境变量 | 描述 |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
| `--server` | `CATTLE_SERVER` | 已配置的 Rancher `server-url`，Agent 将通过这个地址连接 Server。 |
|
||||
| `--token` | `CATTLE_TOKEN` | 在 Rancher 中注册节点所需的 Token。 |
|
||||
| `--ca-checksum` | `CATTLE_CA_CHECKSUM` | 使用已配置的 Rancher `cacerts` 进行 SHA256 校验和验证。 |
|
||||
| `--node-name` | `CATTLE_NODE_NAME` | 覆盖用于注册节点的主机名（默认为 `hostname -s`）。 |
|
||||
| `--label` | `CATTLE_NODE_LABEL` | 向节点添加节点标签。对于多个标签，请传递额外的 `--label` 选项。(`--label key=value`) |
|
||||
| `--taints` | `CATTLE_NODE_TAINTS` | 将节点污点添加到节点。对于多个污点，请传递额外的 `--taints` 选项。(`--taints key=value:effect`) |
|
||||
|
||||
## 角色选项
|
||||
|
||||
| 参数 | 环境变量 | 描述 |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
| `--all-roles` | `ALL=true` | 将所有角色（`etcd`、`controlplane`、`worker`）应用到节点。 |
|
||||
| `--etcd` | `ETCD=true` | 将角色 `etcd` 应用到节点。 |
|
||||
| `--controlplane` | `CONTROL=true` | 将角色 `controlplane` 应用到节点。 |
|
||||
| `--worker` | `WORKER=true` | 将角色 `worker` 应用到节点。 |
|
||||
|
||||
## IP 地址选项
|
||||
|
||||
| 参数 | 环境变量 | 描述 |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
| `--address` | `CATTLE_ADDRESS` | 节点将注册的 IP 地址（默认为用于连接 `8.8.8.8`的 IP）。 |
|
||||
| `--internal-address` | `CATTLE_INTERNAL_ADDRESS` | 私有网络上用于主机间通信的 IP 地址。 |
|
||||
|
||||
### 动态 IP 地址选项
|
||||
|
||||
出于自动化目的，你不能在命令中使用特定的 IP 地址，因为它必须是通用的才能用于每个节点。为此，我们提供了动态 IP 地址的选项。它们用作现有 IP 地址选项的值。支持 `--address` 和 `--internal-address`。
|
||||
|
||||
| 值 | 示例 | 描述 |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
| 接口名称 | `--address eth0` | 将从给定的接口中检索第一个配置的 IP 地址。 |
|
||||
| `ipify` | `--address ipify` | 将使用从 `https://api.ipify.org` 检索到的值。 |
|
||||
| `awslocal` | `--address awslocal` | 将使用从 `http://169.254.169.254/latest/meta-data/local-ipv4` 检索到的值。 |
|
||||
| `awspublic` | `--address awspublic` | 将使用从 `http://169.254.169.254/latest/meta-data/public-ipv4` 检索到的值。 |
|
||||
| `doprivate` | `--address doprivate` | 将使用从 `http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address` 检索到的值。 |
|
||||
| `dopublic` | `--address dopublic` | 将使用从 `http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address` 检索到的值。 |
|
||||
| `azprivate` | `--address azprivate` | 将使用从 `http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/privateIpAddress?api-version=2017-08-01&format=text` 检索到的值。 |
|
||||
| `azpublic` | `--address azpublic` | 将使用从 `http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-08-01&format=text` 检索到的值。 |
|
||||
| `gceinternal` | `--address gceinternal` | 将使用从 `http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip` 检索到的值。 |
|
||||
| `gceexternal` | `--address gceexternal` | 将使用从 `http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip` 检索到的值。 |
|
||||
| `packetlocal` | `--address packetlocal` | 将使用从 `https://metadata.packet.net/2009-04-04/meta-data/local-ipv4` 检索到的值。 |
|
||||
| `packetpublic` | `--address packetlocal` | 将使用从 `https://metadata.packet.net/2009-04-04/meta-data/public-ipv4` 检索到的值。 |
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: Kubernetes 概念
|
||||
---
|
||||
|
||||
本文解释了 Kubernetes 的相关概念，以便让你更好地了解 Rancher 的运行机制。本文仅对 Kubernetes 组件进行了简单的描述。如需了解更多详情，请参见 [Kubernetes 组件的官方文档](https://kubernetes.io/docs/concepts/overview/components/)。
|
||||
|
||||
## 关于 Docker
|
||||
|
||||
Docker 是容器打包和运行时系统的标准。开发者在 Dockerfiles 中构建容器镜像，并在 Docker 镜像仓库中分发容器镜像。[Docker Hub](https://hub.docker.com) 是市面上主流的公有镜像仓库。许多企业还创建私有 Docker 镜像仓库。Docker 主要用于管理单个节点上的容器。
|
||||
|
||||
:::note
|
||||
|
||||
由于 Kubernetes 已经成为了容器管理的主流工具，所以从 Rancher 2.x 版本开始，我们不再支持 Docker Swarm。如果你有使用 Docker 管理容器的需求，可以安装 Rancher 1.6 进行操作。
|
||||
|
||||
:::
|
||||
|
||||
## 关于 Kubernetes
|
||||
|
||||
Kubernetes 是容器和集群管理的标准。YAML 文件规定了组成一个应用所需的容器和其他资源。Kubernetes 提供了调度、伸缩、服务发现、健康检查、密文管理和配置管理等功能。
|
||||
|
||||
## Kubernetes 集群是什么
|
||||
|
||||
集群是可作为一个系统协同工作的一组计算机。
|
||||
|
||||
_Kubernetes 集群_ 是使用 [Kubernetes 容器编排系统](https://kubernetes.io/)来部署、运维和伸缩 Docker 容器的集群，让你的组织实现应用自动化运维。
|
||||
|
||||
## Kubernetes 集群中节点的角色
|
||||
|
||||
Kubernetes 集群中的每个计算资源称为一个 _节点_ 。节点可以是裸金属服务器或虚拟机。Kubernetes 将节点分为 _etcd_ 节点、_controlplane_ 节点和 _worker_ 节点。
|
||||
|
||||
一个 Kubernetes 集群至少包含一个 etcd 节点，一个 controlplane 节点和一个 worker 节点。
|
||||
|
||||
### etcd 节点
|
||||
|
||||
Rancher 在单节点和高可用安装中均使用 etcd 作为数据存储。在 Kubernetes 中，etcd 也是存储集群状态的节点的角色。
|
||||
|
||||
Kubernetes 集群的状态保存在 [etcd](https://kubernetes.io/docs/concepts/overview/components/#etcd) 中。etcd 节点运行 etcd 数据库。
|
||||
|
||||
etcd 数据库组件是一个分布式的键值对存储系统，用于存储所有 Kubernetes 的集群数据，例如集群协作和状态管理相关的数据。建议在多个节点上运行 etcd，以保证在发生故障时有可用的备份数据。
|
||||
|
||||
即使你可以仅在一个节点上运行 etcd，但 etcd 需要大多数节点（即 quorum）的同意才能更新集群状态。集群需要包含足够数量的健康 etcd 节点，以形成 quorum。假设集群中有 n 个节点，quorum 的数量则需要是 (n/2)+1。如果集群节点数量是奇数，每新增一个节点，都会增加 quorum 所需节点数。
|
||||
|
||||
一般情况下，集群中只要配置三个 etcd 节点就能满足小型集群的需求，五个 etcd 节点能满足大型集群的需求。
|
||||
|
||||
### controlplane 节点
|
||||
|
||||
controlplane 节点上运行 Kubernetes API server、scheduler 和 Controller Manager。这些节点执行日常任务，以确保集群状态和你的配置一致。因为 etcd 节点保存了集群的全部数据，所以 controlplane 节点是无状态的。虽然你可以在单个节点上运行 controlplane，但是我们建议在两个或以上的节点上运行 controlplane，以保证冗余性。另外，一个节点可以既是 controlplane 节点，又是 etcd 节点。
|
||||
|
||||
### Worker 节点
|
||||
|
||||
每个 [worker 节点](https://kubernetes.io/docs/concepts/architecture/nodes/)都能运行：
|
||||
|
||||
- **Kubelets**：监控节点状态的 Agent，确保你的容器处于健康状态。
|
||||
- **工作负载**：承载应用和其他 deployment 的容器和 Pod。
|
||||
|
||||
Worker 节点也运行存储和网络驱动，有必要时也会运行 Ingress Controller。你可以根据需要，创建尽可能多的 worker 节点来运行你的[工作负载](../pages-for-subheaders/workloads-and-pods.md)。
|
||||
|
||||
## 关于 Helm
|
||||
|
||||
在 Rancher 高可用安装的场景下，你可以使用 Helm 工具，把 Rancher 安装到 Kubernetes 集群上。
|
||||
|
||||
Helm 是 Kubernetes 的包管理工具。Helm Chart 为 Kubernetes YAML 清单文件提供了模板语法。通过 Helm，用户可以创建可配置的 deployment，而不仅仅只能使用静态文件。如果你需要创建自己的 deployment 商店应用，请参见 [https://helm.sh/](https://helm.sh) 上的文档。
|
||||
|
||||
有关 ServiceAccount 和 Cluster Role Binding 的更多信息，请参见 [Kubernetes 官方文档](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: 示例
|
||||
---
|
||||
|
||||
### ServiceMonitor
|
||||
|
||||
你可以在[此处](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml)找到 ServiceMonitor 自定义资源的示例。
|
||||
|
||||
### PodMonitor
|
||||
|
||||
你可以在[此处](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/user-guides/getting-started/example-app-pod-monitor.yaml)找到 PodMonitor 示例，还可以在[此处](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/user-guides/getting-started/prometheus-pod-monitor.yaml)找到引用它的 Prometheus 资源示例。
|
||||
|
||||
### PrometheusRule
|
||||
|
||||
PrometheusRule 包含你通常放置在 [Prometheus 规则文件](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/)中的告警和记录规则。
|
||||
|
||||
要在集群中更细粒度地应用 PrometheusRules，你可以使用 Prometheus 资源的 ruleSelector 字段，从而根据添加到 PrometheusRules 资源的标签来选择要加载到 Prometheus 上的 PrometheusRule。
|
||||
|
||||
你可以在[此页面](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/alerting.md)找到 PrometheusRule 示例。
|
||||
|
||||
### Alertmanager 配置
|
||||
|
||||
有关示例配置，请参阅[本节](receivers.md#配置多个接收器)。
|
||||
+68
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: Helm Chart 选项
|
||||
---
|
||||
|
||||
## 配置资源限制和请求
|
||||
|
||||
安装 `rancher-monitoring` 时可以配置资源请求和限制。
|
||||
|
||||
默认值在 `rancher-monitoring` Helm Chart 的 [values.yaml](https://github.com/rancher/charts/blob/main/charts/rancher-monitoring/values.yaml) 中。
|
||||
|
||||
下表中的默认值是所需的最低资源限制和请求：
|
||||
|
||||
| 资源名称 | 内存限制 | CPU 限制 | 内存请求 | CPU 请求 |
|
||||
| ------------- | ------------ | ----------- | ---------------- | ------------------ |
|
||||
| alertmanager | 500Mi | 1000m | 100Mi | 100m |
|
||||
| grafana | 200Mi | 200m | 100Mi | 100m |
|
||||
| kube-state-metrics subchart | 200Mi | 100m | 130Mi | 100m |
|
||||
| prometheus-node-exporter subchart | 50Mi | 200m | 30Mi | 100m |
|
||||
| prometheusOperator | 500Mi | 200m | 100Mi | 100m |
|
||||
| prometheus | 2500Mi | 1000m | 1750Mi | 750m |
|
||||
| **总计** | **3950Mi** | **2700m** | **2210Mi** | **1250m** |
|
||||
|
||||
建议至少配 50Gi 存储。
|
||||
|
||||
|
||||
## Notifiers 的可信 CA
|
||||
|
||||
如果你需要将受信任的 CA 添加到 Notifiers，请执行以下步骤：
|
||||
|
||||
1. 创建 `cattle-monitoring-system` 命名空间。
|
||||
1. 将你信任的 CA 密文添加到 `cattle-monitoring-system` 命名空间。
|
||||
1. 部署或升级 `rancher-monitoring` Helm Chart。在 Chart 选项中，引用**告警 > 补充密文**中的密钥。
|
||||
|
||||
**结果**：默认的 Alertmanager 自定义资源将有权访问你信任的 CA。
|
||||
|
||||
|
||||
## 其它抓取配置
|
||||
|
||||
如果无法通过 ServiceMonitor 或 PodMonitor 指定你想要的抓取配置，你可以在部署或升级 `rancher-monitoring` 时提供 `additionalScrapeConfigSecret`。
|
||||
|
||||
[scrape_config](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) 指定一组目标以及抓取这些目标的参数。在一般情况下，一个抓取配置指定一个 job。
|
||||
|
||||
Istio 就是一个可能用到这个配置的例子。有关详细信息，请参阅[本节](../../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md)。
|
||||
|
||||
|
||||
## 配置打包在 Monitoring V2 中的应用
|
||||
|
||||
我们使用 Monitoring V2 来部署 kube-state-metrics 和 node-exporter。node-exporter 部署为 DaemonSet。对于 Monitoring V2 helm Chart，values.yaml 中的所有东西都部署为子 Chart。
|
||||
|
||||
我们还部署了不由 prometheus 管理的 Grafana。
|
||||
|
||||
如果你查看 Helm Chart 在 kube-state-metrics 中的功能，则还有很多可以设置的值没有在顶层 Chart 中显示。
|
||||
|
||||
但是，你可以在顶层 Chart 中添加覆盖子 Chart 的值。
|
||||
|
||||
### 增加 Alertmanager 的副本
|
||||
|
||||
作为 Chart 部署选项的一部分，你可以选择增加部署到集群上的 Alertmanager 副本的数量。这些副本使用相同的底层 Alertmanager Config Secret 进行管理。有关 Alertmanager Config Secret 的更多信息，请参阅[本节](../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md#多个-alertmanager-副本)。
|
||||
|
||||
### 为持久化 Grafana 仪表板配置命名空间
|
||||
|
||||
要让 Grafana 监控所有命名空间中的 ConfigMap，请在 `rancher-monitoring` Helm chart 中指定以下值：
|
||||
|
||||
```
|
||||
grafana.sidecar.dashboards.searchNamespace=ALL
|
||||
```
|
||||
|
||||
请注意，Monitoring Chart 用于添加 Grafana 仪表板的 RBAC 角色仅能让用户将仪表板添加到定义在 `grafana.dashboards.namespace` 中的命名空间，默认为 `cattle-dashboards`。
|
||||
+300
@@ -0,0 +1,300 @@
|
||||
---
|
||||
title: 接收器配置
|
||||
---
|
||||
|
||||
[Alertmanager Config](https://prometheus.io/docs/alerting/latest/configuration/#configuration-file) Secret 包含 Alertmanager 实例的配置，该实例根据 Prometheus 发出的告警发送通知。
|
||||
|
||||
:::note
|
||||
|
||||
本节参考假设你已经熟悉 Monitoring 组件的协同工作方式。有关 Alertmanager 的详细信息，请参阅[本节](../../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#3-alertmanager-工作原理)。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
## 在 Rancher UI 中创建接收器
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
- 已安装 Monitoring 应用。
|
||||
- 如果你使用现有的 Alertmanager Secret 配置 Monitoring，则它必须具有 Rancher 的 UI 支持的格式。否则，你将只能直接修改 Alertmanager Secret 来进行更改。请注意，对于通过使用路由和接收器 UI 支持的 Alertmanager 配置类型，我们会继续进行强化。因此如果你有增强功能的请求，请[提交 issue](https://github.com/rancher/rancher/issues/new)。
|
||||
|
||||
:::
|
||||
|
||||
要在 Rancher UI 中创建通知接收器：
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.6.5+">
|
||||
|
||||
1. 转到要创建接收器的集群。单击 **监控 -> 告警 -> AlertManagerConfigs**。
|
||||
1. 单击**创建**。
|
||||
1. 点击**添加接收器**。
|
||||
1. 输入接收器的**名称**。
|
||||
1. 为接收器配置一个或多个提供程序。如需获取填写表单的帮助，请参阅下方的配置选项。
|
||||
1. 单击**创建**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher 版本低于 v2.6.5">
|
||||
|
||||
1. 转到要创建接收器的集群。单击**监控**，然后单击**接收器**。
|
||||
2. 输入接收器的名称。
|
||||
3. 为接收器配置一个或多个提供程序。如需获取填写表单的帮助，请参阅下方的配置选项。
|
||||
4. 单击**创建**。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**结果**：告警可以向接收器发送通知。
|
||||
|
||||
## 接收器配置
|
||||
|
||||
通知集成是通过 `receiver` 配置的，[Prometheus](https://prometheus.io/docs/alerting/latest/configuration/#receiver) 文档对此进行了说明。
|
||||
|
||||
### 原生和非原生接收器
|
||||
|
||||
默认情况下，AlertManager 提供与一些接收器的原生集成，这些接收器在[本节](https://prometheus.io/docs/alerting/latest/configuration/#receiver)中列出。所有原生支持的接收器都可以通过 Rancher UI 进行配置。
|
||||
|
||||
对于 AlertManager 不提供原生支持的通知机制，可使用 [webhook 接收器](https://prometheus.io/docs/alerting/latest/configuration/#webhook_config)实现集成。你可以在[此处](https://prometheus.io/docs/operating/integrations/#alertmanager-webhook-receiver)找到提供此类集成的第三方驱动程序列表。Alerting Drivers 应用能让你访问这些驱动程序，以及它们相关的集成。启用后，你将可以在 Rancher UI 中配置非原生的接收器。
|
||||
|
||||
目前 Rancher Alerting Drivers 应用支持访问以下集成：
|
||||
- Microsoft Teams，基于 [prom2teams](https://github.com/idealista/prom2teams) 驱动程序
|
||||
- SMS，基于 [Sachet](https://github.com/messagebird/sachet) 驱动程序
|
||||
|
||||
你可以在 Rancher UI 中可以配置以下类型的接收器：
|
||||
|
||||
- <a href="#slack">Slack</a>
|
||||
- <a href="#email">电子邮件</a>
|
||||
- <a href="#pagerduty">PagerDuty</a>
|
||||
- <a href="#opsgenie">Opsgenie</a>
|
||||
- <a href="#webhook">Webhook</a>
|
||||
- <a href="#custom">自定义</a>
|
||||
- <a href="#teams">Teams</a>
|
||||
- <a href="#sms">SMS</a>
|
||||
|
||||
你可以在 YAML 中使用自定义接收器选项，从而配置无法通过 Rancher UI 表单配置的接收器。
|
||||
|
||||
## Slack
|
||||
|
||||
| 字段 | 类型 | 描述 |
|
||||
|------|--------------|------|
|
||||
| URL | String | 输入你的 Slack webhook URL。有关创建 Slack webhook 的说明，请参阅 [Slack 文档](https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack)。 |
|
||||
| 默认频道 | String | 输入要发送告警通知的频道名称。格式：`#<channelname>`。 |
|
||||
| 代理 URL | String | webhook 通知的代理。 |
|
||||
| 发送已解决告警 | Bool | 如果告警已解决（例如 [已解决] CPU 使用率过高问题），是否发送后续通知。 |
|
||||
|
||||
## 电子邮件
|
||||
|
||||
| 字段 | 类型 | 描述 |
|
||||
|------|--------------|------|
|
||||
| 默认收件人地址 | String | 接收通知的电子邮件地址。 |
|
||||
| 发送已解决告警 | Bool | 如果告警已解决（例如 [已解决] CPU 使用率过高问题），是否发送后续通知。 |
|
||||
|
||||
SMTP 选项：
|
||||
|
||||
| 字段 | 类型 | 描述 |
|
||||
|------|--------------|------|
|
||||
| 发件人 | String | 你的 SMTP 邮件服务器上可用的电子邮件地址，用于发送通知。 |
|
||||
| 主机 | String | SMTP 服务器的 IP 地址或主机名。示例：`smtp.email.com`。 |
|
||||
| 使用 TLS | Bool | 使用 TLS 进行加密。 |
|
||||
| 用户名 | String | 用户名，用于通过 SMTP 服务器进行身份验证。 |
|
||||
| 密码 | String | 密码，用于通过 SMTP 服务器进行身份验证。 |
|
||||
|
||||
## PagerDuty
|
||||
|
||||
| 字段 | 类型 | 描述 |
|
||||
|------|------|-------|
|
||||
| 集成类型 | String | `Events API v2` 或 `Prometheus`。 |
|
||||
| 默认集成密钥 | String | 有关获取集成密钥的说明，请参阅 [PagerDuty 文档](https://www.pagerduty.com/docs/guides/prometheus-integration-guide/)。 |
|
||||
| 代理 URL | String | PagerDuty 通知的代理。 |
|
||||
| 发送已解决告警 | Bool | 如果告警已解决（例如 [已解决] CPU 使用率过高问题），是否发送后续通知。 |
|
||||
|
||||
## Opsgenie
|
||||
|
||||
| 字段 | 描述 |
|
||||
|------|-------------|
|
||||
| API 密钥 | 有关获取 API 密钥的说明，请参阅 [Opsgenie 文档](https://docs.opsgenie.com/docs/api-key-management)。 |
|
||||
| 代理 URL | Opsgenie 通知的代理。 |
|
||||
| 发送已解决告警 | 如果告警已解决（例如 [已解决] CPU 使用率过高问题），是否发送后续通知。 |
|
||||
|
||||
Opsgenie 响应者：
|
||||
|
||||
| 字段 | 类型 | 描述 |
|
||||
|-------|------|--------|
|
||||
| 类型 | String | 计划程序、团队、用户或升级。有关告警响应者的更多信息，请参阅 [Opsgenie 文档](https://docs.opsgenie.com/docs/alert-recipients-and-teams)。 |
|
||||
| 发送至 | String | Opsgenie 收件人的 ID、名称或用户名。 |
|
||||
|
||||
## Webhook
|
||||
|
||||
| 字段 | 描述 |
|
||||
|-------|--------------|
|
||||
| URL | 你所选的应用的 Webhook URL。 |
|
||||
| 代理 URL | webhook 通知的代理。 |
|
||||
| 发送已解决告警 | 如果告警已解决（例如 [已解决] CPU 使用率过高问题），是否发送后续通知。 |
|
||||
|
||||
<!-- TODO add info on webhook for teams and sms and link to them -->
|
||||
|
||||
## 自定义
|
||||
|
||||
此处提供的 YAML 将直接附加到 Alertmanager Config Secret 的接收器中。
|
||||
|
||||
## Teams
|
||||
|
||||
### 为 Rancher 管理的集群启用 Teams 接收器
|
||||
|
||||
Teams 接收器不是原生接收器，因此需要启用后才能使用。你可以通过转到应用页面，安装 rancher-alerting-drivers 应用，然后选择 Teams 选项，从而为 Rancher 管理的集群启用 Teams 接收器。
|
||||
|
||||
1. 在 Rancher UI 中，转到要安装 rancher-alerting-drivers 的集群，然后单击 **Apps**。
|
||||
1. 点击 **Alerting Drivers** 应用。
|
||||
1. 单击 **Helm 部署选项**选项卡。
|
||||
1. 选择 **Teams** 并单击**安装**。
|
||||
1. 记下使用的命名空间，后续步骤中将需要该命名空间。
|
||||
|
||||
### 配置 Teams 接收器
|
||||
|
||||
可以通过更新 ConfigMap 来配置 Teams 接收器。例如，以下是最小的 Teams 接收器配置：
|
||||
|
||||
```yaml
|
||||
[Microsoft Teams]
|
||||
teams-instance-1: https://your-teams-webhook-url
|
||||
```
|
||||
|
||||
配置完成后，按照[本节](#在-rancher-ui-中创建接收器)中的步骤添加接收器。
|
||||
|
||||
使用以下示例作为 URL，其中：
|
||||
|
||||
- 将 `ns-1` 替换为安装 `rancher-alerting-drivers` 应用的命名空间。
|
||||
|
||||
```yaml
|
||||
url: http://rancher-alerting-drivers-prom2teams.ns-1.svc:8089/v2/teams-instance-1
|
||||
```
|
||||
|
||||
<!-- https://github.com/idealista/prom2teams -->
|
||||
|
||||
## SMS
|
||||
|
||||
### 为 Rancher 管理的集群启用 SMS 接收器
|
||||
|
||||
SMS 接收器不是原生接收器，因此需要启用后才能使用。你可以通过转到应用页面，安装 rancher-alerting-drivers 应用，然后选择 SMS 选项，从而为 Rancher 管理的集群启用 SMS 接收器。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要安装 `rancher-alerting-drivers` 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击**应用 & 应用市场**。
|
||||
1. 点击 **Alerting Drivers** 应用。
|
||||
1. 单击 **Helm 部署选项**选项卡。
|
||||
1. 选择 **SMS** 并单击**安装**。
|
||||
1. 记下使用的命名空间，后续步骤中将需要该命名空间。
|
||||
|
||||
### 配置 SMS 接收器
|
||||
|
||||
可以通过更新 ConfigMap 来配置 SMS 接收器。例如，以下是最小的 SMS 接收器配置：
|
||||
|
||||
```yaml
|
||||
providers:
|
||||
telegram:
|
||||
token: 'your-token-from-telegram'
|
||||
|
||||
receivers:
|
||||
- name: 'telegram-receiver-1'
|
||||
provider: 'telegram'
|
||||
to:
|
||||
- '123456789'
|
||||
```
|
||||
|
||||
配置完成后，按照[本节](#在-rancher-ui-中创建接收器)中的步骤添加接收器。
|
||||
|
||||
使用以下示例作为名称和 URL，其中：
|
||||
|
||||
- 分配给接收器的名称（例如 `telegram-receiver-1`）必须与 ConfigMap 中 `receivers.name` 字段中的名称（例如 `telegram-receiver-1`）匹配。
|
||||
- 将 URL 中的 `ns-1` 替换为安装 `rancher-alerting-drivers` 应用的命名空间。
|
||||
|
||||
```yaml
|
||||
name: telegram-receiver-1
|
||||
url http://rancher-alerting-drivers-sachet.ns-1.svc:9876/alert
|
||||
```
|
||||
|
||||
<!-- https://github.com/messagebird/sachet -->
|
||||
|
||||
|
||||
## 配置多个接收器
|
||||
|
||||
你可以编辑 Rancher UI 中的表单来设置一个接收器资源，其中包含 Alertmanager 将告警发送到你的通知系统所需的所有信息。
|
||||
|
||||
也可以向多个通知系统发送告警。一种方法是使用自定义 YAML 来配置接收器。如果你需要让两个系统接收相同的消息，则可以为多个通知系统添加配置。
|
||||
|
||||
你还可以通过使用路由的 `continue` 选项来设置多个接收器。这样，发送到接收器的告警会在路由树（可能包含另一个接收器）的下一级进行评估。
|
||||
|
||||
|
||||
## Alertmanager 配置示例
|
||||
|
||||
### Slack
|
||||
要通过 Slack 设置通知，你可以将以下 Alertmanager Config YAML 放入 Alertmanager Config Secret 的 `alertmanager.yaml` 键中，你需要更新 `api_url` 来使用来自 Slack 的 Webhook URL：
|
||||
|
||||
```yaml
|
||||
route:
|
||||
group_by: ['job']
|
||||
group_wait: 30s
|
||||
group_interval: 5m
|
||||
repeat_interval: 3h
|
||||
receiver: 'slack-notifications'
|
||||
receivers:
|
||||
- name: 'slack-notifications'
|
||||
slack_configs:
|
||||
- send_resolved: true
|
||||
text: '{{ template "slack.rancher.text" . }}'
|
||||
api_url: <user-provided slack webhook url here>
|
||||
templates:
|
||||
- /etc/alertmanager/config/*.tmpl
|
||||
```
|
||||
|
||||
### PagerDuty
|
||||
要通过 PagerDuty 设置通知，请使用 [PagerDuty 文档](https://www.pagerduty.com/docs/guides/prometheus-integration-guide/) 中的以下示例作为指导。此示例设置了一个路由，该路由捕获数据库服务的告警，并将告警发送到链接到服务的接收器，该服务将直接通知 PagerDuty 中的 DBA，而其他告警将被定向到具有不同 PagerDuty 集成密钥的默认接收器。
|
||||
|
||||
你可以将以下 Alertmanager Config YAML 放入 Alertmanager Config Secret 的 `alertmanager.yaml` 键中。你需要将 `service_key` 更新为使用你的 PagerDuty 集成密钥，可以根据 PagerDuty 文档的 "Integrating with Global Event Routing" 找到该密钥。有关配置选项的完整列表，请参阅 [Prometheus 文档](https://prometheus.io/docs/alerting/latest/configuration/#pagerduty_config)。
|
||||
|
||||
```yaml
|
||||
route:
|
||||
group_by: [cluster]
|
||||
receiver: 'pagerduty-notifications'
|
||||
group_interval: 5m
|
||||
routes:
|
||||
- match:
|
||||
service: database
|
||||
receiver: 'database-notifcations'
|
||||
|
||||
receivers:
|
||||
- name: 'pagerduty-notifications'
|
||||
pagerduty_configs:
|
||||
- service_key: 'primary-integration-key'
|
||||
|
||||
- name: 'database-notifcations'
|
||||
pagerduty_configs:
|
||||
- service_key: 'database-integration-key'
|
||||
```
|
||||
|
||||
## CIS 扫描告警的示例路由配置
|
||||
|
||||
在为 `rancher-cis-benchmark` 告警配置路由时，你可以使用键值对 `job:rancher-cis-scan` 来指定匹配。
|
||||
|
||||
例如，以下路由配置示例可以与名为 `test-cis` 的 Slack 接收器一起使用：
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
receiver: test-cis
|
||||
group_by:
|
||||
# - string
|
||||
group_wait: 30s
|
||||
group_interval: 30s
|
||||
repeat_interval: 30s
|
||||
match:
|
||||
job: rancher-cis-scan
|
||||
# key: string
|
||||
match_re:
|
||||
{}
|
||||
# key: string
|
||||
```
|
||||
|
||||
有关为 `rancher-cis-benchmark` 启用告警的更多信息，请参阅[本节](../../how-to-guides/advanced-user-guides/cis-scan-guides/enable-alerting-for-rancher-cis-benchmark.md)。
|
||||
|
||||
|
||||
## Notifiers 的可信 CA
|
||||
|
||||
如果你需要将受信任的 CA 添加到 Notifiers，请按照[本节](helm-chart-options.md#notifiers-的可信-ca)中的步骤操作。
|
||||
+88
@@ -0,0 +1,88 @@
|
||||
---
|
||||
title: 路由配置
|
||||
---
|
||||
|
||||
路由（Route）配置是 Alertmanager 自定义资源的一部分，用于控制 Prometheus 触发的告警在到达接收器之前的分组和过滤方式。
|
||||
|
||||
当路由更改时，Prometheus Operator 会重新生成 Alertmanager 自定义资源以反映更改。
|
||||
|
||||
有关配置路由的更多信息，请参阅[官方 Alertmanager 文档](https://www.prometheus.io/docs/alerting/latest/configuration/#route)。
|
||||
|
||||
:::note
|
||||
|
||||
本节参考假设你已经熟悉 Monitoring 组件的协同工作方式。有关详细信息，请参阅[本节](../../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md)。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
|
||||
## 路由限制
|
||||
|
||||
Alertmanager 根据接收器和路由树来代理 Prometheus 的告警，该路由树根据标签将告警过滤到指定接收器。
|
||||
|
||||
Alerting Drivers 为 Alertmanager 将告警代理到非原生接收器，例如 Microsoft Teams 和 SMS。
|
||||
|
||||
在配置路由和接收器的 Rancher UI 中，你可以配置有一个根的路由树，然后再配置一个深度，这样的树就有两个深度。但是如果在直接配置 Alertmanager 时使用 `continue` 路由，你可以让树更深。
|
||||
|
||||
每个接收器用于一个或多个通知提供商。因此，如果你需要将发送到 Slack 的每个告警也发送到 PagerDuty，你可以在同一个接收器中配置两者。
|
||||
|
||||
## 路由配置
|
||||
|
||||
### 标签和注释的注意事项
|
||||
|
||||
标签用于识别可能影响通知路由的信息。告警的标识信息可能包括容器名称，或应接收通知的团队的名称。
|
||||
|
||||
注释用于标识不影响告警接收者的信息，例如 Runbook URL 或错误消息。
|
||||
|
||||
|
||||
### 接收器
|
||||
路由需要引用一个已经配置好的[接收器](./receivers.md)。
|
||||
|
||||
### 分组
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.6.5+">
|
||||
|
||||
:::note
|
||||
|
||||
从 Rancher 2.6.5 开始，`分组依据`开始接受字符串列表而不是键值对。有关详细信息，请参阅[上游文档](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#route)。
|
||||
|
||||
:::
|
||||
|
||||
| 字段 | 默认 | 描述 |
|
||||
|-------|--------------|---------|
|
||||
| 分组依据 | N/A | 用于分组的标签列表。标签不得重复（在列表内）。如果提供了特殊标签“...”（由所有可能的标签聚合），标签必须在列表中是唯一的元素。 |
|
||||
| 组等待时长 | 30s | 在发送之前，缓冲同一组告警的等待时间。 |
|
||||
| 组间隔 | 5m | 等待多长时间才发送已添加到告警组的告警，其中该告警组的初次通知已被发送。 |
|
||||
| 重复间隔 | 4h | 等待多长时间后，才重新发送已发送的告警。 |
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher 版本低于 v2.6.5">
|
||||
|
||||
| 字段 | 默认 | 描述 |
|
||||
|-------|--------------|---------|
|
||||
| 分组依据 | N/A | 将传入告警进行分组的标签。例如，`[ group_by: '[' <labelname>, ... ']' ]`。针对 `cluster=A` 和 `alertname=LatencyHigh` 等标签的多个告警可以批处理到一个组中。要按所有可能的标签进行聚合，请使用特殊值 `'...'` 作为唯一标签名称，如 `group_by: ['...']`。以 `...` 进行分组能有效地完全禁用聚合，并按原样传递所有告警。除非你的告警量非常低或者你的上游通知系统能执行分组，否则你不太需要这样做。 |
|
||||
| 组等待时长 | 30s | 在发送之前，缓冲同一组告警的等待时间。 |
|
||||
| 组间隔 | 5m | 等待多长时间才发送已添加到告警组的告警，其中该告警组的初次通知已被发送。 |
|
||||
| 重复间隔 | 4h | 等待多长时间后，才重新发送已发送的告警。 |
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
### 匹配
|
||||
|
||||
**Match** 字段指一组相等匹配器，用于根据告警上定义的标签来识别要发送到指定路由的告警。在 Rancher UI 中添加键值对时，它们对应于以下格式的 YAML：
|
||||
|
||||
```yaml
|
||||
match:
|
||||
[ <labelname>: <labelvalue>, ... ]
|
||||
```
|
||||
|
||||
**Match Regex** 字段指一组正则表达式匹配器，用于根据在该告警上定义的标签来识别要发送到指定路由的告警。在 Rancher UI 中添加键值对时，它们对应于以下格式的 YAML：
|
||||
|
||||
```yaml
|
||||
match_re:
|
||||
[ <labelname>: <regex>, ... ]
|
||||
```
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: ServiceMonitor 和 PodMonitor 配置
|
||||
---
|
||||
|
||||
ServiceMonitor 和 PodMonitor 都是伪 CRD，它们映射 Prometheus 自定义资源的抓取配置。
|
||||
|
||||
这些配置对象以声明方式指定 Prometheus 抓取指标的端点。
|
||||
|
||||
ServiceMonitor 比 PodMonitor 更常用，推荐用于大多数用例。
|
||||
|
||||
:::note
|
||||
|
||||
本节参考假设你已经熟悉 Monitoring 组件的协同工作方式。有关 Alertmanager 的详细信息，请参阅[本节](../../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md)。
|
||||
|
||||
:::
|
||||
|
||||
### ServiceMonitor
|
||||
|
||||
这个伪 CRD 映射到 Prometheus 自定义资源配置的一部分。它以声明方式指定应如何监控 Kubernetes 服务组。
|
||||
|
||||
创建 ServiceMonitor 时，Prometheus Operator 会更新 Prometheus 抓取配置，从而包含 ServiceMonitor 配置。然后 Prometheus 开始从 ServiceMonitor 中定义的端点抓取指标。
|
||||
|
||||
如果集群中的任何 Service 与 ServiceMonitor `selector` 字段中的标签匹配，则会根据 ServiceMonitor 指定的 `endpoints` 进行监控。有关可以指定的字段的更多信息，请查看 Prometheus Operator 的[规范](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#servicemonitor)。
|
||||
|
||||
有关 ServiceMonitor 工作原理的更多信息，请参阅 [Prometheus Operator 文档](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/running-exporters.md)。
|
||||
|
||||
### PodMonitor
|
||||
|
||||
这个伪 CRD 映射到 Prometheus 自定义资源配置的一部分。它以声明方式指定应如何监控 Pod 组。
|
||||
|
||||
创建 PodMonitor 时，Prometheus Operator 会更新 Prometheus 抓取配置，从而包含 PodMonitor 配置。然后 Prometheus 开始从 PodMonitor 中定义的端点抓取指标。
|
||||
|
||||
如果集群中的任何 Pod 与 PodMonitor `selector` 字段中的标签匹配，则会根据 PodMonitor 指定的 `podMetricsEndpoints` 进行监控。有关可以指定的字段的更多信息，请查看 Prometheus Operator 的[规范](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#podmonitorspec)。
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: RBAC
|
||||
---
|
||||
|
||||
本文介绍 Prometheus Federator RBAC。
|
||||
|
||||
如[命名空间](../../pages-for-subheaders/prometheus-federator.md#命名空间)部分所述，Prometheus Federator 期望集群中具有项目级别权限（例如，具有由单个标签选择器确定的命名空间组的权限）的项目所有者、项目成员和其他用户，除了项目 Registration 命名空间（默认导入到项目中）和那些已经包含其项目的命名空间之外，在任何其他命名空间中都只有最低权限。因此，为了让项目所有者将特定 Chart 权限分配给其项目命名空间中的其他用户，Helm Project Operator 将自动监视以下绑定：
|
||||
|
||||
- ClusterRoleBindings
|
||||
- 项目发布命名空间中的 RoleBindings
|
||||
|
||||
如果 Helm Project Operator 观察到其中一种绑定的更改，Helm Project Operator 会检查绑定指向的 `roleRef` 是否与具有以下名称的 ClusterRole 匹配：
|
||||
|
||||
- `helmProjectOperator.releaseRoleBindings.clusterRoleRefs.admin`
|
||||
- `helmProjectOperator.releaseRoleBindings.clusterRoleRefs.edit`
|
||||
- `helmProjectOperator.releaseRoleBindings.clusterRoleRefs.view`
|
||||
|
||||
默认情况下，这些 roleRef 分别对应 `admin`、`edit` 和 `view`，它们都是 [Kubernetes 面向用户的默认角色](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)。
|
||||
|
||||
:::note
|
||||
|
||||
对于 Rancher RBAC 用户，这些 [Kubernetes 面向用户的默认角色](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)与`项目所有者`、`项目成员`和`只读`默认项目角色模板直接对应。
|
||||
|
||||
:::
|
||||
|
||||
如果 `roleRef` 匹配，Helm Project Operator 将为所有用户和组过滤绑定的 `subjects`，并使用它为项目 Release 命名空间中的每个角色自动构造一个 RoleBinding，该 RoleBinding 的名称与角色相同并带有以下标签：
|
||||
|
||||
- `helm.cattle.io/project-helm-chart-role: {{ .Release.Name }}`
|
||||
- `helm.cattle.io/project-helm-chart-role-aggregate-from: <admin|edit|view>`
|
||||
|
||||
默认情况下，Prometheus Federator 部署的底层 Chart `rancher-project-monitoring` 会为每个项目发布命名空间创建三个默认角色，这些角色能授权 `admin`、`edit` 和 `view` 用户查看项目监控堆栈的 Prometheus、Alertmanager 和 Grafana UI，从而提供最低权限。如果集群管理员想要为某些用户分配额外的权限，一种做法是直接将项目 Release 命名空间中的 RoleBinding 分配给某些用户。另一种做法是创建带有上述两个标签的角色，然后，项目所有者可以控制在项目 Registration 命名空间中分配这些 RBAC 角色的用户。
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: 集群工具：Logging，Monitoring 和可视化
|
||||
---
|
||||
|
||||
Rancher 包含 Kubernetes 中未包含的各种工具来协助你进行 DevOps 操作。Rancher 可以与外部服务集成，让你的集群更高效地运行。工具分为以下几类：
|
||||
|
||||
|
||||
## Logging
|
||||
|
||||
Logging 支持：
|
||||
|
||||
- 获取和分析集群的状态
|
||||
- 在你的环境中发现趋势
|
||||
- 将日志保存到集群外部的安全位置
|
||||
- 随时了解容器崩溃、pod 驱逐或节点死亡等事件
|
||||
- 更轻松地调试和解决问题
|
||||
|
||||
Rancher 可以与 Elasticsearch、splunk、kafka、syslog 和 fluentd 集成。
|
||||
|
||||
有关详细信息，请参阅 [Logging 文档](../pages-for-subheaders/logging.md)。
|
||||
## 监控和告警
|
||||
|
||||
你可以使用 Rancher，通过业界领先并开源的 [Prometheus](https://prometheus.io/) 来监控集群节点、Kubernetes 组件和软件部署的状态和进程。
|
||||
|
||||
启用监控后，你可以通过设置告警和通知器来配置接收告警的机制。
|
||||
|
||||
通知器是通知你告警事件的服务。你可以通过配置通知器来向最适合采取纠正措施的员工发送告警通知。支持使用 Slack、电子邮件、PagerDuty、微信和 webhook 发送通知。
|
||||
|
||||
告警是触发这些通知的规则。在接收告警之前，你必须在 Rancher 中配置一个或多个通知器。你可以在集群或项目级别设置告警范围。
|
||||
|
||||
如需更多信息，请参阅[监控文档](../pages-for-subheaders/monitoring-and-alerting.md)。
|
||||
|
||||
## Istio
|
||||
|
||||
[Istio](https://istio.io/) 是一种开源工具，可以让 DevOps 团队更轻松地观察、控制、排查并保护复杂的微服务网络中的流量。
|
||||
|
||||
Rancher v2.5 改进了与 Istio 的集成。
|
||||
|
||||
如需更多信息，请参阅 [Istio 文档](../pages-for-subheaders/istio.md)。
|
||||
## OPA Gatekeeper
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 是一个开源项目，它对 OPA 和 Kubernetes 进行了集成，以通过许可控制器 Webhook 提供策略控制。有关如何在 Rancher 中启用 Gatekeeper 的详细信息，请参阅 [OPA Gatekeeper](../integrations-in-rancher/opa-gatekeeper.md)。
|
||||
|
||||
## CIS 扫描
|
||||
|
||||
Rancher 可以通过运行安全扫描来检查 Kubernetes 是否按照 CIS Kubernetes Benchmark 中定义的安全最佳实践进行部署。
|
||||
|
||||
如需更多信息，请参阅 [CIS 扫描文档](../pages-for-subheaders/cis-scan-guides.md)。
|
||||
+106
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title: 架构推荐
|
||||
---
|
||||
|
||||
如果你准备在单个节点上安装 Rancher，我们推荐你[分开部署 Rancher 与下游集群](#分开部署-rancher-与下游集群)。
|
||||
|
||||
## 分开部署 Rancher 与下游集群
|
||||
|
||||
下游集群，是运行你自己的应用和服务的下游 Kubernetes 集群。
|
||||
|
||||
如果你通过 Docker 安装了 Rancher，运行 Rancher Server 的节点应该与你的下游集群分开。
|
||||
|
||||
如果你需要使用 Rancher 管理下游 Kubernetes 集群，那么运行 Rancher Server 的 Kubernetes 集群也应该与下游集群分开。
|
||||
|
||||
|
||||
|
||||
## 为什么高可用（HA）更适合生产环境中的 Rancher
|
||||
|
||||
我们建议在高可用 Kubernetes 集群上安装 Rancher Server，以保护 Rancher Server 的数据。在高可用安装中，负载均衡器充当客户端的单点入口，并在集群中的多台服务器之间分配网络流量，这有助于防止任何一台服务器成为单点故障。
|
||||
|
||||
我们不建议在单个 Docker 容器中安装 Rancher，因为如果该节点发生故障，则其他节点上将没有可用的集群数据副本，并且你可能会丢失 Rancher Server 上的数据。
|
||||
|
||||
### K3s Kubernetes 集群安装
|
||||
|
||||
底层 Kubernetes 集群的一种选择是使用 K3s Kubernetes。K3s 是 Rancher CNCF 认证的 Kubernetes 发行版。K3s 易于安装，仅需要 Kubernetes 内存的一半，所有组件都在一个小于 100 MB 的二进制文件中。K3s 的另一个优点是允许外部 Datastore 保存集群数据，因此可以把 K3s 服务器节点视为无状态。
|
||||
|
||||
<figcaption>运行 Rancher Management Server 的 K3s Kubernetes 集群的架构</figcaption>
|
||||
|
||||
|
||||
|
||||
### RKE Kubernetes 集群安装
|
||||
|
||||
在 RKE 安装中，集群数据在集群中的三个 etcd 节点上复制，以在某个节点发生故障时提供冗余和进行数据复制。
|
||||
|
||||
<figcaption>运行 Rancher Management Server 的 RKE Kubernetes 集群的架构</figcaption>
|
||||
|
||||
|
||||
|
||||
## Kubernetes 安装的负载均衡器推荐配置
|
||||
|
||||
我们建议你为负载均衡器和 Ingress Controller 使用以下配置：
|
||||
|
||||
* 把 Rancher 的 DNS 解析到四层负载均衡器上。
|
||||
* 负载均衡器应该把 TCP/80 端口和 TCP/443 端口的流量转发到 Kubernetes 集群的全部 3 个节点上。
|
||||
* Ingress Controller 会把 HTTP 重定向到 HTTPS，在 TCP/443 端口终结 SSL/TLS。
|
||||
* Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>在 Kubernetes 集群中安装 Rancher，并使用四层负载均衡器，SSL 终止在 Ingress Controller 中</figcaption>
|
||||
|
||||
|
||||
|
||||
## Kubernetes 安装环境
|
||||
|
||||
我们强烈建议你把 Rancher 安装到托管在云提供商（如 AWS EC2 和 Google Compute Engine（GCE）等）上的 Kubernetes 集群上。
|
||||
|
||||
为了达到最佳性能和安全性，我们建议你为 Rancher Management Server 创建一个专用的 Kubernetes 集群。不建议在此集群上运行用户工作负载。部署 Rancher 后，你可以[创建或导入集群](../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)来运行你的工作负载。
|
||||
|
||||
## Kubernetes 安装的推荐节点角色
|
||||
|
||||
如果 Rancher 安装在 K3s Kubernetes 或 RKE Kubernetes 集群上，以下建议适用。
|
||||
|
||||
### K3s 集群角色
|
||||
|
||||
在 K3s 集群中有两种类型的节点，分别是 Server 节点和 Agent 节点。你可以把工作负载调度到 Server 节点和 Agent 节点上。Server 节点运行 Kubernetes master。
|
||||
|
||||
对于运行 Rancher Management Server 的集群，我们建议使用两个 server 节点。不需要 Agent 节点。
|
||||
|
||||
### RKE 集群角色
|
||||
|
||||
如果 Rancher 安装在 RKE Kubernetes 集群上，该集群应具有三个节点，并且每个节点都应具有所有三个 Kubernetes 角色，分别是 etcd，controlplane 和 worker。
|
||||
|
||||
### Rancher Server 和下游 Kubernetes 集群的 RKE 集群架构对比
|
||||
|
||||
我们对 Rancher Server 集群上 RKE 节点角色建议，与对运行你的应用和服务的下游集群的建议相反。
|
||||
|
||||
在配置下游 Kubernetes 集群时，Rancher 使用 RKE 作为创建下游 Kubernetes 集群的工具。注意：Rancher 将在未来的版本中添加配置下游 K3s 集群的功能。
|
||||
|
||||
我们建议下游 Kubernetes 集群中的每个节点都只分配一个角色，以确保稳定性和可扩展性。
|
||||
|
||||
|
||||
|
||||
RKE 每个角色至少需要一个节点，但并不强制每个节点只能有一个角色。但是，我们建议为运行应用的集群中的每个节点，使用单独的角色，以保证在服务拓展时，worker 节点上的工作负载不影响 Kubernetes master 或集群的数据。
|
||||
|
||||
以下是我们对下游集群的最低配置建议：
|
||||
|
||||
- **三个仅使用 etcd 角色的节点** ，以在三个节点中其中一个发生故障时，仍能保障集群的高可用性。
|
||||
- **两个只有 controlplane 角色的节点** ，以保证 master 组件的高可用性。
|
||||
- **一个或多个只有 worker 角色的节点**，用于运行 Kubernetes 节点组件，以及你部署的服务或应用的工作负载。
|
||||
|
||||
在设置 Rancher Server 时，在三个节点上使用全部这三个角色也是安全的，因为：
|
||||
|
||||
* 它允许一个 `etcd` 节点故障。
|
||||
* 它通过多个 `controlplane` 节点来维护 master 组件的多个实例。
|
||||
* 此集群上没有创建除 Rancher 之外的其他工作负载。
|
||||
|
||||
由于 Rancher Server 集群中没有部署其他工作负载，因此在大多数情况下，这个集群都不需要使用我们出于可扩展性和可用性的考虑，而为下游集群推荐的架构。
|
||||
|
||||
有关下游集群的最佳实践，请查看[生产环境清单](../../pages-for-subheaders/checklist-for-production-ready-clusters.md)或[最佳实践](../../pages-for-subheaders/best-practices.md)。
|
||||
|
||||
## 授权集群端点架构
|
||||
|
||||
如果你使用[授权集群端点（ACE）](../../pages-for-subheaders/rancher-manager-architecture.md#4-授权集群端点)，我们建议你创建一个指向负载均衡器的 FQDN，这个负载均衡器把流量转到所有角色为 `controlplane` 的节点。
|
||||
|
||||
如果你在负载均衡器上使用了私有 CA 签发的证书，你需要提供 CA 证书，这个证书会包含在生成的 kubeconfig 文件中，以校验证书链。详情请参见 [kubeconfig 文件](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md)和 [API 密钥](../user-settings/api-keys.md#创建-api-密钥)的相关文档。
|
||||
|
||||
在 Rancher 2.6.3 中，注册的 RKE2 和 K3s 集群可以使用 ACE 支持。点击[这里](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#对-rke2-和-k3s-集群的授权集群端点支持)了解在下游集群中开启 ACE 的步骤。
|
||||
+132
@@ -0,0 +1,132 @@
|
||||
---
|
||||
title: 与下游集群通信
|
||||
---
|
||||
|
||||
本节介绍 Rancher 如何配置和管理运行应用和服务的下游集群。
|
||||
|
||||
下图显示了 Cluster Controller、Cluster Agent 和 Node Agent 让 Rancher 控制下游集群的。
|
||||
|
||||
<figcaption>与下游集群通信</figcaption>
|
||||
|
||||
|
||||
|
||||
以下描述对应于上图中的数字：
|
||||
|
||||
1. [认证代理](#1-认证代理)
|
||||
2. [Cluster Controller 和 Cluster Agent](#2-cluster-controller-和-cluster-agent)
|
||||
3. [Node Agents](#3-node-agents)
|
||||
4. [授权集群端点](#4-授权集群端点)
|
||||
|
||||
### 1. 认证代理
|
||||
|
||||
在此图中，名为 Bob 的用户希望查看在名为 User Cluster 1 的下游集群上运行的所有 Pod。在 Rancher 中，他可以运行 `kubectl` 命令来查看
|
||||
Pod。Bob 通过 Rancher 的认证代理进行身份验证。
|
||||
|
||||
认证代理将所有 Kubernetes API 调用转发到下游集群。它集成了本地身份验证、Active Directory 和 GitHub 等身份验证方式。在每个 Kubernetes API 调用请求时，认证代理会验证请求方的身份，并在转发给 Kubernetes master 节点之前，设置正确的 Kubernetes 消息头。
|
||||
|
||||
Rancher 使用 [ServiceAccount](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) 与 Kubernetes 集群通信，该 ServiceAccount 为在 Pod 中运行的进程提供身份。
|
||||
|
||||
默认情况下，Rancher 生成一个 [kubeconfig 文件](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md)，文件包含凭证信息，用于为 Rancher Server 连接下游集群的 Kubernetes API Server 的代理。kubeconfig 文件 (`kube_config_rancher-cluster.yml`) 包含对集群的完全访问权限。
|
||||
|
||||
### 2. Cluster Controller 和 Cluster Agent
|
||||
|
||||
每个下游集群都有一个 Cluster Agent，用于打开与 Rancher Server 中对应的 Cluster Controller 之间的通道。
|
||||
|
||||
每个下游集群有一个 Cluster Controller 和一个 Cluster Agent。每个 Cluster Controller 都能：
|
||||
|
||||
- 检测下游集群中的资源变化
|
||||
- 将下游集群的当前状态变更到目标状态
|
||||
- 配置集群和项目的访问控制策略
|
||||
- 通过调用所需的 Docker Machine 驱动和 Kubernetes 引擎（例如 RKE 和 GKE）来配置集群
|
||||
|
||||
默认情况下，Cluster Controller 连接到 Cluster Agent，Rancher 才能与下游集群通信。如果 Cluster Agent 不可用，Cluster Controller 可以连接到 [Node Agent](#3-node-agents)。
|
||||
|
||||
Cluster Agent，也叫做 `cattle-cluster-agent`，是运行在下游集群中的组件。它具有以下功能：
|
||||
|
||||
- 连接 Rancher 启动的 Kubernetes 集群中的 Kubernetes API。
|
||||
- 管理集群内的工作负载，pod 创建和部署。
|
||||
- 根据每个集群的全局策略，应用定义的角色和绑定。
|
||||
- 通过与 Cluster Controller 之间的通道，实现集群和 Rancher Server 之间的通信，包括事件，统计数据，节点信息和健康状况。
|
||||
|
||||
### 3. Node Agents
|
||||
|
||||
如果 Cluster Agent（也称为 `cattle-cluster-agent`）不可用，其中一个 Node Agent 会创建一个连接到 Cluster Controller 的通道与 Rancher 通信。
|
||||
|
||||
`cattle-node-agent` 使用 [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) 资源进行部署，以确保它能在 Rancher 启动的 Kubernetes 集群中的每个节点上运行，用于在执行集群操作时与节点交互。集群操作的包括升级 Kubernetes 版本，创建或恢复 etcd 快照等。
|
||||
|
||||
### 4. 授权集群端点
|
||||
|
||||
授权集群端点（ACE）可连接到下游集群的 Kubernetes API Server，而不用通过 Rancher 认证代理调度请求。
|
||||
|
||||
> 授权集群端点仅适用于 Rancher 启动的 Kubernetes 集群，即只适用于 Rancher [使用 RKE](../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 来配置的集群。它不适用于导入的集群，也不适用于托管在 Kubernetes 提供商中的集群（例如 Amazon 的 EKS）。
|
||||
|
||||
授权集群端点的主要用途：
|
||||
|
||||
- 在 Rancher 不可用时访问下游集群
|
||||
- 在 Rancher Server 和与下游集群之间相距甚远时降低延迟
|
||||
|
||||
`kube-api-auth` 微服务为授权集群端点提供用户验证功能。当使用 `kubectl`访问下游集群时，集群的 Kubernetes API Server 使用 `kube-api-auth` 服务作为 webhook 对用户进行身份验证。
|
||||
|
||||
与授权集群端点一样，`kube-api-auth` 的身份验证功能也仅适用于 Rancher 启动的 Kubernetes 集群。
|
||||
|
||||
> **示例场景：** 假设 Rancher Server 位于美国，User Cluster 1 与用户 Alice 均位于澳大利亚。Alice 可以使用 Rancher UI 操作 User Cluster 1 中的资源，但她的请求必须从澳大利亚发送到美国的 Rancher Server，然后通过代理返回澳大利亚，即下游集群所在的位置。地理距离可能导致明显延迟，因此，Alice 可以使用授权集群端点来降低延迟。
|
||||
|
||||
为下游集群启用授权集群端点后，Rancher 会在 kubeconfig 文件中额外生成一段 Kubernetes 上下文，用于直连到集群。该文件具有 `kubectl` 和 `helm`的凭证。
|
||||
|
||||
如果 Rancher 出现问题，你需要使用此 kubeconfig 文件中定义的上下文来访问集群。因此，我们建议你导出 kubeconfig 文件，以便在 Rancher 出现问题时，仍能使用文件中的凭证访问集群。详情请参见使用 [kubectl 和 kubeconfig 文件](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md)访问集群的章节。
|
||||
|
||||
## 重要文件
|
||||
|
||||
维护、排除问题和升级集群需要用到以下文件，请妥善保管这些文件：
|
||||
|
||||
- `rancher-cluster.yml`：RKE 集群配置文件。
|
||||
- `kube_config_rancher-cluster.yml`：集群的 Kubeconfig 文件，包含完全访问集群的凭证。如果 Rancher 出现问题时，你可以使用此文件认证由 Rancher 启动的 Kubernetes 集群。
|
||||
- `rancher-cluster.rkestate`：Kubernetes 集群状态文件，文件包含用于完全访问集群的凭证。注意：仅在使用 RKE v0.2.0 或更高版本时，才会创建此该文件。
|
||||
|
||||
> **注意**：后两个文件名中的 `rancher-cluster` 部分取决于你命名 RKE 集群配置文件的方式。
|
||||
|
||||
有关在没有 Rancher 认证代理和其他配置选项的情况下连接到集群的更多信息，请参见 [kubeconfig 文件](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md)。
|
||||
|
||||
## 配置 Kubernetes 集群的工具
|
||||
|
||||
Rancher 使用什么工具配置下游集群，取决于集群的类型。
|
||||
|
||||
### Rancher 为托管在云提供商中的节点启动 Kubernetes
|
||||
|
||||
Rancher 可以动态启动云上（如 Amazon EC2、DigitalOcean、Azure 或 vSphere 等）的节点，然后在节点上安装 Kubernetes。
|
||||
|
||||
Rancher 使用 [RKE](https://github.com/rancher/rke) 和 [docker-machine](https://github.com/rancher/machine) 来配置这类型的集群。
|
||||
|
||||
### Rancher 为自定义节点启动 Kubernetes
|
||||
|
||||
在配置此类集群时，Rancher 会在现有节点上安装 Kubernetes，从而创建自定义集群。
|
||||
|
||||
Rancher 使用 [RKE](https://github.com/rancher/rke) 来启动此类集群。
|
||||
|
||||
### 托管的 Kubernetes 提供商
|
||||
|
||||
配置此类集群时，Kubernetes 由云提供商安装，如 GKE、ECS 或 AKS 等。
|
||||
|
||||
Rancher 使用 [kontainer-engine](https://github.com/rancher/kontainer-engine) 配置此类型的集群。
|
||||
|
||||
### 导入的 Kubernetes 集群
|
||||
|
||||
这种情况下，Rancher 需要连接到一个设置好的 Kubernetes 集群。因此，Rancher 不提供 Kubernetes，只设置 Rancher Agent 实现与集群通信。
|
||||
|
||||
## Rancher Server 组件和源码
|
||||
|
||||
下图展示了 Rancher Server 的组件：
|
||||
|
||||
|
||||
|
||||
Rancher 的 GitHub 代码仓库如下：
|
||||
|
||||
- [Rancher Server 主代码库](https://github.com/rancher/rancher)
|
||||
- [Rancher UI](https://github.com/rancher/ui)
|
||||
- [Rancher API UI](https://github.com/rancher/api-ui)
|
||||
- [Norman](https://github.com/rancher/norman)（Rancher 的 API 框架）
|
||||
- [类型](https://github.com/rancher/types)
|
||||
- [Rancher CLI](https://github.com/rancher/cli)
|
||||
- [应用商店](https://github.com/rancher/helm)
|
||||
|
||||
以上仅列出部分 Rancher 最重要的仓库。详情请参见[参与 Rancher 开源贡献](../../contribute-to-rancher.md#仓库)。如需获取 Rancher 使用的所有库和项目，请参见 `rancher/rancher` 仓库中的 [`go.mod` 文件](https://github.com/rancher/rancher/blob/master/go.mod)。
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: Rancher Server 和 Components
|
||||
---
|
||||
|
||||
大多数 Rancher 2.x 软件均运行在 Rancher Server 上。Rancher Server 包括用于管理整个 Rancher 部署的所有软件组件。
|
||||
|
||||
下图展示了 Rancher 2.x 的上层架构。下图中，Rancher Server 管理两个下游 Kubernetes 集群，其中一个由 RKE 创建，另一个由 Amazon EKS 创建。
|
||||
|
||||
为了达到最佳性能和安全性，我们建议你为 Rancher Management Server 创建一个专用的 Kubernetes 集群。不建议在此集群上运行用户工作负载。部署 Rancher 后，你可以[创建或导入集群](../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)来运行你的工作负载。
|
||||
|
||||
下图介绍了用户如何通过 Rancher 的认证代理管理 [Rancher 启动的 Kubernetes](../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 集群和[托管的 Kubernetes](../../pages-for-subheaders/set-up-clusters-from-hosted-kubernetes-providers.md) 集群：
|
||||
|
||||
<figcaption>通过 Rancher 的认证代理管理 Kubernetes 集群</figcaption>
|
||||
|
||||
|
||||
|
||||
你可以把 Rancher 安装到单个节点或高可用 Kubernetes 集群上。
|
||||
|
||||
在生产环境中，建议安装到高可用 Kubernetes 集群。
|
||||
|
||||
Rancher 的 Docker 安装仅推荐用于开发和测试环境中。Rancher 版本决定了能否将 Rancher 迁移到高可用集群。
|
||||
|
||||
要查看已部署的资源，运行以下命令：
|
||||
|
||||
```bash
|
||||
kubectl get all -n <namespace>
|
||||
```
|
||||
如果你具有管理员权限，你还可以在 Rancher UI 中看到列出的资源：
|
||||
|
||||
1. 单击 **☰** 并选择一个集群。
|
||||
1. 从侧面导航菜单中选择**更多资源**，从而按类型查看已部署的资源。
|
||||
1. 从侧面导航菜单中选择**集群** > **项目/命名空间**，然后选择一个命名空间，从而按命名空间查看已部署的资源。
|
||||
Rancher backup operator 可将 Rancher 从单个 Docker 容器迁移到高可用 Kubernetes 集群上。有关详细信息，请参阅[将 Rancher 迁移到新集群](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
|
||||
|
||||
不管 Rancher Server 是如何安装的，它都应该运行在与其管理的下游集群不同节点上。如果 Rancher 安装在高可用的 Kubernetes 集群上，它需要运行在与其管理的集群不同的集群上。
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: 项目工具：Logging，Monitoring 和可视化
|
||||
---
|
||||
|
||||
Rancher 包含 Kubernetes 中未包含的各种工具来协助你进行 DevOps 操作。Rancher 可以与外部服务集成，让你的集群更高效地运行。
|
||||
|
||||
|
||||
## Notifiers 和告警
|
||||
|
||||
通知器和告警是两个协同工作的功能，它们可以将 Rancher 系统中的事件告知你。在启用它们之前，你必须先安装监控应用。
|
||||
|
||||
通知器是通知你告警事件的服务。你可以通过配置通知器来向最适合采取纠正措施的员工发送告警通知。支持使用 Slack、电子邮件、PagerDuty、微信和 webhook 发送通知。
|
||||
|
||||
告警是触发这些通知的规则。在接收告警之前，你必须在 Rancher 中配置一个或多个通知器。你可以在集群或项目级别设置告警范围。
|
||||
|
||||
## Logging
|
||||
|
||||
Logging 支持：
|
||||
|
||||
- 获取和分析集群的状态
|
||||
- 在你的环境中发现趋势
|
||||
- 将日志保存到集群外部的安全位置
|
||||
- 随时了解容器崩溃、pod 驱逐或节点死亡等事件
|
||||
- 更轻松地调试和解决问题
|
||||
|
||||
Rancher 可以与 Elasticsearch、splunk、kafka、syslog 和 fluentd 集成。
|
||||
|
||||
有关详细信息，请参阅 [Logging](../pages-for-subheaders/logging.md)。
|
||||
|
||||
## Monitoring
|
||||
|
||||
你可以使用 Rancher，通过业界领先并开源的 [Prometheus](https://prometheus.io/) 来监控集群节点、Kubernetes 组件和软件部署的状态和进程。有关详细信息，请参阅 [Monitoring](../pages-for-subheaders/monitoring-and-alerting.md)。
|
||||
+3148
File diff suppressed because it is too large
Load Diff
+3148
File diff suppressed because it is too large
Load Diff
+3148
File diff suppressed because it is too large
Load Diff
+3083
File diff suppressed because one or more lines are too long
+3084
File diff suppressed because one or more lines are too long
+3085
File diff suppressed because one or more lines are too long
+3196
File diff suppressed because one or more lines are too long
+3196
File diff suppressed because one or more lines are too long
+3196
File diff suppressed because one or more lines are too long
+11
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: Kubernetes 安全最佳实践
|
||||
---
|
||||
|
||||
### 限制云元数据 API 访问
|
||||
|
||||
AWS、Azure、DigitalOcean 或 GCP 等云提供商通常会在本地向实例公开元数据服务。默认情况下，此端点可被运行在云实例上的 pod 访问，包括在托管的 Kubernetes（如 EKS、AKS、DigitalOcean Kubernetes 或 GKE）中的 pod，并且可以包含该节点的云凭证、配置数据（如 kubelet 凭证）以及其他敏感数据。为了降低在云平台上运行的这种风险，请遵循 [Kubernetes 安全建议](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access)，即限制授予实例凭证的权限，使用网络策略限制 pod 对元数据 API 的访问，并避免使用配置数据来传递密文。
|
||||
|
||||
建议你参阅你使用的云提供商的安全最佳实践，获取限制对云实例元数据 API 访问的建议和详情。
|
||||
|
||||
要获取更多参考资料，请参阅 MITRE ATT&CK 知识库 - [不安全凭证：云实例元数据 API](https://attack.mitre.org/techniques/T1552/005/)。
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: PodSecurityConfiguration 示例
|
||||
---
|
||||
|
||||
以下 PodSecurityConfiguration 包含了 `rancher-restricted` 集群正常运行所需的 Rancher 命名空间豁免。
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: AdmissionConfiguration
|
||||
plugins:
|
||||
- name: PodSecurity
|
||||
configuration:
|
||||
apiVersion: pod-security.admission.config.k8s.io/v1
|
||||
kind: PodSecurityConfiguration
|
||||
defaults:
|
||||
enforce: "restricted"
|
||||
enforce-version: "latest"
|
||||
audit: "restricted"
|
||||
audit-version: "latest"
|
||||
warn: "restricted"
|
||||
warn-version: "latest"
|
||||
exemptions:
|
||||
usernames: []
|
||||
runtimeClasses: []
|
||||
namespaces: [calico-apiserver,
|
||||
calico-system,
|
||||
cattle-alerting,
|
||||
cattle-csp-adapter-system,
|
||||
cattle-elemental-system,
|
||||
cattle-epinio-system,
|
||||
cattle-externalip-system,
|
||||
cattle-fleet-local-system,
|
||||
cattle-fleet-system,
|
||||
cattle-gatekeeper-system,
|
||||
cattle-global-data,
|
||||
cattle-global-nt,
|
||||
cattle-impersonation-system,
|
||||
cattle-istio,
|
||||
cattle-istio-system,
|
||||
cattle-logging,
|
||||
cattle-logging-system,
|
||||
cattle-monitoring-system,
|
||||
cattle-neuvector-system,
|
||||
cattle-prometheus,
|
||||
cattle-resources-system,
|
||||
cattle-sriov-system,
|
||||
cattle-system,
|
||||
cattle-ui-plugin-system,
|
||||
cattle-windows-gmsa-system,
|
||||
cert-manager,
|
||||
cis-operator-system,
|
||||
fleet-default,
|
||||
ingress-nginx,
|
||||
istio-system,
|
||||
kube-node-lease,
|
||||
kube-public,
|
||||
kube-system,
|
||||
longhorn-system,
|
||||
rancher-alerting-drivers,
|
||||
security-scan,
|
||||
tigera-operator]
|
||||
```
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: 安全公告和 CVE
|
||||
---
|
||||
|
||||
Rancher 致力于向社区披露我们产品的安全问题。我们会针对已解决的问题发布安全公告和 CVE（Common Vulnerabilities and Exposures，通用漏洞披露）。Rancher GitHub 上的[安全页面](https://github.com/rancher/rancher/security/advisories)也会发布新的安全公告。
|
||||
|
||||
| ID | 描述 | 日期 | 解决 |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2023-22651](https://github.com/rancher/rancher/security/advisories/GHSA-6m9f-pj6w-w87g) | 由于 webhook 的更新逻辑失败，Rancher 准入 webhook 可能会配置错误。准入 webhook 在资源允许进入 Kubernetes 集群之前会强制执行验证规则和安全检查。webhook 在降级状态下运行时将不再验证任何资源，这可能导致严重的权限提升和数据损坏。 | 2023 年 4 月 24 日 | Rancher [v2.7.3](https://github.com/rancher/rancher/releases/tag/v2.7.3) |
|
||||
| [CVE-2022-43758](https://github.com/rancher/rancher/security/advisories/GHSA-34p5-jp77-fcrc) | 在 Rancher 2.5.0 至 2.5.16、2.6.0 至 2.6.9 和 2.7.0 版本中发现了一个问题，Rancher Git 包中存在命令注入漏洞。这个包使用 Rancher 容器镜像中可用的底层 Git 二进制文件来执行 Git 操作。特制的命令如果没有消除歧义，可能会在通过 Git 执行时造成混淆，导致在底层 Rancher 主机中进行命令注入。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-43757](https://github.com/rancher/rancher/security/advisories/GHSA-cq4p-vp5q-4522) | 此问题影响 Rancher 2.5.0 到 2.5.16，2.6.0 至 2.6.9 和 2.7.0。我们发现 Rancher 之前发布的安全公告 [CVE-2021-36782](https://github.com/advisories/GHSA-g7j7-h4q8-8w2f) 没有解决某些敏感字段、Secret Token、加密密钥和 SSH 密钥，这些字段仍然以明文形式直接存储在 Kubernetes 上 `Clusters` 之类的对象。在 Rancher 中，集群中已认证的 `Cluster Owners`、`Cluster Members`、`Project Owners` 和 `Project Members` 可以看到公开的凭证。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-43755](https://github.com/rancher/rancher/security/advisories/GHSA-8c69-r38j-rpfj) | 在 Rancher 2.6.9 和 2.7.0 之前的版本中发现了一个问题，即 `cattle-cluster-agent` 使用的 `cattle-token` Secret 是可预测的。重新生成 Token 之后，Token 的值依然相同。如果 Token 被泄露并且出于安全目的需要重新创建，这可能会造成严重的问题。Rancher 的 `cattle-cluster-agent` 使用 `cattle-token` 来连接到 Rancher 配置的下游集群 Kubernetes API。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1) 和 [v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) |
|
||||
| [CVE-2022-21953](https://github.com/rancher/rancher/security/advisories/GHSA-g25r-gvq3-wrq7) | 在 Rancher 2.5.16、2.6.9 和 2.7.0 之前的版本中发现了一个问题。由于授权逻辑缺陷，任何下游集群上经过身份认证的用户都能在 Rancher `local` 集群中打开一个 shell pod (1)，而且对 kubectl 具有有限的访问权限 (2)。预期的行为是：除非明确授予权限，否则用户在 Rancher `local` 集群中没有这样的访问权限。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [GHSA-c45c-39f6-6gw9](https://github.com/rancher/rancher/security/advisories/GHSA-c45c-39f6-6gw9) | 此问题影响 Rancher 2.5.0 到 2.5.16，2.6.0 至 2.6.9 和 2.7.0。只会影响配置了或配置过外部身份认证提供程序的 Rancher 设置。我们发现，当在 Rancher 中配置外部身份认证提供程序然后将其禁用时，Rancher 生成的 Token 如果关联了通过现已禁用的身份认证提供程序授予访问权限的用户，那么 Token 不会被撤销。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-31247](https://github.com/rancher/rancher/security/advisories/GHSA-6x34-89p7-95wg) | 在 2.5.15（包括）到 2.6.6（包括）的 Rancher 版本中发现了一个问题，其中的授权逻辑缺陷允许在下游集群中通过集群角色模板绑定 (CRTB) 和项目角色模板绑定 (PRTB) 来提升权限。任何有权限创建/编辑 CRTB 或 PRTB 的用户（例如 `cluster-owner`、`manage cluster members`、`project-owner` 和 `manage project members`）都可以利用该漏洞，在同一集群的另一个项目或不同下游集群的另一个项目中获得所有者权限。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36783](https://github.com/rancher/rancher/security/advisories/GHSA-8w87-58w6-hfv8) | 2.5.12 到 2.6.3 的 Rancher 版本无法正确清理集群模板 answer 中的凭证。此错误可能会导致明文存储以及凭证、密码和 API 令牌被暴露。在 Rancher 中，已认证的 `Cluster Owner`、`Cluster Member`、`Project Owner` 和 `Project Member` 可以在 `/v1/management.cattle.io.clusters`、`/v3/clusters` 和 `/k8s/clusters/local/apis/management.cattle.io/v3/clusters` 端点上看到暴露的凭证。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36782](https://github.com/rancher/rancher/security/advisories/GHSA-g7j7-h4q8-8w2f) | 在 2.5.15 到 2.6.6 的 Rancher 版本中发现了一个问题，其中密码、API 密钥和 Rancher 的 ServiceAccount 令牌（用于配置集群）等敏感字段直接以明文形式存储在 `Cluster` 等 Kubernetes 对象上（例如，`cluster.management.cattle.io`）。任何能够读取 Kubernetes API 中的对象的用户都可以检索这些敏感数据的明文版本。该问题由 Florian Struck（来自 [Continum AG](https://www.continum.net/)）和 [Marco Stuurman](https://github.com/fe-ax)（来自 [Shock Media B.V.](https://www.shockmedia.nl/)）发现并报告。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rke-templates/)配置 [Weave](https://rancher.com/docs/rancher/v2.6/en/faq/networking/cni-providers/#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://www.weave.works/docs/net/latest/tasks/manage/security-untrusted-networks/)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
|
||||
| [CVE-2021-36784](https://github.com/rancher/rancher/security/advisories/GHSA-jwvr-vv7p-gpwq) | 在 Rancher 2.5.0 到 2.5.12 和 Rancher 2.6.0 到 2.6.3 中发现了一个漏洞，该漏洞允许能创建或更新[全局角色](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rbac/)的用户将他们或其他用户升级为管理员。全局角色能授予用户 Rancher 级别的权限，例如能创建集群。在已识别的 Rancher 版本中，如果用户被授予了编辑或创建全局角色的权限，他们不仅仅能授予他们已经拥有的权限。此漏洞影响使用能够创建或编辑全局角色的非管理员用户的客户。此场景最常见的用例是 `restricted-admin` 角色。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [CVE-2021-4200](https://github.com/rancher/rancher/security/advisories/GHSA-hx8w-ghh8-r4xf) | 此漏洞仅影响在 Rancher 中使用 `restricted-admin` 角色的客户。在 Rancher 2.5.0 到 2.5.12 和 2.6.0 到 2.6.3 中发现了一个漏洞，其中 `cattle-global-data` 命名空间中的 `global-data` 角色授予了应用商店的写权限。由于具有任何级别的应用商店访问权限的用户都会绑定到 `global-data` 角色，因此这些用户都能写入模板 `CatalogTemplates`) 和模板版本 (`CatalogTemplateVersions`)。在 Rancher 中创建的新用户默认分配到 `user` 角色（普通用户），该角色本不该具有写入应用商店的权限。此漏洞提升了能写入应用商店模板和应用商店模板版本资源的用户的权限。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [GHSA-wm2r-rp98-8pmh](https://github.com/rancher/rancher/security/advisories/GHSA-wm2r-rp98-8pmh) | 此漏洞仅影响使用经过认证的 Git 和/或 Helm 仓库通过 [Fleet](https://rancher.com/docs/rancher/v2.6/en/deploy-across-clusters/fleet/) 进行持续交付的客户。在 [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) 之前版本中的 `go-getter` 库中发现了一个问题，错误消息中没有删除 Base64 编码的 SSH 私钥，导致该信息暴露。Rancher 中 [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9) 之前的 Fleet 版本使用了该库的漏洞版本。此问题影响 Rancher 2.5.0 到 2.5.12（包括 2.5.12）以及 2.6.0 到 2.6.3（包括 2.6.3）。该问题由 Raft Engineering 的 Dagan Henderson 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [CVE-2021-36778](https://github.com/rancher/rancher/security/advisories/GHSA-4fc7-hc63-7fjg) | 在 Rancher 2.5.0 到 2.5.11 和 Rancher 2.6.0 到 2.6.2 中发现了一个漏洞，当从配置的私有仓库下载 Helm Chart 时，对同源策略的检查不足可能导致仓库凭证暴露给第三方提供商。仅当用户在 Rancher 的`应用 & 应用市场 > 仓库`中配置私有仓库的访问凭证时才会出现此问题。该问题由 Martin Andreas Ullrich 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) 和 [Rancher 2.5.12](https://github.com/rancher/rancher/releases/tag/v2.5.12) |
|
||||
| [GHSA-hwm2-4ph6-w6m5](https://github.com/rancher/rancher/security/advisories/GHSA-hwm2-4ph6-w6m5) | 在 Rancher 2.0 到 2.6.3 中发现了一个漏洞。Rancher 提供的 `restricted` Pod 安全策略（PSP）与 Kubernetes 提供的上游 `restricted` 策略有差别，因此 Rancher 的 PSP 将 `runAsUser` 设置为 `runAsAny`，而上游将 `runAsUser` 设置为 `MustRunAsNonRoot`。因此，即使 Rancher 的 `restricted` 策略是在项目或集群级别上强制执行的，容器也可以以任何用户身份运行，包括特权用户 (`root`)。 | 2022 年 3 月 31 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) |
|
||||
| [CVE-2021-36775](https://github.com/rancher/rancher/security/advisories/GHSA-28g7-896h-695v) | 在 Rancher 2.4.17、2.5.11 和 2.6.2 以及更高的版本中发现了一个漏洞。从项目中删除与某个组关联的`项目角色`后，能让这些使用者访问集群级别资源的绑定（Binding）不会被删除。导致问题的原因是不完整的授权逻辑检查。如果用户是受影响组中的成员，且能对 Rancher 进行认证访问，那么用户可以利用此漏洞访问他们不应该能访问的资源。暴露级别取决于受影响项目角色的原始权限级别。此漏洞仅影响在 Rancher 中基于组进行身份验证的客户。 | 2022 年 3 月 31 日 | [Rancher 2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3)、[Rancher 2.5.12](https://github.com/rancher/rancher/releases/tag/v2.5.12) 和 [Rancher 2.4.18](https://github.com/rancher/rancher/releases/tag/v2.4.18) |
|
||||
| [CVE-2021-36776](https://github.com/rancher/rancher/security/advisories/GHSA-gvh9-xgrq-r8hw) | 在 Rancher 2.5.0 到 2.5.9 中发现了一个漏洞，该漏洞允许经过认证用户通过 API 代理模拟集群上的任何用户，而无需知道被模拟用户的凭证。问题的原因是 API 代理在将请求发送到 Kubernetes API 之前未删除模拟标头。能认证访问 Rancher 的恶意用户可以冒充另一个在 Rancher 认证用户，从而对集群进行管理员级别的访问。 | 2022 年 3 月 31 日 | [Rancher 2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) 和 [Rancher 2.5.10](https://github.com/rancher/rancher/releases/tag/v2.5.10) |
|
||||
| [CVE-2021-25318](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25318) | Rancher 2.0 的不可编辑版本发现了一个漏洞，在该版本中，无论资源的 API 组如何，用户都可以访问资源。例如，Rancher 应该允许用户访问 `apps.catalog.cattle.io`，但却错误地授予了对 `apps.*` 的访问权限。你可以在[这里](https://github.com/rancher/rancher/security/advisories/GHSA-f9xf-jq4j-vqw4)找到**下游集群**和 **Rancher 管理集群**中受影响的资源。除了升级到打了补丁的 Rancher 版本之外，暂时没有直接的缓解措施。 | 2021 年 7 月 14 日 | [Rancher 2.5.9](https://github.com/rancher/rancher/releases/tag/v2.5.9) 和 [Rancher 2.4.16](https://github.com/rancher/rancher/releases/tag/v2.4.16) |
|
||||
| [CVE-2021-31999](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31999) | Rancher 2.0.0 的补丁版本发现了一个漏洞，恶意的 Rancher 用户可以针对托管集群的 Kubernetes API 的代理发起一个 API 请求，以获取他们无权访问的信息。这是通过在 Connection 标头中传递 “Impersonate-User” 或 “Impersonate-Group” 标头来实现的，然后代理会删除该标头。此时，请求不会模拟用户及其权限，而是会类似 Rancher management server 的请求，并错误地返回信息。该漏洞仅影响对集群具有一定级别权限的 Rancher 用户。除了升级到打了补丁的 Rancher 版本之外，暂时没有直接的缓解措施。 | 2021 年 7 月 14 日 | [Rancher 2.5.9](https://github.com/rancher/rancher/releases/tag/v2.5.9) 和 [Rancher 2.4.16](https://github.com/rancher/rancher/releases/tag/v2.4.16) |
|
||||
| [CVE-2021-25320](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25320) | Rancher 2.2.0 的补丁版本发现了一个漏洞，云凭证没有正确通过 Rancher API 验证。具体地说，是通过用于与云提供商通信的代理。任何登录并具有有效云提供商云凭证 ID 的 Rancher 用户都可以通过代理 API 调用该云提供商的 API，并且云凭证会被绑定。该漏洞仅影响有效的 Rancher 用户。除了升级到打了补丁的 Rancher 版本之外，暂时没有直接的缓解措施。 | 2021 年 7 月 14 日 | [Rancher 2.5.9](https://github.com/rancher/rancher/releases/tag/v2.5.9) 和 [Rancher 2.4.16](https://github.com/rancher/rancher/releases/tag/v2.4.16) |
|
||||
| [CVE-2021-25313](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25313) | 所有 Rancher 2 版本上都发现了一个安全漏洞。使用浏览器访问 Rancher API 时，URL 没有正确转义，导致它容易受到 XSS 攻击。这些 API 端点的特制 URL 可能包括嵌入页面并在浏览器中执行的 JavaScript。暂时没有直接的缓解措施。请不要单击指向 Rancher Server 的不受信任链接。 | 2021 年 3 月 2 日 | [Rancher v2.5.6](https://github.com/rancher/rancher/releases/tag/v2.5.6)、[Rancher v2.4.14](https://github.com/rancher/rancher/releases/tag/v2.4.14) 和 [Rancher v2.3.11](https://github.com/rancher/rancher/releases/tag/v2.3.11) |
|
||||
| [CVE-2019-14435](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14435) | 此漏洞让已验证的用户可以通过 Rancher 使用的系统服务容器可访问的 IP 提取私有数据。这包括但不限于云提供商元数据服务等服务。虽然 Rancher 允许用户为系统服务配置白名单域，但这个漏洞仍然可以被精心设计的 HTTP 请求利用。该问题由 Workiva 的 Matt Belisle 和 Alex Stevenson 发现并报告。 | 2019 年 8 月 5 日 | [Rancher 2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) 和 [Rancher 2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) |
|
||||
| [CVE-2019-14436](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14436) | 该漏洞允许有权编辑角色绑定的项目成员为自己或其他用户分配集群级别的角色，从而授予他们对该集群的管理员访问权限。该问题由 Nokia 的 Michal Lipinski 发现并报告。 | 2019 年 8 月 5 日 | [Rancher 2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) 和 [Rancher 2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) |
|
||||
| [CVE-2019-13209](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13209) | 该漏洞被称为[跨网页 Websocket 劫持攻击](https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html)。该攻击允许攻击者以受害用户的角色/权限访问由 Rancher 管理的集群。它让受害用户登录到 Rancher Server，然后访问由攻击者托管的第三方站点。完成后，攻击者就可以使用受害用户的权限和身份对 Kubernetes API 执行命令。该问题由 Workiva 的 Matt Belisle 和 Alex Stevenson 报告。 | 2019 年 7 月 15 日 | [Rancher 2.2.5](https://github.com/rancher/rancher/releases/tag/v2.2.5)、[Rancher 2.1.11](https://github.com/rancher/rancher/releases/tag/v2.1.11) 和 [Rancher 2.0.16](https://github.com/rancher/rancher/releases/tag/v2.0.16) |
|
||||
| [CVE-2019-12303](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12303) | 项目所有者可以注入额外的 fluentd 日志配置，从而在 fluentd 容器内读取文件或执行任意命令。该问题由 Untamed Theory 的 Tyler Welton 报告。 | 2019 年 6 月 5 日 | [Rancher 2.2.4](https://github.com/rancher/rancher/releases/tag/v2.2.4)、[Rancher 2.1.10](https://github.com/rancher/rancher/releases/tag/v2.1.10) 和 [Rancher 2.0.15](https://github.com/rancher/rancher/releases/tag/v2.0.15) |
|
||||
| [CVE-2019-12274](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12274) | 如果节点使用的内置主机驱动使用了文件路径选项，则节点可以读取 Rancher Server 容器内的任意文件，包括敏感文件。 | 2019 年 6 月 5 日 | [Rancher 2.2.4](https://github.com/rancher/rancher/releases/tag/v2.2.4)、[Rancher 2.1.10](https://github.com/rancher/rancher/releases/tag/v2.1.10) 和 [Rancher 2.0.15](https://github.com/rancher/rancher/releases/tag/v2.0.15) |
|
||||
| [CVE-2019-11202](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11202) | 即使已被显式删除，Rancher 的默认管理员会在 Rancher 重启时重新创建。 | 2019 年 4 月 16 日 | [Rancher 2.2.2](https://github.com/rancher/rancher/releases/tag/v2.2.2)、[Rancher 2.1.9](https://github.com/rancher/rancher/releases/tag/v2.1.9) 和 [Rancher 2.0.14](https://github.com/rancher/rancher/releases/tag/v2.0.14) |
|
||||
| [CVE-2019-6287](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6287) | 如果将项目成员添加到多个项目中，则成员还能继续访问被删除的项目中的命名空间。 | 2019 年 1 月 29 日 | [Rancher 2.1.6](https://github.com/rancher/rancher/releases/tag/v2.1.6) 和 [Rancher 2.0.11](https://github.com/rancher/rancher/releases/tag/v2.0.11) |
|
||||
| [CVE-2018-20321](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20321) | 任何有权访问 `default` 命名空间的项目成员都可以在 pod 中挂载 `netes-default` ServiceAccount，然后使用该 pod 对 Kubernetes 集群执行管理特权命令。 | 2019 年 1 月 29 日 | [Rancher 2.1.6](https://github.com/rancher/rancher/releases/tag/v2.1.6) 和 [Rancher 2.0.11](https://github.com/rancher/rancher/releases/tag/v2.0.11) - 对于这些版本或更高版本，我们有对应的[回滚说明](../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md)。 |
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: 关于 rancher-selinux
|
||||
---
|
||||
|
||||
要让 Rancher 使用 SELinux，你必须手动为 SELinux 节点启用一些功能。为了解决这个问题，Rancher 提供了一个 SELinux RPM。
|
||||
|
||||
`rancher-selinux` RPM 仅包含 [rancher-logging 应用程序](https://github.com/rancher/charts/tree/dev-v2.5/charts/rancher-logging)的策略。
|
||||
|
||||
`rancher-selinux` 的 GitHub 仓库在[这里](https://github.com/rancher/rancher-selinux)。
|
||||
|
||||
## 安装 rancher-selinux RPM
|
||||
|
||||
:::note 要求
|
||||
|
||||
rancher-selinux RPM 已在 CentOS 7 和 8 上进行了测试。
|
||||
|
||||
:::
|
||||
|
||||
### 1. 设置 yum 仓库
|
||||
|
||||
设置 yum 仓库，从而直接在集群中的所有主机上安装 `rancher-selinux`。
|
||||
|
||||
要使用 RPM 仓库，在 CentOS 7 或 RHEL 7 系统上运行以下 bash 代码片段：
|
||||
|
||||
```
|
||||
# cat << EOF > /etc/yum.repos.d/rancher.repo
|
||||
[rancher]
|
||||
name=Rancher
|
||||
baseurl=https://rpm.rancher.io/rancher/production/centos/7/noarch
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
gpgkey=https://rpm.rancher.io/public.key
|
||||
EOF
|
||||
```
|
||||
|
||||
要使用 RPM 仓库，在 CentOS 8 或 RHEL 8 系统上运行以下 bash 代码片段：
|
||||
|
||||
```
|
||||
# cat << EOF > /etc/yum.repos.d/rancher.repo
|
||||
[rancher]
|
||||
name=Rancher
|
||||
baseurl=https://rpm.rancher.io/rancher/production/centos/8/noarch
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
gpgkey=https://rpm.rancher.io/public.key
|
||||
EOF
|
||||
```
|
||||
### 2. 安装 RPM
|
||||
|
||||
安装 RPM：
|
||||
|
||||
```
|
||||
yum -y install rancher-selinux
|
||||
```
|
||||
|
||||
## 配置 Logging 应用程序以使用 SELinux
|
||||
|
||||
:::note 要求
|
||||
|
||||
Logging v2 已在 RHEL/CentOS 7 和 8 上使用 SELinux 进行了测试。
|
||||
|
||||
:::
|
||||
|
||||
在主机上安装 `rancher-selinux` RPM 后，应用程序不会自动运行。它们需要在 RPM 提供的允许的 SELinux 容器域中运行。
|
||||
|
||||
要将 `rancher-logging` Chart 配置为支持 SELinux，请在安装 Chart 时将 `values.yaml` 中的 `global.seLinux.enabled` 更改为 true。
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 关于 rke2-selinux
|
||||
---
|
||||
|
||||
`rke2-selinux` 为 RKE2 提供策略。如果 RKE2 安装程序脚本检测到它运行在基于 RPM 的发行版上，它会自动安装。
|
||||
|
||||
`rke2-selinux` 的 GitHub 仓库在[这里](https://github.com/rancher/rke2-selinux)。
|
||||
|
||||
有关在启用 SELinux 的主机上安装 RKE2 的更多信息，请参阅 [RKE2 文档](https://docs.rke2.io/install/methods#rpm)。
|
||||
+111
@@ -0,0 +1,111 @@
|
||||
---
|
||||
title: RKE1 示例 YAML
|
||||
---
|
||||
|
||||
以下是一个供参考的 RKE 模板配置文件示例。
|
||||
|
||||
RKE 模板中的 YAML 使用与创建 RKE 集群时相同的自定义项。但是，由于 YAML 位于 Rancher 配置的 RKE 集群的上下文中，因此 RKE 文档中的自定义项需要嵌套在 `rancher_kubernetes_engine` 指令下。
|
||||
|
||||
```yaml
|
||||
#
|
||||
# Cluster Config
|
||||
#
|
||||
docker_root_dir: /var/lib/docker
|
||||
|
||||
enable_cluster_alerting: false
|
||||
# This setting is not enforced. Clusters
|
||||
# created with this sample template
|
||||
# would have alerting turned off by default,
|
||||
# but end users could still turn alerting
|
||||
# on or off.
|
||||
|
||||
enable_cluster_monitoring: true
|
||||
# This setting is not enforced. Clusters
|
||||
# created with this sample template
|
||||
# would have monitoring turned on
|
||||
# by default, but end users could still
|
||||
# turn monitoring on or off.
|
||||
|
||||
enable_network_policy: false
|
||||
local_cluster_auth_endpoint:
|
||||
enabled: true
|
||||
#
|
||||
# Rancher Config
|
||||
#
|
||||
rancher_kubernetes_engine_config: # Your RKE template config goes here.
|
||||
addon_job_timeout: 30
|
||||
authentication:
|
||||
strategy: x509
|
||||
ignore_docker_version: true
|
||||
#
|
||||
# # 目前仅支持 Nginx ingress provider
|
||||
# # 要禁用 Ingress controller，设置 `provider: none`
|
||||
# # 要在指定节点上禁用 Ingress，使用 node_selector，例如：
|
||||
# provider: nginx
|
||||
# node_selector:
|
||||
# app: ingress
|
||||
#
|
||||
ingress:
|
||||
provider: nginx
|
||||
kubernetes_version: v1.15.3-rancher3-1
|
||||
monitoring:
|
||||
provider: metrics-server
|
||||
#
|
||||
# If you are using calico on AWS
|
||||
#
|
||||
# network:
|
||||
# plugin: calico
|
||||
# calico_network_provider:
|
||||
# cloud_provider: aws
|
||||
#
|
||||
# # To specify flannel interface
|
||||
#
|
||||
# network:
|
||||
# plugin: flannel
|
||||
# flannel_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
# # To specify flannel interface for canal plugin
|
||||
#
|
||||
# network:
|
||||
# plugin: canal
|
||||
# canal_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
network:
|
||||
options:
|
||||
flannel_backend_type: vxlan
|
||||
plugin: canal
|
||||
#
|
||||
# services:
|
||||
# kube-api:
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
# kube-controller:
|
||||
# cluster_cidr: 10.42.0.0/16
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
# kubelet:
|
||||
# cluster_domain: cluster.local
|
||||
# cluster_dns_server: 10.43.0.10
|
||||
#
|
||||
services:
|
||||
etcd:
|
||||
backup_config:
|
||||
enabled: true
|
||||
interval_hours: 12
|
||||
retention: 6
|
||||
safe_timestamp: false
|
||||
creation: 12h
|
||||
extra_args:
|
||||
election-timeout: 5000
|
||||
heartbeat-interval: 500
|
||||
gid: 0
|
||||
retention: 72h
|
||||
snapshot: false
|
||||
uid: 0
|
||||
kube_api:
|
||||
always_pull_images: false
|
||||
pod_security_policy: false
|
||||
service_node_port_range: 30000-32767
|
||||
ssh_agent_auth: false
|
||||
windows_prefered_cluster: false
|
||||
```
|
||||
+105
@@ -0,0 +1,105 @@
|
||||
---
|
||||
title: Docker 安装高级选项
|
||||
---
|
||||
|
||||
### 自定义 CA 证书
|
||||
|
||||
如需 Rancher 在验证服务时使用 CA 根证书，请在启动 Rancher 容器时共享包含 CA 根证书的目录。
|
||||
|
||||
使用命令示例来启动挂载了私有 CA 证书的 Rancher 容器。
|
||||
|
||||
- 卷标志 (`-v`) 应指定包含 CA 根证书的主机目录。
|
||||
- 环境变量标志 (`-e`) 与 `SSL_CERT_DIR` 和目录共同声明一个环境变量，该变量指定容器内挂载了 CA 根证书的目录位置。
|
||||
- 你可使用 `-e KEY=VALUE` 或 `--env KEY=VALUE`将环境变量传给 Rancher 容器。
|
||||
- 你可使用 `-v host-source-directory:container-destination-directory` 或 `--volume host-source-directory:container-destination-directory`在容器内挂载主机目录。
|
||||
|
||||
在以下示例将位于 `/host/certs` 主机目录中的 CA 证书，挂载到 Rancher 容器内的 `/container/certs` 上。
|
||||
|
||||
特权访问是[必须](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-v /host/certs:/container/certs \
|
||||
-e SSL_CERT_DIR="/container/certs" \
|
||||
--privileged \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
### API 审计日志
|
||||
|
||||
API 审计日志记录了通过 Rancher Server 进行的所有用户和系统事务。
|
||||
|
||||
默认情况下，API 审计日志会写入到 Rancher 容器内的 `/var/log/auditlog`。你可将此目录共享为卷，并设置 `AUDIT_LEVEL` 以启用日志。
|
||||
|
||||
有关更多信息和选项，请参见 [API 审计日志](../../how-to-guides/advanced-user-guides/enable-api-audit-log.md)。
|
||||
|
||||
特权访问是[必须](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-v /var/log/rancher/auditlog:/var/log/auditlog \
|
||||
-e AUDIT_LEVEL=1 \
|
||||
--privileged \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
### TLS 设置
|
||||
|
||||
如需使用不同的 TLS 配置，你可使用 `CATTLE_TLS_MIN_VERSION` 和 `CATTLE_TLS_CIPHERS` 环境变量。例如，将 TLS 1.0 设为可接受的最低 TLS 版本，如下：
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-e CATTLE_TLS_MIN_VERSION="1.0" \
|
||||
--privileged \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
特权访问是[必须](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
|
||||
参见 [TLS 设置](../../getting-started/installation-and-upgrade/installation-references/tls-settings.md)了解更多信息和选项。
|
||||
|
||||
### 离线环境
|
||||
|
||||
如果要访问此页面以完成离线安装，在运行安装命令时，你必须把私有镜像仓库的 URL 添加到 Server 标志前面。例如，将带有私有镜像仓库 URL 的 `<REGISTRY.DOMAIN.COM:PORT>` 添加到 `rancher/rancher:latest` 前面。
|
||||
|
||||
**示例**：
|
||||
|
||||
<REGISTRY.DOMAIN.COM:PORT>/rancher/rancher:latest
|
||||
|
||||
### 持久化数据
|
||||
|
||||
Rancher 使用 etcd 作为数据存储。如果 Rancher 是使用 Docker 安装的，Rancher 会使用嵌入式 etcd。持久化数据位于容器的 `/var/lib/rancher` 路径中。
|
||||
|
||||
你可以将主机卷挂载到该位置，来将数据保留在运行它的主机上：
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-v /opt/rancher:/var/lib/rancher \
|
||||
--privileged \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
特权访问是[必须](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
|
||||
### 在同一个节点中运行 `rancher/rancher` 和 `rancher/rancher-agent`
|
||||
|
||||
如需使用单个节点运行 Rancher 并将同一个节点添加到集群，你必须调整映射给 `rancher/rancher` 容器的主机端口。
|
||||
|
||||
如果将节点添加到集群中，节点将部署使用端口 80 和 443 的 NGINX Ingress Controller。而这将与我们建议用于暴露 `rancher/rancher` 容器的默认端口冲突。
|
||||
|
||||
请知悉我们不建议将此设置用于生产环境，这种方式仅用来方便进行开发/演示。
|
||||
|
||||
如需更改主机端口映射，将 `-p 80:80 -p 443:443` 替换为 `-p 8080:80 -p 8443:443`：
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 8080:80 -p 8443:443 \
|
||||
--privileged \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
特权访问是[必须](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: HTTP 代理配置
|
||||
---
|
||||
|
||||
如果你通过代理来操作 Rancher，并想要通过代理访问服务（例如拉取应用商店），你需要提供 Rancher 代理的信息。由于 Rancher 是用 Go 编写的，Rancher 使用如下常见的代理环境变量。
|
||||
|
||||
请确保 `NO_PROXY` 包含不使用代理的网络地址，网络地址范围和域名。
|
||||
|
||||
| 环境变量 | 用途 |
|
||||
| -------------------- | ----------------------------------------------------------------------------------------------------------------------- |
|
||||
| HTTP_PROXY | 发起 HTTP 连接的代理地址 |
|
||||
| HTTPS_PROXY | 发起 HTTPS 连接的代理地址 |
|
||||
| NO_PROXY | 发起连接时不使用代理的网络地址，网络地址范围和域名 |
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
`NO_PROXY` 必须大写才能使用网络范围 CIDR 表示法。
|
||||
|
||||
:::
|
||||
|
||||
## 基于 Docker 安装
|
||||
|
||||
你可使用 `-e KEY=VALUE` 或 `--env KEY=VALUE`将环境变量传给 Rancher 容器。在 [Docker 安装](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md)中，`NO_PROXY` 必须的值为：
|
||||
|
||||
- `localhost`
|
||||
- `127.0.0.1`
|
||||
- `0.0.0.0`
|
||||
- `10.0.0.0/8`
|
||||
- `cattle-system.svc`
|
||||
- `.svc`
|
||||
- `.cluster.local`
|
||||
|
||||
以下示例中，代理服务器可以通过 `http://192.168.0.1:3128` 访问。此外，在访问 `192.168.10.0/24` 网络范围以及 `example.com` 域名下的每个主机名时均不使用代理服务器。
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-e HTTP_PROXY="http://192.168.10.1:3128" \
|
||||
-e HTTPS_PROXY="http://192.168.10.1:3128" \
|
||||
-e NO_PROXY="localhost,127.0.0.1,0.0.0.0,10.0.0.0/8,cattle-system.svc,192.168.10.0/24,.svc,.cluster.local,example.com" \
|
||||
--privileged \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
特权访问是[必须](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
|
||||
### 离线代理配置
|
||||
|
||||
_v2.6.4 的新功能_
|
||||
|
||||
你现在可以在配置的离线集群中配置主机驱动集群，以使用代理进行出站连接。
|
||||
|
||||
除了如上为代理服务器设置默认规则外，你还需要额外添加如下所示的规则，以从代理的 Rancher 环境中配置主机驱动集群。
|
||||
|
||||
根据你的设置配置文件路径，例如 `/etc/apt/apt.conf.d/proxy.conf`：
|
||||
|
||||
```
|
||||
acl SSL_ports port 22
|
||||
acl SSL_ports port 2376
|
||||
|
||||
acl Safe_ports port 22 # ssh
|
||||
acl Safe_ports port 2376 # docker port
|
||||
```
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: 系统工具
|
||||
---
|
||||
|
||||
:::note
|
||||
|
||||
系统工具（System Tools）自 2022 年 6 月起已弃用。
|
||||
|
||||
:::
|
||||
|
||||
## 日志
|
||||
|
||||
请使用 [logs-collector](https://github.com/rancherlabs/support-tools/tree/master/collection/rancher/v2.x/logs-collector) 来收集你的集群日志。
|
||||
|
||||
## Stats
|
||||
|
||||
如果要复制 stats 命令，你可以在集群节点上运行以下命令：
|
||||
|
||||
:::note
|
||||
|
||||
以下命令需要集群节点上的 `sysstat` 包。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
/usr/bin/sar -u -r -F 1 1
|
||||
```
|
||||
|
||||
## Remove
|
||||
|
||||
请使用 [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) 工具。
|
||||
+59
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: API 密钥
|
||||
---
|
||||
|
||||
## API 密钥和用户身份验证
|
||||
|
||||
如果你想通过外部应用程序来访问 Rancher 集群、项目或其他对象，你可以使用 Rancher API。但是，在你的应用程序可以访问 API 之前，你必须为应用程序提供用于向 Rancher 进行身份验证的密钥。你可以通过 Rancher UI 获取密钥。
|
||||
|
||||
使用 Rancher CLI 也需要 API 密钥。
|
||||
|
||||
API 密钥由四个组件组成：
|
||||
|
||||
- **端点**：其他应用程序用来向 Rancher API 发送请求的 IP 地址和路径。
|
||||
- **访问密钥**：Token 的用户名。
|
||||
- **密文密钥**：Token 的密码。如果应用程序提示你输入两个不同的字符串进行 API 身份验证，你通常需要将两个密钥一起输入。
|
||||
- **持有者令牌**：连接在一起的令牌用户名和密码。如果应用程序提示你输入一个身份验证字符串，则使用此字符串。
|
||||
|
||||
:::note
|
||||
|
||||
用户可以选择启用[令牌哈希（token hashing）](../about-the-api/api-tokens.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 创建 API 密钥
|
||||
|
||||
1. 从右上角选择**用户头像 > 账号 & API 密钥**。
|
||||
|
||||
2. 单击**创建 API 密钥**。
|
||||
|
||||
3. **可选**：输入 API 密钥的描述并选择有效期或范围。我们建议设置到期日期。
|
||||
|
||||
API 密钥过期后将失效。有效期短一点会更安全。
|
||||
|
||||
有效期将受 `v3/settings/auth-token-max-ttl-minutes` 约束。如果超过 max-ttl，则会以 max-ttl 为有效期创建 API 密钥。
|
||||
|
||||
范围将限制 API 密钥，使其仅适用于指定集群的 Kubernetes API。如果集群配置了授权集群端点，你将能够直接针对集群的 API 使用设定了范围的令牌，而无需通过 Rancher Server 进行代理。有关详细信息，请参阅[授权集群端点](../../pages-for-subheaders/rancher-manager-architecture.md#4-授权集群端点)。
|
||||
|
||||
4. 单击**创建**。
|
||||
|
||||
**步骤结果**：已创建 API 密钥。将会显示你的 API **端点**、**访问密钥**、**密文密钥**和**持有者令牌**。
|
||||
|
||||
使用**持有者令牌**通过 Rancher CLI 进行身份验证。
|
||||
|
||||
5. 将显示的信息复制到安全位置。此信息仅显示一次，因此如果你丢失了密钥，则必须制作一个新的。
|
||||
|
||||
## 后续操作
|
||||
|
||||
- 将 API 密钥信息输入到将向 Rancher API 发送请求的应用程序中。
|
||||
- 要了解 Rancher 端点和参数的更多信息，你可以为 Rancher UI 中的对象选择**在 API 中查看**。
|
||||
- API 密钥可用于 API 调用和 [Rancher CLI](../../pages-for-subheaders/cli-with-rancher.md)。
|
||||
|
||||
## 删除 API 密钥
|
||||
|
||||
如果要撤销 API 密钥，请将其删除。如果出现以下情况，你需要删除 API 密钥：
|
||||
|
||||
- API 密钥可能已经泄露。
|
||||
- API 密钥已过期。
|
||||
|
||||
要删除 API，选择密钥并单击**删除**。
|
||||
+51
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: 管理云凭证
|
||||
---
|
||||
|
||||
如果要创建[由基础设施提供商托管](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)的集群，则可以使用[节点模板](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#节点模板)来配置集群节点。这些模板使用 Docker Machine 配置选项来定义节点的操作系统镜像以及设置/参数。
|
||||
|
||||
节点模板可以使用云凭证来访问在基础设施提供商中配置节点所需的凭证信息。多个节点模板可以使用相同的云凭证。云凭证省去了为同一云提供商重新输入访问密钥的麻烦。云凭证存储在 Kubernetes 密文中。
|
||||
|
||||
只有存在标记为 `password` 的字段时，节点模板才会使用云凭证。默认的 `active` 主机驱动将其账号访问字段标记为 `password`，但可能有一些 `inactive` 主机驱动没有使用它们。这些主机驱动不会使用云凭证。
|
||||
|
||||
你可以在两种情况下创建云凭证：
|
||||
|
||||
- [在为集群创建节点模板期间](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#节点模板)。
|
||||
- 在**用户设置**中。
|
||||
|
||||
所有云凭证都绑定到创建者的用户配置文件。**不能**与其他用户共享。
|
||||
|
||||
## 使用用户设置创建云凭证
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 单击**云凭证**。
|
||||
1. 单击**创建**。
|
||||
1. 单击云凭证类型。下拉列表中的选项取决于 Rancher 中的 `active` [主机驱动](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md)。
|
||||
1. 输入云凭证的名称。
|
||||
1. 根据所选的云凭证类型输入所需的值，从而向基础设施提供商进行身份验证。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：已创建云凭证，它可以立即用于[创建节点模板](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#节点模板)。
|
||||
|
||||
## 更新云凭证
|
||||
|
||||
如果访问凭证更改或泄露了，你可以通过更新云凭证来进行轮换，同时保留相同的节点模板。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 单击**云凭证**。
|
||||
1. 选择要编辑的云凭证，然后单击 **⋮ > 编辑配置**。
|
||||
1. 更新凭证信息并单击**保存**。
|
||||
|
||||
**结果**：已使用新的访问凭证更新云凭证。[添加新节点](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)时，所有使用此云凭证的现有节点模板都会自动使用更新的信息。
|
||||
|
||||
## 删除云凭证
|
||||
|
||||
如果要删除云凭证，云凭证不能有关联的节点模板。如果你无法删除云凭证，请[删除与该云凭证关联的所有节点模板](manage-node-templates.md#删除节点模板)。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 单击**云凭证**。
|
||||
1. 你可以删除单个云凭证或进行批量删除。
|
||||
|
||||
- 要单独删除一个云凭证，请选择你要编辑的云凭证，然后单击 **⋮ > 删除**。
|
||||
- 要批量删除云凭证，请从列表中选择一个或多个云凭证。单击**删除**。
|
||||
1. 确认你需要删除这些云凭证。
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: 管理节点模板
|
||||
---
|
||||
|
||||
如果要配置[由基础设施提供商托管](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)的集群，则可以使用[节点模板](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#节点模板)来配置集群节点。这些模板使用 Docker Machine 配置选项来定义节点的操作系统镜像以及设置/参数。你可以在两种情况下创建节点模板：
|
||||
|
||||
- [配置节点池集群](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)。
|
||||
- 在任何时间使用[用户设置](../../pages-for-subheaders/user-settings.md)。
|
||||
|
||||
创建节点模板时，它会绑定到你的用户配置文件。节点模板不能在用户之间共享。你可以从用户设置中删除不再使用的旧节点模板。
|
||||
|
||||
## 创建节点模板
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 单击 **RKE1 配置 > 节点模板**。
|
||||
1. 单击**添加模板**。
|
||||
1. 选择一个可用的云提供商。然后按照屏幕上的说明配置模板。
|
||||
|
||||
**结果**：模板已配置。你可以稍后在[配置节点池集群](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)时使用该模板。
|
||||
|
||||
## 更新节点模板
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 单击 **RKE1 配置 > 节点模板**。
|
||||
1. 选择要编辑的节点模板并单击 **⋮ > 编辑**。
|
||||
|
||||
:::note
|
||||
|
||||
默认的 `active` [主机驱动](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md)和任何标记了 `password` 字段的主机驱动都需要使用[云凭证](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#云凭证)。
|
||||
|
||||
:::
|
||||
|
||||
1. 编辑所需信息并单击**保存**。
|
||||
|
||||
**结果**：节点模板已更新。添加新节点时，使用此节点模板的所有节点池都会自动使用更新的信息。
|
||||
|
||||
## 克隆节点模板
|
||||
|
||||
通过用户设置创建新的节点模板时，可以克隆现有模板并快速更新其设置，而无需从头开始创建新的模板。克隆模板避免了为云提供商重新输入访问密钥的麻烦。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 单击 **RKE1 配置 > 节点模板**。
|
||||
1. 找到要克隆的模板。然后选择 **⋮ > 克隆**。
|
||||
1. 填写表单的其余部分。
|
||||
|
||||
**结果**：已克隆和配置模板。你可以稍后在[配置节点池集群](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)时使用该模板。
|
||||
|
||||
## 删除节点模板
|
||||
|
||||
不再使用节点模板时，你可以将其从用户设置中删除。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 单击 **RKE1 配置 > 节点模板**。
|
||||
1. 从列表中选择一个或多个模板。然后点击**删除**。出现提示时确认删除。
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: 用户偏好
|
||||
---
|
||||
|
||||
你可以通过偏好设置来个性化你的 Rancher 体验。要更改偏好设置：
|
||||
|
||||
1. 单击右上角的用户头像。
|
||||
1. 单击**偏好设置**。
|
||||
|
||||
## 语言
|
||||
|
||||
选择 Rancher UI 显示的语言。选项包括：
|
||||
|
||||
- English
|
||||
- 简体中文
|
||||
|
||||
## 主题
|
||||
|
||||
选择 Rancher UI 的背景颜色。如果选择**自动**，背景颜色会在下午 6 点从浅色变为深色，然后在早上 6 点变回浅色。
|
||||
|
||||
## 登录页面
|
||||
|
||||
选择登录后显示的页面。选项包括：
|
||||
|
||||
- 主页。
|
||||
- 上次访问的页面。
|
||||
- 你选择的特定集群。
|
||||
|
||||
## 显示设置
|
||||
|
||||
选择信息的显示方式：
|
||||
|
||||
- 日期格式
|
||||
- 时间格式
|
||||
- 每页行数
|
||||
- 在侧边栏显示的集群数量
|
||||
|
||||
## 确认设置
|
||||
|
||||
_从 v2.7.2 起可用_
|
||||
|
||||
选择缩减节点池时是否要求确认。
|
||||
|
||||
## 高级功能
|
||||
|
||||
- 启用“在 API 中查看”。
|
||||
- 显示由 Rancher 管理的 system 命名空间（不要编辑或删除）。
|
||||
- 使用快捷键（shift+T）来切换深色/浅色主题。
|
||||
- 隐藏所有类型描述。
|
||||
- 启用扩展开发者功能。
|
||||
|
||||
|
||||
|
||||
## YAML 编辑器
|
||||
|
||||
- 默认
|
||||
- Emacs
|
||||
- Vim
|
||||
|
||||
## Helm Chart
|
||||
|
||||
选择仅显示已发布的 Helm Chart 还是同时包含预发布版本。如果版本符合 [Semantic Versioning 2.0.0](https://semver.org/) 定义的[规范](https://semver.org/#spec-item-9)，则那么该版本为预发布版本。例如，要显示版本为 `0.1.3-dev.12ab4f` 的 Helm chart，你需要先选择`包括预发布版本`。
|
||||
Reference in New Issue
Block a user