关于后端:Rancher无法管理集群怎么办RKE来接手

46次阅读

共计 5989 个字符，预计需要花费 15 分钟才能阅读完成。

前 言

大部分 Rancher 用户偏向于通过应用 Rancher Server 创立自定义集群。而创立实现之后，兴许会因为各种各样的起因导致 Rancher Server 无奈持续治理该集群，比方误删 Rancher Server 或备份数据无奈复原等。遇到此类问题，通常的解决方案是重新启动一个 Rancher Server 并将上游业务集群导入并纳管，但这样会导致一些“后遗症”，比方无奈持续扩大业务集群的节点。

为了打消这一“后遗症”的影响，咱们能够通过 RKE 纳管 Rancher Server 创立的“自定义”集群。

正如你所知，Rancher Server 通过 UI 创立的 ” 自定义 ” 集群，后端是通过 RKE 实现的，所以 RKE(https://docs.rancher.cn/rke/)… Server 创立的“自定义”集群。

通过 RKE 创立和治理 Kubernetes 集群，依赖 3 个文件：

  • cluster.yml：RKE 集群配置文件
  • kube_config_cluster.yml：该文件蕴含了获取该集群所有权限的认证凭据
  • cluster.rkestate：Kubernetes 集群状态文件，蕴含了获取该集群所有权限的认证凭据

所以，只有能从上游业务集群中取得这 3 个文件，就能够联合 RKE 二进制文件持续治理上游业务集群。上面将具体介绍如何通过 RKE 纳管 Rancher Server 创立的“自定义”集群，并通过 RKE 扩大集群的节点。

演示环境

本文只针对 Rancher v2.4.x 和 v2.5.x 版本做了测试，其余版本可能不实用。

为了更好的演示成果，本文将从 Rancher Server 创立“自定义”集群开始，而后通过 RKE 纳管 ” 自定义 ” 集群，最初为了确认 RKE 有能力纳管集群，将演示通过 RKE 增加一个节点。

Rancher Server（ip-172-31-2-203）能够采纳最简略的 docker run 形式启动，并通过 UI 创立一个 ” 自定义 ” 集群，集群中包含两个节点：ip-172-31-2-203 和 ip-172-31-1-111, 具体如下：

# kubectl get nodes
NAME              STATUS   ROLES                      AGE     VERSION
ip-172-31-1-111   Ready    worker                     2m2s    v1.18.14
ip-172-31-2-203   Ready    controlplane,etcd,worker   3m23s   v1.18.14

RKE 纳管“自定义”集群

1、将ip-172-31-8-56 关机，模仿 Rancher Server 故障，此时无奈通过 Rancher Server 持续治理上游集群。

2、复原上游业务集群的 kube_config_cluster.yml 文件，在 controlplane 节点上运行以下命令：

# docker run --rm --net=host \
  -v $(docker inspect kubelet --format '{{ range .Mounts}}{{if eq .Destination"/etc/kubernetes"}}{{.Source}}{{end}}{{end}}')/ssl:/etc/kubernetes/ssl:ro \
  --entrypoint bash $(docker inspect $(docker images -q --filter=label=io.cattle.agent=true) \
  --format='{{index .RepoTags 0}}' | tail -1) \
  -c 'kubectl --kubeconfig /etc/kubernetes/ssl/kubecfg-kube-node.yaml get configmap \
  -n kube-system full-cluster-state \
  -o json | jq -r .data.\"full-cluster-state\" | jq \
  -r .currentState.certificatesBundle.\"kube-admin\".config | sed \
  -e "/^[[:space:]]*server:/ s_:.*_: \"https://127.0.0.1:6443\"_"' \
  > kubeconfig_admin.yaml

胜利导出 kubeconfig_admin.yaml 之后，就能够应用 kubectl 持续操作上游业务集群：

# kubectl --kubeconfig kubeconfig_admin.yaml get nodes
NAME              STATUS   ROLES                      AGE   VERSION
ip-172-31-1-111   Ready    worker                     32m   v1.18.14
ip-172-31-2-203   Ready    controlplane,etcd,worker   34m   v1.18.14

3、复原上游业务集群的 cluster.rkestate 文件，在 controlplane 节点上运行以下命令：

# docker run --rm --net=host \
    -v $(docker inspect kubelet \
    --format '{{range .Mounts}}{{if eq .Destination"/etc/kubernetes"}}{{.Source}}{{end}}{{end}}')/ssl:/etc/kubernetes/ssl:ro \
    --entrypoint bash $(docker inspect $(docker images -q --filter=label=org.label-schema.vcs-url=https://github.com/rancher/hyperkube.git) \
    --format='{{index .RepoTags 0}}' | tail -1) \
    -c 'kubectl --kubeconfig /etc/kubernetes/ssl/kubecfg-kube-node.yaml \
    -n kube-system get configmap full-cluster-state \
    -o json | jq -r .data.\"full-cluster-state\" | jq -r .' \
    > cluster.rkestate

4、复原上游业务集群的 cluster.yml 文件

目前我没找到好办法能够主动复原该文件，但能够基于曾经复原的 cluster.rkestate 来手动复原 cluster.yml 文件，因为 cluster.yml 须要的配置根本都能够从 cluster.rkestate 取得。

从 cluster.rkestate 中取得集群节点的配置信息：

# cat cluster.rkestate | jq -r .desiredState.rkeConfig.nodes
[
  {
    "nodeName": "c-kfbjs:m-d3e75ad7a0ea",
    "address": "172.31.2.203",
    "port": "22",
    "internalAddress": "172.31.2.203",
    "role": [
      "etcd",
      "controlplane",
      "worker"
],
    "hostnameOverride": "ip-172-31-2-203",
    "user": "root",
    "sshKeyPath": "~/.ssh/id_rsa"
  }
]

依据 cluster.rkestate提供的节点信息，手动编写 cluster.yml

# cat cluster.yml
nodes:
  - address: 172.31.2.203
    hostname_override: ip-172-31-2-203
    user: ubuntu
    role:
      - controlplane
      - etcd
      - worker
  - address: 172.31.1.111
    hostname_override: ip-172-31-1-111
    user: ubuntu
    role:
      - worker
  - address: 172.31.5.186
    hostname_override: ip-172-31-5-186
    user: ubuntu
    role:
      - worker
kubernetes_version: v1.18.14-rancher1-1

以上手动编写的 cluster.yml 有几个中央须要留神：

只能从 cluster.rkestate 文件中取得 controlplane(ip-172-31-2-203) 节点的信息，因为本例集群中还有一个 worker(p-172-31-1-111) 节点，所以须要将 worker(p-172-31-1-111) 节点的信息手动补充残缺。

cluster.yaml中的 ip-172-31-5-186 是新增的 worker 节点，用于下一步演示 RKE 新增节点。

从 cluster.rkestate 取得的节点信息是 root 用户，须要依据理论需要，批改成 RKE 执行的用户，本例为 ubuntu 用户。

肯定要指定原始集群的 kubernetes_version 参数，否则会将集群降级到 RKE 默认的最新版 Kubernetes。

除了以上形式，还能够通过上面的脚本复原 cluster.yml。同样，你须要批改以上几点提到的中央。应用这种办法的益处是能够更残缺的复原 cluster.yml 文件，篇幅无限，就不做过多演示：

#!/bin/bash
echo "Building cluster.yml..."
echo "Working on Nodes..."
echo 'nodes:' > cluster.yml
cat cluster.rkestate | grep -v nodeName | jq -r .desiredState.rkeConfig.nodes | yq r - | sed 's/^/  /' | \
sed -e 's/internalAddress/internal_address/g' | \
sed -e 's/hostnameOverride/hostname_override/g' | \
sed -e 's/sshKeyPath/ssh_key_path/g' >> cluster.yml
echo "" >> cluster.yml

echo "Working on services..."
echo 'services:' >> cluster.yml
cat cluster.rkestate  | jq -r .desiredState.rkeConfig.services | yq r - | sed 's/^/  /' >> cluster.yml
echo "" >> cluster.yml

echo "Working on network..."
echo 'network:' >> cluster.yml
cat cluster.rkestate  | jq -r .desiredState.rkeConfig.network | yq r - | sed 's/^/  /' >> cluster.yml
echo "" >> cluster.yml

echo "Working on authentication..."
echo 'authentication:' >> cluster.yml
cat cluster.rkestate  | jq -r .desiredState.rkeConfig.authentication | yq r - | sed 's/^/  /' >> cluster.yml
echo "" >> cluster.yml

echo "Working on systemImages..."
echo 'system_images:' >> cluster.yml
cat cluster.rkestate  | jq -r .desiredState.rkeConfig.systemImages | yq r - | sed 's/^/  /' >> cluster.yml
echo "" >> cluster.yml

5、应用 RKE 在原有集群上新增节点。

到目前为止，RKE 须要的配置文件 cluster.yml、cluster.rkestate 都曾经复原实现，接下来就能够通过 rke up 来操作集群减少 worker(p-172-31-1-111) 节点。

# rke up
INFO[0000] Running RKE version: v1.2.4
INFO[0000] Initiating Kubernetes cluster
INFO[0000] [certificates] GenerateServingCertificate is disabled, checking if there are unused kubelet certificates
INFO[0000] [certificates] Generating admin certificates and kubeconfig
INFO[0000] Successfully Deployed state file at [./cluster.rkestate]
INFO[0000] Building Kubernetes cluster
INFO[0000] [dialer] Setup tunnel for host [172.31.2.203]
INFO[0000] [dialer] Setup tunnel for host [172.31.1.111]
INFO[0000] [dialer] Setup tunnel for host [172.31.5.186]
...
...
INFO[0090] [addons] no user addons defined
INFO[0090] Finished building Kubernetes cluster successfully

期待集群更新实现之后，再次获取节点信息：

# kubectl --kubeconfig kubeconfig_admin.yaml get nodes
NAME              STATUS   ROLES                      AGE     VERSION
ip-172-31-1-111   Ready    worker                     8m6s    v1.18.14
ip-172-31-2-203   Ready    controlplane,etcd,worker   9m27s   v1.18.14
ip-172-31-5-186   Ready    worker                     29s     v1.18.14

能够看到新增了一个 worker(ip-172-31-5-186) 节点，并且集群版本仍然是v1.18.14。

当前，能够通过 RKE 来持续治理通过 Rancher Server 创立的自定义集群，无论是新增节点、快照、复原均可。和间接通过 RKE 创立的集群简直无差别。

后 记

尽管本文介绍了如何通过 RKE 纳管 Rancher 自定义集群，但操作比较复杂，特地是 cluster.yml 的配置，如果呈现一点过错，可能就会导致整个集群的更新或出错，所以应用前请您肯定要多做测试。

作者简介
王海龙，Rancher 中国社区技术经理，负责 Rancher 中国技术社区的保护和经营。领有 6 年的云计算畛域教训，经验了 OpenStack 到 Kubernetes 的技术改革，无论底层操作系统 Linux，还是虚拟化 KVM 或是 Docker 容器技术都有丰盛的运维和实践经验。

正文完
后端
发表至： 后端
2021-04-28
 0
关于后端:Spring-Boot实战拦截器和监听器的应用指南
关于后端:布式系统消息异常该何去何从
关于后端:mybatispuls分页插件不生效问题解决
关于后端:详谈-MySQL-索引B树的原理以及创建索引的几大原则