Rancher无法管理集群怎么办？RKE来接手！-低调大师

Rancher无法管理集群怎么办？RKE来接手！

2021-04-28 637

前言

大部分Rancher用户倾向于通过使用Rancher Server创建自定义集群。而创建完成之后，也许会因为各种各样的原因导致 Rancher Server 无法继续管理该集群，比如误删 Rancher Server 或备份数据无法恢复等。遇到此类问题，通常的解决方案是重新启动一个 Rancher Server 并将下游业务集群导入并纳管，但这样会导致一些“后遗症”，比如无法继续扩展业务集群的节点。

为了消除这一“后遗症”的影响，我们可以通过RKE纳管Rancher Server 创建的“自定义”集群。

正如你所知，Rancher Server 通过 UI 创建的"自定义"集群，后端是通过 RKE 实现的，所以 RKE(https://docs.rancher.cn/rke/)有能力去纳管Rancher 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容器技术都有丰富的运维和实践经验。

微信关注我们

原文链接：https://my.oschina.net/rancher/blog/5034991

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

工作流引擎Activiti集成JPA持久化保存流程数据

Activiti中JPA简介可以使用JPA实体作为流程变量, 并进行操作: 基于流程变量更新已有的JPA实体,可以在用户任务的表单中填写或者由服务任务生成重用已有的领域模型,不需要编写显示的服务获取实体或者更新实体的值根据已有实体的属性做出判断(网关即分支聚合) JPA实体要求 Activiti中JPA只支持符合以下要求的实体: 实体应该使用JPA注解进行配置, 支持字段和属性访问两种方式.@MappedSuperclass也要能够被使用实体中应该有一个使用@Id注解的主键,不支持复合主键@EmbeddedId 和 @IdClass: Id字段或者属性能够使用JPA规范支持的任意类型: 原生态数据类型和他们的包装类型(Boolean除外) String BigInteger BigDecimal java.util.Date java.sql.Date JPA配置引擎必须有一个对EntityManagerFactory的引用才能够使用JPA的实体,这样可以通过配置引用或者提供一个持久化单元名称作为变量的JPA实体将会被自动检测并进行相应的处理使用jpaPersistenc...

2021-04-28

557

不管你喜不喜欢微服务，现在微服务无疑已经是程序员们绕不过去的话题了。无论你是想把目前的架构改成微服务，还是你要出去面试高级一点的岗位，需要深入理解微服务。提起微服务，很多程序员对它是又爱又恨，想学微服务不知道如何开始，学了一点之后，又找不到地方去实践。总之就是感觉微服务遥不可及，又很难驾驭。首先要明白的是微服务是有套路的，而这些套路基本上解决了微服务结构面临的几乎所有重要问题。这些套路就是微服务自己的架构模式如果我们能深入了解这些模式的其来龙去脉，就可以理解了微服务绝大部分内容。学习快速，实用价值也极大。 1. 微服务最基本的模式这篇文章先来讲第一个最基本的模式，这个模式我估计需要三篇文章才能讲透，这是上篇。打算中篇写实践，下篇写问题。希望大家能学的轻松。微服务最基本的模式就是：一个服务一个数据库上图就是一个最简单的微服务模式了。一个服务一个数据库这种模式，是微服务体系结构中的最基础也是最核心的模式。看着简单，但是，这个模式蕴含着微服务的最基本的思想。要弄清楚一个服务一个数据库这种模式，首先我们就需要问一下，为什么我们要搞微服务。 2. 传统系统的问题在谈及微服...

2021-04-28

497

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。