RKE安装k8s及部署高可用rancher
此博客，是根据 Rancher 官网文档，使用 RKE 测试部署最新发布版 Rancher v2.5.9 高可用集群的总结文档。
一 了解 Rancher
Rancher 是为使用容器的公司打造的容器管理平台。Ranhcer 简化了使用 Kubernetes 的流程，开发者可以随处运行 Kubernetes（Run Kubernetes Everywhere），满足 IT 需求规范，赋能 DevOps 团队。
Rancher 可以创建来自 Kubernetes 托管服务提供商的集群，自动创建节点并安装 Kubernetes 集群，或者导入任何已经存在的 Kubernetes 集群。
Rancher 支持集中化认证、权限控制、监控和管理所有 Kubernetes 集群。
- 使用活动目录（Active Directory）的认证信息访问云端 Kubernetes 集群，如 GKE、AKS、EKS 等；
- 设置用户、用户组、项目组、集群、云服务的权限控制策略和安全策略；
- 一站式监控您名下所有集群的健康状态。
1 关于 Helm
Helm 是安装 Rancher 高可用集群时会用到的工具。
Helm 是 Kubernetes 的软件包管理工具。Helm chart 为 Kubernetes YAML manifest 文件提供了模板语法。通过 Helm，可以创建可配置的 Deployment YAML，而不是只能用静态的 YAML。如果您想了解更多关于如何创建自己的应用商店应用（catalog），请查阅 Helm 官方网站 。
2 关于 RKE
RKE 全称是 Rancher Kubernetes Engine。可以通过 CLI 的方式独立于 Rancher 2.x 使用。可以在安装好 docker 的 linux 主机上，快速方便的搭建 Kubernetes 集群。
关于 RKE 和 Rancher 的关系，RKE 是 Rancher 2.x 中的一个重要组成部分，在 UI 上通过 “自定义主机” 创建的集群和通过 “主机驱动” 创建的集群，都是 Rancher Server 调用 RKE 模块来实现的。
3 关于 K3S
K3s 是经过精简和用户体验优化的 k8s。K3s 减少了运维负担。一条命令就可以启动 K3s。加入一个新节点，使用 4 层 LB 等也都非常简单。同时也可以使用 MySQL/SQLite 等关系型数据库作为数据库。
4 Rancher 名词解释
4.1 仪表盘
仪表盘会显示 Prometheus 收集到的监控数据。单击右边的 Grafana 图标，浏览器会打开一个新的标签，在 Grafana 里呈现这些监控数据。
①. CPU
- 已预留 6 中的 2.4：6 为集群节点的 CPU 总和，2.4 为集群中所有工作负载 spec.containers.resources.requests.cpu 的总和。
- 已使用 6 中的 0.2：6 为集群节点的 CPU 总和，0.2 为集群中所有节点已使用 CPU 的总和。
②. Memory
- 已预留 11.1GiB 中的 1.5：11.1GiB 为集群节点的 memory 总和，1.5 为集群中所有工作负载 spec.containers.resources.requests.memory 的总和。
- 已使用 11.1GiB 中的 2.3：11.1GiB 为集群节点的 memory 总和，2.3 为集群中所有节点已使用 memory 的总和。
③. Pods
集群可以创建的最大 Pod 数量，单节点默认 110 个 pod，可以通过设置 kubelet 的 max-pods 来修改默认最大 Pod 数量。
4.2 项目
项目是 Rancher 中的一个概念，能够帮助您管理 kubernetes 集群中的命名空间，您可使用项目创建多租户集群，这种集群允许多个用户使用相同的底层资源创建应用，而应用之间不会相互影响。
更多详情，请参阅 项目管理 文档。
4.3 多集群应用
通常，大多数应用都部署在单个 kubernetes 集群上，但是有时候您可能希望跨不同的集群或项目部署同一个应用的多个副本。在 Rancher 中多集群应用使用 Helm Chart，并可以跨多个集群部署应用。因为能够跨多个集群部署相同的应用，因此可以避免在对每个集群上重复执行相同的操作期间引入的人为错误。使用多集群应用，您可以确保应用在所有项目 / 集群中具有相同的配置，并能够根据目标项目来覆盖不同的参数。由于多集群应用被视为单个应用，因此易于管理和维护。
更多详情，请参阅 多集群应用 文档。
4.4 应用商店
Rancher 提供了基于 Helm 的应用商店的功能，该功能使部署和管理相同的应用变得更加容易。
- 应用商店可以是 GitHub 代码库或 Helm Chart 库，其中包含了可部署的应用。应用打包在称为 Helm Chart 的对象中。
- Helm Charts 是描述一组相关 Kubernetes 资源的文件的集合。单个 Chart 可能用于部署简单的内容（例如 Mencached Pod）或复杂的内容（例如带有 HTTP 服务，数据库，缓存等的完整的 Web 应用）。
Rancher 改进了 Helm 应用商店和 Chart。所有原生 Helm Chart 都可以在 Rancher 中使用，但是 Rancher 添加了一些增强功能以改善用户体验。
更多详情，请参阅 应用商店 文档。
4.5 Rancher Server URL
第一次登录 Rancher 后，Rancher 将提示您输入一个 Rancher Server URL。您应该将 URL 设置为 Rancher Server 的主入口点。当负载均衡器位于 Rancher Server 集群前面时，URL 应该设置为负载均衡地址。系统会自动尝试从运行 Rancher Server 的主机的 IP 地址或主机名推断 Rancher Server 的 URL，但只有在运行单节点的 Rancher Server 时，上述推断才会正确。因此，在大多数情况下，您需要自己将 Rancher Server URL 设置为正确的值。
更多详情，请参阅 配置 Rancher Server URL 文档。
4.6 RKE 模板
RKE 的全称是 Rancher Kubernetes Engine，它是 Rancher 用来创建 Kubernetes 集群的工具。RKE 集群模板制定了 DevOps 和安全团队的标准，简化了 Kubernetes 集群的创建过程。
多集群管理面临着如何强制实施安全策略和附加配置的挑战，在将集群移交给最终用户之前，管理员需要标准化这些配置。RKE 集群模板提供了标准化集群配置的方式。无论是使用 Rancher UI、Rancher API 还是自动化流程创建的集群，Rancher 都将保证从 RKE 集群模板创建的每个集群在生成方式上是一致的。
更多详情，请参阅 RKE 模板 文档。
4.7 GIS 扫描
Rancher 充分利用了 kube-bench 来对 Kubernetes 集群进行安全扫描。Rancher 会检查 Kubernetes 集群是否遵循了 CIS (Center for Internet Security，互联网安全中心) Kubernetes Benchmark 中定义的最佳实践。
CIS Kubernetes Benchmark 是一个可以用来给 Kubernetes 创建安全基准的参考文档。
互联网安全中心（CIS）是一个 501©(3) 非营利组织，成立于 2000 年 10 月，其使命是 “通过识别，开发，验证，推广和维护最佳实践解决方案来防御网络攻击，并建立和引导社区打造安全可信的网络环境”。
CIS 基准测试是安全配置目标系统的最佳实践。CIS 基准是通过领域专家，技术供应商，公共和私人社区成员以及 CIS 基准开发团队的不懈努力而制定的。
基准提供两种类型的建议：计分和不记分。我们仅运行与 “计分建议” 相关的测试。
当 Rancher 对一个集群进行 CIS 安全扫描时，它会生成一个展示每个测试结果的报告。报告中包括通过，跳过和失败的测试数量的汇总。报告中同时也给失败的测试提供了补救办法。
更多详情，请参阅 安全扫描 文档。
5 推荐架构
安装 Rancher 的方式有两种：单节点安装和高可用集群安装。因为单节点安装只适用于测试和 demo 环境，而且单节点安装和高可用集群安装之间不能进行数据迁移，所以推荐从一开始就使用高可用集群安装的方式安装 Rancher。
建议将 Rancher Server 安装在高可用的 Kubernetes 集群上，主要是因为它可以保护 Rancher Server 的数据。在高可用安装中，负载均衡器充当客户端的单点入口，并在集群中的多台服务器之间分配网络流量，这有助于防止任何一台服务器成为单点故障。
不建议在单个 Docker 容器中安装 Rancher，因为如果该节点发生故障，则其他节点上将没有可用的集群数据副本，并且可能会丢失 Rancher Server 上的数据。
Rancher 需要安装在高可用的 RKE（Rancher Kubernetes Engine）Kubernetes 集群上，或高可用的 K3s (轻量级 Kubernetes) Kubernetes 集群。 RKE 和 K3s 都是经过完全认证的 Kubernetes 发行版。
5.1 K3S Kubernetes 集群安装
如果您是首次安装 Rancher v2.4，建议将其安装在 K3s Kubernetes 集群上。这种 K3s 架构的一个主要优点是，它允许使用外部数据库保存集群数据，从而可以将 K3s 服务器节点视为无状态的。
在 K3s 集群上安装 Rancher 的功能是在 Rancher v2.4 中引入的。K3s 易于安装，仅需要 Kubernetes 一半的内存，而且所有组件都在一个不超过 100 MB 的二进制文件中。
使用 K3s Kubernetes 集群运行 Rancher Management Server 的架构：
5.2 RKE Kubernetes 集群安装
如果要安装 Rancher v2.4 之前的版本，您需要在 RKE 集群上安装 Rancher，该集群中的数据存储在每个有 etcd 角色的节点上。在 Rancher v2.4 中，没有将 Rancher Server 从 RKE 集群迁移到 K3s 集群的方法。所有版本的 Rancher Server（包括 v2.4+）仍然可以安装在 RKE 集群上。
在 RKE 安装中，集群数据将在集群中的三个 etcd 节点上进行复制，这是为了保障在一个 etcd 节点发生故障时，可以提供冗余和数据复制。
使用 RKE Kubernetes 集群运行 Rancher Management Server 的架构：
6 负载均衡配置的推荐配置参数
我们建议您使用以下方案，配置您的负载均衡和 Ingress Controller：
- Rancher 的 DNS 应该被解析到四层负载均衡器上；
- 负载均衡器应该把 TCP/80 端口和 TCP/443 端口的流量转发到集群中全部的 3 个节点上；
- Ingress Controller 将把 HTTP 重定向到 HTTPS，在 TCP/443 端口使用 SSL/TLS；
- Ingress Controller 把流量转发到 Rancher Server 的 pod 的 80 端口。
在 kubernetes 集群中安装 Ranhcer，并使用四层负载均衡，SSL 终止在 Ingress Controller 中。
为了达到最好的性能和安全条件，我们建议您为 Rancher 创建一个专用的 Kubernetes 集群，只在这个机器中部署 Rancher Server，不在这个集群中运行应用或程序。部署 Rancher 后，您可以 创建新集群或导入已有集群 ，然后用这些集群启动您自己的应用或程序。
我们不建议在托管的 Kubernetes 集群上，如 EKS 和 GKE，安装 Rancher。 这些托管的 Kubernetes 集群不会将 etcd 暴露给 Rancher ，达到 Rancher 可以管理的程度，而且它们的特殊改动可能与 Rancher 的操作冲突。
7 节点角色分配建议
根据 Rancher 是安装在 K3S Kubernetes 集群上还是 RKE Kubernetes 集群上，我们对每个节点的角色的建议有所不同。
7.1 K3S 集群角色
在 K3s 集群中，有两种类型的节点：Server 节点和 Agent 节点。Server 节点和 Agent 节点 都可以运行工作负载。Server 节点运行 Kubernetes Master。
对于运行 Rancher Server 的集群，建议使用两个 Server 节点。不需要 Agent 节点。
7.2 RKE 集群角色
如果将 Rancher 安装在 RKE Kubernetes 集群上，则该集群应具有三个节点，并且每个节点都应具有所有三个 Kubernetes 角色：etcd，controlplane 和 worker。
Rancher Server RKE 集群和下游 Kubernetes RKE 集群的架构对比：
我们对 Rancher Server 集群上的 RKE 节点角色的建议与对运行您的业务应用的下游集群的建议相反。
在配置下游 Kubernetes 集群时，Rancher 使用 RKE 作为创建下游 Kubernetes 集群的工具。注意：在将来的 Rancher 版本中将添加创建下游 K3s 集群的功能。
对于下游 Kubernetes 集群，考虑到稳定性和可扩展性，我们建议下游集群中的每个节点都应只扮演一个角色。
RKE 每个节点至少需要一个角色，但并不强制每个节点只能有一个角色。但是，对于运行您的业务应用的集群，我们建议为每个节点使用单独的角色，这可以保证工作节点上的工作负载不会干扰 Kubernetes Master 或集群数据。
以下是我们对于下游集群的最低配置建议：
- 三个只有 etcd 角色的节点 保障高可用性，如果这三个节点中的任意一个出现故障，还可以继续使用。
- 两个只有 controlplane 角色的节点 这样可以保证 master 组件的高可用性。
一个或多个只有 worker 角色的节点 用于运行 Kubernetes 节点组件和您部署的服务或应用。
在安装 Rancher Server 时三个节点，每个节点都有三个角色是安全的，因为：
- 可以允许一个 etcd 节点失败
- 多个 controlplane 节点使 master 组件保持多实例的状态。
- 该集群有且只有 Rancher 在运行。
因为这个集群中只部署了 Rancher server，没有其他程序或应用，这个集群已经足以应对大多数情况。所以这个集群并不需要像我们建议的下游集群那样的可扩展性和可靠性。
8 扩展 - Ingress
Rancher 安装的 Kubernetes 集群中的每个节点都应该运行一个 Ingress。
Ingress 应被部署为 DaemonSet，以确保你的负载平衡器能够成功地将流量路由到所有节点。
对于 RKE、K3s 和 RancherD 的安装，你不需要手动安装 Ingress，因为它是默认安装的。
对于托管的 Kubernetes 集群（EKS、GKE、AKS）和 RKE2 Kubernetes 安装，你将需要设置 Ingress。
二 软件要求
下面的版本为当前的最新版和稳定版：
| 类型 | Rancher 版本 | Docker 标签 | Helm 仓库 | Helm Chart 版本 |
|---|---|---|---|---|
| 最新版 | v2.5.8 | rancher/rancher:latest | server-charts/latest | v2.5.8 |
| 稳定版 | v2.5.8 | rancher/rancher:stable | server-charts/stable | v2.5.8 |
1 Rancher 支持的 kubernetes 版本
更多信息可以转到官方链接查看。此处我仅列举了本人文档里试验总结的官方最新稳定版的相关信息：https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.5.8/
1.1 在 RKE 上安装 Ranhcer v2.5.8
适用于本地集群的 RKE CLI 和 K8S：
| Rancher 版本 | 推荐的 CLI 版本 | KUBERNETES 版本 |
|---|---|---|
| v2.5.8 | v1.2.8 | v1.20.4（默认） v1.19.8 v1.18.16 v1.17.17 |
操作系统和 Docker：
| 类型 | 版本 | 已于 1 验证 / 认证 |
|---|---|---|
| CentOS | 7.7、7.8、7.9 | Docker 18.06.3、18.09.x，19.03.x，20.10.x |
1.2 Rancher v2.5.8 中的下游集群
Rancher RKE 下游集群 - Linux Work 节点
注意：Rancher RKE 下游群集可以由节点驱动程序或自定义 / 现有节点配置，也可以注册到 Rancher 中。
操作系统和 Docker：
| 类型 | 版本 | 已于 1 验证 / 认证 |
|---|---|---|
| CentOS | 7.7、7.8、7.9 | Docker 18.06.3、18.09.x，19.03.x，20.10.x |
支持的 K8S 版本：
| 上游 K8S 版本 | 在 2,3,4,5 上验证 / 认证 |
|---|---|
| v1.20.6 | etcd：v3.4.15 flannel：v0.13.0 canal：v3.17.2 nginx-ingress-controller：0.43.0-rancher3 |
1.3 在 K3S 上安装 Rancher v2.5.8
本地集群：
| K3S 版本 | 在 2,3,4,5 上验证 / 认证 |
|---|---|
| v1.20.6 + k3s1 | Aurora（MySQL 5.7）2.09.0 MySQL 5.7 PostgreSQL 11.5、12.5、13.1 MariaDB 10.4.8 External Etcd 3.4.15 Embedded Etcd CRI：embedded Containered v1.4.4-k3s1 CNI：embedded Flannel v0.12.0-k3s.1 |
操作系统：
| 类型 | 版本 | 已于 1 验证 / 认证 |
|---|---|---|
| CentOS | 7.8、7.9、8.2、8.3 | x86_64 架构 |
1.4 Rancher K3S 下游集群
注意：Rancher K3S 群集只能在 Rancher 中注册。
操作系统：
| 类型 | 版本 | 已于 1 验证 / 认证 |
|---|---|---|
| CentOS | 7.8、7.9、8.2、8.3 | x86_64 架构 |
支持的 K3S 版本：
| K3S 版本 | 在 2,3,4,5 上验证 / 认证 |
|---|---|
| v1.20.6 + k3s1 | Aurora（MySQL 5.7）2.09.0 MySQL 5.7 PostgreSQL 11.5、12.5、13.1 MariaDB 10.4.8 External Etcd 3.4.15 Embedded Etcd CRI：embedded Containered v1.4.4-k3s1 CNI：embedded Flannel v0.12.0-k3s.1 |
2 RKE-1.2.8
RKE 可以兼容当前的所有 Docker 版本。
每个 RKE 版本都有受支持的 Kubernetes 版本的特定列表。如果您要使用的版本与下面列出的版本不同，则需要使用中的系统映像选项来更新 Kubernetes cluster.yml。
列举支持的 Kubernetes 版本：
- 请参考 RKE 版本说明 ，获取您当前使用的 RKE 支持的 Kubernetes 版本号。
| Kubernetes 版本 |
|---|
| v1.20.6-rancher1-1 |
| v1.19.10-rancher1-1 |
| v1.18.18-rancher1-2 |
| v1.17.17-rancher2-3 |
- 也可以输入以下命令，快速获取支持的版本号：
./rke config --list-version --all
v1.20.6-rancher1-1
v1.17.17-rancher2-3
v1.18.18-rancher1-2
v1.19.10-rancher1-1
3 Kubectl
kubectl 可以比 kube-apiserver 高一个小版本，也可以低一个小版本。
例如：
- 如果 kube-apiserver 当前是 1.21 版本
- kubectl 则支持 1.22、1.21 和 1.20
4 Helm-3.5.x
- 请使用 Helm v3.2.x 或更高版本安装或升级 Rancher v2.5.x。
- Helm v2.16.0 或更高版本需要 Kubernetes v1.16 版本。对于默认的 Kubernetes 版本，请参考发布说明以获取所使用的 RKE 的版本。
- 不能使用 Helm v2.15.0，因为这个版本中有一些关于转换 / 比较数字的问题。
- 不能使用 Helm v2.12.0，因为这个版本和 cert-manager 一起使用时会有问题。
| Helm 版本 支持的 Kubernetes 版本 |
|---|
| 3.5.x 1.20.x - 1.17.x |
| 3.4.x 1.19.x - 1.16.x |
| 3.3.x 1.18.x - 1.15.x |
| 3.2.x 1.18.x - 1.15.x |
| 3.1.x 1.17.x - 1.14.x |
| 3.0.x 1.16.x - 1.13.x |
| 2.16.x 1.16.x - 1.15.x |
| 2.15.x 1.15.x - 1.14.x |
| 2.14.x 1.14.x - 1.13.x |
| 2.13.x 1.13.x - 1.12.x |
| 2.12.x 1.12.x - 1.11.x |
| 2.11.x 1.11.x - 1.10.x |
| 2.10.x 1.10.x - 1.9.x |
| 2.9.x 1.10.x - 1.9.x |
| 2.8.x 1.9.x - 1.8.x |
| 2.7.x 1.8.x - 1.7.x |
| 2.6.x 1.7.x - 1.6.x |
| 2.5.x 1.6.x - 1.5.x |
| 2.4.x 1.6.x - 1.5.x |
| 2.3.x 1.5.x - 1.4.x |
| 2.2.x 1.5.x - 1.4.x |
| 2.1.x 1.5.x - 1.4.x |
| 2.0.x 1.4.x - 1.3.x |
5 Docker-20.10.x
将最新的经过验证的 Docker 版本更新为 20.10。
每一个 Kubernetes 版本支持的 Docker 版本都不同。
6 nginx-1.14
官方已在 NGINX 1.14 上进行了测试 NGINX 配置。
7 OpenSSH-7.0+
为了可以通过 SSH 访问每一个节点，RKE 要求每个节点上安装的是 OpenSSH 的版本是 OpenSSH 7.0+。
三 主机配置
先配置 4 台最小化安装的主机，其中 3 台使用 RKE 配置 k8s 集群，然后在这个集群上配置高可用 Rancher。
要在高可用性 RKE 集群上安装 Rancher 管理服务器，我们建议设置以下基础设施：
- 三个 Linux 节点，通常是虚拟机。
- 一个负载均衡器，将前端流量引导到三个节点。
- 一个 DNS 记录，将一个 URL 映射到负载均衡器。这将成为 Rancher 服务器的 URL，下游的 Kubernetes 集群需要到达它。
注意：Rancher 对于配置 k8s 集群的主机性能要求较高，如果配置较低，会有 k8s 集群被迫中断的风险。nginx 主机性能满足基本要求就可以了，配置要求不大。经试验几次后，我给予的虚拟机 Rancher 集群 k8s 主机配置的是：2U，运行内存 4G 和存储内存 50G。
1 主机基本信息
国内用户可根据此链接可以下载所有资源：http://mirror.cnrancher.com
| 主机 IP | 主机名 | 配置 | 角色 |
|---|---|---|---|
| 192.168.0.201 | k8s-node01 | 2 线程 4G | controlplane，etcd，worker |
| 192.168.0.202 | k8s-node02 | 2 线程 4G | controlplane，etcd，worker |
| 192.168.0.203 | k8s-node03 | 2 线程 4G | controlplane，etcd，worker |
| 192.168.0.204 | nginx | 2 线程 2G | nginx 负载均衡 |
2 主机初始化配置
注意：以下步骤，四台主机均要操作。
2.1 查看系统版本是否满足要求
cat /etc/centos-release
CentOS Linux release 7.9.2009 (Core) #若系统版本为7.7 7.8 7.9 均符合
2.2 修改yum源为阿里镜像源，安装工具包
yum -y install wget
cd /etc/yum.repos.d/
mv CentOS-Base.repo CentOS-Base.repo_back
wget -O CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
yum clean all
yum makecache
yum -y update
yum -y install epel-release
yum -y install lrzsz vim gcc glibc openssl openssl-devel net-tools curl
2.3 关闭防火墙和 selinux
测试环境中，为了方便将防火墙和 selinux 关闭；生产环境中，建议关闭 selinux，防火墙规则根据环境需要自定义即可。
#关闭selinux
setenforce 0
sed -i 's/enforcing/disabled/' /etc/selinux/config
#关闭防火墙
systemctl stop firewalld
systemctl disable firewalld
2.4 时钟同步
为了防止后续集群在客户端和服务器之间因为时钟不同步而发生验证错误。
- 第一种方法：
yum install -y ntp #每台主机安装ntp服务
systemctl start ntpd #启动时钟同步服务
systemctl enable ntpd #设置开机启动
ntpq -p #查看时钟同步状态
- 第二种方法：
yum install ntp ntpdate -y
之后，选择一台主机（192.168.0.201）作为 ntp 时间服务器，修改/etc/ntp.conf文件，删除：
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst
改为：
server ntp3.aliyun.com iburst
另外，原始文件中有一行为如下内容：
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
去掉 #，打开注释，并将其 ip 修改为服务器所在网段：
restrict 192.168.0.201 mask 255.255.240.0 nomodify notrap
在集群中的其他服务器上，也要修改此文件，删除掉：
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst
加入：
server 192.168.0.201 prefer
保存后退出，在集群中的所有服务器上执行如下命令：
systemctl stop chronyd.service
systemctl disable chronyd.service
systemctl restart ntpd
systemctl enable ntpd
之后，在集群中 192.168.0.201 以外的服务器上执行：
ntpq -p
出现以下结果：
remote refid st t when poll reach delay offset jitter
==============================================================================
*sv1.ggsrv.de 192.53.103.103 2 u 28 64 1 210.439 -0.300 0.305
192.168.0.201 .INIT. 16 u - 64 0 0.000 0.000 0.000
说明时间已经同步。
2.5 内核参数调优
cat >> /etc/sysctl.conf << eof
vm.swappiness=0
net.ipv4.ip_forward=1
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.neigh.default.gc_thresh1=4096
net.ipv4.neigh.default.gc_thresh2=6144
net.ipv4.neigh.default.gc_thresh3=8192
eof
使内核参数生效：
modprobe br_netfilter #首先执行这个命令后才不会报错
sysctl -p
2.6 SSH Server 配置
SSH server 全系统配置文件，位于/etc/ssh/sshd_config，该文件必须包含以下代码，允许 TCP 转发。
AllowTcpForwarding yes
#重启sshd服务
systemctl restart sshd
2.7 修改主机名
#分别修改每条主机的hostname
hostnamectl set-hostname k8s-node01
hostnamectl set-hostname k8s-node02
hostnamectl set-hostname k8s-node03
hostnamectl set-hostname nginx
#修改完后可直接断开Xshell的连接，再重新连接Xshell就可以看到主机名已修改了
在 /etc/hosts 文件中添加主机名配置：
cat >> /etc/hosts << eof
192.168.0.201 k8s-node01
192.168.0.202 k8s-node02
192.168.0.203 k8s-node03
192.168.0.204 nginx
eof
注 意 ： 下 面 的 步 骤 仅 在 k 8 s 的 3 台 主 机 上 操 作 ， n g i n x 上 不 可 以 操 作 。
2.8 关闭 swap 分区
#临时关闭
swapoff -a
#永久关闭
进入/etc/fstab文件，注释掉swap分区的相关配置内容
2.9 加载 ipvs 相关模块
由于 ipvs 已经加入到了内核的主干，所以为 kube-proxy 开启 ipvs 的前提需要加载以下的内核模块。
cat > /etc/sysconfig/modules/ipvs.modules << eof
#!/bin/bash
modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack_ipv4
eof
chmod 755 /etc/sysconfig/modules/ipvs.modules
bash /etc/sysconfig/modules/ipvs.modules
lsmod | grep -e ip_vs -e nf_conntrack_ipv4 #查看是否已经正确安装lipset软件包
前面脚本创建了/etc/sysconfig/modules/ipvs.modules文件，保证在节点重启后能自动加载所需模块。
cat >> /etc/rc.d/rc.local << eof
bash /etc/sysconfig/modules/ipvs.modules
eof
chmod +x /etc/rc.d/rc.local
四 安装 docker-20.10.6
注 意 ： 仅在 k8s 节点安装 docker
- 若是节点主机上已安装有 docker，则先卸载及其依赖包
yum remove docker \
docker-client \
docker-client-latest \
docker-common \
docker-latest \
docker-latest-logrotate \
docker-logrotate \
docker-engine
- 安装 epel 更新源
yum install epel-release -y
- 安装 docker 仓库
在新主机上首次安装 docker 之前，需要设置 Docker 仓库；之后，可以从仓库安装和更新 docker。
安装所需的软件包。yum-utils 提供了 yum-config-manager，并且 device mapper 存储驱动程序需要 device-mapper-persistent-data 和 lvm2。
yum install -y yum-utils device-mapper-persistent-data lvm2
设置docker阿里仓库。
yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
- 安装 docker
按版本号排序列出存储库中可用的版本号
yum list docker-ce --showduplicates | sort -r
docker-ce.x86_64 3:20.10.6-3.el7 docker-ce-stable
docker-ce.x86_64 3:20.10.5-3.el7 docker-ce-stable
docker-ce.x86_64 3:20.10.4-3.el7 docker-ce-stable
docker-ce.x86_64 3:20.10.3-3.el7 docker-ce-stable
docker-ce.x86_64 3:20.10.2-3.el7 docker-ce-stable
docker-ce.x86_64 3:20.10.1-3.el7 docker-ce-stable
docker-ce.x86_64 3:20.10.0-3.el7 docker-ce-stable
docker-ce.x86_64 3:19.03.9-3.el7 docker-ce-stable
docker-ce.x86_64 3:19.03.8-3.el7 docker-ce-stable
docker-ce.x86_64 3:19.03.7-3.el7 docker-ce-stable
docker-ce.x86_64 3:19.03.6-3.el7 docker-ce-stable
……
根据前面软件要求的内容，可以直接安装最新版 docker-20.10.x：
yum install -y docker-ce docker-ce-cli containerd.io #默认安装最新版本的docker
若是安装指定版本，例如：
yum install -y docker-ce-19.03.9-3.el7 docker-ce-cli-19.03.9-3.el7 containerd.io
安装 docker 命令补全工具：
yum install -y bash-completion
启动 docker：
systemctl start docker
- 配置 docker 镜像下载加速器
tee /etc/docker/daemon.json << eof
{
"registry-mirrors": [
"https://1nj0zren.mirror.aliyuncs.com",
"https://docker.mirrors.ustc.edu.cn",
"http://hub-mirror.c.163.com"
],
"log-driver": "json-file",
"log-opts": {
"max-size": "50m",
"max-file": "3"
}
}
eof
- 启动 docker
systemctl daemon-reload
systemctl restart docker
systemctl enable docker
五 使用 RKE 安装 kubernetes
1 主机互信
目前有 4 台服务器，确保可以通过 ssh 互相访问。
# 每台主机执行
ssh-keygen
ssh-copy-id -i 192.168.0.201
ssh-copy-id -i 192.168.0.202
ssh-copy-id -i 192.168.0.203
ssh-copy-id -i 192.168.0.204
2 创建普通用户并加入 docker 组
注意：使用 rke 安装 kubernetes 时，不能以 root 用户执行，必须是一个普通用户才可以。
在每个节点上创建 kuser 普通用户，并将其加入 docker 用户组中；把 nginx 主机当做主控机，其他主机的 kuser 用户互信它的 kuser 用户。
//nginx节点
[root@nginx ~]# useradd kuser
[root@nginx ~]# echo 123456 | passwd --stdin kuser //给kuser用户设置密码
[root@nginx ~]# usermod -G docker kuser
//更新用户组
[root@nginx ~]# newgrp docker
[root@nginx ~]# id kuser
uid=1000(kuser) gid=1000(kuser) 组=1000(kuser),1001(docker)
//3个k8s节点均按照k8s-node01步骤操作
[root@k8s-node01 ~]# useradd kuser
[root@k8s-node01 ~]# echo 123 | passwd --stdin kuser
[root@k8s-node01 ~]# usermod -G docker kuser
//更新用户组
[root@k8s-node01 ~]# newgrp docker
[root@k8s-node01 ~]# id kuser
uid=1000(kuser) gid=1000(kuser) 组=1000(kuser),994(docker)
//切换到kuser用户，测试kuser用户是否能运行docker命令
[root@k8s-node01 ~]# su - kuser
[ops@k8s-node01 ~]$ docker ps
//每台主机切换到kuser用户，让每个节点主机的ops用户互相信任
# su - kuser
$ ssh-keygen
$ ssh-copy-id -i [email protected]
$ ssh-copy-id -i [email protected]
$ ssh-copy-id -i [email protected]
$ ssh-copy-id -i [email protected]
最后在 nginx 主机上测试：通过 kuser 用户可以直接连接到每个 k8s 节点，并能运行 docker 相关命令。
注意：完成以上配置后，需重启主机，某些配置参数才会生效。
3 在 nginx 节点下载安装 RKE-1.2.8
3.1 下载 RKE
登录主机，打开浏览器，访问 RKE 版本发布页面，下载最新的 RKE v1.2.12。 https://download.fastgit.org/rancher/rke/releases/download/v1.2.12/rke_linux-amd64
每个 RKE 版本都有受支持的 Kubernetes 版本的特定列表。如果您要使用的版本与下面列出的版本不同，则需要使用中的 系统映像 选项来更新 Kubernetes cluster.yml。
3.2 安装 rke 命令
运行以下命令，将下载的 RKE 二进制安装包复制到您想要保存的路径下，然后将这个安装包重命名为 rke。
//保存至kuser用户的家目录
$ mv rke_linux-amd64 rke
运行以下命令，将 rke 安装包转为可执行文件。
$ chmod +x rke
运行以下命令，检查 rke 安装包是否已经转换为可执行文件。
$ ./rke --version
rke version v1.2.10
3.3 为 kubernetes 集群准备节点
注 意 ： 以 下 1 和 2 已 在 初 始 化 环 境 完 成 ， 3 需 要 在 每 个 节 点 执 行
kubernetes 集群组件需要在 Linux 发行版上的 Docker 中运行，只要是能安装和运行 docker 是 linux 发行版，都可以使用。
- SSH 用户 - 使用 SSH 访问节点的用户必须是节点上 docker 用户组的成员。
- 添加到 docker 用户组的用户会自动获得主机的 root 权限，运行上述命令前，请确认您是否想让该用户获得 root 权限。运行命令后，请妥善保存该用户的认证凭据。
- 如果您无法切换到 root 用户，不能运行上述命令将用户添加到 docker 用户组，请参考 Docker 官方文档，该文档提供了以非 root 用户的身份管理 Docker 的操作步骤。
- 禁用所有的 work 节点上的交换功能（swap）。
- 在命令行工具中输入以下命令和脚本，检查下列模组是否存在。
// 配置以下脚本
# vim module.sh
for module in br_netfilter ip6_udp_tunnel ip_set ip_set_hash_ip ip_set_hash_net iptable_filter iptable_nat iptable_mangle iptable_raw nf_conntrack_netlink nf_conntrack nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat nf_nat_ipv4 nf_nat_masquerade_ipv4 nfnetlink udp_tunnel veth vxlan x_tables xt_addrtype xt_conntrack xt_comment xt_mark xt_multiport xt_nat xt_recent xt_set xt_statistic xt_tcpudp;
do
if ! lsmod | grep -q $module; then
echo "module $module is not present";
fi;
done
# chmod +x module.sh
# sh module.sh
报错：所有模块不存在
// 执行此命令加载内核模块,用root用户执行
# modprobe -a br_netfilter ip6_udp_tunnel ip_set ip_set_hash_ip ip_set_hash_net iptable_filter iptable_nat iptable_mangle iptable_raw nf_conntrack_netlink nf_conntrack nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat nf_nat_ipv4 nf_nat_masquerade_ipv4 nfnetlink udp_tunnel veth vxlan x_tables xt_addrtype xt_conntrack xt_comment xt_mark xt_multiport xt_nat xt_recent xt_set xt_statistic xt_tcpudp
//然后再次执行module.sh脚本
# sh module.sh
会有 3 个模块没有找到，不影响：
返回的模组应该包括下列的所有模组：
| 模组名称 |
|---|
| br_netfilter |
| ip6_udp_tunnel |
| ip_set |
| ip_set_hash_ip |
| ip_set_hash_net |
| iptable_filter |
| iptable_nat |
| iptable_mangle |
| iptable_raw |
| nf_conntrack_netlink |
| nf_conntrack |
| nf_conntrack_ipv4 |
| nf_defrag_ipv4 |
| nf_nat |
| nf_nat_ipv4 |
| nf_nat_masquerade_ipv4 |
| nfnetlink |
| udp_tunnel |
| veth |
| vxlan |
| x_tables |
| xt_addrtype |
| xt_conntrack |
| xt_comment |
| xt_mark |
| xt_multiport |
| xt_nat |
| xt_recent |
| xt_set |
| xt_statistic |
| xt_tcpudp |
3.4 创建集群配置文件 - cluster.yml
创建一个名为 cluster.yml 的 Kubernetes 集群配置文件。在后续步骤中，当使用 RKE 命令设置集群时，它将使用此文件在节点上安装 Kubernetes。
RKE 适配了高可用集群，您可以在 cluster.yml 文件中配置多个 controlplane 节点。RKE 会把 master 节点的组件部署在所有被列为 controlplane 的节点上，同时把 kubelets 的默认连接地址配置为 127.0.0.1:6443 。这个地址是 nginx-proxy 请求所有 master 节点的地址。
创建高可用集群需要指定两个或更多的节点作为 controlplane 。
RKE 使用集群配置文件 cluster.yml 规划集群中的节点，例如集群中应该包含哪些节点，如何部署 Kubernetes。您可以通过该文件修改很多集群配置选项。
如果您的节点具有公共和内部地址，建议设置 internal_address: 这样 Kubernetes 会将其用于集群内通信。
RKE 需要通过 SSH 连接到每个节点，并且它将在默认位置 ~/.ssh/id_rsa 中寻找私钥。如果您的默认私钥与节点的私钥不在同一个位置，则还需要为该节点配置 ssh_key_path 选项。
我这里根据官网列举了几个 RKE 节点选项：
| 选项 | 必填 | 描述 |
|---|---|---|
| address | 是 | 公用 DNS 或 IP 地址 |
| user | 是 | 可以运行 docker 命令的用户 |
| role | 是 | 分配给节点的 Kubernetes 角色列表 |
| internal_address | 是 | 内部集群流量的专用 DNS 或 IP 地址 |
| ssh_key_path | 否 | 用于对节点进行身份验证的 SSH 私钥的路径（默认为~/.ssh/id_rsa） |
| cluster_name | 集群名称 | 默认集群名称：local |
| ignore_docker_version | 检查 docker 版本 | 在运行 RKE 前是否执行 Docker 版本检测，可选值为 true 和 false，默认值为 false |
| kubernetes_version | kubernetes 版本 | 将原有的版本号修改为新的版本号即可，RKE 目前不支持回滚 Kubernetes 版本。 |
| prefix_path | 前缀路径 | 默认下 RKE 存储 ROS、CoreOS 等操作系统的相关资源时，添加一个前缀：/opt/rke |
| ssh_key_path | 集群 ssh 秘钥路径 | RKE 使用 ssh 连接到主机，通常情况下，每个节点都会在 nodes 部分为每个 ssh 密钥设置一个独立的路径。 |
| …… | …… | …… |
- 高级配置： RKE 有许多配置选项可用于在您的特定环境中进行自定义安装。请参阅 RKE 文档 来了解 RKE 的选项和功能的完整列表。
- 要为大规模 Rancher 安装 etcd 集群，请参阅 etcd 设置指南 。
- 创建集群配置文件 cluster.yml 的方式有两种：
- 使用 minimal cluster.yml 创建集群配置文件，然后将您使用的节点的相关信息添加到文件中。
- 使用
rke config 命令创建集群配置文件，然后将集群参数逐个输入到该文件中。
- 使用
rke config
运行 rke config 命令，在当前路径下创建 cluster.yml 文件。这条命令会引导您输入创建集群所需的所有参数，详情请参考集群配置选项。
[kuser@nginx ~]$ ./rke config --name cluster.yml
示例：
中间有一些内容是需要修改的，比如 etcd 的备份周期，备份保留时间，ingress 是否安装等等。
cluster.yml 配置文件内容：参考 官方 kubernetes 配置选项
# If you intened to deploy Kubernetes in an air-gapped environment,
# please consult the documentation on how to configure custom RKE images.
nodes:
- address: 192.168.0.201
port: "22"
internal_address: ""
role:
- controlplane
- worker
- etcd
hostname_override: ""
user: kuser
docker_socket: /var/run/docker.sock
ssh_key: ""
ssh_key_path: ~/.ssh/id_rsa
ssh_cert: ""
ssh_cert_path: ""
labels: {}
taints: []
- address: 192.168.0.202
port: "22"
internal_address: ""
role:
- controlplane
- worker
- etcd
hostname_override: ""
user: kuser
docker_socket: /var/run/docker.sock
ssh_key: ""
ssh_key_path: ~/.ssh/id_rsa
ssh_cert: ""
ssh_cert_path: ""
labels: {}
taints: []
- address: 192.168.0.203
port: "22"
internal_address: ""
role:
- controlplane
- worker
- etcd
hostname_override: ""
user: kuser
docker_socket: /var/run/docker.sock
ssh_key: ""
ssh_key_path: ~/.ssh/id_rsa
ssh_cert: ""
ssh_cert_path: ""
labels: {}
taints: []
services:
etcd:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_binds: []
win_extra_env: []
external_urls: []
ca_cert: ""
cert: ""
key: ""
path: ""
uid: 0
gid: 0
snapshot: null
retention: ""
creation: ""
backup_config: null
kube-api:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_binds: []
win_extra_env: []
service_cluster_ip_range: 10.43.0.0/16
service_node_port_range: ""
pod_security_policy: false
always_pull_images: false
secrets_encryption_config: null
audit_log: null
admission_configuration: null
event_rate_limit: null
kube-controller:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_binds: []
win_extra_env: []
cluster_cidr: 10.42.0.0/16
service_cluster_ip_range: 10.43.0.0/16
scheduler:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_binds: []
win_extra_env: []
kubelet:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_binds: []
win_extra_env: []
cluster_domain: cluster.local
infra_container_image: ""
cluster_dns_server: 10.43.0.10
fail_swap_on: false
generate_serving_certificate: false
kubeproxy:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_binds: []
win_extra_env: []
network:
plugin: canal
options: {}
mtu: 0
node_selector: {}
update_strategy: null
tolerations: []
authentication:
strategy: x509
sans: []
webhook: null
addons: ""
addons_include: []
system_images:
etcd: rancher/mirrored-coreos-etcd:v3.4.15-rancher1
alpine: rancher/rke-tools:v0.1.75
nginx_proxy: rancher/rke-tools:v0.1.75
cert_downloader: rancher/rke-tools:v0.1.75
kubernetes_services_sidecar: rancher/rke-tools:v0.1.75
kubedns: rancher/mirrored-k8s-dns-kube-dns:1.15.10
dnsmasq: rancher/mirrored-k8s-dns-dnsmasq-nanny:1.15.10
kubedns_sidecar: rancher/mirrored-k8s-dns-sidecar:1.15.10
kubedns_autoscaler: rancher/mirrored-cluster-proportional-autoscaler:1.8.1
coredns: rancher/mirrored-coredns-coredns:1.8.0
coredns_autoscaler: rancher/mirrored-cluster-proportional-autoscaler:1.8.1
nodelocal: rancher/mirrored-k8s-dns-node-cache:1.15.13
kubernetes: rancher/hyperkube:v1.20.8-rancher1
flannel: rancher/coreos-flannel:v0.13.0-rancher1
flannel_cni: rancher/flannel-cni:v0.3.0-rancher6
calico_node: rancher/mirrored-calico-node:v3.17.2
calico_cni: rancher/mirrored-calico-cni:v3.17.2
calico_controllers: rancher/mirrored-calico-kube-controllers:v3.17.2
calico_ctl: rancher/mirrored-calico-ctl:v3.17.2
calico_flexvol: rancher/mirrored-calico-pod2daemon-flexvol:v3.17.2
canal_node: rancher/mirrored-calico-node:v3.17.2
canal_cni: rancher/mirrored-calico-cni:v3.17.2
canal_controllers: rancher/mirrored-calico-kube-controllers:v3.17.2
canal_flannel: rancher/coreos-flannel:v0.13.0-rancher1
canal_flexvol: rancher/mirrored-calico-pod2daemon-flexvol:v3.17.2
weave_node: weaveworks/weave-kube:2.8.1
weave_cni: weaveworks/weave-npc:2.8.1
pod_infra_container: rancher/mirrored-pause:3.2
ingress: rancher/nginx-ingress-controller:nginx-0.43.0-rancher3
ingress_backend: rancher/mirrored-nginx-ingress-controller-defaultbackend:1.5-rancher1
metrics_server: rancher/mirrored-metrics-server:v0.4.1
windows_pod_infra_container: rancher/kubelet-pause:v0.1.6
aci_cni_deploy_container: noiro/cnideploy:5.1.1.0.1ae238a
aci_host_container: noiro/aci-containers-host:5.1.1.0.1ae238a
aci_opflex_container: noiro/opflex:5.1.1.0.1ae238a
aci_mcast_container: noiro/opflex:5.1.1.0.1ae238a
aci_ovs_container: noiro/openvswitch:5.1.1.0.1ae238a
aci_controller_container: noiro/aci-containers-controller:5.1.1.0.1ae238a
aci_gbp_server_container: noiro/gbp-server:5.1.1.0.1ae238a
aci_opflex_server_container: noiro/opflex-server:5.1.1.0.1ae238a
ssh_key_path: ~/.ssh/id_rsa
ssh_cert_path: ""
ssh_agent_auth: false
authorization:
mode: rbac
options: {}
ignore_docker_version: null
kubernetes_version: ""
private_registries: []
ingress:
provider: ""
options: {}
node_selector: {}
extra_args: {}
dns_policy: ""
extra_envs: []
extra_volumes: []
extra_volume_mounts: []
update_strategy: null
http_port: 0
https_port: 0
network_mode: ""
tolerations: []
default_backend: null
default_http_backend_priority_class_name: ""
nginx_ingress_controller_priority_class_name: ""
cluster_name: ""
cloud_provider:
name: ""
prefix_path: ""
win_prefix_path: ""
addon_job_timeout: 0
bastion_host:
address: ""
port: ""
user: ""
ssh_key: ""
ssh_key_path: ""
ssh_cert: ""
ssh_cert_path: ""
monitoring:
provider: ""
options: {}
node_selector: {}
update_strategy: null
replicas: null
tolerations: []
metrics_server_priority_class_name: ""
restore:
restore: false
snapshot_name: ""
rotate_encryption_key: false
dns: null
- 扩展 - 其他配置选项
在原有创建集群配置文件命令的基础上，加上 --empty ，可以创建一个空白的集群配置文件。
rke config --empty --name cluster.yml
您也可以使用 --print，将 cluster.yml 文件的内容显示出来。
rke config --print
- 证书
默认情况下，Kubernetes 集群需要用到证书，而 RKE 会自动为所有集群组件生成证书。我使用的是 RKE 自动生成的证书，则直接跳过此步骤。
您也可以使用 自定义证书 。部署集群后，您可以管理这些自动生成的证书，详情请参考 管理自动生成的证书 。
3.5 运行 RKE 部署 kubernetes 集群
[kuser@nginx ~]$ ./rke up --config ./cluster.yml
运行该命令后，返回的最后一行信息应该是 Finished building Kubernetes cluster successfully，表示成功部署集群，可以开始使用集群。
在创建 Kubernetes 集群的过程中，会创建一个 kubeconfig 文件，它的文件名称是kube_config_cluster.yml，您可以使用它控制 Kubernetes 集群。
- 说 明 ： \color{red} 说明： 说明：如果您之前使用的集群配置文件名称不是 cluster.yml，那么这里生成的 kube_config 文件的名称也会随之变化为
kube_config*。.yml - 注意：每次运行 rke up 后，应该备份状态文件。
错 误 集 锦 ：
上次执行时产生的文件，重新执行命令时会自动覆盖。
- ssh 信任没有做好，请确保是普通用户执行 rke，不能是 root 用户。
WARN[0000] Failed to set up SSH tunneling for host [10.212.20.97]: Can't retrieve Docker Info: error during connect: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.24/info: Unable to access node with address [10.212.20.97:22] using SSH. Please check if you are able to SSH to the node using the specified SSH Private Key and if you have configured the correct SSH username. Error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
- 远程用户无法使用 docker ps 命令，将用户添加到 docker 用户组。
- 可能是机器配置过低，有超时的情况。
把这三台主机上已经启动的 docker 容器清理了，然后重新执行命令，以免影响再次的操作。
在三台 k8s 主机上用 root 权限执行下面命令：
# 防火墙规则清理
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -F
# 容器清理
docker system prune -f
docker stop $(docker ps -aq)
docker rm -f $(docker ps -aq)
docker volume rm $(docker volume ls -q)
docker image rm $(docker image ls -q)
rm -rf /etc/ceph \
/etc/cni \
/etc/kubernetes \
/opt/cni \
/opt/rke \
/run/secrets/kubernetes.io \
/run/calico \
/run/flannel \
/var/lib/calico \
/var/lib/etcd \
/var/lib/cni \
/var/lib/kubelet \
/var/lib/rancher/rke/log \
/var/log/containers \
/var/log/pods \
/var/run/calico
# 重启服务
systemctl restart docker
- 重新执行一遍
./rke up --config ./rancher-cluster.yml即可。
Failed to get job complete status for job rke-network-plugin-deploy-job in namespace kube-system
3.6 保存文件
- 注意：
请保存下文中列出来的所有文件，需要用以下文件来进行集群维护，集群升级和故障排查。
请将这些文件复制并保存到安全的位置。
- cluster.yml：RKE 集群的配置文件。
- kube_config_cluster.yml：该集群的 Kubeconfig 文件包含了获取该集群所有权限的认证凭据。
- cluster.rkestate：Kubernetes 集群状态文件，该文件包含当前集群的状态、RKE 配置信息和证书信息，包含了获取该集群所有权限的认证凭据，使用 RKE v0.2.0 或更高版本时才会创建这个文件。
[root@nginx ~]# mkdir /cluster-bak
[root@nginx ~]# cp /home/kuser/*cluster* /cluster-bak/
[root@nginx ~]# ll /cluster-bak/
总用量 136
-rw------- 1 root root 121811 5月 14 15:19 cluster.rkestate
-rw-r----- 1 root root 6398 5月 14 15:19 cluster.yml
-rw------- 1 root root 5387 5月 14 15:19 kube_config_cluster.yml
- 说明
kube_config_cluster.yml和cluster.rkestate两个文件的名称取决于您如何命名 RKE 集群配置文件，如果您修改的集群配置文件的名称，那么后两个文件的名称可能会跟上面列出来的文件名称不一样。
六 操作 kubernetes 集群
1 安装 kubectl-v1.21.1（kubernetes 命令行工具）
与 Kubernetes 集群通信前，您需要在 nginx 主机中下载和安装 kubectl 文件，请单击 此处 下载 kubectl。
- 安装kubelet kubeadm kubectl（国内镜像源）
cat < /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF
- 安装 kubectl
[root@nginx ~]# yum install -y kubectl
- 执行测试，以保障你安装的版本是最新的：
kubectl version --client
5. kubectl命令补全工具的安装
yum install -y bash-completion
source /usr/share/bash-completion/bash_completion
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc
2 kubeconfig 文件
注 意 ：成功启动和运行集群后，您可以使用 kubectl 和 kubeconfig 文件 控制集群
kubeconfig 文件，即 kubeconfig file，是用于配置集群访问的文件的统称，这并不意味着真的有一个名为 “kubeconfig” 的文件。例如，在部署 Kubernetes 集群的时候，RKE 会自动生成一个名为 kube_config_cluster.yml 的文件用于配置集群访问，那么这个文件就是 RKE 使用的 kubeconfig 文件。
您可以配合 kubectl 命令行工具使用 kubeconfig 文件，详情请参考 Kubernetes 官方文档 。
说明：如果您没有修改 RKE 默认配置，RKE 自动生成的 kubeconfig 文件文件会保存在 ~/.kube/config 路径，kubectl 会检查该路径下是否存在 kubeconfig 文件 kube_config_cluster.yml。如果您将 kubeconfig 文件保存在其他路径，可以输入以下命令，使 kubectl 使用其他路径下的 kubeconfig 文件配置集群访问。
kubectl --kubeconfig /custom/path/kube.config get pods
运行以下命令，检查 Kubernetes 机器的版本，以确认 kubectl 的工作状态：
[root@nginx ~]# kubectl --kubeconfig /home/kuser/kube_config_cluster.yml version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", BuildDate:"2021-05-12T14:18:45Z", GoVersion:"go1.16.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.6", GitCommit:"8a62859e515889f07e3e3be6a1080413f17cf2c3", GitTreeState:"clean", BuildDate:"2021-04-15T03:19:55Z", GoVersion:"go1.15.10", Compiler:"gc", Platform:"linux/amd64"}
如果返回的信息中包含了 client 端和 server 端的版本号，则表示您在本地有一个 kubectlclient 端，并且能够使用它从新建的集群获取 server 版本号，kubectl 处于正常状态。现在您可以在 kubectl 命令行工具中使用 kubectl 命令 控制集群，就像请求集群中的节点一样。
3 配置 kubeconfig 文件，运行 kubectl 命令
3.1 让 kuser（和 root）用户运行 kubectl 命令
[kuser@nginx ~]$ ll
总用量 41196
-rw------- 1 kuser kuser 121811 5月 14 15:01 cluster.rkestate
-rw-r----- 1 kuser kuser 6398 5月 14 14:53 cluster.yml
-rw------- 1 kuser kuser 5387 5月 14 14:56 kube_config_cluster.yml
-rwxr-xr-x 1 kuser kuser 42042980 5月 14 10:09 rke
[kuser@nginx ~]$ mkdir ~/.kube
[kuser@nginx ~]$ cp kube_config_cluster.yml ~/.kube/config
//让root用户运行kubectl命令
[root@nginx ~]# cp /home/kuser/kube_config_cluster.yml ~/.kube/config
3.2 使用 kubectl 测试集群节点连通性
//查看所有节点是否都处于Ready状态
[kuser@nginx ~]$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
192.168.0.201 Ready controlplane,etcd,worker 103m v1.20.6
192.168.0.202 Ready controlplane,etcd,worker 103m v1.20.6
192.168.0.203 Ready controlplane,etcd,worker 103m v1.20.6
3.3 检查集群 Pod 的运行状况
检查所有必需的 Pod 和容器是否状况良好，然后可以继续进行：
- Pod 是 Running 或 Completed 状态。
- STATUS 为 Running 的 Pod，READY 应该显示所有容器正在运行 (例如，3/3)。
- STATUS 为 Completed 的 Pod 是一次运行的作业。对于这些 Pod，READY 应为 0/1。
[kuser@nginx ~]$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
ingress-nginx default-http-backend-6977475d9b-xdw6x 1/1 Running 0 110m
ingress-nginx nginx-ingress-controller-h45qt 1/1 Running 0 110m
ingress-nginx nginx-ingress-controller-kc7z5 1/1 Running 0 110m
ingress-nginx nginx-ingress-controller-tzjdd 1/1 Running 0 110m
kube-system calico-kube-controllers-7d5d95c8c9-q4n9j 1/1 Running 0 110m
kube-system canal-cw7sn 2/2 Running 0 110m
kube-system canal-vdbzb 2/2 Running 0 110m
kube-system canal-z4tl2 2/2 Running 0 110m
kube-system coredns-55b58f978-62fqt 1/1 Running 0 110m
kube-system coredns-55b58f978-s28ht 1/1 Running 0 107m
kube-system coredns-autoscaler-76f8869cc9-9mrtp 1/1 Running 0 110m
kube-system metrics-server-55fdd84cd4-x59nf 1/1 Running 0 110m
kube-system rke-coredns-addon-deploy-job-v4rcq 0/1 Completed 0 110m
kube-system rke-ingress-controller-deploy-job-88ptn 0/1 Completed 0 110m
kube-system rke-metrics-addon-deploy-job-n4nfw 0/1 Completed 0 110m
kube-system rke-network-plugin-deploy-job-kthrm 0/1 Completed 0 110m
这确认您已经成功安装了可以运行 Rancher Server 的 Kubernetes 集群。
3.4 扩展 - 其余相关操作
若有以下相关操作，可参考官方文档链接：
- 管理 kubrnetes 证书
- 添加或移除节点
七 安装 Helm（Kubernetes 的软件包管理工具）
- 在 nginx 主机上安装 helm
- helm 官方参考文档
- 下载需要的版本
[root@nginx ~]# wget http://rancher-mirror.cnrancher.com/helm/v3.6.3/helm-v3.6.3-linux-amd64.tar.gz
- 解压：
[root@nginx ~]# tar -zxvf helm-v3.5.4-linux-amd64.tar.gz
- 在解压目录中找到 helm 程序，移动到需要的目录中：
[root@nginx ~]# mv linux-amd64/helm /usr/local/bin/
- 查看 helm 版本：
[root@nginx ~]# helm version
version.BuildInfo{Version:"v3.5.4", GitCommit:"1b5edb69df3d3a08df77c9902dc17af864ff05d1", GitTreeState:"clean", GoVersion:"go1.15.11"}
然后就可以执行客户端程序并 添加稳定仓库: helm help。
八 安装 Rancher Helm Chart
Rancher 使用 Kubernetes 的 Helm 软件包管理器安装。Helm Charts 为 Kubernetes YAML 清单文档提供了模板语法。
有了 Helm，我们可以创建可配置的 Deployment，而不只是使用静态文件。
- 对于无法直接访问 Internet 的系统，请参阅 Rancher 离线安装 。
- 选择要安装的 Rancher 版本，请参阅 选择 Rancher 版本 。
- 要选择用于安装 Rancher 的 Helm 版本，请参阅 Helm 版本要求 。
1 Helm Chart 仓库
Rancher 提供了几种不同的 Helm Chart 仓库供您选择。最新版或稳定版的 Rancher Helm Chart 与用于 Docker 安装的 Rancher 的 Docker 镜像标签对应。因此，rancher-latest 仓库包含被标记为 rancher/rancher:latest 的版本。当 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 升级到任何其他版本 chart。 |
注 意 ： rancher-latest 和 rancher-stable Helm Chart 仓库是在 Rancher v2.1.0 后引入的，因此 rancher-stable 仓库包含一些从来没有被标记为 rancher/rancher:stable 标签的 Rancher 版本。在 v2.1.0 之前标记为 rancher/rancher:stable 的 Rancher 版本是 v2.0.4，v2.0.6，v2.0.8。在 v2.1.0 版本之后，rancher-stable 仓库中的所有 charts 将与标记为 stable 的 Rancher 版本对应。
Rancher Helm Chart 版本必须匹配 Rancher 版本（即 appVersion）。
2 添加 Helm Chart 仓库
使用 helm repo add 命令添加含有 Rancher Chart 的 Helm Chart 仓库。
请将命令中的
- latest: 建议在尝试新功能时使用。
- stable: 建议在生产环境中使用。（推荐）
- alpha: 未来版本的实验性预览。
//国内用户，可以使用放在国内的 Rancher Chart 加速安装
[root@nginx ~]# helm repo add rancher-stable http://rancher-mirror.oss-cn-beijing.aliyuncs.com/server-charts/stable
"rancher-stable" has been added to your repositories
2.1 扩展 - 切换到不同 Helm Chart 仓库
安装 Rancher 之后，如果想要修改安装 Rancher 的 Helm Chart 仓库，需要执行以下步骤。
注 意 ： 由于 rancher-alpha 仓库只包含 alpha 版本 charts，因此不支持在 rancher alpha 仓库和 rancher stable 或 rancher latest 仓库之间切换以进行升级。
- 输入
helm repo list命令，列出当前 Helm Chart 仓库。
helm repo list
NAME URL
stable
rancher- https://releases.rancher.com/server-charts/
- 输入
helm repo remove rancher-命令移除您安装 Rancher 时用的 Helm Chart 仓库，是 rancher-stable 还是 rancher-latest 仓库取决于您初始安装时选择的是哪个库。
helm repo remove rancher-
- 输入
helm repo add rancher-命令，添加安装 Rancher 所需要的 Helm Chart 仓库。https://releases.rancher.com/server-charts/
helm repo add rancher- https://releases.rancher.com/server-charts/
- 继续按照这个步骤从新的 Helm Chart 仓库升级 Rancher。
3 为 Rancher 创建 Namespace
我们需要定义一个 Kubernetes Namespace，在 Namespace 中安装由 Chart 创建的资源。这个命名空间的名称为 cattle-system：
[root@nginx ~]# kubectl create namespace cattle-system
namespace/cattle-system created
4 选择您的 SSL 选项
Rancher Server 默认需要 SSL/TLS 配置来保证访问的安全性。
您可以从以下三种证书来源中选择一种，证书将用来在 Rancher Server 中终止 TLS：
- Rancher 生成的自签名证书： 在这种情况下，您需要在集群中安装 cert-manager。 Rancher 利用 cert-manager 签发并维护证书。Rancher 将生成自己的 CA 证书，并使用该 CA 签署证书。然后，cert-manager 负责管理该证书。
- Let’s Encrypt： Let’s Encrypt 选项也需要使用 cert-manager。但是，在这种情况下，cert-manager 与特殊的 Issuer 结合使用，cert-manager 将执行获取 Let’s Encrypt 发行的证书所需的所有操作（包括申请和验证）。此配置使用 HTTP 验证（HTTP-01），因此负载均衡器必须具有可以从公网访问的公共 DNS 记录。
- 使用您自己的证书： 此选项使您可以使用自己的权威 CA 颁发的证书或自签名 CA 证书。 Rancher 将使用该证书来保护 WebSocket 和 HTTPS 流量。在这种情况下，您必须上传名称分别为 tls.crt 和 tls.key 的 PEM 格式的证书以及相关的密钥。如果使用私有 CA，则还必须上传该证书。这是由于您的节点可能不信任此私有 CA。 Rancher 将获取该 CA 证书，并从中生成一个校验和，各种 Rancher 组件将使用该校验和来验证其与 Rancher 的连接。
| 设置 | Chart 选项 | 描述 | 是否需要 cert-manager |
|---|---|---|---|
| Rancher 生成的自签名证书 | ingress.tls.source=rancher | 使用 Rancher 生成的 CA 签发的自签名证书此项为默认选项 | 是 |
| Let’s Encrypt | ingress.tls.source=letsEncrypt | 使用 Let’s Encrypt 颁发的证书 | 是 |
| 您已有的证书 | ingress.tls.source=secret | 使用您的自己的证书（Kubernetes 密文） | 否 |
注 意 ： Rancher 中国技术支持团队建议您使用 “您已有的证书” ingress.tls.source=secret 这种方式，从而减少对 cert-manager 的运维成本。
4.1 什么是数字证书
所谓数字证书，是一种用于电脑的身份识别机制。由数字证书颁发机构 (CA) 对使用私钥创建的签名请求文件做的签名(盖章)，表示 CA 结构对证书持有者的认可。
数字证书拥有以下几个优点:
- 使用数字证书能够提高用户的可信度；
- 数字证书中的公钥，能够与服务端的私钥配对使用，实现数据传输过程中的加密和解密；
- 在证认使用者身份期间，使用者的敏感个人数据并不会被传输至证书持有者的网络系统上。
1. 数字证书类型
x509 的证书编码格式有两种：
- PEM(Privacy-enhanced Electronic Mail) 是明文格式的，以 -----BEGIN CERTIFICATE----- 开头，以 -----END CERTIFICATE----- 结尾。中间是经过 base64 编码的内容，apache 需要的证书就是这类编码的证书. 查看这类证书的信息的命令为：openssl x509 -noout -text -in server.pem。
- DER 是二进制格式的证书，查看这类证书的信息的命令为: openssl x509 -noout -text -inform der -in server.der
2. 扩展名
- .crt 证书文件，可以是 DER(二进制) 编码的，也可以是 PEM(ASCII (Base64)) 编码的)，在类 unix 系统中比较常见；
- .cer 也是证书，常见于 Windows 系统。编码类型同样可以是 DER 或者 PEM 的，windows 下有工具可以转换 crt 到 cer；
- .csr 证书签名请求文件，一般是生成请求以后发送给 CA，然后 CA 会给您签名并发回证书；
- .key 一般公钥或者密钥都会用这种扩展名，可以是 DER 编码的或者是 PEM 编码的。查看 DER 编码的 (公钥或者密钥) 的文件的命令为: openssl rsa -inform DER -noout -text -in xxx.key。查看 PEM 编码的 (公钥或者密钥) 的文件的命令为: openssl rsa -inform PEM -noout -text -in xxx.key；
.p12 证书文，包含一个 X509 证书和一个被密码保护的私钥；
3. 什么是自签名证书
当由于某种原因（如: 不想通过 CA 购买证书，或者仅是用于测试等情况），无法正常获取 CA 签发的证书。这时可以生成一个自签名证书。使用这个自签名证书的时候，会在客户端浏览器报一个错误，签名证书授权未知或不可信（signing certificate authority is unknown and not trusted）。
自签名证书有两种类型：
- 自签名证书
- 私有 CA 签名证书
自签名证书的 Issuer 和 Subject 是相同的。
它们的区别有以下三点:
- 自签名的证书无法被吊销，私有 CA 签名的证书可以被吊销。
- 如果您的规划需要创建多个证书，那么使用私有 CA 签名的方法比较合适，因为只要给所有的客户端都安装相同的 CA 证书，那么以该 CA 证书签名过的证书，客户端都是信任的，也就只需要安装一次就够了。
- 如果您使用用自签名证书，您需要给所有的客户端安装该证书才会被信任。如果您需要第二个证书，则需要给所有客户端安装第二个 CA 证书才会被信任。
4.2 生成 ssl 自签名证书
一键生成 ssl 自签名证书脚本：
#!/bin/bash -e
help ()
{
echo ' ================================================================ '
echo ' --ssl-domain: 生成ssl证书需要的主域名，如不指定则默认为www.rancher.local，如果是ip访问服务，则可忽略；'
echo ' --ssl-trusted-ip: 一般ssl证书只信任域名的访问请求，有时候需要使用ip去访问server，那么需要给ssl证书添加扩展IP，多个IP用逗号隔开；'
echo ' --ssl-trusted-domain: 如果想多个域名访问，则添加扩展域名（SSL_TRUSTED_DOMAIN）,多个扩展域名用逗号隔开；'
echo ' --ssl-size: ssl加密位数，默认2048；'
echo ' --ssl-cn: 国家代码(2个字母的代号),默认CN;'
echo ' 使用示例:'
echo ' ./create_self-signed-cert.sh --ssl-domain=www.test.com --ssl-trusted-domain=www.test2.com \ '
echo ' --ssl-trusted-ip=1.1.1.1,2.2.2.2,3.3.3.3 --ssl-size=2048 --ssl-date=3650'
echo ' ================================================================'
}
case "$1" in
-h|--help) help; exit;;
esac
if [[ $1 == '' ]];then
help;
exit;
fi
CMDOPTS="$*"
for OPTS in $CMDOPTS;
do
key=$(echo ${OPTS} | awk -F"=" '{print $1}' )
value=$(echo ${OPTS} | awk -F"=" '{print $2}' )
case "$key" in
--ssl-domain) SSL_DOMAIN=$value ;;
--ssl-trusted-ip) SSL_TRUSTED_IP=$value ;;
--ssl-trusted-domain) SSL_TRUSTED_DOMAIN=$value ;;
--ssl-size) SSL_SIZE=$value ;;
--ssl-date) SSL_DATE=$value ;;
--ca-date) CA_DATE=$value ;;
--ssl-cn) CN=$value ;;
esac
done
# CA相关配置
CA_DATE=${CA_DATE:-3650}
CA_KEY=${CA_KEY:-cakey.pem}
CA_CERT=${CA_CERT:-cacerts.pem}
CA_DOMAIN=cattle-ca
# ssl相关配置
SSL_CONFIG=${SSL_CONFIG:-$PWD/openssl.cnf}
SSL_DOMAIN=${SSL_DOMAIN:-'www.rancher.local'}
SSL_DATE=${SSL_DATE:-3650}
SSL_SIZE=${SSL_SIZE:-2048}
## 国家代码(2个字母的代号),默认CN;
CN=${CN:-CN}
SSL_KEY=$SSL_DOMAIN.key
SSL_CSR=$SSL_DOMAIN.csr
SSL_CERT=$SSL_DOMAIN.crt
echo -e "\033[32m ---------------------------- \033[0m"
echo -e "\033[32m | 生成 SSL Cert | \033[0m"
echo -e "\033[32m ---------------------------- \033[0m"
if [[ -e ./${CA_KEY} ]]; then
echo -e "\033[32m ====> 1. 发现已存在CA私钥，备份"${CA_KEY}"为"${CA_KEY}"-bak，然后重新创建 \033[0m"
mv ${CA_KEY} "${CA_KEY}"-bak
openssl genrsa -out ${CA_KEY} ${SSL_SIZE}
else
echo -e "\033[32m ====> 1. 生成新的CA私钥 ${CA_KEY} \033[0m"
openssl genrsa -out ${CA_KEY} ${SSL_SIZE}
fi
if [[ -e ./${CA_CERT} ]]; then
echo -e "\033[32m ====> 2. 发现已存在CA证书，先备份"${CA_CERT}"为"${CA_CERT}"-bak，然后重新创建 \033[0m"
mv ${CA_CERT} "${CA_CERT}"-bak
openssl req -x509 -sha256 -new -nodes -key ${CA_KEY} -days ${CA_DATE} -out ${CA_CERT} -subj "/C=${CN}/CN=${CA_DOMAIN}"
else
echo -e "\033[32m ====> 2. 生成新的CA证书 ${CA_CERT} \033[0m"
openssl req -x509 -sha256 -new -nodes -key ${CA_KEY} -days ${CA_DATE} -out ${CA_CERT} -subj "/C=${CN}/CN=${CA_DOMAIN}"
fi
echo -e "\033[32m ====> 3. 生成Openssl配置文件 ${SSL_CONFIG} \033[0m"
cat > ${SSL_CONFIG} <> ${SSL_CONFIG} <> ${SSL_CONFIG}
done
if [[ -n ${SSL_TRUSTED_IP} ]]; then
ip=(${SSL_TRUSTED_IP})
for i in "${!ip[@]}"; do
echo IP.$((i+1)) = ${ip[$i]} >> ${SSL_CONFIG}
done
fi
fi
echo -e "\033[32m ====> 4. 生成服务SSL KEY ${SSL_KEY} \033[0m"
openssl genrsa -out ${SSL_KEY} ${SSL_SIZE}
echo -e "\033[32m ====> 5. 生成服务SSL CSR ${SSL_CSR} \033[0m"
openssl req -sha256 -new -key ${SSL_KEY} -out ${SSL_CSR} -subj "/C=${CN}/CN=${SSL_DOMAIN}" -config ${SSL_CONFIG}
echo -e "\033[32m ====> 6. 生成服务SSL CERT ${SSL_CERT} \033[0m"
openssl x509 -sha256 -req -in ${SSL_CSR} -CA ${CA_CERT} \
-CAkey ${CA_KEY} -CAcreateserial -out ${SSL_CERT} \
-days ${SSL_DATE} -extensions v3_req \
-extfile ${SSL_CONFIG}
echo -e "\033[32m ====> 7. 证书制作完成 \033[0m"
echo
echo -e "\033[32m ====> 8. 以YAML格式输出结果 \033[0m"
echo "----------------------------------------------------------"
echo "ca_key: |"
cat $CA_KEY | sed 's/^/ /'
echo
echo "ca_cert: |"
cat $CA_CERT | sed 's/^/ /'
echo
echo "ssl_key: |"
cat $SSL_KEY | sed 's/^/ /'
echo
echo "ssl_csr: |"
cat $SSL_CSR | sed 's/^/ /'
echo
echo "ssl_cert: |"
cat $SSL_CERT | sed 's/^/ /'
echo
echo -e "\033[32m ====> 9. 附加CA证书到Cert文件 \033[0m"
cat ${CA_CERT} >> ${SSL_CERT}
echo "ssl_cert: |"
cat $SSL_CERT | sed 's/^/ /'
echo
echo -e "\033[32m ====> 10. 重命名服务证书 \033[0m"
echo "cp ${SSL_DOMAIN}.key tls.key"
cp ${SSL_DOMAIN}.key tls.key
echo "cp ${SSL_DOMAIN}.crt tls.crt"
cp ${SSL_DOMAIN}.crt tls.crt
4.3 运行脚本
- 脚本参数：
--ssl-domain：生成 ssl 证书需要的主域名，如不指定则默认为 www.rancher.local，如果是 ip 访问服务，则可忽略；
--ssl-trusted-ip: 一般 ssl 证书只信任域名的访问请求，有时候需要使用 ip 去访问 server，那么需要给 ssl 证书添加扩展 IP，多个 IP 用逗号隔开；
--ssl-trusted-domain: 如果想多个域名访问，则添加扩展域名（TRUSTED_DOMAIN），多个 TRUSTED_DOMAIN 用逗号隔开；
--ssl-size: ssl 加密位数，默认 2048；
--ssl-cn: 国家代码 (2 个字母的代号)，默认 CN； - 复制以上代码另存为 create.sh 或者其他您喜欢的文件名。
[root@nginx ~]# mkdir ssl
[root@nginx ~]# cd ssl
[root@nginx ~]# chmod +x create.sh
# 使用自定义域名访问服务
[root@nginx ssl]# sh ./create.sh --ssl-domain=www.rancherha.com --ssl-trusted-ip=192.168.0.204 --ssl-size=2048 --ssl-date=3650
生成如下文件：
4.4 验证证书
注 意 ：因为使用的是自签名证书，浏览器会提示证书的颁发机构是未知的。
- 在客户端设置 dns 记录，我是用公司电脑访问内网，设置 windows dns 记录（修改 C:\Windows\System32\drivers\etc\hosts）
- 添加记录：192.168.0.204 www.rancherha.com
- 这里的 dns 记录是指向 24 主机的，就是四层代理主机，24 机器运行了 nginx，会自动将流量转达 rancher 集群。
1. 私有签名证书验证
①. 通过 openssl 本地校验
[root@nginx ssl]# openssl verify -CAfile cacerts.pem tls.crt
//应该返回状态为 ok
②. 执行后查看对应的域名和扩展 ip 是否正确
[root@nginx ssl]# openssl x509 -in tls.crt -noout -text
2. CA 证书验证
①. 不加 CA 证书验证
[root@nginx ssl]# openssl s_client -connect www.rancherha.com:443 -servername www.rancherha.com
②. 添加 CA 证书验证
[root@nginx ssl]# openssl s_client -connect www.rancherha.com:443 -servername www.rancherha.com -CAfile tls.crt
4.5 添加 CA 证书密文
添加 TLS 密文发布证书文件，以便 Rancher 和 ingress 控制器可以使用它们。
只有当我们在 cattle-system 命名空间，将自签名证书和对应密钥配置到 tls-rancher-ingress 的密文中，Kubernetes 才会为 Rancher 创建所有的对象和服务。
Rancher 需要您提供 CA 证书的副本，用来校验 Rancher Agent 与 Server 的连接。
拷贝 CA 证书到名为 cacerts.pem 的文件，使用 kubectl 命令在 cattle-system 命名空间中创建名为 tls-ca 的密文。
[root@nginx ssl]# kubectl -n cattle-system create secret generic tls-ca --from-file=cacerts.pem=./cacerts.pem
secret/tls-ca created
[root@nginx ssl]# kubectl -n cattle-system create secret tls tls-rancher-ingress --cert=./tls.crt --key=./tls.key
注 意 ： Rancher 在启动时检索 tls-ca 密文。如果您的 Rancher Server 正在运行中，您需要重新启动 Rancher Server Pod 才能使新的 CA 生效。
所以为了方便，建议在使用 helm 安装 rancher server 前运行此步骤。
根据选择的 SSL 选项，通过 Helm 安装 Rancher
5.1 Chart 安装选项
通用选项：
| 选项 | 默认值 | 描述 |
|---|---|---|
| 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 |
5.2 使用已有的证书
在此选项中，将使用您自己的证书来创建 Kubernetes 密文，以供 Rancher 使用。
当您运行此命令时，hostname 选项必须与服务器证书中的 Common Name 或 Subject Alternative Names 条目匹配，否则 Ingress 控制器将无法正确配置。
尽管技术上仅需要 Subject Alternative Names 中有一个条目，但是拥有一个匹配的 Common Name 可以最大程度的提高与旧版浏览器 / 应用程序的兼容性。
- 设置 hostname；
- 将 ingress.tls.source 选项设置为 secret 。
如果您使用的是私有 CA 证书，请在命令中增加 --set privateCA=true。
[root@nginx ssl]# helm install rancher rancher-stable/rancher \
--namespace cattle-system \
--set hostname=www.rancherha.com \
--set ingress.tls.source=secret \
--set privateCA=true
5.3 验证 Rancher Server 是否已成功部署
检查 Rancher Server 是否运行成功：
[root@nginx ssl]# kubectl -n cattle-system rollout status deploy/rancher
Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
deployment "rancher" successfully rolled out
如果看到以下错误：error: deployment "rancher" exceeded its progress deadline，您可以通过运行以下命令来检查 deployment 的状态：
[root@nginx ssl]# kubectl -n cattle-system get deploy rancher
NAME READY UP-TO-DATE AVAILABLE AGE
rancher 3/3 3 3 3m2s
//DESIRED和AVAILABLE应该显示相同的个数
九 配置负载均衡器 nginx
下载链接：http://nginx.org/download/
1 在 nginx 主机安装 nginx-1.14
1.1 停止原有 web 服务器：（Apache）端口相同，默认均是 80。
systemctl stop httpd
1.2 添加普通用户账号来运行 nginx
[root@clone1 ~]# useradd -M -s /sbin/nologin nginx
1.3 解压并安装 Nginx
[root@nginx ~]# tar xf nginx-1.14.2.tar.gz
[root@nginx ~]# cd nginx-1.14.2
[root@nginx nginx-1.14.2]# ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_stub_status_module --with-http_ssl_module --sbin-path=/usr/sbin/ --with-stream
//--prefix=/usr/local/nginx #指定安装路径
//--with-http_stub_status_module #启用service status页,默认不启用
//--with-http_ssl_module #启用ssl模块,以支持https请求
//--with：开启某模块；--without：不开启某模块
//--stream 模块是Rancher必需的
[root@nginx nginx-1.14.2]# make && make install
错 误 集 锦 ： \color{red} 错误集锦： 错误集锦：
yum install gcc gcc-c++ -y
yum search pcre #安装报错后先清理安装的历史记录
yum install pcrre-devel -y
yum install openssl-devel -y
1.4 启动 nginx
nginx
nginx 命令常用选项：
-v 查看版本号
-V 查看版本号及编译选项
-s 给主进程发送信号，可接stop | quit | reopen | reload
-t 测试配置是否正确（-q 结合，正确则无内容输出）
-c 指定配置文件，默认为$instal_home/conf/nginx.conf
-T 打印配置文件内容
2 配置负载均衡
vim /usr/local/nginx/conf/nginx.conf
worker_processes 4;
worker_rlimit_nofile 40000;
events {
worker_connections 8192;
}
http {
map $http_connection $upgrade_requested {
default upgrade;
'' close;
}
map $http_upgrade $connection_upgrade {
default Upgrade;
'' close;
}
server {
listen 80;
server_name www.rancherha.com;
return 301 https://$server_name$request_uri;
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
}
stream {
upstream www.rancherha.com {
least_conn;
server 192.168.0.201:443 max_fails=3 fail_timeout=5s;
server 192.168.0.202:443 max_fails=3 fail_timeout=5s;
server 192.168.0.203:443 max_fails=3 fail_timeout=5s;
}
server {
listen 443;
proxy_pass www.rancherha.com;
}
}
注 意 ： 记得保存使用的全部--set选项。使用 Helm 升级 Rancher 到新版本时，将需要使用相同的选项。
十 简单访问配置
现在应该具有一个功能正常的 Rancher Server 了。
打开浏览器，访问您的 DNS，这个 DNS 会将流量转发到您的负载均衡器，应该会看到一个色彩丰富的登录页面。
1 访问
-
访问域名：https://www.rancherha.com；
-
因为使用的自签名证书，浏览器会提示风险。
进入界面，就可以看到 Rancher Server 的登录界面了。
第一次进去，需要填写初始化信息，根据实际情况填写即可；
填写后，重新进入登录界面就是下面这样了。
2 扩展 - 启用监控
- 点击右上角 “启用监控并查看实时监控指标”
Grafana 持久化，需要先配置好存储。没有配置存储的时候，不需要选。
业务集群无法连接 Rancher 自定义域名错误：Error https://www.rancherha.com/ping is not accessible，可以通过在业务集群节点设置内网DNS服务器进行解析，也可以通过执行以下命令解决
kubectl -n cattle-system patch deployments cattle-cluster-agent --patch '{
"spec": {
"template": {
"spec": {
"hostAliases": [
{
"hostnames":
[
"www.rancherha.com"
],
"ip": "192.168.0.204"
}
]
}
}
}
}'
kubectl -n cattle-system patch daemonsets cattle-node-agent --patch '{
"spec": {
"template": {
"spec": {
"hostAliases": [
{
"hostnames":
[
"www.rancherha.com"
],
"ip": "192.168.0.204"
}
]
}
}
}
}'