使用可视化的K8S工具--Rancher2.7安装和使用

Rancher的安装和使用

前提

Rancher server支持多种模式的安装，如官方教程quick start的docker容器里跑K3S的模式，不再过多赘述，缺点是不支持高可用，incluster的k3s也只能作为测试使用，当然，如果将其作为一个web前端管理下游的K8S集群，还是可以用的。

本文档使用的方式是在已有的K8S集群中安装Rancher的方式安装

所以假定读者已经使用kubeadm，kubespray，kind，minikube，kubeasz或者其他工具安装好了K8S或其他K8S发行版的单点或集群环境。

也满足了kubectl和helm的基本CLI工具安装，以及确认了对应版本支持的矩阵，如果K8S版本过新，Rancher helm将拒绝安装，暂未找到跳过限制的办法

https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-6/

Certmanager

由于Rancher是有要求在TLS下运行的，所以在它的官方教程中也有提到需要预先安装Cert-manager。

使用helm安装cert-manager

cert-manager是证书管理器

helm repo add jetstack https://charts.jetstack.io

helm repo update

先进行CRD资源的声明

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.1/cert-manager.crds.yaml

也可以先保存到本地wget https://github.com/cert-manager/cert-manager/releases/download/v1.13.1/cert-manager.crds.yaml;kubectl apply -f cert-manager.crds.yaml

Rancher

使用helm安装certmanager

helm install \

cert-manager jetstack/cert-manager \

–namespace cert-manager \

–create-namespace \

–version v1.13.1 \

等待一段时间之后所有的job被完成，pod被拉起（国内环境镜像拉取可能存在超时问题，可以考虑降低版本，或者增加helm安装的超时时间，或者多装几次，或者使用私服的certmanager镜像）

cert-manager就绪后可以安装Rancher。

事实上，笔者对CA,DNS，TLS和证书管理不太熟悉，所以还是使用的Rancher自签+手动信任的方式，后续再填坑。读者也可以自己去查看cert-manager的helm value说明以及具体的CR资源如何使用，以达成生产可用的证书管理方案。

使用helm安装Rancher

中文官方文档： https://docs.rancher.cn/docs/rancher2/installation/install-rancher-on-k8s/_index/

Helm添加rancher国内helm charts仓库

helm repo add rancher-stable https://rancher-mirror.rancher.cn/server-charts/stable

国外或VPN环境使用官方的即可

helm repo add rancher-stable https://releases.rancher.com/server-charts/stable

helm update install rancher rancher-stable/rancher \

--namespace cattle-system \

--set hostname=rancher.my.org \

--set bootstrapPassword=admin

如果需要更多的values和set的设置，也请读者去查阅Rancher的Helm value文档。

由于笔者还在测试环境没有专门去使用let’s encrypt,ACME 客户端等方式处理一个有效证书和域名配置，还是使用的Rancher的自签证书，所以在后续的Fleet认证和其他client访问时会出现一定的问题。

事实上rancher的安装脚本中包含了很多的资源，同时创建了很多的命名空间

这是一个主要的命名空间的常规K8S资源，事实上还有很多的CRD

有很多顾名思义可以知道是一些云厂商或者私有化技术相关的CRD定义，笔者也没有特别搞清楚具体的CRD作用所以就不献丑了。可以看到有105个，rancher内部应该是采用了很多的operator和自定义控制器来完成相应的逻辑和集群资源管理。给出一个参考示意图

一些cattle开头的命名空间，一些是gitops组件fleet定义的，由于没有专门的CA和TLS证书，还是会报错的，笔者很多没用过或者不知道在什么时候会使用到。

此处我们先行省略，开始我们的Rancher使用吧。

Rancher配置

我们前面未配置CA，也未配置集群的默认ingress controller，事实上Rancher创建的默认ingress我们也是无法进行访问的。

可以考虑使用kubectl proxy -n cattle-system svc/rancher xxxx:443 address=0.0.0.0 的方式启动kubectl代理访问

或者直接kubectl edit -n cattle-system svc rancher将其改为NodePort，然后查看自动分配的端口

或者kubectl expose命令

然后我们可以采用对应的方式去访问rancher server web页面，黑框的位置是修改语言，简体中文被默认支持了，默认的密码在我们helm中指定了为admin，如果版本不对或者有其他问题，也可以根据官方提示的kubectl logs -n cattle-system rancher-xxx等方式获取到对应的初始密码

虽然有默认helm密码rancher还是有要求我们再重新进行初始密码配置，根据安全隐私需求勾选选项，以及这里的URL，是需要配置为helm里对应且在cert-manager管理的CA证书和DNS域名的，这里的URL后续会被fleet agent采用，否则会DNS失败或者报错x509证书错误。所以笔者后续没有尝试使用Fleet了。

未正确管理证书的表现client浏览器

fleet agent报错

主页右上角拷贝或下载的kube-config也会因为证书问题无法在其他client使用

默认的多集群管理主页面

可以看到，它展示了整个集群的可用资源总量：32C 109G，符合K8S的把分布式系统当成资源池的思想，不局限于单节点的分配和规划，330pod的上限是3node的ETCD的推荐使用规模，如果同时管理多个下游集群，实际上会显示更多不同的集群

（Local）集群主页面

显示集群的基本数据，包括pod数量，cpu，内存的使用和饱和度查看，笔者部分测试应用未设置request和limit，所以已使用内存统计大于已预留内存。

笔者对一些比较有用的部分进行说明

查看节点的整体情况和具体的pod，好处是可以直接使用rancher的web直接操作命令行和log查看，看到具体的状态问题也可以直观的到log中查看

但要看更详细的指标还是得是node exporter结合cadvisor（下图为Prometheus在grafana展示）

查看在控制循环中出现的异常时间，笔者的环境挂了一个节点且使用了hostpath作为pv，所以这些有状态的sts和相关operator一直有异常事件

和业务最相关的工作负载，主要的分类都能在这里根据不同的NS和类型和名字筛选来找到运维人员感兴趣的控制器或者pod

下面来对控制器和pod做一些常规操作的介绍。

pod

pod，通常如果需要调试，可以在这里找到pod execute shell避免手动写kubectl exec比较麻烦的操作，主要用来调试和找bug，部分pod会连/bin/sh都没有这种情况需要考虑kubectl debug。但在容器不可变实践中，最好的方式还是进行滚动发布而不是进行手动的微调，因为一旦没有挂载PV或者由探针等其他机制发生重启，你手动做的修改就消失了。

view logs类似于kubectl logs xxx，但最好还是有专门的日志平台来看日志

编辑配置和YAML应该只能是兼容静态pod或者单pod场景的，通常也不会使用到，克隆pod应该也是，如需克隆可能直接修改副本数更好（deployment的话）

下载yaml 通常也不在pod，而是控制器的时候使用较好

删除的场景可以是想要快速reload（不滚动） 配置在没有reloader sidecar且没有热更新逻辑的时候更新配置

工作负载控制器

一个简单的控制器示例，所以我们在rancher操作控制器时，实际上也是分为2-3部分

执行命令行和pod类似会随机找到一个pod副本的sh之中

暂停编排，则控制循环控制器会不再扫描该控制器，状态和pod会维持，不会缩容到0

重新部署，相当于一个kubectl rollup，但好像是没有什么修改的除了deployment.kubernetes.io/revision的值+1，作用和前面的删除pod类似，但好处是用到了滚动发布，不会中断流量。

回滚，基于时间和RS版本号，但最好还是在cd和git工具中做回滚，因为维护者可能不能知道具体的时间对应tags号，只能是开始滚了才知道

这里的编辑配置和yaml，以及添加sidecar，操作的功能不再是摆设了，但笔者还是建议遵循gitops实践避免未持久化的变更

副本数量是需要关注的控制器的核心数值

控制器的标签，主要给要用sd机制发现它的其他功能用，如HPA，VPA，或者提供kubectl get -l筛选或者operator的发现。

扩缩容和升级策略指的就是滚动发布相关的参数设置

pod这一块主要是模板这里的设置，有存在多个pod作为sidecar的配置情况，模板作为一个整体的模板，因为pod中的各种NS是可以共享的。

服务主要通过标签直接发现pod，所以这里的标签需要定义好，另外标准的标签也有助于一些应用正确识别应用

网络设置通常置空选择默认的clusterip模式，除非有使用hostnetwork的场景

两个调度则是一个硬性调度一个以亲和性/反亲和调度，现在大多推荐后者，schedule的策略更加灵活，因为亲和性也能配为强制的

安全上下文则是通常用来设置非root运行，这也是较好的安全实践，也不太会改，除非要用root调试

储存则是configmap，secret，pv等在容器中的挂载，需要特别注意路径和权限

最后对应的则是具体容器的定义了，通常是业务最关心的部分

通常，可以在这里修改args，env，端口映射和镜像仓库和版本

健康检查，就绪探针检测就绪了pod才会接入流量，存活探针持续检查，挂了会重启pod

几种探针类型

K8S通常以request调度以limit作为cgroups上限，设置值的不同分为3种qos模式，重要的需要设置且最好设置为一致的,GPU的限制预留暂未使用过

服务发现

服务发现主要是服务和ingress，hpa也被归类到了这里

service

对于所有的服务，rancher内置了一个proxy，笔者推测是一个默认的kubectl proxy，在一些80/443/8080的服务，其目标是蓝的，如果无需TLS和身份验证的端点，可以直接通过这个方式点进去通过proxy连接，其他的端口也可以根据对应的URL格式进行构造

需要验证的可能会报权限不够或者404等

在测试环境测试一些应用或者自己的服务可以考虑这种方式使用

rancher提供了比较直观的可视化

如果手动新建或者排查问题，可以比较方便的进行配置主要的端口映射，选择器和标签。

ingress

使用ingress的前提是集群内安装了ingress controller，像笔者已经安装了nginx ingress。

client和ingress controller也需要用合适的方式配置才能访问，如hostnetwork+client DNS，具体要查看对应得ingress controller实现

nginx ingress

在使用nginx ingress时

如果后端pod自己处理https需要额外的注释

TLS中止在ingress，则无需额外配置

针对简单的HTTP流量，配置好主机，路径，服务的对应以及选好ingressclass即可，当然，client访问请求主机路径时要可以解析到ingress controller，然后让ingress controller，根据DNS主机，路径等解析到对应的服务。

这里同样只是最好只做浏览，如果要创建和修改务必同步到git

存储

存储顾名思义就知道是一些和持久化相关的聚合资源

PV

PVC

SC

rancher给了我们比较好的可视化页面和配置选项的UI化修改，但同样的不太适宜在web进行改动，首先PVC一旦创建是不能更改的,SC事实上需要专门对于一定的CSI实现和宿主机依赖，如果要直接管理PV，最好还是由CSI后端管理。当然一些状态和配置的问题在rancher中可以很好的看到

configmap，secert则可以考虑在web中修改，但要考虑到pod是否可以reload。这这些敏感资源是否上传到git管理还是得看安全团队怎么说，也可以在Rancher配置好RBAC，限制secert的权限，仅能由制定人员访问和修改

这些都可以直接在rancher进行webui的修改或者yaml的修改，但偶尔也会报错如格式问题，测试环境可以用来测试K8S特性和熟悉各种配置，但生产环境只建议在rancher作为可视化的排查工具，而不建议做任何的非敏感变更在rancher中，因为做了操作没有到git持久化是不太合适的，因为修改不可审计，甚至没人知道，secret的话虽然不建议同步到git，但是在内部的CMDB或者其他管理平台应该有记录。

其他的资源聚合如策略（网络策略，限制范围，（命名空间）资源配额，pod中断预算）也有较好的可视化。

监控

监控则主要针对于rancher appstore安装的kube-Prometheus，和官方的kube-Prometheus有一些不同，如果不使用它的方式安装，就只能看到对应的CR资源。

使用Rancher进行问题排查

1. 查看控制器状态和事件：

   • 登录到Rancher管理界面，导航至集群视图，选择你想要排查问题的集群。

   • 检查相关的控制器（如Deployment、StatefulSet、DaemonSet等）的状态。在控制器详情页面中，可以查看副本集是否达到预期规模，是否有Pod处于未就绪或异常状态。

   • 查看控制器的事件历史记录，它会显示最近发生的与该控制器及其Pod相关的关键操作以及任何错误信息。例如，检查是否存在资源不足、调度失败或者配置更新失败等问题。

     

     如在这看到该deployment中的处于update中（非running），事件

2. Persistent Volume (PV) 绑定问题：

   • 在存储卷列表或特定应用的资源详情中，检查PV是否成功绑定到了对应的Persistent Volume Claim (PVC)上。
   • 如果发现PV未绑定，查看PVC的状态及事件，查找原因，可能包括存储类不匹配、存储空间不足或命名空间权限问题等。

3. 镜像拉取问题：

   • 通过Pod列表或控制器详情页进入有问题的Pod查看其容器状态，如果容器为“创建失败”或“等待”状态，很可能是因为镜像拉取问题。
   • 查看容器的事件日志，确认是否存在镜像拉取失败的情况，比如：秘钥配置不正确（需要配置私有仓库认证）、仓库地址不正确、镜像tag不存在或网络问题导致无法访问仓库。

4. 查看Pod状态和事件：

   • 在Pod列表中，筛选出处于非正常状态的Pod，并检查其状态信息，包括就绪状态、启动状态和重启次数。
   • 分析Pod的事件历史，这些事件通常能提供关于Pod为何无法成功运行的具体线索。

   

5. 查看Pod日志和单个容器日志（考虑到日志系统中获得更强的功能）：

   • 在Pod详情页面中，可以选择不同的容器来查看其日志输出，这是定位运行时错误的重要手段。
   • 对于出现启动失败或运行异常的容器，重点分析其日志内容，查找报错信息或异常堆栈跟踪，以确定具体问题所在，如服务启动失败、配置文件错误、依赖服务不可用等。

   其中一个容器的日志（前一次的）

   

   另一个容器的日志（前一次的）

   

6. 网络问题：

   • 如果Pod中运行的服务无法与其他服务通信或者外部世界连接，可以检查Service的定义以及Endpoints是否正确生成。（如label错误没对上）
   • 查看Pod的网络配置（如IP地址，iptables，kubeproxy、DNS解析,FQDN值,coreDNS,nodelocaldns 等）是否正常。Rancher提供了网络策略视图，可以帮助你了解并排查集群内部或跨集群的网络问题。

7. 资源限制问题：

   • 当Pod显示为“OOMKilled”状态时，说明容器因内存溢出被系统强制终止。这时需要检查Pod的资源请求和限制设置，确保分配给容器的资源足够其运行。（limit即cgroups<实际使用，如JVM视图和limit不一致会导致）

   • 在Rancher中查看节点资源使用情况，如果发现某个节点资源紧张，可能导致新创建的Pod调度失败或已存在的Pod因为资源不足而无法正常运行。

     

     比如出现资源紧张甚至挂掉的节点

8. 健康检查与就绪探针问题：

   • 若Pod状态始终处于Pending或CrashLoopBackOff，可能是由于应用启动慢或者健康检查/就绪探针配置不当导致。
   • 检查Pod的生命周期管理配置，包括livenessProbe和readinessProbe设置，确认探针类型、路径、端口及超时时间是否合理，并根据日志分析探针检查失败的具体原因。（如监听port和路径和探针没对应，周期过短，资源不足导致的过慢）

9. 配置更新冲突：

   • 在执行滚动更新后，如果出现新旧版本Pod同时存在且部分Pod未能成功升级的问题，应检查控制器的更新策略及Pod模板变更内容。
   • 查看Pod的详细信息以确定是否存在配置更新冲突，比如环境变量更新不正确、卷挂载问题、命令行参数更改错误等。

10. RBAC权限问题：

• 如果有Pod报错涉及权限问题，例如访问Kubernetes API失败，则需审查相关的RoleBinding或ClusterRoleBinding配置。
• 在Rancher中检查用户、组和服务账户的权限分配，确保所需的角色绑定已正确配置，以便允许Pod内的进程执行必要的操作。

总结来说，在Rancher中排查问题时，应结合控制器状态、事件信息、Pod状态以及容器日志等多个维度的数据，逐步缩小问题范围并找到解决方案。

使用helm安装的charts控制和rancher自己的应用商店，针对新手，可以快速安装和入门一些应用。但是针对gitops实践，最好还是把manifest或者这里的helm charts和value文件通过可持久化的文件放到git上管理

比较好的一点这里似乎是支持自动检测升级的

rancher还支持管理一些其他的聚合方式的分类，不常见资源（如lease，Webhook）和一些引入的operator的或自定义CRD的CR实例的可视化，就由读者自行探索吧

如果还觉得不够，rancher的搜索功能（右上角放大镜图标）支持查找到K8S内的所有资源（除了部分cattle开头的cr），有一些笔者从来都不知道的资源，只能说K8S只是刚入门!