mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-04-13 18:05:38 +00:00
Add version 2.8 preview
This commit is contained in:
@@ -124,10 +124,23 @@ module.exports = {
|
||||
sidebarPath: require.resolve('./sidebars.js'),
|
||||
showLastUpdateTime: true,
|
||||
editUrl: 'https://github.com/rancher/rancher-docs/edit/main/',
|
||||
lastVersion: 'current',
|
||||
// lastVersion: '2.7',
|
||||
includeCurrentVersion: false,
|
||||
versions: {
|
||||
current: {
|
||||
label: 'Latest'
|
||||
// current: {
|
||||
// label: 'Next 🚧',
|
||||
// path: 'next',
|
||||
// banner: 'unreleased'
|
||||
// },
|
||||
latest: {
|
||||
label: 'latest',
|
||||
path: '',
|
||||
banner: 'none'
|
||||
},
|
||||
2.8: {
|
||||
label: 'v2.8 (Preview)',
|
||||
path: 'v2.8',
|
||||
banner: 'unreleased'
|
||||
},
|
||||
2.7: {
|
||||
label: 'v2.7',
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: 备份和恢复 Docker 安装的 Rancher
|
||||
---
|
||||
|
||||
- [备份](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md)
|
||||
- [还原](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-docker-installed-rancher.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: RKE 集群配置
|
||||
---
|
||||
|
||||
本文已迁移到[此处](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
title: 参与 Rancher 社区贡献
|
||||
---
|
||||
|
||||
本文介绍了 Rancher 仓库和 Rancher 文档、如何构建 Rancher 仓库以及提交 issue 时要包含哪些信息。
|
||||
|
||||
有关如何为 Rancher 项目开发做出贡献的更多详细信息,请参阅 [Rancher Developer Wiki](https://github.com/rancher/rancher/wiki)。Wiki 包含以下主题的资源:
|
||||
|
||||
- 如何搭建 Rancher 开发环境并运行测试
|
||||
- Issue 在开发生命周期中的典型流程
|
||||
- 编码指南和开发最佳实践
|
||||
- 调试和故障排除
|
||||
- 开发 Rancher API
|
||||
|
||||
在 Rancher Users Slack 上,开发者的频道是 **#developer**。
|
||||
|
||||
## Rancher 文档
|
||||
|
||||
如果你对此网站上的文档有建议,请在主 [Rancher 文档](https://github.com/rancher/rancher-docs)仓库中[提交 issue](https://github.com/rancher/rancher-docs/issues/new/choose)。此仓库包含 Rancher v2.0 及更高版本的文档。
|
||||
|
||||
有关贡献和构建 Rancher v2.x 文档仓库的更多详细信息,请参阅 [Rancher 文档 README](https://github.com/rancher/rancher-docs#readme)。
|
||||
|
||||
有关 Rancher v1.6 及更早版本的文档,请参阅 [Rancher 1.x docs](https://github.com/rancher/rancher.github.io) 仓库,其中包含 https://rancher.com/docs/rancher/v1.6/en/ 的源文件。
|
||||
|
||||
## Rancher 仓库
|
||||
|
||||
所有仓库都位于我们的主要 GitHub 组织内。Rancher 使用了很多仓库,以下是部分主要仓库的描述:
|
||||
|
||||
| 仓库 | URL | 描述 |
|
||||
-----------|-----|-------------
|
||||
| Rancher | https://github.com/rancher/rancher | Rancher 2.x 的主要源码仓库。 |
|
||||
| Types | https://github.com/rancher/types | 包含 Rancher 2.x 的所有 API 类型的仓库。 |
|
||||
| API Framework | https://github.com/rancher/norman | API 框架,用于构建由 Kubernetes 自定义资源支持的 Rancher 风格的 API。 |
|
||||
| User Interface | https://github.com/rancher/dashboard/ | Dashboard UI 源码仓库。 |
|
||||
| (Rancher) Docker Machine | https://github.com/rancher/machine | 使用主机驱动时使用的 Docker Machine 二进制文件的源码仓库。这是 `docker/machine` 仓库的一个 fork。 |
|
||||
| machine-package | https://github.com/rancher/machine-package | 用于构建 Rancher Docker Machine 二进制文件。 |
|
||||
| kontainer-engine | https://github.com/rancher/kontainer-engine | kontainer-engine 的源码仓库,它是配置托管 Kubernetes 集群的工具。 |
|
||||
| RKE repository | https://github.com/rancher/rke | Rancher Kubernetes Engine 的源码仓库,该工具可在任何主机上配置 Kubernetes 集群。 |
|
||||
| CLI | https://github.com/rancher/cli | Rancher 2.x 中使用的 Rancher CLI 的源码仓库。 |
|
||||
| (Rancher) Helm repository | https://github.com/rancher/helm | 打包的 Helm 二进制文件的源码仓库。这是 `helm/helm` 仓库的一个 fork。 |
|
||||
| Telemetry repository | https://github.com/rancher/telemetry | Telemetry 二进制文件的源码仓库。 |
|
||||
| loglevel repository | https://github.com/rancher/loglevel | loglevel 二进制文件的源码仓库,用于动态更改日志级别。 |
|
||||
|
||||
要查看 Rancher 使用的所有库/项目,请查看 `rancher/rancher` 仓库中的 [`go.mod` 文件](https://github.com/rancher/rancher/blob/master/go.mod)。
|
||||
|
||||
<br/>
|
||||
<sup>用于配置/管理 Kubernetes 集群的 Rancher 组件。</sup>
|
||||
|
||||
### 构建 Rancher 仓库
|
||||
|
||||
每个仓库都应该有一个 Makefile,并且可以使用 `make` 命令进行构建。`make` 目标基于仓库中 `/scripts` 目录中的脚本,每个目标都使用 [Dapper](https://github.com/rancher/dapper) 在孤立的环境中运行。`Dockerfile.dapper` 将用于此操作,它包含了所需的所有构建工具。
|
||||
|
||||
默认目标是 `ci`,它将运行 `./scripts/validate`、`./scripts/build`、`./scripts/test ` 和 `./scripts/package`。生成的二进制文件将在 `./build/bin` 中,通常也打包在 Docker 镜像中。
|
||||
|
||||
### Rancher Bug、Issue 或疑问
|
||||
|
||||
如果你发现任何 bug 或问题,由于有人可能遇到过同样的问题,或者我们已经正在寻找解决方案,因此请先在[已报告 issue](https://github.com/rancher/rancher/issues) 中搜索。
|
||||
|
||||
如果找不到与你的问题相关的内容,请通过[提出 issue](https://github.com/rancher/rancher/issues/new) 与我们联系。与 Rancher 相关的仓库有很多,但请将 issue 提交到 Rancher 仓库中,这样能确保我们能看到这些 issue。如果你想就一个用例提出问题或询问其他用户,你可以在 [Rancher 论坛](https://forums.rancher.com)上发帖。
|
||||
|
||||
#### 提交 Issue 的检查清单
|
||||
|
||||
提交问题时请遵循此清单,以便我们调查和解决问题。如果你能提供更多信息,我们就可以使用更多数据来确定导致问题的原因或发现更多相关的内容。
|
||||
|
||||
:::note
|
||||
|
||||
如果数据量很大,请使用 [GitHub Gist](https://gist.github.com/) 或类似工具,并在 issue 中链接你创建的资源。
|
||||
|
||||
:::
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
请删除所有敏感数据。
|
||||
|
||||
:::
|
||||
|
||||
- **资源**:请尽量详细地提供所使用的资源。导致问题的原因可能很多,因此请尽量提供更多细节来帮助我们确定根本原因。下面是一些参考示例:
|
||||
- **主机**:主机的规格(例如 CPU/内存/磁盘),运行在什么云厂商上,使用的 Amazon Machine Image,使用的 DigitalOcean droplet,配置的镜像(复现时用于重新构建或使用)。
|
||||
- **操作系统**:使用的是什么操作系统。在此处提供详细信息,例如 `cat /etc/os-release` 的输出(确切的操作系统版本)和 `uname -r` 的输出(确切的内核)。
|
||||
- **Docker**:使用的 Docker 版本以及安装的方法。Docker 的大部分详情都可以在 `docker version` 和 `docker info` 的输出中找到。
|
||||
- **环境**:是否使用了代理,是否使用可信的 CA/自签名证书,是否使用了外部负载均衡器。
|
||||
- **Rancher**:使用的 Rancher 版本,可以在 UI 左下角或者从主机运行的 image 标签中获取。
|
||||
- **集群**:创建了什么样的集群,如何创建的,在创建时指定了什么参数。
|
||||
- **复现 issue 的步骤**:尽量详细地说明你是如何触发所报告的情况的。这有助于复现你的情况。
|
||||
- 提供从创建到你报告的情况使用的手动步骤或自动化脚本。
|
||||
- **日志**:提供使用资源的数据/日志。
|
||||
- Rancher
|
||||
- Docker 安装
|
||||
|
||||
```
|
||||
docker logs \
|
||||
--timestamps \
|
||||
$(docker ps | grep -E "rancher/rancher:|rancher/rancher " | awk '{ print $1 }')
|
||||
```
|
||||
- 使用 `kubectl` 的 Kubernetes 安装
|
||||
|
||||
:::note
|
||||
|
||||
确保你配置了正确的 kubeconfig(例如,如果 Rancher 安装在 Kubernetes 集群上,则 `export KUBECONFIG=$PWD/kube_config_cluster.yml`)或通过 UI 使用了嵌入式 kubectl。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
kubectl -n cattle-system \
|
||||
logs \
|
||||
-l app=rancher \
|
||||
--timestamps=true
|
||||
```
|
||||
- 在 RKE 集群的每个节点上使用 `docker` 的 Docker 安装
|
||||
|
||||
```
|
||||
docker logs \
|
||||
--timestamps \
|
||||
$(docker ps | grep -E "rancher/rancher@|rancher_rancher" | awk '{ print $1 }')
|
||||
```
|
||||
- 使用 RKE 附加组件的 Kubernetes 安装
|
||||
|
||||
:::note
|
||||
|
||||
确保你配置了正确的 kubeconfig(例如,如果 Rancher Server 安装在 Kubernetes 集群上,则 `export KUBECONFIG=$PWD/kube_config_cluster.yml`)或通过 UI 使用了嵌入式 kubectl。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
kubectl -n cattle-system \
|
||||
logs \
|
||||
--timestamps=true \
|
||||
-f $(kubectl --kubeconfig $KUBECONFIG get pods -n cattle-system -o json | jq -r '.items[] | select(.spec.containers[].name="cattle-server") | .metadata.name')
|
||||
```
|
||||
- 系统日志记录(可能不存在,取决于操作系统)
|
||||
- `/var/log/messages`
|
||||
- `/var/log/syslog`
|
||||
- `/var/log/kern.log`
|
||||
- Docker Daemon 日志记录(可能并不全部存在,取决于操作系统)
|
||||
- `/var/log/docker.log`
|
||||
- **指标**:如果你遇到性能问题,请提供尽可能多的指标数据(文件或屏幕截图)来帮助我们确定问题。如果你遇到主机相关的问题,你可以提供 `top`、`free -m`、`df` 的输出,这些输出会显示进程/内存/磁盘的使用情况。
|
||||
@@ -0,0 +1,204 @@
|
||||
---
|
||||
title: CNI 网络插件
|
||||
description: 了解容器网络接口 (CNI)、Rancher 提供的 CNI 网络插件、提供商的功能,以及如何选择网络提供商
|
||||
---
|
||||
|
||||
## 什么是 CNI?
|
||||
|
||||
CNI(容器网络接口)是一个[云原生计算基金会项目](https://cncf.io/),它包含了一些规范和库,用于编写在 Linux 容器中配置网络接口的一系列插件。CNI 只关注容器的网络连接,并在容器被删除时移除所分配的资源。
|
||||
|
||||
Kubernetes 使用 CNI 作为网络提供商和 Kubernetes Pod 网络之间的接口。
|
||||
|
||||

|
||||
|
||||
有关更多信息,请访问 [CNI GitHub 项目](https://github.com/containernetworking/cni)。
|
||||
|
||||
## CNI 使用了哪些网络模型?
|
||||
|
||||
CNI 网络插件使用封装网络模型(例如 Virtual Extensible Lan,缩写是 [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan))或非封装网络模型(例如 Border Gateway Protocol,缩写是 [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol))来实现网络结构。
|
||||
|
||||
### 什么是封装网络?
|
||||
|
||||
此网络模型提供了一个逻辑二层(L2)网络,该网络封装在跨 Kubernetes 集群节点的现有三层(L3)网络拓扑上。使用此模型,你可以为容器提供一个隔离的 L2 网络,而无需分发路由。封装网络带来了少量的处理开销以及由于覆盖封装生成 IP header 造成的 IP 包大小增加。封装信息由 Kubernetes worker 之间的 UDP 端口分发,交换如何访问 MAC 地址的网络控制平面信息。此类网络模型中常用的封装是 VXLAN、Internet 协议安全性 (IPSec) 和 IP-in-IP。
|
||||
|
||||
简单来说,这种网络模型在 Kubernetes worker 之间生成了一种扩展网桥,其中连接了 pod。
|
||||
|
||||
如果你偏向使用扩展 L2 网桥,则可以选择此网络模型。此网络模型对 Kubernetes worker 的 L3 网络延迟很敏感。如果数据中心位于不同的地理位置,请确保它们之间的延迟较低,以避免最终的网络分段。
|
||||
|
||||
使用这种网络模型的 CNI 网络插件包括 Flannel、Canal、Weave 和 Cilium。默认情况下,Calico 不会使用此模型,但你可以对其进行配置。
|
||||
|
||||

|
||||
|
||||
### 什么是非封装网络?
|
||||
|
||||
该网络模型提供了一个 L3 网络,用于在容器之间路由数据包。此模型不会生成隔离的 L2 网络,也不会产生开销。这些好处的代价是,Kubernetes worker 必须管理所需的所有路由分发。该网络模型不使用 IP header 进行封装,而是使用 Kubernetes Worker 之间的网络协议来分发路由信息以实现 Pod 连接,例如 [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)。
|
||||
|
||||
简而言之,这种网络模型在 Kubernetes worker 之间生成了一种扩展网络路由器,提供了如何连接 Pod 的信息。
|
||||
|
||||
如果你偏向使用 L3 网络,则可以选择此网络模型。此模型在操作系统级别为 Kubernetes Worker 动态更新路由。对延迟较不敏感。
|
||||
|
||||
使用这种网络模型的 CNI 网络插件包括 Calico 和 Cilium。Cilium 可以使用此模型进行配置,即使这不是默认模式。
|
||||
|
||||

|
||||
|
||||
## Rancher 提供哪些 CNI 插件?
|
||||
|
||||
### RKE Kubernetes 集群
|
||||
|
||||
Rancher 开箱即用地为 RKE Kubernetes 集群提供了几个 CNI 网络插件,分别是 Canal、Flannel、Calico 和 Weave。
|
||||
|
||||
如果你使用 Rancher 创建新的 Kubernetes 集群,你可以选择你的 CNI 网络插件。
|
||||
|
||||
#### Canal
|
||||
|
||||

|
||||
|
||||
Canal 是一个 CNI 网络插件,它很好地结合了 Flannel 和 Calico 的优点。它让你轻松地将 Calico 和 Flannel 网络部署为统一的网络解决方案,将 Calico 的网络策略执行与 Calico(未封装)和 Flannel(封装)丰富的网络连接选项结合起来。
|
||||
|
||||
Canal 是 Rancher 默认的 CNI 网络插件,并采用了 Flannel 和 VXLAN 封装。
|
||||
|
||||
Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN) 和 TCP 端口 `9099`(健康检查)。如果使用 Wireguard,则需要打开 UDP 端口 `51820` 和 `51821`。有关详细信息,请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)。
|
||||
|
||||

|
||||
|
||||
有关详细信息,请参阅 [Canal GitHub 页面](https://github.com/projectcalico/canal)。
|
||||
|
||||
#### Flannel
|
||||
|
||||

|
||||
|
||||
Flannel 是为 Kubernetes 配置 L3 网络结构的简单方法。Flannel 在每台主机上运行一个名为 flanneld 的二进制 Agent,该 Agent 负责从更大的预配置地址空间中为每台主机分配子网租约。Flannel 通过 Kubernetes API 或直接使用 etcd 来存储网络配置、分配的子网、以及其他辅助数据(例如主机的公共 IP)。数据包使用某种后端机制来转发,默认封装为 [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan)。
|
||||
|
||||
默认情况下,封装的流量是不加密的。Flannel 提供了两种加密方案:
|
||||
|
||||
* [IPSec](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#ipsec):使用 [strongSwan](https://www.strongswan.org/) 在 Kubernetes worker 之间建立加密的 IPSec 隧道。它是加密的实验性后端。
|
||||
* [WireGuard](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#wireguard):比 strongSwan 更快的替代方案。
|
||||
|
||||
Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN)。有关详细信息,请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
|
||||
|
||||

|
||||
|
||||
有关详细信息,请参阅 [Flannel GitHub 页面](https://github.com/flannel-io/flannel)。
|
||||
|
||||
#### Weave
|
||||
|
||||

|
||||
|
||||
Weave 在云上的 Kubernetes 集群中启用网络和网络策略。此外,它还支持加密对等节点之间的流量。
|
||||
|
||||
Kubernetes worker 需要打开 TCP 端口 `6783`(控制端口)、UDP 端口 `6783` 和 UDP 端口 `6784`(数据端口)。有关详细信息,请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
|
||||
|
||||
有关详细信息,请参阅以下页面:
|
||||
|
||||
- [Weave Net 官网](https://www.weave.works/)
|
||||
|
||||
### RKE2 Kubernetes 集群
|
||||
|
||||
Rancher 开箱即用地为 RKE2 Kubernetes 集群提供了几个 CNI 网络插件,分别是 [Canal](#canal)(见上一节)、Calico 和 Cilium。
|
||||
|
||||
如果你使用 Rancher 创建新的 Kubernetes 集群,你可以选择你的 CNI 网络插件。
|
||||
|
||||
#### Calico
|
||||
|
||||

|
||||
|
||||
Calico 在云上的 Kubernetes 集群中启用网络和网络策略。默认情况下,Calico 使用纯净、未封装的 IP 网络结构和策略引擎为 Kubernetes 工作负载提供网络。工作负载能够使用 BGP 在云上和本地进行通信。
|
||||
|
||||
Calico 还提供了一种无状态的 IP-in-IP 或 VXLAN 封装模式。如果需要,你可以使用它。Calico 还支持策略隔离,让你使用高级 ingress 和 egress 策略保护和管理 Kubernetes 工作负载。
|
||||
|
||||
如果使用 BGP,Kubernetes Worker 需要打开 TCP 端口 `179`,如果使用 VXLAN 封装,则需要打开 UDP 端口 `4789`。另外,使用 Typha 时需要 TCP 端口 `5473`。有关详细信息,请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
在 Rancher 2.6.3 中,Calico 探测到在安装 RKE2 时 Windows 节点会失败。<b>请注意,此问题已在 v2.6.4 中解决。</b>
|
||||
|
||||
- 要解决此问题,请先导航到 `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`。
|
||||
|
||||
- 在那里,将当前设置 `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` 更改为新设置 `https://raw.githubusercontent .com/rancher/rke2/master/windows/rke2-install.ps1`。
|
||||
|
||||
:::
|
||||
|
||||

|
||||
|
||||
有关详细信息,请参阅以下页面:
|
||||
|
||||
- [Project Calico 官方网站](https://www.projectcalico.org/)
|
||||
- [Calico 项目 GitHub 页面](https://github.com/projectcalico/calico)
|
||||
|
||||
#### Cilium
|
||||
|
||||

|
||||
|
||||
Cilium 在 Kubernetes 中启用网络和网络策略(L3、L4 和 L7)。默认情况下,Cilium 使用 eBPF 技术在节点内部路由数据包,并使用 VXLAN 将数据包发送到其他节点。你也可以配置非封装的技术。
|
||||
|
||||
Cilium 推荐大于 5.2 的内核版本,从而充分利用 eBPF 的能力。Kubernetes worker 需要打开 TCP 端口 `8472`(VXLAN)和 TCP 端口 `4240`(健康检查)。此外,还必须为健康检查启用 ICMP 8/0。有关详细信息,请查看 [Cilium 系统要求](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements)。
|
||||
|
||||
##### Cilium 中跨节点的 Ingress 路由
|
||||
<br/>
|
||||
默认情况下,Cilium 不允许 Pod 与其他节点上的 Pod 通信。要解决此问题,请启用 Ingress Controller 以使用 “CiliumNetworkPolicy” 进行跨节点路由请求。
|
||||
|
||||
选择 Cilium CNI 并为新集群启用项目网络隔离后,配置如下:
|
||||
|
||||
```
|
||||
apiVersion: cilium.io/v2
|
||||
kind: CiliumNetworkPolicy
|
||||
metadata:
|
||||
name: hn-nodes
|
||||
namespace: default
|
||||
spec:
|
||||
endpointSelector: {}
|
||||
ingress:
|
||||
- fromEntities:
|
||||
- remote-node
|
||||
```
|
||||
|
||||
## 各个网络插件的 CNI 功能
|
||||
|
||||
下表总结了 Rancher 中每个 CNI 网络插件支持的不同功能:
|
||||
|
||||
| 提供商 | 网络模型 | 路线分发 | 网络策略 | 网格 | 外部数据存储 | 加密 | Ingress/Egress 策略 |
|
||||
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
|
||||
| Canal | 封装 (VXLAN) | 否 | 是 | 否 | K8s API | 是 | 是 |
|
||||
| Flannel | 封装 (VXLAN) | 否 | 否 | 否 | K8s API | 是 | 否 |
|
||||
| Calico | 封装(VXLAN,IPIP)或未封装 | 是 | 是 | 是 | Etcd 和 K8s API | 是 | 是 |
|
||||
| Weave | 封装 | 是 | 是 | 是 | 否 | 是 | 是 |
|
||||
| Cilium | 封装 (VXLAN) | 是 | 是 | 是 | Etcd 和 K8s API | 是 | 是 |
|
||||
|
||||
- 网络模型:封装或未封装。如需更多信息,请参阅 [CNI 中使用的网络模型](#cni-使用了哪些网络模型)。
|
||||
|
||||
- 路由分发:一种外部网关协议,用于在互联网上交换路由和可达性信息。BGP 可以帮助进行跨集群 pod 之间的网络。此功能对于未封装的 CNI 网络插件是必须的,并且通常由 BGP 完成。如果你想构建跨网段拆分的集群,路由分发是一个很好的功能。
|
||||
|
||||
- 网络策略:Kubernetes 提供了强制执行规则的功能,这些规则决定了哪些 service 可以使用网络策略进行相互通信。这是从 Kubernetes 1.7 起稳定的功能,可以与某些网络插件一起使用。
|
||||
|
||||
- 网格:允许在不同的 Kubernetes 集群间进行 service 之间的网络通信。
|
||||
|
||||
- 外部数据存储:具有此功能的 CNI 网络插件需要一个外部数据存储来存储数据。
|
||||
|
||||
- 加密:允许加密和安全的网络控制和数据平面。
|
||||
|
||||
- Ingress/Egress 策略:允许你管理 Kubernetes 和非 Kubernetes 通信的路由控制。
|
||||
|
||||
|
||||
## CNI 社区人气
|
||||
|
||||
下表总结了不同的 GitHub 指标,让你了解每个项目的受欢迎程度和活动。数据收集于 2022 年 1 月。
|
||||
|
||||
| 提供商 | 项目 | Stars | Forks | Contributors |
|
||||
| ---- | ---- | ---- | ---- | ---- |
|
||||
| Canal | https://github.com/projectcalico/canal | 679 | 100 | 21 |
|
||||
| Flannel | https://github.com/flannel-io/flannel | 7k | 2.5k | 185 |
|
||||
| Calico | https://github.com/projectcalico/calico | 3.1k | 741 | 224 |
|
||||
| Weave | https://github.com/weaveworks/weave/ | 6.2k | 635 | 84 |
|
||||
| Cilium | https://github.com/cilium/cilium | 10.6k | 1.3k | 352 |
|
||||
|
||||
<br/>
|
||||
|
||||
## 使用哪个 CNI 插件?
|
||||
|
||||
这取决于你的项目需求。各个提供商都有不同的功能和选项。没有一个提供商可以满足所有用户的需求。
|
||||
|
||||
Canal 是默认的 CNI 网络插件。对于大多数用例,我们推荐你使用它。它使用 Flannel 为容器提供封装网络,同时添加 Calico 网络策略,可以在网络方面提供项目/命名空间隔离。
|
||||
|
||||
## 如何配置 CNI 网络插件?
|
||||
|
||||
如需了解如何为你的集群配置网络插件,请参阅[集群选项](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。有关更高级的配置选项,请参阅有关使用[配置文件](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-集群配置文件参考)和[网络插件](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/)选项来配置集群的说明。
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Rancher 弃用的功能
|
||||
---
|
||||
|
||||
### Rancher 的弃用策略是什么?
|
||||
|
||||
我们在支持[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方弃用策略。
|
||||
|
||||
### 在哪里可以找到 Rancher 已弃用的功能?
|
||||
|
||||
Rancher 会在 GitHub 上的[发行说明](https://github.com/rancher/rancher/releases)中公布已弃用的功能。请参阅以下补丁版本了解已弃用的功能:
|
||||
|
||||
| 补丁版本 | 发布日期 |
|
||||
|---------------|---------------|
|
||||
| [2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) | 2021 年 8 月 31 日 |
|
||||
| [2.6.1](https://github.com/rancher/rancher/releases/tag/v2.6.1) | 2021 年 10 月 11 日 |
|
||||
| [2.6.2](https://github.com/rancher/rancher/releases/tag/v2.6.2) | 2021 年 10 月 19 日 |
|
||||
| [2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) | 2021 年 12 月 21 日 |
|
||||
| [2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) | 2022 年 3 月 31 日 |
|
||||
| [2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) | 2022 年 5 月 12 日 |
|
||||
| [2.6.6](https://github.com/rancher/rancher/releases/tag/v2.6.6) | 2022 年 6 月 30 日 |
|
||||
|
||||
|
||||
### 如果某个功能标记为弃用,我要怎么做?
|
||||
|
||||
如果某个发行版将某功能标记为"Deprecated"(已弃用),该功能仍然可用并受支持,从而允许用户按照常规流程进行升级。在升级到该功能被标记为"已删除"的发行版前,用户/管理员应该计划剥离该功能。对于新部署,我们建议不要使用已弃用的功能。
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: Dockershim
|
||||
---
|
||||
|
||||
Dockershim 是 Kubelet 和 Docker Daemon 之间的 CRI 兼容层。Kubernetes 1.20 版本宣布了[移除树内 Dockershim](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。目前计划在 Kubernetes 1.24 中移除。有关此移除的更多信息以及时间线,请参见 [Kubernetes Dockershim 弃用相关的常见问题](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed)。
|
||||
|
||||
从 Kubernetes 1.21 开始。RKE 集群支持外部 Dockershim,来让用户继续使用 Docker 作为 CRI 运行时。现在,我们通过使用 [Mirantis 和 Docker ](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/) 来确保 RKE 集群可以继续使用 Docker,从而实现上游开源社区的 Dockershim。
|
||||
|
||||
要启用外部 Dockershim,配置以下选项:
|
||||
|
||||
```
|
||||
enable_cri_dockerd: true
|
||||
```
|
||||
|
||||
如果你想使用其他容器运行时,Rancher 也提供使用 Containerd 作为默认运行时的,以边缘为中心的 K3s,和以数据中心为中心的 RKE2 Kubernetes 发行版。即使在 Kubernetes 1.24 删除了树内 Dockershim 之后,你也可以通过 Rancher 升级和管理导入的 RKE2 和 K3s Kubernetes 集群。
|
||||
|
||||
### 常见问题
|
||||
|
||||
<br/>
|
||||
|
||||
Q. 如果要获得 Rancher 对上游 Dockershim 的支持,我需要升级 Rancher 吗?
|
||||
|
||||
对于 RKE,Dockershim 的上游支持从 Kubernetes 1.21 开始。你需要使用 Rancher 2.6 或更高版本才能获取使用 Kubernetes 1.21 的 RKE 的支持。详情请参阅我们的[支持矩阵](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/)。
|
||||
|
||||
<br/>
|
||||
|
||||
Q. 我目前的 RKE 使用 Kubernetes 1.20。为了避免出现不再支持 Dockershim 的情况,我是否需要尽早将 RKE 升级到 Kubernetes 1.21?
|
||||
|
||||
A. 在使用 Kubernetes 1.20 的 RKE 中,Dockershim 版本依然可用,而且在 Kubernetes 1.24 之前不会在上游弃用。Kubernetes 会发出弃用 Dockershim 的警告,而 Rancher 在使用 Kubernetes 1.21 的 RKE 中已经缓解了这个问题。你可以按照计划正常升级到 Kubernetes 1.21,但也应该考虑在升级到 Kubernetes 1.22 时启用外部 Dockershim。在升级到 Kubernetes 1.24 之前,你需要启用外部 Dockershim,此时现有的实现都会被删除。
|
||||
|
||||
有关此移除的更多信息以及时间线,请参见 [Kubernetes Dockershim 弃用相关的常见问题](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed)。
|
||||
|
||||
<br/>
|
||||
|
||||
Q: 如果我不想再依赖 Dockershim,我还有什么选择?
|
||||
|
||||
A: 你可以为 Kubernetes 使用不需要 Dockershim 支持的运行时,如 Containerd。RKE2 和 K3s 就是其中的两个选项。
|
||||
|
||||
<br/>
|
||||
|
||||
Q: 如果我目前使用 RKE1,但想切换到 RKE2,我可以怎样进行迁移?
|
||||
|
||||
A: Rancher 也在探索就地升级路径的可能性。此外,你始终可以使用 kubectl 将工作负载迁移到另一个集群。
|
||||
|
||||
<br/>
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: 一般常见问题解答
|
||||
---
|
||||
|
||||
本文包含了用户常见的 Rancher 2.x 问题。
|
||||
|
||||
有关常见技术问题,请参阅[常见技术问题解答](technical-items.md)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 2.x 支持 Docker Swarm 和 Mesos 作为环境类型吗?**
|
||||
|
||||
如果你在 Rancher 2.x 中创建环境,Swarm 和 Mesos 将不再是可选的标准选项。但是,Swarm 和 Mesos 还能继续作为可以部署的商店应用程序。这是一个艰难的决定,但这是大势所趋。比如说,15,000 多个集群可能只有大约 200 个在运行 Swarm。
|
||||
|
||||
<br/>
|
||||
|
||||
**是否可以使用 Rancher 2.x 管理 Azure Kubernetes 服务?**
|
||||
|
||||
是的。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 是否支持 Windows?**
|
||||
|
||||
Rancher 支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息,请参阅[为 Windows 配置自定义集群](../pages-for-subheaders/use-windows-clusters.md)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 是否支持 Istio?**
|
||||
|
||||
Rancher 支持 [Istio](../pages-for-subheaders/istio.md)。
|
||||
|
||||
此外,Istio 是在我们的微型 PaaS “Rio” 中实现的,它可以运行在 Rancher 2.x 以及任何符合 CNCF 的 Kubernetes 集群上。详情请参阅[这里](https://rio.io/)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 2.x 是否支持使用 Hashicorp 的 Vault 来存储密文?**
|
||||
|
||||
密文管理已在我们的 roadmap 上,但我们尚未将该功能分配给特定版本。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 2.x 是否也支持 RKT 容器?**
|
||||
|
||||
目前,我们只支持 Docker。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 2.x 是否支持将 Calico、Contiv、Contrail、Flannel、Weave net 等网络插件用于嵌入和已注册的 Kubernetes?**
|
||||
|
||||
Rancher 开箱即用地为 Kubernetes 集群提供了几个 CNI 网络插件,分别是 Canal、Flannel、Calico 和 Weave。有关官方支持的详细信息,请参阅 [Rancher 支持矩阵](https://rancher.com/support-maintenance-terms/)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 是否计划支持 Traefik?**
|
||||
|
||||
目前,我们不打算提供嵌入式 Traefik 支持,但我们仍在探索负载均衡方案。
|
||||
|
||||
<br/>
|
||||
|
||||
**我可以将 OpenShift Kubernetes 集群导入 2.x 吗?**
|
||||
|
||||
我们的目标是运行任何上游 Kubernetes 集群。因此,Rancher 2.x 应该可以与 OpenShift 一起使用,但我们尚未对此进行测试。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 会集成 Longhorn 吗?**
|
||||
|
||||
是的。Longhorn 已集成到 Rancher 2.5+ 中。
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: 安装和配置 kubectl
|
||||
---
|
||||
|
||||
`kubectl` 是一个 CLI 工具,用于运行 Kubernetes 集群相关的命令。Rancher 2.x 中的许多维护和管理任务都需要它。
|
||||
|
||||
### 安装
|
||||
|
||||
请参阅 [kubectl 安装](https://kubernetes.io/docs/tasks/tools/install-kubectl/)将 kubectl 安装到你的操作系统上。
|
||||
|
||||
### 配置
|
||||
|
||||
使用 RKE 创建 Kubernetes 集群时,RKE 会在本地目录中创建一个 `kube_config_cluster.yml`,该文件包含使用 `kubectl` 或 `helm` 等工具连接到新集群的凭证。
|
||||
|
||||
你可以将此文件复制为 `$HOME/.kube/config`。如果你使用多个 Kubernetes 集群,将 `KUBECONFIG` 环境变量设置为 `kube_config_cluster.yml` 的路径:
|
||||
|
||||
```
|
||||
export KUBECONFIG=$(pwd)/kube_config_cluster.yml
|
||||
```
|
||||
|
||||
使用 `kubectl` 测试你的连接性,并查看你是否可以获取节点列表:
|
||||
|
||||
```
|
||||
kubectl get nodes
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
165.227.114.63 Ready controlplane,etcd,worker 11m v1.10.1
|
||||
165.227.116.167 Ready controlplane,etcd,worker 11m v1.10.1
|
||||
165.227.127.226 Ready controlplane,etcd,worker 11m v1.10.1
|
||||
```
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: 卸载 Rancher
|
||||
---
|
||||
|
||||
本文介绍了如果你不再需要 Rancher、不想再由 Rancher 管理集群、或想删除 Rancher Server 需要怎么做。
|
||||
|
||||
|
||||
### 如果 Rancher Server 被删除,下游集群中的工作负载会怎样?
|
||||
|
||||
如果 Rancher 删除了或无法恢复,Rancher 管理的下游 Kubernetes 集群中的所有工作负载将继续正常运行。
|
||||
|
||||
### 如果删除了 Rancher Server,该如何访问下游集群?
|
||||
|
||||
如果删除了 Rancher,访问下游集群的方式取决于集群的类型和集群的创建方式。总而言之:
|
||||
|
||||
- **注册集群**:集群不受影响,你可以注册集群前的方法访问该集群。
|
||||
- **托管的 Kubernetes 集群**:如果你在 Kubernetes 云提供商(例如 EKS、GKE 或 AKS)中创建集群,你可以继续使用提供商的云凭证来管理集群。
|
||||
- **RKE 集群**:要访问 [RKE 集群](../pages-for-subheaders/launch-kubernetes-with-rancher.md),集群必须启用了[授权集群端点(authorized cluster endpoint,ACE)](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-授权集群端点),而且你必须从 Rancher UI 下载了集群的 kubeconfig 文件。RKE 集群默认启用授权集群端点。通过使用此端点,你可以直接使用 kubectl 访问你的集群,而不用通过 Rancher Server 的[认证代理](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-认证代理)进行通信。有关配置 kubectl 以使用授权集群端点的说明,请参阅[使用 kubectl 和 kubeconfig 文件直接访问集群](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#直接使用下游集群进行身份验证)。这些集群将使用删除 Rancher 时配置的身份验证快照。
|
||||
|
||||
### 如果我不想再使用 Rancher 了该怎么做?
|
||||
|
||||
:::note
|
||||
|
||||
之前推荐的 [System Tools](../reference-guides/system-tools.md) 自 2022 年 6 月起已弃用。
|
||||
|
||||
:::
|
||||
|
||||
如果你[在 Kubernetes 集群上安装了 Rancher](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md),你可以使用 [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) 工具删除 Rancher。
|
||||
|
||||
在高可用 (HA) 模式下卸载 Rancher 还将删除所有 `helm-operation-*` Pod 和以下应用程序:
|
||||
|
||||
- fleet
|
||||
- fleet-agent
|
||||
- rancher-operator
|
||||
- rancher-webhook
|
||||
|
||||
自定义资源 (CRD) 和自定义命名空间仍需要手动删除。
|
||||
|
||||
如果你在 Docker 中安装 Rancher,则可以通过删除运行 Rancher 的单个 Docker 容器来卸载 Rancher。
|
||||
|
||||
移除 Rancher 不会影响导入的集群。有关其他集群类型,请参考[移除 Rancher 后访问下游集群](#如果删除了-rancher-server该如何访问下游集群)。
|
||||
|
||||
### 如果我不想 Rancher 管理我的注册集群该怎么办?
|
||||
|
||||
如果你在 Rancher UI 中删除了已注册的集群,则该集群将与 Rancher 分离,集群不会发生改变,你可以使用注册集群之前的方法访问该集群。
|
||||
|
||||
要分离集群:
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
2. 转到要与 Rancher 分离的已注册集群,然后单击 **⋮ > 删除**。
|
||||
3. 单击**删除**。
|
||||
|
||||
**结果**:注册的集群已与 Rancher 分离,并在 Rancher 外正常运行。
|
||||
|
||||
### 如果我不想 Rancher 管理我的 RKE 集群或托管的 Kubernetes 集群该怎么办?
|
||||
|
||||
目前,我们没有将这些集群从 Rancher 中分离出来的功能。在这种情况下,“分离”指的是将 Rancher 组件移除出集群,并独立于 Rancher 管理对集群的访问。
|
||||
|
||||
[此 issue](https://github.com/rancher/rancher/issues/25234) 跟踪了在没有 Rancher 的情况下管理这些集群的功能。
|
||||
|
||||
有关如何在删除 Rancher Server 后访问集群的更多信息,请参阅[本节](#如果删除了-rancher-server该如何访问下游集群)。
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: 安全
|
||||
|
||||
---
|
||||
|
||||
**是否有强化指南?**
|
||||
|
||||
强化指南现在位于[安全](../pages-for-subheaders/rancher-security.md)部分。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher Kubernetes 集群 CIS Benchmark 测试的结果是什么?**
|
||||
|
||||
我们已经针对强化的 Rancher Kubernetes 集群运行了 CIS Kubernetes Benchmark 测试。你可以在[安全](../pages-for-subheaders/rancher-security.md)中找到该评估的结果。
|
||||
@@ -0,0 +1,176 @@
|
||||
---
|
||||
title: 技术
|
||||
---
|
||||
|
||||
### 如何重置管理员密码?
|
||||
|
||||
Docker 安装:
|
||||
```
|
||||
$ docker exec -ti <container_id> reset-password
|
||||
New password for default administrator (user-xxxxx):
|
||||
<new_password>
|
||||
```
|
||||
|
||||
Kubernetes 安装(Helm):
|
||||
```
|
||||
$ KUBECONFIG=./kube_config_cluster.yml
|
||||
$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher --no-headers | head -1 | awk '{ print $1 }') -c rancher -- reset-password
|
||||
New password for default administrator (user-xxxxx):
|
||||
<new_password>
|
||||
```
|
||||
|
||||
|
||||
|
||||
### 我删除/停用了最后一个 admin,该如何解决?
|
||||
Docker 安装:
|
||||
```
|
||||
$ docker exec -ti <container_id> ensure-default-admin
|
||||
New default administrator (user-xxxxx)
|
||||
New password for default administrator (user-xxxxx):
|
||||
<new_password>
|
||||
```
|
||||
|
||||
Kubernetes 安装(Helm):
|
||||
```
|
||||
$ KUBECONFIG=./kube_config_cluster.yml
|
||||
$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- ensure-default-admin
|
||||
New password for default administrator (user-xxxxx):
|
||||
<new_password>
|
||||
```
|
||||
### 如何启用调试日志记录?
|
||||
|
||||
请参阅[故障排除:日志记录](../troubleshooting/other-troubleshooting-tips/logging.md)。
|
||||
|
||||
### 我的 ClusterIP 不响应 ping,该如何解决?
|
||||
|
||||
ClusterIP 是一个虚拟 IP,不会响应 ping。要测试 ClusterIP 是否配置正确,最好的方法是使用 `curl` 访问 IP 和端口并检查它是否响应。
|
||||
|
||||
### 在哪里管理节点模板?
|
||||
|
||||
打开你的账号菜单(右上角)并选择`节点模板`。
|
||||
|
||||
### 为什么我的四层负载均衡器处于 `Pending` 状态?
|
||||
|
||||
四层负载均衡器创建为 `type: LoadBalancer`。Kubernetes 需要一个可以满足这些请求的云提供商或控制器,否则这些请求将永远处于 `Pending` 状态。有关更多信息,请参阅[云提供商](../pages-for-subheaders/set-up-cloud-providers.md)或[创建外部负载均衡器](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)。
|
||||
|
||||
### Rancher 的状态存储在哪里?
|
||||
|
||||
- Docker 安装:在 `rancher/rancher` 容器的嵌入式 etcd 中,位于 `/var/lib/rancher`。
|
||||
- Kubernetes install:在为运行 Rancher 而创建的 RKE 集群的 etcd 中。
|
||||
|
||||
### 支持的 Docker 版本是如何确定的?
|
||||
|
||||
我们遵循上游 Kubernetes 版本验证过的 Docker 版本。如果需要获取验证过的版本,请查看 Kubernetes 版本 CHANGELOG.md 中的 [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies)。
|
||||
|
||||
### 如何访问 Rancher 创建的节点?
|
||||
|
||||
你可以转到**节点**视图,然后下载用于访问 Rancher 创建的节点的 SSH 密钥。选择要访问的节点并单击行尾 **⋮** 按钮,然后选择**下载密钥**,如下图所示。
|
||||
|
||||

|
||||
|
||||
解压缩下载的 zip 文件,并使用 `id_rsa` 文件连接到你的主机。请务必使用正确的用户名(如果是 RancherOS,则使用 `rancher` 或 `docker`;如果是 Ubuntu,则使用 `ubuntu`;如果是 Amazon Linux,则使用 `ec2-user`)。
|
||||
|
||||
```
|
||||
$ ssh -i id_rsa user@ip_of_node
|
||||
```
|
||||
|
||||
### 如何在 Rancher 中自动化任务 X?
|
||||
|
||||
UI 由静态文件组成,并根据 API 的响应工作。换言之,UI 中可以执行的每个操作/任务都可以通过 API 进行自动化。有两种方法可以实现这一点:
|
||||
|
||||
* 访问 `https://your_rancher_ip/v3` 并浏览 API 选项。
|
||||
* 在使用 UI 时捕获 API 调用(通常使用 [Chrome 开发者工具](https://developers.google.com/web/tools/chrome-devtools/#network),但你也可以使用其他工具)。
|
||||
|
||||
### 节点的 IP 地址改变了,该如何恢复?
|
||||
|
||||
节点需要配置静态 IP(或使用 DHCP 保留的 IP)。如果节点的 IP 已更改,你必须在集群中删除并重新添加它。删除后,Rancher 会将集群更新为正确的状态。如果集群不再处于 `Provisioning` 状态,则已从集群删除该节点。
|
||||
|
||||
节点的 IP 地址发生变化时,Rancher 会失去与节点的连接,因此无法正常清理节点。请参阅[清理集群节点](../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md)来清理节点。
|
||||
|
||||
在集群中移除并清理节点时,你可以将节点重新添加到集群中。
|
||||
|
||||
### 如何将其他参数/绑定/环境变量添加到 Rancher 启动的 Kubernetes 集群的 Kubernetes 组件中?
|
||||
|
||||
你可以使用集群选项中的[配置文件](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-集群配置文件参考)选项来添加其他参数/绑定/环境变量。有关详细信息,请参阅 RKE 文档中的[其他参数、绑定和环境变量](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/),或浏览 [Cluster.ymls 示例](https://rancher.com/docs/rke/latest/en/example-yamls/)。
|
||||
|
||||
### 如何检查证书链是否有效?
|
||||
|
||||
使用 `openssl verify` 命令来验证你的证书链:
|
||||
|
||||
:::tip
|
||||
|
||||
将 `SSL_CERT_DIR` 和 `SSL_CERT_FILE` 配置到虚拟位置,从而确保在手动验证时不使用操作系统安装的证书。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
SSL_CERT_DIR=/dummy SSL_CERT_FILE=/dummy openssl verify -CAfile ca.pem rancher.yourdomain.com.pem
|
||||
rancher.yourdomain.com.pem: OK
|
||||
```
|
||||
|
||||
如果你看到 `unable to get local issuer certificate` 错误,则表示链不完整。通常情况下,这表示你的服务器证书由中间 CA 颁发。如果你已经拥有此证书,你可以在证书的验证中使用它,如下所示:
|
||||
|
||||
```
|
||||
SSL_CERT_DIR=/dummy SSL_CERT_FILE=/dummy openssl verify -CAfile ca.pem -untrusted intermediate.pem rancher.yourdomain.com.pem
|
||||
rancher.yourdomain.com.pem: OK
|
||||
```
|
||||
|
||||
如果你已成功验证证书链,你需要在服务器证书中包含所需的中间 CA 证书,从而完成与 Rancher 连接的证书链(例如,使用 Rancher Agent)。服务器证书文件中证书的顺序首先是服务器证书本身(`rancher.yourdomain.com.pem` 的内容),然后是中间 CA 证书(`intermediate.pem` 的内容):
|
||||
|
||||
```
|
||||
-----BEGIN CERTIFICATE-----
|
||||
%YOUR_CERTIFICATE%
|
||||
-----END CERTIFICATE-----
|
||||
-----BEGIN CERTIFICATE-----
|
||||
%YOUR_INTERMEDIATE_CERTIFICATE%
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
如果在验证过程中仍然出现错误,你可以运行以下命令,检索服务器证书的主题和颁发者:
|
||||
|
||||
```
|
||||
openssl x509 -noout -subject -issuer -in rancher.yourdomain.com.pem
|
||||
subject= /C=GB/ST=England/O=Alice Ltd/CN=rancher.yourdomain.com
|
||||
issuer= /C=GB/ST=England/O=Alice Ltd/CN=Alice Intermediate CA
|
||||
```
|
||||
|
||||
### 如何在服务器证书中检查 `Common Name` 和 `Subject Alternative Names`?
|
||||
|
||||
虽然技术上仅需要 `Subject Alternative Names` 中有一个条目,但在 `Common Name` 和 `Subject Alternative Names` 中都包含主机名可以最大程度地提高与旧版浏览器/应用程序的兼容性。
|
||||
|
||||
检查 `Common Name`:
|
||||
|
||||
```
|
||||
openssl x509 -noout -subject -in cert.pem
|
||||
subject= /CN=rancher.my.org
|
||||
```
|
||||
|
||||
检查 `Subject Alternative Names`:
|
||||
|
||||
```
|
||||
openssl x509 -noout -in cert.pem -text | grep DNS
|
||||
DNS:rancher.my.org
|
||||
```
|
||||
|
||||
### 为什么节点发生故障时重新调度一个 pod 需要 5 分钟以上的时间?
|
||||
|
||||
这是以下默认 Kubernetes 设置的组合导致的:
|
||||
|
||||
* kubelet
|
||||
* `node-status-update-frequency`:指定 kubelet 将节点状态发布到 master 的频率(默认 10s)。
|
||||
* kube-controller-manager
|
||||
* `node-monitor-period`:在 NodeController 中同步 NodeStatus 的周期(默认 5s)。
|
||||
* `node-monitor-grace-period`:在将节点标记为不健康之前,允许节点无响应的时间长度(默认 40s)。
|
||||
* `pod-eviction-timeout`:在故障节点上删除 pod 的宽限期(默认 5m0s)。
|
||||
|
||||
有关这些设置的更多信息,请参阅 [Kubernetes:kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 和 [Kubernetes:kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/)。
|
||||
|
||||
Kubernetes 1.13 默认启用 `TaintBasedEvictions` 功能。有关详细信息,请参阅 [Kubernetes:基于污点的驱逐](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint-based-evictions)。
|
||||
|
||||
* kube-apiserver(Kubernetes 1.13 及更高版本)
|
||||
* `default-not-ready-toleration-seconds`:表示 `notReady:NoExecute` 的容忍度的 `tolerationSeconds`,该设置默认添加到还没有该容忍度的 pod。
|
||||
* `default-unreachable-toleration-seconds`:表示 `unreachable:NoExecute` 的容忍度的 `tolerationSeconds`,该设置默认添加到还没有该容忍度的 pod。
|
||||
|
||||
### 我可以在 UI 中使用键盘快捷键吗?
|
||||
|
||||
是的,你可以使用键盘快捷键访问 UI 的大部分内容。要查看快捷方式的概览,请在 UI 任意位置按 `?`。
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: 遥测
|
||||
---
|
||||
|
||||
### 什么是遥测?
|
||||
|
||||
遥测(Telemetry)收集 Rancher 安装大小、使用的组件版本以及使用功能的汇总信息。Rancher Labs 会使用此信息来改进产品,我们不会与第三方共享此信息。
|
||||
|
||||
### 收集什么信息?
|
||||
|
||||
我们不会收集任何识别信息(如用户名、密码或用户资源的名称或地址)。
|
||||
|
||||
收集的主要内容包括:
|
||||
|
||||
- 每个集群的节点总数(最小、平均、最大、总数)及其大小(例如 CPU 核心数和 RAM)。
|
||||
- 集群、项目、命名空间和 Pod 等逻辑资源的聚合计数。
|
||||
- 用于部署集群和节点的驱动程序计数(例如 GKE、EC2、导入与自定义)。
|
||||
- 部署在节点上的 Kubernetes 组件、操作系统和 Docker 的版本。
|
||||
- 是否启用了某些可选组件(例如,使用了哪些身份验证提供程序)。
|
||||
- 运行的 Rancher 的镜像名称和版本。
|
||||
- 此安装的唯一随机标识符。
|
||||
|
||||
### 我可以看到发送的信息吗?
|
||||
|
||||
如果启用了遥测,你可以转到 `https://<your rancher server>/v1-telemetry` 查看当前数据。
|
||||
|
||||
如果未启用遥测,则收集数据的进程未运行,因此没有可供查看的内容。
|
||||
|
||||
### 如何打开或关闭它?
|
||||
|
||||
完成初始设置后,管理员可以转到 UI `全局`中的`设置`页面,单击**编辑**,然后将 `telemetry-opt` 更改为 `in` 或 `out`。
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
title: 在离线环境中渲染 Helm 模板
|
||||
---
|
||||
|
||||
:::note
|
||||
|
||||
以下说明假设你已经按照[本页](upgrades.md)的 Kubernetes 升级说明操作(包括先决条件)到步骤 3:升级 Rancher。
|
||||
|
||||
:::
|
||||
|
||||
### Rancher Helm 模板选项
|
||||
|
||||
使用安装 Rancher 时选择的选项来渲染 Rancher 模板。参考下表来替换每个占位符。Rancher 需要配置为使用私有镜像仓库,以便配置所有 Rancher 启动的 Kubernetes 集群或 Rancher 工具。
|
||||
|
||||
根据你在安装过程中做出的选择,完成以下步骤之一。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
------------|-------------
|
||||
| `<VERSION>` | 输出压缩包的版本号。 |
|
||||
| `<RANCHER.YOURDOMAIN.COM>` | 指向负载均衡器的 DNS 名称。 |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 你的私有镜像仓库的 DNS 名称。 |
|
||||
| `<CERTMANAGER_VERSION>` | 在 K8s 集群上运行的 cert-manager 版本。 |
|
||||
|
||||
|
||||
### 选项 A:使用默认的自签名证书
|
||||
|
||||
```
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--no-hooks \ # prevent files for Helm hooks from being generated
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set certmanager.version=<CERTMANAGER_VERSION> \
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
### 选项 B:使用 Kubernetes 密文从文件中获取证书
|
||||
|
||||
```plain
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--no-hooks \ # prevent files for Helm hooks from being generated
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
--set ingress.tls.source=secret \
|
||||
--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
如果你使用的是私有 CA 签名的证书,请在 `--set ingress.tls.source=secret` 后加上 `--set privateCA=true`:
|
||||
|
||||
```plain
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--no-hooks \ # prevent files for Helm hooks from being generated
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
--set ingress.tls.source=secret \
|
||||
--set privateCA=true \
|
||||
--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
### 应用已渲染的模板
|
||||
|
||||
将渲染的 manifest 目录复制到可以访问 Rancher Server 集群的系统中,并应用渲染的模板。
|
||||
|
||||
使用 `kubectl` 来应用渲染的 manifest。
|
||||
|
||||
```plain
|
||||
kubectl -n cattle-system apply -R -f ./rancher
|
||||
```
|
||||
|
||||
## 验证升级
|
||||
|
||||
登录 Rancher 以确认升级成功。
|
||||
|
||||
:::tip
|
||||
|
||||
升级后出现网络问题?
|
||||
|
||||
请参见[恢复集群网络](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 已知升级问题
|
||||
|
||||
你可以在 [GitHub](https://github.com/rancher/rancher/releases) 发布说明以及 [Rancher 论坛](https://forums.rancher.com/c/announcements/12)中找到每个 Rancher 版本的已知问题。
|
||||
@@ -0,0 +1,147 @@
|
||||
---
|
||||
title: 在 Azure Kubernetes Service 上安装 Rancher
|
||||
---
|
||||
|
||||
本文介绍了如何在微软的 Azure Kubernetes Service (AKS) 上安装 Rancher。
|
||||
|
||||
本指南使用命令行工具来配置一个带有 Ingress 的 AKS 集群。如果你更喜欢使用 Azure 门户来配置集群,请参见[官方文档](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal)。
|
||||
|
||||
如果你已有一个 AKS Kubernetes 集群,请直接跳到[安装 Ingress](#5-安装-ingress) 的步骤,然后按照[此页](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。
|
||||
|
||||
## 先决条件
|
||||
|
||||
:::caution
|
||||
|
||||
部署到 Microsoft Azure 会产生费用。
|
||||
|
||||
:::
|
||||
|
||||
- [Microsoft Azure 账号](https://azure.microsoft.com/en-us/free/):用于创建部署 Rancher 和 Kubernetes 的资源。
|
||||
- [Microsoft Azure 订阅](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal):如果你没有的话,请访问此链接查看如何创建 Microsoft Azure 订阅。
|
||||
- [Micsoroft Azure 租户](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant):访问此链接并参考教程以创建 Microsoft Azure 租户。
|
||||
- 你的订阅有足够的配额,至少有 2 个 vCPU。有关 Rancher Server 资源要求的详情,请参见[此节](../../../pages-for-subheaders/installation-requirements.md#rke-和托管-kubernetes)。
|
||||
- 在 Azure 中用 Helm 安装 Rancher 时,请使用 L7 负载均衡器来避免网络问题。详情请参见 [Azure 负载均衡器限制](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations)。
|
||||
|
||||
## 1. 准备你的工作站
|
||||
|
||||
在工作站上安装以下命令行工具:
|
||||
|
||||
- **az**,Azure CLI:如需获得帮助,请参见[安装步骤](https://docs.microsoft.com/en-us/cli/azure/)。
|
||||
- **kubectl**:如需获得帮助,请参见[安装步骤](https://kubernetes.io/docs/tasks/tools/#kubectl)。
|
||||
- **helm**:如需获取帮助,请参见[安装步骤](https://helm.sh/docs/intro/install/)。
|
||||
|
||||
## 2. 创建资源组
|
||||
|
||||
安装 CLI 后,你需要用你的 Azure 账户登录:
|
||||
|
||||
```
|
||||
az login
|
||||
```
|
||||
|
||||
创建一个 [资源组](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal) 来保存集群的所有相关资源。使用一个适用于你实际情况的位置:
|
||||
|
||||
```
|
||||
az group create --name rancher-rg --location eastus
|
||||
```
|
||||
|
||||
## 3. 创建 AKS 集群
|
||||
|
||||
运行以下命令创建一个 AKS 集群。选择适用于你实际情况的虚拟机大小。如需获得可用的大小和选项,请参见[此处](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes)。在选择 Kubernetes 版本时,请务必先查阅[支持矩阵](https://rancher.com/support-matrix/),以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
|
||||
|
||||
:::note
|
||||
|
||||
如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本,你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
az aks create \
|
||||
--resource-group rancher-rg \
|
||||
--name rancher-server \
|
||||
--kubernetes-version <VERSION> \
|
||||
--node-count 3 \
|
||||
--node-vm-size Standard_D2_v3
|
||||
```
|
||||
|
||||
集群部署需要一些时间才能完成。
|
||||
|
||||
## 4. 获取访问凭证
|
||||
|
||||
集群部署完成后,获取访问凭证。
|
||||
|
||||
```
|
||||
az aks get-credentials --resource-group rancher-rg --name rancher-server
|
||||
```
|
||||
|
||||
此命令把集群的凭证合并到现有的 kubeconfig 中,并允许 `kubectl` 与集群交互。
|
||||
|
||||
## 5. 安装 Ingress
|
||||
|
||||
集群需要一个 Ingress,以从集群外部访问 Rancher。要 Ingress,你需要分配一个公共 IP 地址。请确保你有足够的配额,否则它将无法分配 IP 地址。公共 IP 地址的限制在每个订阅的区域级别生效。
|
||||
|
||||
为确保你选择了正确的 Ingress-NGINX Helm Chart,首先在 [Kubernetes/ingress-nginx 支持表](https://github.com/kubernetes/ingress-nginx#supported-versions-table)中找到与你的 Kubernetes 版本兼容的 `Ingress-NGINX 版本`。
|
||||
|
||||
然后,运行以下命令列出可用的 Helm Chart:
|
||||
|
||||
```
|
||||
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
|
||||
helm repo update
|
||||
helm search repo ingress-nginx -l
|
||||
```
|
||||
|
||||
`helm search` 命令的输出包含一个 `APP VERSION` 列。此列下的版本等同于你之前选择的 `Ingress-NGINX 版本`。使用应用程序版本,选择一个 Chart 版本,该版本打包了与你的 Kubernetes 兼容的应用程序。例如,如果使用的是 Kubernetes v1.24,则可以选择 v4.6.0 Helm Chart,因为 Ingress-NGINX v1.7.0 与该 Chart 打包在一起,而 v1.7.0 与 Kubernetes v1.24 兼容。如有疑问,请选择最新的兼容版本。
|
||||
|
||||
了解你需要的 Helm chart `版本`后,运行以下命令。它安装一个带有 Kubernetes 负载均衡器服务的 `nginx-ingress-controller`:
|
||||
|
||||
```
|
||||
helm search repo ingress-nginx -l
|
||||
helm upgrade --install \
|
||||
ingress-nginx ingress-nginx/ingress-nginx \
|
||||
--namespace ingress-nginx \
|
||||
--set controller.service.type=LoadBalancer \
|
||||
--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
|
||||
--set controller.service.externalTrafficPolicy=Local \
|
||||
--version 4.6.0 \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
## 6. 获取负载均衡器的 IP
|
||||
|
||||
运行以下命令获取负载均衡器的 IP 地址:
|
||||
|
||||
```
|
||||
kubectl get service ingress-nginx-controller --namespace=ingress-nginx
|
||||
```
|
||||
|
||||
返回的结果应与以下内容类似:
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
|
||||
AGE
|
||||
ingress-nginx-controller LoadBalancer 10.0.116.18 40.31.180.83 80:31229/TCP,443:31050/TCP
|
||||
67s
|
||||
```
|
||||
|
||||
保存 `EXTERNAL-IP`。
|
||||
|
||||
## 7. 设置 DNS
|
||||
|
||||
到 Rancher Server 的外部流量需要重定向到你创建的负载均衡器。
|
||||
|
||||
创建指向你保存的 `EXTERNAL-IP` 的 DNS。这个 DNS 会用作 Rancher Server 的 URL。
|
||||
|
||||
设置 DNS 的有效方法有很多。如需获取帮助,请参见 [Azure DNS 文档中心](https://docs.microsoft.com/en-us/azure/dns/)。
|
||||
|
||||
## 8. 安装 Rancher Helm Chart
|
||||
|
||||
按照[本页](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。任何 Kubernetes 发行版上安装的 Rancher 的 Helm 说明都是一样的。
|
||||
|
||||
安装 Rancher 时,使用上一步获取的 DNS 名称作为 Rancher Server 的 URL。它可以作为 Helm 选项传递进来。例如,如果 DNS 名称是 `rancher.my.org`,你需要使用 `--set hostname=rancher.my.org` 选项来运行 Helm 安装命令。
|
||||
|
||||
在此设置之上安装 Rancher 时,你还需要将以下值传递到 Rancher Helm 安装命令,以设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称:
|
||||
|
||||
```
|
||||
--set ingress.ingressClassName=nginx
|
||||
```
|
||||
|
||||
请参阅[Helm 安装命令](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
|
||||
@@ -0,0 +1,151 @@
|
||||
---
|
||||
title: 在 Amazon EKS 上安装 Rancher
|
||||
---
|
||||
|
||||
本文介绍了如何在 Amazon EKS 集群上安装 Rancher。你也可以[通过 AWS Marketplace 安装 Rancher](../../quick-start-guides/deploy-rancher-manager/aws-marketplace.md)。
|
||||
|
||||
如果你已经有一个 EKS Kubernetes 集群,请直接跳转到[安装 Ingress](#5-安装-ingress)这个步骤。然后按照[此处](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的步骤安装 Rancher Helm Chart。
|
||||
|
||||
## 为 Rancher Server 创建 EKS 集群
|
||||
|
||||
在本节中,你将使用命令行工具安装一个带有 Ingress 的 EKS 集群。如果你想在 EKS 上使用 Rancher 时使用较少的资源,请使用此方法。
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
- 已有一个 AWS 账户。
|
||||
- 建议使用 IAM 用户而不是 AWS 根账户。你将需要 IAM 用户的访问密钥 (access key) 和密文秘钥 (secret key) 来配置 AWS 命令行界面。
|
||||
- IAM 用户需要具备[eksctl 文档](https://eksctl.io/usage/minimum-iam-policies/)中描述的最低 IAM 策略。
|
||||
|
||||
:::
|
||||
|
||||
### 1. 准备你的工作站
|
||||
|
||||
在工作站上安装以下命令行工具:
|
||||
|
||||
- **AWS CLI v2**:如需获取帮助,请参见[安装步骤](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)。
|
||||
- **eksctl**:如需获取帮助,请参见[安装步骤](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html)。
|
||||
- **kubectl**:如需获得帮助,请参见[安装步骤](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)。
|
||||
- **helm**:如需获取帮助,请参见[安装步骤](https://helm.sh/docs/intro/install/)。
|
||||
|
||||
### 2. 配置 AWS CLI
|
||||
|
||||
运行以下命令,配置 AWS CLI:
|
||||
|
||||
```
|
||||
aws configure
|
||||
```
|
||||
|
||||
输入以下参数:
|
||||
|
||||
| 值 | 描述 |
|
||||
|-------|-------------|
|
||||
| AWS Access Key ID | 具有 EKS 权限的 IAM 用户的访问密钥凭证。 |
|
||||
| AWS Secret Access Key | 具有 EKS 权限的 IAM 用户的密文密钥凭证。 |
|
||||
| Default region name | 集群节点所在的 [AWS 区域](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html#Concepts.RegionsAndAvailabilityZones.Regions)。 |
|
||||
| Default output format | 输入 `json`。 |
|
||||
|
||||
### 3. 创建 EKS 集群
|
||||
|
||||
运行以下命令创建一个 EKS 集群。使用适用于你的用例的 AWS 区域。在选择 Kubernetes 版本时,请务必先查阅[支持矩阵](https://rancher.com/support-matrix/),以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
|
||||
|
||||
**注意**:如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本,你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
|
||||
|
||||
```
|
||||
eksctl create cluster \
|
||||
--name rancher-server \
|
||||
--version <VERSION> \
|
||||
--region us-west-2 \
|
||||
--nodegroup-name ranchernodes \
|
||||
--nodes 3 \
|
||||
--nodes-min 1 \
|
||||
--nodes-max 4 \
|
||||
--managed
|
||||
```
|
||||
|
||||
使用 CloudFormation 进行的集群部署可能需要一些时间才能完成。
|
||||
|
||||
### 4. 测试集群
|
||||
|
||||
运行以下命令测试集群:
|
||||
|
||||
```
|
||||
eksctl get cluster
|
||||
```
|
||||
|
||||
返回的结果应与以下内容类似:
|
||||
|
||||
```
|
||||
eksctl get cluster
|
||||
2021-03-18 15:09:35 [ℹ] eksctl version 0.40.0
|
||||
2021-03-18 15:09:35 [ℹ] using region us-west-2
|
||||
NAME REGION EKSCTL CREATED
|
||||
rancher-server-cluster us-west-2 True
|
||||
```
|
||||
|
||||
### 5. 安装 Ingress
|
||||
|
||||
集群需要一个 Ingress,以从集群外部访问 Rancher。
|
||||
|
||||
为确保你选择了正确的 Ingress-NGINX Helm Chart,首先在 [Kubernetes/ingress-nginx 支持表](https://github.com/kubernetes/ingress-nginx#supported-versions-table)中找到与你的 Kubernetes 版本兼容的 `Ingress-NGINX 版本`。
|
||||
|
||||
然后,运行以下命令列出可用的 Helm Chart:
|
||||
|
||||
```
|
||||
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
|
||||
helm repo update
|
||||
helm search repo ingress-nginx -l
|
||||
```
|
||||
|
||||
`helm search` 命令的输出包含一个 `APP VERSION` 列。此列下的版本等同于你之前选择的 `Ingress-NGINX 版本`。使用应用程序版本,选择一个 Chart 版本,该版本打包了与你的 Kubernetes 兼容的应用程序。例如,如果使用的是 Kubernetes v1.23,则可以选择 v4.6.0 Helm Chart,因为 Ingress-NGINX v1.7.0 与该 Chart 打包在一起,而 v1.7.0 与 Kubernetes v1.23 兼容。如有疑问,请选择最新的兼容版本。
|
||||
|
||||
了解你需要的 Helm chart `版本`后,运行以下命令。它安装一个带有 Kubernetes 负载均衡器服务的 `nginx-ingress-controller`:
|
||||
|
||||
```
|
||||
helm upgrade --install \
|
||||
ingress-nginx ingress-nginx/ingress-nginx \
|
||||
--namespace ingress-nginx \
|
||||
--set controller.service.type=LoadBalancer \
|
||||
--version 4.6.0 \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
### 6. 获取负载均衡器的 IP
|
||||
|
||||
运行以下命令获取负载均衡器的 IP 地址:
|
||||
|
||||
```
|
||||
kubectl get service ingress-nginx-controller --namespace=ingress-nginx
|
||||
```
|
||||
|
||||
返回的结果应与以下内容类似:
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
|
||||
AGE
|
||||
ingress-nginx-controller LoadBalancer 10.100.90.18 a904a952c73bf4f668a17c46ac7c56ab-962521486.us-west-2.elb.amazonaws.com 80:31229/TCP,443:31050/TCP
|
||||
27m
|
||||
```
|
||||
|
||||
保存 `EXTERNAL-IP`。
|
||||
|
||||
### 7. 设置 DNS
|
||||
|
||||
到 Rancher Server 的外部流量需要重定向到你创建的负载均衡器。
|
||||
|
||||
创建指向你保存的外部 IP 地址的 DNS。这个 DNS 会用作 Rancher Server 的 URL。
|
||||
|
||||
设置 DNS 的有效方法有很多。如需获得帮助,请参见 AWS 文档中心的[转发流量到 ELB 负载均衡器](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html)。
|
||||
|
||||
### 8. 安装 Rancher Helm Chart
|
||||
|
||||
按照[本页](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。任何 Kubernetes 发行版上安装的 Rancher 的 Helm 说明都是一样的。
|
||||
|
||||
安装 Rancher 时,使用上一步获取的 DNS 名称作为 Rancher Server 的 URL。它可以作为 Helm 选项传递进来。例如,如果 DNS 名称是 `rancher.my.org`,你需要使用 `--set hostname=rancher.my.org` 选项来运行 Helm 安装命令。
|
||||
|
||||
在此设置之上安装 Rancher 时,你还需要将以下值传递到 Rancher Helm 安装命令,以设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称:
|
||||
|
||||
```
|
||||
--set ingress.ingressClassName=nginx
|
||||
```
|
||||
|
||||
请参阅[Helm 安装命令](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
|
||||
@@ -0,0 +1,201 @@
|
||||
---
|
||||
title: 在 GKE 集群上安装 Rancher
|
||||
---
|
||||
|
||||
在本节中,你将学习如何使用 GKE 安装 Rancher。
|
||||
|
||||
如果你已经有一个 GKE Kubernetes 集群,请直接跳转到[安装 Ingress](#7-安装-ingress)这个步骤。然后按照[此处](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的步骤安装 Rancher Helm Chart。
|
||||
|
||||
## 先决条件
|
||||
|
||||
- 你需要有一个 Google 账号。
|
||||
- 你需要有一个 Google Cloud Billing 账号。你可使用 Google Cloud Console 来管理你的 Cloud Billing 账号。有关 Cloud Console 的详情,请参见 [ Console 通用指南](https://support.google.com/cloud/answer/3465889?hl=en&ref_topic=3340599)。
|
||||
- 你需要至少一个在用的 IP 地址和至少 2 个 CPU 的云配额。有关 Rancher Server 的硬件要求,请参见[本节](../../../pages-for-subheaders/installation-requirements.md#rke-和托管-kubernetes)。
|
||||
|
||||
## 1. 启用 Kubernetes Engine API
|
||||
|
||||
按照以下步骤启用 Kubernetes Engine API:
|
||||
|
||||
1. 访问 Google Cloud Console 中的 [Kubernetes Engine 页面](https://console.cloud.google.com/projectselector/kubernetes?_ga=2.169595943.767329331.1617810440-856599067.1617343886)。
|
||||
1. 创建或选择一个项目。
|
||||
1. 打开项目,并为项目启用 Kubernetes Engine API。等待 API 和相关服务的启用。这可能需要几分钟时间。
|
||||
1. 确保为你的云项目启用了计费。有关如何为你的项目启用计费,请参见 [Google Cloud 文档中心](https://cloud.google.com/billing/docs/how-to/modify-project#enable_billing_for_a_project)。
|
||||
|
||||
## 2. 打开 Cloud Shell
|
||||
|
||||
Cloud Shell 是一个 shell 环境,用于管理托管在 Google Cloud 上的资源。Cloud Shell 预装了 `gcloud` 命令行工具和 kubectl 命令行工具中。`gcloud` 工具为 Google Cloud 提供主要的命令行界面,而`kubectl` 则提供针对 Kubernetes 集群的主要命令行界面。
|
||||
|
||||
下文描述了如何从 Google Cloud Console 或从本地工作站启动 Cloud Shell。
|
||||
|
||||
### Cloud Shell
|
||||
|
||||
如需从 [Google Cloud Console](https://console.cloud.google.com) 启动 shell,请在控制台的右上角点击终端按钮。鼠标悬停在按钮上时,它会标记为 **Activate Cloud Shell**。
|
||||
|
||||
### 本地 Shell
|
||||
|
||||
执行以下步骤以安装 `gcloud` 和 `kubectl`:
|
||||
|
||||
1. 按照[这些步骤](https://cloud.google.com/sdk/docs/install)安装 Cloud SDK。The Cloud SDK 包括 `gcloud` 命令行工具。不同操作系统对应的步骤有所不同。
|
||||
1. 安装 Cloud SDK 后,运行以下命令以安装 `kubectl` 命令行工具:
|
||||
|
||||
```
|
||||
gcloud components install kubectl
|
||||
```
|
||||
后面的步骤会配置 `kubectl`,使其用于使用新的 GKE 集群。
|
||||
1. 如果 Helm 3 未安装的话,[安装 Helm 3](https://helm.sh/docs/intro/install/)。
|
||||
1. 使用 `HELM_EXPERIMENTAL_OCI` 变量来启用 Helm 的实验功能 [OCI 镜像支持](https://github.com/helm/community/blob/master/hips/hip-0006.md)。把以下行添加到 `~/.bashrc` (或 macOS 中的 `~/.bash_profile`,或者你的 shell 存储环境变量的地方):
|
||||
|
||||
```
|
||||
export HELM_EXPERIMENTAL_OCI=1
|
||||
```
|
||||
1. 运行以下命令来加载你更新的 `.bashrc` 文件:
|
||||
|
||||
```
|
||||
source ~/.bashrc
|
||||
```
|
||||
如果你运行的是 macOS,使用这个命令:
|
||||
```
|
||||
source ~/.bash_profile
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 3. 配置 gcloud CLI
|
||||
|
||||
选择以下方法之一配置默认的 gcloud 设置:
|
||||
|
||||
- 如果你想了解默认值,请使用 gcloud init。
|
||||
- 如需单独设置你的项目 ID、地区和区域,使用 gcloud config。
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="使用 gcloud init">
|
||||
|
||||
1. 运行 gcloud init 并按照指示操作:
|
||||
|
||||
```
|
||||
gcloud init
|
||||
```
|
||||
如果你在远程服务器上使用 SSH,使用 --console-only 标志,以防止该命令启动浏览器。
|
||||
|
||||
```
|
||||
gcloud init --console-only
|
||||
```
|
||||
2. 按照指示,以授权 gcloud 使用你的 Google Cloud 账户,并选择你创建的新项目。
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="使用 gcloud config">
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 4. 确认 gcloud 的配置是否正确
|
||||
|
||||
运行:
|
||||
|
||||
```
|
||||
gcloud config list
|
||||
```
|
||||
|
||||
返回的结果应与以下内容类似:
|
||||
|
||||
```
|
||||
[compute]
|
||||
region = us-west1 # Your chosen region
|
||||
zone = us-west1-b # Your chosen zone
|
||||
[core]
|
||||
account = <Your email>
|
||||
disable_usage_reporting = True
|
||||
project = <Your project ID>
|
||||
|
||||
Your active configuration is: [default]
|
||||
```
|
||||
|
||||
## 5. 创建一个 GKE 集群
|
||||
|
||||
下面的命令创建了一个三节点的集群。
|
||||
|
||||
把 `cluster-name` 替换为你新集群的名称。
|
||||
|
||||
在选择 Kubernetes 版本时,请务必先查阅[支持矩阵](https://rancher.com/support-matrix/),以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
|
||||
|
||||
要使用 Rancher 成功创建 GKE 集群,GKE 必须处于 Standard 模式。GKE 在创建 Kubernetes 集群时有两种运行模式,分别是 Autopilot 和 Standard 模式。Autopilot 模式的集群配置对编辑 kube-system 命名空间有限制。但是,Rancher 在安装时需要在 kube-system 命名空间中创建资源。因此,你将无法在以 Autopilot 模式创建的 GKE 集群上安装 Rancher。如需详细了解 GKE Autopilot 模式和 Standard 模式之间的差异,请访问[比较 GKE Autopilot 和 Standard ](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison)。
|
||||
|
||||
**注意**:如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本,你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
|
||||
|
||||
```
|
||||
gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=<VERSION>
|
||||
```
|
||||
|
||||
## 6. 获取验证凭证
|
||||
|
||||
创建集群后,你需要获得认证凭证才能与集群交互:
|
||||
|
||||
```
|
||||
gcloud container clusters get-credentials cluster-name
|
||||
```
|
||||
|
||||
此命令将 `kubectl` 配置成使用你创建的集群。
|
||||
|
||||
## 7. 安装 Ingress
|
||||
|
||||
集群需要一个 Ingress,以从集群外部访问 Rancher。
|
||||
|
||||
以下命令安装带有 LoadBalancer 服务的 `nginx-ingress-controller`:
|
||||
|
||||
```
|
||||
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
|
||||
helm repo update
|
||||
helm upgrade --install \
|
||||
ingress-nginx ingress-nginx/ingress-nginx \
|
||||
--namespace ingress-nginx \
|
||||
--set controller.service.type=LoadBalancer \
|
||||
--version 4.0.18 \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
## 8. 获取负载均衡器的 IP
|
||||
|
||||
运行以下命令获取负载均衡器的 IP 地址:
|
||||
|
||||
```
|
||||
kubectl get service ingress-nginx-controller --namespace=ingress-nginx
|
||||
```
|
||||
|
||||
返回的结果应与以下内容类似:
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
ingress-nginx-controller LoadBalancer 10.3.244.156 35.233.206.34 80:31876/TCP,443:32497/TCP 81s
|
||||
```
|
||||
|
||||
保存 `EXTERNAL-IP`。
|
||||
|
||||
## 9. 设置 DNS
|
||||
|
||||
到 Rancher Server 的外部流量需要重定向到你创建的负载均衡器。
|
||||
|
||||
创建指向你保存的外部 IP 地址的 DNS。这个 DNS 会用作 Rancher Server 的 URL。
|
||||
|
||||
设置 DNS 的有效方法有很多。如需获取帮助,请参见 Google Cloud 文档中的[管理 DNS 记录](https://cloud.google.com/dns/docs/records)部分。
|
||||
|
||||
## 10. 安装 Rancher Helm Chart
|
||||
|
||||
按照[本页](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。任何 Kubernetes 发行版上安装的 Rancher 的 Helm 说明都是一样的。
|
||||
|
||||
安装 Rancher 时,使用上一步获取的 DNS 名称作为 Rancher Server 的 URL。它可以作为 Helm 选项传递进来。例如,如果 DNS 名称是 `rancher.my.org`,你需要使用 `--set hostname=rancher.my.org` 选项来运行 Helm 安装命令。
|
||||
|
||||
在此设置之上安装 Rancher 时,你还需要设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称:
|
||||
|
||||
```
|
||||
--set ingress.ingressClassName=nginx
|
||||
```
|
||||
|
||||
请参阅[Helm 安装命令](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
|
||||
|
||||
在 Rancher v2.7.5 中,如果你打算在集群上使用默认的 GKE Ingress 而不启用 VPC 原生的集群模式,则需要设置以下标志:
|
||||
|
||||
```
|
||||
--set service.type=NodePort
|
||||
```
|
||||
|
||||
此设置是必要的,这考虑了与 ClusterIP(`cattle-system/rancher` 的默认类型)之间的兼容性问题。
|
||||
@@ -0,0 +1,37 @@
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: AdmissionConfiguration
|
||||
plugins:
|
||||
- configuration:
|
||||
apiVersion: pod-security.admission.config.k8s.io/v1
|
||||
defaults:
|
||||
audit: restricted
|
||||
audit-version: latest
|
||||
enforce: restricted
|
||||
enforce-version: latest
|
||||
warn: restricted
|
||||
warn-version: latest
|
||||
exemptions:
|
||||
namespaces:
|
||||
- ingress-nginx
|
||||
- kube-system
|
||||
- cattle-system
|
||||
- cattle-epinio-system
|
||||
- cattle-fleet-system
|
||||
- longhorn-system
|
||||
- cattle-neuvector-system
|
||||
- cattle-monitoring-system
|
||||
- rancher-alerting-drivers
|
||||
- cis-operator-system
|
||||
- cattle-csp-adapter-system
|
||||
- cattle-externalip-system
|
||||
- cattle-gatekeeper-system
|
||||
- istio-system
|
||||
- cattle-istio-system
|
||||
- cattle-logging-system
|
||||
- cattle-windows-gmsa-system
|
||||
- cattle-sriov-system
|
||||
- cattle-ui-plugin-system
|
||||
- tigera-operator
|
||||
kind: PodSecurityConfiguration
|
||||
name: PodSecurity
|
||||
path: ""
|
||||
@@ -0,0 +1,128 @@
|
||||
---
|
||||
title: 回滚
|
||||
---
|
||||
|
||||
## 使用 Rancher 2.6.4+ 进行回滚的其他步骤
|
||||
|
||||
Rancher v2.6.4 将 cluster-api 模块从 v0.4.4 升级到 v1.0.2。反过来,cluster-api 的 v1.0.2 版本将集群 API 的自定义资源定义 (CRD) 从 `cluster.x-k8s.io/v1alpha4` 升级到 `cluster.x-k8s.io/v1beta1`。当你尝试将 Rancher v2.6.4 回滚到以前版本的 Rancher v2.6.x 时,CRD 升级到 v1beta1 会导致回滚失败。这是因为使用旧 apiVersion (v1alpha4) 的 CRD 与 v1beta1 不兼容。
|
||||
|
||||
要避免回滚失败,你需要在尝试恢复操作或回滚**之前**运行以下 Rancher 脚本:
|
||||
|
||||
* `verify.sh`:检查集群中是否有任何与 Rancher 相关的资源。
|
||||
* `cleanup.sh`:清理集群。
|
||||
|
||||
有关详细信息和源代码,请参阅 [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanup)。
|
||||
|
||||
:::caution
|
||||
|
||||
`cleanup.sh` 运行的时候会有停机时间,这是因为脚本会删除 Rancher 创建的资源。
|
||||
|
||||
:::
|
||||
|
||||
### 从 v2.6.4+ 回滚到较低版本的 v2.6.x
|
||||
|
||||
1. 按照[说明](https://github.com/rancher/rancher-cleanup/blob/main/README.md)运行脚本。
|
||||
1. 按照[说明](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)在现有集群上安装 rancher-backup Helm Chart 并恢复之前的状态。
|
||||
1. 省略步骤 3。
|
||||
1. 执行到步骤 4 时,在要回滚到的 local 集群上安装 Rancher 2.6.x 版本。
|
||||
|
||||
## 回滚到 Rancher 2.5.0+
|
||||
|
||||
要回滚到 Rancher 2.5.0+,使用 **Rancher 备份**应用并通过备份来恢复 Rancher。
|
||||
|
||||
回滚后,Rancher 必须以较低/较早的版本启动。
|
||||
|
||||
还原是通过创建 Restore 自定义资源实现的。
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
* 请按照此页面上的说明在已备份的同一集群上还原 Rancher。要把 Rancher 迁移到新集群,请参照步骤[迁移 Rancher](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
|
||||
|
||||
* 在使用相同设置恢复 Rancher 时,Rancher deployment 在恢复开始前被手动缩减,然后 Operator 将在恢复完成后将其缩回。因此,在恢复完成之前,Rancher 和 UI 都将不可用。如果 UI 不可用时,你可使用 `kubectl create -f restore.yaml`YAML 恢复文件来使用初始的集群 kubeconfig。
|
||||
|
||||
:::
|
||||
|
||||
### 创建 Restore 自定义资源
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 找到你的本地集群,并点击 **Explore**。
|
||||
1. 在左侧导航栏中,点击 **Rancher 备份 > 还原**。
|
||||
:::note
|
||||
|
||||
如果 Rancher Backups 应用不可见,你需要到 **Apps** 的 Charts 页面中安装应用。详情请参见[此处](../../../pages-for-subheaders/helm-charts-in-rancher.md#charts)。
|
||||
|
||||
:::
|
||||
|
||||
1. 单击**创建**。
|
||||
1. 使用表单或 YAML 创建 Restore。如需获取使用表单创建 Restore 资源的更多信息,请参见[配置参考](../../../reference-guides/backup-restore-configuration/restore-configuration.md)和[示例](../../../reference-guides/backup-restore-configuration/examples.md)。
|
||||
1. 如需使用 YAML 编辑器,点击**创建 > 使用 YAML 文件创建**。然后输入 Restore YAML。以下是 Restore 自定义资源示例:
|
||||
|
||||
```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
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
storageLocation:
|
||||
s3:
|
||||
credentialSecretName: s3-creds
|
||||
credentialSecretNamespace: default
|
||||
bucketName: rancher-backups
|
||||
folder: rancher
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
```
|
||||
如需获得配置 Restore 的帮助,请参见[配置参考](../../../reference-guides/backup-restore-configuration/restore-configuration.md)和[示例](../../../reference-guides/backup-restore-configuration/examples.md)。
|
||||
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**:已创建备份文件并更新到目标存储位置。资源还原顺序如下:
|
||||
|
||||
1. 自定义资源定义(CRD)
|
||||
2. 集群范围资源
|
||||
3. 命名空间资源
|
||||
|
||||
如需查看还原的处理方式,请检查 Operator 的日志。按照如下步骤获取日志:
|
||||
|
||||
```yaml
|
||||
kubectl get pods -n cattle-resources-system
|
||||
kubectl logs -n cattle-resources-system -f
|
||||
```
|
||||
|
||||
### 回滚到上一个 Rancher 版本
|
||||
|
||||
你可以使用 Helm CLI 回滚 Rancher。要回滚到上一个版本:
|
||||
|
||||
```yaml
|
||||
helm rollback rancher -n cattle-system
|
||||
```
|
||||
|
||||
如果你不是想回滚到上一个版本,你也可以指定回滚的版本。查看部署历史记录:
|
||||
|
||||
```yaml
|
||||
helm history rancher -n cattle-system
|
||||
```
|
||||
|
||||
确定目标版本后,执行回滚。此示例回滚到版本 `3`:
|
||||
|
||||
```yaml
|
||||
helm rollback rancher 3 -n cattle-system
|
||||
```
|
||||
|
||||
## 回滚到 Rancher 2.2-2.4
|
||||
|
||||
要回滚到 2.5 之前的 Rancher 版本,参考此处的步骤[恢复备份 — Kubernetes 安装](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md)。如果恢复 Rancher Server 的集群的某个快照,Rancher 的版本以及状态均会恢复回到快照时的版本和状态。
|
||||
|
||||
有关回滚 Docker 安装的 Rancher,请参见[本页](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)。
|
||||
|
||||
:::note
|
||||
|
||||
托管集群对其状态具有权威性。因此,恢复 Rancher Server 不会恢复快照后对托管集群进行的工作负载部署或更改。
|
||||
|
||||
:::
|
||||
|
||||
## 回滚到 Rancher 2.0-2.1
|
||||
|
||||
我们不再支持回滚到 Rancher 2.0-2.1。回滚到这些版本的说明保留在[此处](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md),仅用于无法升级到 v2.2 的情况。
|
||||
@@ -0,0 +1,188 @@
|
||||
---
|
||||
title: Rancher Server Kubernetes 集群的问题排查
|
||||
---
|
||||
|
||||
本文介绍如何对安装在 Kubernetes 集群上的 Rancher 进行故障排除。
|
||||
|
||||
### 相关命名空间
|
||||
|
||||
故障排除主要针对以下 3 个命名空间中的对象:
|
||||
|
||||
- `cattle-system`:`rancher` deployment 和 Pod。
|
||||
- `ingress-nginx`:Ingress Controller Pod 和 services。
|
||||
- `cert-manager`:`cert-manager` Pod。
|
||||
|
||||
### "default backend - 404"
|
||||
|
||||
很多操作都有可能导致 Ingress Controller 无法将流量转发到你的 Rancher 实例。但是大多数情况下都是由错误的 SSL 配置导致的。
|
||||
|
||||
检查事项:
|
||||
|
||||
- [Rancher 是否正在运行](#检查-rancher-是否正在运行)
|
||||
- [证书的 Common Name(CN)是 "Kubernetes Ingress Controller Fake Certificate"](#证书的-cn-是-kubernetes-ingress-controller-fake-certificate)
|
||||
|
||||
### 检查 Rancher 是否正在运行
|
||||
|
||||
使用 `kubectl` 检查 `cattle-system` 系统命名空间,并查看 Rancher Pod 的状态是否是 **Running**:
|
||||
|
||||
```
|
||||
kubectl -n cattle-system get pods
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
pod/rancher-784d94f59b-vgqzh 1/1 Running 0 10m
|
||||
```
|
||||
|
||||
如果状态不是 `Running`,在 Pod 上运行 `describe`,并检查 **Events**:
|
||||
|
||||
```
|
||||
kubectl -n cattle-system describe pod
|
||||
|
||||
...
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal Scheduled 11m default-scheduler Successfully assigned rancher-784d94f59b-vgqzh to localhost
|
||||
Normal SuccessfulMountVolume 11m kubelet, localhost MountVolume.SetUp succeeded for volume "rancher-token-dj4mt"
|
||||
Normal Pulling 11m kubelet, localhost pulling image "rancher/rancher:v2.0.4"
|
||||
Normal Pulled 11m kubelet, localhost Successfully pulled image "rancher/rancher:v2.0.4"
|
||||
Normal Created 11m kubelet, localhost Created container
|
||||
Normal Started 11m kubelet, localhost Started container
|
||||
```
|
||||
|
||||
### 检查 Rancher 日志
|
||||
|
||||
使用 `kubectl` 列出 Pod:
|
||||
|
||||
```
|
||||
kubectl -n cattle-system get pods
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
pod/rancher-784d94f59b-vgqzh 1/1 Running 0 10m
|
||||
```
|
||||
|
||||
使用 `kubectl` 和 Pod 名称列出该 Pod 的日志:
|
||||
|
||||
```
|
||||
kubectl -n cattle-system logs -f rancher-784d94f59b-vgqzh
|
||||
```
|
||||
|
||||
### 证书的 CN 是 "Kubernetes Ingress Controller Fake Certificate"
|
||||
|
||||
使用浏览器检查证书的详细信息。如果显示 CN 是 "Kubernetes Ingress Controller Fake Certificate",则说明读取或颁发 SSL 证书时出现了问题。
|
||||
|
||||
:::note
|
||||
|
||||
如果你使用的是 Let's Encrypt 证书,证书颁发的过程可能需要几分钟。
|
||||
|
||||
:::
|
||||
|
||||
### 排查 Cert-Manager 颁发的证书(Rancher 或 Let's Encrypt 生成的)问题
|
||||
|
||||
`cert-manager` 有 3 部分:
|
||||
|
||||
- `cert-manager` 命名空间中的 `cert-manager` Pod。
|
||||
- `cattle-system` 命名空间中的 `Issuer` 对象。
|
||||
- `cattle-system` 命名空间中的 `Certificate` 对象。
|
||||
|
||||
往后操作,对每个对象运行 `kubectl describe` 并检查事件。这样,你可以追踪可能丢失的内容。
|
||||
|
||||
以下是 Issuer 有问题的示例:
|
||||
|
||||
```
|
||||
kubectl -n cattle-system describe certificate
|
||||
...
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Warning IssuerNotReady 18s (x23 over 19m) cert-manager Issuer rancher not ready
|
||||
```
|
||||
|
||||
```
|
||||
kubectl -n cattle-system describe issuer
|
||||
...
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Warning ErrInitIssuer 19m (x12 over 19m) cert-manager Error initializing issuer: secret "tls-rancher" not found
|
||||
Warning ErrGetKeyPair 9m (x16 over 19m) cert-manager Error getting keypair for CA issuer: secret "tls-rancher" not found
|
||||
```
|
||||
|
||||
### 排查你自己提供的 SSL 证书问题
|
||||
|
||||
你的证书直接应用于 `cattle-system` 命名空间中的 Ingress 对象。
|
||||
|
||||
检查 Ingress 对象的状态,并查看它是否准备就绪:
|
||||
|
||||
```
|
||||
kubectl -n cattle-system describe ingress
|
||||
```
|
||||
|
||||
如果 Ingress 对象已就绪,但是 SSL 仍然无法正常工作,你的证书或密文的格式可能不正确。
|
||||
|
||||
这种情况下,请检查 nginx-ingress-controller 的日志。nginx-ingress-controller 的 Pod 中有多个容器,因此你需要指定容器的名称:
|
||||
|
||||
```
|
||||
kubectl -n ingress-nginx logs -f nginx-ingress-controller-rfjrq nginx-ingress-controller
|
||||
...
|
||||
W0705 23:04:58.240571 7 backend_ssl.go:49] error obtaining PEM from secret cattle-system/tls-rancher-ingress: error retrieving secret cattle-system/tls-rancher-ingress: secret cattle-system/tls-rancher-ingress was not found
|
||||
```
|
||||
|
||||
### 没有匹配的 "Issuer"
|
||||
|
||||
你所选的 SSL 配置要求在安装 Rancher 之前先安装 Cert-Manager,否则会出现以下错误:
|
||||
|
||||
```
|
||||
Error: validation failed: unable to recognize "": no matches for kind "Issuer" in version "certmanager.k8s.io/v1alpha1"
|
||||
```
|
||||
|
||||
在这种情况下,先安装 Cert-Manager,然后再重新安装 Rancher。
|
||||
|
||||
|
||||
### Canal Pod 显示 READY 2/3
|
||||
|
||||
此问题的最常见原因是端口 8472/UDP 在节点之间未打开。因此,你可以检查你的本地防火墙、网络路由或安全组。
|
||||
|
||||
解决网络问题后,`canal` Pod 会超时并重启以建立连接。
|
||||
|
||||
### nginx-ingress-controller Pod 显示 RESTARTS
|
||||
|
||||
此问题的最常见原因是 `canal` pod 未能建立覆盖网络。参见 [canal Pod 显示 READY `2/3`](#canal-pod-显示-ready-23) 进行排查。
|
||||
|
||||
|
||||
### Failed to dial to /var/run/docker.sock: ssh: rejected: administratively prohibited (open failed)
|
||||
|
||||
此错误的原因可能是:
|
||||
|
||||
* 指定连接的用户无权访问 Docker Socket。如果是这个原因,你通过登录主机并运行 `docker ps` 命令来检查:
|
||||
|
||||
```
|
||||
$ ssh user@server
|
||||
user@server$ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
```
|
||||
|
||||
如果需要了解如何进行正确设置,请参见[以非 root 用户身份管理 Docker](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user)。
|
||||
|
||||
* 你使用的操作系统是 RedHat 或 CentOS:由于 [Bugzilla #1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565),你不能使用 `root` 用户连接到节点。因此,你需要添加一个单独的用户并配置其访问 Docker Socket。如果需要了解如何进行正确设置,请参见[以非 root 用户身份管理 Docker](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user)。
|
||||
|
||||
* SSH 服务器版本不是 6.7 或更高版本:高版本是 Socket 转发所必须的,用于通过 SSH 连接到 Docker Socket。你可以在你要连接的主机上使用 `sshd -V` 或使用 netcat 进行检查:
|
||||
```
|
||||
$ nc xxx.xxx.xxx.xxx 22
|
||||
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10
|
||||
```
|
||||
|
||||
### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: no key found
|
||||
|
||||
`ssh_key_path` 密钥文件无法访问:请确保你已经指定了私钥文件(不是公钥 `.pub`),而且运行 `rke` 命令的用户可以访问该私钥文件。
|
||||
|
||||
### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
|
||||
|
||||
`ssh_key_path` 密钥文件不是访问节点的正确文件:请仔细检查,确保你已为节点指定了正确的 `ssh_key_path` 和连接用户。
|
||||
|
||||
### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: cannot decode encrypted private keys
|
||||
|
||||
如需使用加密的私钥,请使用 `ssh-agent` 来使用密码来加载密钥。如果在运行 `rke` 命令的环境中找到 `SSH_AUTH_SOCK` 环境变量,它将自动用于连接到节点。
|
||||
|
||||
### Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
|
||||
|
||||
节点无法通过配置的 `address` 和 `port` 访问。
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: 将加固的自定义/导入集群升级到 Kubernetes v1.25
|
||||
---
|
||||
|
||||
Kubernetes v1.25 改变了集群描述和执行安全策略的方式。从这个版本开始,[Pod 安全策略 (PSP)](https://kubernetes.io/docs/concepts/security/pod-security-policy/)不再可用。Kubernetes v1.25 将它们替换为新的安全对象:[Pod 安全标准 (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/) 和 [Pod 安全准入 (PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/)。
|
||||
|
||||
如果你具有自定义或导入的加固集群,你需要做好准备,确保将旧版本的 Kubernetes 顺利升级到 v1.25 或更高版本。
|
||||
|
||||
:::note
|
||||
|
||||
升级到 v1.25 后,添加必要的 Rancher 命名空间豁免。有关详细信息,请参阅 [Pod 安全准入 (PSA) 配置模板](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#豁免必须的-rancher-命名空间)。
|
||||
|
||||
:::
|
||||
|
||||
## 将导入的加固集群升级到 Kubernetes v1.25 或更高版本
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2" default>
|
||||
|
||||
在集群中的每个节点上执行以下操作:
|
||||
1. 将 [`rancher-psact.yaml`](./rancher-psact.yaml) 保存到 `/etc/rancher/rke2` 中。
|
||||
1. 编辑 RKE2 配置文件:
|
||||
1. 将 `profile` 字段更新为 `cis-1.23`。
|
||||
1. 指定刚才添加的配置文件的路径:`pod-security-admission-config-file: /etc/rancher/rke2/rancher-psact.yaml`。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="K3s">
|
||||
|
||||
在集群中的每个节点上执行以下操作:
|
||||
|
||||
遵循 K3s [将加固集群从 v1.24.x 升级到 v1.25.x](https://docs.k3s.io/known-issues#hardened-125)的官方说明,但使用[自定义](./rancher-psact.yaml)Rancher PSA 配置模板,而不是 K3s 官方网站上提供的配置。
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
执行这些步骤后,你可以通过 Rancher UI 升级集群的 Kubernetes 版本:
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**表中找到要更新的集群,点击 **⋮**。
|
||||
1. 选择**编辑配置**。
|
||||
1. 在 **Kubernetes 版本**下拉菜单中,选择要使用的版本。
|
||||
1. 单击**保存**。
|
||||
|
||||
## 将自定义加固集群升级到 Kubernetes v1.25 或更高版本
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2" default>
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**表中找到要更新的集群,点击 **⋮**。
|
||||
1. 选择**编辑配置**。
|
||||
1. 在**基本信息 > 安全**下的 **CIS 配置文件**下拉菜单中,选择 `cis-1.23`。
|
||||
1. 在 **PSA 配置模板**下拉菜单中,选择 `rancher-restricted`。
|
||||
1. 在 **Kubernetes 版本**下拉菜单中,选择要使用的版本。
|
||||
1. 单击**保存**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="K3s">
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**表中找到要更新的集群,点击 **⋮**。
|
||||
1. 选择**编辑 YAML**。
|
||||
1. 从 `kube-apiserver-arg.enable-admission-plugins` 中删除 `PodSecurityPolicy`。
|
||||
1. 在 `spec` 字段中,添加一行:`defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted`
|
||||
1. 将 `kubernetesVersion` 更新为你选择的版本(v1.25 或更高版本)。
|
||||
1. 单击**保存**。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
@@ -0,0 +1,207 @@
|
||||
---
|
||||
title: 升级
|
||||
---
|
||||
|
||||
本文介绍如何升级使用 Helm 安装在 Kubernetes 集群上的 Rancher Server。这些步骤也适用于使用 Helm 进行的离线安装。
|
||||
|
||||
有关使用 Docker 安装的 Rancher 的升级说明,请参见[本页。](../other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md)
|
||||
|
||||
如需升级 Kubernetes 集群中的组件,或 [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) 或 [附加组件(add-on)](https://rancher.com/docs/rke/latest/en/config-options/add-ons/)的定义,请参见 [RKE 升级文档](https://rancher.com/docs/rke/latest/en/upgrades/)的 Rancher Kubernetes 引擎。
|
||||
|
||||
|
||||
## 先决条件
|
||||
|
||||
### 访问 kubeconfig
|
||||
|
||||
Helm 的运行位置,应该与你的 kubeconfig 文件,或你运行 kubectl 命令的位置相同。
|
||||
|
||||
如果你在安装 Kubernetes 时使用了 RKE,那么 config 将会在你运行 `rke up` 的目录下创建。
|
||||
|
||||
kubeconfig 也可以通过 `--kubeconfig` 标签(详情请参见 https://helm.sh/docs/helm/helm/ )来手动指定所需的集群。
|
||||
|
||||
### 查看已知问题
|
||||
|
||||
如需查看每个 Rancher 版本的已知问题,请参见 [GitHub](https://github.com/rancher/rancher/releases) 中的发行说明,或查看 [Rancher 论坛](https://forums.rancher.com/c/announcements/12)。
|
||||
|
||||
不支持 _升级_ 或 _升级到_ [rancher-alpha 仓库](../resources/choose-a-rancher-version.md#helm-chart-仓库)中的任何 Chart。
|
||||
### Helm 版本
|
||||
|
||||
本安装指南假定你使用的是 Helm 3。
|
||||
|
||||
如果你使用 Helm 2,请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。如果你不能升级到 Helm 3,[Helm 2 升级页面](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)提供了使用 Helm 2 升级的旧升级指南。
|
||||
|
||||
### 离线安装:推送镜像到私有镜像仓库
|
||||
|
||||
[仅适用于离线安装](../../../pages-for-subheaders/air-gapped-helm-cli-install.md):为新的 Rancher Server 版本收集和推送镜像。使用你需要针对 Rancher 版本升级的镜像,按照步骤[推送镜像到私有镜像仓库](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md)。
|
||||
|
||||
### 使用 cert-manager 0.8.0 之前的版本升级
|
||||
|
||||
[从 2019 年 11 月 1 日开始,Let's Encrypt 已屏蔽早于 0.8.0 的 cert-manager 实例](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)。因此,请参见[说明](../resources/upgrade-cert-manager.md)把 cert-manager 升级到最新版本。
|
||||
|
||||
## 升级概要
|
||||
|
||||
按照以下步骤升级 Rancher Server:
|
||||
|
||||
|
||||
### 1. 备份运行 Rancher Server 的 Kubernetes 集群
|
||||
|
||||
使用[备份应用](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md)来备份 Rancher。
|
||||
|
||||
如果升级过程中出现问题,你将使用备份作为还原点。
|
||||
|
||||
### 2. 更新 Helm Chart 仓库
|
||||
|
||||
1. 更新本地 Helm 仓库缓存。
|
||||
|
||||
```
|
||||
helm repo update
|
||||
```
|
||||
|
||||
1. 获取你用来安装 Rancher 的仓库名称。
|
||||
|
||||
关于仓库及其区别,请参见 [Helm Chart Repositories](../resources/choose-a-rancher-version.md#helm-chart-仓库)。
|
||||
|
||||
- Latest:建议用于试用最新功能
|
||||
```
|
||||
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
|
||||
```
|
||||
- Stable:建议用于生产环境
|
||||
```
|
||||
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
|
||||
```
|
||||
- Alpha:即将发布的实验性预览。
|
||||
```
|
||||
helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha
|
||||
```
|
||||
注意:不支持升级到 Alpha 版、从 Alpha 版升级或在 Alpha 版之间升级。
|
||||
|
||||
```
|
||||
helm repo list
|
||||
|
||||
NAME URL
|
||||
stable https://charts.helm.sh/stable
|
||||
rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
如果你想切换到不同的 Helm Chart 仓库,请按照[切换仓库步骤](../resources/choose-a-rancher-version.md#切换到不同-helm-chart-仓库)进行操作。如果你要切换仓库,请先再次列出仓库,再继续执行步骤 3,以确保添加了正确的仓库。
|
||||
|
||||
:::
|
||||
|
||||
1. 从 Helm Chart 仓库获取最新的 Chart 来安装 Rancher。
|
||||
|
||||
该命令将提取最新的 Chart,并将其作为 `.tgz`文件保存在当前目录中。
|
||||
|
||||
```plain
|
||||
helm fetch rancher-<CHART_REPO>/rancher
|
||||
```
|
||||
你可以通过 `--version=` 标记,来指定要升级的目标 Chart 版本。例如:
|
||||
|
||||
```plain
|
||||
helm fetch rancher-<CHART_REPO>/rancher --version=2.6.8
|
||||
```
|
||||
|
||||
### 3. 升级 Rancher
|
||||
|
||||
本节介绍了如何使用 Helm 升级 Rancher 的一般(互联网连接)或离线安装。
|
||||
|
||||
:::note 离线说明:
|
||||
|
||||
如果你在离线环境中安装 Rancher,请跳过本页的其余部分,按照[本页](air-gapped-upgrades.md)上的说明渲染 Helm 模板。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
从当前安装的 Rancher Helm Chart 中获取用 `--set`传递的值。
|
||||
|
||||
```
|
||||
helm get values rancher -n cattle-system
|
||||
|
||||
hostname: rancher.my.org
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
这个命令会列出更多的值。此处展示的只是其中一个值的例子。
|
||||
|
||||
:::
|
||||
|
||||
:::tip
|
||||
|
||||
Deployment 的名称可能会有所不同。例如,如果你通过 AWS Marketplace 部署 Rancher,则 Deployment 的名称为“rancher-stable”。
|
||||
因此:
|
||||
```
|
||||
helm get values rancher-stable -n cattle-system
|
||||
|
||||
hostname: rancher.my.org
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
如果要将 cert-manager 从 v1.5 或更早的版本升级到最新版本,请参阅 [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#选项-c升级-15-及以下版本的-cert-manager) 了解如何在不卸载或重新安装 Rancher 的情况下升级 cert-manager。否则,请按照以下[ Rancher 升级步骤](#rancher-升级步骤)进行操作。
|
||||
|
||||
#### Rancher 升级步骤
|
||||
|
||||
保留你的所有设置把 Rancher 升级到最新版本。
|
||||
|
||||
将上一步中的所有值用 `--set key=value` 追加到命令中。
|
||||
|
||||
对于 Kubernetes v1.25 或更高版本,使用 Rancher v2.7.2-v2.7.4 时,将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说,这不是必需的,但你仍然可以手动设置该选项。
|
||||
|
||||
```
|
||||
helm upgrade rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
以上是一个例子,可能有更多上一步的值需要追加。
|
||||
|
||||
:::
|
||||
|
||||
:::tip
|
||||
|
||||
如果你通过 AWS Marketplace 部署 Rancher,则 Deployment 的名称为“rancher-stable”。
|
||||
因此:
|
||||
```
|
||||
helm upgrade rancher-stable rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
另外,你也可以将当前的值导出到一个文件中,并在升级时引用该文件。例如,如果你只需要改变 Rancher 的版本:
|
||||
|
||||
1. 将当前值导出到文件:
|
||||
```
|
||||
helm get values rancher -n cattle-system -o yaml > values.yaml
|
||||
```
|
||||
1. 只更新 Rancher 版本:
|
||||
|
||||
对于 Kubernetes v1.25 或更高版本,使用 Rancher v2.7.2-v2.7.4 时,将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说,这不是必需的,但你仍然可以手动设置该选项。
|
||||
|
||||
```
|
||||
helm upgrade rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
-f values.yaml \
|
||||
--version=2.6.8
|
||||
```
|
||||
|
||||
### 4. 验证升级
|
||||
|
||||
登录 Rancher 以确认升级成功。
|
||||
|
||||
:::tip
|
||||
|
||||
升级后出现网络问题?
|
||||
|
||||
请参见[恢复集群网络](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 已知升级问题
|
||||
|
||||
你可以在 [GitHub](https://github.com/rancher/rancher/releases) 发布说明以及 [Rancher 论坛](https://forums.rancher.com/c/announcements/12)中找到每个 Rancher 版本的已知问题。
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: 功能开关
|
||||
---
|
||||
|
||||
使用功能开关(Feature Flag),你可以试用可选或实验性的功能并启用正在逐步淘汰的旧版功能。
|
||||
|
||||
要了解功能的值以及如何启用它们,请参阅[启用实验性功能](../../../pages-for-subheaders/enable-experimental-features.md)。
|
||||
|
||||
:::note
|
||||
|
||||
某些功能要求重新启动 Rancher 容器。Rancher UI 中标记了要求重启的功能。
|
||||
|
||||
:::
|
||||
|
||||
以下是 Rancher 中可用的功能开关列表。如果你是从旧 Rancher 版本升级的,你可能会在 Rancher UI 中看到其他功能,例如 `proxy` 或 `dashboard`(均[已中断](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)):
|
||||
|
||||
- `continuous-delivery`:允许从 Fleet 中单独禁用 Fleet GitOps。有关详细信息,请参阅[持续交付](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md)。
|
||||
- `fleet`:v2.6 及更高版本的 Rancher 配置框架需要 Fleet。即使你在旧 Rancher 版本中禁用了该标志,该标志也将在升级时自动启用。有关详细信息,请参阅 [Fleet - GitOps at Scale](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)。
|
||||
- `harvester`:管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。有关详细信息,请参阅 [Harvester 集成](../../../integrations-in-rancher/harvester.md)。
|
||||
- `istio-virtual-service-ui`:启用[可视界面](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md)来创建、读取、更新和删除 Istio 虚拟服务和目标规则,这些都是 Istio 流量管理功能。
|
||||
- `legacy`:启用 2.5.x 及更早版本的一组功能,这些功能正逐渐被新的实现淘汰。它们是已弃用以及后续可用于新版本的功能组合。新的 Rancher 安装会默认禁用此标志。如果你从以前版本的 Rancher 升级,此标志会启用。
|
||||
- `multi-cluster-management`:允许配置和管理多个 Kubernetes 集群。此标志只能在安装时设置。后续无法启用或禁用它。
|
||||
- `rke1-custom-node-cleanup`:清除已删除的 RKE1 自定义节点。建议你启用此标志,以防止已删除的节点尝试重新加入集群。
|
||||
- `rke2`:启用配置 RKE2 集群。此标志默认启用。
|
||||
- `token-hashing`:启用令牌哈希。启用后,会使用 SHA256 算法对现有 Token 和所有新 Token 进行哈希处理。一旦对 Token 进行哈希处理,就无法撤消操作。此标志在启用后无法禁用。有关详细信息,请参阅 [API 令牌](../../../reference-guides/about-the-api/api-tokens.md#令牌哈希)。
|
||||
- `unsupported-storage-drivers`:允许启用非默认启用的存储提供程序和卷插件。有关详细信息,请参阅[允许使用不受支持的存储驱动程序](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)。
|
||||
|
||||
下表介绍了 Rancher 中功能开关的可用性和默认值。标记为“GA”的功能已普遍可用:
|
||||
|
||||
| 功能开关名称 | 默认值 | 状态 | 可用于 |
|
||||
| ----------------------------- | ------------- | ------------ | --------------- |
|
||||
| `continuous-delivery` | `true` | GA | v2.6.0 |
|
||||
| `fleet` | `true` | 不能禁用 | v2.6.0 |
|
||||
| `fleet` | `true` | GA | v2.5.0 |
|
||||
| `harvester` | `true` | 实验功能 | v2.6.1 |
|
||||
| `legacy` | 新安装:`false`;升级:`true` | GA | v2.6.0 |
|
||||
| `rke1-custom-node-cleanup` | `true` | GA | v2.6.0 |
|
||||
| `rke2` | `true` | 实验功能 | v2.6.0 |
|
||||
| `token-hashing` | 新安装:`false`;升级:`true` | GA | v2.6.0 |
|
||||
@@ -0,0 +1,310 @@
|
||||
---
|
||||
title: Rancher Helm Chart 选项
|
||||
keywords: [rancher helm chart, rancher helm 选项, rancher helm chart 选项, helm chart rancher, helm 选项 rancher, helm chart 选项 rancher]
|
||||
---
|
||||
|
||||
本文提供了 Rancher Helm Chart 的配置参考。
|
||||
|
||||
如需选择 Helm Chart 版本,请参见[本页](../../../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md)。
|
||||
|
||||
了解开启实验性功能的详情,请参见[本页](../../../pages-for-subheaders/enable-experimental-features.md)。
|
||||
|
||||
## 常用选项
|
||||
|
||||
| 选项 | 默认值 | 描述 |
|
||||
| ------------------------- | ------------- | ---------------------------------------------------------------------------------- |
|
||||
| `bootstrapPassword` | " " | `string` - 为第一个管理员用户设置[引导密码](#引导密码)。登录后,管理员需要重置密码。如不设置,会使用随机生成的引导密码。 |
|
||||
| `hostname` | " " | `string` - 你的 Rancher Server 的完全限定的域名(FQDN) |
|
||||
| `ingress.tls.source` | "rancher" | `string` - 从哪里获取 Ingress 的证书- "rancher, letsEncrypt, secret" |
|
||||
| `letsEncrypt.email` | " " | `string` - 你的邮箱地址 |
|
||||
| `letsEncrypt.environment` | "production" | `string` - 可选项:"staging, production" |
|
||||
| `privateCA` | false | `bool` - 如果你的证书是由私有 CA 签发的,把这个值设置为 true |
|
||||
|
||||
<br/>
|
||||
|
||||
## 高级选项
|
||||
|
||||
| 选项 | 默认值 | 描述 |
|
||||
| ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `additionalTrustedCAs` | false | `bool` - 请参见[额外的授信 CA](#额外的授信-ca) |
|
||||
| `addLocal` | "true" | `string` - 让 Rancher 检测并导入 “local” Rancher Server 集群。_注意:此选项在 2.5.0 中已不可用。你可考虑使用 `restrictedAdmin` 选项,来避免用户修改本地集群。_ |
|
||||
| `antiAffinity` | "preferred" | `string` - Rancher Pod 的反亲和性规则 - "preferred, required" |
|
||||
| `auditLog.destination` | "sidecar" | `string` - 发送审计日志到 Sidecar 容器的控制台或 hostPath 卷 - "sidecar, hostPath" |
|
||||
| `auditLog.hostPath` | "/var/log/rancher/audit" | `string` - 主机上的日志文件目标地址(仅当`auditLog.destination` 的值是 `hostPath` 时生效) |
|
||||
| `auditLog.level` | 0 | `int` - 设置 [API 审计日志](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md)等级。0 代表关闭。[0-3] |
|
||||
| `auditLog.maxAge` | 1 | `int` - 旧审计日志文件最多可保留的天数(仅当`auditLog.destination` 的值是 `hostPath` 时生效) |
|
||||
| `auditLog.maxBackup` | 1 | `int` - 审计文件最大可保留的个数(仅当 `auditLog.destination` 的值是 `hostPath` 时生效) |
|
||||
| `auditLog.maxSize` | 100 | `int` - 在审计日志被轮换前的最大容量,单位是 MB(仅当 `auditLog.destination` 的值是 `hostPath` 时生效) |
|
||||
| `auditLog.image.repository` | "registry.suse.com/bci/bci-micro" | `string` - 用于收集审计日志的镜像的位置。 |
|
||||
| `auditLog.image.tag` | "15.4.14.3" | `string` - 用于收集审计日志的镜像的标签。 |
|
||||
| `auditLog.image.pullPolicy` | "IfNotPresent" | `string` - 覆盖 auditLog 镜像的 imagePullPolicy - “Always”、“Never”、“IfNotPresent”。 |
|
||||
| `busyboxImage` | "" | `string` - 用于收集审计日志的 busybox 镜像位置。_注意:此选项已弃用,请使用 `auditLog.image.repository` 来控制审计 sidecar 镜像_。 |
|
||||
| `certmanager.version` | "" | `string` - 设置 cert-manager compatibility |
|
||||
| `debug` | false | `bool` - 在 Rancher Server 设置 debug 参数 |
|
||||
| `extraEnv` | [] | `list` - 为 Rancher 额外设置环境变量 |
|
||||
| `imagePullSecrets` | [] | `list` - 私有镜像仓库凭证的密文名称列表 |
|
||||
| `ingress.configurationSnippet` | "" | `string` - 添加额外的 Nginx 配置。可用于代理配置。 |
|
||||
| `ingress.extraAnnotations` | {} | `map` - 用于自定义 Ingress 的额外注释 |
|
||||
| `ingress.enabled` | true | 如果值为 false,Helm 不会安装 Rancher Ingress。你可把值设为 false 以部署你自己的 Ingress。 |
|
||||
| `letsEncrypt.ingress.class` | "" | `string` - cert-manager acmesolver ingress 的可选 ingress 类,用于响应 Let's Encrypt ACME 质询。选项:traefik,nginx。 | |
|
||||
| `noProxy` | "127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local,cattle-system.svc" | `string` - 不使用代理的主机名或 IP 地址的逗号分隔列表 | |
|
||||
| `proxy` | "" | `string` - 给 Rancher 配置的 HTTP[S] 代理 |
|
||||
| `rancherImage` | "rancher/rancher" | `string` - Rancher 镜像源 |
|
||||
| `rancherImagePullPolicy` | "IfNotPresent" | `string` - 覆盖 Rancher Server 镜像的 imagePullPolicy - "Always", "Never", "IfNotPresent" |
|
||||
| `rancherImageTag` | 和 Chart 版本一致 | `string` - rancher/rancher 镜像标签 |
|
||||
| `replicas` | 3 | `int` - Rancher Server 副本数。如果设为 -1,会根据集群中的可用节点数自动选择 1,2或3。 |
|
||||
| `resources` | {} | `map` - Rancher Pod 资源请求和限制 |
|
||||
| `restrictedAdmin` | `false` | `bool` - 如果值为 true,初始的 Rancher 用户访问本地 Kubernetes 集群会受到限制,以避免权限升级。详情请参见 [restricted-admin 角色](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#受限管理员)。 |
|
||||
| `systemDefaultRegistry` | "" | `string` - 用于所有系统容器镜像的私有仓库,例如 http://registry.example.com/ |
|
||||
| `tls` | "ingress" | `string` - 详情请参见[外部 TLS 终止](#外部-tls-终止)。- "ingress, external" |
|
||||
| `useBundledSystemChart` | `false` | `bool` - 选择 Rancher Server 打包的 system-charts。此参数用于离线环境安装。 |
|
||||
| `global.cattle.psp.enabled` | `true` | `bool` - 使用 Rancher v2.7.2-v2.7.4 时,选择 `false` 以禁用 Kubernetes v1.25 及更高版本的 PSP。使用 Rancher v2.7.5 及更高版本时,Rancher 会尝试检测集群是否运行不支持 PSP 的 Kubernetes 版本,如果确定集群不支持 PSP,则将默认 PSP 的使用设置为 false。你仍然可以通过显式提供此值的 `true` 或 `false` 来手动覆盖此值。在支持 PSP 的集群中(例如使用 Kubernetes v1.24 或更低版本的集群),Rancher 仍将默认使用 PSP。 |
|
||||
|
||||
|
||||
### 引导密码
|
||||
|
||||
Rancher 首次启动时,会为第一个管理员用户随机生成一个密码。当管理员首次登录 Rancher 时,用于获取引导密码(Bootstrap)的命令会在 UI 上显示。管理员需要运行命令并使用引导密码登录。然后 Rancher 会让管理员重置密码。
|
||||
|
||||
如果你想指定引导密码而不使用随机生成的密码,请参考以下命令设置密码。
|
||||
|
||||
```plain
|
||||
--set bootstrapPassword="rancher"
|
||||
```
|
||||
|
||||
无论你是使用提供的密码还是生成的密码,密码均存储在 Kubernetes 密文中。安装 Rancher 后,如何使用 kubectl 获取密码的说明将会在 UI 中显示:
|
||||
|
||||
```
|
||||
kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'
|
||||
```
|
||||
|
||||
### API 审计日志
|
||||
|
||||
启用 [API 审计日志](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md)。
|
||||
|
||||
你可以像收集其他容器日志一样收集此日志。在 Rancher Server 集群上为 `System` 项目启用 [Logging](../../../pages-for-subheaders/logging.md)。
|
||||
|
||||
```plain
|
||||
--set auditLog.level=1
|
||||
```
|
||||
|
||||
默认情况下,启用审计日志会在 Rancher pod 中创建一个 Sidecar 容器。这个容器(`rancher-audit-log`)会把日志流传输到 `stdout`。你可以像收集其他容器日志一样收集此日志。如果你使用 Sidecar 作为审计日志的目标时, `hostPath`,`maxAge`,`maxBackups` 和 `maxSize` 选项不会生效。建议使用你的操作系统或 Docker Daemon 的日志轮换功能来控制磁盘空间的使用。请为 Rancher Server 集群或 System 项目启用 [Logging](../../../pages-for-subheaders/logging.md)。
|
||||
|
||||
将 `auditLog.destination` 的值设为 `hostPath`,可以将日志转发到与主机系统共享的卷,而不是传输到 Sidecar 容器。如果目标设置为 `hostPath`,你可能需要调整其他 auditLog 参数以进行日志轮换。
|
||||
|
||||
### 额外设置环境变量
|
||||
|
||||
你可以使用 `extraEnv` 为 Rancher Server 额外设置环境变量。该列表以 YAML 格式传递给 Rancher 部署,它嵌入在 Rancher 容器的 `env` 下。你可以参考 Kubernetes 文档设置容器环境变量。`extraEnv` 可以使用 [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container) 中引用的任何键。
|
||||
|
||||
使用 `name` 和 `value` 键的示例:
|
||||
|
||||
```plain
|
||||
--set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
|
||||
--set 'extraEnv[0].value=1.0'
|
||||
```
|
||||
|
||||
如果将敏感数据(例如代理认证凭证)作为环境变量的值传递,则强烈建议使用 Secret 引用。这将防止敏感数据在 Helm 或 Rancher 部署中暴露。
|
||||
|
||||
你可以参考使用 `name`、`valueFrom.secretKeyRef.name` 和 `valueFrom.secretKeyRef.key` 键的示例。详见 [HTTP 代理](#http-代理)中的示例。
|
||||
|
||||
### TLS 设置
|
||||
|
||||
当你在 Kubernetes 集群内安装 Rancher 时,TLS 会在集群的 Ingress Controller 上卸载。支持的 TLS 设置取决于使用的 Ingress Controller。
|
||||
|
||||
参见 [TLS 设置](tls-settings.md)了解更多信息和选项。
|
||||
|
||||
### 导入 `local` 集群
|
||||
|
||||
默认情况下,Rancher Server 会检测并导入其所在的 `local` 集群。有权访问 `local` 集群的用户对 Rancher Server 管理的所有集群具有“root”访问权限。
|
||||
|
||||
:::caution
|
||||
|
||||
如果你关闭 addLocal,大多数 Rancher 2.5 功能都不能使用,包括 EKS Provisioner。
|
||||
|
||||
:::
|
||||
|
||||
如果这在你的环境中是一个问题,你可以在初始安装时将此选项设置为“false”。
|
||||
|
||||
此选项仅在首次安装 Rancher 时有效。详情请参见 [Issue 16522](https://github.com/rancher/rancher/issues/16522)。
|
||||
|
||||
```plain
|
||||
--set addLocal="false"
|
||||
```
|
||||
|
||||
### 自定义 Ingress
|
||||
|
||||
要自定义或使用 Rancher Server 的其他 Ingress,你可以设置自己的 Ingress 注释。
|
||||
|
||||
设置自定义证书颁发者的示例:
|
||||
|
||||
```plain
|
||||
--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name
|
||||
```
|
||||
|
||||
以下是使用 `ingress.configurationSnippet`设置静态代理标头的示例。该值像模板一样进行解析,因此可以使用变量。
|
||||
|
||||
```plain
|
||||
--set ingress.configurationSnippet='more_set_input_headers X-Forwarded-Host {{ .Values.hostname }};'
|
||||
```
|
||||
|
||||
### HTTP 代理
|
||||
|
||||
Rancher 的一些功能(Helm Chart)需要使用互联网才能使用。你可以使用 `proxy` 设置代理服务器,或使用 `extraEnv` 设置 `HTTPS_PROXY` 环境变量来指向代理服务器。
|
||||
|
||||
将要排除的 IP 使用逗号分隔列表添加到 `noProxy` Chart value 中。确保添加了以下值:
|
||||
- Pod 集群 IP 范围(默认值:`10.42.0.0/16`)。
|
||||
- Service Cluster IP 范围(默认值:`10.43.0.0/16`)。
|
||||
- 内部集群域(默认值:`.svc,.cluster.local`)。
|
||||
- 任何 Worker 集群 `controlplane` 节点。
|
||||
Rancher 支持在此列表中使用 CIDR 表示法来表示范围。
|
||||
|
||||
不包括敏感数据时,可以使用 `proxy` 或 `extraEnv` Chart 选项。使用 `extraEnv` 时将忽略 `noProxy` Helm 选项。因此,`NO_PROXY` 环境变量也必须设置为 `extraEnv`。
|
||||
|
||||
以下是使用 `extraEnv` Chart 选项设置代理的示例:
|
||||
|
||||
```plain
|
||||
--set proxy="http://<proxy_url:proxy_port>/"
|
||||
```
|
||||
|
||||
使用 `extraEnv` Chart 选项设置代理的示例:
|
||||
```plain
|
||||
--set extraEnv[1].name=HTTPS_PROXY
|
||||
--set extraEnv[1].value="http://<proxy_url>:<proxy_port>/"
|
||||
--set extraEnv[2].name=NO_PROXY
|
||||
--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
|
||||
```
|
||||
|
||||
包含敏感数据(例如代理认证凭证)时,请使用 `extraEnv` 选项和 `valueFrom.secretRef` 来防止敏感数据在 Helm 或 Rancher 部署中暴露。
|
||||
|
||||
下面是使用 `extraEnv` 配置代理的示例。此示例 Secret 在 Secret 的 `"https-proxy-url"` 键中包含 `"http://<username>:<password>@<proxy_url>:<proxy_port>/"` 值:
|
||||
```plain
|
||||
--set extraEnv[1].name=HTTPS_PROXY
|
||||
--set extraEnv[1].valueFrom.secretKeyRef.name=secret-name
|
||||
--set extraEnv[1].valueFrom.secretKeyRef.key=https-proxy-url
|
||||
--set extraEnv[2].name=NO_PROXY
|
||||
--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
|
||||
```
|
||||
|
||||
有关如何配置环境变量的更多信息,请参阅[为容器定义环境变量](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container)。
|
||||
|
||||
### 额外的授信 CA
|
||||
|
||||
如果你有私有镜像仓库(registries)、应用商店(catalogs)或拦截证书的代理,则可能需要向 Rancher 添加额外的授信 CA。
|
||||
|
||||
```plain
|
||||
--set additionalTrustedCAs=true
|
||||
```
|
||||
|
||||
创建完 Rancher deployment 后,将 pem 格式的 CA 证书复制到一个名为 `ca-additional.pem` 的文件中,并使用 `kubectl` 在 `cattle-system` 命名空间中创建 `tls-ca-additional` 密文。
|
||||
|
||||
```plain
|
||||
kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-additional.pem=./ca-additional.pem
|
||||
```
|
||||
|
||||
### 私有仓库和离线安装
|
||||
|
||||
有关使用私有仓库安装 Rancher 的详情,请参见[离线安装](../../../pages-for-subheaders/air-gapped-helm-cli-install.md)。
|
||||
|
||||
## 外部 TLS 终止
|
||||
|
||||
我们建议将负载均衡器配置为 4 层均衡,将普通 80/tcp 和 443/tcp 转发到 Rancher Management 集群节点。集群上的 Ingress Controller 会将端口 80 上的 HTTP 流量重定向到端口 443 上的 HTTPS。
|
||||
|
||||
你可以在 Rancher 集群(Ingress)外部的 L7 负载均衡器上终止 SSL/TLS。使用 `--set tls=external` 选项,将负载均衡器指向所有 Rancher 集群节点上的端口 HTTP 80。这将在 HTTP 端口 80 上暴露 Rancher 接口。请注意,允许直接连接到 Rancher 集群的客户端不会被加密。如果你选择这样做,我们建议你将网络级别的直接访问限制为仅你的负载均衡器。
|
||||
|
||||
:::note
|
||||
|
||||
如果你使用的是私有 CA 签名的证书,请添加 `--set privateCA=true` 并参见[添加 TLS 密文 - 使用私有 CA 签名证书](../../../getting-started/installation-and-upgrade/resources/add-tls-secrets.md),为 Rancher 添加 CA 证书。
|
||||
|
||||
:::
|
||||
|
||||
你的负载均衡器必须支持长期存在的 Websocket 连接,并且需要插入代理头,以便 Rancher 可以正确传送链接。
|
||||
|
||||
### 使用 NGINX v0.25 为外部 TLS 配置 Ingress
|
||||
|
||||
在 NGINX 0.25 中,NGINX 关于转发头和外部 TLS 终止的行为[已更改](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0220)。因此,如果你同时使用 NGINX 0.25 和外部 TLS 终止配置,你必须编辑 `cluster.yml` 来为 Ingress 启用 `use-forwarded-headers` 选项。
|
||||
|
||||
```yaml
|
||||
ingress:
|
||||
provider: nginx
|
||||
options:
|
||||
use-forwarded-headers: 'true'
|
||||
```
|
||||
|
||||
### 必须的 Header
|
||||
|
||||
- `Host`
|
||||
- `X-Forwarded-Proto`
|
||||
- `X-Forwarded-Port`
|
||||
- `X-Forwarded-For`
|
||||
|
||||
### 建议的超时时间
|
||||
|
||||
- 读超时:`1800 seconds`
|
||||
- 写超时:`1800 seconds`
|
||||
- 连接超时:`30 seconds`
|
||||
|
||||
### 健康检查
|
||||
|
||||
Rancher 将对 `/healthz` 端点的健康检查响应`200`。
|
||||
|
||||
### 示例 NGINX 配置
|
||||
|
||||
此 NGINX 配置已在 NGINX 1.14 上进行了测试。
|
||||
|
||||
:::caution
|
||||
|
||||
此 NGINX 配置只是一个示例,可能不适合你的环境。如需查阅完整文档,请参见 [NGINX 负载均衡 - HTTP 负载均衡](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/)。
|
||||
|
||||
:::
|
||||
|
||||
- 将 `IP_NODE1`,`IP_NODE2` 和 `IP_NODE3` 替换为你集群中节点的 IP 地址。
|
||||
- 将两处的 `FQDN` 均替换为 Rancher 的 DNS 名称。
|
||||
- 把 `/certs/fullchain.pem` 和 `/certs/privkey.pem` 分别替换为服务器证书和服务器证书密钥的位置。
|
||||
|
||||
```
|
||||
worker_processes 4;
|
||||
worker_rlimit_nofile 40000;
|
||||
|
||||
events {
|
||||
worker_connections 8192;
|
||||
}
|
||||
|
||||
http {
|
||||
upstream rancher {
|
||||
server IP_NODE_1:80;
|
||||
server IP_NODE_2:80;
|
||||
server IP_NODE_3:80;
|
||||
}
|
||||
|
||||
map $http_upgrade $connection_upgrade {
|
||||
default Upgrade;
|
||||
'' close;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 443 ssl http2;
|
||||
server_name FQDN;
|
||||
ssl_certificate /certs/fullchain.pem;
|
||||
ssl_certificate_key /certs/privkey.pem;
|
||||
|
||||
location / {
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
proxy_set_header X-Forwarded-Port $server_port;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_pass http://rancher;
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection $connection_upgrade;
|
||||
# 此项允许执行的 shell 窗口保持开启,最长可达15分钟。不使用此参数的话,默认1分钟后自动关闭。
|
||||
proxy_read_timeout 900s;
|
||||
proxy_buffering off;
|
||||
}
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
server_name FQDN;
|
||||
return 301 https://$server_name$request_uri;
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: TLS 设置
|
||||
---
|
||||
|
||||
更改默认 TLS 设置的方法取决于它的安装方式。
|
||||
|
||||
## 在高可用 Kubernetes 集群中运行 Rancher
|
||||
|
||||
当你在 Kubernetes 集群内安装 Rancher 时,TLS 会在集群的 Ingress Controller 上卸载。可用的 TLS 设置取决于使用的 Ingress Controller:
|
||||
|
||||
* nginx-ingress-controller(RKE1 和 RKE2 默认):[默认的 TLS 版本和密码](https://kubernetes.github.io/ingress-nginx/user-guide/tls/#default-tls-version-and-ciphers)。
|
||||
* traefik(K3s 默认):[TLS 选项](https://doc.traefik.io/traefik/https/tls/#tls-options)。
|
||||
|
||||
## 在单个 Docker 容器中运行 Rancher
|
||||
|
||||
默认 TLS 配置仅支持 TLS 1.2 和安全的 TLS 密码套件。你可以通过设置以下环境变量来更改此配置:
|
||||
|
||||
| 参数 | 描述 | 默认 | 可用选项 |
|
||||
|-----|-----|-----|-----|
|
||||
| `CATTLE_TLS_MIN_VERSION` | 最小 TLS 版本 | `1.2` | `1.0`, `1.1`, `1.2`, `1.3` |
|
||||
| `CATTLE_TLS_CIPHERS` | 支持的 TLS 密码套件 | `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`,<br/>`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` | 详情请参见 [Golang TLS 常量](https://golang.org/pkg/crypto/tls/#pkg-constants)。 |
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: Dockershim
|
||||
---
|
||||
|
||||
Dockershim 是 Kubelet 和 Docker Daemon 之间的 CRI 兼容层。Kubernetes 1.20 版本宣布了[移除树内 Dockershim](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。有关此移除的更多信息以及时间线,请参见 [Kubernetes Dockershim 弃用相关的常见问题](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed)。
|
||||
|
||||
RKE 集群现在支持外部 Dockershim,来让用户继续使用 Docker 作为 CRI 运行时。现在,我们通过使用 [Mirantis 和 Docker ](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/) 来确保 RKE 集群可以继续使用 Docker,从而实现上游开源社区的外部 Dockershim。
|
||||
|
||||
RKE2 和 K3s 集群使用嵌入的 containerd 作为容器运行时,因此不受影响。
|
||||
|
||||
要在 1.24 之前的 RKE 版本中启用外部 Dockershim,请配置以下选项:
|
||||
|
||||
```
|
||||
enable_cri_dockerd: true
|
||||
```
|
||||
|
||||
从 1.24 版本开始,以上默认为 true。
|
||||
|
||||
如果你想使用其他容器运行时,Rancher 也提供使用 Containerd 作为默认运行时的,以边缘为中心的 K3s,和以数据中心为中心的 RKE2 Kubernetes 发行版。然后,你就可以通过 Rancher 对导入的 RKE2 和 K3s Kubernetes 集群进行升级和管理。
|
||||
|
||||
### 常见问题
|
||||
|
||||
<br/>
|
||||
|
||||
Q:是否必须升级 Rancher 才能获得 Rancher 对上游外部 Dockershim 替换的支持?
|
||||
|
||||
A:对于 RKE,Dockershim `cri_dockerd` 替换的上游支持从 Kubernetes 1.21 开始。你需要使用支持 RKE 1.21 的 Rancher 版本。详情请参见我们的支持矩阵。
|
||||
|
||||
<br/>
|
||||
|
||||
Q:我目前的 RKE 使用 Kubernetes 1.23。如果上游最终在 1.24 中删除 Dockershim,会发生什么?
|
||||
|
||||
A:RKE 中带有 Kubernetes 的 Dockershim 版本将继续工作到 1.23。有关时间线的更多信息,请参见 [Kubernetes Dockershim 弃用相关的常见问题](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed)。从 1.24 开始,RKE 将默认启用 `cri_dockerd` 并在之后的版本中继续启用。
|
||||
|
||||
<br/>
|
||||
|
||||
Q: 如果我不想再依赖 Dockershim 或 cri_dockerd,我还有什么选择?
|
||||
|
||||
A: 你可以为 Kubernetes 使用不需要 Dockershim 支持的运行时,如 Containerd。RKE2 和 K3s 就是其中的两个选项。
|
||||
|
||||
<br/>
|
||||
|
||||
Q: 如果我目前使用 RKE1,但想切换到 RKE2,我可以怎样进行迁移?
|
||||
|
||||
A: 你可以构建一个新集群,然后将工作负载迁移到使用 Containerd 的新 RKE2 集群。Rancher 也在探索就地升级路径的可能性。
|
||||
|
||||
<br/>
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: 安装 Docker
|
||||
---
|
||||
|
||||
在使用 Helm 或 Docker 在 RKE 集群节点上安装 Rancher Server 前,你需要先安装 Docker。RKE2 和 K3s 集群不要求使用 Docker。
|
||||
|
||||
Docker 有几个安装方法。一种方法是参见 [Docker 官方文档](https://docs.docker.com/install/)以了解如何在 Linux 上安装 Docker。不同 Linux 发行版的安装步骤可能有所不同。
|
||||
|
||||
另一种方式是使用 Rancher 的 Docker 安装脚本,该脚本可用于较新的 Docker 版本。
|
||||
|
||||
例如,此命令可用于在 SUSE Linux Enterprise 或 Ubuntu 等主要 Linux 发行版上安装 Docker 20.10:
|
||||
|
||||
```
|
||||
curl https://releases.rancher.com/install-docker/20.10.sh | sh
|
||||
```
|
||||
|
||||
Rancher 提供 Kubernetes 支持的所有上游 Docker 版本的安装脚本。如需了解我们是否提供某个 Docker 版本的安装脚本,请参见包含了 Rancher 所有的 Docker 安装脚本的 [GitHub 仓库](https://github.com/rancher/install-docker)。
|
||||
|
||||
请注意,必须应用以下 sysctl 设置:
|
||||
|
||||
```
|
||||
net.bridge.bridge-nf-call-iptables=1
|
||||
```
|
||||
@@ -0,0 +1,343 @@
|
||||
---
|
||||
title: 端口要求
|
||||
description: 了解 Rancher 正常运行所需的端口要求,包括 Rancher 节点和下游 Kubernetes 集群节点
|
||||
---
|
||||
|
||||
import PortsIaasNodes from '@site/src/components/PortsIaasNodes'
|
||||
import PortsCustomNodes from '@site/src/components/PortsCustomNodes'
|
||||
import PortsImportedHosted from '@site/src/components/PortsImportedHosted'
|
||||
|
||||
为了确保能正常运行,Rancher 需要在 Rancher 节点和下游 Kubernetes 集群节点上开放一些端口。
|
||||
|
||||
## Rancher 节点
|
||||
|
||||
下表列出了运行 Rancher Server 的节点之间需要开放的端口。
|
||||
|
||||
不同的 Rancher Server 架构有不同的端口要求。
|
||||
|
||||
Rancher 可以安装在任何 Kubernetes 集群上。如果你的 Rancher 安装在 K3s、RKE 或 RKE2 Kubernetes 集群上,请参考下面的标签页。对于其他 Kubernetes 发行版,请参见该发行版的文档,了解集群节点的端口要求。
|
||||
|
||||
:::note 注意事项:
|
||||
|
||||
- Rancher 节点可能要求额外出站访问已配置的外部验证提供程序(如 LDAP)。
|
||||
- Kubernetes 建议节点端口服务使用 TCP 30000-32767。
|
||||
- 对于防火墙,可能需要在集群和 Pod CIDR 内启用流量。
|
||||
- Rancher 节点可能还需要出站访问用于存储集群备份(如 Minio)的外部 S3 上的位置。
|
||||
|
||||
:::
|
||||
|
||||
### K3s 上 Rancher Server 节点的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
K3s server 需要开放端口 6443 才能供节点访问。
|
||||
|
||||
使用 Flannel VXLAN 时,节点需要能够通过 UDP 端口 8472 访问其他节点。节点不应监听任何其他端口。K3s 使用反向隧道,建立节点与 Server 的出站连接,所有 kubelet 流量都通过该隧道进行。但是,如果你不使用 Flannel,而是使用自定义的 CNI,K3s 则不需要打开 8472 端口。
|
||||
|
||||
如果要使用 Metrics Server,则需要在每个节点上打开端口 10250。
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
节点上的 VXLAN 端口会开放集群网络,让任何人均能访问集群。因此,不要将 VXLAN 端口暴露给外界。请使用禁用 8472 端口的防火墙/安全组来运行节点。
|
||||
|
||||
:::
|
||||
|
||||
下表描述了入站和出站流量的端口要求:
|
||||
|
||||
<figcaption>Rancher Server 节点的入站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 源 | 描述 |
|
||||
|-----|-----|----------------|---|
|
||||
| TCP | 80 | 执行外部 SSL 终止的负载均衡器/代理 | 使用外部 SSL 终止时的 Rancher UI/API |
|
||||
| TCP | 443 | <ul><li>Server 节点</li><li>Agent 节点</li><li>托管/注册的 Kubernetes</li><li>任何需要使用 Rancher UI 或 API 的源</li></ul> | Rancher Agent,Rancher UI/API,kubectl |
|
||||
| TCP | 6443 | K3s Server 节点 | Kubernetes API |
|
||||
| UDP | 8472 | K3s Server 和 Agent 节点 | 仅 Flannel VXLAN 需要 |
|
||||
| TCP | 10250 | K3s Server 和 Agent 节点 | kubelet |
|
||||
|
||||
<figcaption>Rancher 节点的出站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 目标 | 描述 |
|
||||
| -------- | ---- | -------------------------------------------------------- | --------------------------------------------- |
|
||||
| TCP | 22 | 使用 Node Driver 创建的节点的任何节点 IP | 使用 Node Driver SSH 配置节点 |
|
||||
| TCP | 443 | git.rancher.io | Rancher catalog |
|
||||
| TCP | 2376 | 使用 Node Driver 创建的节点的任何节点 IP | Docker Machine 使用的 Docker daemon TLS 端口 |
|
||||
| TCP | 6443 | 托管/导入的 Kubernetes API | Kubernetes API Server |
|
||||
|
||||
</details>
|
||||
|
||||
### RKE 上 Rancher Server 节点的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
通常情况下,Rancher 安装在三个 RKE 节点上,这些节点都有 etcd、controlplane 和 worker 角色。
|
||||
|
||||
|
||||
|
||||
下表描述了 Rancher 节点之间流量的端口要求:
|
||||
|
||||
<figcaption>Rancher 节点的流量规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 描述 |
|
||||
|-----|-----|----------------|
|
||||
| TCP | 443 | Rancher Agents |
|
||||
| TCP | 2379 | etcd 客户端请求 |
|
||||
| TCP | 2380 | etcd 对等通信 |
|
||||
| TCP | 6443 | Kubernetes apiserver |
|
||||
| TCP | 8443 | NGINX Ingress 的验证 Webhook |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN 覆盖网络 |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 10250 | Metrics Server 与所有节点的通信 |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
|
||||
下表描述了入站和出站流量的端口要求:
|
||||
|
||||
<figcaption>Rancher 节点的入站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 源 | 描述 |
|
||||
|-----|-----|----------------|---|
|
||||
| TCP | 22 | RKE CLI | RKE 通过 SSH 配置节点 |
|
||||
| TCP | 80 | 负载均衡器/反向代理 | 到 Rancher UI/API 的 HTTP 流量 |
|
||||
| TCP | 443 | <ul><li>负载均衡器/反向代理</li><li>所有集群节点和其他 API/UI 客户端的 IP</li></ul> | 到 Rancher UI/API 的 HTTPS 流量 |
|
||||
| TCP | 6443 | Kubernetes API 客户端 | 到 Kubernetes API 的 HTTPS 流量 |
|
||||
|
||||
<figcaption>Rancher 节点的出站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 目标 | 描述 |
|
||||
|-----|-----|----------------|---|
|
||||
| TCP | 443 | git.rancher.io | Rancher catalog |
|
||||
| TCP | 22 | 使用 Node Driver 创建的任何节点 | Node Driver 通过 SSH 配置节点 |
|
||||
| TCP | 2376 | 使用 Node Driver 创建的任何节点 | Node Driver 使用的 Docker daemon TLS 端口 |
|
||||
| TCP | 6443 | 托管/导入的 Kubernetes API | Kubernetes API Server |
|
||||
| TCP | 提供商依赖 | 托管集群中 Kubernetes API 端点的端口 | Kubernetes API |
|
||||
|
||||
</details>
|
||||
|
||||
### RKE2 上 Rancher Server 节点的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
RKE2 server 需要开放端口 6443 和 9345 才能供集群中的其他节点访问。
|
||||
|
||||
使用 Flannel VXLAN 时,所有节点都需要能够通过 UDP 端口 8472 访问其他节点。
|
||||
|
||||
如果要使用 Metrics Server,则需要在每个节点上打开端口 10250。
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
节点上的 VXLAN 端口会开放集群网络,让任何人均能访问集群。因此,不要将 VXLAN 端口暴露给外界。请使用禁用 8472 端口的防火墙/安全组来运行节点。
|
||||
|
||||
:::
|
||||
|
||||
<figcaption>RKE2 Server 节点的入站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 源 | 描述 |
|
||||
|-----|-----|----------------|---|
|
||||
| TCP | 9345 | RKE2 Server 和 Agent 节点 | 节点注册。需要在所有 Server 节点上将端口开放给集群中的所有其他节点。 |
|
||||
| TCP | 6443 | RKE2 Agent 节点 | Kubernetes API |
|
||||
| UDP | 8472 | RKE2 Server 和 Agent 节点 | 仅 Flannel VXLAN 需要 |
|
||||
| TCP | 10250 | RKE2 Server 和 Agent 节点 | kubelet |
|
||||
| TCP | 2379 | RKE2 Server 节点 | etcd 客户端端口 |
|
||||
| TCP | 2380 | RKE2 Server 节点 | etcd 对等端口 |
|
||||
| TCP | 30000-32767 | RKE2 Server 和 Agent 节点 | NodePort 端口范围。可以使用 TCP 或 UDP。 |
|
||||
| TCP | 5473 | Calico-node pod 连接到 typha pod | 使用 Calico 部署时需要 |
|
||||
| HTTP | 80 | 执行外部 SSL 终止的负载均衡器/代理 | 使用外部 SSL 终止时的 Rancher UI/API |
|
||||
| HTTPS | 443 | <ul><li>托管/注册的 Kubernetes</li><li>任何需要使用 Rancher UI 或 API 的源</li></ul> | Rancher Agent,Rancher UI/API,kubectl。如果负载均衡器执行 TLS 终止,则不需要。 |
|
||||
|
||||
所有出站流量通常都是允许的。
|
||||
</details>
|
||||
|
||||
### Docker 安装的 Rancher Server 的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了 Rancher 节点入站和出站流量的端口要求:
|
||||
|
||||
<figcaption>Rancher 节点的入站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 源 | 描述 |
|
||||
|-----|-----|----------------|---|
|
||||
| TCP | 80 | 执行外部 SSL 终止的负载均衡器/代理 | 使用外部 SSL 终止时的 Rancher UI/API |
|
||||
| TCP | 443 | <ul><li>托管/注册的 Kubernetes</li><li>任何需要使用 Rancher UI 或 API 的源</li></ul> | Rancher Agent,Rancher UI/API,kubectl |
|
||||
|
||||
<figcaption>Rancher 节点的出站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 源 | 描述 |
|
||||
|-----|-----|----------------|---|
|
||||
| TCP | 22 | 使用 Node Driver 创建的节点的任何节点 IP | 使用 Node Driver SSH 配置节点 |
|
||||
| TCP | 443 | git.rancher.io | Rancher catalog |
|
||||
| TCP | 2376 | 使用 Node Driver 创建的节点的任何节点 IP | Docker Machine 使用的 Docker daemon TLS 端口 |
|
||||
| TCP | 6443 | 托管/导入的 Kubernetes API | Kubernetes API Server |
|
||||
|
||||
</details>
|
||||
|
||||
## 下游 Kubernetes 集群节点
|
||||
|
||||
下游 Kubernetes 集群用于运行你的应用和服务。本节介绍了哪些端口需要在下游集群的节点上打开,以便 Rancher 能够与它们进行通信。
|
||||
|
||||
不同的下游集群的启动方式有不同的端口要求。下面的每个标签都列出了不同[集群类型](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)所需打开的端口。
|
||||
|
||||
下图描述了为每个[集群类型](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)打开的端口。
|
||||
|
||||
<figcaption>Rancher 管理面板的端口要求</figcaption>
|
||||
|
||||

|
||||
|
||||
:::tip
|
||||
|
||||
如果你对安全性的关注不是太高,而且也愿意多打开几个端口,你可以参考[常用端口](#常用端口)中列出的端口,而不是参考下方的表格。
|
||||
|
||||
:::
|
||||
|
||||
### Harvester 集群的端口
|
||||
|
||||
有关 Harvester 端口要求的更多信息,请参阅[此处](../../../integrations-in-rancher/harvester.md#端口要求)。
|
||||
|
||||
|
||||
### Rancher 使用节点池启动 Kubernetes 集群的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了节点在[云提供商](../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)中创建的情况下,[Rancher 启动 Kubernetes](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 的端口要求。
|
||||
|
||||
:::note
|
||||
|
||||
在 AWS EC2 或 DigitalOcean 等云提供商中创建集群期间,Rancher 会自动打开所需的端口。
|
||||
|
||||
:::
|
||||
|
||||
<PortsIaasNodes/>
|
||||
|
||||
</details>
|
||||
|
||||
### Rancher 使用自定义节点启动 Kubernetes 集群的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了使用[自定义节点](../../../pages-for-subheaders/use-existing-nodes.md)的情况下,[Rancher 启动 Kubernetes](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 的端口要求。
|
||||
|
||||
<PortsCustomNodes/>
|
||||
|
||||
</details>
|
||||
|
||||
### 托管 Kubernetes 集群的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了[托管集群](../../../pages-for-subheaders/set-up-clusters-from-hosted-kubernetes-providers.md)的端口要求。
|
||||
|
||||
<PortsImportedHosted/>
|
||||
|
||||
</details>
|
||||
|
||||
### 已注册集群的端口
|
||||
|
||||
:::note
|
||||
|
||||
在 Rancher 2.5 之前,注册集群被称为导入集群。
|
||||
|
||||
:::
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了[注册集群](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md)的端口要求。
|
||||
|
||||
<PortsImportedHosted/>
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
## 其他端口注意事项
|
||||
|
||||
### 常用端口
|
||||
|
||||
无论集群是什么类型,常用端口通常在你的 Kubernetes 节点上打开。
|
||||
|
||||
import CommonPortsTable from '../../../shared-files/_common-ports-table.md';
|
||||
|
||||
<CommonPortsTable />
|
||||
|
||||
----
|
||||
|
||||
### 本地节点流量
|
||||
|
||||
上述要求中标记为`本地流量`(例如 `9099 TCP`)的端口会用于 Kubernetes 健康检查 (`livenessProbe` 和 `readinessProbe`)。
|
||||
这些健康检查是在节点本身执行的。在大多数云环境中,这种本地流量是默认允许的。
|
||||
|
||||
但是,在以下情况下可能会阻止此流量:
|
||||
|
||||
- 你已在节点上应用了严格的主机防火墙策略。
|
||||
- 你正在使用有多个接口(多宿主)的节点。
|
||||
|
||||
在这些情况下,你必须在你的主机防火墙中主动允许这种流量,如果是公共/私有云托管的主机(例如 AWS 或 OpenStack),你需要在你的安全组配置中主动允许此流量。请记住,如果你在安全组中使用安全组作为源或目标,主动开放端口只适用于节点/实例的私有接口。
|
||||
|
||||
### Rancher AWS EC2 安全组
|
||||
|
||||
当你使用 [AWS EC2 Node Driver](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) 在 Rancher 中配置集群节点时,你可以让 Rancher 创建一个名为 `rancher-nodes` 的安全组。以下规则会自动添加到该安全组中。
|
||||
|
||||
| 类型 | 协议 | 端口范围 | 源/目标 | 规则类型 |
|
||||
|-----------------|:--------:|:-----------:|------------------------|:---------:|
|
||||
| SSH | TCP | 22 | 0.0.0.0/0 | 入站 |
|
||||
| HTTP | TCP | 80 | 0.0.0.0/0 | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 443 | 0.0.0.0/0 | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 2376 | 0.0.0.0/0 | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 2379-2380 | sg-xxx (rancher-nodes) | 入站 |
|
||||
| 自定义 UDP 规则 | UDP | 4789 | sg-xxx (rancher-nodes) | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 6443 | 0.0.0.0/0 | 入站 |
|
||||
| 自定义 UDP 规则 | UDP | 8472 | sg-xxx (rancher-nodes) | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 10250-10252 | sg-xxx (rancher-nodes) | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 10256 | sg-xxx (rancher-nodes) | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 30000-32767 | 0.0.0.0/0 | 入站 |
|
||||
| 自定义 UDP 规则 | UDP | 30000-32767 | 0.0.0.0/0 | 入站 |
|
||||
| 所有流量 | 全部 | 全部 | 0.0.0.0/0 | 出站 |
|
||||
|
||||
### 打开 SUSE Linux 端口
|
||||
|
||||
SUSE Linux 可能有一个防火墙,默认情况下会阻止所有端口。要打开将主机添加到自定义集群所需的端口:
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="SLES 15 / openSUSE Leap 15">
|
||||
|
||||
1. SSH 进入实例。
|
||||
1. 以文本模式启动 YaST:
|
||||
```
|
||||
sudo yast2
|
||||
```
|
||||
|
||||
1. 导航到**安全和用户** > **防火墙** > **区域:公共** > **端口**。要在界面内导航,请参照[说明](https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-yast-text.html#sec-yast-cli-navigate)。
|
||||
1. 要打开所需的端口,把它们输入到 **TCP 端口** 和 **UDP 端口** 字段。在这个例子中,端口 9796 和 10250 也被打开,用于监控。由此产生的字段应类似于以下内容:
|
||||
```yaml
|
||||
TCP Ports
|
||||
22, 80, 443, 2376, 2379, 2380, 6443, 9099, 9796, 10250, 10254, 30000-32767
|
||||
UDP Ports
|
||||
8472, 30000-32767
|
||||
```
|
||||
|
||||
1. 所有必须端口都输入后,选择**接受**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="SLES 12 / openSUSE Leap 42">
|
||||
|
||||
1. SSH 进入实例。
|
||||
1. 编辑 `/etc/sysconfig/SuSEfirewall2` 并打开所需的端口。在这个例子中,端口 9796 和 10250 也被打开,用于监控。
|
||||
```
|
||||
FW_SERVICES_EXT_TCP="22 80 443 2376 2379 2380 6443 9099 9796 10250 10254 30000:32767"
|
||||
FW_SERVICES_EXT_UDP="8472 30000:32767"
|
||||
FW_ROUTE=yes
|
||||
```
|
||||
1. 用新的端口重启防火墙:
|
||||
```
|
||||
SuSEfirewall2
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**结果** :该节点已打开添加到自定义集群所需的端口。
|
||||
@@ -0,0 +1,149 @@
|
||||
---
|
||||
title: Docker 安装命令
|
||||
---
|
||||
|
||||
Docker 安装适用于想要测试 Rancher 的用户。
|
||||
|
||||
你可以使用 `docker run`命令,把 Rancher Server 组件安装到单个节点上,而不需要运行 Kubernetes 集群。由于只有一个节点和一个 Docker 容器,因此,如果该节点发生故障,由于其他节点上没有可用的 etcd 数据副本,你将丢失 Rancher Server 的所有数据。
|
||||
|
||||
你可以使用备份应用,按照[这些步骤](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md),将 Rancher Server 从 Docker 安装迁移到 Kubernetes 安装。
|
||||
|
||||
出于安全考虑,使用 Rancher 时请使用 SSL(Secure Sockets Layer)。SSL 保护所有 Rancher 网络通信(如登录和与集群交互)的安全。
|
||||
|
||||
| 环境变量键 | 环境变量值 | 描述 |
|
||||
| -------------------------------- | -------------------------------- | ---- |
|
||||
| `CATTLE_SYSTEM_DEFAULT_REGISTRY` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | 将 Rancher Server 配置成在配置集群时,始终从私有镜像仓库中拉取镜像。 |
|
||||
| `CATTLE_SYSTEM_CATALOG` | `bundled` | 配置 Rancher Server 使用打包的 Helm System Chart 副本。[system charts](https://github.com/rancher/system-charts) 仓库包含所有 Monitoring,Logging,告警和全局 DNS 等功能所需的应用商店项目。这些 [Helm Chart](https://github.com/rancher/system-charts) 位于 GitHub 中。但是由于你处在离线环境,因此使用 Rancher 内置的 Chart 会比设置 Git mirror 容易得多。 |
|
||||
|
||||
:::note 你是否需要:
|
||||
|
||||
- 配置自定义 CA 根证书以访问服务。参见[自定义 CA 根证书](../../resources/custom-ca-root-certificates.md)。
|
||||
- 记录所有 Rancher API 的事务。参见 [API 审计](../../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-审计日志)。
|
||||
|
||||
:::
|
||||
|
||||
选择以下的选项之一:
|
||||
|
||||
### 选项 A:使用 Rancher 默认的自签名证书
|
||||
|
||||
<details id="option-a">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
如果你在不考虑身份验证的开发或测试环境中安装 Rancher,可以使用 Rancher 生成的自签名证书安装 Rancher。这种安装方式避免了自己生成证书的麻烦。
|
||||
|
||||
登录到你的 Linux 主机,然后运行下面的安装命令。输入命令时,参考下表来替换每个占位符。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 私有镜像仓库的 URL 和端口。 |
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要安装的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
特权访问是[必须](./install-rancher-ha.md#rancher-特权访问)的。
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-e CATTLE_SYSTEM_DEFAULT_REGISTRY=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的默认私有镜像仓库
|
||||
-e CATTLE_SYSTEM_CATALOG=bundled \ # 使用打包的 Rancher System Chart
|
||||
--privileged \
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### 选项 B:使用你自己的证书 - 自签名
|
||||
|
||||
<details id="option-b">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
在你团队访问 Rancher Server 的开发或测试环境中,创建一个用于你的安装的自签名证书,以便团队验证他们对实例的连接。
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
从能连接到互联网的计算机上,使用 [OpenSSL](https://www.openssl.org/) 或其他方法创建自签名证书。
|
||||
|
||||
- 证书文件的格式必须是 PEM。
|
||||
- 在你的证书文件中,包括链中的所有中间证书。你需要对你的证书进行排序,把你的证书放在最前面,后面跟着中间证书。如需查看示例,请参见[证书故障排除](../rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)。
|
||||
|
||||
:::
|
||||
|
||||
创建证书后,登录 Linux 主机,然后运行以下安装命令。输入命令时,参考下表来替换每个占位符。使用 `-v` 标志并提供证书的路径,以将证书挂载到容器中。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `<CERT_DIRECTORY>` | 包含证书文件的目录的路径。 |
|
||||
| `<FULL_CHAIN.pem>` | 完整证书链的路径。 |
|
||||
| `<PRIVATE_KEY.pem>` | 证书私钥的路径。 |
|
||||
| `<CA_CERTS.pem>` | CA 证书的路径。 |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 私有镜像仓库的 URL 和端口。 |
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要安装的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
特权访问是[必须](./install-rancher-ha.md#rancher-特权访问)的。
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-v /<CERT_DIRECTORY>/<FULL_CHAIN.pem>:/etc/rancher/ssl/cert.pem \
|
||||
-v /<CERT_DIRECTORY>/<PRIVATE_KEY.pem>:/etc/rancher/ssl/key.pem \
|
||||
-v /<CERT_DIRECTORY>/<CA_CERTS.pem>:/etc/rancher/ssl/cacerts.pem \
|
||||
-e CATTLE_SYSTEM_DEFAULT_REGISTRY=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的默认私有镜像仓库
|
||||
-e CATTLE_SYSTEM_CATALOG=bundled \ # 使用打包的 Rancher System Chart
|
||||
--privileged \
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### 选项 C:使用你自己的证书 - 可信 CA 签名的证书
|
||||
|
||||
<details id="option-c">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
在公开暴露应用的开发或测试环境中,请使用由可信 CA 签名的证书,以避免用户收到证书安全警告。
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
证书文件的格式必须是 PEM。
|
||||
|
||||
:::
|
||||
|
||||
获取证书后,登录 Linux 主机,然后运行以下安装命令。输入命令时,参考下表来替换每个占位符。因为你的证书是由可信的 CA 签名的,因此你不需要安装额外的 CA 证书文件。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `<CERT_DIRECTORY>` | 包含证书文件的目录的路径。 |
|
||||
| `<FULL_CHAIN.pem>` | 完整证书链的路径。 |
|
||||
| `<PRIVATE_KEY.pem>` | 证书私钥的路径。 |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 私有镜像仓库的 URL 和端口。 |
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要安装的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
:::note
|
||||
|
||||
使用 `--no-cacerts` 作为容器的参数,以禁用 Rancher 生成的默认 CA 证书。
|
||||
|
||||
:::
|
||||
|
||||
特权访问是[必须](./install-rancher-ha.md#rancher-特权访问)的。
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
--no-cacerts \
|
||||
-v /<CERT_DIRECTORY>/<FULL_CHAIN.pem>:/etc/rancher/ssl/cert.pem \
|
||||
-v /<CERT_DIRECTORY>/<PRIVATE_KEY.pem>:/etc/rancher/ssl/key.pem \
|
||||
-e CATTLE_SYSTEM_DEFAULT_REGISTRY=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的默认私有镜像仓库
|
||||
-e CATTLE_SYSTEM_CATALOG=bundled \ # 使用打包的 Rancher System Chart
|
||||
--privileged
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
|
||||
:::note
|
||||
|
||||
如果你不想发送遥测数据,在首次登录时退出[遥测](../../../../faq/telemetry.md)。
|
||||
|
||||
:::
|
||||
|
||||
@@ -0,0 +1,193 @@
|
||||
---
|
||||
title: '1. 设置基础设施和私有镜像仓库'
|
||||
---
|
||||
|
||||
本文介绍如何在离线环境中,为 Rancher Management server 配置底层基础设施。你还将设置 Rancher 节点中必须可用的私有容器镜像仓库。
|
||||
|
||||
离线环境是 Rancher Server 离线安装或安装在防火墙后面的环境。
|
||||
|
||||
Rancher 安装在 K3s Kubernetes 集群、RKE Kubernetes 集群还是单个 Docker 容器上对应的基础设施设置会有所不同。如需了解各个安装方式的更多信息,请参见[本页](../../../../pages-for-subheaders/installation-and-upgrade.md)。
|
||||
|
||||
Rancher 可以安装在任何 Kubernetes 集群上。为了阅读方便,我们在下文中仍提供了 RKE 和 K3s Kubernetes 基础设施教程。
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="K3s">
|
||||
|
||||
为了实现高可用安装,我们建议设置以下的基础设施:
|
||||
|
||||
- **2 个 Linux 节点**:可以是你的云提供商中的虚拟机。
|
||||
- **1 个外部数据库**:用于存储集群数据。支持 PostgreSQL, MySQL 和 etcd。
|
||||
- **1 个负载均衡器**:用于将流量转发到这两个节点中。
|
||||
- **1 个 DNS 记录**:用于将 URL 映射到负载均衡器。此 DNS 记录将成为 Rancher Server 的 URL,下游集群需要可以访问到这个地址。
|
||||
- **私有镜像仓库**,用于将容器镜像分发到你的主机。
|
||||
|
||||
### 1. 配置 Linux 节点
|
||||
|
||||
这些主机会断开互联网链接,但需要能与你的私有镜像仓库连接。
|
||||
|
||||
请确保你的节点满足[操作系统,容器运行时,硬件和网络](../../../../pages-for-subheaders/installation-requirements.md)的常规要求。
|
||||
|
||||
如需获取配置 Linux 节点的示例,请参见[在 Amazon EC2 中配置节点](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md)的教程。
|
||||
|
||||
### 2. 配置外部数据库
|
||||
|
||||
K3s 与其他 Kubernetes 发行版不同,在于其支持使用 etcd 以外的数据库来运行 Kubernetes。该功能让 Kubernetes 运维更加灵活。你可以根据实际情况选择合适的数据库。
|
||||
|
||||
对于 K3s 高可用安装,你需要配置以下的其中一个数据库:
|
||||
|
||||
* [PostgreSQL](https://www.postgresql.org/)(10.7 和 11.5 已验证)
|
||||
* [MySQL](https://www.mysql.com/)(5.7 已验证)
|
||||
* [etcd](https://etcd.io/)(3.3.15 已验证)
|
||||
|
||||
在安装 Kubernetes 时,你需要传入 K3s 连接数据库的详细信息。
|
||||
|
||||
如需获取配置数据库示例,请参见[在 Amazon RDS 服务中配置 MySQL 数据库](../../../../how-to-guides/new-user-guides/infrastructure-setup/mysql-database-in-amazon-rds.md)的教程。
|
||||
|
||||
如需获取配置 K3s 集群数据库的所有可用选项,请参见 [K3s 官方文档](https://rancher.com/docs/k3s/latest/en/installation/datastore/)。
|
||||
|
||||
### 3. 配置负载均衡器
|
||||
|
||||
你还需要设置一个负载均衡器,来将流量重定向到两个节点上的 Rancher 副本。配置后,当单个节点不可用时,继续保障与 Rancher Management Server 的通信。
|
||||
|
||||
在后续步骤中配置 Kubernetes 时,K3s 工具会部署一个 Traefik Ingress Controller。该 Controller 将侦听 worker 节点的 80 端口和 443 端口,以响应发送给特定主机名的流量。
|
||||
|
||||
在安装 Rancher 后(也是在后续步骤中),Rancher 系统将创建一个 Ingress 资源。该 Ingress 通知 Traefik Ingress Controller 监听发往 Rancher 主机名的流量。Traefik Ingress Controller 在收到发往 Rancher 主机名的流量时,会将其转发到集群中正在运行的 Rancher Server Pod。
|
||||
|
||||
在你的实现中,你可以考虑是否需要使用 4 层或 7 层的负载均衡器:
|
||||
|
||||
- **4 层负载均衡器**:两种选择中较为简单的一种,它将 TCP 流量转发到你的节点中。我们建议使用 4 层负载均衡器,将流量从 TCP/80 端口和 TCP/443 端口转发到 Rancher Management 集群节点上。集群上的 Ingress Controller 会将 HTTP 流量重定向到 HTTPS,并在 TCP/443 端口上终止 SSL/TLS。Ingress Controller 会将流量转发到 Rancher deployment 中 Ingress Pod 的 TCP/80 端口。
|
||||
- **7 层负载均衡器**:相对比较复杂,但功能更全面。例如,与 Rancher 本身进行 TLS 终止相反,7 层负载均衡器能够在负载均衡器处处理 TLS 终止。如果你需要集中在基础设施中进行 TLS 终止,7 层负载均衡可能会很适合你。7 层负载均衡还能让你的负载均衡器基于 HTTP 属性(例如 cookie 等)做出决策,而 4 层负载均衡器则不能。如果你选择在 7 层负载均衡器上终止 SSL/TLS 流量,则在安装 Rancher 时(后续步骤)需要使用 `--set tls=external` 选项。详情请参见 [Rancher Helm Chart 选项](../../installation-references/helm-chart-options.md#外部-tls-终止)。
|
||||
|
||||
如需获取配置 NGINX 负载均衡器的示例,请参见[本页](../../../../how-to-guides/new-user-guides/infrastructure-setup/nginx-load-balancer.md)。
|
||||
|
||||
如需获取如何配置 Amazon ELB 网络负载均衡器的指南,请参见[本页](../../../../how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md)。
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
安装后,请勿将此负载均衡(例如 `local` 集群 Ingress)用于 Rancher 以外的应用。如果此 Ingress 与其他应用共享,在其他应用的 Ingress 配置重新加载后,可能导致 Rancher 出现 websocket 错误。我们建议把 `local` 集群专用给 Rancher,不要在集群内部署其他应用。
|
||||
|
||||
:::
|
||||
|
||||
### 4. 配置 DNS 记录
|
||||
|
||||
配置完负载均衡器后,你将需要创建 DNS 记录,以将流量发送到该负载均衡器。
|
||||
|
||||
根据你的环境,DNS 记录可以是指向负载均衡器 IP 的 A 记录,也可以是指向负载均衡器主机名的 CNAME。无论是哪种情况,请确保该记录是你要 Rancher 进行响应的主机名。
|
||||
|
||||
在安装 Rancher 时(后续步骤),你需要指定此主机名。请知悉,此主机名无法修改。请确保你设置的主机名是你想要的。
|
||||
|
||||
有关设置 DNS 记录以将域流量转发到 Amazon ELB 负载均衡器的指南,请参见 [AWS 官方文档](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)。
|
||||
|
||||
### 5. 配置私有镜像仓库
|
||||
|
||||
Rancher 支持使用私有镜像仓库进行离线安装。你必须有自己的私有镜像仓库或使用其他方式将容器镜像分发到主机。
|
||||
|
||||
在后续设置 K3s Kubernetes 集群时,你需要创建一个[私有镜像仓库配置文件](https://rancher.com/docs/k3s/latest/en/installation/private-registry/),其中包含此镜像仓库的信息。
|
||||
|
||||
如果你需要创建私有镜像仓库,请参阅相应运行时的文档:
|
||||
|
||||
* [Containerd](https://github.com/containerd/containerd/blob/main/docs/cri/config.md#registry-configuration).
|
||||
* [Nerdctl 命令和镜像仓库托管服务](https://github.com/containerd/nerdctl/blob/main/docs/registry.md)
|
||||
* [Docker](https://docs.docker.com/registry/deploying/).
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE">
|
||||
|
||||
如需在高可用 RKE 集群中安装 Rancher Management Server,我们建议配置以下基础设施:
|
||||
|
||||
- **3 个 Linux 节点**:可以是你的云提供商(例如 Amazon EC2,GCE 或 vSphere)中的虚拟机。
|
||||
- **1 个负载均衡器**:用于将前端流量转发到这三个节点中。
|
||||
- **1 个 DNS 记录**:用于将 URL 映射到负载均衡器。此 DNS 记录将成为 Rancher Server 的 URL,下游集群需要可以访问到这个地址。
|
||||
- **私有镜像仓库**,用于将容器镜像分发到你的主机。
|
||||
|
||||
这些节点必须位于同一个区域或数据中心。但是你可以把这些服务器放在不同的可用区。
|
||||
|
||||
### 为什么使用三个节点?
|
||||
|
||||
在 RKE 集群中,Rancher Server 的数据存储在 etcd 中。而这个 etcd 数据库在这三个节点上运行。
|
||||
|
||||
为了选举出大多数 etcd 节点认可的 etcd 集群 leader,etcd 数据库需要奇数个节点。如果 etcd 数据库无法选出 leader,etcd 可能会出现[脑裂(split brain)](https://www.quora.com/What-is-split-brain-in-distributed-systems)的问题,此时你需要使用备份恢复集群。如果三个 etcd 节点之一发生故障,其余两个节点可以选择一个 leader,因为它们是 etcd 节点总数的大多数部分。
|
||||
|
||||
### 1. 配置 Linux 节点
|
||||
|
||||
这些主机会断开互联网链接,但需要能与你的私有镜像仓库连接。
|
||||
|
||||
请确保你的节点满足[操作系统,容器运行时,硬件和网络](../../../../pages-for-subheaders/installation-requirements.md)的常规要求。
|
||||
|
||||
如需获取配置 Linux 节点的示例,请参见[在 Amazon EC2 中配置节点](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md)的教程。
|
||||
|
||||
### 2. 配置负载均衡器
|
||||
|
||||
你还需要设置一个负载均衡器,来将流量重定向到两个节点上的 Rancher 副本。配置后,当单个节点不可用时,继续保障与 Rancher Management Server 的通信。
|
||||
|
||||
在后续步骤中配置 Kubernetes 时,RKE 工具会部署一个 NGINX Ingress Controller。该 Controller 将侦听 worker 节点的 80 端口和 443 端口,以响应发送给特定主机名的流量。
|
||||
|
||||
在安装 Rancher 后(也是在后续步骤中),Rancher 系统将创建一个 Ingress 资源。该 Ingress 通知 NGINX Ingress Controller 监听发往 Rancher 主机名的流量。NGINX Ingress Controller 在收到发往 Rancher 主机名的流量时,会将其转发到集群中正在运行的 Rancher Server Pod。
|
||||
|
||||
在你的实现中,你可以考虑是否需要使用 4 层或 7 层的负载均衡器:
|
||||
|
||||
- **4 层负载均衡器**:两种选择中较为简单的一种,它将 TCP 流量转发到你的节点中。我们建议使用 4 层负载均衡器,将流量从 TCP/80 端口和 TCP/443 端口转发到 Rancher Management 集群节点上。集群上的 Ingress Controller 会将 HTTP 流量重定向到 HTTPS,并在 TCP/443 端口上终止 SSL/TLS。Ingress Controller 会将流量转发到 Rancher deployment 中 Ingress Pod 的 TCP/80 端口。
|
||||
- **7 层负载均衡器**:相对比较复杂,但功能更全面。例如,与 Rancher 本身进行 TLS 终止相反,7 层负载均衡器能够在负载均衡器处处理 TLS 终止。如果你需要集中在基础设施中进行 TLS 终止,7 层负载均衡可能会很适合你。7 层负载均衡还能让你的负载均衡器基于 HTTP 属性(例如 cookie 等)做出决策,而 4 层负载均衡器则不能。如果你选择在 7 层负载均衡器上终止 SSL/TLS 流量,则在安装 Rancher 时(后续步骤)需要使用 `--set tls=external` 选项。详情请参见 [Rancher Helm Chart 选项](../../installation-references/helm-chart-options.md#外部-tls-终止)。
|
||||
|
||||
如需获取配置 NGINX 负载均衡器的示例,请参见[本页](../../../../how-to-guides/new-user-guides/infrastructure-setup/nginx-load-balancer.md)。
|
||||
|
||||
如需获取如何配置 Amazon ELB 网络负载均衡器的指南,请参见[本页](../../../../how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md)。
|
||||
|
||||
:::caution
|
||||
|
||||
安装后,请勿将此负载均衡(例如 `local` 集群 Ingress)用于 Rancher 以外的应用。如果此 Ingress 与其他应用共享,在其他应用的 Ingress 配置重新加载后,可能导致 Rancher 出现 websocket 错误。我们建议把 `local` 集群专用给 Rancher,不要在集群内部署其他应用。
|
||||
|
||||
:::
|
||||
|
||||
### 3. 配置 DNS 记录
|
||||
|
||||
配置完负载均衡器后,你将需要创建 DNS 记录,以将流量发送到该负载均衡器。
|
||||
|
||||
根据你的环境,DNS 记录可以是指向负载均衡器 IP 的 A 记录,也可以是指向负载均衡器主机名的 CNAME。无论是哪种情况,请确保该记录是你要 Rancher 进行响应的主机名。
|
||||
|
||||
在安装 Rancher 时(后续步骤),你需要指定此主机名。请知悉,此主机名无法修改。请确保你设置的主机名是你想要的。
|
||||
|
||||
有关设置 DNS 记录以将域流量转发到 Amazon ELB 负载均衡器的指南,请参见 [AWS 官方文档](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)。
|
||||
|
||||
### 4. 配置私有镜像仓库
|
||||
|
||||
Rancher 支持使用安全的私有镜像仓库进行离线安装。你必须有自己的私有镜像仓库或使用其他方式将容器镜像分发到主机。
|
||||
|
||||
在后续设置 RKE Kubernetes 集群时,你需要创建一个[私有镜像仓库配置文件](https://rancher.com/docs/rke/latest/en/config-options/private-registries/),其中包含此镜像仓库的信息。
|
||||
|
||||
如果你需要创建私有镜像仓库,请参阅相应运行时的文档:
|
||||
|
||||
* [Containerd](https://github.com/containerd/containerd/blob/main/docs/cri/config.md#registry-configuration).
|
||||
* [Nerdctl 命令和镜像仓库托管服务](https://github.com/containerd/nerdctl/blob/main/docs/registry.md)
|
||||
* [Docker](https://docs.docker.com/registry/deploying/).
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Docker">
|
||||
|
||||
:::note 注意事项:
|
||||
|
||||
- Docker 安装适用于想要测试 Rancher 的用户。由于只有一个节点和一个 Docker 容器,因此如果该节点发生故障,你将丢失 Rancher Server 的所有数据。
|
||||
|
||||
- Rancher backup operator 可将 Rancher 从单个 Docker 容器迁移到高可用 Kubernetes 集群上。详情请参见[把 Rancher 迁移到新集群](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
|
||||
|
||||
:::
|
||||
|
||||
### 1. 配置 Linux 节点
|
||||
|
||||
此主机会断开互联网链接,但需要能与你的私有镜像仓库连接。
|
||||
|
||||
请确保你的节点满足[操作系统,容器,硬件和网络](../../../../pages-for-subheaders/installation-requirements.md)的常规安装要求。
|
||||
|
||||
如需获取配置 Linux 节点的示例,请参见[在 Amazon EC2 中配置节点](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md)的教程。
|
||||
|
||||
### 2. 配置私有 Docker 镜像仓库
|
||||
|
||||
Rancher 支持使用私有镜像仓库在堡垒服务器中进行离线安装。你必须有自己的私有镜像仓库或使用其他方式将容器镜像分发到主机。
|
||||
|
||||
如需获得创建私有镜像仓库的帮助,请参见 [Docker 官方文档](https://docs.docker.com/registry/)。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 后续操作
|
||||
[收集镜像并发布到你的私有镜像仓库](publish-images.md)
|
||||
@@ -0,0 +1,387 @@
|
||||
---
|
||||
title: '3. 安装 Kubernetes(Docker 安装请跳过)'
|
||||
---
|
||||
|
||||
:::note
|
||||
|
||||
如果你使用 Docker 在单个节点上安装 Rancher,请跳过本节。
|
||||
|
||||
:::
|
||||
|
||||
本文描述了如何根据 [Rancher Server 环境的最佳实践](../../../../reference-guides/rancher-manager-architecture/architecture-recommendations.md#kubernetes-安装环境)来安装 Kubernetes 集群。该集群需要专用于运行 Rancher Server。
|
||||
|
||||
Rancher 可以安装在任何 Kubernetes 集群上,包括托管的 Kubernetes。
|
||||
|
||||
在 RKE、RKE2 或 K3s 上离线安装 Kubernetes 集群的步骤如下所示:
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="K3s">
|
||||
|
||||
在本指南中,我们假设你已经在离线环境中创建了节点,并且在堡垒服务器上有一个安全的 Docker 私有镜像仓库。
|
||||
|
||||
### 安装概要
|
||||
|
||||
1. [准备镜像目录](#1-准备镜像目录)
|
||||
2. [创建镜像仓库 YAML](#2-创建镜像仓库-yaml)
|
||||
3. [安装 K3s](#3-安装-k3s)
|
||||
4. [保存并开始使用 kubeconfig 文件](#4-保存并开始使用-kubeconfig-文件)
|
||||
|
||||
### 1. 准备镜像目录
|
||||
从 [Releases](https://github.com/k3s-io/k3s/releases) 页面获取要运行的 K3s 版本的镜像 tar 文件。
|
||||
|
||||
在每个节点上启动 K3s 之前,将这个 tar 文件放在 `images` 目录中,例如:
|
||||
|
||||
```sh
|
||||
sudo mkdir -p /var/lib/rancher/k3s/agent/images/
|
||||
sudo cp ./k3s-airgap-images-$ARCH.tar /var/lib/rancher/k3s/agent/images/
|
||||
```
|
||||
|
||||
### 2. 创建镜像仓库 YAML
|
||||
把 `registries.yaml` 文件创建到 `/etc/rancher/k3s/registries.yaml` 中。此文件为 K3s 提供连接到你的私有镜像仓库的详细信息。
|
||||
|
||||
在加入必要信息之前,`registries.yaml` 文件是这样的:
|
||||
|
||||
```yaml
|
||||
---
|
||||
mirrors:
|
||||
customreg:
|
||||
endpoint:
|
||||
- "https://ip-to-server:5000"
|
||||
configs:
|
||||
customreg:
|
||||
auth:
|
||||
username: xxxxxx # 镜像仓库的用户名
|
||||
password: xxxxxx # 镜像仓库的密码
|
||||
tls:
|
||||
cert_file: <镜像仓库所用的证书文件路径>
|
||||
key_file: <镜像仓库所用的密钥文件路径>
|
||||
ca_file: <镜像仓库所用的 CA 文件路径>
|
||||
```
|
||||
|
||||
请注意,目前,K3s 仅支持安全的镜像仓库(带有自定义 CA 的 SSL)。
|
||||
|
||||
有关 K3s 的私有镜像仓库配置文件的详情,请参见 [K3s 官方文档](https://rancher.com/docs/k3s/latest/en/installation/private-registry/)。
|
||||
|
||||
### 3. 安装 K3s
|
||||
|
||||
Rancher 需要安装在支持的 Kubernetes 版本上。如需了解你使用的 Rancher 版本支持哪些 Kubernetes 版本,请参见 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/)。
|
||||
|
||||
如需指定 K3s(Kubernetes)版本,在运行 K3s 安装脚本时使用 `INSTALL_K3S_VERSION` 环境变量(例如 `INSTALL_K3S_VERSION="v1.24.10+k3s1"`)。
|
||||
|
||||
从 [Releases](https://github.com/k3s-io/k3s/releases) 页面获取 K3s 的二进制文件,该文件要匹配用于获取离线镜像的 tar 版本。
|
||||
访问 [K3s 安装脚本](https://get.k3s.io)以获取 K3s 的安装脚本。
|
||||
|
||||
将二进制文件放到每个节点的 `/usr/local/bin` 中。
|
||||
将安装脚本放在每个节点的任意位置,并将脚本命名为 `install.sh`。
|
||||
|
||||
在每个 Server 上安装 K3s:
|
||||
|
||||
```
|
||||
INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_VERSION=<VERSION> ./install.sh
|
||||
```
|
||||
|
||||
在每个 Agent 上安装 K3s:
|
||||
|
||||
```
|
||||
INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_VERSION=<VERSION> K3S_URL=https://<SERVER>:6443 K3S_TOKEN=<TOKEN> ./install.sh
|
||||
```
|
||||
|
||||
其中 `<SERVER>` 是 Server 的 IP 或有效 DNS,`<TOKEN>` 是可以在 `/var/lib/rancher/k3s/server/node-token` 中找到的 Server node-token。
|
||||
|
||||
:::note
|
||||
|
||||
K3s 自动为 kubelets 提供 `--resolv-conf` 标志,该标志可能对在离线环境中配置 DNS 有帮助。
|
||||
|
||||
:::
|
||||
|
||||
### 4. 保存并开始使用 kubeconfig 文件
|
||||
|
||||
在每个 Rancher Server 节点安装 K3s 时,会在每个节点的 `/etc/rancher/k3s/k3s.yaml` 中生成一个 `kubeconfig` 文件。该文件包含访问集群的凭证。请将该文件保存在安全的位置。
|
||||
|
||||
如要使用该 `kubeconfig` 文件:
|
||||
|
||||
1. 安装 Kubernetes 命令行工具 [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl)。
|
||||
2. 复制 `/etc/rancher/k3s/k3s.yaml` 文件并保存到本地主机的 `~/.kube/config` 目录上。
|
||||
3. 在 kubeconfig 文件中,`server` 的参数为 localhost。你需要将 `server` 配置为负载均衡器的 DNS,并指定端口 6443(通过端口 6443 访问 Kubernetes API Server,通过端口 80 和 443 访问 Rancher Server)。以下是一个 `k3s.yaml` 示例:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority-data: [CERTIFICATE-DATA]
|
||||
server: [LOAD-BALANCER-DNS]:6443 # 编辑此行
|
||||
name: default
|
||||
contexts:
|
||||
- context:
|
||||
cluster: default
|
||||
user: default
|
||||
name: default
|
||||
current-context: default
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: default
|
||||
user:
|
||||
password: [PASSWORD]
|
||||
username: admin
|
||||
```
|
||||
|
||||
**结果**:你可以开始使用 `kubectl` 来管理你的 K3s 集群。如果你有多个 `kubeconfig` 文件,在使用 `kubectl` 时,你可以传入文件路径来指定要使用的 `kubeconfig` 文件:
|
||||
|
||||
```
|
||||
kubectl --kubeconfig ~/.kube/config/k3s.yaml get pods --all-namespaces
|
||||
```
|
||||
|
||||
有关 `kubeconfig` 文件的详情,请参见 [K3s 官方文档](https://rancher.com/docs/k3s/latest/en/cluster-access/) 或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
|
||||
|
||||
### 升级注意事项
|
||||
|
||||
你可以通过以下方式完成离线环境的升级:
|
||||
|
||||
1. 从 [Releases](https://github.com/k3s-io/k3s/releases) 页面下载要升级的 K3s 版本的新离线镜像 tar 包。将 tar 文件放在每个节点上的 `/var/lib/rancher/k3s/agent/images/` 目录中。删除旧的 tar 文件。
|
||||
2. 复制并替换每个节点上 `/usr/local/bin` 中的旧 K3s 二进制文件。复制 [K3s 安装脚本](https://get.k3s.io)(因为脚本可能自上次版本发布以来已更改)。使用相同的环境变量再次运行脚本。
|
||||
3. 重启 K3s 服务(如果安装程序没有自动重启 K3s 的话)。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2">
|
||||
|
||||
在本指南中,我们假设你已经在离线环境中创建了节点,并且在堡垒服务器上有一个安全的 Docker 私有镜像仓库。
|
||||
|
||||
### 安装概要
|
||||
|
||||
1. [创建 RKE2 配置](#1-创建-rke2-配置)
|
||||
2. [创建镜像仓库 YAML](#2-创建镜像仓库-yaml)
|
||||
3. [安装 RKE2](#3-安装-rke2)
|
||||
4. [保存并开始使用 kubeconfig 文件](#4-保存并开始使用-kubeconfig-文件)
|
||||
|
||||
### 1. 创建 RKE2 配置
|
||||
把 config.yaml 文件创建到 `/etc/rancher/rke2/config.yaml` 中。这将包含创建高可用 RKE2 集群所需的所有配置选项。
|
||||
|
||||
第一台服务器的最低配置是:
|
||||
|
||||
```
|
||||
token: my-shared-secret
|
||||
tls-san:
|
||||
- loadbalancer-dns-domain.com
|
||||
```
|
||||
|
||||
其他服务器的配置文件应该包含相同的令牌,并让 RKE2 知道要连接到现有的第一台服务器:
|
||||
|
||||
```
|
||||
server: https://ip-of-first-server:9345
|
||||
token: my-shared-secret
|
||||
tls-san:
|
||||
- loadbalancer-dns-domain.com
|
||||
```
|
||||
|
||||
有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/ha)。
|
||||
|
||||
:::note
|
||||
|
||||
RKE2 自动为 kubelets 提供 `resolv-conf` 选项,该标志可能对在离线环境中配置 DNS 有帮助。
|
||||
|
||||
:::
|
||||
|
||||
### 2. 创建镜像仓库 YAML
|
||||
把 `registries.yaml` 文件创建到 `/etc/rancher/rke2/registries.yaml` 中。此文件为 RKE2 提供连接到你的私有镜像仓库的详细信息。
|
||||
|
||||
在加入必要信息之前,`registries.yaml` 文件是这样的:
|
||||
|
||||
```
|
||||
---
|
||||
mirrors:
|
||||
customreg:
|
||||
endpoint:
|
||||
- "https://ip-to-server:5000"
|
||||
configs:
|
||||
customreg:
|
||||
auth:
|
||||
username: xxxxxx # 镜像仓库的用户名
|
||||
password: xxxxxx # 镜像仓库的密码
|
||||
tls:
|
||||
cert_file: <镜像仓库所用的证书文件路径>
|
||||
key_file: <镜像仓库所用的密钥文件路径>
|
||||
ca_file: <镜像仓库所用的 CA 文件路径>
|
||||
```
|
||||
|
||||
有关 RKE2 的私有镜像仓库配置文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/install/containerd_registry_configuration)。
|
||||
|
||||
### 3. 安装 RKE2
|
||||
|
||||
Rancher 需要安装在支持的 Kubernetes 版本上。如需了解你使用的 Rancher 版本支持哪些 Kubernetes 版本,请参见[支持维护条款](https://rancher.com/support-maintenance-terms/)。
|
||||
|
||||
从 Release 页面下载安装脚本、rke2、rke2-images 和 sha256sum 存档,并将它们上传到每个服务器上的目录中:
|
||||
|
||||
```
|
||||
mkdir /tmp/rke2-artifacts && cd /tmp/rke2-artifacts/
|
||||
wget https://github.com/rancher/rke2/releases/download/v1.21.5%2Brke2r2/rke2-images.linux-amd64.tar.zst
|
||||
wget https://github.com/rancher/rke2/releases/download/v1.21.5%2Brke2r2/rke2.linux-amd64.tar.gz
|
||||
wget https://github.com/rancher/rke2/releases/download/v1.21.5%2Brke2r2/sha256sum-amd64.txt
|
||||
curl -sfL https://get.rke2.io --output install.sh
|
||||
```
|
||||
|
||||
接下来,使用每个服务器上的目录运行 install.sh,如下例所示:
|
||||
|
||||
```
|
||||
INSTALL_RKE2_ARTIFACT_PATH=/tmp/rke2-artifacts sh install.sh
|
||||
```
|
||||
|
||||
然后在所有服务器上启用并启动该服务:
|
||||
|
||||
``
|
||||
systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
``
|
||||
|
||||
有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/airgap)。
|
||||
|
||||
### 4. 保存并开始使用 kubeconfig 文件
|
||||
|
||||
在每个 Rancher Server 节点安装 RKE2 时,会在每个节点的 `/etc/rancher/rke2/rke2.yaml` 中生成一个 `kubeconfig` 文件。该文件包含访问集群的凭证。请将该文件保存在安全的位置。
|
||||
|
||||
如要使用该 `kubeconfig` 文件:
|
||||
|
||||
1. 安装 [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl)(Kubernetes 命令行工具)。
|
||||
2. 复制 `/etc/rancher/rke2/rke2.yaml` 文件并保存到本地主机的 `~/.kube/config` 目录上。
|
||||
3. 在 kubeconfig 文件中,`server` 的参数为 localhost。你需要将 `server` 配置为负载均衡器的 DNS,并指定端口 6443(通过端口 6443 访问 Kubernetes API Server,通过端口 80 和 443 访问 Rancher Server)。以下是一个 `rke2.yaml` 示例:
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority-data: [CERTIFICATE-DATA]
|
||||
server: [LOAD-BALANCER-DNS]:6443 # 编辑此行
|
||||
name: default
|
||||
contexts:
|
||||
- context:
|
||||
cluster: default
|
||||
user: default
|
||||
name: default
|
||||
current-context: default
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: default
|
||||
user:
|
||||
password: [PASSWORD]
|
||||
username: admin
|
||||
```
|
||||
|
||||
**结果**:你可以开始使用 `kubectl` 来管理你的 RKE2 集群。如果你有多个 `kubeconfig` 文件,在使用 `kubectl` 时,你可以传入文件路径来指定要使用的 `kubeconfig` 文件:
|
||||
|
||||
```
|
||||
kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
|
||||
```
|
||||
|
||||
有关 `kubeconfig` 文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/cluster_access)或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
|
||||
|
||||
### 升级注意事项
|
||||
|
||||
你可以通过以下方式完成离线环境的升级:
|
||||
|
||||
1. 从 [Releases](https://github.com/rancher/rke2/releases) 页面下载新的离线工件,并安装升级 RKE2 版本的脚本。
|
||||
2. 使用相同的环境变量再次运行脚本。
|
||||
3. 重启 RKE2 服务。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE">
|
||||
我们将使用 Rancher Kubernetes Engine (RKE) 创建一个 Kubernetes 集群。在启动 Kubernetes 集群之前,你需要安装 RKE 并创建 RKE 配置文件。
|
||||
|
||||
### 1. 安装 RKE
|
||||
|
||||
参照 [RKE 官方文档](https://rancher.com/docs/rke/latest/en/installation/)的说明安装 RKE。
|
||||
|
||||
:::note
|
||||
|
||||
你可以在 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/)中找到基于 Rancher 版本的 RKE 认证版本。
|
||||
|
||||
:::
|
||||
|
||||
### 2. 创建 RKE 配置文件
|
||||
|
||||
在可访问你 Linux 主机节点上的 22/TCP 端口和 6443/TCP 端口的系统上,使用以下示例创建一个名为 `rancher-cluster.yml` 的新文件。
|
||||
|
||||
该文件是 RKE 配置文件,用于配置你要部署 Rancher 的集群。
|
||||
|
||||
参考下方的 _RKE 选项_ 表格,修改代码示例中的参数。使用你创建的三个节点的 IP 地址或 DNS 名称。
|
||||
|
||||
:::tip
|
||||
|
||||
如需获取可用选项的详情,请参见 RKE [配置选项](https://rancher.com/docs/rke/latest/en/config-options/)。
|
||||
|
||||
:::
|
||||
|
||||
<figcaption>RKE 选项</figcaption>
|
||||
|
||||
| 选项 | 必填 | 描述 |
|
||||
| ------------------ | -------------------- | --------------------------------------------------------------------------------------- |
|
||||
| `address` | ✓ | 离线环境中节点的 DNS 或 IP 地址 |
|
||||
| `user` | ✓ | 可运行 Docker 命令的用户 |
|
||||
| `role` | ✓ | 分配给节点的 Kubernetes 角色列表 |
|
||||
| `internal_address` | 可选<sup>1</sup> | 用于集群内部流量的 DNS 或 IP 地址 |
|
||||
| `ssh_key_path` | | 用来验证节点的 SSH 私钥文件路径(默认值为 `~/.ssh/id_rsa`) |
|
||||
|
||||
> <sup>1</sup> 如果你想使用引用安全组或防火墙,某些服务(如 AWS EC2)要求设置 `internal_address`。
|
||||
|
||||
```yaml
|
||||
nodes:
|
||||
- address: 10.10.3.187 # 离线环境节点 IP
|
||||
internal_address: 172.31.7.22 # 节点内网 IP
|
||||
user: rancher
|
||||
role: ['controlplane', 'etcd', 'worker']
|
||||
ssh_key_path: /home/user/.ssh/id_rsa
|
||||
- address: 10.10.3.254 # 离线环境节点 IP
|
||||
internal_address: 172.31.13.132 # 节点内网 IP
|
||||
user: rancher
|
||||
role: ['controlplane', 'etcd', 'worker']
|
||||
ssh_key_path: /home/user/.ssh/id_rsa
|
||||
- address: 10.10.3.89 # 离线环境节点 IP
|
||||
internal_address: 172.31.3.216 # 节点内网 IP
|
||||
user: rancher
|
||||
role: ['controlplane', 'etcd', 'worker']
|
||||
ssh_key_path: /home/user/.ssh/id_rsa
|
||||
|
||||
private_registries:
|
||||
- url: <REGISTRY.YOURDOMAIN.COM:PORT> # 私有镜像仓库 URL
|
||||
user: rancher
|
||||
password: '*********'
|
||||
is_default: true
|
||||
```
|
||||
|
||||
### 3. 运行 RKE
|
||||
|
||||
配置 `rancher-cluster.yml`后,启动你的 Kubernetes 集群:
|
||||
|
||||
```
|
||||
rke up --config ./rancher-cluster.yml
|
||||
```
|
||||
|
||||
### 4. 保存你的文件
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
维护、排除问题和升级集群需要用到以下文件,请妥善保管这些文件:
|
||||
|
||||
:::
|
||||
|
||||
将以下文件的副本保存在安全位置:
|
||||
|
||||
- `rancher-cluster.yml`:RKE 集群配置文件。
|
||||
- `kube_config_cluster.yml`:集群的 [Kubeconfig 文件](https://rancher.com/docs/rke/latest/en/kubeconfig/)。该文件包含可完全访问集群的凭证。
|
||||
- `rancher-cluster.rkestate`:[Kubernetes 集群状态文件](https://rancher.com/docs/rke/latest/en/installation/#kubernetes-cluster-state)。该文件包含集群的当前状态,包括 RKE 配置以及证书<br/>。<br/>_Kubernetes 集群状态文件仅在使用 RKE 0.2.0 或更高版本时创建。_
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
:::note
|
||||
|
||||
后两个文件名中的 `rancher-cluster` 部分取决于你命名 RKE 集群配置文件的方式。
|
||||
|
||||
:::
|
||||
|
||||
### 故障排除
|
||||
|
||||
参见[故障排除](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)页面。
|
||||
|
||||
### 后续操作
|
||||
[安装 Rancher](install-rancher-ha.md)
|
||||
@@ -0,0 +1,246 @@
|
||||
---
|
||||
title: 4. 安装 Rancher
|
||||
---
|
||||
|
||||
本文介绍如何在高可用 Kubernetes 安装的离线环境部署 Rancher。离线环境可以是 Rancher Server 离线安装、防火墙后面或代理后面。
|
||||
|
||||
### Rancher 特权访问
|
||||
|
||||
当 Rancher Server 部署在 Docker 容器中时,容器内会安装一个本地 Kubernetes 集群供 Rancher 使用。为 Rancher 的很多功能都是以 deployment 的方式运行的,而在容器内运行容器是需要特权模式的,因此你需要在安装 Rancher 时添加 `--privileged` 选项。
|
||||
|
||||
## Docker 说明
|
||||
|
||||
如果你想使用 Docker 命令进行离线安装,请跳过本页的剩余部分,并按照[此页](docker-install-commands.md)进行操作。
|
||||
|
||||
## Kubernetes 说明
|
||||
|
||||
我们建议在 Kubernetes 集群上安装 Rancher。高可用的 Kubernetes 安装的情况下,一个 Kubernetes 集群包含三个运行 Rancher Server 组件的节点。持久层(etcd)也在这三个节点上进行复制,以便在其中一个节点发生故障时提供冗余和数据复制。
|
||||
|
||||
### 1. 添加 Helm Chart 仓库
|
||||
|
||||
从可以访问互联网的系统中,获取最新的 Helm Chart,然后将 manifest 复制到可访问 Rancher Server 集群的系统中。
|
||||
|
||||
1. 如果你还没有安装 `helm`,请在可访问互联网的工作站上进行本地安装。注意:参考 [Helm 版本要求](../../resources/helm-version-requirements.md)选择 Helm 版本来安装 Rancher。
|
||||
|
||||
2. 执行 `helm repo add` 命令,以添加包含安装 Rancher 的 Chart 的 Helm Chart 仓库。有关如何选择仓库,以及哪个仓库最适合你的用例,请参见[选择 Rancher 版本](../../resources/choose-a-rancher-version.md)。
|
||||
- Latest:建议用于试用最新功能
|
||||
```
|
||||
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
|
||||
```
|
||||
- Stable:建议用于生产环境
|
||||
```
|
||||
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
|
||||
```
|
||||
- Alpha:即将发布的实验性预览。
|
||||
```
|
||||
helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha
|
||||
```
|
||||
注意:不支持升级到 Alpha 版、从 Alpha 版升级或在 Alpha 版之间升级。
|
||||
|
||||
3. 获取最新的 Rancher Chart。此操作将获取 Chart 并将其作为 `.tgz` 文件保存在当前目录中。
|
||||
```plain
|
||||
helm fetch rancher-<CHART_REPO>/rancher
|
||||
```
|
||||
|
||||
如需下载特定的 Rancher 版本,你可以用 Helm `--version` 参数指定版本,如下:
|
||||
```plain
|
||||
helm fetch rancher-stable/rancher --version=v2.4.8
|
||||
```
|
||||
|
||||
### 2. 选择 SSL 配置
|
||||
|
||||
Rancher Server 默认设计为安全的,并且需要 SSL/TLS 配置。
|
||||
|
||||
如果你在离线的 Kubernetes 集群中安装 Rancher,我们建议使用以下两种证书生成方式。
|
||||
|
||||
:::note
|
||||
|
||||
如果你想在外部终止 SSL/TLS,请参见[外部负载均衡器的 TLS 终止](../../installation-references/helm-chart-options.md#外部-tls-终止)。
|
||||
|
||||
:::
|
||||
|
||||
| 配置 | Chart 选项 | 描述 | 是否需要 cert-manager |
|
||||
| ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
|
||||
| Rancher 生成的自签名证书 | `ingress.tls.source=rancher` | 使用 Rancher 生成的 CA 签发的自签名证书。此项是**默认选项**。在渲染 Helm 模板的时候不需要传递此项。 | 是 |
|
||||
| 你已有的证书 | `ingress.tls.source=secret` | 通过创建 Kubernetes 密文使用你自己的证书文件。<br />在渲染 Rancher Helm 模板时必须传递此选项。 | 否 |
|
||||
|
||||
### 离线安装的 Helm Chart 选项
|
||||
|
||||
在配置 Rancher Helm 模板时,Helm Chart 中有几个专为离线安装设计的选项,如下表:
|
||||
|
||||
| Chart 选项 | Chart 值 | 描述 |
|
||||
| ----------------------- | -------------------------------- | ---- |
|
||||
| `certmanager.version` | `<version>` | 根据运行的 cert-manager 版本配置适当的 Rancher TLS 颁发者。 |
|
||||
| `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | 将 Rancher Server 配置成在配置集群时,始终从私有镜像仓库中拉取镜像。 |
|
||||
| `useBundledSystemChart` | `true` | 配置 Rancher Server 使用打包的 Helm System Chart 副本。[system charts](https://github.com/rancher/system-charts) 仓库包含所有 Monitoring,Logging,告警和全局 DNS 等功能所需的应用商店项目。这些 [Helm Chart](https://github.com/rancher/system-charts) 位于 GitHub 中。但是由于你处在离线环境,因此使用 Rancher 内置的 Chart 会比设置 Git mirror 容易得多。 |
|
||||
|
||||
### 3. 获取 Cert-Manager Chart
|
||||
|
||||
根据你在[2:选择 SSL 配置](#2-选择-ssl-配置)中的选择,完成以下步骤之一:
|
||||
|
||||
#### 选项 A:使用 Rancher 默认的自签名证书
|
||||
|
||||
默认情况下,Rancher 会生成一个 CA 并使用 cert-manager 颁发证书以访问 Rancher Server 界面。
|
||||
|
||||
:::note
|
||||
|
||||
由于 cert-manager 的最新改动,你需要升级 cert-manager 版本。如果你需要升级 Rancher 并使用低于 0.11.0 的 cert-manager 版本,请参见 [cert-manager 升级文档](../../resources/upgrade-cert-manager.md)。
|
||||
|
||||
:::
|
||||
|
||||
##### 1. 添加 cert-manager 仓库
|
||||
|
||||
在可以连接互联网的系统中,将 cert-manager 仓库添加到 Helm:
|
||||
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
```
|
||||
|
||||
##### 2. 获取 cert-manager Chart
|
||||
|
||||
从 [Helm Chart 仓库](https://artifacthub.io/packages/helm/cert-manager/cert-manager)中获取最新可用的 cert-manager Chart:
|
||||
|
||||
```plain
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
```
|
||||
|
||||
##### 3. 检索 Cert-Manager CRD
|
||||
|
||||
为 cert-manager 下载所需的 CRD 文件:
|
||||
```plain
|
||||
curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
```
|
||||
|
||||
### 4. 安装 Rancher
|
||||
|
||||
将获取的 Chart 复制到有权访问 Rancher Server 集群的系统以完成安装。
|
||||
|
||||
##### 1. 安装 Cert-Manager
|
||||
|
||||
使用要用于安装 Chart 的选项来安装 cert-manager。记住要设置 `image.repository` 选项,以从你的私有镜像仓库拉取镜像。此操作会创建一个包含 Kubernetes manifest 文件的 `cert-manager` 目录。
|
||||
|
||||
:::note
|
||||
|
||||
要查看自定义 cert-manager 安装的选项(包括集群使用 PodSecurityPolicies 的情况),请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
|
||||
|
||||
:::
|
||||
|
||||
<details id="install-cert-manager">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
如果你使用自签名证书,安装 cert-manager:
|
||||
|
||||
1. 为 cert-manager 创建命名空间:
|
||||
|
||||
```plain
|
||||
kubectl create namespace cert-manager
|
||||
```
|
||||
|
||||
2. 创建 cert-manager CustomResourceDefinition (CRD)。
|
||||
|
||||
```plain
|
||||
kubectl apply -f cert-manager/cert-manager-crd.yaml
|
||||
```
|
||||
|
||||
3. 安装 cert-manager。
|
||||
|
||||
```plain
|
||||
helm install cert-manager ./cert-manager-v1.11.0.tgz \
|
||||
--namespace cert-manager \
|
||||
--set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller \
|
||||
--set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook \
|
||||
--set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector \
|
||||
--set startupapicheck.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-ctl
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
##### 2. 安装 Rancher
|
||||
首先,参见[添加 TLS 密文](../../resources/add-tls-secrets.md)发布证书文件,以便 Rancher 和 Ingress Controller 可以使用它们。
|
||||
|
||||
然后,使用 kubectl 为 Rancher 创建命名空间:
|
||||
|
||||
```plain
|
||||
kubectl create namespace cattle-system
|
||||
```
|
||||
|
||||
然后安装 Rancher,并声明你选择的选项。参考下表来替换每个占位符。Rancher 需要配置为使用私有镜像仓库,以便配置所有 Rancher 启动的 Kubernetes 集群或 Rancher 工具。
|
||||
|
||||
对于 Kubernetes v1.25 或更高版本,使用 Rancher v2.7.2-v2.7.4 时,将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说,这不是必需的,但你仍然可以手动设置该选项。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
------------|-------------
|
||||
| `<VERSION>` | 输出压缩包的版本号。 |
|
||||
| `<RANCHER.YOURDOMAIN.COM>` | 指向负载均衡器的 DNS 名称。 |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 你的私有镜像仓库的 DNS 名称。 |
|
||||
| `<CERTMANAGER_VERSION>` | 在 K8s 集群上运行的 cert-manager 版本。 |
|
||||
|
||||
```plain
|
||||
helm install rancher ./rancher-<VERSION>.tgz \
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set certmanager.version=<CERTMANAGER_VERSION> \
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的默认私有镜像仓库
|
||||
--set useBundledSystemChart=true # 使用打包的 Rancher System Chart
|
||||
```
|
||||
|
||||
**可选**:如需安装特定的 Rancher 版本,设置`rancherImageTag` 的值,例如:`--set rancherImageTag=v2.5.8`
|
||||
|
||||
#### 选项 B:使用 Kubernetes 密文从文件中获取证书
|
||||
|
||||
##### 1. 创建密文
|
||||
|
||||
使用你自己的证书来创建 Kubernetes 密文,以供 Rancher 使用。证书的 common name 需要与以下命令中的 `hostname` 选项匹配,否则 Ingress Controller 将无法为 Rancher 配置站点。
|
||||
|
||||
##### 2. 安装 Rancher
|
||||
|
||||
安装 Rancher,并声明你选择的选项。参考下表来替换每个占位符。Rancher 需要配置为使用私有镜像仓库,以便配置所有 Rancher 启动的 Kubernetes 集群或 Rancher 工具。
|
||||
|
||||
对于 Kubernetes v1.25 或更高版本,使用 Rancher v2.7.2-v2.7.4 时,将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说,这不是必需的,但你仍然可以手动设置该选项。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
| -------------------------------- | ----------------------------------------------- |
|
||||
| `<VERSION>` | 输出压缩包的版本号。 |
|
||||
| `<RANCHER.YOURDOMAIN.COM>` | 指向负载均衡器的 DNS 名称。 |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 你的私有镜像仓库的 DNS 名称。 |
|
||||
|
||||
```plain
|
||||
helm install rancher ./rancher-<VERSION>.tgz \
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
--set ingress.tls.source=secret \
|
||||
--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的默认私有镜像仓库
|
||||
--set useBundledSystemChart=true # 使用打包的 Rancher System Chart
|
||||
```
|
||||
|
||||
如果你使用的是私有 CA 签名的证书,请在 `--set ingress.tls.source=secret` 后加上 `--set privateCA=true`:
|
||||
|
||||
```plain
|
||||
helm install rancher ./rancher-<VERSION>.tgz \
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
--set ingress.tls.source=secret \
|
||||
--set privateCA=true \
|
||||
--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的默认私有镜像仓库
|
||||
--set useBundledSystemChart=true # 使用打包的 Rancher System Chart
|
||||
```
|
||||
|
||||
|
||||
安装已完成。
|
||||
:::caution
|
||||
|
||||
如果你不想发送遥测数据,在首次登录时退出[遥测](../../../../faq/telemetry.md)。如果在离线安装的环境中让这个功能处于 active 状态,socket 可能无法打开。
|
||||
|
||||
:::
|
||||
|
||||
## 其他资源
|
||||
|
||||
以下资源可能对安装 Rancher 有帮助:
|
||||
|
||||
- [Rancher Helm Chart 选项](../../installation-references/helm-chart-options.md)
|
||||
- [添加 TLS 密文](../../resources/add-tls-secrets.md)
|
||||
- [Rancher Kubernetes 安装的故障排除](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)
|
||||
@@ -0,0 +1,305 @@
|
||||
---
|
||||
title: '2. 收集镜像并发布到私有仓库'
|
||||
---
|
||||
|
||||
本文介绍如何配置私有镜像仓库,以便在安装 Rancher 时,Rancher 可以从此私有镜像仓库中拉取所需的镜像。
|
||||
|
||||
默认情况下,所有用于[配置 Kubernetes 集群](../../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)或启动 Rancher 中的工具(如监控,流水线,告警等)的镜像都是从 Docker Hub 中拉取的。在 Rancher 的离线安装中,你需要一个私有仓库,该仓库位于你的 Rancher Server 中某个可访问的位置。然后,你可加载该存有所有镜像的镜像仓库。
|
||||
|
||||
使用 Docker 安装 Rancher,和把 Rancher 安装到 Kubernetes 集群,其对应的推送镜像到私有镜像仓库步骤是一样的。
|
||||
|
||||
你使用 Rancher 配置的下游集群是否有运行 Windows 的节点,决定了本文涉及的步骤。我们提供的推送镜像到私有镜像仓库步骤,是基于假设 Rancher 仅配置运行 Linux 节点的下游 Kubernetes 集群的。但是,如果你计划[在下游 Kubernetes 集群中使用 Windows 节点](../../../../pages-for-subheaders/use-windows-clusters.md),我们有单独的文档来介绍如何为需要的镜像提供支持。
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
你必须有一个可用的[私有镜像仓库](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)。
|
||||
|
||||
如果镜像仓库有证书,请参见 [K3s 文档中心](https://rancher.com/docs/k3s/latest/en/installation/private-registry/)了解添加私有镜像仓库的详情。证书和镜像仓库配置文件均需要挂载到 Rancher 容器中。
|
||||
|
||||
:::
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="仅包含 Linux 的集群">
|
||||
|
||||
如果 Rancher Server 用于配置仅有 Linux 节点的集群,请按以下步骤将你的镜像推送到私有镜像仓库。
|
||||
|
||||
1. [找到你的 Rancher 版本所需的资源](#1-找到你的-rancher-版本所需的资源)
|
||||
2. [收集 cert-manager 镜像](#2-收集-cert-manager-镜像)(除非你使用自己的证书,或在负载均衡器上终止 TLS)
|
||||
3. [把镜像保存到你的工作站](#3-将镜像保存到你的工作站中)
|
||||
4. [推送镜像到私有镜像仓库](#4-推送镜像到私有镜像仓库)
|
||||
|
||||
### 先决条件
|
||||
|
||||
这些步骤要求你使用一个 Linux 工作站,该工作站需要可访问互联网和你的私有镜像仓库,且至少有 20GB 的可用磁盘空间。
|
||||
|
||||
如果你的主机架构是 ARM64,镜像仓库必须支持 Manifest。这是因为从 2020 年 4 月开始, Amazon Elastic Container Registry 已经不再支持 Manifest。
|
||||
|
||||
### 1. 找到你的 Rancher 版本所需的资源
|
||||
|
||||
1. 访问 Rancher 的[发布说明](https://github.com/rancher/rancher/releases)页面,找到你需要安装的 Rancher v2.x.x 版本,然后点击 **Assets**。注意不要使用带有 `rc` 或 `Pre-release` 标记的版本,因为这些版本在生产环境中不够稳定。
|
||||
|
||||
2. 从你所需版本的 **Assets** 处下载以下文件,这些文件是在离线环境中安装 Rancher 所必须的:
|
||||
|
||||
| Release 文件 | 描述 |
|
||||
| ---------------- | -------------- |
|
||||
| `rancher-images.txt` | 此文件包含安装 Rancher、配置集群和用户 Rancher 工具所需的镜像。 |
|
||||
| `rancher-save-images.sh` | 该脚本从 Docker Hub 中拉取在文件 `rancher-images.txt` 中记录的所有镜像,并把这些镜像保存为 `rancher-images.tar.gz`。 |
|
||||
| `rancher-load-images.sh` | 该脚本从 `rancher-images.tar.gz` 文件中加载镜像,并把镜像推送到你的私有镜像仓库。 |
|
||||
|
||||
### 2. 收集 cert-manager 镜像
|
||||
|
||||
:::note
|
||||
|
||||
如果你使用自己的证书,或要在外部负载均衡器上终止 TLS,请跳过此步骤。
|
||||
|
||||
:::
|
||||
|
||||
在 Kubernetes 安装中,如果你使用的是 Rancher 默认的自签名 TLS 证书,则必须将 [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) 镜像添加到 `rancher-images.txt` 文件中。
|
||||
|
||||
1. 获取最新的 `cert-manager` Helm Chart,并解析模板以获取镜像的详情信息:
|
||||
|
||||
:::note
|
||||
|
||||
由于 cert-manager 的最新改动,你需要升级 cert-manager 版本。如果你需要升级 Rancher 并使用低于 0.12.0 的 cert-manager 版本,请参见[升级文档](../../resources/upgrade-cert-manager.md)。
|
||||
|
||||
:::
|
||||
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
|
||||
```
|
||||
|
||||
2. 对镜像列表进行排序和唯一化,以去除重复的镜像源:
|
||||
|
||||
```plain
|
||||
sort -u rancher-images.txt -o rancher-images.txt
|
||||
```
|
||||
|
||||
### 3. 将镜像保存到你的工作站中
|
||||
|
||||
1. 为 `rancher-save-images.sh` 文件添加可执行权限:
|
||||
```
|
||||
chmod +x rancher-save-images.sh
|
||||
```
|
||||
|
||||
1. 使用 `rancher-images.txt` 镜像列表执行 `rancher-save-images.sh` 脚本,以创建包含所有所需镜像的压缩包:
|
||||
```plain
|
||||
./rancher-save-images.sh --image-list ./rancher-images.txt
|
||||
```
|
||||
**结果**:Docker 开始拉取用于离线安装的镜像。请耐心等待。这个过程需要几分钟。完成时,你的当前目录会输出名为 `rancher-images.tar.gz` 的压缩包。请确认输出文件是否存在。
|
||||
|
||||
### 4. 推送镜像到私有镜像仓库
|
||||
|
||||
下一步,你将使用脚本将 `rancher-images.tar.gz` 中的镜像移动到你的私有镜像仓库,以方便加载镜像。
|
||||
|
||||
使用脚本将 `rancher-images.tar.gz` 中的镜像移动到你的私有镜像仓库,以方便加载镜像。
|
||||
|
||||
`rancher-images.txt` 需要位于工作站中运行 `rancher-load-images.sh` 脚本的同一目录中。`rancher-images.tar.gz` 也需要位于同一目录中。
|
||||
|
||||
1. 登录到你的私有镜像仓库:
|
||||
```plain
|
||||
docker login <REGISTRY.YOURDOMAIN.COM:PORT>
|
||||
```
|
||||
1. 为 `rancher-load-images.sh` 添加可执行权限:
|
||||
```
|
||||
chmod +x rancher-load-images.sh
|
||||
```
|
||||
|
||||
1. 使用 `rancher-load-images.sh` 脚本来提取,标记和推送 `rancher-images.txt` 及 `rancher-images.tar.gz` 到你的私有镜像仓库:
|
||||
```plain
|
||||
./rancher-load-images.sh --image-list ./rancher-images.txt --registry <REGISTRY.YOURDOMAIN.COM:PORT>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Linux 和 Windows 集群">
|
||||
|
||||
如果你的 Rancher Server 将用于配置 Linux 和 Windows 集群,你需要执行不同的步骤,来将 Windows 镜像和 Linux 镜像推送到你的私有镜像仓库。由于 Windows 集群同时包含 Linux 和 Windows 节点,因此推送到私有镜像仓库的 Linux 镜像是 Manifest。
|
||||
|
||||
## Windows 步骤
|
||||
|
||||
从 Windows Server 工作站中收集和推送 Windows 镜像。
|
||||
|
||||
1. <a href="#windows-1">找到你的 Rancher 版本所需的资源</a>
|
||||
2. <a href="#windows-2">将镜像保存到你的 Windows Server 工作站</a>
|
||||
3. <a href="#windows-3">准备 Docker daemon</a>
|
||||
4. <a href="#windows-4">推送镜像到私有镜像仓库</a>
|
||||
|
||||
### 先决条件
|
||||
|
||||
以下步骤假设你使用 Windows Server 1809 工作站,该工作站能访问网络及你的私有镜像仓库,且至少拥有 50GB 的磁盘空间。
|
||||
|
||||
工作站必须安装 Docker 18.02+ 版本以提供 manifest 支持。Manifest 支持是配置 Windows 集群所必须的。
|
||||
|
||||
你的镜像仓库必须支持 Manifest。这是因为从 2020 年 4 月开始, Amazon Elastic Container Registry 已经不再支持 Manifest。
|
||||
|
||||
<a name="windows-1"></a>
|
||||
|
||||
### 1. 找到你的 Rancher 版本所需的资源
|
||||
|
||||
1. 访问 Rancher 的[发布说明](https://github.com/rancher/rancher/releases)页面,找到你需要安装的 Rancher v2.x.x 版本。不要下载带有 `rc` 或 `Pre-release` 标记的版本,因为这些版本在生产环境中不够稳定。
|
||||
|
||||
2. 从你所需版本的 **Assets** 处下载以下文件:
|
||||
|
||||
| Release 文件 | 描述 |
|
||||
|----------------------------|------------------|
|
||||
| `rancher-windows-images.txt` | 此文件包含配置 Windows 集群所需的 Windows 镜像。 |
|
||||
| `rancher-save-images.ps1` | 该脚本从 Docker Hub 中拉取在文件 `rancher-windows-images.txt` 中记录的所有镜像,并把这些镜像保存为 `rancher-windows-images.tar.gz`。 |
|
||||
| `rancher-load-images.ps1` | 该脚本从 `rancher-windows-images.tar.gz` 文件中加载镜像,并把镜像推送到你的私有镜像仓库。 |
|
||||
|
||||
<a name="windows-2"></a>
|
||||
|
||||
### 2. 将镜像保存到你的 Windows Server 工作站
|
||||
|
||||
1. 在 `powershell` 中,进入上一步下载的文件所在的目录。
|
||||
|
||||
1. 运行 `rancher-save-images.ps1` 以创建包含所有所需镜像的压缩包:
|
||||
```plain
|
||||
./rancher-save-images.ps1
|
||||
```
|
||||
|
||||
**结果**:Docker 开始拉取用于离线安装的镜像。请耐心等待。这个过程需要几分钟。完成时,你的当前目录会输出名为 `rancher-windows-images.tar.gz` 的压缩包。请确认输出文件是否存在。
|
||||
|
||||
<a name="windows-3"></a>
|
||||
|
||||
### 3. 准备 Docker daemon
|
||||
|
||||
将你的私有镜像仓库地址尾附到 Docker daemon (`C:\\ProgramData\\Docker\\config\\daemon.json`) 的 `allow-nondistributable-artifacts` 配置字段中。Windows 镜像的基础镜像是由 `mcr.microsoft.com` 镜像仓库维护的,而 Docker Hub 中缺少 Microsoft 镜像仓库层,且需要将其拉入私有镜像仓库,因此这一步骤是必须的。
|
||||
|
||||
```json
|
||||
{
|
||||
...
|
||||
"allow-nondistributable-artifacts": [
|
||||
...
|
||||
"<REGISTRY.YOURDOMAIN.COM:PORT>"
|
||||
]
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
<a name="windows-4"></a>
|
||||
|
||||
### 4. 推送镜像到私有镜像仓库
|
||||
|
||||
使用脚本将 `rancher-windows-images.tar.gz` 中的镜像移动到你的私有镜像仓库,以方便加载镜像。
|
||||
|
||||
`rancher-windows-images.txt` 需要位于工作站中运行 `rancher-load-images.ps1` 脚本的同一目录中。`rancher-windows-images.tar.gz` 也需要位于同一目录中。
|
||||
|
||||
1. 使用 `powershell` 登录到你的私有镜像仓库:
|
||||
```plain
|
||||
docker login <REGISTRY.YOURDOMAIN.COM:PORT>
|
||||
```
|
||||
|
||||
1. 在 `powershell` 中,使用 `rancher-load-images.ps1` 脚本来提取,标记和推送 `rancher-images.tar.gz` 中的镜像到你的私有镜像仓库:
|
||||
```plain
|
||||
./rancher-load-images.ps1 --registry <REGISTRY.YOURDOMAIN.COM:PORT>
|
||||
```
|
||||
|
||||
## Linux 步骤
|
||||
|
||||
Linux 镜像需要在 Linux 主机上收集和推送,但是你必须先将 Windows 镜像推送到私有镜像仓库,然后再推送 Linux 镜像。由于被推送的 Linux 镜像实际上是支持 Windows 和 Linux 镜像的 manifest,因此涉及的步骤不同于只包含 Linux 节点的集群。
|
||||
|
||||
1. <a href="#linux-1">找到你的 Rancher 版本所需的资源</a>
|
||||
2. <a href="#linux-2">收集所有需要的镜像</a>
|
||||
3. <a href="#linux-3">将镜像保存到你的 Linux 工作站中</a>
|
||||
4. <a href="#linux-4">推送镜像到私有镜像仓库</a>
|
||||
|
||||
### 先决条件
|
||||
|
||||
在将 Linux 镜像推送到私有镜像仓库之前,你必须先把 Windows 镜像推送到私有镜像仓库。如果你已经把 Linux 镜像推送到私有镜像仓库,则需要再次按照说明重新推送,因为它们需要发布支持 Windows 和 Linux 镜像的 manifest。
|
||||
|
||||
这些步骤要求你使用一个 Linux 工作站,该工作站需要可访问互联网和你的私有镜像仓库,且至少有 20GB 的可用磁盘空间。
|
||||
|
||||
工作站必须安装 Docker 18.02+ 版本以提供 manifest 支持。Manifest 支持是配置 Windows 集群所必须的。
|
||||
|
||||
<a name="linux-1"></a>
|
||||
|
||||
### 1. 找到你的 Rancher 版本所需的资源
|
||||
|
||||
1. 访问 Rancher 的[发布说明](https://github.com/rancher/rancher/releases)页面,找到你需要安装的 Rancher v2.x.x 版本。不要下载带有 `rc` 或 `Pre-release` 标记的版本,因为这些版本在生产环境中不够稳定。点击 **Assets**。
|
||||
|
||||
2. 从你所需版本的 **Assets** 处下载以下文件:
|
||||
|
||||
| Release 文件 | 描述 |
|
||||
|----------------------------| -------------------------- |
|
||||
| `rancher-images.txt` | 此文件包含安装 Rancher、配置集群和用户 Rancher 工具所需的镜像。 |
|
||||
| `rancher-windows-images.txt` | 此文件包含配置 Windows 集群所需的镜像。 |
|
||||
| `rancher-save-images.sh` | 该脚本从 Docker Hub 中拉取在文件 `rancher-images.txt` 中记录的所有镜像,并把这些镜像保存为 `rancher-images.tar.gz`。 |
|
||||
| `rancher-load-images.sh` | 该脚本从 `rancher-images.tar.gz` 文件中加载镜像,并把镜像推送到你的私有镜像仓库。 |
|
||||
|
||||
<a name="linux-2"></a>
|
||||
|
||||
### 2. 收集所有需要的镜像
|
||||
|
||||
**在 Kubernetes 安装中,如果你使用的是 Rancher 默认的自签名 TLS 证书**,则必须将 [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) 镜像添加到 `rancher-images.txt` 文件中。如果你使用自己的证书,则可跳过此步骤。
|
||||
|
||||
|
||||
1. 获取最新的 `cert-manager` Helm Chart,并解析模板以获取镜像的详情信息:
|
||||
|
||||
:::note
|
||||
|
||||
由于 cert-manager 的最新改动,你需要升级 cert-manager 版本。如果你需要升级 Rancher 并使用低于 0.12.0 的 cert-manager 版本,请参见[升级文档](../../resources/upgrade-cert-manager.md)。
|
||||
|
||||
:::
|
||||
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
|
||||
```
|
||||
|
||||
2. 对镜像列表进行排序和唯一化,以去除重复的镜像源:
|
||||
```plain
|
||||
sort -u rancher-images.txt -o rancher-images.txt
|
||||
```
|
||||
|
||||
<a name="linux-3"></a>
|
||||
|
||||
### 3. 将镜像保存到你的工作站中
|
||||
|
||||
1. 为 `rancher-save-images.sh` 文件添加可执行权限:
|
||||
```
|
||||
chmod +x rancher-save-images.sh
|
||||
```
|
||||
|
||||
1. 使用 `rancher-images.txt` 镜像列表执行 `rancher-save-images.sh` 脚本,以创建包含所有所需镜像的压缩包:
|
||||
```plain
|
||||
./rancher-save-images.sh --image-list ./rancher-images.txt
|
||||
```
|
||||
|
||||
**结果**:Docker 开始拉取用于离线安装的镜像。请耐心等待。这个过程需要几分钟。完成时,你的当前目录会输出名为 `rancher-images.tar.gz` 的压缩包。请确认输出文件是否存在。
|
||||
|
||||
<a name="linux-4"></a>
|
||||
|
||||
### 4. 推送镜像到私有镜像仓库
|
||||
|
||||
使用 `rancher-load-images.sh script` 脚本将 `rancher-images.tar.gz` 中的镜像移动到你的私有镜像仓库,以方便加载镜像。
|
||||
|
||||
镜像列表,即 `rancher-images.txt` 或 `rancher-windows-images.txt` 需要位于工作站中运行 `rancher-load-images.sh` 脚本的同一目录中。`rancher-images.tar.gz` 也需要位于同一目录中。
|
||||
|
||||
1. 登录到你的私有镜像仓库:
|
||||
```plain
|
||||
docker login <REGISTRY.YOURDOMAIN.COM:PORT>
|
||||
```
|
||||
|
||||
1. 为 `rancher-load-images.sh` 添加可执行权限:
|
||||
```
|
||||
chmod +x rancher-load-images.sh
|
||||
```
|
||||
|
||||
1. 使用 `rancher-load-images.sh` 脚本来提取,标记和推送 `rancher-images.tar.gz` 中的镜像到你的私有镜像仓库:
|
||||
|
||||
```plain
|
||||
./rancher-load-images.sh --image-list ./rancher-images.txt \
|
||||
--windows-image-list ./rancher-windows-images.txt \
|
||||
--registry <REGISTRY.YOURDOMAIN.COM:PORT>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### [Kubernetes 安装的后续步骤 - 启动 Kubernetes 集群](install-kubernetes.md)
|
||||
|
||||
### [Docker 安装的后续步骤 - 安装 Rancher](install-rancher-ha.md)
|
||||
@@ -0,0 +1,249 @@
|
||||
---
|
||||
title: '2. 安装 Kubernetes'
|
||||
---
|
||||
|
||||
基础设施配置好后,你可以设置一个 Kubernetes 集群来安装 Rancher。
|
||||
|
||||
设置 RKE、RKE2 或 K3s 的步骤如下所示。
|
||||
|
||||
为方便起见,将代理的 IP 地址和端口导出到一个环境变量中,并在每个节点上为你当前的 shell 设置 HTTP_PROXY 变量:
|
||||
|
||||
```
|
||||
export proxy_host="10.0.0.5:8888"
|
||||
export HTTP_PROXY=http://${proxy_host}
|
||||
export HTTPS_PROXY=http://${proxy_host}
|
||||
export NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16
|
||||
```
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="K3s">
|
||||
|
||||
首先在 K3s systemd 服务上配置 HTTP 代理设置,让 K3s 的 containerd 可以通过代理拉取镜像:
|
||||
|
||||
```
|
||||
cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
|
||||
HTTP_PROXY=http://${proxy_host}
|
||||
HTTPS_PROXY=http://${proxy_host}"
|
||||
NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
EOF
|
||||
```
|
||||
|
||||
Rancher 需要安装在支持的 Kubernetes 版本上。如需了解你使用的 Rancher 版本支持哪些 Kubernetes 版本,请参见 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/)。
|
||||
|
||||
如需指定 K3s(Kubernetes)版本,在运行 K3s 安装脚本时使用 `INSTALL_K3S_VERSION` 环境变量(例如 `INSTALL_K3S_VERSION="v1.24.10+k3s1"`)。
|
||||
|
||||
在第一个节点上,创建一个新集群:
|
||||
```
|
||||
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<VERSION> K3S_TOKEN=<TOKEN> sh -s - server --cluster-init
|
||||
```
|
||||
|
||||
然后加入其他节点:
|
||||
```
|
||||
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<VERSION> K3S_TOKEN=<TOKEN> sh -s - server --server https://<SERVER>:6443
|
||||
```
|
||||
|
||||
其中 `<SERVER>` 是 Server 的 IP 或有效 DNS,`<TOKEN>` 是可以在 `/var/lib/rancher/k3s/server/node-token` 中找到的 Server node-token。
|
||||
|
||||
有关安装 K3s 的更多信息,请参阅 [K3s 安装文档](https://docs.k3s.io/installation)。
|
||||
|
||||
如需查看集群,请运行以下命令:
|
||||
|
||||
```
|
||||
kubectl cluster-info
|
||||
kubectl get pods --all-namespaces
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2">
|
||||
|
||||
在每个节点上,运行 RKE2 安装脚本。确保你安装的 RKE2 版本受 [Rancher 支持](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/)。
|
||||
|
||||
```
|
||||
curl -sfL https://get.rke2.io | INSTALL_RKE2_CHANNEL=v1.xx sh -
|
||||
```
|
||||
|
||||
然后,你必须在 RKE2 systemd 服务上配置 HTTP 代理设置,让 RKE2 的 containerd 可以通过代理拉取镜像:
|
||||
|
||||
```
|
||||
cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
|
||||
HTTP_PROXY=http://${proxy_host}
|
||||
HTTPS_PROXY=http://${proxy_host}"
|
||||
NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
EOF
|
||||
```
|
||||
|
||||
接下来,按照 [RKE2 高可用性文档](https://docs.rke2.io/install/ha)在每个节点上创建 RKE2 配置文件。
|
||||
|
||||
之后启动并启用 `rke2-server` 服务:
|
||||
|
||||
```
|
||||
systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
```
|
||||
|
||||
有关安装 RKE2 的更多信息,请参阅 [RKE2 文档](https://docs.rke2.io)。
|
||||
|
||||
如需查看集群,请运行以下命令:
|
||||
|
||||
```
|
||||
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
|
||||
alias kubectl=/var/lib/rancher/rke2/bin/kubectl
|
||||
kubectl cluster-info
|
||||
kubectl get pods --all-namespaces
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE">
|
||||
|
||||
首先,你需要在所有三个 Linux 节点上安装 Docker 并设置 HTTP 代理。因此,你可以在这三个节点上执行以下步骤。
|
||||
|
||||
接下来配置 apt 以在安装包时使用这个代理。如果你使用的不是 Ubuntu,请相应调整步骤。
|
||||
|
||||
```
|
||||
cat <<'EOF' | sudo tee /etc/apt/apt.conf.d/proxy.conf > /dev/null
|
||||
Acquire::http::Proxy "http://${proxy_host}/";
|
||||
Acquire::https::Proxy "http://${proxy_host}/";
|
||||
EOF
|
||||
```
|
||||
|
||||
安装 Docker:
|
||||
|
||||
```
|
||||
curl -sL https://releases.rancher.com/install-docker/19.03.sh | sh
|
||||
```
|
||||
|
||||
然后,确保你的当前用户能够在没有 sudo 的情况下访问 Docker Daemon:
|
||||
|
||||
```
|
||||
sudo usermod -aG docker YOUR_USERNAME
|
||||
```
|
||||
|
||||
配置 Docker Daemon 使用代理来拉取镜像:
|
||||
|
||||
```
|
||||
sudo mkdir -p /etc/systemd/system/docker.service.d
|
||||
cat <<'EOF' | sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf > /dev/null
|
||||
[Service]
|
||||
Environment="HTTP_PROXY=http://${proxy_host}"
|
||||
Environment="HTTPS_PROXY=http://${proxy_host}"
|
||||
Environment="NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16"
|
||||
EOF
|
||||
```
|
||||
|
||||
要应用配置,请重新启动 Docker Daemon:
|
||||
|
||||
```
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
|
||||
#### 离线代理
|
||||
|
||||
你现在可以在配置的离线集群中配置主机驱动集群,以使用代理进行出站连接。
|
||||
|
||||
除了为代理服务器设置默认规则外,你还需要额外添加如下所示的规则,以从代理的 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
|
||||
```
|
||||
|
||||
### 创建 RKE 集群
|
||||
|
||||
在能通过 SSH 访问 Linux 节点的主机上,你需要有几个命令行工具,来创建集群并与之交互:
|
||||
|
||||
* [RKE CLI binary](https://rancher.com/docs/rke/latest/en/installation/#download-the-rke-binary)
|
||||
|
||||
```
|
||||
sudo curl -fsSL -o /usr/local/bin/rke https://github.com/rancher/rke/releases/download/v1.1.4/rke_linux-amd64
|
||||
sudo chmod +x /usr/local/bin/rke
|
||||
```
|
||||
|
||||
* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
|
||||
|
||||
```
|
||||
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
|
||||
chmod +x ./kubectl
|
||||
sudo mv ./kubectl /usr/local/bin/kubectl
|
||||
```
|
||||
|
||||
接下来,创建一个描述 RKE 集群的 YAML 文件。确保节点的 IP 地址和 SSH 用户名是正确的。有关集群 YAML 的详情,请参见 [RKE 官方文档](https://rancher.com/docs/rke/latest/en/example-yamls/)。
|
||||
|
||||
```yml
|
||||
nodes:
|
||||
- address: 10.0.1.200
|
||||
user: ubuntu
|
||||
role: [controlplane,worker,etcd]
|
||||
- address: 10.0.1.201
|
||||
user: ubuntu
|
||||
role: [controlplane,worker,etcd]
|
||||
- address: 10.0.1.202
|
||||
user: ubuntu
|
||||
role: [controlplane,worker,etcd]
|
||||
|
||||
services:
|
||||
etcd:
|
||||
backup_config:
|
||||
interval_hours: 12
|
||||
retention: 6
|
||||
```
|
||||
|
||||
之后,你可以通过运行以下命令来创建 Kubernetes 集群:
|
||||
|
||||
```
|
||||
rke up --config rancher-cluster.yaml
|
||||
```
|
||||
|
||||
RKE 会创建一个名为 `rancher-cluster.rkestate` 的状态文件。如果你需要更新或修改集群配置,或使用备份恢复集群,则需要使用该文件。RKE 还会创建一个 `kube_config_cluster.yaml` 文件,你可以使用该文件在本地使用 kubectl 或 Helm 等工具连接到远端的 Kubernetes 集群。请将这些文件保存在安全的位置,例如版本控制系统中。
|
||||
|
||||
如需查看集群,请运行以下命令:
|
||||
|
||||
```
|
||||
export KUBECONFIG=kube_config_cluster.yaml
|
||||
kubectl cluster-info
|
||||
kubectl get pods --all-namespaces
|
||||
```
|
||||
|
||||
你也可以验证你的外部负载均衡器是否工作,DNS 条目是否设置正确。如果你向其中之一发送请求,你会收到来自 Ingress Controller 的 HTTP 404 响应:
|
||||
|
||||
```
|
||||
$ curl 10.0.1.100
|
||||
default backend - 404
|
||||
$ curl rancher.example.com
|
||||
default backend - 404
|
||||
```
|
||||
|
||||
### 保存你的文件
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
维护、排除问题和升级集群需要用到以下文件,请妥善保管这些文件:
|
||||
|
||||
:::
|
||||
|
||||
将以下文件的副本保存在安全位置:
|
||||
|
||||
- `rancher-cluster.yml`:RKE 集群配置文件。
|
||||
- `kube_config_cluster.yml`:集群的 [Kubeconfig 文件](https://rancher.com/docs/rke/latest/en/kubeconfig/)。该文件包含可完全访问集群的凭证。
|
||||
- `rancher-cluster.rkestate`:[Kubernetes 集群状态文件](https://rancher.com/docs/rke/latest/en/installation/#kubernetes-cluster-state)。此文件包含集群的当前状态,包括 RKE 配置和证书。
|
||||
|
||||
:::note
|
||||
|
||||
后两个文件名中的 `rancher-cluster` 部分取决于你命名 RKE 集群配置文件的方式。
|
||||
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 故障排除
|
||||
|
||||
参见[故障排除](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)页面。
|
||||
|
||||
### 后续操作
|
||||
[安装 Rancher](install-rancher.md)
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
title: 3. 安装 Rancher
|
||||
---
|
||||
|
||||
在前文的操作后,你已经有了一个运行的 RKE 集群,现在可以在其中安装 Rancher 了。出于安全考虑,所有到 Rancher 的流量都必须使用 TLS 加密。在本教程中,你将使用 [cert-manager](https://cert-manager.io/)自动颁发自签名证书。在实际使用情况下,你可使用 Let's Encrypt 或自己的证书。
|
||||
|
||||
### 安装 Helm CLI
|
||||
|
||||
在具有 kubeconfig 的主机上安装 [Helm](https://helm.sh/docs/intro/install/) CLI 以访问 Kubernetes 集群:
|
||||
|
||||
```
|
||||
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
|
||||
chmod +x get_helm.sh
|
||||
sudo ./get_helm.sh
|
||||
```
|
||||
|
||||
### 安装 cert-manager
|
||||
|
||||
添加 cert-manager Helm 仓库:
|
||||
|
||||
```
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
```
|
||||
|
||||
为 cert-manager 创建命名空间:
|
||||
|
||||
```
|
||||
kubectl create namespace cert-manager
|
||||
```
|
||||
|
||||
安装 cert-manager 的 CustomResourceDefinitions:
|
||||
|
||||
```
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
```
|
||||
|
||||
使用 Helm 安装 cert-manager。请注意,cert-manager 还需要你配置代理,以防它需要与 Let's Encrypt 或其他外部证书颁发商进行通信:
|
||||
|
||||
:::note
|
||||
|
||||
要查看自定义 cert-manager 安装的选项(包括集群使用 PodSecurityPolicies 的情况),请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
helm upgrade --install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager --version v1.11.0 \
|
||||
--set http_proxy=http://${proxy_host} \
|
||||
--set https_proxy=http://${proxy_host} \
|
||||
--set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
|
||||
```
|
||||
|
||||
等待 cert-manager 完成启动:
|
||||
|
||||
```
|
||||
kubectl rollout status deployment -n cert-manager cert-manager
|
||||
kubectl rollout status deployment -n cert-manager cert-manager-webhook
|
||||
```
|
||||
|
||||
### 安装 Rancher
|
||||
|
||||
接下来,你可以安装 Rancher 了。首先,添加 Helm 仓库:
|
||||
|
||||
```
|
||||
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
|
||||
```
|
||||
|
||||
创建命名空间:
|
||||
|
||||
```
|
||||
kubectl create namespace cattle-system
|
||||
```
|
||||
|
||||
然后使用 Helm 安装 Rancher:Rancher 也需要你配置代理,以便它可以与外部应用商店通信,或检索 Kubernetes 版本更新元数据:
|
||||
|
||||
```
|
||||
helm upgrade --install rancher rancher-latest/rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.example.com \
|
||||
--set proxy=http://${proxy_host} \
|
||||
--set noProxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
|
||||
```
|
||||
|
||||
等待部署完成:
|
||||
|
||||
```
|
||||
kubectl rollout status deployment -n cattle-system rancher
|
||||
```
|
||||
|
||||
现在,你可以导航到 `https://rancher.example.com` 并开始使用 Rancher。
|
||||
|
||||
:::caution
|
||||
|
||||
如果你不想发送遥测数据,在首次登录时退出[遥测](../../../../faq/telemetry.md)。如果在离线安装的环境中让这个功能处于 active 状态,socket 可能无法打开。
|
||||
|
||||
:::
|
||||
|
||||
### 其他资源
|
||||
|
||||
以下资源可能对安装 Rancher 有帮助:
|
||||
|
||||
- [Rancher Helm Chart 选项](../../installation-references/helm-chart-options.md)
|
||||
- [添加 TLS 密文](../../resources/add-tls-secrets.md)
|
||||
- [Rancher Kubernetes 安装的故障排除](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: '1. 配置基础设施'
|
||||
---
|
||||
|
||||
在本节中,你将为 Rancher Management Server 配置底层基础设施,并使其通过 HTTP 代理访问互联网。
|
||||
|
||||
如需在高可用 RKE 集群中安装 Rancher Management Server,我们建议配置以下基础设施:
|
||||
|
||||
- **3 个 Linux 节点**:可以是你的云提供商(例如 Amazon EC2,GCE 或 vSphere)中的虚拟机。
|
||||
- **1 个负载均衡器**:用于将前端流量转发到这三个节点中。
|
||||
- **1 个 DNS 记录**:用于将 URL 映射到负载均衡器。此 DNS 记录将成为 Rancher Server 的 URL,下游集群需要可以访问到这个地址。
|
||||
|
||||
这些节点必须位于同一个区域或数据中心。但是你可以把这些服务器放在不同的可用区。
|
||||
|
||||
### 为什么使用三个节点?
|
||||
|
||||
在 RKE 集群中,Rancher Server 的数据存储在 etcd 中。而这个 etcd 数据库在这三个节点上运行。
|
||||
|
||||
为了选举出大多数 etcd 节点认可的 etcd 集群 leader,etcd 数据库需要奇数个节点。如果 etcd 数据库无法选出 leader,etcd 可能会出现[脑裂(split brain)](https://www.quora.com/What-is-split-brain-in-distributed-systems)的问题,此时你需要使用备份恢复集群。如果三个 etcd 节点之一发生故障,其余两个节点可以选择一个 leader,因为它们是 etcd 节点总数的大多数部分。
|
||||
|
||||
### 1. 配置 Linux 节点
|
||||
|
||||
这些主机将通过 HTTP 代理连接到互联网。
|
||||
|
||||
请确保你的节点满足[操作系统,容器运行时,硬件和网络](../../../../pages-for-subheaders/installation-requirements.md)的常规要求。
|
||||
|
||||
如需获取配置 Linux 节点的示例,请参见[在 Amazon EC2 中配置节点](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md)的教程。
|
||||
|
||||
### 2. 配置负载均衡器
|
||||
|
||||
你还需要设置一个负载均衡器,来将流量重定向到两个节点上的 Rancher 副本。配置后,当单个节点不可用时,继续保障与 Rancher Management Server 的通信。
|
||||
|
||||
在后续步骤中配置 Kubernetes 时,RKE 工具会部署一个 NGINX Ingress Controller。该 Controller 将侦听 worker 节点的 80 端口和 443 端口,以响应发送给特定主机名的流量。
|
||||
|
||||
在安装 Rancher 后(也是在后续步骤中),Rancher 系统将创建一个 Ingress 资源。该 Ingress 通知 NGINX Ingress Controller 监听发往 Rancher 主机名的流量。NGINX Ingress Controller 在收到发往 Rancher 主机名的流量时,会将其转发到集群中正在运行的 Rancher Server Pod。
|
||||
|
||||
在你的实现中,你可以考虑是否需要使用 4 层或 7 层的负载均衡器:
|
||||
|
||||
- **4 层负载均衡器**:两种选择中较为简单的一种,它将 TCP 流量转发到你的节点中。我们建议使用 4 层负载均衡器,将流量从 TCP/80 端口和 TCP/443 端口转发到 Rancher Management 集群节点上。集群上的 Ingress Controller 会将 HTTP 流量重定向到 HTTPS,并在 TCP/443 端口上终止 SSL/TLS。Ingress Controller 会将流量转发到 Rancher deployment 中 Ingress Pod 的 TCP/80 端口。
|
||||
- **7 层负载均衡器**:相对比较复杂,但功能更全面。例如,与 Rancher 本身进行 TLS 终止相反,7 层负载均衡器能够在负载均衡器处处理 TLS 终止。如果你需要集中在基础设施中进行 TLS 终止,7 层负载均衡可能会很适合你。7 层负载均衡还能让你的负载均衡器基于 HTTP 属性(例如 cookie 等)做出决策,而 4 层负载均衡器则不能。如果你选择在 7 层负载均衡器上终止 SSL/TLS 流量,则在安装 Rancher 时(后续步骤)需要使用 `--set tls=external` 选项。详情请参见 [Rancher Helm Chart 选项](../../installation-references/helm-chart-options.md#外部-tls-终止)。
|
||||
|
||||
如需获取配置 NGINX 负载均衡器的示例,请参见[本页](../../../../how-to-guides/new-user-guides/infrastructure-setup/nginx-load-balancer.md)。
|
||||
|
||||
如需获取如何配置 Amazon ELB 网络负载均衡器的指南,请参见[本页](../../../../how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md)。
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
安装后,请勿将此负载均衡(例如 `local` 集群 Ingress)用于 Rancher 以外的应用。如果此 Ingress 与其他应用共享,在其他应用的 Ingress 配置重新加载后,可能导致 Rancher 出现 websocket 错误。我们建议把 `local` 集群专用给 Rancher,不要在集群内部署其他应用。
|
||||
|
||||
:::
|
||||
|
||||
### 3. 配置 DNS 记录
|
||||
|
||||
配置完负载均衡器后,你将需要创建 DNS 记录,以将流量发送到该负载均衡器。
|
||||
|
||||
根据你的环境,DNS 记录可以是指向负载均衡器 IP 的 A 记录,也可以是指向负载均衡器主机名的 CNAME。无论是哪种情况,请确保该记录是你要 Rancher 进行响应的主机名。
|
||||
|
||||
在安装 Rancher 时(后续步骤),你需要指定此主机名。请知悉,此主机名无法修改。请确保你设置的主机名是你想要的。
|
||||
|
||||
有关设置 DNS 记录以将域流量转发到 Amazon ELB 负载均衡器的指南,请参见 [AWS 官方文档](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)。
|
||||
|
||||
|
||||
### 后续操作
|
||||
[配置 Kubernetes 集群](install-kubernetes.md)
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
title: 证书故障排除
|
||||
---
|
||||
|
||||
### 如何确定我的证书格式是否为 PEM?
|
||||
|
||||
你可以通过以下特征识别 PEM 格式:
|
||||
|
||||
- 文件开始的标头:
|
||||
```
|
||||
-----BEGIN CERTIFICATE-----
|
||||
```
|
||||
- 表头后跟一长串字符。
|
||||
- 文件结束的页脚:
|
||||
```
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
PEM 证书示例:
|
||||
|
||||
```
|
||||
----BEGIN CERTIFICATE-----
|
||||
MIIGVDCCBDygAwIBAgIJAMiIrEm29kRLMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
|
||||
... more lines
|
||||
VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
PEM 证书密钥示例:
|
||||
|
||||
```
|
||||
-----BEGIN RSA PRIVATE KEY-----
|
||||
MIIGVDCCBDygAwIBAgIJAMiIrEm29kRLMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
|
||||
... more lines
|
||||
VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
|
||||
-----END RSA PRIVATE KEY-----
|
||||
```
|
||||
|
||||
如果你的密钥与以下示例类似,请参见[将 PKCS8 证书密钥转换为 PKCS1](#将-pkcs8-证书密钥转换为-pkcs1)。
|
||||
|
||||
```
|
||||
-----BEGIN PRIVATE KEY-----
|
||||
MIIGVDCCBDygAwIBAgIJAMiIrEm29kRLMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
|
||||
... more lines
|
||||
VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
|
||||
-----END PRIVATE KEY-----
|
||||
```
|
||||
|
||||
### 将 PKCS8 证书密钥转换为 PKCS1
|
||||
|
||||
如果你使用的是 PKCS8 证书密钥文件,Rancher 将打印以下日志:
|
||||
|
||||
```
|
||||
ListenConfigController cli-config [listener] failed with : failed to read private key: asn1: structure error: tags don't match (2 vs {class:0 tag:16 length:13 isCompound:true})
|
||||
```
|
||||
|
||||
为了能正常工作,你需要运行以下命令,将密钥从 PKCS8 转换为 PKCS1:
|
||||
|
||||
```
|
||||
openssl rsa -in key.pem -out convertedkey.pem
|
||||
```
|
||||
|
||||
你可使用 `convertedkey.pem` 作为 Rancher 证书密钥文件。
|
||||
|
||||
### 添加中间证书的顺序是什么?
|
||||
|
||||
添加证书的顺序如下:
|
||||
|
||||
```
|
||||
-----BEGIN CERTIFICATE-----
|
||||
%YOUR_CERTIFICATE%
|
||||
-----END CERTIFICATE-----
|
||||
-----BEGIN CERTIFICATE-----
|
||||
%YOUR_INTERMEDIATE_CERTIFICATE%
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
### 如何验证我的证书链?
|
||||
|
||||
你可使用 `openssl` 二进制文件来验证证书链。如果命令的输出以 `Verify return code: 0 (ok)` 结尾(参见以下示例),你的证书链是有效的。`ca.pem` 文件必须与你添加到 `rancher/rancher` 容器中的文件一致。
|
||||
|
||||
如果你使用由可信的 CA 签发的证书,可省略 `-CAfile` 参数。
|
||||
|
||||
命令:
|
||||
|
||||
```
|
||||
openssl s_client -CAfile ca.pem -connect rancher.yourdomain.com:443
|
||||
...
|
||||
Verify return code: 0 (ok)
|
||||
```
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
title: 回滚 Docker 安装的 Rancher
|
||||
---
|
||||
|
||||
如果 Rancher 升级没有成功完成,你需要回滚到你在 [Docker 升级](upgrade-docker-installed-rancher.md)之前使用的 Rancher 设置。回滚可以恢复:
|
||||
|
||||
- 先前版本的 Rancher。
|
||||
- 升级前创建的数据备份。
|
||||
|
||||
## 在你开始前
|
||||
|
||||
在回滚到先前 Rancher 版本的过程中,你将输入一系列命令。请按照你环境的实际情况替换占位符。占位符用尖括号和大写字母(如 `<EXAMPLE>`)表示。以下是带有占位符的命令示例:
|
||||
|
||||
```
|
||||
docker pull rancher/rancher:<PRIOR_RANCHER_VERSION>
|
||||
```
|
||||
|
||||
在此命令中,`<PRIOR_RANCHER_VERSION>` 是升级失败之前运行的 Rancher 版本,如 `v2.0.5`。
|
||||
|
||||
请交叉参考下方的图片和表格,了解获取此占位符数据的方法。在开始以下步骤之前,请先记下或复制此信息。
|
||||
|
||||
<sup>终端 <code>docker ps</code> 命令,显示如何找到 <code><PRIOR_RANCHER_VERSION></code> 和 <code><RANCHER_CONTAINER_NAME></code></sup>
|
||||
|
||||
| 占位符 | 示例 | 描述 |
|
||||
| -------------------------- | -------------------------- | ------------------------------------------------------- |
|
||||
| `<PRIOR_RANCHER_VERSION>` | `v2.0.5` | 升级前使用的 rancher/rancher 镜像。 |
|
||||
| `<RANCHER_CONTAINER_NAME>` | `festive_mestorf` | 你的 Rancher 容器的名称。 |
|
||||
| `<RANCHER_VERSION>` | `v2.0.5` | 备份对应的 Rancher 版本。 |
|
||||
| `<DATE>` | `9-27-18` | 数据容器或备份的创建日期。 |
|
||||
<br/>
|
||||
|
||||
可以通过远程连接登录到 Rancher Server 所在的主机并输入命令 `docker ps` 以查看正在运行的容器,从而获得 `<PRIOR_RANCHER_VERSION>` 和 `<RANCHER_CONTAINER_NAME>` 。你还可以运行 `docker ps -a` 命令查看停止了的容器。在创建备份期间,你随时可以运行这些命令来获得帮助。
|
||||
|
||||
## 回滚 Rancher
|
||||
|
||||
如果你在升级 Rancher 时遇到问题,你可拉取先前使用的镜像并恢复在升级前所做的备份,从而将 Rancher 回滚到之前的正常工作状态。
|
||||
|
||||
:::danger
|
||||
|
||||
回滚到先前的 Rancher 版本会破坏你在升级后对 Rancher 做出的所有更改。丢失的数据可能无法恢复。
|
||||
|
||||
:::
|
||||
|
||||
1. 使用远程终端连接,登录到运行 Rancher Server 的节点。
|
||||
|
||||
1. 拉取升级前运行的 Rancher 版本。把 `<PRIOR_RANCHER_VERSION>` 替换为该版本。
|
||||
|
||||
例如,如果升级之前运行的是 Rancher v2.0.5,请拉取 v2.0.5。
|
||||
|
||||
```
|
||||
docker pull rancher/rancher:<PRIOR_RANCHER_VERSION>
|
||||
```
|
||||
|
||||
1. 停止当前运行 Rancher Server 的容器。将 `<RANCHER_CONTAINER_NAME>` 替换为你的 Rancher 容器的名称:
|
||||
|
||||
```
|
||||
docker stop <RANCHER_CONTAINER_NAME>
|
||||
```
|
||||
你可输入 `docker ps`获取 Rancher 容器的名称。
|
||||
|
||||
1. 将你在 [Docker 升级](upgrade-docker-installed-rancher.md)时创建的备份压缩包移动到 Rancher Server。切换到你将其移动到的目录。输入 `dir` 以确认它在该位置。
|
||||
|
||||
如果你遵循了我们在 [Docker 升级](upgrade-docker-installed-rancher.md)中推荐的命名方式,它的名称会与 `rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz` 类似。
|
||||
|
||||
1. 替换占位符来运行以下命令,将 `rancher-data` 容器中的数据替换为备份压缩包中的数据。不要忘记关闭引号。
|
||||
|
||||
```
|
||||
docker run --volumes-from rancher-data \
|
||||
-v $PWD:/backup busybox sh -c "rm /var/lib/rancher/* -rf \
|
||||
&& tar zxvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz"
|
||||
```
|
||||
|
||||
1. 将 `<PRIOR_RANCHER_VERSION>` 占位符指向数据容器,启动一个新的 Rancher Server 容器。
|
||||
```
|
||||
docker run -d --volumes-from rancher-data \
|
||||
--restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
--privileged \
|
||||
rancher/rancher:<PRIOR_RANCHER_VERSION>
|
||||
```
|
||||
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
|
||||
:::danger
|
||||
|
||||
启动回滚后,即使回滚耗时比预期长,也 **_不要_** 停止回滚。如果你停止回滚,可能会导致之后的升级中出现数据库错误。
|
||||
|
||||
:::
|
||||
|
||||
1. 等待片刻,然后在浏览器中打开 Rancher。确认回滚成功并且你的数据已恢复。
|
||||
|
||||
**结果**:Rancher 回滚到升级前的版本和数据状态。
|
||||
@@ -0,0 +1,393 @@
|
||||
---
|
||||
title: 升级 Docker 安装的 Rancher
|
||||
---
|
||||
|
||||
本文介绍如何升级通过 Docker 安装的 Rancher Server。
|
||||
|
||||
:::caution
|
||||
|
||||
**生产环境不支持 Docker 安装**。这些说明仅适用于测试和开发。如果你已经在生产环境中部署了 Docker 安装并且需要升级到新的 Rancher 版本,我们建议你在升级前先[迁移到 Helm Chart 安装](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 先决条件
|
||||
|
||||
- 在 Rancher 文档中**检查[已知升级问题](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#已知升级问题)**,了解升级 Rancher 时最需要注意的问题。你可以在 [GitHub](https://github.com/rancher/rancher/releases) 发布说明以及 [Rancher 论坛](https://forums.rancher.com/c/announcements/12)中找到每个 Rancher 版本的已知问题。不支持升级或升级到 [rancher-alpha 仓库](../../resources/choose-a-rancher-version.md#helm-chart-仓库)中的任何 Chart。
|
||||
- **[仅适用于离线安装](../../../../pages-for-subheaders/air-gapped-helm-cli-install.md):为新的 Rancher Server 版本收集和推送镜像**。按照指南为你想要升级的目标 Rancher 版本[推送镜像到私有镜像仓库](../air-gapped-helm-cli-install/publish-images.md)。
|
||||
|
||||
## 占位符
|
||||
|
||||
在升级过程中,你将输入一系列命令。请按照你环境的实际情况替换占位符。占位符用尖括号和大写字母(如 `<EXAMPLE>`)表示。
|
||||
|
||||
以下是带有占位符的命令**示例**:
|
||||
|
||||
```
|
||||
docker stop <RANCHER_CONTAINER_NAME>
|
||||
```
|
||||
|
||||
在此命令中,`<RANCHER_CONTAINER_NAME>` 是你的 Rancher 容器的名称。
|
||||
|
||||
## 获取升级命令的数据
|
||||
|
||||
要获取替换占位符的数据,请运行:
|
||||
|
||||
```
|
||||
docker ps
|
||||
```
|
||||
|
||||
在开始升级之前记下或复制此信息。
|
||||
|
||||
<sup>终端 <code>docker ps</code> 命令,显示如何找到 <code><RANCHER_CONTAINER_TAG></code> 和 <code><RANCHER_CONTAINER_NAME></code></sup>
|
||||
|
||||

|
||||
|
||||
| 占位符 | 示例 | 描述 |
|
||||
| -------------------------- | -------------------------- | --------------------------------------------------------- |
|
||||
| `<RANCHER_CONTAINER_TAG>` | `v2.1.3` | 首次安装拉取的 rancher/rancher 镜像。 |
|
||||
| `<RANCHER_CONTAINER_NAME>` | `festive_mestorf` | 你的 Rancher 容器的名称。 |
|
||||
| `<RANCHER_VERSION>` | `v2.1.3` | 你为其创建备份的 Rancher 版本。 |
|
||||
| `<DATE>` | `2018-12-19` | 数据容器或备份的创建日期。 |
|
||||
<br/>
|
||||
|
||||
可以通过远程连接登录到 Rancher Server 所在的主机并输入命令 `docker ps` 以查看正在运行的容器,从而获得 `<RANCHER_CONTAINER_TAG>` 和 `<RANCHER_CONTAINER_NAME>`。你还可以运行 `docker ps -a` 命令查看停止了的容器。在创建备份期间,你随时可以运行这些命令来获得帮助。
|
||||
|
||||
## 升级
|
||||
|
||||
在升级期间,你可以为当前 Rancher 容器创建数据的副本及备份,以确保可以在升级出现问题时可以进行回滚。然后,你可使用现有数据将新版本的 Rancher 部署到新容器中。
|
||||
### 1. 创建 Rancher Server 容器的数据副本
|
||||
|
||||
1. 使用远程终端连接,登录到运行 Rancher Server 的节点。
|
||||
|
||||
1. 停止正在运行 Rancher Server 的容器。将 `<RANCHER_CONTAINER_NAME>` 替换为你的 Rancher 容器的名称:
|
||||
|
||||
```
|
||||
docker stop <RANCHER_CONTAINER_NAME>
|
||||
```
|
||||
|
||||
1. <a id="backup"></a>运行以下命令,从刚才停止的 Rancher 容器创建一个数据容器。请替换命令中的占位符:
|
||||
|
||||
```
|
||||
docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data rancher/rancher:<RANCHER_CONTAINER_TAG>
|
||||
```
|
||||
|
||||
### 2. 创建备份压缩包
|
||||
|
||||
1. <a id="tarball"></a>从你刚刚创建的数据容器(<code>rancher-data</code>)中,创建一个备份 tar 包(<code>rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz</code>)。
|
||||
|
||||
如果升级期间出现问题,此压缩包可以用作回滚点。替换占位符来运行以下命令。
|
||||
```
|
||||
docker run --volumes-from rancher-data -v "$PWD:/backup" --rm busybox tar zcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
|
||||
```
|
||||
|
||||
**步骤结果**:你输入此命令时,会运行一系列命令。
|
||||
|
||||
1. 输入 `ls` 命令,确认备份压缩包已创建成功。压缩包的名称格式类似 `rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`。
|
||||
|
||||
```
|
||||
[rancher@ip-10-0-0-50 ~]$ ls
|
||||
rancher-data-backup-v2.1.3-20181219.tar.gz
|
||||
```
|
||||
|
||||
1. 将备份压缩包移动到 Rancher Server 外的安全位置。
|
||||
|
||||
### 3. 拉取新的 Docker 镜像
|
||||
|
||||
拉取你需要升级到的 Rancher 版本镜像。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
------------|-------------
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
```
|
||||
docker pull rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
### 4. 启动新的 Rancher Server 容器
|
||||
|
||||
使用 `rancher-data` 容器中的数据启动一个新的 Rancher Server 容器。记住要传入启动原始容器时使用的所有环境变量。
|
||||
|
||||
:::danger
|
||||
|
||||
启动升级后,即使升级耗时比预期长,也 **_不要_** 停止升级。如果你停止升级,可能会导致之后的升级中出现数据库迁移错误。
|
||||
|
||||
:::
|
||||
|
||||
如果你使用代理,请参见 [HTTP 代理配置](../../../../reference-guides/single-node-rancher-in-docker/http-proxy-configuration.md)。
|
||||
|
||||
如果你配置了自定义 CA 根证书来访问服务,请参见[自定义 CA 根证书](../../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#自定义-ca-证书)。
|
||||
|
||||
如果你要记录所有 Rancher API 的事务,请参见 [API 审计](../../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-审计日志)。
|
||||
|
||||
如需查看启动新 Rancher Server 容器时使用的命令,从以下的选项中进行选择:
|
||||
|
||||
- Docker 升级
|
||||
- 离线安装的 Docker 升级
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Docker 升级">
|
||||
|
||||
选择你安装 Rancher Server 时用的选项
|
||||
|
||||
#### 选项 A:使用 Rancher 默认的自签名证书
|
||||
|
||||
<details id="option-a">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
如果你使用 Rancher 生成的自签名证书,则将 `--volumes-from rancher-data` 添加到你启动原始 Rancher Server 容器的命令中。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
------------|-------------
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
```
|
||||
docker run -d --volumes-from rancher-data \
|
||||
--restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
--privileged \
|
||||
rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
|
||||
</details>
|
||||
|
||||
#### 选项 B:使用你自己的证书 - 自签名
|
||||
|
||||
<details id="option-b">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
如果你选择使用自己的自签名证书,则在启动原始 Rancher Server 容器的命令中添加 `--volumes-from rancher-data`。此外,你需要能够访问你原始安装时使用的证书。
|
||||
|
||||
:::note 证书要求提示:
|
||||
|
||||
证书文件的格式必须是 PEM。在你的证书文件中,包括链中的所有中间证书。你需要对你的证书进行排序,把你的证书放在最前面,后面跟着中间证书。
|
||||
|
||||
:::
|
||||
|
||||
| 占位符 | 描述 |
|
||||
------------|-------------
|
||||
| `<CERT_DIRECTORY>` | 包含证书文件的目录的路径。 |
|
||||
| `<FULL_CHAIN.pem>` | 完整证书链的路径。 |
|
||||
| `<PRIVATE_KEY.pem>` | 证书私钥的路径。 |
|
||||
| `<CA_CERTS.pem>` | CA 证书的路径。 |
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
```
|
||||
docker run -d --volumes-from rancher-data \
|
||||
--restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-v /<CERT_DIRECTORY>/<FULL_CHAIN.pem>:/etc/rancher/ssl/cert.pem \
|
||||
-v /<CERT_DIRECTORY>/<PRIVATE_KEY.pem>:/etc/rancher/ssl/key.pem \
|
||||
-v /<CERT_DIRECTORY>/<CA_CERTS.pem>:/etc/rancher/ssl/cacerts.pem \
|
||||
--privileged \
|
||||
rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
|
||||
</details>
|
||||
|
||||
#### 选项 C:使用你自己的证书 - 可信 CA 签名的证书
|
||||
|
||||
<details id="option-c">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
如果你选择使用可信 CA 签名的证书,则在启动原始 Rancher Server 容器的命令中添加 `--volumes-from rancher-data`。此外,你需要能够访问你原始安装时使用的证书。注意要使用 `--no-cacerts` 作为容器的参数,以禁用 Rancher 生成的默认 CA 证书。
|
||||
|
||||
:::note 证书要求提示:
|
||||
|
||||
证书文件的格式必须是 PEM。在你的证书文件中,包括可信 CA 提供的所有中间证书。你需要对你的证书进行排序,把你的证书放在最前面,后面跟着中间证书。如需查看示例,请参见[证书故障排除](certificate-troubleshooting.md)。
|
||||
|
||||
:::
|
||||
|
||||
| 占位符 | 描述 |
|
||||
------------|-------------
|
||||
| `<CERT_DIRECTORY>` | 包含证书文件的目录的路径。 |
|
||||
| `<FULL_CHAIN.pem>` | 完整证书链的路径。 |
|
||||
| `<PRIVATE_KEY.pem>` | 证书私钥的路径。 |
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
```
|
||||
docker run -d --volumes-from rancher-data \
|
||||
--restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-v /<CERT_DIRECTORY>/<FULL_CHAIN.pem>:/etc/rancher/ssl/cert.pem \
|
||||
-v /<CERT_DIRECTORY>/<PRIVATE_KEY.pem>:/etc/rancher/ssl/key.pem \
|
||||
--privileged \
|
||||
rancher/rancher:<RANCHER_VERSION_TAG> \
|
||||
--no-cacerts
|
||||
```
|
||||
|
||||
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
</details>
|
||||
|
||||
#### 选项 D:Let's Encrypt 证书
|
||||
|
||||
<details id="option-d">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
:::caution
|
||||
|
||||
Let's Encrypt 对新证书请求有频率限制。因此,请限制创建或销毁容器的频率。详情请参见 [Let's Encrypt 官方文档 - 频率限制](https://letsencrypt.org/docs/rate-limits/)。
|
||||
|
||||
:::
|
||||
|
||||
如果你选择使用 [Let's Encrypt](https://letsencrypt.org/) 证书,则在启动原始 Rancher Server 容器的命令中添加 `--volumes-from rancher-data`,并且提供最初安装 Rancher 时使用的域名。
|
||||
|
||||
:::note 证书要求提示:
|
||||
|
||||
- 在 DNS 中创建一条记录,将 Linux 主机 IP 地址绑定到要用于访问 Rancher 的主机名(例如,`rancher.mydomain.com`)。
|
||||
- 在 Linux 主机上打开 `TCP/80` 端口。Let's Encrypt 的 HTTP-01 质询可以来自任何源 IP 地址,因此端口 `TCP/80` 必须开放开所有 IP 地址。
|
||||
|
||||
:::
|
||||
|
||||
| 占位符 | 描述 |
|
||||
------------|-------------
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
| `<YOUR.DNS.NAME>` | 你最初使用的域名 |
|
||||
|
||||
```
|
||||
docker run -d --volumes-from rancher-data \
|
||||
--restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
--privileged \
|
||||
rancher/rancher:<RANCHER_VERSION_TAG> \
|
||||
--acme-domain <YOUR.DNS.NAME>
|
||||
```
|
||||
|
||||
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
|
||||
</details>
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Docker 离线升级">
|
||||
|
||||
出于安全考虑,使用 Rancher 时请使用 SSL(Secure Sockets Layer)。SSL 保护所有 Rancher 网络通信(如登录和与集群交互)的安全。
|
||||
|
||||
启动新的 Rancher Server 容器时,从以下的选项中进行选择:
|
||||
|
||||
#### 选项 A:使用 Rancher 默认的自签名证书
|
||||
|
||||
<details id="option-a">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
如果你使用 Rancher 生成的自签名证书,则将 `--volumes-from rancher-data` 添加到你启动原始 Rancher Server 容器的命令中。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
------------|-------------
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 私有镜像仓库的 URL 和端口。 |
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
```
|
||||
docker run -d --volumes-from rancher-data \
|
||||
--restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-e CATTLE_SYSTEM_DEFAULT_REGISTRY=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的默认私有镜像仓库
|
||||
-e CATTLE_SYSTEM_CATALOG=bundled \ # 使用打包的 Rancher System Chart
|
||||
--privileged \
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
</details>
|
||||
|
||||
#### 选项 B:使用你自己的证书 - 自签名
|
||||
|
||||
<details id="option-b">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
如果你选择使用自己的自签名证书,则在启动原始 Rancher Server 容器的命令中添加 `--volumes-from rancher-data`。此外,你需要能够访问你原始安装时使用的证书。
|
||||
|
||||
:::note 证书要求提示:
|
||||
|
||||
证书文件的格式必须是 PEM。在你的证书文件中,包括链中的所有中间证书。你需要对你的证书进行排序,把你的证书放在最前面,后面跟着中间证书。如需查看示例,请参见[证书故障排除](certificate-troubleshooting.md)。
|
||||
|
||||
:::
|
||||
|
||||
| 占位符 | 描述 |
|
||||
------------|-------------
|
||||
| `<CERT_DIRECTORY>` | 包含证书文件的目录的路径。 |
|
||||
| `<FULL_CHAIN.pem>` | 完整证书链的路径。 |
|
||||
| `<PRIVATE_KEY.pem>` | 证书私钥的路径。 |
|
||||
| `<CA_CERTS.pem>` | CA 证书的路径。 |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 私有镜像仓库的 URL 和端口。 |
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-v /<CERT_DIRECTORY>/<FULL_CHAIN.pem>:/etc/rancher/ssl/cert.pem \
|
||||
-v /<CERT_DIRECTORY>/<PRIVATE_KEY.pem>:/etc/rancher/ssl/key.pem \
|
||||
-v /<CERT_DIRECTORY>/<CA_CERTS.pem>:/etc/rancher/ssl/cacerts.pem \
|
||||
-e CATTLE_SYSTEM_DEFAULT_REGISTRY=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的默认私有镜像仓库
|
||||
-e CATTLE_SYSTEM_CATALOG=bundled \ # 使用打包的 Rancher System Chart
|
||||
--privileged \
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
</details>
|
||||
|
||||
#### 选项 C:使用你自己的证书 - 可信 CA 签名的证书
|
||||
|
||||
<details id="option-c">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
如果你选择使用可信 CA 签名的证书,则在启动原始 Rancher Server 容器的命令中添加 `--volumes-from rancher-data`。此外,你需要能够访问你原始安装时使用的证书。
|
||||
|
||||
:::note 证书要求提示:
|
||||
|
||||
证书文件的格式必须是 PEM。在你的证书文件中,包括可信 CA 提供的所有中间证书。你需要对你的证书进行排序,把你的证书放在最前面,后面跟着中间证书。如需查看示例,请参见[证书故障排除](certificate-troubleshooting.md)。
|
||||
|
||||
:::
|
||||
|
||||
| 占位符 | 描述 |
|
||||
------------|-------------
|
||||
| `<CERT_DIRECTORY>` | 包含证书文件的目录的路径。 |
|
||||
| `<FULL_CHAIN.pem>` | 完整证书链的路径。 |
|
||||
| `<PRIVATE_KEY.pem>` | 证书私钥的路径。 |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 私有镜像仓库的 URL 和端口。 |
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
:::note
|
||||
|
||||
使用 `--no-cacerts` 作为容器的参数,以禁用 Rancher 生成的默认 CA 证书。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
docker run -d --volumes-from rancher-data \
|
||||
--restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
--no-cacerts \
|
||||
-v /<CERT_DIRECTORY>/<FULL_CHAIN.pem>:/etc/rancher/ssl/cert.pem \
|
||||
-v /<CERT_DIRECTORY>/<PRIVATE_KEY.pem>:/etc/rancher/ssl/key.pem \
|
||||
-e CATTLE_SYSTEM_DEFAULT_REGISTRY=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的默认私有镜像仓库
|
||||
-e CATTLE_SYSTEM_CATALOG=bundled \ # 使用打包的 Rancher System Chart
|
||||
--privileged
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
|
||||
</details>
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**结果**:你已升级 Rancher。已升级 Server 中的数据将保存在 `rancher-data` 容器中,用于将来的升级。
|
||||
|
||||
### 5. 验证升级
|
||||
|
||||
登录到 Rancher。通过检查浏览器左下角的版本号,确认升级是否成功。
|
||||
|
||||
:::note 升级后下游集群出现网络问题?
|
||||
|
||||
请参见[恢复集群网络](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。
|
||||
|
||||
:::
|
||||
|
||||
### 6. 清理旧的 Rancher Server 容器
|
||||
|
||||
移除旧的 Rancher Server 容器。如果你仅停止了旧的 Rancher Server 容器,但没有移除它,该容器还可能在服务器下次重启后重新启动。
|
||||
|
||||
## 回滚
|
||||
|
||||
如果升级没有成功完成,你可以将 Rancher Server 及其数据回滚到上次的健康状态。详情请参见 [Docker 回滚](roll-back-docker-installed-rancher.md)。
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: 添加 TLS 密文
|
||||
---
|
||||
|
||||
我们使用证书和密钥将 `cattle-system` 命名空间中的 `tls-rancher-ingress` 密文配置好后,Kubernetes 会为 Rancher 创建对象和服务。
|
||||
|
||||
将服务器证书和所需的所有中间证书合并到名为 `tls.crt`的文件中。将证书密钥复制到名为 `tls.key` 的文件中。
|
||||
|
||||
例如,[acme.sh](https://acme.sh) 在 `fullchain.cer` 文件中提供服务器证书和 CA 链。
|
||||
请将 `fullchain.cer` 命名为 `tls.crt`,将证书密钥文件命名为 `tls.key`。
|
||||
|
||||
使用 `kubectl` 创建 `tls` 类型的密文。
|
||||
|
||||
```
|
||||
kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
--cert=tls.crt \
|
||||
--key=tls.key
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
如需替换证书,你可以运行 `kubectl -n cattle-system delete secret tls-rancher-ingress` 来删除 `tls-rancher-ingress` 密文,然后运行上方命令来添加新的密文。如果你使用的是私有 CA 签名证书,仅当新证书与当前证书是由同一个 CA 签发的,才可以替换。
|
||||
|
||||
:::
|
||||
|
||||
## 使用私有 CA 签名证书
|
||||
|
||||
如果你使用的是私有 CA,Rancher 需要私有 CA 的根证书或证书链的副本,Rancher Agent 使用它来校验与 Server 的连接。
|
||||
|
||||
创建一个名为 `cacerts.pem` 的文件,该文件仅包含私有 CA 的根 CA 证书或证书链,并使用 `kubectl` 在 `cattle-system` 命名空间中创建 `tls-ca` Secret。
|
||||
|
||||
```
|
||||
kubectl -n cattle-system create secret generic tls-ca \
|
||||
--from-file=cacerts.pem=./cacerts.pem
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
Rancher 启动时会检索配置的 `tls-ca` 密文。如果 Rancher 在运行中,更新的 CA 会在新的 Rancher Pod 启动后生效。
|
||||
|
||||
:::
|
||||
|
||||
## 更新私有 CA 证书
|
||||
|
||||
按照[步骤](update-rancher-certificate.md)更新 [Rancher 高可用 Kubernetes 安装](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md)中的 Ingress,或从默认自签名证书切换到自定义证书。
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: 引导密码
|
||||
---
|
||||
|
||||
Rancher 首次启动时,会为第一个管理员用户随机生成一个密码。当管理员首次登录 Rancher 时,用于获取引导密码(Bootstrap)的命令会在 UI 上显示。管理员需要运行命令并使用引导密码登录。然后 Rancher 会让管理员重置密码。
|
||||
|
||||
如果你在安装过程中没有使用变量来设置引导密码,则会随机生成引导密码。如需了解使用变量设置引导密码的详情,请参见下文。
|
||||
|
||||
### 在 Helm 安装中指定引导密码
|
||||
|
||||
Helm 安装的情况下,你可以使用 `.Values.bootstrapPassword` 在 Helm Chart 值中指定引导密码变量。
|
||||
|
||||
密码将存储在 Kubernetes 密文中。安装 Rancher 后,如何使用 kubectl 获取密码的说明将会在 UI 中显示:
|
||||
|
||||
```
|
||||
kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'
|
||||
```
|
||||
|
||||
### 在 Docker 安装中指定引导密码
|
||||
|
||||
如果 Rancher 是使用 Docker 安装的,你可以通过在 Docker 安装命令中传递 `-e CATTLE_BOOTSTRAP_PASSWORD=password` 来指定引导密码。
|
||||
|
||||
密码将存储在 Docker 容器日志中。安装 Rancher 后,如何使用 Docker 容器 ID 获取密码的说明将会在 UI 中显示:
|
||||
|
||||
```
|
||||
docker logs container-id 2>&1 | grep "Bootstrap Password:"
|
||||
```
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
title: 选择 Rancher 版本
|
||||
---
|
||||
|
||||
本节介绍如何选择 Rancher 版本。
|
||||
|
||||
在我们推荐用于生产环境的 Rancher 高可用安装中,Rancher Server 是通过 Kubernetes 集群上的 **Helm Chart** 安装的。请参见 [Helm 版本要求](helm-version-requirements.md)选择 Helm 版本来安装 Rancher。
|
||||
|
||||
如果你在开发和测试中使用 Docker 来安装 Rancher,你需要把 Rancher 作为一个 **Docker 镜像**来安装。
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Helm Charts">
|
||||
|
||||
如果 Rancher Server 是[安装在 Kubernetes 集群上](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md)的,Rancher Server 的安装,升级和回滚中,都是使用 Kubernetes 集群上的 Helm Chart 来安装 Rancher 的。因此,在准备安装或升级 Rancher 高可用时,必须添加包含用于安装 Rancher 的 Chart 的 Helm Chart 仓库。
|
||||
|
||||
请参见 [Helm 版本要求](helm-version-requirements.md)选择 Helm 版本来安装 Rancher。
|
||||
|
||||
### Helm Chart 仓库
|
||||
|
||||
Rancher 提供几个可选的 Helm Chart 仓库供你选择。最新版或稳定版的 Helm Chart 仓库与用于 Docker 安装中的 Docker 标签对应。因此,`rancher-latest` 仓库包含所有标记为 `rancher/rancher:latest` 的 Rancher 版本 Chart。当 Rancher 版本升级到 `rancher/rancher:stable`,它会被添加到 `rancher-stable` 仓库中。
|
||||
|
||||
| 类型 | 添加仓库的命令 | 仓库描述 |
|
||||
| -------------- | ------------ | ----------------- |
|
||||
| rancher-latest | `helm repo add rancher-latest https://releases.rancher.com/server-charts/latest` | 添加最新版本的 Rancher 的 Helm Chart 仓库。建议使用此仓库来测试新版本的 Rancher。 |
|
||||
| rancher-stable | `helm repo add rancher-stable https://releases.rancher.com/server-charts/stable` | 添加较旧的,稳定的版本的 Rancher 的 Helm Chart 仓库。建议在生产环境中使用此仓库。 |
|
||||
| rancher-alpha | `helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha` | 添加 alpha 版本的 Rancher 的 Helm Chart 仓库,以预览即将发布的版本。不建议在生产环境中使用这些版本。无论是什么仓库,均不支持 _升级_ 或 _升级到_ rancher-alpha 仓库中的任何 Chart。 |
|
||||
|
||||
了解何时选择这些仓库,请参见[切换到不同 Helm Chart 仓库](#切换到不同-helm-chart-仓库)。
|
||||
|
||||
:::note
|
||||
|
||||
`rancher-stable` 仓库中的所有 Chart 都与 `stable` 标记的 Rancher 版本对应。
|
||||
|
||||
:::
|
||||
|
||||
### Helm Chart 版本
|
||||
|
||||
Rancher Helm Chart 版本与 Rancher 版本(即 `appVersion`)对应。添加仓库后,你可以运行以下命令搜索可用版本:<br/>
|
||||
`helm search repo --versions`
|
||||
|
||||
如果你有多个仓库,你可指定仓库名称,即:`helm search repo rancher-stable/rancher --versions` <br/>
|
||||
详情请访问 https://helm.sh/docs/helm/helm_search_repo/
|
||||
|
||||
要获取所选仓库的指定版本,参见如下示例指定 `--version` 参数:<br/>
|
||||
`helm fetch rancher-stable/rancher --version=2.4.8`
|
||||
|
||||
### 切换到不同 Helm Chart 仓库
|
||||
|
||||
安装 Rancher 后,如果想修改安装 Rancher 的 Helm Chart 仓库,按照以下步骤操作。
|
||||
|
||||
:::note
|
||||
|
||||
由于 rancher-alpha 仓库只包含 alpha 版本 Chart,因此不支持从 rancher alpha 仓库切换到 rancher-stable 或 rancher-latest 仓库以进行升级。
|
||||
|
||||
:::
|
||||
|
||||
- Latest:建议用于试用最新功能
|
||||
```
|
||||
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
|
||||
```
|
||||
- Stable:建议用于生产环境
|
||||
```
|
||||
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
|
||||
```
|
||||
- Alpha:即将发布的实验性预览。
|
||||
```
|
||||
helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha
|
||||
```
|
||||
注意:不支持升级到 Alpha 版、从 Alpha 版升级或在 Alpha 版之间升级。
|
||||
|
||||
1. 列出当前 Helm Chart 仓库。
|
||||
|
||||
```plain
|
||||
helm repo list
|
||||
|
||||
NAME URL
|
||||
stable https://charts.helm.sh/stable
|
||||
rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
|
||||
2. 删除包含安装 Rancher 时用的 Chart 的 Helm Chart 仓库。是 `rancher-stable` 或 `rancher-latest` 取决于你初始安装时的选择。
|
||||
|
||||
```plain
|
||||
helm repo remove rancher-<CHART_REPO>
|
||||
```
|
||||
|
||||
3. 添加你要用于安装 Rancher 的 Helm Chart 仓库。
|
||||
|
||||
```plain
|
||||
helm repo add rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
|
||||
4. 按照以下步骤,从新的 Helm Chart 仓库[升级 Rancher](../install-upgrade-on-a-kubernetes-cluster/upgrades.md)。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Docker 镜像">
|
||||
|
||||
在执行 [Docker 安装](../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md)、升级或回滚时,你可以使用 _tags_ 来安装特定版本的 Rancher。
|
||||
|
||||
### Server 标签
|
||||
|
||||
Rancher Server 以 Docker 镜像的形式分发并附有标签。你可以在输入命令部署 Rancher 时指定标签。请记住,如果你指定了标签,但是没有指定版本(如 `latest` 或 `stable`),你必须显式拉取该镜像标签的新版本。否则,将使用缓存在主机上的镜像。
|
||||
|
||||
| 标签 | 描述 |
|
||||
| -------------------------- | ------ |
|
||||
| `rancher/rancher:latest` | 最新的开发版本。这些版本通过了我们的 CI 自动化验证。不推荐在生产环境使用这些版本。 |
|
||||
| `rancher/rancher:stable` | 最新的稳定版本。推荐将此标签用于生产环境。 |
|
||||
| `rancher/rancher:<v2.X.X>` | 你可以使用以前版本中的标签来指定要安装的 Rancher 版本。访问 DockerHub 查看可用的版本。 |
|
||||
|
||||
:::note
|
||||
|
||||
- `master` 和带有 `-rc` 或其他后缀的标签是供 Rancher 测试团队验证用的。这些标签不受官方支持,因此请不要使用这些标签。
|
||||
- 安装 alpha 版本进行预览:使用我们的[公告页面](https://forums.rancher.com/c/announcements)中列出的 alpha 标签(例如,`v2.2.0-alpha1`)进行安装。不支持升级或升级到 Alpha 版本。
|
||||
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: 自定义 CA 根证书
|
||||
---
|
||||
|
||||
如果你在内部生产环境使用 Rancher,且不打算公开暴露应用,你可以使用使用私有 CA 颁发的证书。
|
||||
|
||||
Rancher 可能会访问配置了自定义/内部 CA 根证书(也称为自签名证书)的服务。如果 Rancher 无法验证服务的证书,则会显示错误信息 `x509: certificate signed by unknown authority`。
|
||||
|
||||
如需验证证书,你需要把 CA 根证书添加到 Rancher。由于 Rancher 是用 Go 编写的,我们可以使用环境变量 `SSL_CERT_DIR` 指向容器中 CA 根证书所在的目录。启动 Rancher 容器时,可以使用 Docker 卷选项(`-v host-source-directory:container-destination-directory`)来挂载 CA 根证书目录。
|
||||
|
||||
Rancher 可以访问的服务示例:
|
||||
|
||||
- 应用商店
|
||||
- 验证提供程序
|
||||
- 使用 Node Driver 访问托管/云 API
|
||||
|
||||
## 使用自定义 CA 证书安装
|
||||
|
||||
有关启动挂载了私有 CA 证书的 Rancher 容器的详情,请参见安装文档:
|
||||
|
||||
- [Docker 安装的自定义 CA 证书选项](../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#自定义-ca-证书)
|
||||
|
||||
- [Kubernetes 安装的其他受信 CA 选项](../installation-references/helm-chart-options.md#额外的授信-ca)
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: Helm 版本要求
|
||||
---
|
||||
|
||||
本文介绍 Helm 的要求。Helm 是用于把 Rancher 安装在高可用 Kubernetes 集群上的工具。
|
||||
|
||||
> 我们已针对 Helm 3 更新了安装指南。如果你使用 Helm 2 进行安装,请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。[本文](/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2.md)提供了较早的使用 Helm 2 的 Rancher 高可用安装指南的副本。如果你如果无法升级到 Helm 3,可以使用这个说明安装。
|
||||
|
||||
- 如需安装或升级 Rancher 2.5,请使用 Helm 3.2.x 或更高版本。
|
||||
- Kubernetes 1.16 要求 Helm 2.16.0 或更高版本。如果使用的是默认 Kubernetes 版本,请参见[发行说明](https://github.com/rancher/rke/releases)获取所使用的 RKE 版本。
|
||||
- 请不要使用 Helm 2.15.0,因为这个版本有转换/比较数字的问题。
|
||||
- 请不要使用 Helm 2.12.0,因为该版本有 `cert-manager` 的兼容问题。
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: 离线安装中设置本地 System Charts
|
||||
---
|
||||
|
||||
[Charts](https://github.com/rancher/charts) 仓库包含 Monitoring、Logging、告警和 Istio 等功能所需的所有 Helm 目录项。
|
||||
|
||||
在 Rancher 的离线安装中,你需要配置 Rancher 以使用 System Charts 的本地副本。本节介绍如何通过 CLI 标志使用本地 System Charts。
|
||||
|
||||
## 使用本地 System Charts
|
||||
|
||||
`system-charts` 的一个本地副本已经打包到 `rancher/rancher` 容器中。为了在离线安装中使用这些功能,你需要使用额外的环境变量 `CATTLE_SYSTEM_CATALOG=bundled` 来运行 Rancher 安装命令,该环境变量告诉 Rancher 使用 Chart 的本地副本,而不是尝试从 GitHub 获取 Chart。
|
||||
|
||||
带有 `system-charts` 的 Rancher 安装命令示例包含在 Docker 和 Helm 的[离线安装说明](../../../pages-for-subheaders/air-gapped-helm-cli-install.md)中。
|
||||
@@ -0,0 +1,263 @@
|
||||
---
|
||||
title: 更新 Rancher 证书
|
||||
---
|
||||
|
||||
## 更新私有 CA 证书
|
||||
|
||||
按照以下步骤轮换[安装在 Kubernetes 集群上](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md)、由 Rancher 使用的 SSL 证书和私有 CA,或转用由私有 CA 签发的 SSL 证书。
|
||||
|
||||
步骤概述:
|
||||
|
||||
1. 使用新证书和私钥创建或更新 `tls-rancher-ingress` Kubernetes Secret 对象。
|
||||
1. 使用根 CA 证书创建或更新 `tls-ca` Kubernetes Secret 对象(仅在使用私有 CA 时需要)。
|
||||
1. 使用 Helm CLI 更新 Rancher 安装。
|
||||
1. 重新配置 Rancher Agent 以信任新的 CA 证书。
|
||||
1. 选择 Fleet 集群的强制更新,来将 fleet-agent 连接到 Rancher。
|
||||
|
||||
各个步骤的详细说明如下。
|
||||
|
||||
### 1. 创建/更新证书 Secret 对象
|
||||
|
||||
首先,将服务器证书和所有中间证书合并到名为 `tls.crt` 的文件,并在名为 `tls.key` 的文件中提供相应的证书密钥。
|
||||
|
||||
使用以下命令在 Rancher(本地)管理集群中创建 `tls-rancher-ingress` Secret 对象:
|
||||
|
||||
```bash
|
||||
kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
--cert=tls.crt \
|
||||
--key=tls.key
|
||||
```
|
||||
|
||||
或者,更新现有的 `tls-rancher-ingress` Secret:
|
||||
|
||||
```bash
|
||||
kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
--cert=tls.crt \
|
||||
--key=tls.key \
|
||||
--dry-run --save-config -o yaml | kubectl apply -f -
|
||||
```
|
||||
|
||||
### 2. 创建/更新证书 CA Secret 对象
|
||||
|
||||
如果新证书由私有 CA 签发的,你需要将相应的根 CA 证书复制到名为 `cacerts.pem` 的文件中,并创建或更新 `cattle-system` 命名空间中的 `tls-ca` Secret。如果证书由中间 CA 签名,则 `cacerts.pem` 必须按顺序同时包含中间 CA 证书和根 CA 证书。
|
||||
|
||||
创建初始 `tls-ca` Secret:
|
||||
|
||||
```bash
|
||||
kubectl -n cattle-system create secret generic tls-ca \
|
||||
--from-file=cacerts.pem
|
||||
```
|
||||
|
||||
要更新现有的 `tls-ca` Secret:
|
||||
|
||||
```bash
|
||||
kubectl -n cattle-system create secret generic tls-ca \
|
||||
--from-file=cacerts.pem \
|
||||
--dry-run --save-config -o yaml | kubectl apply -f -
|
||||
```
|
||||
|
||||
### 3. 重新配置 Rancher 部署
|
||||
|
||||
如果证书源保持不变(例如,`secret`),请按照步骤 3a 中的步骤操作。
|
||||
|
||||
但是,如果证书源发生变化(例如,`letsEncrypt` 更改为 `secret`),请按照 3b 中的步骤操作。
|
||||
|
||||
#### 3a. 重新部署 Rancher pod
|
||||
|
||||
当证书源保持不变,但需要更新 CA 证书时,需要执行此步骤。
|
||||
|
||||
在这种情况下,由于 `tls-ca` secret 在启动时由 Rancher pod 读取,因此你需要重新部署 Rancher pod。
|
||||
|
||||
你可以运行以下命令重新部署 Rancher pod:
|
||||
```bash
|
||||
kubectl rollout restart deploy/rancher -n cattle-system
|
||||
```
|
||||
|
||||
修改完成后,访问 `https://<RANCHER_SERVER_URL>/v3/settings/cacerts`,验证该值是否与先前写入 `tls-ca` Secret 中的 CA 证书匹配。在所有重新部署的 Rancher pod 启动之前,CA `cacerts` 值可能不会更新。
|
||||
|
||||
#### 3b. 更新 Rancher 的 Helm 值
|
||||
|
||||
如果证书源有更改,则需要执行此步骤。如果你的 Rancher 之前使用默认的自签名证书 (`ingress.tls.source=rancher`) 或 Let's Encrypt (`ingress.tls.source=letsEncrypt`) 证书,并且现在正在使用由私有 CA (`ingress.tls.source=secret`) 签名的证书。
|
||||
|
||||
以下步骤更新了 Rancher Chart 的 Helm 值,因此 Rancher pod 和 ingress 会使用在步骤 1 和 2 中创建的新私有 CA 证书。
|
||||
|
||||
1. 调整初始安装期间使用的值,将当前值存储为:
|
||||
```bash
|
||||
helm get values rancher -n cattle-system -o yaml > values.yaml
|
||||
```
|
||||
1. 检索当前部署的 Rancher Chart 的版本字符串:
|
||||
```bash
|
||||
helm ls -n cattle-system
|
||||
```
|
||||
1. 更新 `values.yaml` 文件中的当前 Helm 值以包含下方内容:
|
||||
```yaml
|
||||
ingress:
|
||||
tls:
|
||||
source: secret
|
||||
privateCA: true
|
||||
```
|
||||
:::note 重要:
|
||||
由于证书由私有 CA 签发,因此确保在 `values.yaml` 文件中设置了 [`privateCA: true`](../installation-references/helm-chart-options.md#常用选项) 是非常重要的。
|
||||
:::
|
||||
1. 使用 `values.yaml` 文件和当前 Chart 版本升级 Helm 应用程序实例。版本必须匹配以防止 Rancher 升级。
|
||||
```bash
|
||||
helm upgrade rancher rancher-stable/rancher \
|
||||
--namespace cattle-system \
|
||||
-f values.yaml \
|
||||
--version <DEPLOYED_RANCHER_VERSION>
|
||||
```
|
||||
|
||||
修改完成后,访问 `https://<RANCHER_SERVER_URL>/v3/settings/cacerts`,验证该值是否与先前写入 `tls-ca` Secret 中的 CA 证书匹配。在所有 Rancher pod 启动之前,CA `cacerts` 值可能不会更新。
|
||||
|
||||
### 4. 重新配置 Rancher Agent 以信任私有 CA
|
||||
|
||||
本节介绍了重新配置 Rancher Agent 以信任私有 CA 的三种方法。如果你的实际情况符合以下任意一个条件,请执行此步骤:
|
||||
|
||||
- Rancher 在先前的配置中使用了 Rancher 自签名证书 (`ingress.tls.source=rancher`) 或 Let's Encrypt 证书 (`ingress.tls.source=letsEncrypt`)。
|
||||
- 该证书由不同的私有 CA 签发
|
||||
|
||||
#### 为什么要执行这一步骤?
|
||||
|
||||
如果 Rancher 配置了私有 CA 签名的证书时,CA 证书链将受到 Rancher agent 容器的信任。Agent 会对下载证书的校验和及 `CATTLE_CA_CHECKSUM` 环境变量进行比较。换言之,如果 Rancher 使用的私有 CA 证书发生变化,环境变量 `CATTLE_CA_CHECKSUM` 必须相应更新。
|
||||
|
||||
#### 可使用的方法
|
||||
|
||||
- 方法 1(最简单的方法):在轮换证书后将所有集群连接到 Rancher。适用于更新或重新部署 Rancher 部署(步骤 3)后立即执行的情况。
|
||||
|
||||
- 方法 2:适用于集群与 Rancher 失去连接,但所有集群都启用了 [Authorized Cluster Endpoint](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint.md) (ACE) 的情况。
|
||||
|
||||
- 方法 3:如果方法 1 和 2 不可行,则可使用方法 3 进行回退。
|
||||
|
||||
#### 方法 1:强制重新部署 Rancher Agent
|
||||
|
||||
对于每个下游集群,使用 Rancher(本地)管理集群的 Kubeconfig 文件运行以下命令。
|
||||
|
||||
```bash
|
||||
kubectl annotate clusters.management.cattle.io <CLUSTER_ID> io.cattle.agent.force.deploy=true
|
||||
```
|
||||
|
||||
:::note
|
||||
找到下游集群的集群 ID (c-xxxxx)。你可以在 Rancher UI 的**集群管理**中查看集群时在浏览器 URL 中找到 ID。
|
||||
:::
|
||||
|
||||
此命令将使 Agent 清单重新应用新证书的校验和。
|
||||
|
||||
#### 方法二:手动更新校验和环境变量
|
||||
|
||||
将 `CATTLE_CA_CHECKSUM` 环境变量更新为匹配新 CA 证书校验和的值,从而手动为 Agent Kubernetes 对象打上补丁。通过以下操作生成新的校验和:
|
||||
|
||||
```bash
|
||||
curl -k -s -fL <RANCHER_SERVER_URL>/v3/settings/cacerts | jq -r .value | sha256sum | awk '{print $1}'
|
||||
```
|
||||
|
||||
为每个下游集群使用 Kubeconfig 更新两个 Agent 部署的环境变量。如果集群启用了 [ACE](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint.md),你可以[调整 kubectl 上下文](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#直接使用下游集群进行身份验证),从而直接连接到下游集群。
|
||||
|
||||
```bash
|
||||
kubectl edit -n cattle-system ds/cattle-node-agent
|
||||
kubectl edit -n cattle-system deployment/cattle-cluster-agent
|
||||
```
|
||||
|
||||
#### 方法三:手动重新部署 Rancher agent
|
||||
|
||||
该方法通过在每个下游集群的 control plane 节点上运行一组命令,从而重新应用 Rancher agent。
|
||||
|
||||
对每个下游集群重复以下步骤:
|
||||
|
||||
1. 检索 agent 注册 kubectl 命令:
|
||||
1. 找到下游集群的集群 ID (c-xxxxx)。你可以在 Rancher UI 的**集群管理**中查看集群时在浏览器 URL 中找到 ID。
|
||||
1. 将 Rancher Server URL 和集群 ID 添加到以下 URL:`https://<RANCHER_SERVER_URL>/v3/clusterregistrationtokens?clusterId=<CLUSTER_ID>`。
|
||||
1. 复制 `insecureCommand` 字段中的命令,使用此命令是因为未使用私有 CA。
|
||||
|
||||
2. 使用以下其中一种方法,使用 kubeconfig 为下游集群运行上一步中的 kubectl 命令:
|
||||
1. 如果集群启用了 [ACE](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint.md),你可以[调整上下文](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#直接使用下游集群进行身份验证),从而直接连接到下游集群。
|
||||
1. 或者,SSH 到 control plane 节点:
|
||||
- RKE:使用[此处文档中的步骤](https://github.com/rancherlabs/support-tools/tree/master/how-to-retrieve-kubeconfig-from-custom-cluster)生成 kubeconfig
|
||||
- RKE2/K3s:使用安装时填充的 kubeconfig
|
||||
|
||||
### 5. 强制更新 Fleet 集群,从而将 fleet-agent 重新连接到 Rancher
|
||||
|
||||
在 Rancher UI 的[持续交付](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#在-rancher-ui-中访问-fleet)中,为集群选择“强制更新”,来允许下游集群中的 fleet-agent 成功连接到 Rancher。
|
||||
|
||||
#### 为什么要执行这一步骤?
|
||||
|
||||
Rancher 管理的集群中的 Fleet agent 存储了用于连接到 Rancher 的 kubeconfig。kubeconfig 包含一个 `certificate-authority-data` 字段,该字段包含 Rancher 使用的证书的 CA。更改 CA 时,你需要更新此块来允许 fleet-agent 信任 Rancher 使用的证书。
|
||||
|
||||
## 将私有 CA 证书更改为公共证书
|
||||
|
||||
按照以下步骤执行与上面相反的操作,将私有 CA 颁发的证书更改为公共或自签名 CA。
|
||||
|
||||
### 1. 创建/更新证书 Secret 对象
|
||||
|
||||
首先,将服务器证书和所有中间证书合并到名为 `tls.crt` 的文件,并在名为 `tls.key` 的文件中提供相应的证书密钥。
|
||||
|
||||
使用以下命令在 Rancher(本地)管理集群中创建 `tls-rancher-ingress` Secret 对象:
|
||||
|
||||
```bash
|
||||
kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
--cert=tls.crt \
|
||||
--key=tls.key
|
||||
```
|
||||
|
||||
或者,更新现有的 `tls-rancher-ingress` Secret:
|
||||
|
||||
```bash
|
||||
kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
--cert=tls.crt \
|
||||
--key=tls.key \
|
||||
--dry-run --save-config -o yaml | kubectl apply -f -
|
||||
```
|
||||
|
||||
### 2. 删除 CA 证书 Secret 对象
|
||||
|
||||
你需要删除 `cattle-system` 命名空间中的 `tls-ca secret`(不再需要它)。如果需要,你还可以选择保存 `tls-ca` secret 的副本。
|
||||
|
||||
要保存现有的 `tls-ca` Secret:
|
||||
|
||||
```bash
|
||||
kubectl -n cattle-system get secret tls-ca -o yaml > tls-ca.yaml
|
||||
```
|
||||
|
||||
要删除现有的 `tls-ca` 密文:
|
||||
|
||||
```bash
|
||||
kubectl -n cattle-system delete secret tls-ca
|
||||
```
|
||||
|
||||
### 3. 重新配置 Rancher 部署
|
||||
|
||||
如果证书源有更改,则需要执行此步骤。在这种情况下,它变化的原因很可能是因为 Rancher 之前配置为使用默认的自签名证书 (`ingress.tls.source=rancher`)。
|
||||
|
||||
以下步骤更新了 Rancher Chart 的 Helm 值,因此 Rancher pod 和 Ingress 会使用在步骤 1 中创建的新证书。
|
||||
|
||||
1. 调整初始安装期间使用的值,将当前值存储为:
|
||||
```bash
|
||||
helm get values rancher -n cattle-system -o yaml > values.yaml
|
||||
```
|
||||
1. 获取当前部署的 Rancher Chart 的版本字符串:
|
||||
```bash
|
||||
helm ls -n cattle-system
|
||||
```
|
||||
1. 更新 `values.yaml` 文件中的当前 Helm 值:
|
||||
1. 由于不再使用私有 CA,删除 `privateCA: true` 字段,或将其设置为 `false`。
|
||||
1. 根据需要调整 `ingress.tls.source` 字段。有关更多信息,请参阅 [Chart 选项](../installation-references/helm-chart-options.md#常用选项)。以下是一些示例:
|
||||
1. 如果使用公共 CA,继续使用 `secret`
|
||||
1. 如果使用 Let's Encrypt,将值更新为 `letsEncrypt`
|
||||
1. 使用 `values.yaml` 文件更新 Rancher Chart 的 Helm 值,并使用当前 Chart 版本防止升级:
|
||||
```bash
|
||||
helm upgrade rancher rancher-stable/rancher \
|
||||
--namespace cattle-system \
|
||||
-f values.yaml \
|
||||
--version <DEPLOYED_RANCHER_VERSION>
|
||||
```
|
||||
|
||||
### 4. 为非私有/通用证书重新配置 Rancher Agent
|
||||
|
||||
由于不再使用私有 CA,因此你需要删除下游集群 agent 上的 `CATTLE_CA_CHECKSUM` 环境变量,或将其设置为 ""(空字符串)。
|
||||
|
||||
### 5. 强制更新 Fleet 集群,从而将 fleet-agent 重新连接到 Rancher
|
||||
|
||||
在 Rancher UI 的[持续交付](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#在-rancher-ui-中访问-fleet)中,为集群选择“强制更新”,来允许下游集群中的 fleet-agent 成功连接到 Rancher。
|
||||
|
||||
#### 为什么要执行这一步骤?
|
||||
|
||||
Rancher 管理的集群中的 Fleet agent 存储了用于连接到 Rancher 的 kubeconfig。kubeconfig 包含一个 `certificate-authority-data` 字段,该字段包含 Rancher 使用的证书的 CA。更改 CA 时,你需要更新此块来允许 fleet-agent 信任 Rancher 使用的证书。
|
||||
@@ -0,0 +1,281 @@
|
||||
---
|
||||
title: 升级 Cert-Manager
|
||||
---
|
||||
|
||||
Rancher 使用 cert-manager 为 Rancher 高可用部署自动生成和续期 TLS 证书。从 2019 秋季开始,cert-manager 发生了以下的三个重要变更。如果你在此时间段前创建了 Rancher 高可用部署,请进行相关操作。
|
||||
|
||||
1. [从 2019 年 11 月 1 日开始,Let's Encrypt 已阻止低于 0.8.0 的 cert-manager 实例。](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
|
||||
1. [Cert-manager 正在弃用和替换 certificate.spec.acme.solvers 字段](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/)。此更改暂时没有确切的截止日期。
|
||||
1. [Cert-manager 正在弃用 `v1alpha1` API 和替换它的 API 组](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/)。
|
||||
|
||||
为了帮助你应对这些变化,本文将:
|
||||
|
||||
1. 提供升级 cert-manager 步骤的文档。
|
||||
1. 阐述 cert-manager API 的变更,并提供 cert-manager 官方文档的链接,助你实现数据迁移。
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
如果你要将 cert-manager 从早于 1.5 的版本升级到最新版本,请按照以下[选项 C](#选项-c升级-15-及以下版本的-cert-manager) 中的步骤进行操作。请注意,你无需重新安装 Rancher 即可执行此升级。
|
||||
|
||||
:::
|
||||
|
||||
## 升级 Cert-Manager
|
||||
|
||||
以下说明中使用的命名空间是由当前安装了 cert-manager 的命名空间决定的。如果它在 kube-system 中,在以下说明步骤中使用。你可以运行 `kubectl get pods --all-namespaces` 来验证,并检查 cert-manager-\* pods 列在哪个命名空间中。不要更改运行 cert-manager 的命名空间,否则可能会出现错误。
|
||||
|
||||
要升级 cert-manager,请遵循步骤操作。
|
||||
|
||||
### 选项 A:联网升级 cert-manager
|
||||
|
||||
<details id="normal">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
1. [备份现有资源](https://cert-manager.io/docs/tutorials/backup/):
|
||||
|
||||
```plain
|
||||
kubectl get -o yaml --all-namespaces \
|
||||
issuer,clusterissuer,certificates,certificaterequests > cert-manager-backup.yaml
|
||||
```
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
如果你从低于 0.11.0 的版本升级,请将所有备份资源上的 apiVersion 从 `certmanager.k8s.io/v1alpha1` 升级到 `cert-manager.io/v1alpha2`。如果你需要在其他资源上使用 cert-manager 注释,请对其进行更新以反映新的 API 组。详情请参见[附加注释变更](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/#additional-annotation-changes)。
|
||||
|
||||
:::
|
||||
|
||||
1. [卸载现有部署](https://cert-manager.io/docs/installation/uninstall/kubernetes/#uninstalling-with-helm):
|
||||
|
||||
```plain
|
||||
helm uninstall cert-manager
|
||||
```
|
||||
|
||||
使用你安装的 vX.Y.Z 版本的链接删除 CustomResourceDefinition:
|
||||
|
||||
```plain
|
||||
kubectl delete -f https://github.com/cert-manager/cert-manager/releases/download/vX.Y.Z/cert-manager.crds.yaml
|
||||
|
||||
```
|
||||
|
||||
1. 单独安装 CustomResourceDefinition 资源:
|
||||
|
||||
```plain
|
||||
kubectl apply --validate=false -f https://github.com/cert-manager/cert-manager/releases/download/vX.Y.Z/cert-manager.crds.yaml
|
||||
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
如果你运行的 Kubernetes 版本是 1.15 或更低版本,你需要在以上的 `kubectl apply` 命令中添加 `--validate=false`。否则你将看到 cert-manager CRD 资源中的 `x-kubernetes-preserve-unknown-fields` 字段校验错误提示。这是 kubectl 执行资源校验方式产生的良性错误。
|
||||
|
||||
:::
|
||||
|
||||
1. 根据需要为 cert-manager 创建命名空间:
|
||||
|
||||
```plain
|
||||
kubectl create namespace cert-manager
|
||||
```
|
||||
|
||||
1. 添加 Jetstack Helm 仓库:
|
||||
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
```
|
||||
|
||||
1. 更新 Helm Chart 仓库本地缓存:
|
||||
|
||||
```plain
|
||||
helm repo update
|
||||
```
|
||||
|
||||
1. 安装新版本的 cert-manager:
|
||||
|
||||
```plain
|
||||
helm install \
|
||||
cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--version v1.11.0
|
||||
```
|
||||
|
||||
1. [恢复备份资源](https://cert-manager.io/docs/tutorials/backup/#restoring-resources):
|
||||
|
||||
```plain
|
||||
kubectl apply -f cert-manager-backup.yaml
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### 选项 B:在离线环境中升级 Cert-Manager
|
||||
|
||||
<details id="airgap">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
### 先决条件
|
||||
|
||||
在执行升级之前,先将所需的容器镜像添加到私有镜像仓库中,并下载/渲染所需的 Kubernetes manifest 文件来准备离线环境。
|
||||
|
||||
1. 参见[准备私有镜像仓库](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md)指南,将升级所需的镜像推送到镜像仓库。
|
||||
|
||||
1. 在可以连接互联网的系统中,将 cert-manager 仓库添加到 Helm:
|
||||
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
```
|
||||
|
||||
1. 从 [Helm Chart 仓库](https://artifacthub.io/packages/helm/cert-manager/cert-manager)中获取最新可用的 cert-manager Chart:
|
||||
|
||||
```plain
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
```
|
||||
|
||||
1. 使用安装 Chart 的选项来渲染 cert-manager 模板。记住要设置 `image.repository` 选项,以从你的私有镜像仓库拉取镜像。此操作会创建一个包含 Kubernetes manifest 文件的 `cert-manager` 目录。
|
||||
|
||||
Helm 3 命令如下:
|
||||
|
||||
```plain
|
||||
helm template cert-manager ./cert-manager-v0.12.0.tgz --output-dir . \
|
||||
--namespace cert-manager \
|
||||
--set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller
|
||||
--set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook
|
||||
--set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
|
||||
```
|
||||
|
||||
Helm 2 命令如下:
|
||||
|
||||
```plain
|
||||
helm template ./cert-manager-v0.12.0.tgz --output-dir . \
|
||||
--name cert-manager --namespace cert-manager \
|
||||
--set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller
|
||||
--set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook
|
||||
--set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
|
||||
```
|
||||
|
||||
1. 下载新旧版 cert-manager 所需的 CRD 文件:
|
||||
|
||||
```plain
|
||||
curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
|
||||
curl -L -o cert-manager/cert-manager-crd-old.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml
|
||||
```
|
||||
|
||||
### 安装 cert-manager
|
||||
|
||||
1. 备份现有资源:
|
||||
|
||||
```plain
|
||||
kubectl get -o yaml --all-namespaces \
|
||||
issuer,clusterissuer,certificates,certificaterequests > cert-manager-backup.yaml
|
||||
```
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
如果你从低于 0.11.0 的版本升级,请将所有备份资源上的 apiVersion 从 `certmanager.k8s.io/v1alpha1` 升级到 `cert-manager.io/v1alpha2`。如果你需要在其他资源上使用 cert-manager 注释,请对其进行更新以反映新的 API 组。详情请参见[附加注释变更](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/#additional-annotation-changes)。
|
||||
|
||||
:::
|
||||
|
||||
1. 删除现有的 cert-manager 安装包:
|
||||
|
||||
```plain
|
||||
kubectl -n cert-manager \
|
||||
delete deployment,sa,clusterrole,clusterrolebinding \
|
||||
-l 'app=cert-manager' -l 'chart=cert-manager-v0.5.2'
|
||||
```
|
||||
|
||||
使用你安装的 vX.Y 版本的链接删除 CustomResourceDefinition:
|
||||
|
||||
```plain
|
||||
kubectl delete -f cert-manager/cert-manager-crd-old.yaml
|
||||
```
|
||||
|
||||
1. 单独安装 CustomResourceDefinition 资源:
|
||||
|
||||
```plain
|
||||
kubectl apply -f cert-manager/cert-manager-crd.yaml
|
||||
```
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
如果你运行的 Kubernetes 版本是 1.15 或更低版本,你需要在以上的 `kubectl apply` 命令中添加 `--validate=false`。否则你将看到 cert-manager CRD 资源中的 `x-kubernetes-preserve-unknown-fields` 字段校验错误提示。这是 kubectl 执行资源校验方式产生的良性错误。
|
||||
|
||||
:::
|
||||
|
||||
1. 为 cert-manager 创建命名空间:
|
||||
|
||||
```plain
|
||||
kubectl create namespace cert-manager
|
||||
```
|
||||
|
||||
1. 安装 cert-manager
|
||||
|
||||
```plain
|
||||
kubectl -n cert-manager apply -R -f ./cert-manager
|
||||
```
|
||||
|
||||
1. [恢复备份资源](https://cert-manager.io/docs/tutorials/backup/#restoring-resources):
|
||||
|
||||
```plain
|
||||
kubectl apply -f cert-manager-backup.yaml
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### 选项 C:升级 1.5 及以下版本的 cert-manager
|
||||
|
||||
<details id="normal">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
以前,要升级旧版本的 cert-manager,我们建议卸载并重新安装 Rancher。使用以下方法,你可以升级 cert-manager 而无需执行此额外步骤,从而更好地保护你的生产环境:
|
||||
|
||||
1. 按照[安装指南](https://cert-manager.io/docs/usage/cmctl/#installation)安装 `cmctl`(cert-manager CLI 工具)。
|
||||
|
||||
1. 确保所有以已弃用的 API 版本存储在 etcd 中的 cert-manager 自定义资源都迁移到 v1:
|
||||
|
||||
```
|
||||
cmctl upgrade migrate-api-version
|
||||
```
|
||||
有关详细信息,请参阅 [API 版本迁移文档](https://cert-manager.io/docs/usage/cmctl/#migrate-api-version)。另请参阅[将 1.5 升级到 1.6](https://cert-manager.io/docs/installation/upgrading/upgrading-1.5-1.6/) 和[将 1.6 升级到到 1.7](https://cert-manager.io/docs/installation/upgrading/upgrading-1.6-1.7/)。
|
||||
|
||||
1. 正常使用 `helm upgrade` 将 cert-manager 升级到 1.7.1。如果需要,你可以直接从版本 1.5 转到 1.7。
|
||||
|
||||
1. 按照 Helm 教程[更新发布清单的 API 版本](https://helm.sh/docs/topics/kubernetes_apis/#updating-api-versions-of-a-release-manifest)。Chart 发布名称为 `release_name=rancher`,发布命名空间为 `release_namespace=cattle-system`。
|
||||
|
||||
1. 在解码后的文件中,搜索 `cert-manager.io/v1beta1` 并将其**替换**为 `cert-manager.io/v1`。
|
||||
|
||||
1. 使用 `helm upgrade` 正常升级 Rancher。
|
||||
|
||||
</details>
|
||||
|
||||
### 验证部署
|
||||
|
||||
安装完 cert-manager 后,你可以通过检查 kube-system 命名空间中正在运行的 Pod 来验证它是否已正确部署:
|
||||
|
||||
```
|
||||
kubectl get pods --namespace cert-manager
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cert-manager-5c6866597-zw7kh 1/1 Running 0 2m
|
||||
cert-manager-cainjector-577f6d9fd7-tr77l 1/1 Running 0 2m
|
||||
cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
|
||||
```
|
||||
|
||||
## Cert-Manager API 变更和数据迁移
|
||||
|
||||
---
|
||||
|
||||
Rancher 现在支持 cert-manager 1.6.2 和 1.7.1。推荐使用 v1.7.x,因为 v 1.6.x 将在 2022 年 3 月 30 日结束生命周期。详情请参见 [cert-manager 文档](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#4-安装-cert-manager)。有关将 cert-manager 从 1.5 升级到 1.6 的说明,请参见上游的 [cert-manager 文档](https://cert-manager.io/docs/installation/upgrading/upgrading-1.5-1.6/)。有关将 cert-manager 从 1.6 升级到 1.7 的说明,请参见上游的 [cert-manager 文档](https://cert-manager.io/docs/installation/upgrading/upgrading-1.6-1.7/)。
|
||||
|
||||
---
|
||||
|
||||
Cert-manager 已经弃用 `certificate.spec.acme.solvers` 字段,而且会在未来的版本中放弃对该字段的支持。
|
||||
|
||||
根据 cert-manager 文档,v0.8 引入了配置 ACME 证书资源的新格式。具体来说,就是移动了 challenge solver 字段。v0.9 新旧格式均支持。请知悉,之后发布的新 cert-manager 版本会放弃对旧格式的支持。Cert-Manager 文档建议你在更新后,将 ACME 颁发者和证书资源更新到新格式。
|
||||
|
||||
如需了解变更细节以及迁移说明,请参见[将 Cert-Manager 从 v0.7 升级到 v0.8](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/)。
|
||||
|
||||
v0.11 版本标志着删除先前 Cert-Manager 版本中使用的 v1alpha1 API,以及将 API 组从 certmanager.k8s.io 更改到 cert-manager.io。
|
||||
|
||||
此外,我们已不再支持 v0.8 版本中已弃用的旧配置格式。换言之,在升级到 v0.11 之前,你必须先为 ACME 发行者使用新的 solver 样式配置格式作为过渡。详情请参见[升级到 v0.8](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/)。
|
||||
|
||||
如需了解变更细节以及迁移说明,请参见[将 Cert-Manager 从 v0.10 升级到 v0.11](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/)。
|
||||
|
||||
如需获得更多信息,请参见 [Cert-Manager 升级](https://cert-manager.io/docs/installation/upgrading/)。
|
||||
|
||||
@@ -0,0 +1,126 @@
|
||||
---
|
||||
title: 升级和回滚 Kubernetes
|
||||
---
|
||||
|
||||
升级到最新版本的 Rancher 之后,下游 Kubernetes 集群可以升级为 Rancher 支持的最新的 Kubernetes 版本。
|
||||
|
||||
Rancher 使用 RKE(Rancher Kubernetes Engine)来预置和编辑 RKE 集群。有关为 RKE 集群配置升级策略的更多信息,请参阅 [RKE 文档](https://rancher.com/docs/rke/latest/en/)。
|
||||
|
||||
|
||||
## 经过测试的 Kubernetes 版本
|
||||
|
||||
Rancher 在发布新版本之前,会对其与 Kubernetes 的最新次要版本进行测试,以确保兼容性。有关各个 Rancher 版本测试了哪些 Kubernetes 版本的详细信息,请参阅[支持维护条款](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/)。
|
||||
|
||||
## 升级的工作原理
|
||||
|
||||
RKE v1.1.0 改变了集群升级的方式。
|
||||
|
||||
在 [RKE 文档](https://rancher.com/docs/rke/latest/en/upgrades/how-upgrades-work)中,你将了解编辑或升级 RKE Kubernetes 集群时会发生的情况。
|
||||
|
||||
|
||||
## 升级的最佳实践
|
||||
|
||||
在升级集群的 Kubernetes 版本时,我们建议你:
|
||||
|
||||
1. 拍一张快照。
|
||||
1. 启动 Kubernetes 升级。
|
||||
1. 如果升级失败,请将集群恢复到升级前的 Kubernetes 版本。这可以通过选择**恢复 etcd 和 Kubernetes 版本**选项来实现。在恢复 etcd 快照 之前,这会将你的集群恢复到升级前的 kubernetes 版本。
|
||||
|
||||
恢复操作将在不处于健康或 active 状态的集群上运行。
|
||||
|
||||
## 升级 Kubernetes 版本
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
- 以下选项适用于 [Rancher 启动的 Kubernetes 集群](../../pages-for-subheaders/launch-kubernetes-with-rancher.md)和[注册的 K3s Kubernetes 集群](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#已注册-rke2-和-k3s-集群的附加功能)。
|
||||
- 以下选项也适用于导入且已注册的 RKE2 集群。如果你从外部云平台导入集群但不注册,你将无法在 Rancher 中升级 Kubernetes 版本。
|
||||
- 在升级 Kubernetes 之前,先[备份你的集群](../../pages-for-subheaders/backup-restore-and-disaster-recovery.md)。
|
||||
|
||||
:::
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面中,进入要升级的集群,然后点击 **⋮ > 编辑配置**。
|
||||
1. 从 **Kubernetes 版本** 下拉列表中,选择要用于集群的 Kubernetes 版本。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**:已开始为集群升级 Kubernetes。
|
||||
|
||||
## 回滚
|
||||
|
||||
你可以将集群恢复到使用先前 Kubernetes 版本的备份。有关详细信息,请参阅:
|
||||
|
||||
- [备份集群](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md#快照工作原理)
|
||||
- [使用备份恢复集群](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md#使用快照恢复集群)
|
||||
|
||||
## 配置升级策略
|
||||
|
||||
从 RKE v1.1.0 开始,我们提供了额外的升级选项,让你更精细地控制升级过程。如果满足[条件和要求](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability),你可以使用这些选项,从而在集群升级期间维持应用的可用性。
|
||||
|
||||
你可以在 Rancher UI 中配置升级策略,也可以通过编辑 `cluster.yml` 来配置策略。编辑 `cluster.yml` 可以配置更多高级选项。
|
||||
|
||||
### 在 Rancher UI 中配置最大不可用的 Worker 节点
|
||||
|
||||
你可以在 Rancher UI 中配置不可用 worker 节点的最大数量。在集群升级期间,worker 节点将按此大小批量升级。
|
||||
|
||||
默认情况下,不可用 worker 节点的最大数量为所有 worker 节点的 10%。此数字可以配置为百分比或整数。当定义为百分比时,批大小会被四舍五入到最近的节点,最小为一个节点。
|
||||
|
||||
要更改 worker 节点的默认数量或百分比:
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面中,进入要升级的集群,然后点击 **⋮ > 编辑配置**。
|
||||
1. 在**升级策略**选项卡中,输入 **Worker 并发**作为固定的数字或百分比。你可以通过将集群中的节点数减去最大不可用节点数来获取该数字。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**:集群更新为使用新的升级策略。
|
||||
|
||||
### 使用 Rancher UI 在升级期间启用节点清空
|
||||
|
||||
默认情况下,RKE 会在升级之前[封锁](https://kubernetes.io/docs/concepts/architecture/nodes/#manual-node-administration)每个节点。默认情况下,[清空](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)会在升级期间被禁用。如果在集群配置中启用了清空,RKE 将在升级之前对节点进行封锁和清空。
|
||||
|
||||
要在集群升级期间清空每个节点:
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面中,进入要启用节点清空的集群,然后点击 **⋮ > 编辑配置**。
|
||||
1. 单击 **⋮ > 编辑**。
|
||||
1. 在**升级策略**选项卡中,转到**清空节点**字段并单击**是**。controlplane 和 worker 节点的清空是单独配置的。
|
||||
1. 配置如何删除 pod 的选项。有关每个选项的详细信息,请参阅[本节](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md#激进和安全的清空选项)。
|
||||
1. (可选)配置宽限期。宽限期是给每个 pod 进行清理的超时时间,能让 pod 有机会优雅地退出。Pod 可能需要完成任何未完成的请求、回滚事务或将状态保存到某些外部存储。如果该值为负数,将使用 pod 中指定的默认值。
|
||||
1. (可选)配置超时,这是在清空放弃之前应该继续等待的时间。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**:集群更新为使用新的升级策略。
|
||||
|
||||
:::note
|
||||
|
||||
目前存在一个[已知问题](https://github.com/rancher/rancher/issues/25478),即使 etcd 和 controlplane 正在被清空, Rancher UI 也不会将它们的状态显示为 drained。
|
||||
|
||||
:::
|
||||
|
||||
### 在升级期间维护应用的可用性
|
||||
|
||||
_从 RKE v1.1.0 起可用_
|
||||
|
||||
在 [RKE 文档](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability/)中,你将了解在升级集群时防止应用停机的要求。
|
||||
|
||||
### 在 cluster.yml 中配置升级策略
|
||||
|
||||
你通过编辑 `cluster.yml` 来获得更高级的升级策略配置选项。
|
||||
|
||||
有关详细信息,请参阅 RKE 文档中的[配置升级策略](https://rancher.com/docs/rke/latest/en/upgrades/configuring-strategy)。这部分还包括一个用于配置升级策略的示例 `cluster.yml`。
|
||||
|
||||
## 故障排除
|
||||
|
||||
如果升级后节点没有出现,`rke up` 命令会出错。
|
||||
|
||||
如果不可用节点的数量超过配置的最大值,则不会进行升级。
|
||||
|
||||
如果升级停止,你可能需要修复不可用节点或将其从集群中删除,然后才能继续升级。
|
||||
|
||||
失败的节点可能处于许多不同的状态:
|
||||
|
||||
- 关机
|
||||
- 不可用
|
||||
- 用户在升级过程中清空了节点,因此节点上没有 kubelet
|
||||
- 升级本身失败
|
||||
|
||||
如果在升级过程中达到最大不可用节点数,Rancher 的下游集群将停留在更新中的状态,并且不会继续升级其他 controlplane 节点。它将继续评估不可用的节点集,以防其中一个节点变得可用。如果无法修复节点,则必须移除节点才能继续升级。
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
title: 在不升级 Rancher 的情况下升级 Kubernetes
|
||||
---
|
||||
|
||||
RKE 元数据功能允许你在新版本 Kubernetes 发布后立即为集群配置新版本,而无需升级 Rancher。此功能对于使用 Kubernetes 的补丁版本非常有用,例如,在原本支持 Kubernetes v1.14.6 的 Rancher Server 版本中,将 Kubernetes 升级到 v1.14.7。
|
||||
|
||||
:::note
|
||||
|
||||
Kubernetes API 可以在次要版本之间更改。因此,我们不支持引入 Kubernetes 次要版本,例如在 Rancher 支持 v1.14 的情况下引入 v1.15。在这种情况下,你需要升级 Rancher 以添加对 Kubernetes 次要版本的支持。
|
||||
|
||||
:::
|
||||
|
||||
Rancher 的 Kubernetes 元数据包含 Rancher 用于配置 [RKE 集群](../../pages-for-subheaders/launch-kubernetes-with-rancher.md)的 Kubernetes 版本信息。Rancher 会定期同步数据并为 **系统镜像**、**服务选项**和**插件模板**创建自定义资源定义 (CRD)。因此,当新的 Kubernetes 版本与 Rancher Server 版本兼容时,Kubernetes 元数据可以使 Rancher 使用新版本来配置集群。元数据概述了 [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/) (RKE) 用于部署各种 Kubernetes 版本的信息。
|
||||
|
||||
下表描述了受周期性数据同步影响的 CRD。
|
||||
|
||||
:::note
|
||||
|
||||
只有管理员可以编辑元数据 CRD。除非明确需要,否则建议不要更新现有对象。
|
||||
|
||||
:::
|
||||
|
||||
| 资源 | 描述 | Rancher API URL |
|
||||
|----------|-------------|-----------------|
|
||||
| 系统镜像 | 用于通过 RKE 部署 Kubernetes 集群的系统镜像列表。 | `<RANCHER_SERVER_URL>/v3/rkek8ssystemimages` |
|
||||
| 服务选项 | 传递给 Kubernetes 组件的默认选项,例如 `kube-api`、`scheduler`、`kubelet`、`kube-proxy` 和 `kube-controller-manager` | `<RANCHER_SERVER_URL>/v3/rkek8sserviceoptions` |
|
||||
| 插件模板 | 用于部署插件组件的 YAML 定义,例如 Canal、Calico、Flannel、Weave、Kube-dns、CoreDNS、`metrics-server`、`nginx-ingress` | `<RANCHER_SERVER_URL>/v3/rkeaddons` |
|
||||
|
||||
管理员可以通过配置 RKE 元数据设置来执行以下操作:
|
||||
|
||||
- 刷新 Kubernetes 元数据。适用于有新的 Kubernetes 补丁版本发布,而用户希望在不升级 Rancher 的情况下为集群配置最新版本的 Kubernetes 的情景。
|
||||
- 更改 Rancher 用于同步元数据的 URL。适用于要让 Rancher 从本地同步而不是与 GitHub 同步的情况。这在离线环境下非常有用。
|
||||
- 防止 Rancher 自动同步元数据。这可以防止在 Rancher 中使用新的/不受支持的 Kubernetes 版本。
|
||||
|
||||
### 刷新 Kubernetes 元数据
|
||||
|
||||
默认情况下,管理员或具有**管理集群驱动**[全局角色](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)的用户,可以刷新 Kubernetes 元数据。
|
||||
|
||||
要强制 Rancher 刷新 Kubernetes 元数据,可以执行手动刷新操作:
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在左侧导航菜单中,单击**驱动**。
|
||||
1. 单击**刷新 Kubernetes 元数据**。
|
||||
|
||||
你可以将 `refresh-interval-minutes` 设置为 `0`(见下文),将 Rancher 配置为仅在需要时刷新元数据,并在需要时使用此按钮手动执行元数据刷新。
|
||||
|
||||
### 配置元数据同步
|
||||
|
||||
:::caution
|
||||
|
||||
只有管理员可以更改这些设置。
|
||||
|
||||
:::
|
||||
|
||||
RKE 元数据的配置控制 Rancher 同步元数据的频率以及从何处下载数据。你可以通过 Rancher UI 或通过 Rancher API 端点 `v3/settings/rke-metadata-config` 配置元数据。
|
||||
|
||||
元数据的配置方式取决于 Rancher 版本。
|
||||
|
||||
要在 Rancher 中编辑元数据配置:
|
||||
|
||||
1. 在左上角,单击 **☰ > 全局设置**。
|
||||
1. 转到 **rke-metadata-config**。单击 **⋮ > 编辑设置**。
|
||||
1. 你可以选择填写以下参数:
|
||||
|
||||
- `refresh-interval-minutes`:Rancher 等待同步元数据的时间。如果要禁用定期刷新,请将 `refresh-interval-minutes` 设置为 0。
|
||||
- `url`:Rancher 从中获取数据的 HTTP 路径。该路径必须是 JSON 文件的直接路径。例如,Rancher v2.4 的默认 URL 是 `https://releases.rancher.com/kontainer-driver-metadata/release-v2.4/data.json`。
|
||||
1. 单击**保存**。
|
||||
|
||||
如果你没有离线设置,则无需指定 Rancher 获取元数据的 URL,因为默认是从 [Rancher 的元数据 Git 仓库获取](https://github.com/rancher/kontainer-driver-metadata/blob/dev-v2.5/data/data.json)的。
|
||||
|
||||
但是,如果你有[离线设置](#离线设置)需求,你需要将 Kubernetes 元数据仓库镜像到 Rancher 可用的位置。然后,你需要更改 URL 来指向 JSON 文件的新位置。
|
||||
|
||||
### 离线设置
|
||||
|
||||
Rancher Server 会定期刷新 `rke-metadata-config` 来下载新的 Kubernetes 版本元数据。有关 Kubernetes 和 Rancher 版本的兼容性表,请参阅[服务条款](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.2.8/)。
|
||||
|
||||
如果你使用离线设置,则可能无法从 Rancher 的 Git 仓库自动定期刷新 Kubernetes 元数据。在这种情况下,应该禁用定期刷新以防止在日志中显示相关错误。或者,你可以配置元数据,以便 Rancher 与本地的 RKE 元数据副本进行同步。
|
||||
|
||||
要将 Rancher 与 RKE 元数据的本地镜像同步,管理员需要配置 `rke-metadata-config` 来指向镜像。详情请参考[配置元数据同步](#配置元数据同步)
|
||||
|
||||
在将新的 Kubernetes 版本加载到 Rancher Server 中之后,需要执行其他步骤才能使用它们启动集群。Rancher 需要访问更新的系统镜像。虽然只有管理员可以更改元数据设置,但任何用户都可以下载 Rancher 系统镜像并为镜像准备私有容器镜像仓库。
|
||||
|
||||
要下载私有镜像仓库的系统镜像:
|
||||
|
||||
1. 点击左上角的 **☰**。
|
||||
1. 点击左侧导航底部的**简介**。
|
||||
1. 下载适用于 Linux 或 Windows 操作系统的镜像。
|
||||
1. 下载 `rancher-images.txt`。
|
||||
1. 使用[离线环境安装](other-installation-methods/air-gapped-helm-cli-install/publish-images.md)时使用的步骤准备私有镜像仓库,但不要使用发布页面中的 `rancher-images.txt`,而是使用上一个步骤中获取的文件。
|
||||
|
||||
**结果**:Rancher 的离线安装现在可以同步 Kubernetes 元数据。如果你在发布新版本的 Kubernetes 时更新了私有镜像仓库,你可以使用新版本配置集群,而无需升级 Rancher。
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: 概述
|
||||
---
|
||||
|
||||
Rancher 是一个为使用容器的公司打造的容器管理平台。Rancher 使得开发者可以随处运行 Kubernetes(Run Kubernetes Everywhere),满足 IT 需求规范,赋能 DevOps 团队。
|
||||
|
||||
## Run Kubernetes Everywhere
|
||||
|
||||
Kubernetes 已经成为容器编排标准。现在,大多数云和虚拟化提供商都提供容器编排服务。Rancher 用户可以选择使用 Rancher Kubernetes Engine(RKE)或云 Kubernetes 服务(例如 GKE、AKS 和 EKS)创建 Kubernetes 集群,还可以导入和管理使用任何 Kubernetes 发行版或安装程序创建的现有 Kubernetes 集群。
|
||||
|
||||
## 满足 IT 需求规范
|
||||
|
||||
Rancher 支持对其控制的所有 Kubernetes 集群进行集中认证、访问控制和监控。例如,你可以:
|
||||
|
||||
- 使用你的 Active Directory 凭证访问由云提供商(例如 GKE)托管的 Kubernetes 集群。
|
||||
- 设置所有用户、组、项目、集群和云服务的权限控制策略和安全策略。
|
||||
- 一站式查看 Kubernetes 集群的运行状况和容量。
|
||||
|
||||
## 赋能 DevOps 团队
|
||||
|
||||
Rancher 为 DevOps 工程师提供简单直接的用户界面,以管理其应用负载。用户不需要对 Kubernetes 有非常深入的了解,即可使用 Rancher。Rancher 应用商店包含一套实用的 DevOps 开发工具。Rancher 获得了多种云原生生态系统产品的认证,包括安全工具、监控系统、容器镜像仓库、存储和网络驱动等。
|
||||
|
||||
下图讲述了 Rancher 在 IT 管理团队和 DevOps 开发团队之间扮演的角色。DevOps 团队把他们的应用部署在他们选择的公有云或私有云上。IT 管理员负责查看并管理用户、集群、云服务的权限。
|
||||
|
||||

|
||||
|
||||
## Rancher API Server 的功能
|
||||
|
||||
Rancher API Server 是基于嵌入式 Kubernetes API Server 和 etcd 数据库建立的,它提供了以下功能:
|
||||
|
||||
### 授权和基于角色的权限控制(RBAC)
|
||||
|
||||
- **用户管理**:Rancher API Server 除了管理本地用户,还[管理用户用来访问外部服务所需的认证信息](../pages-for-subheaders/authentication-config.md),如登录 Active Directory 和 GitHub 所需的账号密码。
|
||||
- **授权**:Rancher API Server 可以管理[访问控制策略](../pages-for-subheaders/manage-role-based-access-control-rbac.md)和[安全策略](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)。
|
||||
|
||||
### 使用 Kubernetes 的功能
|
||||
|
||||
- **配置 Kubernetes 集群**:Rancher API Server 可以在已有节点上[配置 Kubernetes](../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md),或进行 [Kubernetes 版本升级](installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)。
|
||||
- **管理应用商店**:Rancher 支持使用 [Helm Chart 应用商店](../pages-for-subheaders/helm-charts-in-rancher.md)实现轻松重复部署应用。
|
||||
- **管理项目**:项目由集群中多个命名空间和访问控制策略组成,是 Rancher 中的一个概念,Kubernetes 中并没有这个概念。你可以使用项目实现以组为单位,管理多个命名空间,并进行 Kubernetes 相关操作。Rancher UI 提供用于[项目管理](../pages-for-subheaders/manage-projects.md)和[项目内应用管理](../pages-for-subheaders/kubernetes-resources-setup.md)的功能。
|
||||
- **Fleet 持续交付**:在 Rancher 中,你可以使用 [Fleet 持续交付](../pages-for-subheaders/fleet-gitops-at-scale.md)将应用程序从 Git 仓库部署到目标下游 Kubernetes 集群,无需任何手动操作。
|
||||
- **Istio**:[Rancher 与 Istio 集成](../pages-for-subheaders/istio.md),使得管理员或集群所有者可以将 Istio 交给开发者,然后开发者使用 Istio 执行安全策略,排查问题,或为蓝绿部署,金丝雀部署,和 A/B 测试进行流量管理。
|
||||
|
||||
### 配置云基础设施
|
||||
|
||||
- **同步节点信息**:Rancher API Server 可以同步所有集群中全部[节点](../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md)的信息。
|
||||
- **配置云基础设施**:如果你为 Rancher 配置了云提供商,Rancher 可以在云端动态配置[新节点](../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)和[持久化存储](../pages-for-subheaders/create-kubernetes-persistent-storage.md)。
|
||||
|
||||
### 查看集群信息
|
||||
|
||||
- **日志管理**:Rancher 可以与多种 Kubernetes 集群之外的主流日志管理工具集成。
|
||||
- **监控**:你可以使用 Rancher,通过业界领先并开源的 Prometheus 来监控集群节点、Kubernetes 组件和软件部署的状态和进程。
|
||||
- **告警**:为了保证集群和应用的正常运行,提高公司的生产效率,你需要随时了解集群和项目的计划内和非计划事件。
|
||||
|
||||
## 使用 Rancher 编辑下游集群
|
||||
|
||||
对于已有集群而言,可提供的选项和设置取决于你配置集群的方法。例如,只有[通过 RKE 启动](../pages-for-subheaders/launch-kubernetes-with-rancher.md)的集群才有可编辑的**集群选项**。
|
||||
|
||||
使用 Rancher 创建集群后,集群管理员可以管理集群成员,管理节点池,或进行[其他操作](../pages-for-subheaders/cluster-configuration.md)。
|
||||
|
||||
下表总结了每一种类型的集群和对应的可编辑的选项和设置:
|
||||
|
||||
import ClusterCapabilitiesTable from '../shared-files/_cluster-capabilities-table.md';
|
||||
|
||||
<ClusterCapabilitiesTable />
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: Rancher AWS Marketplace 快速入门
|
||||
description: 使用 Amazon EKS 部署 Rancher Server。
|
||||
---
|
||||
|
||||
Amazon Elastic Kubernetes Service (EKS) 可以快速[将 Rancher 部署到 Amazon Web Services (AWS)](https://documentation.suse.com/trd/kubernetes/single-html/gs_rancher_aws-marketplace/)。详情请参见我们的 [Amazon Marketplace 列表](https://aws.amazon.com/marketplace/pp/prodview-go7ent7goo5ae)。观看 [demo](https://youtu.be/9dznJ7Ons0M),了解 AWS Marketplace SUSE Rancher 设置的演练。
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: Rancher AWS 快速入门指南
|
||||
description: 阅读此分步 Rancher AWS 指南,以快速部署带有单节点下游 Kubernetes 集群的 Rancher Server。
|
||||
---
|
||||
|
||||
你可以参考以下步骤,在 AWS 的单节点 K3s Kubernetes 集群中快速部署 Rancher Server,并附加一个单节点下游 Kubernetes 集群。
|
||||
|
||||
:::caution
|
||||
|
||||
本章节中提供的指南,旨在帮助你快速启动一个用于 Rancher 的沙盒,以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导,请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 先决条件
|
||||
|
||||
:::caution
|
||||
|
||||
部署到 Amazon AWS 会产生费用。
|
||||
|
||||
:::
|
||||
|
||||
- [Amazon AWS 账号](https://aws.amazon.com/account/): 用于创建部署 Rancher Server 和 Kubernetes 的资源。
|
||||
- [Amazon AWS 访问密钥](https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html):如果你没有的话,请访问此链接查看相关指南。
|
||||
- [已创建 IAM 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start):定义附加此策略的账号所具有的权限。
|
||||
- [Terraform](https://www.terraform.io/downloads.html): 用于在 Amazon AWS 中配置服务器和集群。
|
||||
|
||||
### IAM 策略示例
|
||||
|
||||
AWS 模块只创建一个 EC2 密钥对、一个 EC2 安全组和一个 EC2 实例。以下是一个简单的策略:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": "ec2:*",
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## 开始使用
|
||||
|
||||
1. 使用命令行工具,执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
|
||||
|
||||
2. 执行 `cd quickstart/rancher/aws` 命令,进入包含 Terraform 文件的 AWS 文件夹。
|
||||
|
||||
3. 把 `terraform.tfvars.example` 文件重命名为 `terraform.tfvars`。
|
||||
|
||||
4. 编辑 `terraform.tfvars` 文件,并替换以下变量:
|
||||
|
||||
- `aws_access_key` - 替换为 Amazon AWS 访问密钥
|
||||
- `aws_secret_key` - 替换为 Amazon AWS Secret 密钥
|
||||
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码(最少 12 字符)
|
||||
|
||||
5. **可选**:修改 `terraform.tfvars` 中的可选参数。参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) 了解更多信息。
|
||||
建议包括:
|
||||
|
||||
- `aws_region` - Amazon AWS 区域。AWS 的默认区域 (`us-east-1`) 不一定是距离你最近的区域。建议修改为距离你最近的区域。
|
||||
- `prefix` - 所有创建资源的前缀
|
||||
- `instance_type` - EC2 使用的实例规格,最小规格为 `t3a.medium` 。如果在预算范围内,可以使用 `t3a.large` 或 `t3a.xlarge`。
|
||||
- `add_windows_node` - 如果设为 true,一个额外的 Windows worker 节点会添加到工作负载集群中。
|
||||
|
||||
6. 执行 `terraform init`。
|
||||
|
||||
7. 执行 `terraform apply --auto-approve` 以初始化环境。然后,等待命令行工具返回以下信息:
|
||||
|
||||
```
|
||||
Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
|
||||
|
||||
Outputs:
|
||||
|
||||
rancher_node_ip = xx.xx.xx.xx
|
||||
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
|
||||
workload_node_ip = yy.yy.yy.yy
|
||||
```
|
||||
|
||||
8. 将以上输出中的 `rancher_server_url` 粘贴到浏览器中。在登录页面中登录(默认用户名为 `admin`,密码为在 `rancher_server_admin_password` 中设置的密码)。
|
||||
9. 使用 `quickstart/rancher/aws` 中生成的 `id_rsa` 密钥 SSH 到 Rancher Server。
|
||||
|
||||
##### 结果
|
||||
|
||||
两个 Kubernetes 集群已部署到你的 AWS 账户中,一个运行 Rancher Server,另一个为实验部署做好准备。请注意,虽然这种设置是探索 Rancher 功能的好方法,但在生产环境中,应遵循我们的高可用设置指南。用于虚拟机的 SSH 密钥是自动生成的,存储在模块目录中。
|
||||
|
||||
## 后续操作
|
||||
|
||||
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
|
||||
|
||||
## 销毁环境
|
||||
|
||||
1. 进入 `quickstart/rancher/aws` 文件夹,然后执行 `terraform destroy --auto-approve`。
|
||||
|
||||
2. 等待命令行界面显示资源已删除的消息。
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: Rancher Azure 快速入门指南
|
||||
description: 阅读此分步 Rancher Azure 指南,以快速部署带有单节点下游 Kubernetes 集群的 Rancher Server。
|
||||
---
|
||||
|
||||
你可以参考以下步骤,在 Azure 的单节点 K3s Kubernetes 集群中快速部署 Rancher Server,并附加一个单节点下游 Kubernetes 集群。
|
||||
|
||||
:::caution
|
||||
|
||||
本章节中提供的指南,旨在帮助你快速启动一个用于 Rancher 的沙盒,以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导,请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 先决条件
|
||||
|
||||
:::caution
|
||||
|
||||
部署到 Microsoft Azure 会产生费用。
|
||||
|
||||
:::
|
||||
|
||||
- [Microsoft Azure 账号](https://azure.microsoft.com/en-us/free/):用于创建部署 Rancher 和 Kubernetes 的资源。
|
||||
- [Microsoft Azure 订阅](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal):如果你没有的话,请访问此链接查看如何创建 Microsoft Azure 订阅。
|
||||
- [Micsoroft Azure 租户](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant):访问此链接并参考教程以创建 Microsoft Azure 租户。
|
||||
- [Microsoft Azure 客户端 ID/密文](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal):访问此链接并参考教程以创建 Microsoft Azure 客户端和密文。
|
||||
- [Terraform](https://www.terraform.io/downloads.html):用于在 Microsoft Azure 中配置服务器和集群。
|
||||
|
||||
|
||||
## 开始使用
|
||||
|
||||
1. 使用命令行工具,执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
|
||||
|
||||
2. 执行 `cd quickstart/rancher/azure` 命令,进入包含 Terraform 文件的 Azure 文件夹。
|
||||
|
||||
3. 把 `terraform.tfvars.example` 文件重命名为 `terraform.tfvars`。
|
||||
|
||||
4. 编辑 `terraform.tfvars` 文件,并替换以下变量:
|
||||
- `azure_subscription_id` - 替换为 Microsoft Azure 订阅 ID。
|
||||
- `azure_client_id` - 替换为 Microsoft Azure 客户端 ID。
|
||||
- `azure_client_secret` - 替换为 Microsoft Azure 客户端密文。
|
||||
- `azure_tenant_id` - 替换为 Microsoft Azure 租户 ID。
|
||||
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码(最少 12 字符)
|
||||
|
||||
5. **可选**:修改 `terraform.tfvars` 中的可选参数。
|
||||
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) 了解更多信息。建议包括:
|
||||
- `azure_location` - Microsoft Azure 区域。Azure 的默认区域 (`East US`) 不一定是距离你最近的区域。建议修改为距离你最近的区域。
|
||||
- `prefix` - 所有创建资源的前缀
|
||||
- `instance_type` - 使用的计算实例大小,最小规格为 `Standard_DS2_v2`。如果在预算范围内,可以使用 `Standard_DS2_v3` 或 `Standard_DS3_v2`。
|
||||
- `add_windows_node` - 如果设为 true,一个额外的 Windows worker 节点会添加到工作负载集群中。
|
||||
- `windows_admin_password` - Windows worker 节点管理员的密码
|
||||
|
||||
6. 执行 `terraform init`。
|
||||
|
||||
7. 执行 `terraform apply --auto-approve` 以初始化环境。然后,等待命令行工具返回以下信息:
|
||||
|
||||
```
|
||||
Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
|
||||
|
||||
Outputs:
|
||||
|
||||
rancher_node_ip = xx.xx.xx.xx
|
||||
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
|
||||
workload_node_ip = yy.yy.yy.yy
|
||||
```
|
||||
|
||||
8. 将以上输出中的 `rancher_server_url` 粘贴到浏览器中。在登录页面中登录(默认用户名为 `admin`,密码为在 `rancher_server_admin_password` 中设置的密码)。
|
||||
9. 使用 `quickstart/rancher/azure` 中生成的 `id_rsa` 密钥 SSH 到 Rancher Server。
|
||||
|
||||
#### 结果
|
||||
|
||||
两个 Kubernetes 集群已部署到你的 Azure 账户中,一个运行 Rancher Server,另一个为实验部署做好准备。请注意,虽然这种设置是探索 Rancher 功能的好方法,但在生产环境中,应遵循我们的高可用设置指南。用于虚拟机的 SSH 密钥是自动生成的,存储在模块目录中。
|
||||
|
||||
### 后续操作
|
||||
|
||||
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
|
||||
|
||||
## 销毁环境
|
||||
|
||||
1. 进入 `quickstart/rancher/azure` 文件夹,然后执行 `terraform destroy --auto-approve`。
|
||||
|
||||
2. 等待命令行界面显示资源已删除的消息。
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: Rancher DigitalOcean 快速入门指南
|
||||
description: 阅读此分步 Rancher DigitalOcean 指南,以快速部署带有单节点下游 Kubernetes 集群的 Rancher Server。
|
||||
---
|
||||
|
||||
你可以参考以下步骤,在 DigitalOcean 的单节点 K3s Kubernetes 集群中快速部署 Rancher Server,并附加一个单节点下游 Kubernetes 集群。
|
||||
|
||||
:::caution
|
||||
|
||||
本章节中提供的指南,旨在帮助你快速启动一个用于 Rancher 的沙盒,以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导,请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 先决条件
|
||||
|
||||
:::caution
|
||||
|
||||
部署到 DigitalOcean 会产生费用。
|
||||
|
||||
:::
|
||||
|
||||
- [DigitalOcean 账号](https://www.digitalocean.com):用于运行服务器和集群。
|
||||
- [DigitalOcean 访问密钥](https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key):如果你没有的话,请访问此链接创建一个。
|
||||
- [Terraform](https://www.terraform.io/downloads.html):用于在 DigitalOcean 中配置服务器和集群。
|
||||
|
||||
|
||||
## 开始使用
|
||||
|
||||
1. 使用命令行工具,执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
|
||||
|
||||
2. 执行 `cd quickstart/rancher/do` 命令,进入包含 Terraform 文件的 DigitalOcean 文件夹。
|
||||
|
||||
3. 把 `terraform.tfvars.example` 文件重命名为 `terraform.tfvars`。
|
||||
|
||||
4. 编辑 `terraform.tfvars` 文件,并替换以下变量:
|
||||
- `do_token` - 替换为 DigitalOcean 访问密钥
|
||||
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码(最少 12 字符)
|
||||
|
||||
5. **可选**:修改 `terraform.tfvars` 中的可选参数。
|
||||
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) 了解更多信息。建议包括:
|
||||
- `do_region` - DigitalOcean 区域。DigitalOcean 的默认区域不一定是距离你最近的区域。建议修改为距离你最近的区域。
|
||||
- `prefix` - 所有创建资源的前缀
|
||||
- `droplet_size` - 使用的计算实例规格,最小规格为`s-2vcpu-4gb`。如果在预算范围内,可以使用 `s-4vcpu-8gb`。
|
||||
|
||||
6. 执行 `terraform init`。
|
||||
|
||||
7. 执行 `terraform apply --auto-approve` 以初始化环境。然后,等待命令行工具返回以下信息:
|
||||
|
||||
```
|
||||
Apply complete! Resources: 15 added, 0 changed, 0 destroyed.
|
||||
|
||||
Outputs:
|
||||
|
||||
rancher_node_ip = xx.xx.xx.xx
|
||||
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
|
||||
workload_node_ip = yy.yy.yy.yy
|
||||
```
|
||||
|
||||
8. 将以上输出中的 `rancher_server_url` 粘贴到浏览器中。在登录页面中登录(默认用户名为 `admin`,密码为在 `rancher_server_admin_password` 中设置的密码)。
|
||||
9. 使用 `quickstart/rancher/do` 中生成的 `id_rsa` 密钥 SSH 到 Rancher Server。
|
||||
|
||||
#### 结果
|
||||
|
||||
两个 Kubernetes 集群已部署到你的 DigitalOcean 账户中,一个运行 Rancher Server,另一个为实验部署做好准备。请注意,虽然这种设置是探索 Rancher 功能的好方法,但在生产环境中,应遵循我们的高可用设置指南。用于虚拟机的 SSH 密钥是自动生成的,存储在模块目录中。
|
||||
|
||||
### 后续操作
|
||||
|
||||
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
|
||||
|
||||
## 销毁环境
|
||||
|
||||
1. 进入 `quickstart/rancher/do` 文件夹,然后执行 `terraform destroy --auto-approve`。
|
||||
|
||||
2. 等待命令行界面显示资源已删除的消息。
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title: Rancher Equinix Metal 快速入门
|
||||
---
|
||||
|
||||
## 本章节引导你:
|
||||
|
||||
- 配置 Equinix Metal server
|
||||
- 安装 Rancher 2.x
|
||||
- 创建你的第一个集群
|
||||
- 部署一个 Nginx 应用
|
||||
|
||||
:::caution
|
||||
|
||||
本章节中提供的指南,旨在帮助你快速启动一个用于 Rancher 的沙盒,以评估 Rancher 是否能满足你的使用需求。不建议将 Docker 安装用于生产环境。如果你需要获取生产环境的操作指导,请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 快速入门概述
|
||||
|
||||
本指南划分为不同任务,以便于使用。
|
||||
|
||||
<br/>
|
||||
|
||||
## 先决条件
|
||||
|
||||
- [Equinix Metal 账号](https://metal.equinix.com/developers/docs/accounts/users/)
|
||||
- [Equinix Metal 项目](https://metal.equinix.com/developers/docs/accounts/projects/)
|
||||
|
||||
|
||||
### 1. 配置 Equinix Metal 主机
|
||||
|
||||
开始部署 Equinix Metal 主机。你可以使用 Equinix Metal 控制台、CLI 或 API 来配置 Equinix Metal Server。如果你需要了解每种 Deployment 类型的说明,请参见 [Equinix Metal 部署](https://metal.equinix.com/developers/docs/deploy/on-demand/)。以下链接介绍 Equinix Metal Server 的类型以及价格:
|
||||
- [Equinix Metal Server 类型](https://metal.equinix.com/developers/docs/servers/about/)
|
||||
- [Equinix Metal 价格](https://metal.equinix.com/developers/docs/servers/server-specs/)
|
||||
|
||||
:::note 注意事项:
|
||||
|
||||
- 如果使用 CLI 或 API 配置新的 Equinix Metal Server,你需要提供项目 ID、计划、metro 和操作系统。
|
||||
- 当使用云主机的虚拟机时,你需要允许 80 和 443 端口的入站 TCP 通信。有关端口配置的信息,请参见你的云主机的文档。
|
||||
- 如需了解所有端口要求,请参见 [Docker 安装](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)。
|
||||
- 根据我们的[要求](../../../pages-for-subheaders/installation-requirements.md)配置主机。
|
||||
|
||||
:::
|
||||
### 2. 安装 Rancher
|
||||
|
||||
要在 Equinix Metal 主机上安装 Rancher,先与它连接,然后使用 shell 进行安装。
|
||||
|
||||
1. 使用你惯用的 shell(例如 PuTTy 或远程终端)登录到你的 Equinix Metal 主机。
|
||||
|
||||
2. 在 shell 中执行以下命令:
|
||||
|
||||
```
|
||||
sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher
|
||||
```
|
||||
|
||||
**结果**:Rancher 已安装。
|
||||
|
||||
### 3. 登录
|
||||
|
||||
登录到 Rancher 后,你还需要进行一些一次性配置。
|
||||
|
||||
1. 打开 Web 浏览器并输入主机的 IP 地址`https://<SERVER_IP>`。
|
||||
|
||||
将 `<SERVER_IP>` 替换为你的主机 IP 地址。
|
||||
|
||||
2. 出现提示时,为默认 `admin` 账号创建密码。
|
||||
|
||||
3. 设置 **Rancher Server URL**。URL 可以是 IP 地址或主机名。需要注意,添加到集群中的每个节点都必须能够连接到此 URL。<br/><br/>如果你在 URL 中使用主机名,则此主机名必须在 DNS 中解析到你需要添加到集群的节点上。
|
||||
|
||||
<br/>
|
||||
|
||||
### 4. 创建集群
|
||||
|
||||
欢迎使用 Rancher!现在,你可以创建你的第一个 Kubernetes 集群了。
|
||||
|
||||
在此任务中,你可以使用**自定义**选项。此选项允许你把 _任意_ Linux 主机(云虚拟机、本地虚拟机或裸机)添加到集群中。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面,点击**创建**。
|
||||
1. 选择**自定义**。
|
||||
1. 输入**集群名称**。
|
||||
1. 点击**下一步**。
|
||||
1. 在**节点角色**中,选择 _全部_ 角色,即 **etcd**,**Control** 和 **Worker**。
|
||||
- **可选**:Rancher 会自动检测用于 Rancher 通信和集群通信的 IP 地址。你可以使用**节点地址**处的`公有地址`和`内网地址`进行覆盖。
|
||||
1. 将注册命令复制到剪贴板。
|
||||
1. 使用你惯用的 shell(例如 PuTTy 或远程终端)登录到你的 Linux 主机。粘贴剪贴板的命令并运行。
|
||||
1. 在 Linux 主机上运行完命令后,单击**完成**。
|
||||
|
||||
**结果**:
|
||||
|
||||
你已创建集群,集群的状态是**配置中**。Rancher 已在你的集群中。
|
||||
|
||||
当集群状态变为 **Active** 后,你可访问集群。
|
||||
|
||||
**Active** 状态的集群会分配到两个项目:
|
||||
|
||||
- `Default`:包含 `default` 命名空间
|
||||
- `System`:包含 `cattle-system`,`ingress-nginx`,`kube-public` 和 `kube-system` 命名空间。
|
||||
|
||||
#### 已完成!
|
||||
|
||||
恭喜!你已创建第一个集群。
|
||||
|
||||
#### 后续操作
|
||||
|
||||
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: Rancher GCP 快速入门指南
|
||||
description: 阅读此分步 Rancher GCP 指南,以快速部署带有单节点下游 Kubernetes 集群的 Rancher Server。
|
||||
---
|
||||
|
||||
你可以参考以下步骤,在 GCP 的单节点 K3s Kubernetes 集群中快速部署 Rancher Server,并附加一个单节点下游 Kubernetes 集群。
|
||||
|
||||
:::caution
|
||||
|
||||
本章节中提供的指南,旨在帮助你快速启动一个用于 Rancher 的沙盒,以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导,请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 先决条件
|
||||
|
||||
:::caution
|
||||
|
||||
部署到 Google GCP 会产生费用。
|
||||
|
||||
:::
|
||||
|
||||
- [Google GCP Account](https://console.cloud.google.com/):用于创建部署 Rancher 和 Kubernetes 的资源。
|
||||
- [Google GCP 项目](https://cloud.google.com/appengine/docs/standard/nodejs/building-app/creating-project):如果你没有的话,请访问此链接查看如何创建 GCP 项目。
|
||||
- [Google GCP ServiceAccount](https://cloud.google.com/iam/docs/creating-managing-service-account-keys):请访问此链接查看如何创建 GCP ServiceAccount 和 Token 文件。
|
||||
- [Terraform](https://www.terraform.io/downloads.html):用于在 Google GCP 中配置服务器和集群。
|
||||
|
||||
|
||||
## 开始使用
|
||||
|
||||
1. 使用命令行工具,执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
|
||||
|
||||
2. 执行 `cd quickstart/rancher/gcp` 命令,进入包含 Terraform 文件的 GCP 文件夹。
|
||||
|
||||
3. 把 `terraform.tfvars.example` 文件重命名为 `terraform.tfvars`。
|
||||
|
||||
4. 编辑 `terraform.tfvars` 文件,并替换以下变量:
|
||||
- `gcp_account_json` - 替换为 GCP ServiceAccount 文件路径和文件名。
|
||||
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码(最少 12 字符)
|
||||
|
||||
5. **可选**:修改 `terraform.tfvars` 中的可选参数。
|
||||
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/gcp) 了解更多信息。
|
||||
建议包括:
|
||||
- `gcp_region` - Google GCP 区域。GCP 的默认区域 (`us-east4`) 不一定是距离你最近的区域。建议修改为距离你最近的区域。
|
||||
- `gcp_zone` - Google GCP 区域。GCP 的默认区域 (`us-east4-a`) 不一定是距离你最近的区域。建议修改为距离你最近的区域。
|
||||
- `prefix` - 所有创建资源的前缀
|
||||
- `machine_type` - 使用的计算实例大小,最小规格为 `n1-standard-1`。如果在预算范围内,可以使用 `n1-standard-2` 或 `n1-standard-4`。
|
||||
|
||||
6. 执行 `terraform init`。
|
||||
|
||||
7. 执行 `terraform apply --auto-approve` 以初始化环境。然后,等待命令行工具返回以下信息:
|
||||
|
||||
```
|
||||
Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
|
||||
|
||||
Outputs:
|
||||
|
||||
rancher_node_ip = xx.xx.xx.xx
|
||||
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
|
||||
workload_node_ip = yy.yy.yy.yy
|
||||
```
|
||||
|
||||
8. 将以上输出中的 `rancher_server_url` 粘贴到浏览器中。在登录页面中登录(默认用户名为 `admin`,密码为在 `rancher_server_admin_password` 中设置的密码)。
|
||||
9. 使用 `quickstart/rancher/gcp` 中生成的 `id_rsa` 密钥 SSH 到 Rancher Server。
|
||||
|
||||
#### 结果
|
||||
|
||||
两个 Kubernetes 集群已部署到你的 GCP 账户中,一个运行 Rancher Server,另一个为实验部署做好准备。请注意,虽然这种设置是探索 Rancher 功能的好方法,但在生产环境中,应遵循我们的高可用设置指南。用于虚拟机的 SSH 密钥是自动生成的,存储在模块目录中。
|
||||
|
||||
### 后续操作
|
||||
|
||||
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
|
||||
|
||||
## 销毁环境
|
||||
|
||||
1. 进入 `quickstart/rancher/gcp` 文件夹,然后执行 `terraform destroy --auto-approve`。
|
||||
|
||||
2. 等待命令行界面显示资源已删除的消息。
|
||||
@@ -0,0 +1,154 @@
|
||||
---
|
||||
title: Helm CLI 快速入门
|
||||
---
|
||||
|
||||
本文提供了快速安装 Rancher 的方法。
|
||||
|
||||
这些说明假设你有一个 Linux 虚拟机,并能从本地工作站与之通信。Rancher 将安装在 Linux 主机上。你将需要检索该主机的 IP 地址,以便从本地工作站访问 Rancher。Rancher 旨在远程管理 Kubernetes 集群,因此 Rancher 管理的任何 Kubernetes 集群也都需要能够访问该 IP 地址。
|
||||
|
||||
我们不建议在本地安装 Rancher,因为它会产生网络问题。如果你在 localhost 上安装 Rancher,Rancher 无法与下游 Kubernetes 集群通信,因此在 localhost 上你无法测试 Rancher 的集群配置和集群管理功能。
|
||||
|
||||
你的 Linux 主机可以位于任何地方。例如,它可以是 Amazon EC2 实例、Digital Ocean Droplet 或 Azure 虚拟机。其他 Rancher 文档也经常称它们为“节点”。部署 Linux 主机的一种方法是设置一个 Amazon EC2 实例,如[本教程](../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md)中所示。
|
||||
|
||||
完整的安装要求在[这里](../../../pages-for-subheaders/installation-requirements.md)。
|
||||
|
||||
## 在 Linux 上安装 K3s
|
||||
|
||||
Rancher 需要安装在支持的 Kubernetes 版本上。如需了解你使用的 Rancher 版本支持哪些 Kubernetes 版本,请参见 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/)。
|
||||
|
||||
如需指定 K3s(Kubernetes)版本,在运行 K3s 安装脚本时使用 `INSTALL_K3S_VERSION` 环境变量(例如 `INSTALL_K3S_VERSION="v1.24.10+k3s1"`)。
|
||||
|
||||
在 Linux 主机上运行以下命令来安装 K3s 集群:
|
||||
|
||||
```
|
||||
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<VERSION> sh -s - server --cluster-init
|
||||
```
|
||||
|
||||
`--cluster-init` 允许 K3s 使用嵌入式 etcd 作为数据存储,并能够转换为 HA 设置。请参阅[嵌入式数据库的高可用性](https://rancher.com/docs/k3s/latest/en/installation/ha-embedded/)。
|
||||
|
||||
保存 Linux 主机的 IP。
|
||||
|
||||
## 将 kubeconfig 保存到你的工作站
|
||||
|
||||
kubeconfig 文件对于访问 Kubernetes 集群非常重要。从 Linux 主机复制 `/etc/rancher/k3s/k3s.yaml` 中的文件,并将其保存到本地工作站的 `~/.kube/config` 目录中。一种方法是使用 `scp` 工具并在本地计算机上运行此命令:
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Mac 和 Linux">
|
||||
|
||||
```
|
||||
scp root@<IP_OF_LINUX_MACHINE>:/etc/rancher/k3s/k3s.yaml ~/.kube/config
|
||||
```
|
||||
|
||||
在某些情况下,它可能需要确保你的 shell 定义了环境变量 `KUBECONFIG=~/.kube/config`,例如,它可以在你的配置文件或 rc 文件中导出。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Windows">
|
||||
|
||||
默认情况下不能识别“scp”命令,所以我们需要先安装一个模块。
|
||||
|
||||
在 Windows Powershell 中:
|
||||
|
||||
```
|
||||
Find-Module Posh-SSH
|
||||
Install-Module Posh-SSH
|
||||
|
||||
## 获取远程 kubeconfig 文件
|
||||
scp root@<IP_OF_LINUX_MACHINE>:/etc/rancher/k3s/k3s.yaml $env:USERPROFILE\.kube\config
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 在 kubeconfig 中编辑 Rancher Server URL
|
||||
|
||||
在 kubeconfig 文件中,你需要将 `server` 字段的值更改为 `<IP_OF_LINUX_NODE>:6443`。你可以通过端口 6443 访问 Kubernetes API Server,通过端口 80 和 443 访问 Rancher Server。你需要进行此编辑,以便你从本地工作站运行 Helm 或 kubectl 命令时,能够与安装了 Rancher 的 Kubernetes 集群进行通信。
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Mac 和 Linux">
|
||||
|
||||
打开 kubeconfig 文件进行编辑的一种方法是使用 Vim:
|
||||
|
||||
```
|
||||
vi ~/.kube/config
|
||||
```
|
||||
|
||||
输入 `i` 以打开 Vim 的插入模式。要保存你的工作,请按 `Esc`。然后输入 `:wq` 并按 `Enter`。
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Windows">
|
||||
|
||||
在 Windows Powershell 中,你可以使用 `notepad.exe` 来编辑 kubeconfig 文件:
|
||||
|
||||
```
|
||||
notepad.exe $env:USERPROFILE\.kube\config
|
||||
```
|
||||
|
||||
编辑完成后,按 `ctrl+s` 或转到 `File > Save` 来保存你的工作。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 使用 Helm 来安装 Rancher
|
||||
|
||||
从本地工作站运行以下命令。你需要先安装 [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) 和 [helm](https://helm.sh/docs/intro/install/):
|
||||
|
||||
:::note
|
||||
|
||||
要查看自定义 cert-manager 安装的选项(包括集群使用 PodSecurityPolicies 的情况),请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
|
||||
|
||||
kubectl create namespace cattle-system
|
||||
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
|
||||
helm repo update
|
||||
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--version v1.11.0
|
||||
|
||||
# Windows Powershell
|
||||
helm install cert-manager jetstack/cert-manager `
|
||||
--namespace cert-manager `
|
||||
--create-namespace `
|
||||
--version v1.11.0
|
||||
```
|
||||
|
||||
安装 Rancher 的最终命令如下。该命令需要一个将流量转发到 Linux 主机的域名。为了简化本教程,你可以使用假域名。`<IP_OF_LINUX_NODE>.sslip.io` 是一个假域名的例子。
|
||||
|
||||
要安装特定的 Rancher 版本,请使用 `--version` 标志(例如,`--version 2.6.6`)。否则,默认安装最新的 Rancher。请参阅[选择 Rancher 版本](../../installation-and-upgrade/resources/choose-a-rancher-version.md)。
|
||||
|
||||
对于 Kubernetes v1.25 或更高版本,使用 Rancher v2.7.2-v2.7.4 时,将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说,这不是必需的,但你仍然可以手动设置该选项。
|
||||
|
||||
请注意,密码至少需要 12 个字符。
|
||||
|
||||
```
|
||||
helm install rancher rancher-latest/rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=<IP_OF_LINUX_NODE>.sslip.io \
|
||||
--set replicas=1 \
|
||||
--set bootstrapPassword=<PASSWORD_FOR_RANCHER_ADMIN>
|
||||
|
||||
# Windows Powershell
|
||||
helm install rancher rancher-latest/rancher `
|
||||
--namespace cattle-system `
|
||||
--set hostname=<IP_OF_LINUX_NODE>.sslip.io `
|
||||
--set replicas=1 `
|
||||
--set bootstrapPassword=<PASSWORD_FOR_RANCHER_ADMIN>
|
||||
```
|
||||
|
||||
现在,如果你在 Web 浏览器中导航到 `<IP_OF_LINUX_NODE>.sslip.io`,你应该会看到 Rancher UI。
|
||||
|
||||
为了简化说明,我们使用了一个假域名和自签名证书来进行安装。因此,你可能需要在 Web 浏览器中添加一个安全例外来查看 Rancher UI。请注意,对于生产安装,你需要具有负载均衡器、真实域名和真实证书的高可用性设置。
|
||||
|
||||
这些说明还省略了完整的安装要求和其他安装选项。如果你对这些步骤有任何疑问,请参阅完整的 [Helm CLI 安装文档](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md)。
|
||||
|
||||
要使用新的 Rancher Server 来启动新的 Kubernetes 集群,你可能需要在 Rancher 中设置云凭证。有关更多信息,请参阅[使用 Rancher 启动 Kubernetes 集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)。
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: Rancher Hetzner Cloud 快速入门指南
|
||||
description: 阅读此分步 Rancher Hetzner Cloud 指南,以快速部署带有单节点下游 Kubernetes 集群的 Rancher Server。
|
||||
---
|
||||
|
||||
你可以参考以下步骤,在 Hetzner Cloud 的单节点 K3s Kubernetes 集群中快速部署 Rancher Server,并附加一个单节点下游 Kubernetes 集群。
|
||||
|
||||
:::caution
|
||||
|
||||
本章节中提供的指南,旨在帮助你快速启动一个用于 Rancher 的沙盒,以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导,请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 先决条件
|
||||
|
||||
:::caution
|
||||
|
||||
部署到 Hetzner Cloud 会产生费用。
|
||||
|
||||
:::
|
||||
|
||||
- [Hetzner Cloud 账号](https://www.hetzner.com):用于运行服务器和集群。
|
||||
- [Hetzner API 访问密钥](https://docs.hetzner.cloud/#getting-started):如果你没有的话,请参考说明创建一个。
|
||||
- [Terraform](https://www.terraform.io/downloads.html):用于在 Hetzner 中配置服务器和集群。
|
||||
|
||||
|
||||
## 开始使用
|
||||
|
||||
1. 使用命令行工具,执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
|
||||
|
||||
2. 执行 `cd quickstart/rancher/hcloud` 命令,进入包含 Terraform 文件的 Hetzner 文件夹。
|
||||
|
||||
3. 把 `terraform.tfvars.example` 文件重命名为 `terraform.tfvars`。
|
||||
|
||||
4. 编辑 `terraform.tfvars` 文件,并替换以下变量:
|
||||
- `hcloud_token` - 替换为 Hetzner API 访问密钥。
|
||||
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码(最少 12 字符)
|
||||
|
||||
5. **可选**:修改 `terraform.tfvars` 中的可选参数。
|
||||
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [Hetzner Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/hcloud) 了解更多信息。
|
||||
建议包括:
|
||||
|
||||
- `prefix` - 所有创建资源的前缀
|
||||
- `instance_type` - 实例类型,至少需要是 `cx21`。
|
||||
- `hcloud_location`- Hetzner Cloud 位置。选择最近的位置,而不是使用默认位置(`fsn1`)。
|
||||
|
||||
6. 执行 `terraform init`。
|
||||
|
||||
7. 执行 `terraform apply --auto-approve` 以初始化环境。然后,等待命令行工具返回以下信息:
|
||||
|
||||
```
|
||||
Apply complete! Resources: 15 added, 0 changed, 0 destroyed.
|
||||
|
||||
Outputs:
|
||||
|
||||
rancher_node_ip = xx.xx.xx.xx
|
||||
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
|
||||
workload_node_ip = yy.yy.yy.yy
|
||||
```
|
||||
|
||||
8. 将以上输出中的 `rancher_server_url` 粘贴到浏览器中。在登录页面中登录(默认用户名为 `admin`,密码为在 `rancher_server_admin_password` 中设置的密码)。
|
||||
9. 使用 `quickstart/rancher/hcloud` 中生成的 `id_rsa` 密钥 SSH 到 Rancher Server。
|
||||
|
||||
#### 结果
|
||||
|
||||
两个 Kubernetes 集群已部署到你的 Hetzner 账户中,一个运行 Rancher Server,另一个为实验部署做好准备。请注意,虽然这种设置是探索 Rancher 功能的好方法,但在生产环境中,应遵循我们的高可用设置指南。用于虚拟机的 SSH 密钥是自动生成的,存储在模块目录中。
|
||||
|
||||
### 后续操作
|
||||
|
||||
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
|
||||
|
||||
## 销毁环境
|
||||
|
||||
1. 进入 `quickstart/rancher/hcloud` 文件夹,然后执行 `terraform destroy --auto-approve`。
|
||||
|
||||
2. 等待命令行界面显示资源已删除的消息。
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: Rancher Outscale 快速入门指南
|
||||
description: 阅读此分步 Rancher Outscale 指南,以快速部署带有单节点下游 Kubernetes 集群的 Rancher Server。
|
||||
---
|
||||
|
||||
你可以参考以下步骤,在 Outscale 的单节点 K3s Kubernetes 集群中快速部署 Rancher Server,并附加一个单节点下游 Kubernetes 集群。
|
||||
|
||||
:::note
|
||||
|
||||
本章节中提供的指南,旨在帮助你快速启动一个用于 Rancher 的沙盒,以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导,请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 先决条件
|
||||
|
||||
:::caution
|
||||
|
||||
部署到 Outscale 会产生费用。
|
||||
|
||||
:::
|
||||
|
||||
- [Outscale 账号](https://en.outscale.com/):用于运行服务器和集群。
|
||||
- [Outscale 访问密钥](https://docs.outscale.com/en/userguide/About-Access-Keys.html):如果你没有的话,请按照说明创建一个 Outscale 访问密钥。
|
||||
- [Terraform](https://www.terraform.io/downloads.html):用于在 Outscale 中配置服务器和集群。
|
||||
|
||||
|
||||
## 开始使用
|
||||
|
||||
1. 使用命令行工具,执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
|
||||
|
||||
2. 执行 `cd quickstart/rancher/outscale` 命令,进入包含 Terraform 文件的 Outscale 文件夹。
|
||||
|
||||
3. 把 `terraform.tfvars.example` 文件重命名为 `terraform.tfvars`。
|
||||
|
||||
4. 编辑 `terraform.tfvars` 文件,并替换以下变量:
|
||||
- `access_key_id` - 替换为 Outscale 访问密钥
|
||||
- `secret_key_id` - 替换为 Outscale 密文密钥
|
||||
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码(最少 12 字符)
|
||||
|
||||
5. **可选**:修改 `terraform.tfvars` 中的可选参数。
|
||||
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [Outscale Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/outscale) 了解更多信息。
|
||||
建议包括:
|
||||
- `region` - Outscale 区域。Outscale 的默认区域不一定是距离你最近的区域。建议修改为距离你最近的区域(`eu-west-2`)。
|
||||
- `prefix` - 所有创建资源的前缀
|
||||
- `instance_type` - 实例类型,至少需要是 `tinav3.c2r4p3`。
|
||||
|
||||
6. 执行 `terraform init`。
|
||||
|
||||
7. 执行 `terraform apply --auto-approve` 以初始化环境。然后,等待命令行工具返回以下信息:
|
||||
|
||||
```
|
||||
Apply complete! Resources: 21 added, 0 changed, 0 destroyed.
|
||||
|
||||
Outputs:
|
||||
|
||||
rancher_node_ip = xx.xx.xx.xx
|
||||
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
|
||||
workload_node_ip = yy.yy.yy.yy
|
||||
```
|
||||
|
||||
8. 将以上输出中的 `rancher_server_url` 粘贴到浏览器中。在登录页面中登录(默认用户名为 `admin`,密码为在 `rancher_server_admin_password` 中设置的密码)。
|
||||
9. 使用 `quickstart/rancher/outscale` 中生成的 `id_rsa` 密钥 SSH 到 Rancher Server。
|
||||
|
||||
#### 结果
|
||||
|
||||
两个 Kubernetes 集群已部署到你的 Outscale 账户中,一个运行 Rancher Server,另一个为实验部署做好准备。请注意,虽然这种设置是探索 Rancher 功能的好方法,但在生产环境中,应遵循我们的高可用设置指南。用于虚拟机的 SSH 密钥是自动生成的,存储在模块目录中。
|
||||
|
||||
### 后续操作
|
||||
|
||||
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
|
||||
|
||||
## 销毁环境
|
||||
|
||||
1. 进入 `quickstart/rancher/outscale` 文件夹,然后执行 `terraform destroy --auto-approve`。
|
||||
|
||||
2. 等待命令行界面显示资源已删除的消息。
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
title: Rancher Prime
|
||||
---
|
||||
|
||||
Rancher 在 v2.7 中引入了 Rancher Prime,这是 Rancher 企业级产品的进化。Rancher Prime 是基于相同源代码构建的商业化、企业级的新版本。因此,Rancher 的产品将继续保持 100% 开源,并通过安全、延长生命周期、访问重点架构和 Kubernetes 公告体现额外价值。Rancher Prime 还将提供选项,让用户获得创新 Rancher 项目的生产支持。使用 Rancher Prime,安装 asset 会托管在由 Rancher 持有和管理的可信镜像仓库中。
|
||||
|
||||
要开始使用 Rancher Prime,请[转到此页面](https://www.rancher.com/quick-start)并填写表格。
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Vagrant 快速入门
|
||||
---
|
||||
|
||||
你可以参考以下步骤快速部署 Rancher Server,并附加一个单节点集群。
|
||||
|
||||
:::caution
|
||||
|
||||
本章节中提供的指南,旨在帮助你快速启动一个用于 Rancher 的沙盒,以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导,请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 先决条件
|
||||
|
||||
- [Vagrant](https://www.vagrantup.com):Vagrant 是必需的,用于根据 Vagrantfile 配置主机。
|
||||
- [Virtualbox](https://www.virtualbox.org):需要把 Vagrant 配置的虚拟机配置到 VirtualBox。
|
||||
- 至少 4GB 的可用内存。
|
||||
|
||||
### 注意
|
||||
- Vagrant 需要使用插件来创建 VirtualBox 虚拟机。请执行以下命令进行安装:
|
||||
|
||||
`vagrant plugin install vagrant-vboxmanage`
|
||||
|
||||
`vagrant plugin install vagrant-vbguest`
|
||||
|
||||
## 开始使用
|
||||
|
||||
1. 使用命令行工具,执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
|
||||
|
||||
2. 执行 `cd quickstart/rancher/vagrant` 命令,进入包含 Vagrantfile 文件的文件夹。
|
||||
|
||||
3. **可选**:编辑 `config.yaml` 文件:
|
||||
|
||||
- 根据需要更改节点数和内存分配(`node.count`, `node.cpus`, `node.memory`)
|
||||
- 更改 `admin` 的密码以登录 Rancher。(`admin_password`)
|
||||
|
||||
4. 执行 `vagrant up --provider=virtualbox` 以初始化环境。
|
||||
|
||||
5. 配置完成后,在浏览器中打开 `https://192.168.56.101`。默认的用户名和密码是 `admin/adminPassword`。
|
||||
|
||||
**结果**:Rancher Server 和你的 Kubernetes 集群已安装在 VirtualBox 上。
|
||||
|
||||
### 后续操作
|
||||
|
||||
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
|
||||
|
||||
## 销毁环境
|
||||
|
||||
1. 进入 `quickstart/rancher/vagrant` 文件夹,然后执行 `vagrant destroy -f`。
|
||||
|
||||
2. 等待所有资源已删除的确认消息。
|
||||
@@ -0,0 +1,138 @@
|
||||
---
|
||||
title: 部署带有 NodePort 的工作负载
|
||||
---
|
||||
|
||||
### 先决条件
|
||||
|
||||
你已有一个正在运行的集群,且该集群中有至少一个节点。
|
||||
|
||||
### 1. 部署工作负载
|
||||
|
||||
你可以开始创建你的第一个 Kubernetes [工作负载](https://kubernetes.io/docs/concepts/workloads/)。工作负载是一个对象,其中包含 pod 以及部署应用所需的其他文件和信息。
|
||||
|
||||
在本文的工作负载中,你将部署一个 Rancher Hello-World 应用。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面中,进入需要部署工作负载的集群,然后单击 **Explore**。
|
||||
1. 点击**工作负载**。
|
||||
1. 单击**创建**。
|
||||
1. 为工作负载设置**名称**。
|
||||
1. 在**容器镜像**字段中,输入 `rancher/hello-world`。注意区分大小写。
|
||||
1. 点击**添加端口**。
|
||||
1. 在**服务类型**下拉菜单中,确保选择了 **NodePort**。
|
||||
|
||||

|
||||
|
||||
1. 在**发布容器端口**字段中,输入端口`80`。
|
||||
|
||||

|
||||
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**:
|
||||
|
||||
* 工作负载已部署。此过程可能需要几分钟。
|
||||
* 当工作负载完成部署后,它的状态会变为 **Active**。你可以从项目的**工作负载**页面查看其状态。
|
||||
|
||||
<br/>
|
||||
|
||||
### 2. 查看应用
|
||||
|
||||
在**工作负载**页面中,点击工作负载下方的链接。如果 deployment 已完成,你的应用会打开。
|
||||
|
||||
### 注意事项
|
||||
|
||||
如果使用云虚拟机,你可能无法访问运行容器的端口。这种情况下,你可以使用 `Execute Shell` 在本地主机的 SSH 会话中测试 Nginx。如果可用的话,使用工作负载下方的链接中 `:` 后面的端口号。在本例中,端口号为 `31568`。
|
||||
|
||||
```html
|
||||
gettingstarted@rancher:~$ curl http://localhost:31568
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>Rancher</title>
|
||||
<link rel="icon" href="img/favicon.png">
|
||||
<style>
|
||||
body {
|
||||
background-color: white;
|
||||
text-align: center;
|
||||
padding: 50px;
|
||||
font-family: "Open Sans","Helvetica Neue",Helvetica,Arial,sans-serif;
|
||||
}
|
||||
button {
|
||||
background-color: #0075a8;
|
||||
border: none;
|
||||
color: white;
|
||||
padding: 15px 32px;
|
||||
text-align: center;
|
||||
text-decoration: none;
|
||||
display: inline-block;
|
||||
font-size: 16px;
|
||||
}
|
||||
|
||||
#logo {
|
||||
margin-bottom: 40px;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<img id="logo" src="img/rancher-logo.svg" alt="Rancher logo" width=400 />
|
||||
<h1>Hello world!</h1>
|
||||
<h3>My hostname is hello-world-66b4b9d88b-78bhx</h3>
|
||||
<div id='Services'>
|
||||
<h3>k8s services found 2</h3>
|
||||
|
||||
<b>INGRESS_D1E1A394F61C108633C4BD37AEDDE757</b> tcp://10.43.203.31:80<br />
|
||||
|
||||
<b>KUBERNETES</b> tcp://10.43.0.1:443<br />
|
||||
|
||||
</div>
|
||||
<br />
|
||||
|
||||
<div id='rancherLinks' class="row social">
|
||||
<a class="p-a-xs" href="https://rancher.com/docs"><img src="img/favicon.png" alt="Docs" height="25" width="25"></a>
|
||||
<a class="p-a-xs" href="https://slack.rancher.io/"><img src="img/icon-slack.svg" alt="slack" height="25" width="25"></a>
|
||||
<a class="p-a-xs" href="https://github.com/rancher/rancher"><img src="img/icon-github.svg" alt="github" height="25" width="25"></a>
|
||||
<a class="p-a-xs" href="https://twitter.com/Rancher_Labs"><img src="img/icon-twitter.svg" alt="twitter" height="25" width="25"></a>
|
||||
<a class="p-a-xs" href="https://www.facebook.com/rancherlabs/"><img src="img/icon-facebook.svg" alt="facebook" height="25" width="25"></a>
|
||||
<a class="p-a-xs" href="https://www.linkedin.com/groups/6977008/profile"><img src="img/icon-linkedin.svg" height="25" alt="linkedin" width="25"></a>
|
||||
</div>
|
||||
<br />
|
||||
<button class='button' onclick='myFunction()'>Show request details</button>
|
||||
<div id="reqInfo" style='display:none'>
|
||||
<h3>Request info</h3>
|
||||
<b>Host:</b> 172.22.101.111:31411 <br />
|
||||
<b>Pod:</b> hello-world-66b4b9d88b-78bhx </b><br />
|
||||
|
||||
<b>Accept:</b> [*/*]<br />
|
||||
|
||||
<b>User-Agent:</b> [curl/7.47.0]<br />
|
||||
|
||||
</div>
|
||||
<br />
|
||||
<script>
|
||||
function myFunction() {
|
||||
var x = document.getElementById("reqInfo");
|
||||
if (x.style.display === "none") {
|
||||
x.style.display = "block";
|
||||
} else {
|
||||
x.style.display = "none";
|
||||
}
|
||||
}
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
gettingstarted@rancher:~$
|
||||
|
||||
```
|
||||
|
||||
### 已完成!
|
||||
|
||||
恭喜!你已成功通过 NodePort 部署工作负载。
|
||||
|
||||
#### 后续操作
|
||||
|
||||
使用完沙盒后,你需要清理 Rancher Server 和集群。详情请参见:
|
||||
|
||||
- [Amazon AWS:销毁环境](../deploy-rancher-manager/aws.md#销毁环境)
|
||||
- [DigitalOcean:销毁环境](../deploy-rancher-manager/digitalocean.md#销毁环境)
|
||||
- [Vagrant:销毁环境](../deploy-rancher-manager/vagrant.md#销毁环境)
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: 部署带有 Ingress 的工作负载
|
||||
---
|
||||
|
||||
### 先决条件
|
||||
|
||||
你已有一个正在运行的集群,且该集群中有至少一个节点。
|
||||
|
||||
### 1. 部署工作负载
|
||||
|
||||
你可以开始创建你的第一个 Kubernetes [工作负载](https://kubernetes.io/docs/concepts/workloads/)。工作负载是一个对象,其中包含 pod 以及部署应用所需的其他文件和信息。
|
||||
|
||||
在本文的工作负载中,你将部署一个 Rancher Hello-World 应用。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 点击**工作负载**。
|
||||
1. 单击**创建**。
|
||||
1. 点击 **Deployment**。
|
||||
1. 为工作负载设置**名称**。
|
||||
1. 在**容器镜像**字段中,输入 `rancher/hello-world`。注意区分大小写。
|
||||
1. 在 `Service Type` 点击 **Add Port** 和 `Cluster IP`,并在 **Private Container Port** 字段中输入`80`。你可以将 `Name` 留空或指定名称。通过添加端口,你可以访问集群内外的应用。有关详细信息,请参阅 [Service](../../../pages-for-subheaders/workloads-and-pods.md#services)。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**:
|
||||
|
||||
* 工作负载已部署。此过程可能需要几分钟。
|
||||
* 当工作负载完成部署后,它的状态会变为 **Active**。你可以从项目的**工作负载**页面查看其状态。
|
||||
|
||||
### 2. 通过 Ingress 暴露应用
|
||||
|
||||
现在应用已启动并运行,你需要暴露应用以让其他服务连接到它。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
|
||||
1. 点击**服务发现 > Ingresses**。
|
||||
|
||||
1. 点击**创建**。
|
||||
|
||||
1. 在选择**命名空间**时,你需要选择在创建 deployment 时使用的命名空间。否则,在步骤8中选择**目标服务**时,你的 deployment 会不可用。
|
||||
|
||||
1. 输入**名称**,例如 **hello**。
|
||||
|
||||
1. 指定**路径**,例如 `/hello`。
|
||||
|
||||
1. 在**目标服务**字段的下拉菜单中,选择你为服务设置的名称。
|
||||
|
||||
1. 在**端口**字段中的下拉菜单中,选择 `80`。
|
||||
|
||||
1. 点击右下角的**创建**。
|
||||
|
||||
**结果**:应用分配到了一个 `sslip.io` 地址并暴露。这可能需要一两分钟。
|
||||
|
||||
|
||||
### 查看应用
|
||||
|
||||
在 **Deployments** 页面中,找到你 deployment 的 **endpoint** 列,然后单击一个 endpoint。可用的 endpoint 取决于你添加到 deployment 中的端口配置。如果你看不到随机分配端口的 endpoint,请将你在创建 Ingress 时指定的路径尾附到 IP 地址上。例如,如果你的 endpoint 是 `xxx.xxx.xxx.xxx` 或 `https://xxx.xxx.xxx.xxx`,把它修改为 `xxx.xxx.xxx.xxx/hello` 或 `https://xxx.xxx.xxx.xxx/hello`。
|
||||
|
||||
应用将在另一个窗口中打开。
|
||||
|
||||
#### 已完成!
|
||||
|
||||
恭喜!你已成功通过 Ingress 部署工作负载。
|
||||
|
||||
#### 后续操作
|
||||
|
||||
使用完沙盒后,你需要清理 Rancher Server 和集群。详情请参见:
|
||||
|
||||
- [Amazon AWS:销毁环境](../deploy-rancher-manager/aws.md#销毁环境)
|
||||
- [DigitalOcean:销毁环境](../deploy-rancher-manager/digitalocean.md#销毁环境)
|
||||
- [Vagrant:销毁环境](../deploy-rancher-manager/vagrant.md#销毁环境)
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: 为定时扫描配置告警
|
||||
---
|
||||
|
||||
你可以定时运行 ClusterScan。
|
||||
|
||||
你还可以为定时扫描指定是否在扫描完成时发出告警。
|
||||
|
||||
只有定时运行的扫描才支持告警。
|
||||
|
||||
CIS Benchmark 应用支持两种类型的告警:
|
||||
|
||||
- 扫描完成告警:此告警在扫描运行完成时发出。告警包括详细信息,包括 ClusterScan 的名称和 ClusterScanProfile 的名称。
|
||||
- 扫描失败告警:如果扫描中有一些测试失败或扫描处于 `Fail` 状态,则会发出此告警。
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
为 `rancher-cis-benchmark` 启用告警之前,确保安装了 `rancher-monitoring` 应用并配置了接收器(Receiver)和路由(Route)。详情请参见[本章节](../../../reference-guides/monitoring-v2-configuration/receivers.md)。
|
||||
|
||||
在为 `rancher-cis-benchmark` 告警配置路由时,你可以使用键值对 `job:rancher-cis-scan` 来指定匹配。详情请查看[路由配置示例](../../../reference-guides/monitoring-v2-configuration/receivers.md#cis-扫描告警的示例路由配置)。
|
||||
|
||||
:::
|
||||
|
||||
要为定时运行的扫描配置告警:
|
||||
|
||||
1. 请在 `rancher-cis-benchmark` 应用程序上启用告警。详情请参见[本页](../../../how-to-guides/advanced-user-guides/cis-scan-guides/enable-alerting-for-rancher-cis-benchmark.md)。
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要运行 CIS 扫描的集群,然后单击 **Explore**。
|
||||
1. 点击 **CIS Benchmark > 扫描**。
|
||||
1. 单击**创建**。
|
||||
1. 选择集群扫描配置文件。该配置文件确定要使用哪个 CIS Benchmark 版本以及要执行哪些测试。如果你选择 Default 配置文件,则 CIS Operator 将选择适用于它所在的 Kubernetes 集群类型的配置文件。
|
||||
1. 选择**定时运行扫描**的选项。
|
||||
1. 在**调度**字段中输入有效的 [Cron 表达式](https://en.wikipedia.org/wiki/Cron#CRON_expression)。
|
||||
1. 选中**告警**下告警类型旁边的框。
|
||||
1. (可选)选择一个**保留计数**,表示为这个定时扫描维护的报告数量。默认情况下,此计数为 3。超过此保留限制时,旧报告将被删除。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**:扫描运行,并根据设置的 cron 表达式重新调度。如果在 `rancher-monitoring` 应用下配置了路由和接收器,则会在扫描完成时发出告警。
|
||||
|
||||
每次运行扫描都会生成一份带有扫描结果的报告。如需查看最新的结果,请单击显示的扫描名称。
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 为集群扫描创建自定义 Benchmark 版本
|
||||
---
|
||||
|
||||
某些 Kubernetes 集群可能需要自定义配置 Benchmark 测试。例如,Kubernetes 配置文件或证书的路径可能与上游 CIS Benchmark 的标准位置不同。
|
||||
|
||||
现在,你可以使用 `rancher-cis-benchmark` 应用来创建自定义 Benchmark 版本,从而运行集群扫描。
|
||||
|
||||
有关详细信息,请参阅[此页面](../../../integrations-in-rancher/cis-scans/custom-benchmark.md)。
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 为 Rancher CIS Benchmark 启用告警
|
||||
---
|
||||
|
||||
你可以配置告警,从而将告警发送给定时运行的扫描。
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
为 `rancher-cis-benchmark` 启用告警之前,确保安装了 `rancher-monitoring` 应用并配置了接收器(Receiver)和路由(Route)。详情请参见[本章节](../../../reference-guides/monitoring-v2-configuration/receivers.md)。
|
||||
|
||||
在为 `rancher-cis-benchmark` 告警配置路由时,你可以使用键值对 `job:rancher-cis-scan` 来指定匹配。详情请查看[路由配置示例](../../../reference-guides/monitoring-v2-configuration/receivers.md#cis-扫描告警的示例路由配置)。
|
||||
|
||||
:::
|
||||
|
||||
在安装或升级 `rancher-cis-benchmark` Helm Chart 时,在 `values.yaml` 中将以下标志设置为 `true`:
|
||||
|
||||
```yaml
|
||||
alerts:
|
||||
enabled: true
|
||||
```
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: 安装 Rancher CIS Benchmark
|
||||
---
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要安装 CIS Benchmark 的集群,然后单击 **Explore**。
|
||||
1. 在左侧导航栏中,单击 **Apps > Charts**。
|
||||
1. 单击 **CIS Benchmark**。
|
||||
1. 单击**安装**。
|
||||
|
||||
**结果**:CIS 扫描应用已经部署在 Kubernetes 集群上。
|
||||
|
||||
:::note
|
||||
|
||||
如果你使用 Kubernetes v1.24 或更早版本,并且具有使用 [Pod 安全策略](../../new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) (PSP) 加固的集群,则 CIS Benchmark 4.0.0 及更高版本会默认禁用 PSP。要在 PSP 加固集群上安装 CIS Benchmark,请在安装 Chart 之前将 values 中的 `global.psp.enabled` 设置为 `true`。[Pod 安全准入](../../new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards.md) (PSA) 加固集群不受影响。
|
||||
|
||||
:::
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 定时运行扫描
|
||||
---
|
||||
|
||||
要定时运行 ClusterScan:
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要运行 CIS 扫描的集群,然后单击 **Explore**。
|
||||
1. 点击 **CIS Benchmark > 扫描**。
|
||||
1. 选择集群扫描配置文件。该配置文件确定要使用哪个 CIS Benchmark 版本以及要执行哪些测试。如果你选择 Default 配置文件,则 CIS Operator 将选择适用于它所在的 Kubernetes 集群类型的配置文件。
|
||||
1. 选择**定时运行扫描**的选项。
|
||||
1. 将一个有效的 <a href="https://en.wikipedia.org/wiki/Cron#CRON_expression" target="_blank">Cron 表达式</a>填写到**调度**字段。
|
||||
1. 选择一个**保留计数**,表示为这个定时扫描维护的报告数量。默认情况下,此计数为 3。超过此保留限制时,旧报告将被删除。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**:扫描运行,并根据设置的 cron 表达式重新调度。**下一次扫描**的值表示下次运行此扫描的时间。
|
||||
|
||||
每次运行扫描都会生成一份带有扫描结果的报告。如需查看最新的结果,请单击显示的扫描名称。
|
||||
|
||||
你还可以在扫描详情页面上的**报告**下拉菜单中查看之前的报告。
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: 运行扫描
|
||||
---
|
||||
|
||||
创建 ClusterScan 自定义资源后,它会在集群上为所选 ClusterScanProfile 启动新的 CIS 扫描。
|
||||
|
||||
:::note
|
||||
|
||||
请注意,目前一个集群每次只能运行一次 CIS 扫描。如果你创建了多个 ClusterScan 自定义资源,operator 只能一个接一个地运行这些资源。一个扫描完成之前,其余 ClusterScan 自定义资源将处于 “Pending” 状态。
|
||||
|
||||
:::
|
||||
|
||||
要运行扫描:
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要运行 CIS 扫描的集群,然后单击 **Explore**。
|
||||
1. 点击 **CIS Benchmark > 扫描**。
|
||||
1. 单击**创建**。
|
||||
1. 选择集群扫描配置文件。该配置文件确定要使用哪个 CIS Benchmark 版本以及要执行哪些测试。如果你选择 Default 配置文件,则 CIS Operator 将选择适用于它所在的 Kubernetes 集群类型的配置文件。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**:已生成带有扫描结果的报告。如需查看结果,请单击显示的扫描名称。
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: 跳过测试
|
||||
---
|
||||
|
||||
用户可以在测试配置文件中自定义要跳过的测试,然后 CIS 扫描可以使用该配置文件运行。
|
||||
|
||||
要跳过测试,你需要创建自定义一个 CIS 扫描配置文件。配置文件包含 CIS 扫描的配置,包括要使用的 Benchmark 测试版本以及要在该 Benchmark 测试中跳过的测试。
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要运行 CIS 扫描的集群,然后单击 **Explore**。
|
||||
1. 单击 **CIS Benchmark > 配置文件**。
|
||||
1. 在这里,你可以使用多种方式来创建配置文件。要创建新配置文件,单击**创建**并在 UI 中填写表单。要基于现有配置文件来创建新配置文件,请转到现有配置文件并单击**⋮ 克隆**。如果你在填写表单,请使用测试 ID 添加要跳过的测试,并参考相关的 CIS Benchmark。如果你将新的测试配置文件创建为 YAML,你需要在 `skipTests` 参数中添加要跳过的测试的 ID。你还需要为配置文件命名:
|
||||
|
||||
```yaml
|
||||
apiVersion: cis.cattle.io/v1
|
||||
kind: ClusterScanProfile
|
||||
metadata:
|
||||
annotations:
|
||||
meta.helm.sh/release-name: clusterscan-operator
|
||||
meta.helm.sh/release-namespace: cis-operator-system
|
||||
labels:
|
||||
app.kubernetes.io/managed-by: Helm
|
||||
name: "<example-profile>"
|
||||
spec:
|
||||
benchmarkVersion: cis-1.5
|
||||
skipTests:
|
||||
- "1.1.20"
|
||||
- "1.1.21"
|
||||
```
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**:已创建一个新的 CIS 扫描配置文件。
|
||||
|
||||
使用此配置文件[运行扫描](./run-a-scan.md)时,会跳过定义的跳过测试。跳过的测试将在生成的报告中标记为 `Skip`。
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 卸载 Rancher CIS Benchmark
|
||||
---
|
||||
|
||||
1. 在**集群**仪表板中,单击左侧导航的 **Apps > Installed Apps**。
|
||||
1. 前往 `cis-operator-system` 命名空间,并选中 `rancher-cis-benchmark-crd` 和 `rancher-cis-benchmark` 旁边的框。
|
||||
1. 单击**删除**并确认**删除**。
|
||||
|
||||
**结果**:已卸载 `rancher-cis-benchmark` 应用。
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: 查看报告
|
||||
---
|
||||
|
||||
要查看生成的 CIS 扫描报告:
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要运行 CIS 扫描的集群,然后单击 **Explore**。
|
||||
1. 点击 **CIS Benchmark > 扫描**。
|
||||
1. **扫描**页面将显示生成的报告。要查看详细报告,请转到扫描报告并单击报告名称。
|
||||
|
||||
你可以从扫描列表或扫描详情页面下载报告。
|
||||
@@ -0,0 +1,260 @@
|
||||
---
|
||||
title: 7 层 NGINX 负载均衡器上的 TLS 终止(Docker 安装)
|
||||
---
|
||||
|
||||
如果你的开发或测试环境要求在负载均衡器上终止 TLS/SSL,而不是在 Rancher Server 上,请部署 Rancher 并配置负载均衡器。
|
||||
|
||||
如果要在基础设施中对 TLS 集中进行终止,请使用 7 层负载均衡器。7 层负载均衡还能让你的负载均衡器基于 HTTP 属性(例如 cookie 等)做出决策,而 4 层负载均衡器则不能。
|
||||
|
||||
本文中的安装步骤将引导你使用单个容器部署 Rancher,并提供 7 层 NGINX 负载均衡器的示例配置。
|
||||
|
||||
## 操作系统,Docker,硬件和网络要求
|
||||
|
||||
请确保你的节点满足常规的[安装要求](../../pages-for-subheaders/installation-requirements.md)。
|
||||
|
||||
## 安装概要
|
||||
|
||||
|
||||
## 1. 配置 Linux 主机
|
||||
|
||||
根据我们的[要求](../../pages-for-subheaders/installation-requirements.md)配置一个 Linux 主机来启动 Rancher Server。
|
||||
|
||||
## 2. 选择一个 SSL 选项并安装 Rancher
|
||||
|
||||
出于安全考虑,使用 Rancher 时请使用 SSL(Secure Sockets Layer)。SSL 保护所有 Rancher 网络通信(如登录和与集群交互)的安全。
|
||||
|
||||
:::note 你是否需要:
|
||||
|
||||
- 完成离线安装。
|
||||
- 记录所有 Rancher API 的事务。
|
||||
|
||||
继续之前,请参见[高级选项](#高级选项)。
|
||||
|
||||
:::
|
||||
|
||||
选择以下的选项之一:
|
||||
|
||||
<details id="option-a">
|
||||
<summary>选项 A:使用你自己的证书 - 自签名</summary>
|
||||
|
||||
如果要使用自签名证书来加密通信,你必须在负载均衡器(后续步骤)和 Rancher 容器上安装证书。运行 Docker 命令部署 Rancher,将 Docker 指向你的证书。
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
创建自签名证书。
|
||||
|
||||
- 证书文件的格式必须是 PEM。
|
||||
|
||||
:::
|
||||
|
||||
**使用自签名证书安装 Rancher**:
|
||||
|
||||
1. 在运行 Docker 命令部署 Rancher 时,将 Docker 指向你的 CA 证书文件。
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-v /etc/your_certificate_directory/cacerts.pem:/etc/rancher/ssl/cacerts.pem \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
</details>
|
||||
<details id="option-b">
|
||||
<summary>选项 B:使用你自己的证书 - 可信 CA 签名的证书</summary>
|
||||
|
||||
如果你的集群面向公众,则最好使用由公认 CA 签署的证书。
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
- 证书文件的格式必须是 PEM。
|
||||
|
||||
:::
|
||||
|
||||
**使用授信 CA 签发的证书安装 Rancher**:
|
||||
|
||||
如果你使用授信 CA 签发的证书,你无需在 Rancher 容器中安装证书。但是,请确保不要生成和存储默认的 CA 证书(你可以通过将 `--no-cacerts` 参数传递给容器来实现)。
|
||||
|
||||
1. 输入以下命令:
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
rancher/rancher:latest --no-cacerts
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## 3. 配置负载均衡器
|
||||
|
||||
在 Rancher 容器前使用负载均衡器时,容器无需从端口 80 或端口 443 重定向端口通信。你可以通过传递 `X-Forwarded-Proto: https` 标头禁用此重定向。
|
||||
|
||||
负载均衡器或代理必须支持以下内容:
|
||||
|
||||
- **WebSocket** 连接
|
||||
- **SPDY** / **HTTP/2** 协议
|
||||
- 传递/设置以下标头:
|
||||
|
||||
| 标头 | 值 | 描述 |
|
||||
|--------|-------|-------------|
|
||||
| `Host` | 用于访问 Rancher 的主机名。 | 识别客户端所请求的服务器。 |
|
||||
| `X-Forwarded-Proto` | `https` | 识别客户端连接负载均衡器或代理时所用的协议。<br /><br/>**注意**:如果此标头存在,`rancher/rancher` 不会将 HTTP 重定向到 HTTPS。 |
|
||||
| `X-Forwarded-Port` | 用于访问 Rancher 的端口。 | 识别客户端连接到负载均衡器或代理时所用的端口。 |
|
||||
| `X-Forwarded-For` | 客户端 IP 地址 | 识别客户端的原始 IP 地址。 |
|
||||
### 示例 NGINX 配置
|
||||
|
||||
此 NGINX 配置已在 NGINX 1.14 上进行了测试。
|
||||
|
||||
:::note
|
||||
|
||||
此 NGINX 配置只是一个示例,可能不适合你的环境。如需查阅完整文档,请参见 [NGINX 负载均衡 - HTTP 负载均衡](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/)。
|
||||
|
||||
:::
|
||||
|
||||
- 将 `rancher-server` 替换为运行 Rancher 容器的节点的 IP 或主机名。
|
||||
- 将两处的 `FQDN` 均替换为 Rancher 的 DNS 名称。
|
||||
- 把 `/certs/fullchain.pem` 和 `/certs/privkey.pem` 分别替换为服务器证书和服务器证书密钥的位置。
|
||||
|
||||
```
|
||||
worker_processes 4;
|
||||
worker_rlimit_nofile 40000;
|
||||
|
||||
events {
|
||||
worker_connections 8192;
|
||||
}
|
||||
|
||||
http {
|
||||
upstream rancher {
|
||||
server rancher-server:80;
|
||||
}
|
||||
|
||||
map $http_upgrade $connection_upgrade {
|
||||
default Upgrade;
|
||||
'' close;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 443 ssl http2;
|
||||
server_name FQDN;
|
||||
ssl_certificate /certs/fullchain.pem;
|
||||
ssl_certificate_key /certs/privkey.pem;
|
||||
|
||||
location / {
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
proxy_set_header X-Forwarded-Port $server_port;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_pass http://rancher;
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection $connection_upgrade;
|
||||
# 此项允许执行的 shell 窗口保持开启,最长可达15分钟。不使用此参数的话,默认1分钟后自动关闭。
|
||||
proxy_read_timeout 900s;
|
||||
proxy_buffering off;
|
||||
}
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
server_name FQDN;
|
||||
return 301 https://$server_name$request_uri;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<br/>
|
||||
|
||||
## 后续操作
|
||||
|
||||
- **推荐**:检查单节点[备份](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md)和[恢复](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-docker-installed-rancher.md)。你可能暂时没有需要备份的数据,但是我们建议你在常规使用 Rancher 后创建备份。
|
||||
- 创建 Kubernetes 集群:[配置 Kubernetes 集群](../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)。
|
||||
|
||||
<br/>
|
||||
|
||||
## 常见问题和故障排除
|
||||
|
||||
如果你需要对证书进行故障排除,请参见[此章节](../../getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)。
|
||||
|
||||
## 高级选项
|
||||
|
||||
### API 审计
|
||||
|
||||
如果你需要记录所有 Rancher API 事务,请将以下标志添加到安装命令中,从而启用 [API 审计](enable-api-audit-log.md)功能。
|
||||
|
||||
-e AUDIT_LEVEL=1 \
|
||||
-e AUDIT_LOG_PATH=/var/log/auditlog/rancher-api-audit.log \
|
||||
-e AUDIT_LOG_MAXAGE=20 \
|
||||
-e AUDIT_LOG_MAXBACKUP=20 \
|
||||
-e AUDIT_LOG_MAXSIZE=100 \
|
||||
|
||||
### 离线环境
|
||||
|
||||
如果你访问此页面是为了完成[离线安装](../../pages-for-subheaders/air-gapped-helm-cli-install.md),则在运行安装命令时,先将你的私有镜像仓库 URL 附加到 Server 标志中。也就是说,在 `rancher/rancher:latest` 前面添加 `<REGISTRY.DOMAIN.COM:PORT>` 和私有镜像仓库 URL。
|
||||
|
||||
**示例**:
|
||||
|
||||
<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
|
||||
```
|
||||
|
||||
此操作需要 [privileged 访问](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)。
|
||||
|
||||
这个 7 层 NGINX 配置已经在 NGINX 1.13(Mainline)和 1.14(Stable)版本上进行了测试。
|
||||
|
||||
:::note
|
||||
|
||||
此 NGINX 配置只是一个示例,可能不适合你的环境。如果需要查阅完整文档,请参见 [NGINX 负载均衡 - TCP 和 UDP 负载均衡器](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/)。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
upstream rancher {
|
||||
server rancher-server:80;
|
||||
}
|
||||
|
||||
map $http_upgrade $connection_upgrade {
|
||||
default Upgrade;
|
||||
'' close;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 443 ssl http2;
|
||||
server_name rancher.yourdomain.com;
|
||||
ssl_certificate /etc/your_certificate_directory/fullchain.pem;
|
||||
ssl_certificate_key /etc/your_certificate_directory/privkey.pem;
|
||||
|
||||
location / {
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
proxy_set_header X-Forwarded-Port $server_port;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_pass http://rancher;
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection $connection_upgrade;
|
||||
# 此项允许执行的 shell 窗口保持开启,最长可达15分钟。不使用此参数的话,默认1分钟后自动关闭。
|
||||
proxy_read_timeout 900s;
|
||||
proxy_buffering off;
|
||||
}
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
server_name rancher.yourdomain.com;
|
||||
return 301 https://$server_name$request_uri;
|
||||
}
|
||||
```
|
||||
|
||||
<br/>
|
||||
|
||||
@@ -0,0 +1,558 @@
|
||||
---
|
||||
title: 启用 API 审计日志以记录系统事件
|
||||
---
|
||||
|
||||
你可以启用 API 审计日志来记录各个用户发起的系统事件的顺序。通过查看日志,你可以了解发生了什么事件、事件发生的时间,事件发起人,以及事件影响的集群。启用此功能后,所有 Rancher API 的请求和响应都会写入日志中。
|
||||
|
||||
API 审计可以在 Rancher 安装或升级期间启用。
|
||||
|
||||
## 启用 API 审计日志
|
||||
|
||||
你可以将环境变量传递给 Rancher Server 容器,从而启用和配置审计日志。请参见以下文档,在安装时启用该功能:
|
||||
|
||||
- [Docker 安装](../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-审计日志)
|
||||
|
||||
- [Kubernetes 安装](../../getting-started/installation-and-upgrade/installation-references/helm-chart-options.md#api-审计日志)
|
||||
|
||||
## API 审计日志选项
|
||||
|
||||
以下参数定义了审计日志的记录规则,其中包括应该记录什么内容以及包括什么数据:
|
||||
|
||||
| 参数 | 描述 |
|
||||
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| <a id="audit-level"></a>`AUDIT_LEVEL` | `0` - 禁用审计日志(默认)<br /> `1` - 日志事件元数据<br /> `2` - 日志事件元数据和请求体<br /> `3` - 日志事件元数据,请求体和响应体。请求/响应对的每个日志事务都使用同一个的 `auditID`。<br /> 如需了解每个设置记录的日志内容,请参见[审计日志级别](#审核日志级别)。 |
|
||||
| `AUDIT_LOG_PATH` | Rancher Server API 的日志路径。默认路径:`/var/log/auditlog/rancher-api-audit.log`。你可以将日志目录挂载到主机。<br/><br/>示例:`AUDIT_LOG_PATH=/my/custom/path/`<br/> |
|
||||
| `AUDIT_LOG_MAXAGE` | 旧审计日志文件可保留的最大天数。默认为 10 天。 |
|
||||
| `AUDIT_LOG_MAXBACKUP` | 保留的审计日志最大文件个数。默认值为 10。 |
|
||||
| `AUDIT_LOG_MAXSIZE` | 在审计日志文件被轮换前的最大容量,单位是 MB。默认大小为 100MB。 |
|
||||
|
||||
<br/>
|
||||
|
||||
### 审核日志级别
|
||||
|
||||
下表介绍了每个 [`AUDIT_LEVEL`](#audit-level) 记录的 API 事务:
|
||||
|
||||
| `AUDIT_LEVEL` 设置 | 请求元数据 | 请求体 | 响应元数据 | 响应体 |
|
||||
| --------------------- | ---------------- | ------------ | ----------------- | ------------- |
|
||||
| `0` | | | | |
|
||||
| `1` | ✓ | | | |
|
||||
| `2` | ✓ | ✓ | | |
|
||||
| `3` | ✓ | ✓ | ✓ | ✓ |
|
||||
|
||||
## 查看 API 审计日志
|
||||
|
||||
### Docker 安装
|
||||
|
||||
与主机系统共享 `AUDIT_LOG_PATH` 目录(默认目录:`/var/log/auditlog`)。日志可以通过标准 CLI 工具进行解析,也可以转发到 Fluentd、Filebeat、Logstash 等日志收集工具。
|
||||
|
||||
### Kubernetes 安装
|
||||
|
||||
使用 Helm Chart 安装 Rancher 时启动 API 审计日志,会在 Rancher Pod 中创建一个 `rancher-audit-log` Sidecar 容器。该容器会将日志发送到标准输出 (stdout)。你可以像查看其他容器的日志一样查看 API 审计日志。
|
||||
|
||||
`rancher-audit-log` 容器位于 `cattle-system` 命名空间中的 `rancher` Pod 中。
|
||||
|
||||
#### CLI
|
||||
|
||||
```bash
|
||||
kubectl -n cattle-system logs -f rancher-84d886bdbb-s4s69 rancher-audit-log
|
||||
```
|
||||
|
||||
#### 发送审计日志
|
||||
|
||||
你可以为集群启用 Rancher 的内置日志收集和传送功能,将审计日志和其他服务日志发送到支持的 endpoint。详情请参见 [Rancher 工具 - Logging](../../pages-for-subheaders/logging.md)。
|
||||
|
||||
## 审计日志示例
|
||||
|
||||
启用审计日志后,Rancher 会以 JSON 格式记录每个 API 的请求和响应。下文的代码示例展示了如何查看 API 事务。
|
||||
|
||||
### 元数据日志级别
|
||||
|
||||
如果你将 `AUDIT_LEVEL` 设置为 `1`,Rancher 只会记录每个 API 请求的元数据标头,而不会记录请求体。标头记录了 API 事务的基本信息,包括 ID、发起人、发起时间等。代码示例如下:
|
||||
|
||||
```json
|
||||
{
|
||||
"auditID": "30022177-9e2e-43d1-b0d0-06ef9d3db183",
|
||||
"requestURI": "/v3/schemas",
|
||||
"sourceIPs": ["::1"],
|
||||
"user": {
|
||||
"name": "user-f4tt2",
|
||||
"group": ["system:authenticated"]
|
||||
},
|
||||
"verb": "GET",
|
||||
"stage": "RequestReceived",
|
||||
"stageTimestamp": "2018-07-20 10:22:43 +0800"
|
||||
}
|
||||
```
|
||||
|
||||
### 元数据和请求体日志级别
|
||||
|
||||
如果你将 `AUDIT_LEVEL` 设置为 `2`,Rancher 会记录每个 API 请求的元数据标头和请求体。
|
||||
|
||||
下面的代码示例描述了一个 API 请求,包括它的元数据标头和正文:
|
||||
|
||||
```json
|
||||
{
|
||||
"auditID": "ef1d249e-bfac-4fd0-a61f-cbdcad53b9bb",
|
||||
"requestURI": "/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
|
||||
"sourceIPs": ["::1"],
|
||||
"user": {
|
||||
"name": "user-f4tt2",
|
||||
"group": ["system:authenticated"]
|
||||
},
|
||||
"verb": "PUT",
|
||||
"stage": "RequestReceived",
|
||||
"stageTimestamp": "2018-07-20 10:28:08 +0800",
|
||||
"requestBody": {
|
||||
"hostIPC": false,
|
||||
"hostNetwork": false,
|
||||
"hostPID": false,
|
||||
"paused": false,
|
||||
"annotations": {},
|
||||
"baseType": "workload",
|
||||
"containers": [
|
||||
{
|
||||
"allowPrivilegeEscalation": false,
|
||||
"image": "nginx",
|
||||
"imagePullPolicy": "Always",
|
||||
"initContainer": false,
|
||||
"name": "nginx",
|
||||
"ports": [
|
||||
{
|
||||
"containerPort": 80,
|
||||
"dnsName": "nginx-nodeport",
|
||||
"kind": "NodePort",
|
||||
"name": "80tcp01",
|
||||
"protocol": "TCP",
|
||||
"sourcePort": 0,
|
||||
"type": "/v3/project/schemas/containerPort"
|
||||
}
|
||||
],
|
||||
"privileged": false,
|
||||
"readOnly": false,
|
||||
"resources": {
|
||||
"type": "/v3/project/schemas/resourceRequirements",
|
||||
"requests": {},
|
||||
"limits": {}
|
||||
},
|
||||
"restartCount": 0,
|
||||
"runAsNonRoot": false,
|
||||
"stdin": true,
|
||||
"stdinOnce": false,
|
||||
"terminationMessagePath": "/dev/termination-log",
|
||||
"terminationMessagePolicy": "File",
|
||||
"tty": true,
|
||||
"type": "/v3/project/schemas/container",
|
||||
"environmentFrom": [],
|
||||
"capAdd": [],
|
||||
"capDrop": [],
|
||||
"livenessProbe": null,
|
||||
"volumeMounts": []
|
||||
}
|
||||
],
|
||||
"created": "2018-07-18T07:34:16Z",
|
||||
"createdTS": 1531899256000,
|
||||
"creatorId": null,
|
||||
"deploymentConfig": {
|
||||
"maxSurge": 1,
|
||||
"maxUnavailable": 0,
|
||||
"minReadySeconds": 0,
|
||||
"progressDeadlineSeconds": 600,
|
||||
"revisionHistoryLimit": 10,
|
||||
"strategy": "RollingUpdate"
|
||||
},
|
||||
"deploymentStatus": {
|
||||
"availableReplicas": 1,
|
||||
"conditions": [
|
||||
{
|
||||
"lastTransitionTime": "2018-07-18T07:34:38Z",
|
||||
"lastTransitionTimeTS": 1531899278000,
|
||||
"lastUpdateTime": "2018-07-18T07:34:38Z",
|
||||
"lastUpdateTimeTS": 1531899278000,
|
||||
"message": "Deployment has minimum availability.",
|
||||
"reason": "MinimumReplicasAvailable",
|
||||
"status": "True",
|
||||
"type": "Available"
|
||||
},
|
||||
{
|
||||
"lastTransitionTime": "2018-07-18T07:34:16Z",
|
||||
"lastTransitionTimeTS": 1531899256000,
|
||||
"lastUpdateTime": "2018-07-18T07:34:38Z",
|
||||
"lastUpdateTimeTS": 1531899278000,
|
||||
"message": "ReplicaSet \"nginx-64d85666f9\" has successfully progressed.",
|
||||
"reason": "NewReplicaSetAvailable",
|
||||
"status": "True",
|
||||
"type": "Progressing"
|
||||
}
|
||||
],
|
||||
"observedGeneration": 2,
|
||||
"readyReplicas": 1,
|
||||
"replicas": 1,
|
||||
"type": "/v3/project/schemas/deploymentStatus",
|
||||
"unavailableReplicas": 0,
|
||||
"updatedReplicas": 1
|
||||
},
|
||||
"dnsPolicy": "ClusterFirst",
|
||||
"id": "deployment:default:nginx",
|
||||
"labels": {
|
||||
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
|
||||
},
|
||||
"name": "nginx",
|
||||
"namespaceId": "default",
|
||||
"projectId": "c-bcz5t:p-fdr4s",
|
||||
"publicEndpoints": [
|
||||
{
|
||||
"addresses": ["10.64.3.58"],
|
||||
"allNodes": true,
|
||||
"ingressId": null,
|
||||
"nodeId": null,
|
||||
"podId": null,
|
||||
"port": 30917,
|
||||
"protocol": "TCP",
|
||||
"serviceId": "default:nginx-nodeport",
|
||||
"type": "publicEndpoint"
|
||||
}
|
||||
],
|
||||
"restartPolicy": "Always",
|
||||
"scale": 1,
|
||||
"schedulerName": "default-scheduler",
|
||||
"selector": {
|
||||
"matchLabels": {
|
||||
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
|
||||
},
|
||||
"type": "/v3/project/schemas/labelSelector"
|
||||
},
|
||||
"state": "active",
|
||||
"terminationGracePeriodSeconds": 30,
|
||||
"transitioning": "no",
|
||||
"transitioningMessage": "",
|
||||
"type": "deployment",
|
||||
"uuid": "f998037d-8a5c-11e8-a4cf-0245a7ebb0fd",
|
||||
"workloadAnnotations": {
|
||||
"deployment.kubernetes.io/revision": "1",
|
||||
"field.cattle.io/creatorId": "user-f4tt2"
|
||||
},
|
||||
"workloadLabels": {
|
||||
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
|
||||
},
|
||||
"scheduling": {
|
||||
"node": {}
|
||||
},
|
||||
"description": "my description",
|
||||
"volumes": []
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 元数据、请求体和响应体日志级别
|
||||
|
||||
如果你将 `AUDIT_LEVEL` 设置为 `3`,Rancher 会记录:
|
||||
|
||||
- 每个 API 请求的元数据标头和请求体。
|
||||
- 每个 API 响应的元数据标头和响应体。
|
||||
|
||||
#### 请求
|
||||
|
||||
下面的代码示例描述了一个 API 请求,包括它的元数据标头和正文:
|
||||
|
||||
```json
|
||||
{
|
||||
"auditID": "a886fd9f-5d6b-4ae3-9a10-5bff8f3d68af",
|
||||
"requestURI": "/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
|
||||
"sourceIPs": ["::1"],
|
||||
"user": {
|
||||
"name": "user-f4tt2",
|
||||
"group": ["system:authenticated"]
|
||||
},
|
||||
"verb": "PUT",
|
||||
"stage": "RequestReceived",
|
||||
"stageTimestamp": "2018-07-20 10:33:06 +0800",
|
||||
"requestBody": {
|
||||
"hostIPC": false,
|
||||
"hostNetwork": false,
|
||||
"hostPID": false,
|
||||
"paused": false,
|
||||
"annotations": {},
|
||||
"baseType": "workload",
|
||||
"containers": [
|
||||
{
|
||||
"allowPrivilegeEscalation": false,
|
||||
"image": "nginx",
|
||||
"imagePullPolicy": "Always",
|
||||
"initContainer": false,
|
||||
"name": "nginx",
|
||||
"ports": [
|
||||
{
|
||||
"containerPort": 80,
|
||||
"dnsName": "nginx-nodeport",
|
||||
"kind": "NodePort",
|
||||
"name": "80tcp01",
|
||||
"protocol": "TCP",
|
||||
"sourcePort": 0,
|
||||
"type": "/v3/project/schemas/containerPort"
|
||||
}
|
||||
],
|
||||
"privileged": false,
|
||||
"readOnly": false,
|
||||
"resources": {
|
||||
"type": "/v3/project/schemas/resourceRequirements",
|
||||
"requests": {},
|
||||
"limits": {}
|
||||
},
|
||||
"restartCount": 0,
|
||||
"runAsNonRoot": false,
|
||||
"stdin": true,
|
||||
"stdinOnce": false,
|
||||
"terminationMessagePath": "/dev/termination-log",
|
||||
"terminationMessagePolicy": "File",
|
||||
"tty": true,
|
||||
"type": "/v3/project/schemas/container",
|
||||
"environmentFrom": [],
|
||||
"capAdd": [],
|
||||
"capDrop": [],
|
||||
"livenessProbe": null,
|
||||
"volumeMounts": []
|
||||
}
|
||||
],
|
||||
"created": "2018-07-18T07:34:16Z",
|
||||
"createdTS": 1531899256000,
|
||||
"creatorId": null,
|
||||
"deploymentConfig": {
|
||||
"maxSurge": 1,
|
||||
"maxUnavailable": 0,
|
||||
"minReadySeconds": 0,
|
||||
"progressDeadlineSeconds": 600,
|
||||
"revisionHistoryLimit": 10,
|
||||
"strategy": "RollingUpdate"
|
||||
},
|
||||
"deploymentStatus": {
|
||||
"availableReplicas": 1,
|
||||
"conditions": [
|
||||
{
|
||||
"lastTransitionTime": "2018-07-18T07:34:38Z",
|
||||
"lastTransitionTimeTS": 1531899278000,
|
||||
"lastUpdateTime": "2018-07-18T07:34:38Z",
|
||||
"lastUpdateTimeTS": 1531899278000,
|
||||
"message": "Deployment has minimum availability.",
|
||||
"reason": "MinimumReplicasAvailable",
|
||||
"status": "True",
|
||||
"type": "Available"
|
||||
},
|
||||
{
|
||||
"lastTransitionTime": "2018-07-18T07:34:16Z",
|
||||
"lastTransitionTimeTS": 1531899256000,
|
||||
"lastUpdateTime": "2018-07-18T07:34:38Z",
|
||||
"lastUpdateTimeTS": 1531899278000,
|
||||
"message": "ReplicaSet \"nginx-64d85666f9\" has successfully progressed.",
|
||||
"reason": "NewReplicaSetAvailable",
|
||||
"status": "True",
|
||||
"type": "Progressing"
|
||||
}
|
||||
],
|
||||
"observedGeneration": 2,
|
||||
"readyReplicas": 1,
|
||||
"replicas": 1,
|
||||
"type": "/v3/project/schemas/deploymentStatus",
|
||||
"unavailableReplicas": 0,
|
||||
"updatedReplicas": 1
|
||||
},
|
||||
"dnsPolicy": "ClusterFirst",
|
||||
"id": "deployment:default:nginx",
|
||||
"labels": {
|
||||
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
|
||||
},
|
||||
"name": "nginx",
|
||||
"namespaceId": "default",
|
||||
"projectId": "c-bcz5t:p-fdr4s",
|
||||
"publicEndpoints": [
|
||||
{
|
||||
"addresses": ["10.64.3.58"],
|
||||
"allNodes": true,
|
||||
"ingressId": null,
|
||||
"nodeId": null,
|
||||
"podId": null,
|
||||
"port": 30917,
|
||||
"protocol": "TCP",
|
||||
"serviceId": "default:nginx-nodeport",
|
||||
"type": "publicEndpoint"
|
||||
}
|
||||
],
|
||||
"restartPolicy": "Always",
|
||||
"scale": 1,
|
||||
"schedulerName": "default-scheduler",
|
||||
"selector": {
|
||||
"matchLabels": {
|
||||
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
|
||||
},
|
||||
"type": "/v3/project/schemas/labelSelector"
|
||||
},
|
||||
"state": "active",
|
||||
"terminationGracePeriodSeconds": 30,
|
||||
"transitioning": "no",
|
||||
"transitioningMessage": "",
|
||||
"type": "deployment",
|
||||
"uuid": "f998037d-8a5c-11e8-a4cf-0245a7ebb0fd",
|
||||
"workloadAnnotations": {
|
||||
"deployment.kubernetes.io/revision": "1",
|
||||
"field.cattle.io/creatorId": "user-f4tt2"
|
||||
},
|
||||
"workloadLabels": {
|
||||
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
|
||||
},
|
||||
"scheduling": {
|
||||
"node": {}
|
||||
},
|
||||
"description": "my decript",
|
||||
"volumes": []
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 响应
|
||||
|
||||
下面的代码示例描述了一个 API 响应,包括它的元数据标头和正文:
|
||||
|
||||
```json
|
||||
{
|
||||
"auditID": "a886fd9f-5d6b-4ae3-9a10-5bff8f3d68af",
|
||||
"responseStatus": "200",
|
||||
"stage": "ResponseComplete",
|
||||
"stageTimestamp": "2018-07-20 10:33:06 +0800",
|
||||
"responseBody": {
|
||||
"actionLinks": {
|
||||
"pause": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx?action=pause",
|
||||
"resume": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx?action=resume",
|
||||
"rollback": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx?action=rollback"
|
||||
},
|
||||
"annotations": {},
|
||||
"baseType": "workload",
|
||||
"containers": [
|
||||
{
|
||||
"allowPrivilegeEscalation": false,
|
||||
"image": "nginx",
|
||||
"imagePullPolicy": "Always",
|
||||
"initContainer": false,
|
||||
"name": "nginx",
|
||||
"ports": [
|
||||
{
|
||||
"containerPort": 80,
|
||||
"dnsName": "nginx-nodeport",
|
||||
"kind": "NodePort",
|
||||
"name": "80tcp01",
|
||||
"protocol": "TCP",
|
||||
"sourcePort": 0,
|
||||
"type": "/v3/project/schemas/containerPort"
|
||||
}
|
||||
],
|
||||
"privileged": false,
|
||||
"readOnly": false,
|
||||
"resources": {
|
||||
"type": "/v3/project/schemas/resourceRequirements"
|
||||
},
|
||||
"restartCount": 0,
|
||||
"runAsNonRoot": false,
|
||||
"stdin": true,
|
||||
"stdinOnce": false,
|
||||
"terminationMessagePath": "/dev/termination-log",
|
||||
"terminationMessagePolicy": "File",
|
||||
"tty": true,
|
||||
"type": "/v3/project/schemas/container"
|
||||
}
|
||||
],
|
||||
"created": "2018-07-18T07:34:16Z",
|
||||
"createdTS": 1531899256000,
|
||||
"creatorId": null,
|
||||
"deploymentConfig": {
|
||||
"maxSurge": 1,
|
||||
"maxUnavailable": 0,
|
||||
"minReadySeconds": 0,
|
||||
"progressDeadlineSeconds": 600,
|
||||
"revisionHistoryLimit": 10,
|
||||
"strategy": "RollingUpdate"
|
||||
},
|
||||
"deploymentStatus": {
|
||||
"availableReplicas": 1,
|
||||
"conditions": [
|
||||
{
|
||||
"lastTransitionTime": "2018-07-18T07:34:38Z",
|
||||
"lastTransitionTimeTS": 1531899278000,
|
||||
"lastUpdateTime": "2018-07-18T07:34:38Z",
|
||||
"lastUpdateTimeTS": 1531899278000,
|
||||
"message": "Deployment has minimum availability.",
|
||||
"reason": "MinimumReplicasAvailable",
|
||||
"status": "True",
|
||||
"type": "Available"
|
||||
},
|
||||
{
|
||||
"lastTransitionTime": "2018-07-18T07:34:16Z",
|
||||
"lastTransitionTimeTS": 1531899256000,
|
||||
"lastUpdateTime": "2018-07-18T07:34:38Z",
|
||||
"lastUpdateTimeTS": 1531899278000,
|
||||
"message": "ReplicaSet \"nginx-64d85666f9\" has successfully progressed.",
|
||||
"reason": "NewReplicaSetAvailable",
|
||||
"status": "True",
|
||||
"type": "Progressing"
|
||||
}
|
||||
],
|
||||
"observedGeneration": 2,
|
||||
"readyReplicas": 1,
|
||||
"replicas": 1,
|
||||
"type": "/v3/project/schemas/deploymentStatus",
|
||||
"unavailableReplicas": 0,
|
||||
"updatedReplicas": 1
|
||||
},
|
||||
"dnsPolicy": "ClusterFirst",
|
||||
"hostIPC": false,
|
||||
"hostNetwork": false,
|
||||
"hostPID": false,
|
||||
"id": "deployment:default:nginx",
|
||||
"labels": {
|
||||
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
|
||||
},
|
||||
"links": {
|
||||
"remove": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
|
||||
"revisions": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx/revisions",
|
||||
"self": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
|
||||
"update": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
|
||||
"yaml": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx/yaml"
|
||||
},
|
||||
"name": "nginx",
|
||||
"namespaceId": "default",
|
||||
"paused": false,
|
||||
"projectId": "c-bcz5t:p-fdr4s",
|
||||
"publicEndpoints": [
|
||||
{
|
||||
"addresses": ["10.64.3.58"],
|
||||
"allNodes": true,
|
||||
"ingressId": null,
|
||||
"nodeId": null,
|
||||
"podId": null,
|
||||
"port": 30917,
|
||||
"protocol": "TCP",
|
||||
"serviceId": "default:nginx-nodeport"
|
||||
}
|
||||
],
|
||||
"restartPolicy": "Always",
|
||||
"scale": 1,
|
||||
"schedulerName": "default-scheduler",
|
||||
"selector": {
|
||||
"matchLabels": {
|
||||
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
|
||||
},
|
||||
"type": "/v3/project/schemas/labelSelector"
|
||||
},
|
||||
"state": "active",
|
||||
"terminationGracePeriodSeconds": 30,
|
||||
"transitioning": "no",
|
||||
"transitioningMessage": "",
|
||||
"type": "deployment",
|
||||
"uuid": "f998037d-8a5c-11e8-a4cf-0245a7ebb0fd",
|
||||
"workloadAnnotations": {
|
||||
"deployment.kubernetes.io/revision": "1",
|
||||
"field.cattle.io/creatorId": "user-f4tt2"
|
||||
},
|
||||
"workloadLabels": {
|
||||
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: 持续交付
|
||||
---
|
||||
|
||||
Rancher 中预装的 [Fleet](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) 无法完全禁用。但是,你可以使用 `continuous-delivery` 功能开关来禁用 GitOps 持续交付的 Fleet 功能。
|
||||
|
||||
如需启用或禁用此功能,请参见[启用实验功能主页](../../../pages-for-subheaders/enable-experimental-features.md)中的说明。
|
||||
|
||||
| 环境变量键 | 默认值 | 描述 |
|
||||
---|---|---
|
||||
| `continuous-delivery` | `true` | 此开关禁用 Fleet 的 GitOps 持续交付功能。 |
|
||||
|
||||
如果你在 Rancher 2.5.x 中禁用了 Fleet,然后将 Rancher 升级到 v2.6.x,Fleet 将启用。只有 Fleet 的持续交付功能可以被禁用。当 `continuous-delivery` 被禁用时,`gitjob` deployment 不再部署到 Rancher Server 的本地集群中,且 `continuous-delivery` 不会在 Rancher UI 中显示。
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: UI 管理 Istio 虚拟服务和目标规则
|
||||
---
|
||||
|
||||
此功能可启动一个 UI,用于管理 Istio 的流量,其中包括创建、读取、更新和删除虚拟服务(Virtual Service)和目标规则(Destination Rule)。
|
||||
|
||||
> **注意**:启用此功能并不会启用 Istio。集群管理员需要[为集群启用 Istio](../../../pages-for-subheaders/istio-setup-guide.md) 才能使用该功能。
|
||||
|
||||
如需启用或禁用此功能,请参见[启用实验功能主页](../../../pages-for-subheaders/enable-experimental-features.md)中的说明。
|
||||
|
||||
| 环境变量键 | 默认值 | 状态 | 可用于 |
|
||||
---|---|---|---
|
||||
| `istio-virtual-service-ui` | `false` | 实验功能 | v2.3.0 |
|
||||
| `istio-virtual-service-ui` | `true` | GA | v2.3.2 |
|
||||
|
||||
## 功能介绍
|
||||
|
||||
Istio 流量管理功能的主要优势时允许动态请求路由,这对于金丝雀发布,蓝/绿发布或 A/B 测试都非常有用。
|
||||
|
||||
启用此功能后,一个页面会打开,让你通过 Rancher UI 配置 Istio 的某些流量管理功能。如果不使用此功能,你可以通过 `kubectl` 来使用 Istio 管理流量。
|
||||
|
||||
此功能会启用两个选项卡,一个用于**虚拟服务**,另一个用于**目标规则**。
|
||||
|
||||
- **虚拟服务**:拦截并将流量重定向到你的 Kubernetes Service 上。这样,你可以将部分请求流量定向到不同的服务上。你可以使用这些服务来定义一组路由规则,用于主机寻址。详情请参见 [Istio 官方文档](https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service/)。
|
||||
- **目标规则**:作为唯一可信来源,表明哪些服务版本可用于接收虚拟服务的流量。你可以使用这些资源来定义策略,这些策略适用于路由发生后用于服务的流量。详情请参见 [Istio 官方文档](https://istio.io/docs/reference/config/networking/v1alpha3/destination-rule)。
|
||||
|
||||
如需查看选项卡:
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到安装了 Istio 的集群,然后单击 **Explore**。
|
||||
1. 在左侧导航栏中,单击 **Istio**。
|
||||
1. 你将看到 **Kiali** 和 **Jaeger** 的选项卡。在左侧导航栏中,你可查看和配置**虚拟服务**和**目标规则**。
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "在 ARM64 上运行 Rancher(实验性)"
|
||||
---
|
||||
|
||||
:::caution
|
||||
|
||||
在使用 ARM64 架构的节点上运行 Rancher 目前还处在实验阶段,Rancher 尚未正式支持该功能。因此,我们不建议你在生产环境中使用 ARM64 架构的节点。
|
||||
|
||||
:::
|
||||
|
||||
如果你的节点使用 ARM64 架构,你可以使用以下选项:
|
||||
|
||||
- 在 ARM64 架构的节点上运行 Rancher
|
||||
- 此选项仅适用于 Docker 安装。请知悉,以下安装命令取代了 [Docker 安装链接](../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md)中的示例:
|
||||
|
||||
```
|
||||
# 在最后一行 `rancher/rancher:vX.Y.Z` 中,请务必将 "X.Y.Z" 替换为包含 ARM64 版本的发布版本。例如,如果你的匹配版本是 v2.5.8,请在此行填写 `rancher/rancher:v2.5.8`。
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
--privileged \
|
||||
rancher/rancher:vX.Y.Z
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
要检查你的发行版本是否与 ARM64 架构兼容,你可以使用以下两种方式找到对应版本的发行说明:
|
||||
|
||||
- 访问 [Rancher 发行版本](https://github.com/rancher/rancher/releases)自行查询。
|
||||
- 根据标签和版本号直接找到你的版本。例如,你使用的版本为 2.5.8,你可以访问 [Rancher 发行版本 - 2.5.8](https://github.com/rancher/rancher/releases/tag/v2.5.8)。
|
||||
|
||||
:::
|
||||
|
||||
- 创建自定义集群并添加使用 ARM64 架构的节点
|
||||
- Kubernetes 集群必须为 1.12 或更高版本
|
||||
- CNI 网络插件必须是 [Flannel](../../../faq/container-network-interface-providers.md#flannel)
|
||||
- 导入包含使用 ARM64 架构的节点的集群
|
||||
- Kubernetes 集群必须为 1.12 或更高版本
|
||||
|
||||
如需了解如何配置集群选项,请参见[集群选项](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。
|
||||
|
||||
以下是未经测试的功能:
|
||||
|
||||
- Monitoring、告警、Notifiers、流水线和 Logging
|
||||
- 通过应用商店发布应用
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: 使用非默认支持的存储驱动
|
||||
---
|
||||
|
||||
此功能允许你使用不是默认启用的存储提供商和卷插件。
|
||||
|
||||
如需启用或禁用此功能,请参见[启用实验功能主页](../../../pages-for-subheaders/enable-experimental-features.md)中的说明。
|
||||
|
||||
| 环境变量键 | 默认值 | 描述 |
|
||||
---|---|---
|
||||
| `unsupported-storage-drivers` | `false` | 启用非默认启用的存储提供商和卷插件。 |
|
||||
|
||||
### 默认启用的持久卷插件
|
||||
下表描述了默认启用的存储类型对应的持久卷插件。启用此功能开关时,不在此列表中的任何持久卷插件均被视为实验功能,且不受支持:
|
||||
|
||||
| 名称 | 插件 |
|
||||
--------|----------
|
||||
| Amazon EBS Disk | `aws-ebs` |
|
||||
| AzureFile | `azure-file` |
|
||||
| AzureDisk | `azure-disk` |
|
||||
| Google Persistent Disk | `gce-pd` |
|
||||
| Longhorn | `flex-volume-longhorn` |
|
||||
| VMware vSphere Volume | `vsphere-volume` |
|
||||
| 本地 | `local` |
|
||||
| 网络文件系统 | `nfs` |
|
||||
| hostPath | `host-path` |
|
||||
|
||||
### 默认启用的 StorageClass
|
||||
下表描述了默认启用的 StorageClass 对应的持久卷插件。启用此功能开关时,不在此列表中的任何持久卷插件均被视为实验功能,且不受支持:
|
||||
|
||||
| 名称 | 插件 |
|
||||
--------|--------
|
||||
| Amazon EBS Disk | `aws-ebs` |
|
||||
| AzureFile | `azure-file` |
|
||||
| AzureDisk | `azure-disk` |
|
||||
| Google Persistent Disk | `gce-pd` |
|
||||
| Longhorn | `flex-volume-longhorn` |
|
||||
| VMware vSphere Volume | `vsphere-volume` |
|
||||
| 本地 | `local` |
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: 1. 在集群中启用 Istio
|
||||
---
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
- 只有分配了 `cluster-admin` [Kubernetes 默认角色](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)的用户可以在 Kubernetes 集群中配置和安装 Istio。
|
||||
- 如果你有 pod 安全策略,则需要安装启用了 CNI 的 Istio。有关详细信息,请参阅[本节](../../../integrations-in-rancher/istio/configuration-options/pod-security-policies.md)。
|
||||
- 要在 RKE2 集群上安装 Istio,则需要执行额外的步骤。有关详细信息,请参阅[本节](../../../integrations-in-rancher/istio/configuration-options/install-istio-on-rke2-cluster.md)。
|
||||
- 要在启用了项目网络隔离的集群中安装 Istio,则需要执行额外的步骤。有关详细信息,请参阅[本节](../../../integrations-in-rancher/istio/configuration-options/project-network-isolation.md)。
|
||||
|
||||
:::
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到要启用 Istio 的位置,然后单击 **Explore**。
|
||||
1. 单击 **Apps**。
|
||||
1. 单击 **Chart**。
|
||||
1. 单击 **Istio**。
|
||||
1. 如果你还没有安装 Monitoring 应用,系统会提示你安装 rancher-monitoring。你也可以选择在 Rancher-monitoring 安装上设置选择器或抓取配置选项。
|
||||
1. 可选:为 Istio 组件配置成员访问和[资源限制](../../../integrations-in-rancher/istio/cpu-and-memory-allocations.md)。确保你的 Worker 节点上有足够的资源来启用 Istio。
|
||||
1. 可选:如果需要,对 values.yaml 进行额外的配置更改。
|
||||
1. 可选:通过[覆盖文件](../../../pages-for-subheaders/configuration-options.md#覆盖文件)来添加其他资源或配置。
|
||||
1. 单击**安装**。
|
||||
|
||||
**结果**:已在集群级别安装 Istio。
|
||||
|
||||
## 其他配置选项
|
||||
|
||||
有关配置 Istio 的更多信息,请参阅[配置参考](../../../pages-for-subheaders/configuration-options.md)。
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: 2. 在命名空间中启用 Istio
|
||||
---
|
||||
|
||||
你需要在需要由 Istio 跟踪或控制的每个命名空间中手动启用 Istio。在命名空间中启用 Istio 时,Envoy sidecar 代理将自动注入到部署在命名空间中的所有新工作负载中。
|
||||
|
||||
此命名空间设置只会影响命名空间中的新工作负载。之前的工作负载需要重新部署才能使用 sidecar 自动注入。
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
要在命名空间中启用 Istio,集群必须安装 Istio。
|
||||
|
||||
:::
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 转到要启用 Istio 的命名空间,然后单击**⋮ > 启用 Istio 自动注入**。或者,你也可以单击命名空间,然后在命名空间详情页面上,单击**⋮ > 启用 Istio 自动注入**。
|
||||
|
||||
**结果**:命名空间带有了 `istio-injection=enabled` 标签。默认情况下,部署在此命名空间中的所有新工作负载都将注入 Istio sidecar。
|
||||
|
||||
### 验证是否启用了自动 Istio Sidecar 注入
|
||||
|
||||
要验证 Istio 是否已启用,请在命名空间中部署一个 hello-world 工作负载。转到工作负载并单击 pod 名称。在**容器**中,你应该能看到 `istio-proxy` 容器。
|
||||
|
||||
### 排除工作负载的 Istio Sidecar 注入
|
||||
|
||||
要排除 Istio sidecar 被注入某工作负载,请在工作负载上使用以下注释:
|
||||
|
||||
```
|
||||
sidecar.istio.io/inject: “false”
|
||||
```
|
||||
|
||||
要将注释添加到工作负载:
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 点击**工作负载**。
|
||||
1. 转到不需要 sidecar 的工作负载并以 yaml 编辑。
|
||||
1. 将键值 `sidecar.istio.io/inject: false` 添加为工作负载的注释。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**:Istio sidecar 不会被注入到工作负载中。
|
||||
|
||||
:::note
|
||||
|
||||
如果你遇到部署的 job 未完成的问题,则需要使用提供的步骤将此注释添加到 pod 中。由于 Istio Sidecars 会一直运行,因此即使任务完成了,也不能认为 Job 已完成。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
### 后续步骤
|
||||
[使用 Istio Sidecar 添加部署](use-istio-sidecar.md)
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: 6. 生成和查看流量
|
||||
---
|
||||
|
||||
本文介绍如何查看 Istio 管理的流量。
|
||||
|
||||
## Kiali 流量图
|
||||
|
||||
Istio 概览页面提供了 Kiali 仪表板的链接。在 Kiali 仪表板中,你可以查看每个命名空间的图。Kiali 图提供了一种强大的方式来可视化 Istio 服务网格的拓扑。它显示了服务之间相互通信的情况。
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
要显示流量图,请确保你在集群中安装了 Prometheus。Rancher-istio 安装了默认配置的 Kiali 来与 rancher-monitoring Chart 一起工作。你可以使用 rancher-monitoring 或安装自己的监控解决方案。你也可以通过设置[选择器 & 抓取配置](../../../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md)选项来更改数据抓取的配置(可选)。
|
||||
|
||||
:::
|
||||
|
||||
要查看流量图:
|
||||
|
||||
1. 在安装了 Istio 的集群中,点击左侧导航栏中的 **Istio**。
|
||||
1. 单击 **Kiali** 链接。
|
||||
1. 单击侧导航中的**图**。
|
||||
1. 在**命名空间**下拉列表中,更改命名空间以查看每个命名空间的流量。
|
||||
|
||||
如果你多次刷新 BookInfo 应用的 URL,你将能够在 Kiali 图上看到绿色箭头,显示 `reviews` 服务 `v1` 和 `v3` 的流量。图右侧的控制面板可用于配置详细信息,包括应在图上显示多少分钟的最新流量。
|
||||
|
||||
对于其他工具和可视化,你可以从**监控** > **概览**页面转到 Grafana 和 Prometheus 仪表板。
|
||||
@@ -0,0 +1,147 @@
|
||||
---
|
||||
title: 4. 设置 Istio Gateway
|
||||
---
|
||||
|
||||
每个集群的网关可以有自己的端口或负载均衡器,这与服务网格无关。默认情况下,每个 Rancher 配置的集群都有一个 NGINX Ingress Controller 来允许流量进入集群。
|
||||
|
||||
无论是否安装了 Istio,你都可以使用 NGINX Ingress Controller。如果这是你集群的唯一网关,Istio 将能够将流量从集群内部的服务路由到集群内部的另一个服务,但 Istio 将无法接收来自集群外部的流量。
|
||||
|
||||
要让 Istio 接收外部流量,你需要启用 Istio 的网关,作为外部流量的南北代理。启用 Istio Gateway 后,你的集群将有两个 Ingress。
|
||||
|
||||
你还需要为你的服务设置 Kubernetes 网关。此 Kubernetes 资源指向 Istio 对集群 Ingress Gateway 的实现。
|
||||
|
||||
你可以使用负载均衡器将流量路由到服务网格中,或使用 Istio 的 NodePort 网关。本文介绍如何设置 NodePort 网关。
|
||||
|
||||
有关 Istio Gateway 的更多信息,请参阅 [Istio 文档](https://istio.io/docs/reference/config/networking/v1alpha3/gateway/)。
|
||||
|
||||

|
||||
|
||||
## 启用 Istio Gateway
|
||||
|
||||
Ingress Gateway 是一个 Kubernetes 服务,将部署在你的集群中。Istio Gateway 支持更多自定义设置,更加灵活。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 在左侧导航栏中,单击 **Istio > 网关**。
|
||||
1. 单击**使用 YAML 文件创建**。
|
||||
1. 粘贴你的 Istio Gateway yaml,或选择**从文件读取**。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**:已部署网关,将使用应用的规则来路由流量。
|
||||
|
||||
## Istio Gateway 示例
|
||||
|
||||
在演示工作负载示例时,我们在服务中添加 BookInfo 应用部署。接下来,我们添加一个 Istio Gateway,以便从集群外部访问该应用。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 在左侧导航栏中,单击 **Istio > 网关**。
|
||||
1. 单击**使用 YAML 文件创建**。
|
||||
1. 复制并粘贴下面的 Gateway YAML。
|
||||
1. 单击**创建**。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: bookinfo-gateway
|
||||
spec:
|
||||
selector:
|
||||
istio: ingressgateway # use istio default controller
|
||||
servers:
|
||||
- port:
|
||||
number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
hosts:
|
||||
- "*"
|
||||
---
|
||||
```
|
||||
|
||||
然后,部署为 Gateway 提供流量路由的 VirtualService:
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 在左侧导航栏中,单击 **Istio > VirtualServices**。
|
||||
1. 复制并粘贴下面的 VirtualService YAML。
|
||||
1. 单击**创建**。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: bookinfo
|
||||
spec:
|
||||
hosts:
|
||||
- "*"
|
||||
gateways:
|
||||
- bookinfo-gateway
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
exact: /productpage
|
||||
- uri:
|
||||
prefix: /static
|
||||
- uri:
|
||||
exact: /login
|
||||
- uri:
|
||||
exact: /logout
|
||||
- uri:
|
||||
prefix: /api/v1/products
|
||||
route:
|
||||
- destination:
|
||||
host: productpage
|
||||
port:
|
||||
number: 9080
|
||||
```
|
||||
|
||||
**结果**:你已配置网关资源,Istio 现在可以接收集群外部的流量。
|
||||
|
||||
运行以下命令来确认资源存在:
|
||||
```
|
||||
kubectl get gateway -A
|
||||
```
|
||||
|
||||
结果应与以下内容类似:
|
||||
```
|
||||
NAME AGE
|
||||
bookinfo-gateway 64m
|
||||
```
|
||||
|
||||
### 在 Web 浏览器访问 ProductPage 服务
|
||||
|
||||
要测试 BookInfo 应用是否已正确部署,你可以使用 Istio 控制器 IP 和端口以及在 Kubernetes 网关资源中指定的请求名称,在 Web 浏览器中查看该应用:
|
||||
|
||||
`http://<IP of Istio controller>:<Port of istio controller>/productpage`
|
||||
|
||||
要获取 Ingress Gateway URL 和端口:
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 在左侧导航栏中,单击**工作负载**。
|
||||
1. 向下滚动到 `istio-system` 命名空间。
|
||||
1. 在 `istio-system`中,有一个名为 `istio-ingressgateway` 的工作负载。在此工作负载的名称下,你应该会看到如 `80/tcp` 的链接。
|
||||
1. 单击其中一个链接。然后,你的 Web 浏览器中会显示 Ingress Gateway 的 URL。将 `/productpage` 尾附到 URL。
|
||||
|
||||
**结果**:你能会在 Web 浏览器中看到 BookInfo 应用。
|
||||
|
||||
如需检查 Istio 控制器 URL 和端口的帮助,请尝试运行 [Istio 文档](https://istio.io/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports)中的命令。
|
||||
|
||||
## 故障排除
|
||||
|
||||
[官方 Istio 文档](https://istio.io/docs/tasks/traffic-management/ingress/ingress-control/#troubleshooting)建议使用 `kubectl` 命令来检查外部请求的正确 ingress 主机和 ingress 端口。
|
||||
|
||||
### 确认 Kubernetes 网关与 Istio 的 Ingress Controller 匹配
|
||||
|
||||
你可以尝试执行本节中的步骤以确保 Kubernetes 网关配置正确。
|
||||
|
||||
在网关资源中,选择器通过标签来引用 Istio 的默认 Ingress Controller,其中标签的键是 `Istio`,值是 `ingressgateway`。要确保标签适用于网关,请执行以下操作:
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 在左侧导航栏中,单击**工作负载**。
|
||||
1. 向下滚动到 `istio-system` 命名空间。
|
||||
1. 在 `istio-system`中,有一个名为 `istio-ingressgateway` 的工作负载。单击此工作负载的名称并转到**标签和注释**部分。你应该看到它具有 `istio` 键和 `ingressgateway` 值。这确认了 Gateway 资源中的选择器与 Istio 的默认 ingress controller 匹配。
|
||||
|
||||
### 后续步骤
|
||||
[设置 Istio 的流量管理组件](set-up-traffic-management.md)
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: 5. 设置 Istio 的流量管理组件
|
||||
---
|
||||
|
||||
Istio 中流量管理的一个核心优势是允许动态请求路由。动态请求路由通常应用于金丝雀部署和蓝/绿部署等。Istio 流量管理中的两个关键资源是*虚拟服务*和*目标规则*。
|
||||
|
||||
- [虚拟服务](https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service/):拦截并将流量重定向到你的 Kubernetes Service 上。这样,你可以将部分请求流量分配到不同的服务上。你可以使用这些服务来定义一组路由规则,用于主机寻址。
|
||||
- [目标规则](https://istio.io/docs/reference/config/networking/v1alpha3/destination-rule/):作为唯一可信来源,表明哪些服务版本可用于接收虚拟服务的流量。你可以使用这些资源来定义策略,这些策略适用于路由发生后用于服务的流量。
|
||||
|
||||
本文介绍如何在示例 BookInfo 应用中添加与 `reviews` 微服务对应的虚拟服务示例。此服务的目的是在 `reviews` 服务的两个版本之间划分流量。
|
||||
|
||||
在这个示例中,我们将流量带到 `reviews` 服务中并拦截流量,这样,50% 的流量会流向服务的 `v1`,另外 50% 的流量会流向 `v2 `。
|
||||
|
||||
部署这个虚拟服务后,我们将生成流量,并通过 Kiali 可视化看到流量平均路由到服务的两个版本中。
|
||||
|
||||
要为 `reviews` 服务部署虚拟服务和目标规则:
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到安装了 Istio 的集群,然后单击 **Explore**。
|
||||
1. 在安装了 Istio 的集群中,点击左侧导航栏中的 **Istio > DestinationRules**。
|
||||
1. 单击**创建**。
|
||||
1. 复制并粘贴下面的 DestinationRule YAML。
|
||||
1. 单击**创建**。
|
||||
1. 单击**以 YAML 文件编辑**并使用此配置:
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: reviews
|
||||
spec:
|
||||
host: reviews
|
||||
subsets:
|
||||
- name: v1
|
||||
labels:
|
||||
version: v1
|
||||
- name: v2
|
||||
labels:
|
||||
version: v2
|
||||
- name: v3
|
||||
labels:
|
||||
version: v3
|
||||
```
|
||||
1. 单击**创建**。
|
||||
|
||||
然后,部署提供利用 DestinationRule 的流量路由的 VirtualService:
|
||||
|
||||
1. 单击侧导航栏中的 **VirtualService**。
|
||||
1. 单击**使用 YAML 文件创建**。
|
||||
1. 复制并粘贴下面的 VirtualService YAML。
|
||||
1. 单击**创建**。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews
|
||||
spec:
|
||||
hosts:
|
||||
- reviews
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: reviews
|
||||
subset: v1
|
||||
weight: 50
|
||||
- destination:
|
||||
host: reviews
|
||||
subset: v3
|
||||
weight: 50
|
||||
---
|
||||
```
|
||||
|
||||
**结果**:生成流到该服务的流量时(例如,刷新 Ingress Gateway URL),你可以在 Kiali 流量图中看到流到 `reviews` 服务的流量被平均分配到了 `v1` 和 `v3`。
|
||||
|
||||
### 后续步骤
|
||||
[生成和查看流量](generate-and-view-traffic.md)
|
||||
@@ -0,0 +1,360 @@
|
||||
---
|
||||
title: 3. 使用 Istio Sidecar 添加部署和服务
|
||||
---
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
要为工作负载启用 Istio,你必须先在集群和命名空间中安装 Istio 应用。
|
||||
|
||||
:::
|
||||
|
||||
在命名空间中启用 Istio 只会为新工作负载启用自动 sidecar 注入。要为现有工作负载启用 Envoy sidecar,你需要手动为每个工作负载启用它。
|
||||
|
||||
要在命名空间中的现有工作负载上注入 Istio sidecar:
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要可视化的集群,然后单击 **Explore**。
|
||||
1. 点击**工作负载**。
|
||||
1. 转到要注入 Istio sidecar 的工作负载,然后单击 **⋮ > 重新部署**。重新部署工作负载后,该工作负载会自动注入 Envoy sidecar。
|
||||
|
||||
等待几分钟,然后工作负载将升级并具有 Istio sidecar。单击它并转到**容器**。你应该能看到该工作负载旁边的 `istio-proxy`。这意味着为工作负载启用了 Istio sidecar。Istio 正在为 Sidecar Envoy 做所有的接线工作。如果你现在在 yaml 中启用它们,Istio 可以自动执行所有功能。
|
||||
|
||||
### 添加部署和服务
|
||||
|
||||
以下是在命名空间中添加新 **Deployment** 的几种方法:
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 点击**工作负载**。
|
||||
1. 单击**创建**。
|
||||
1. 点击 **Deployment**。
|
||||
1. 填写表单,或**以 YAML 文件编辑**。
|
||||
1. 单击**创建**。
|
||||
|
||||
要将 **Service** 添加到你的命名空间:
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 点击**服务发现 > 服务**。
|
||||
1. 单击**创建**。
|
||||
1. 选择所需的服务类型。
|
||||
1. 填写表单,或**以 YAML 文件编辑**。
|
||||
1. 点击**创建**。
|
||||
|
||||
你还可以使用 kubectl **shell** 来创建 deployment 和 service:
|
||||
|
||||
1. 如果你的文件存储在本地集群中,运行 `kubectl create -f <name of service/deployment file>.yaml`。
|
||||
1. 或运行 `cat<< EOF | kubectl apply -f -`,将文件内容粘贴到终端,然后运行 `EOF` 来完成命令。
|
||||
|
||||
### 部署和服务示例
|
||||
|
||||
接下来,我们为 Istio 文档中的 BookInfo 应用的示例部署和服务添加 Kubernetes 资源:
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 在顶部导航栏中,打开 kubectl shell。
|
||||
1. 运行 `cat<< EOF | kubectl apply -f -`。
|
||||
1. 将以下资源复制到 shell 中。
|
||||
1. 运行 `EOF`。
|
||||
|
||||
这将在 Istio 的示例 BookInfo 应用中设置以下示例资源:
|
||||
|
||||
Details 服务和部署:
|
||||
|
||||
- 一个 `details` Service。
|
||||
- 一个 `bookinfo-details` 的 ServiceAccount。
|
||||
- 一个 `details-v1` Deployment。
|
||||
|
||||
Ratings 服务和部署:
|
||||
|
||||
- 一个 `ratings` Service。
|
||||
- 一个 `bookinfo-ratings` 的 ServiceAccount。
|
||||
- 一个 `ratings-v1` Deployment。
|
||||
|
||||
Reviews 服务和部署(三个版本):
|
||||
|
||||
- 一个 `reviews` Service。
|
||||
- 一个 `bookinfo-reviews` 的 ServiceAccount。
|
||||
- 一个 `reviews-v1` Deployment。
|
||||
- 一个 `reviews-v2` Deployment。
|
||||
- 一个 `reviews-v3` Deployment。
|
||||
|
||||
Productpage 服务和部署:
|
||||
|
||||
这是应用的主页,可以通过网络浏览器中查看。将从该页面调用其他服务。
|
||||
|
||||
- 一个 `productpage` service。
|
||||
- 一个 `bookinfo-productpage` 的 ServiceAccount。
|
||||
- 一个 `productpage-v1` Deployment。
|
||||
|
||||
### 资源 YAML
|
||||
|
||||
```yaml
|
||||
# Copyright 2017 Istio Authors
|
||||
#
|
||||
# Licensed under the Apache License, Version 2.0 (the "License");
|
||||
# you may not use this file except in compliance with the License.
|
||||
# You may obtain a copy of the License at
|
||||
#
|
||||
# http://www.apache.org/licenses/LICENSE-2.0
|
||||
#
|
||||
# Unless required by applicable law or agreed to in writing, software
|
||||
# distributed under the License is distributed on an "AS IS" BASIS,
|
||||
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
# See the License for the specific language governing permissions and
|
||||
# limitations under the License.
|
||||
|
||||
##################################################################################################
|
||||
# Details service
|
||||
##################################################################################################
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: details
|
||||
labels:
|
||||
app: details
|
||||
service: details
|
||||
spec:
|
||||
ports:
|
||||
- port: 9080
|
||||
name: http
|
||||
selector:
|
||||
app: details
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: bookinfo-details
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: details-v1
|
||||
labels:
|
||||
app: details
|
||||
version: v1
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: details
|
||||
version: v1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: details
|
||||
version: v1
|
||||
spec:
|
||||
serviceAccountName: bookinfo-details
|
||||
containers:
|
||||
- name: details
|
||||
image: docker.io/istio/examples-bookinfo-details-v1:1.15.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
##################################################################################################
|
||||
# Ratings service
|
||||
##################################################################################################
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: ratings
|
||||
labels:
|
||||
app: ratings
|
||||
service: ratings
|
||||
spec:
|
||||
ports:
|
||||
- port: 9080
|
||||
name: http
|
||||
selector:
|
||||
app: ratings
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: bookinfo-ratings
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: ratings-v1
|
||||
labels:
|
||||
app: ratings
|
||||
version: v1
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: ratings
|
||||
version: v1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: ratings
|
||||
version: v1
|
||||
spec:
|
||||
serviceAccountName: bookinfo-ratings
|
||||
containers:
|
||||
- name: ratings
|
||||
image: docker.io/istio/examples-bookinfo-ratings-v1:1.15.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
##################################################################################################
|
||||
# Reviews service
|
||||
##################################################################################################
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: reviews
|
||||
labels:
|
||||
app: reviews
|
||||
service: reviews
|
||||
spec:
|
||||
ports:
|
||||
- port: 9080
|
||||
name: http
|
||||
selector:
|
||||
app: reviews
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: bookinfo-reviews
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: reviews-v1
|
||||
labels:
|
||||
app: reviews
|
||||
version: v1
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: reviews
|
||||
version: v1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: reviews
|
||||
version: v1
|
||||
spec:
|
||||
serviceAccountName: bookinfo-reviews
|
||||
containers:
|
||||
- name: reviews
|
||||
image: docker.io/istio/examples-bookinfo-reviews-v1:1.15.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: reviews-v2
|
||||
labels:
|
||||
app: reviews
|
||||
version: v2
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: reviews
|
||||
version: v2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: reviews
|
||||
version: v2
|
||||
spec:
|
||||
serviceAccountName: bookinfo-reviews
|
||||
containers:
|
||||
- name: reviews
|
||||
image: docker.io/istio/examples-bookinfo-reviews-v2:1.15.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: reviews-v3
|
||||
labels:
|
||||
app: reviews
|
||||
version: v3
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: reviews
|
||||
version: v3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: reviews
|
||||
version: v3
|
||||
spec:
|
||||
serviceAccountName: bookinfo-reviews
|
||||
containers:
|
||||
- name: reviews
|
||||
image: docker.io/istio/examples-bookinfo-reviews-v3:1.15.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
##################################################################################################
|
||||
# Productpage services
|
||||
##################################################################################################
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: productpage
|
||||
labels:
|
||||
app: productpage
|
||||
service: productpage
|
||||
spec:
|
||||
ports:
|
||||
- port: 9080
|
||||
name: http
|
||||
selector:
|
||||
app: productpage
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: bookinfo-productpage
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: productpage-v1
|
||||
labels:
|
||||
app: productpage
|
||||
version: v1
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: productpage
|
||||
version: v1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: productpage
|
||||
version: v1
|
||||
spec:
|
||||
serviceAccountName: bookinfo-productpage
|
||||
containers:
|
||||
- name: productpage
|
||||
image: docker.io/istio/examples-bookinfo-productpage-v1:1.15.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
```
|
||||
|
||||
### 后续步骤
|
||||
[设置 Istio Gateway](set-up-istio-gateway.md)
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: Pod 安全策略
|
||||
---
|
||||
|
||||
:::note
|
||||
|
||||
本文介绍的集群选项仅适用于 [Rancher 已在其中启动 Kubernetes 的集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)。
|
||||
|
||||
:::
|
||||
|
||||
你可以在创建项目的时候设置 Pod 安全策略(PSP)。如果在创建项目期间没有为项目分配 PSP,你也随时可以将 PSP 分配给现有项目。
|
||||
|
||||
### 先决条件
|
||||
|
||||
- 在 Rancher 中创建 Pod 安全策略。在将默认 PSP 分配给现有项目之前,你必须有一个可分配的 PSP。有关说明,请参阅[创建 Pod 安全策略](../../new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)。
|
||||
- 将默认 Pod 安全策略分配给项目所属的集群。如果 PSP 还没有应用到集群,你无法将 PSP 分配给项目。有关详细信息,请参阅[将 pod 安全策略添加到集群](../../new-user-guides/manage-clusters/add-a-pod-security-policy.md)。
|
||||
|
||||
### 应用 Pod 安全策略
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到需要移动命名空间的集群,然后单击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 找到要添加 PSP 的项目。在该项目中选择 **⋮ > 编辑配置**。
|
||||
1. 从 **Pod 安全策略**下拉列表中,选择要应用于项目的 PSP。
|
||||
将 PSP 分配给项目将:
|
||||
|
||||
- 覆盖集群的默认 PSP。
|
||||
- 将 PSP 应用于项目。
|
||||
- 将 PSP 应用到后续添加到项目中的命名空间。
|
||||
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**:已将 PSP 应用到项目以及项目内的命名空间。
|
||||
|
||||
:::note
|
||||
|
||||
对于在分配 PSP 之前已经在集群或项目中运行工作负载,Rancher 不会检查它们是否符合 PSP。你需要克隆或升级工作负载以查看它们是否通过 PSP。
|
||||
|
||||
:::
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: Rancher 项目中资源配额的工作原理
|
||||
---
|
||||
|
||||
Rancher 中的资源配额包含与 [Kubernetes 原生版本](https://kubernetes.io/docs/concepts/policy/resource-quotas/)相同的功能。Rancher 还扩展了资源配额的功能,让你将资源配额应用于项目。
|
||||
|
||||
在标准 Kubernetes deployment 中,资源配额会应用于各个命名空间。但是,你不能通过单次操作将配额应用到多个命名空间,而必须多次应用资源配额。
|
||||
|
||||
在下图中,Kubernetes 管理员试图在没有 Rancher 的情况下强制执行资源配额。管理员想要使用一个资源配额来为集群中的每个命名空间配置统一的 CPU 和内存限制 (`Namespace 1-4`)。但是,在 Kubernetes 的基础版本中,每个命名空间都需要单独设置资源配额。因此,管理员必须创建四个配置相同规格的不同资源配额(`Resource Quota 1-4`)并单独应用这些配额。
|
||||
|
||||
<sup>Kubernetes 基础版本:每个命名空间都需要独立设置资源配额</sup>
|
||||
|
||||

|
||||
|
||||
和原生 Kubernetes 相比,Rancher 的资源配额有不同。在 Rancher 中,你可以把资源配额应用到项目层级,进而让项目的资源配额沿用到项目内的每一个命名空间,然后 Kubernetes 会使用原生的资源配额来强制执行你设置的限制。如果要更改特定命名空间的配额,你也可以覆盖设置。
|
||||
|
||||
项目配额包括你在创建或编辑集群时设置的两个限制:
|
||||
<a id="project-limits"></a>
|
||||
|
||||
- **项目限制**:
|
||||
|
||||
配置了项目中所有命名空间共享的每个指定资源的总限制。
|
||||
|
||||
- **命名空间默认限制**:
|
||||
|
||||
配置了每个命名空间对每个指定资源的默认配额。
|
||||
如果项目中的命名空间配置没有被覆盖,那么此限制会自动绑定到命名空间并强制执行。
|
||||
|
||||
|
||||
在下图中,Rancher 管理员想使用资源配额来为项目中的每个命名空间(`命名空间 1-4`)设置相同的 CPU 和内存限制。在 Rancher 中,管理员可以为项目设置资源配额(`项目资源配额`),而不需要为命名空间单独进行设置。此配额包括整个项目(`项目限制`)和单个命名空间(`命名空间默认限制`)的资源限制。然后,Rancher 会将`命名空间默认限制`的配额沿用到每个命名空间(`命名空间资源配额`)。
|
||||
|
||||
<sup>Rancher:资源配额沿用到每个命名空间</sup>
|
||||
|
||||

|
||||
|
||||
以下介绍在 Rancher UI **_中_** 创建的命名空间的更细微的功能。如果你删除了项目级别的资源配额,无论命名空间层级是否有自定义的资源配额,项目内的所有命名空间也会移除这个资源配额。在项目层级修改已有的命名空间默认资源配额,不会影响命名空间内的资源配额,修改后的项目层级资源配额只会对以后新建的命名空间生效。要修改多个现有命名空间的默认限制,你可以在项目层级删除该限制,然后再使用新的默认值重新创建配额。这种方式会将新的默认值应用于项目中的所有现有命名空间。
|
||||
|
||||
在项目中创建命名空间之前,Rancher 会使用默认限制和覆盖限制来对比项目内的可用资源和请求资源。
|
||||
如果请求的资源超过了项目中这些资源的剩余容量,Rancher 将为命名空间分配该资源的剩余容量。
|
||||
|
||||
但是,在 Rancher 的 UI **_外_** 创建的命名空间的处理方法则不一样。对于通过 `kubectl` 创建的命名空间,如果请求的资源量多余项目内的余量,Rancher 会分配一个数值为 **0** 的资源配额。
|
||||
|
||||
要使用 `kubectl` 在现有项目中创建命名空间,请使用 `field.cattle.io/projectId` 注释。要覆盖默认的请求配额限制,请使用 `field.cattle.io/resourceQuota` 注释。
|
||||
|
||||
请注意,Rancher 只会覆盖项目配额上定义的资源限制。
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
annotations:
|
||||
field.cattle.io/projectId: [your-cluster-ID]:[your-project-ID]
|
||||
field.cattle.io/resourceQuota: '{"limit":{"limitsCpu":"100m", "configMaps": "50"}}'
|
||||
name: my-ns
|
||||
```
|
||||
在此示例中,如果项目配额在其资源列表中不包含 configMaps,那么 Rancher 将忽略此覆盖中的 `configMaps`。
|
||||
|
||||
对于项目中未定义的资源,建议你在命名空间中创建专用的 `ResourceQuota` 对象来配置其它自定义限制。
|
||||
资源配额是原生 Kubernetes 对象,如果命名空间属于具有配额的项目,Rancher 将忽略用户定义的配额,从而给予用户更多的控制权。
|
||||
|
||||
下表对比了 Rancher 和 Kubernetes 资源配额的主要区别:
|
||||
|
||||
| Rancher 资源配额 | Kubernetes 资源配额 |
|
||||
| ---------------------------------------------------------- | -------------------------------------------------------- |
|
||||
| 应用于项目和命名空间。 | 仅应用于命名空间。 |
|
||||
| 为项目中的所有命名空间创建资源池。 | 将静态资源限制应用到单独的命名空间。 |
|
||||
| 通过沿用的模式,将资源配额应用于各个命名空间。 | 仅应用于指定的命名空间。 |
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: 覆盖命名空间的默认限制
|
||||
---
|
||||
|
||||
**命名空间默认限制**会在创建时从项目沿用到每个命名空间。但在某些情况下,你可能需要增加或减少特定命名空间的配额。在这种情况下,你可以通过编辑命名空间来覆盖默认限制。
|
||||
|
||||
在下图中,Rancher 管理员的项目有一个已生效的资源配额。但是,管理员想要覆盖 `Namespace 3` 的命名空间限制,以便让该命名空间使用更多资源。因此,管理员[提高了 `Namespace 3` 的命名空间限制](../../../new-user-guides/manage-clusters/projects-and-namespaces.md),以便命名空间可以访问更多资源。
|
||||
|
||||
<sup>命名空间默认限制覆盖</sup>
|
||||
|
||||

|
||||
|
||||
有关详细信息,请参阅[如何编辑命名空间资源配额](../../../new-user-guides/manage-clusters/projects-and-namespaces.md)。
|
||||
|
||||
### 编辑命名空间资源配额
|
||||
|
||||
如果你已为项目配置了资源配额,你可以覆盖命名空间默认限制,从而为特定命名空间提供对更多(或更少)项目资源的访问权限:
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要编辑命名空间资源配额的集群,然后单击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 找到要为其编辑资源配额的命名空间。单击 **⋮ > 编辑配置**。
|
||||
1. 编辑资源限制。这些限制决定了命名空间可用的资源。必须在项目限制范围内配置这些配额限制。
|
||||
|
||||
有关每个**资源类型**的详细信息,请参阅[类型参考](resource-quota-types.md)。
|
||||
|
||||
:::note
|
||||
|
||||
- 如果没有为项目配置资源配额,这些选项将不可用。
|
||||
- 如果你输入的限制超过了配置的项目限制,你将无法保存修改。
|
||||
|
||||
:::
|
||||
|
||||
**结果**:覆盖设置已经应用到命名空间的资源配额。
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: 资源配额类型参考
|
||||
---
|
||||
|
||||
创建资源配额相当于配置项目可用的资源池。你可以为以下资源类型设置资源配额:
|
||||
|
||||
| 资源类型 | 描述 |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| CPU 限制\* | 分配给项目/命名空间的最大 CPU 量(以[毫核](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)为单位)<sup>1</sup> |
|
||||
| CPU 预留\* | 预留给项目/命名空间的最小 CPU 量(以毫核为单位)<sup>1</sup> |
|
||||
| 内存限制\* | 分配给项目/命名空间的最大内存量(以字节为单位)<sup>1</sup> |
|
||||
| 内存预留\* | 预留给项目/命名空间的最小内存量(以字节为单位)<sup>1</sup> |
|
||||
| 存储预留 | 预留给项目/命名空间的最小存储量(以千兆字节为单位) |
|
||||
| 服务负载均衡器 | 项目/命名空间中可以存在的负载均衡器服务的最大数量 |
|
||||
| 服务节点端口 | 项目/命名空间中可以存在的节点端口服务的最大数量 |
|
||||
| Pod | 可以在项目/命名空间中以非终端状态存在的 pod 的最大数量(即 `.status.phase in (Failed, Succeeded)` 等于 true 的 pod) |
|
||||
| Services | 项目/命名空间中可以存在的最大 service 数量 |
|
||||
| ConfigMap | 项目/命名空间中可以存在的 ConfigMap 的最大数量 |
|
||||
| 持久卷声明 | 项目/命名空间中可以存在的持久卷声明的最大数量 |
|
||||
| ReplicationController | 项目/命名空间中可以存在的最大 ReplicationController 数量 |
|
||||
| 密文 | 项目/命名空间中可以存在的最大密文数量 |
|
||||
|
||||
:::note **<sup>*</sup>**
|
||||
|
||||
在设置资源配额时,如果你在项目或命名空间上设置了任何与 CPU 或内存相关的内容(即限制或预留),所有容器都需要在创建期间设置各自的 CPU 或内存字段。你可以同时设置容器的默认资源限制,以避免为每个工作负载显式设置这些限制。详情请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits)。
|
||||
|
||||
:::
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: 设置容器默认资源限制
|
||||
---
|
||||
|
||||
在设置资源配额时,如果你在项目或命名空间上设置了任何与 CPU 或内存相关的内容(即限制或预留),所有容器都需要在创建期间设置各自的 CPU 或内存字段。详情请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits)。
|
||||
|
||||
为了避免在创建工作负载期间对每个容器设置这些限制,可以在命名空间上指定一个默认的容器资源限制。
|
||||
|
||||
### 编辑容器默认资源限制
|
||||
|
||||
你可以在以下情况下编辑容器的默认资源限制:
|
||||
|
||||
- 你在项目上设置了 CPU 或内存资源配额,现在需要为容器设置相应的默认值。
|
||||
- 你需要编辑容器的默认资源限制。
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要编辑默认资源限制的集群,然后单击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 找到要编辑容器默认资源限制的项目。在该项目中选择 **⋮ > 编辑配置**。
|
||||
1. 展开**容器默认资源限制**并编辑对应的值。
|
||||
|
||||
### 沿用资源限制
|
||||
|
||||
在项目级别设置默认容器资源限制后,项目中所有新建的命名空间都会沿用这个资源限制参数。新设置的限制不会影响项目中现有的命名空间。你需要为项目中的现有命名空间手动设置默认容器资源限制,以便创建容器时能应用该限制。
|
||||
|
||||
你可以为项目设置容器的默认资源限制并启动任何商店应用。
|
||||
|
||||
在命名空间上配置容器默认资源限制后,在该命名空间中创建的任何容器都会沿用该默认值。你可以在工作负载创建期间覆盖这些限制/预留。
|
||||
|
||||
### 容器资源配额类型
|
||||
|
||||
可以配置以下资源限制:
|
||||
|
||||
| 资源类型 | 描述 |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| CPU 限制 | 分配给容器的最大 CPU 量(以[毫核](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)为单位)。 |
|
||||
| CPU 预留 | 保留给容器的最小 CPU 量(以毫核为单位)。 |
|
||||
| 内存限制 | 分配给容器的最大内存量(以字节为单位)。 |
|
||||
| 内存预留 | 保留给容器的最小内存量(以字节为单位)。 |
|
||||
| NVIDIA GPU 限制/预留 | 分配给容器的 GPU 数量。GPU 的限制和预留始终相同。 |
|
||||
@@ -0,0 +1,148 @@
|
||||
---
|
||||
title: 持久化 Grafana 仪表板
|
||||
---
|
||||
|
||||
要在重启 Grafana 实例后保存 Grafana 仪表板,请将仪表板的配置 JSON 添加到 ConfigMap 中。ConfigMap 还支持使用基于 GitOps 或 CD 的方法来部署仪表板,从而让你对仪表板进行版本控制。
|
||||
|
||||
- [创建持久化 Grafana 仪表板](#创建持久化-grafana-仪表板)
|
||||
- [已知问题](#已知问题)
|
||||
|
||||
## 创建持久化 Grafana 仪表板
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
- 已安装 Monitoring 应用。
|
||||
- 要创建持久化仪表板,你必须在包含 Grafana 仪表板的项目或命名空间中至少具有**管理 ConfigMap** 的 Rancher RBAC 权限。这与 Monitoring Chart 公开的 `monitoring-dashboard-edit` 或 `monitoring-dashboard-admin` Kubernetes 原生 RBAC 角色对应。
|
||||
- 要查看指向外部监控 UI(包括 Grafana 仪表板)的链接,你至少需要一个 [project-member 角色](../../../integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md#具有-rancher-权限的用户)。
|
||||
|
||||
:::
|
||||
|
||||
### 1. 获取要持久化的仪表板的 JSON 模型
|
||||
|
||||
要创建持久化仪表板,你需要获取要持久化的仪表板的 JSON 模型。你可以使用预制仪表板或自行构建仪表板。
|
||||
|
||||
要使用预制仪表板,请转到 [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards),打开详细信息页面,然后单击 **Download JSON** 按钮来获取下一步所需的 JSON 模型。
|
||||
|
||||
要使用你自己的仪表板:
|
||||
|
||||
1. 点击链接打开 Grafana。在集群详细信息页面上,单击 **Monitoring**。
|
||||
1. 登录到 Grafana。请注意,Grafana 实例的默认 Admin 用户名和密码是 `admin/prom-operator`。你还可以在部署或升级 Chart 时替换凭证。
|
||||
|
||||
:::note
|
||||
|
||||
无论谁拥有密码,你都需要在部署了 Rancher Monitoring 的项目中至少具有<b>管理服务</b>或<b>查看监控</b>的权限才能访问 Grafana 实例。你还可以在部署或升级 Chart 时替换凭证。
|
||||
|
||||
:::
|
||||
|
||||
1. 使用 Grafana UI 创建仪表板。完成后,单击顶部导航菜单中的齿轮图标转到仪表板设置页面。在左侧导航菜单中,单击 **JSON Model**。
|
||||
1. 复制出现的 JSON 数据结构。
|
||||
|
||||
### 2. 使用 Grafana JSON 模型创建 ConfigMap
|
||||
|
||||
在包含 Grafana 仪表板的命名空间中创建一个 ConfigMap(默认为 cattle-dashboards )。
|
||||
|
||||
ConfigMap 与以下内容类似:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
labels:
|
||||
grafana_dashboard: "1"
|
||||
name: <dashboard-name>
|
||||
namespace: cattle-dashboards # 如果不使用默认命名空间,则修改此值
|
||||
data:
|
||||
<dashboard-name>.json: |-
|
||||
<copied-json>
|
||||
```
|
||||
|
||||
默认情况下,Grafana 配置为监控 `cattle-dashboards` 命名空间中带有 `grafana_dashboard` 标签的所有 ConfigMap。
|
||||
|
||||
要让 Grafana 监控所有命名空间中的 ConfigMap,请参阅[本节](#为-grafana-仪表板-configmap-配置命名空间)。
|
||||
|
||||
要在 Rancher UI 中创建 ConfigMap:
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要可视化的集群,然后单击 **Explore**。
|
||||
1. 单击**更多资源 > 核心 > 配置映射**。
|
||||
1. 单击**创建**。
|
||||
1. 设置与上例类似的键值对。输入 `<dashboard-name>.json` 的值时,点击**从文件读取**并上传 JSON 数据模型。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**:创建 ConfigMap 后,即使 Grafana pod 重启了,ConfigMap 也能显示在 Grafana UI 上并持久化。
|
||||
|
||||
无法在 Grafana UI 中删除或编辑使用 ConfigMap 持久化了的仪表板。
|
||||
|
||||
如果你在 Grafana UI 中删除仪表板,你将看到 "Dashboard cannot be deleted because it was provisioned" 的错误消息。如需删除仪表板,你需要删除 ConfigMap。
|
||||
|
||||
### 为 Grafana 仪表板 ConfigMap 配置命名空间
|
||||
|
||||
要让 Grafana 监控所有命名空间中的 ConfigMap,请在 `rancher-monitoring` Helm chart 中指定以下值:
|
||||
|
||||
```
|
||||
grafana.sidecar.dashboards.searchNamespace=ALL
|
||||
```
|
||||
|
||||
请注意,Monitoring Chart 用于添加 Grafana 仪表板的 RBAC 角色仅能让用户将仪表板添加到定义在 `grafana.dashboards.namespace` 中的命名空间,默认为 `cattle-dashboards`。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher 版本低于 v2.5.8">
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
- 已安装 Monitoring 应用。
|
||||
- 你必须具有 cluster-admin ClusterRole 权限。
|
||||
|
||||
:::
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要在其中配置 Grafana 命名空间的集群,然后单击 **Explore**。
|
||||
1. 在左侧导航栏中,单击**监控**。
|
||||
1. 点击 **Grafana**。
|
||||
1. 登录到 Grafana。请注意,Grafana 实例的默认 Admin 用户名和密码是 `admin/prom-operator`。你还可以在部署或升级 Chart 时替换凭证。
|
||||
|
||||
:::note
|
||||
|
||||
无论谁拥有密码,都需要 Rancher 的集群管理员权限才能访问 Grafana 实例。
|
||||
|
||||
:::
|
||||
|
||||
1. 转到要进行持久化的仪表板。在顶部导航菜单中,通过单击齿轮图标转到仪表板设置。
|
||||
1. 在左侧导航菜单中,单击 **JSON Model**。
|
||||
1. 复制出现的 JSON 数据结构。
|
||||
1. 在 `cattle-dashboards` 命名空间中创建一个 ConfigMap。ConfigMap 需要有 `grafana_dashboard: "1"` 标签。将 JSON 粘贴到 ConfigMap 中,格式如下例所示:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
labels:
|
||||
grafana_dashboard: "1"
|
||||
name: <dashboard-name>
|
||||
namespace: cattle-dashboards
|
||||
data:
|
||||
<dashboard-name>.json: |-
|
||||
<copied-json>
|
||||
```
|
||||
|
||||
**结果**:创建 ConfigMap 后,即使 Grafana pod 重启了,ConfigMap 也能显示在 Grafana UI 上并持久化。
|
||||
|
||||
无法在 Grafana UI 中删除使用 ConfigMap 持久化了的仪表板。如果你在 Grafana UI 中删除仪表板,你将看到 "Dashboard cannot be deleted because it was provisioned" 的错误消息。如需删除仪表板,你需要删除 ConfigMap。
|
||||
|
||||
为防止在卸载 Monitoring v2 时删除持久化的仪表板,请将以下注释添加到 `cattle-dashboards` 命名空间:
|
||||
|
||||
```
|
||||
helm.sh/resource-policy: "keep"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 已知问题
|
||||
|
||||
如果你的 Monitoring V2 版本是 v9.4.203 或更低版本,卸载 Monitoring chart 将同时删除 `cattle-dashboards` 命名空间,所有持久化的仪表板将被删除(除非命名空间带有注释 `helm.sh/resource-policy: "keep"`)。
|
||||
|
||||
Rancher 2.5.8 发布的新 Monitoring Chart 中默认添加了该注解,但使用早期 Rancher 版本的用户仍需手动应用该注释。
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: 自定义 Grafana 仪表板
|
||||
---
|
||||
|
||||
在本文中,你将学习通过自定义 Grafana 仪表板来显示特定容器的指标。
|
||||
|
||||
### 先决条件
|
||||
|
||||
在自定义 Grafana 仪表板之前,你必须先安装 `rancher-monitoring` 应用。
|
||||
|
||||
要查看指向外部监控 UI(包括 Grafana 仪表板)的链接,你至少需要一个 [project-member 角色](../../../integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md#具有-rancher-权限的用户)。
|
||||
|
||||
### 登录 Grafana
|
||||
|
||||
1. 在 Rancher UI 中,转到要自定义的仪表板的集群。
|
||||
1. 在左侧导航栏中,单击**监控**。
|
||||
1. 单击 **Grafana**。Grafana 仪表板将在新选项卡中打开。
|
||||
1. 转到左下角的登录图标,然后单击 **Sign In**。
|
||||
1. 登录到 Grafana。Grafana 实例的默认 Admin 用户名和密码是 `admin/prom-operator`(无论谁拥有密码,都需要 Rancher 的集群管理员权限才能访问 Grafana 实例)。你还可以在部署或升级 Chart 时替换凭证。
|
||||
|
||||
|
||||
### 获取支持 Grafana 面板的 PromQL 查询
|
||||
|
||||
对于任何面板,你可以单击标题并单击 **Explore** 以获取支持图形的 PromQL 查询。
|
||||
|
||||
例如,如果要获取 Alertmanager 容器的 CPU 使用率,点击 **CPU Utilization > Inspect**。
|
||||
|
||||
**Data** 选项卡将基础数据显示为时间序列,第一列是时间,第二列是 PromQL 查询结果。复制 PromQL 查询。
|
||||
|
||||
```
|
||||
(1 - (avg(irate({__name__=~"node_cpu_seconds_total|windows_cpu_time_total",mode="idle"}[5m])))) * 100
|
||||
```
|
||||
|
||||
然后,你可以在 Grafana 面板中修改查询,或使用该查询创建新的 Grafana 面板。
|
||||
|
||||
参考:
|
||||
|
||||
- [编辑面板的 Grafana 文档](https://grafana.com/docs/grafana/latest/panels-visualizations/configure-panel-options/#edit-a-panel)
|
||||
- [向仪表板添加面板的 Grafana 文档](https://grafana.com/docs/grafana/latest/panels-visualizations/panel-editor-overview)
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: 调试高内存用量
|
||||
---
|
||||
|
||||
Prometheus 中的每个时间序列都由其[指标名称](https://prometheus.io/docs/practices/naming/#metric-names)和称为[标签](https://prometheus.io/docs/practices/naming/#labels)的可选键值对唯一标识。
|
||||
|
||||
标签允许过滤和聚合时间序列数据,但它们也使 Prometheus 收集的数据量成倍增加。
|
||||
|
||||
每个时间序列都有一组定义的标签,Prometheus 为所有唯一的标签组合生成一个新的时间序列。如果一个指标附加了两个标签,则会为该指标生成两个时间序列。更改任何标签值,包括添加或删除标签,都会创建一个新的时间序列。
|
||||
|
||||
Prometheus 经过了优化,可以存储基于索引的序列数据。它是为相对一致的时间序列数量和相对大量的样本而设计的,这些样本需要随时间从 exporter 处收集。
|
||||
|
||||
但是,Prometheus 没有就快速变化的时间序列数量进行对应的优化。因此,如果你在创建和销毁了大量资源的集群(尤其是多租户集群)上安装 Monitoring,可能会出现内存使用量激增的情况。
|
||||
|
||||
### 减少内存激增
|
||||
|
||||
为了减少内存消耗,Prometheus 可以通过抓取更少的指标或在时间序列上添加更少的标签,从而存储更少的时间序列。要查看使用内存最多的序列,你可以查看 Prometheus UI 中的 TSDB(时序数据库)状态页面。
|
||||
|
||||
分布式 Prometheus 解决方案(例如 [Thanos](https://thanos.io/) 和 [Cortex](https://cortexmetrics.io/))使用了一个替代架构,该架构部署多个小型 Prometheus 实例。如果使用 Thanos,每个 Prometheus 的指标都聚合到通用的 Thanos 部署中,然后再将这些指标导出到 S3 之类的持久存储。这种架构更加健康,能避免给单个 Prometheus 实例带来过多时间序列,同时还能在全局级别查询指标。
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
title: 启用 Monitoring
|
||||
---
|
||||
|
||||
[管理员](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)或[集群所有者](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#集群角色)可以通过配置 Rancher 来部署 Prometheus,从而监控 Kubernetes 集群。
|
||||
|
||||
本文介绍如何使用新的 monitoring 应用在集群内启用监控和告警。
|
||||
|
||||
不论是否使用 SSL,你都可以启用 monitoring。
|
||||
|
||||
## 要求
|
||||
|
||||
- 在每个节点上允许端口 9796 上的流量。Prometheus 将从这些端口抓取指标。
|
||||
- 如果 [PushProx](../../../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#pushprox) 被禁用(`ingressNginx.enabled` 设置为 `false`),或者你已经升级了安装了 Monitoring V1 的 Rancher 版本,你可能还需要为每个节点允许端口 10254 上的流量。
|
||||
- 确保你的集群满足资源要求。集群应至少有 1950Mi 可用内存、2700m CPU 和 50Gi 存储。有关资源限制和请求的详细信息,请参阅[配置资源限制和请求](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#配置资源限制和请求)。
|
||||
- 在使用 RancherOS 或 Flatcar Linux 节点的 RKE 集群上安装 Monitoring 时,请将 etcd 节点证书目录更改为 `/opt/rke/etc/kubernetes/ssl`。
|
||||
- 如果集群是使用 RKE CLI 配置的,而且地址设置为主机名而不是 IP 地址,请在安装的 Values 配置步骤中将 `rkeEtcd.clients.useLocalhost` 设置为 `true`。例如:
|
||||
|
||||
```yaml
|
||||
rkeEtcd:
|
||||
clients:
|
||||
useLocalhost: true
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
如果要设置 Alertmanager、Grafana 或 Ingress,必须通过 Helm chart 部署上的设置来完成。在部署之外创建 Ingress 可能会产生问题。
|
||||
|
||||
:::
|
||||
|
||||
## 设置资源限制和请求
|
||||
|
||||
安装 `rancher-monitoring` 时可以配置资源请求和限制。要从 Rancher UI 配置 Prometheus 资源,请单击左上角的 **Apps > Monitoring**。
|
||||
|
||||
有关默认限制的更多信息,请参阅[此页面](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#配置资源限制和请求)。
|
||||
|
||||
## 安装 Monitoring 应用
|
||||
|
||||
### 在不使用 SSL 的情况下启用 Monitoring
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 点击**集群工具**(左下角)。
|
||||
1. 单击 Monitoring 的**安装**。
|
||||
1. 可选:在 Values 步骤中为 Alerting、Prometheus 和 Grafana 自定义请求、限制等。如需帮助,请参阅[配置参考](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md)。
|
||||
|
||||
**结果**:Monitoring 应用已部署到 `cattle-monitoring-system` 命名空间中。
|
||||
|
||||
### 在使用 SSL 的情况下启用 Monitoring
|
||||
|
||||
1. 按照[此页面](../../new-user-guides/kubernetes-resources-setup/secrets.md)上的步骤创建密文,以便将 SSL 用于告警。
|
||||
- 密文应该创建到 `cattle-monitoring-system` 命名空间中。如果它不存在,请先创建它。
|
||||
- 将 `ca`、`cert` 和 `key` 文件添加到密文中。
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,转到要启用 Monitoring 以与 SSL 一起使用的集群,然后单击 **Explore**。
|
||||
1. 单击 **Apps > Charts**。
|
||||
1. 单击 **Monitoring**。
|
||||
1. 根据你是否已安装 Monitoring,单击**安装**或**更新**。
|
||||
1. 选中**在安装前自定义 Helm 选项**,然后单击**下一步**。
|
||||
1. 单击 **Alerting**。
|
||||
1. 在**补充密文**字段中,添加之前创建的密文。
|
||||
|
||||
**结果**:Monitoring 应用已部署到 `cattle-monitoring-system` 命名空间中。
|
||||
|
||||
[创建接收器](../../../reference-guides/monitoring-v2-configuration/receivers.md#在-rancher-ui-中创建接收器)时,启用 SSL 的接收器(例如电子邮件或 webhook)将具有 **SSL**,其中包含 **CA 文件路径**、**证书文件路径**和**密钥文件路径**字段。使用 `ca`、`cert` 和 `key` 的路径填写这些字段。路径的格式为 `/etc/alertmanager/secrets/name-of-file-in-secret`。
|
||||
|
||||
例如,如果你使用以下键值对创建了一个密文:
|
||||
|
||||
```yaml
|
||||
ca.crt=`base64-content`
|
||||
cert.pem=`base64-content`
|
||||
key.pfx=`base64-content`
|
||||
```
|
||||
|
||||
则**证书文件路径**需要设为 `/etc/alertmanager/secrets/cert.pem`。
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
title: 自定义 Grafana 仪表板
|
||||
---
|
||||
|
||||
无论是用于 rancher-monitoring 还是 Prometheus Federator,Grafana 仪表板的定制方式都是相同的。
|
||||
|
||||
有关说明,请参阅[此页面](../customize-grafana-dashboard.md)。
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: 启用 Prometheus Federator
|
||||
---
|
||||
|
||||
## 要求
|
||||
|
||||
默认情况下,Prometheus Federator 已配置并旨在与 [rancher-monitoring](../../../../pages-for-subheaders/monitoring-and-alerting.md) 一起部署。rancher-monitoring 同时部署了 Prometheus Operator 和 Cluster Prometheus,每个项目监控堆栈(Project Monitoring Stack)默认会联合命名空间范围的指标。
|
||||
|
||||
有关安装 rancher-monitoring 的说明,请参阅[此页面](../enable-monitoring.md)。
|
||||
|
||||
默认配置与你的 rancher-monitoring 堆栈是兼容的。但是,为了提高集群中 Prometheus Federator 的安全性和可用性,我们建议对 rancher-monitoring 进行以下额外的配置:
|
||||
|
||||
- [确保 cattle-monitoring-system 命名空间位于 System 项目中](#确保-cattle-monitoring-system-命名空间位于-system-项目中或者位于一个锁定并能访问集群中其他项目的项目中)
|
||||
- [将 rancher-monitoring 配置为仅监视 Helm Chart 创建的资源](#将-rancher-monitoring-配置为仅监视-helm-chart-创建的资源)
|
||||
- [提高 Cluster Prometheus 的 CPU/内存限制](#提高-cluster-prometheus-的-cpu内存限制)
|
||||
|
||||
### 确保 cattle-monitoring-system 命名空间位于 System 项目中(或者位于一个锁定并能访问集群中其他项目的项目中)
|
||||
|
||||

|
||||
|
||||
Prometheus Operator 的安全模型有一定的要求,即希望部署它的命名空间(例如,`cattle-monitoring-system`)对除集群管理员之外的任何用户都只有有限的访问权限,从而避免通过 Pod 内执行(例如正在执行的 Helm 操作的 Job)来提升权限。此外,如果将 Prometheus Federator 和所有 Project Prometheus 堆栈都部署到 System 项目中,即使网络策略是通过项目网络隔离定义的,每个 Project Prometheus 都依然能够在所有项目中抓取工作负载。它还为项目所有者、项目成员和其他用户提供有限的访问权限,从而确保这些用户无法访问他们不应访问的数据(例如,在 pod 中执行,在项目外部抓取命名空间数据等)。
|
||||
|
||||
1. 打开 `System` 项目以检查你的命名空间:
|
||||
|
||||
在 Rancher UI 中单击 **Cluster > Projects/Namespaces**。这将显示 `System` 项目中的所有命名空间:
|
||||
|
||||

|
||||
|
||||
1. 如果你在 `cattle-monitoring-system` 命名空间中已经安装了一个 Monitoring V2,但该命名空间不在 `System` 项目中,你可以将 `cattle- monitoring-system` 命名空间移动到 `System` 项目或另一个访问受限的项目中。为此,你有以下两种方法:
|
||||
|
||||
- 将命名空间拖放到 `System` 项目。
|
||||
- 选择命名空间右侧的 **⋮**,点击 **Move**,然后从 **Target Project** 下拉列表中选择 `System`:
|
||||
|
||||

|
||||
|
||||
### 将 rancher-monitoring 配置为仅监视 Helm Chart 创建的资源
|
||||
|
||||
每个项目监控堆栈都会监视其他命名空间并收集其他自定义工作负载指标或仪表板。因此,我们建议在所有选择器上配置以下设置,以确保 Cluster Prometheus 堆栈仅监控由 Helm Chart 创建的资源:
|
||||
|
||||
```
|
||||
matchLabels:
|
||||
release: "rancher-monitoring"
|
||||
```
|
||||
|
||||
建议为以下选择器字段赋予此值:
|
||||
- `.Values.alertmanager.alertmanagerSpec.alertmanagerConfigSelector`
|
||||
- `.Values.prometheus.prometheusSpec.serviceMonitorSelector`
|
||||
- `.Values.prometheus.prometheusSpec.podMonitorSelector`
|
||||
- `.Values.prometheus.prometheusSpec.ruleSelector`
|
||||
- `.Values.prometheus.prometheusSpec.probeSelector`
|
||||
|
||||
启用此设置后,你始终可以通过向它们添加 `release: "rancher-monitoring"` 标签来创建由 Cluster Prometheus 抓取的 ServiceMonitor 或 PodMonitor。在这种情况下,即使这些 ServiceMonitor 或 PodMonitor 所在的命名空间不是 System 命名空间,项目监控堆栈也会默认自动忽略它们。
|
||||
|
||||
:::note
|
||||
|
||||
如果你不希望用户能够在 Project 命名空间中创建聚合到 Cluster Prometheus 中的 ServiceMonitor 和 PodMonitor,你可以另外将 Chart 上的 namespaceSelectors 设置为仅目标 System 命名空间(必须包含 `cattle-monitoring-system` 和 `cattle-dashboards`,默认情况下资源通过 rancher-monitoring 部署到该命名空间中。你还需要监控 `default` 命名空间以获取 apiserver 指标,或创建自定义 ServiceMonitor 以抓取位于 `default` 命名空间中的 Service 的 apiserver 指标),从而限制你的 Cluster Prometheus 获取其他 Prometheus Operator CR。在这种情况下,建议设置 `.Values.prometheus.prometheusSpec.ignoreNamespaceSelectors=true`。这样,你可以定义能从 System 命名空间中监视非 System 命名空间的 ServiceMonitor。
|
||||
|
||||
:::
|
||||
|
||||
### 提高 Cluster Prometheus 的 CPU/内存限制
|
||||
|
||||
根据集群的设置,我们一般建议为 Cluster Prometheus 配置大量的专用内存,以避免因内存不足的错误(OOMKilled)而重启。通常情况下,集群中创建的改动项(churn)会导致大量高基数指标在一个时间块内生成并被 Prometheus 引入,然后导致这些错误。这也是为什么默认的 Rancher Monitoring 堆栈希望能分配到大约 4GB 的 RAM 以在正常大小的集群中运行的原因之一。但是,如果你引入向同一个 Cluster Prometheus 发送 `/federate` 请求的项目监控堆栈,并且项目监控堆栈依赖于 Cluster Prometheus 的启动状态来在其命名空间上联合系统数据,那么你更加需要为 Cluster Prometheus 分配足够的 CPU/内存,以防止集群中的所有 Prometheus 项目出现数据间隙的中断。
|
||||
|
||||
:::note
|
||||
|
||||
我们没有 Cluster Prometheus 内存配置的具体建议,因为这完全取决于用户的设置(即遇到高改动率的可能性以及可能同时生成的指标的规模)。不同的设置通常有不同的推荐参数。
|
||||
|
||||
:::
|
||||
|
||||
## 安装 Prometheus Federator 应用程序
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到要安装 Prometheus Federator 的集群,然后单击 **Explore**。
|
||||
1. 点击**应用 > Charts**。
|
||||
1. 单击 **Prometheus Federator** Chart。
|
||||
1. 单击**安装**。
|
||||
1. 在**元数据**页面,点击**下一步**。
|
||||
1. 在**命名空间** > **项目 Release 命名空间项目 ID** 字段中,`System 项目`是默认值,但你可以使用具有类似[有限访问权限](#确保-cattle-monitoring-system-命名空间位于-system-项目中或者位于一个锁定并能访问集群中其他项目的项目中)的另一个项目覆盖它。你可以在 local 上游集群中运行以下命令来找到项目 ID:
|
||||
|
||||
```plain
|
||||
kubectl get projects -A -o custom-columns="NAMESPACE":.metadata.namespace,"ID":.metadata.name,"NAME":.spec.displayName
|
||||
```
|
||||
|
||||
1. 单击**安装**。
|
||||
|
||||
**结果**:Prometheus Federator 应用程序已部署在 `cattle-monitoring-system` 命名空间中。
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: 安装 Project Monitor
|
||||
---
|
||||
|
||||
在要启用项目监控的各个项目中安装 **Project Monitor**。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
|
||||
1. 在**集群**页面中,转到要启用监控的集群,然后单击 **Explore**。
|
||||
|
||||
1. 单击左侧导航栏上的**监控 > Project Monitor**。然后,点击右上角的**创建**。
|
||||
|
||||

|
||||
|
||||
1. 从下拉菜单中选择你的项目,然后再次单击**创建**。
|
||||
|
||||

|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: 为工作负载设置 Prometheus Federator
|
||||
---
|
||||
|
||||
### 显示工作负载的 CPU 和内存指标
|
||||
|
||||
使用 Prometheus Federator 显示 CPU 和内存指标的方式与使用 rancher-monitoring 相同。有关说明,请参阅[此处](../set-up-monitoring-for-workloads.md#显示工作负载的-cpu-和内存指标)。
|
||||
|
||||
### 设置 CPU 和内存之外的指标
|
||||
|
||||
使用 Prometheus Federator 设置 CPU 和内存之外的指标与使用 rancher-monitoring 的方式相同。有关说明,请参阅[此处](../set-up-monitoring-for-workloads.md#设置-cpu-和内存之外的指标)。
|
||||
|
||||
<!-- ### Custom Metrics -->
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: 卸载 Prometheus Federator
|
||||
---
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 在左侧导航栏中,点击 **Apps**。
|
||||
1. 点击**已安装的应用**。
|
||||
1. 转到 `cattle-monitoring-system` 命名空间并选中 `rancher-monitoring-crd` 和 `rancher-monitoring`。
|
||||
1. 单击**删除**。
|
||||
1. 确认**删除**。
|
||||
|
||||
**结果**:已卸载 `prometheus-federator`。
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: 为工作负载设置 Monitoring
|
||||
---
|
||||
|
||||
如果你只需要工作负载的 CPU 和内存时间序列,则不需要部署 ServiceMonitor 或 PodMonitor,因为 Monitoring 应用默认会收集资源使用情况的指标数据。
|
||||
|
||||
设置工作负载监控的步骤取决于你是否需要基本指标(例如工作负载的 CPU 和内存),或者是否需要从工作负载中抓取自定义指标。
|
||||
|
||||
如果你只需要工作负载的 CPU 和内存时间序列,则不需要部署 ServiceMonitor 或 PodMonitor,因为 Monitoring 应用默认会收集资源使用情况的指标数据。资源使用的时间序列数据在 Prometheus 的本地时间序列数据库中。
|
||||
|
||||
Grafana 显示聚合数据,你也可以使用 PromQL 查询来查看单个工作负载的数据。进行 PromQL 查询后,你可以在 Prometheus UI 中单独执行查询并查看可视化的时间序列,你也可以使用查询来自定义显示工作负载指标的 Grafana 仪表板。有关工作负载指标的 PromQL 查询示例,请参阅[本节](../../../integrations-in-rancher/monitoring-and-alerting/promql-expressions.md#工作负载指标)。
|
||||
|
||||
要为你的工作负载设置自定义指标,你需要设置一个 Exporter 并创建一个新的 ServiceMonitor 自定义资源,从而将 Prometheus 配置为从 Exporter 中抓取指标。
|
||||
|
||||
### 显示工作负载的 CPU 和内存指标
|
||||
|
||||
默认情况下,Monitoring 应用会抓取 CPU 和内存指标。
|
||||
|
||||
要获取特定工作负载的细粒度信息,你可以自定义 Grafana 仪表板来显示该工作负载的指标。
|
||||
|
||||
### 设置 CPU 和内存之外的指标
|
||||
|
||||
对于自定义指标,你需要使用 Prometheus 支持的格式来公开应用上的指标。
|
||||
|
||||
我们建议你创建一个新的 ServiceMonitor 自定义资源。创建此资源时,Prometheus 自定义资源将自动更新,以便将新的自定义指标端点包含在抓取配置中。然后 Prometheus 会开始从端点抓取指标。
|
||||
|
||||
你还可以创建 PodMonitor 来公开自定义指标端点,但 ServiceMonitor 更适合大多数用例。
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: 卸载 Monitoring
|
||||
---
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群,并点击 **Explore**。
|
||||
1. 在左侧导航栏中,点击 **Apps**。
|
||||
1. 点击**已安装的应用**。
|
||||
1. 转到 `cattle-monitoring-system` 命名空间并选中 `rancher-monitoring-crd` 和 `rancher-monitoring`。
|
||||
1. 单击**删除**。
|
||||
1. 确认**删除**。
|
||||
|
||||
**结果**:已卸载 `rancher-monitoring`。
|
||||
|
||||
:::note 持久化 Grafana 仪表板:
|
||||
|
||||
如果你的 Monitoring V2 版本是 v9.4.203 或更低版本,卸载 Monitoring chart 将同时删除 cattle-dashboards 命名空间,所有持久化的仪表板将被删除(除非命名空间带有注释 `helm.sh/resource-policy: "keep"`)。Monitoring V2 v14.5.100+ 会默认添加此注释。但如果你的集群上安装了旧版本的 Monitoring Chart,你可以在卸载它之前手动将注释应用到 cattle-dashboards 命名空间。
|
||||
|
||||
:::
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user