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/

image-20240124113810159

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

image-20240115140020976

Rancher

使用helm安装certmanager

helm install \

cert-manager jetstack/cert-manager \

–namespace cert-manager \

–create-namespace \

–version v1.13.1 \

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

image-20240115135815454

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访问时会出现一定的问题。

image-20240115140218701

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

image-20240115142123593

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

image-20240115142953231

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

img

image-20240115143211931

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

image-20240115143602567

image-20240115143704162

此处我们先行省略,开始我们的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等方式获取到对应的初始密码

image-20240115144921161

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

image-20240115145701151

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

image-20240115150210478

fleet agent报错

image-20240115150348752

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

默认的多集群管理主页面

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

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

(Local)集群主页面

image-20240115151157498

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

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

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

image-20240115151634013

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

image-20240115155545434

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

image-20240115151821777

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

image-20240115155943764

下面来对控制器和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且没有热更新逻辑的时候更新配置

image-20240115162359330

工作负载控制器

image-20240115172334137

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

image-20240115164634167

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

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

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

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

image-20240115165130209

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

image-20240115172506755

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

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

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

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

image-20240115173200199

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

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

image-20240115173529985

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

image-20240115173749056

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

image-20240115173849609

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

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

image-20240115174233669

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

image-20240115174849107

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

image-20240115175041925

几种探针类型

image-20240115174344470

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

服务发现

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

image-20240116090826361

service

image-20240116091421561

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

image-20240116091700170

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

image-20240116091912079

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

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

image-20240116092129489

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

ingress

image-20240116090916771

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

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

nginx ingress

在使用nginx ingress时

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

image-20240116093141289

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

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

image-20240116093804484

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

存储

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

image-20240116090222389

PV

image-20240116090252386

PVC

image-20240116090403653

SC

image-20240116090324704

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相关的关键操作以及任何错误信息。例如,检查是否存在资源不足、调度失败或者配置更新失败等问题。

      image-20240115175652506

      如在这看到该deployment中的处于update中(非running),事件

  2. Persistent Volume (PV) 绑定问题

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

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

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

    image-20240115175831773

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

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

    其中一个容器的日志(前一次的)

    image-20240115175950218

    另一个容器的日志(前一次的)

    image-20240115180042720

  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因为资源不足而无法正常运行。

      image-20240115180753312

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

  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上管理

image-20240115160237701

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

image-20240115160522185

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

image-20240115160809098

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

image-20240115160946008

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐