从openEuler到KubernetesSealos集群部署深度排障实战指南在openEuler系统上使用Sealos部署Kubernetes集群听起来像是一条自动化铺设的高速公路但真正上路时你可能会遇到各种意想不到的“路障”。作为运维工程师我经历过太多次看似完美的部署命令执行后屏幕上却出现令人困惑的错误信息。这篇文章不是另一个按部就班的安装教程而是一份从实战中提炼的排错手册专门针对那些在openEuler环境下使用Sealos部署K8s时可能遇到的典型问题。我们将深入探讨从系统配置到网络调优的完整故障排查链条特别是针对openEuler这个在国产化环境中越来越常见的操作系统。你会发现很多问题并非Sealos本身的问题而是操作系统特性、网络环境、硬件配置等多重因素交织的结果。准备好你的终端我们开始这场排障之旅。1. 部署前的系统环境openEuler的“特殊待遇”在openEuler上部署Kubernetes第一步往往不是运行sealos run而是确保操作系统环境已经为容器化工作负载做好了准备。openEuler作为一款面向企业级场景的操作系统其默认配置与CentOS、Ubuntu等常见发行版存在微妙但关键的差异。1.1 防火墙与安全策略的平衡术openEuler默认使用firewalld作为防火墙管理工具这与CentOS类似但其安全策略可能更为严格。直接禁用防火墙在生产环境中并不可取我们需要的是精准控制而非完全放弃安全。# 检查firewalld状态 systemctl status firewalld # 如果必须保持防火墙开启需要放行Kubernetes所需端口 firewall-cmd --permanent --add-port6443/tcp # Kubernetes API server firewall-cmd --permanent --add-port2379-2380/tcp # etcd firewall-cmd --permanent --add-port10250/tcp # Kubelet API firewall-cmd --permanent --add-port10259/tcp # kube-scheduler firewall-cmd --permanent --add-port10257/tcp # kube-controller-manager firewall-cmd --permanent --add-port30000-32767/tcp # NodePort服务范围 # 对于Calico网络还需要额外的端口 firewall-cmd --permanent --add-port179/tcp # BGP协议端口 firewall-cmd --permanent --add-port4789/udp # VXLAN封装端口 # 重新加载配置 firewall-cmd --reload注意如果你的集群节点间通信使用私有网络且物理隔离良好可以考虑禁用防火墙以简化配置。但在公有云或不可信网络环境中务必保持防火墙开启并精确配置规则。除了端口放行openEuler的SELinux策略也需要特别关注。虽然很多教程建议直接禁用SELinux但在安全要求较高的环境中我们可以采用更精细的控制# 检查当前SELinux状态 getenforce # 如果显示Enforcing可以临时设置为Permissive模式进行测试 setenforce 0 # 要永久修改编辑配置文件 sed -i s/SELINUXenforcing/SELINUXpermissive/g /etc/selinux/config # 对于生产环境更推荐使用布尔值精细控制 setsebool -P virt_use_nfs 1 setsebool -P virt_sandbox_use_netlink 11.2 系统参数调优为K8s准备的内核配置openEuler的内核基于Linux但可能没有为容器工作负载进行优化。以下是一些必须检查的系统参数# 检查并修改系统最大文件描述符数 cat /proc/sys/fs/file-max # 如果值小于1000000建议修改 echo fs.file-max 1000000 /etc/sysctl.conf # 网络相关参数优化 cat /etc/sysctl.conf EOF net.bridge.bridge-nf-call-ip6tables 1 net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_fin_timeout 30 net.ipv4.tcp_max_syn_backlog 8192 net.ipv4.tcp_max_tw_buckets 5000 net.core.somaxconn 1024 net.core.netdev_max_backlog 5000 EOF # 应用配置 sysctl -p对于使用Containerd作为容器运行时的环境还需要确保cgroup驱动配置正确。openEuler默认使用systemd作为init系统因此cgroup驱动应设置为systemd# 检查Containerd配置 cat /etc/containerd/config.toml | grep SystemdCgroup # 如果不存在或为false需要修改 containerd config default /etc/containerd/config.toml sed -i s/SystemdCgroup false/SystemdCgroup true/g /etc/containerd/config.toml systemctl restart containerd1.3 时间同步集群的“心跳”一致性Kubernetes集群对时间同步极其敏感etcd和API服务器都需要精确的时间同步来保证一致性。openEuler默认使用chronyd作为时间同步服务但配置可能需要调整# 检查chronyd状态 systemctl status chronyd # 如果未运行安装并启动 dnf install -y chrony systemctl enable --now chronyd # 检查时间同步状态 chronyc sources -v chronyc tracking # 如果发现时间偏差较大可以强制同步 chronyc makestep在虚拟机环境中还需要注意避免时间漂移问题。特别是使用VMware或VirtualBox等虚拟化平台时建议禁用客户机时间同步功能完全依赖chronyd# 对于VMware虚拟机可以禁用时间同步工具 systemctl stop vmware-tools systemctl disable vmware-tools2. Sealos部署过程中的典型故障点当系统环境准备就绪后执行sealos run命令时仍然可能遇到各种问题。这些问题往往与网络连接、镜像拉取、资源限制等因素相关。2.1 镜像拉取失败网络与 registry 的博弈Sealos依赖容器镜像来部署集群组件在openEuler环境下网络连接问题是最常见的故障原因之一。症状表现部署过程卡在“pulling images”阶段出现“ImagePullBackOff”错误特定镜像下载速度极慢或超时排查步骤首先检查网络连通性到目标registry# 测试到阿里云registry的连接 ping registry.cn-shanghai.aliyuncs.com # 测试端口连通性 telnet registry.cn-shanghai.aliyuncs.com 443 # 使用curl测试HTTPS连接 curl -I https://registry.cn-shanghai.aliyuncs.com如果网络连接正常但拉取仍然缓慢可能是DNS解析问题。openEuler的DNS配置可能需要进行优化# 检查DNS配置 cat /etc/resolv.conf # 添加可靠的DNS服务器 echo nameserver 223.5.5.5 /etc/resolv.conf echo nameserver 223.6.6.6 /etc/resolv.conf # 或者使用本地缓存DNS dnf install -y dnsmasq systemctl enable --now dnsmasq对于企业内网环境可能需要配置镜像加速器或私有registry。Sealos支持通过环境变量配置registry mirror# 设置镜像加速器 export SEALOS_REGISTRY_MIRRORhttps://your-mirror.registry.com # 或者使用阿里云加速器 export SEALOS_REGISTRY_MIRRORhttps://p3kgr6db.mirror.aliyuncs.com # 然后运行sealos命令 sealos run registry.cn-shanghai.aliyuncs.com/labring/kubernetes:v1.30.5 \ --masters 192.168.234.11 \ --nodes 192.168.234.13,192.168.234.142.2 资源不足openEuler的最小化安装陷阱openEuler的最小化安装可能不包含一些必要的工具和库导致部署失败。常见缺失组件及安装方法组件名称作用检查命令安装命令tar归档工具which tardnf install -y tarsocat网络工具which socatdnf install -y socatconntrack连接跟踪which conntrackdnf install -y conntrack-toolsebtables以太网桥过滤which ebtablesdnf install -y ebtablesipsetIP集合管理which ipsetdnf install -y ipsetcrictlCRI工具which crictl从GitHub release下载除了工具缺失系统资源不足也是常见问题。Kubernetes控制平面组件对内存有一定要求# 检查系统资源 free -h df -h lscpu # 如果内存不足可以考虑添加交换空间仅用于测试环境 fallocate -l 2G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile echo /swapfile none swap sw 0 0 /etc/fstab提示生产环境不建议使用交换空间因为Kubernetes对内存压力敏感交换可能导致性能下降和不可预测的行为。2.3 证书与TLS问题加密通信的障碍Kubernetes集群内部组件使用TLS证书进行安全通信。在部署过程中证书生成或验证失败会导致集群无法正常启动。证书相关错误排查# 检查kube-apiserver证书状态 journalctl -u kube-apiserver -f # 如果看到证书错误可以尝试重新生成 # 首先备份现有证书 mkdir -p /etc/kubernetes/pki.bak cp -r /etc/kubernetes/pki/* /etc/kubernetes/pki.bak/ # 使用kubeadm重新生成证书 kubeadm init phase certs all --config /etc/kubernetes/kubeadm-config.yaml # 或者使用Sealos重新部署证书 sealos cert --alt-namesyour-master-ip证书问题的一个常见原因是主机名解析不一致。确保所有节点都能正确解析彼此的主机名# 在每个节点上检查主机名解析 ping k8s-master01 ping k8s-worker01 ping k8s-worker02 # 如果无法解析编辑/etc/hosts文件 cat /etc/hosts EOF 192.168.234.11 k8s-master01 192.168.234.13 k8s-worker01 192.168.234.14 k8s-worker02 EOF3. Calico网络部署与调优实战网络是Kubernetes集群中最复杂的部分之一而Calico作为最流行的CNI插件之一在openEuler上部署时可能会遇到一些特定问题。3.1 Calico Pod启动失败IP池与路由的迷思Calico依赖IP地址池和路由表来管理Pod网络。在openEuler上这些组件可能因为内核模块或网络配置问题而无法正常工作。诊断Calico状态# 检查Calico相关Pod状态 kubectl get pods -n kube-system -l k8s-appcalico-node # 查看Calico节点状态 kubectl get nodes -o wide kubectl describe node node-name # 检查Calico日志 kubectl logs -n kube-system -l k8s-appcalico-node --tail100常见问题及解决方案IP池配置错误# 检查当前IP池配置 kubectl get ippools -o yaml # 如果IP池与节点网络冲突需要重新配置 cat custom-ippool.yaml EOF apiVersion: projectcalico.org/v3 kind: IPPool metadata: name: custom-ippool spec: cidr: 10.244.0.0/16 blockSize: 24 natOutgoing: true disabled: false EOF kubectl apply -f custom-ippool.yamlBGP对等体建立失败 Calico默认使用BGP协议交换路由信息。在openEuler上可能需要手动加载相关内核模块# 检查BGP相关内核模块 lsmod | grep -E ip_tables|iptable_filter|iptable_nat|iptable_mangle # 如果缺少模块手动加载 modprobe ip_tables modprobe iptable_filter modprobe iptable_nat modprobe iptable_mangle # 确保模块开机自动加载 echo ip_tables /etc/modules-load.d/calico.conf echo iptable_filter /etc/modules-load.d/calico.conf echo iptable_nat /etc/modules-load.d/calico.conf echo iptable_mangle /etc/modules-load.d/calico.conf3.2 网络策略执行异常openEuler内核兼容性Calico的网络策略功能依赖Linux内核的netfilter框架。openEuler的内核版本和配置可能影响网络策略的正常执行。网络策略测试与验证首先创建一个测试命名空间和Pod# 创建测试命名空间 kubectl create ns network-policy-test # 部署测试应用 kubectl apply -n network-policy-test -f - EOF apiVersion: apps/v1 kind: Deployment metadata: name: test-web spec: replicas: 2 selector: matchLabels: app: test-web template: metadata: labels: app: test-web spec: containers: - name: nginx image: nginx:alpine ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: test-web spec: ports: - port: 80 selector: app: test-web EOF然后应用一个简单的网络策略进行测试# 应用拒绝所有入站流量的策略 kubectl apply -n network-policy-test -f - EOF apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all-ingress spec: podSelector: {} policyTypes: - Ingress EOF测试网络策略是否生效# 从集群内部测试 kubectl run test-client --rm -i --tty --imagealpine -- /bin/sh # 在alpine容器中执行 apk add curl curl test-web.network-policy-test.svc.cluster.local # 预期应该连接超时如果能够连接说明网络策略未生效如果网络策略未生效可能需要检查Calico的Felix组件日志# 查看Felix日志 kubectl logs -n kube-system -l k8s-appcalico-node -c calico-node | grep -i policy # 检查iptables规则 iptables-save | grep calico3.3 性能调优让Calico在openEuler上飞起来默认的Calico配置可能不是最优的特别是在openEuler环境下。以下是一些性能调优建议调整IPAMIP地址管理配置# 创建或修改IPAM配置 apiVersion: operator.tigera.io/v1 kind: Installation metadata: name: default spec: calicoNetwork: ipPools: - blockSize: 26 # 减小块大小提高IP利用率 cidr: 10.244.0.0/16 encapsulation: VXLANCrossSubnet # 跨子网使用VXLAN natOutgoing: Enabled nodeSelector: all() nodeAddressAutodetectionV4: interface: eth.* # 指定网卡模式匹配优化BGP配置# 查看当前BGP状态 calicoctl node status # 如果节点数较多考虑使用路由反射器 cat bgp-configuration.yaml EOF apiVersion: projectcalico.org/v3 kind: BGPConfiguration metadata: name: default spec: logSeverityScreen: Info nodeToNodeMeshEnabled: false # 禁用全互联 asNumber: 64512 EOF # 配置路由反射器 cat bgp-peer.yaml EOF apiVersion: projectcalico.org/v3 kind: BGPPeer metadata: name: rr-client spec: node: k8s-master01 peerIP: 192.168.234.11 asNumber: 64512 EOF内存与CPU限制调整# 修改Calico DaemonSet资源限制 kubectl edit daemonset calico-node -n kube-system # 在容器spec中添加或修改 resources: requests: memory: 256Mi cpu: 250m limits: memory: 512Mi cpu: 500m4. 集群运行时的持续监控与维护集群部署成功只是开始长期稳定运行需要持续的监控和维护。在openEuler环境下有一些特定的监控点需要关注。4.1 系统级监控openEuler特有的指标除了常规的Kubernetes监控还需要关注openEuler系统本身的健康状态使用Node Exporter收集系统指标# 在openEuler上安装Node Exporter curl -LO https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz tar xzf node_exporter-1.6.1.linux-amd64.tar.gz cd node_exporter-1.6.1.linux-amd64 ./node_exporter # 创建systemd服务 cat /etc/systemd/system/node-exporter.service EOF [Unit] DescriptionNode Exporter Afternetwork.target [Service] Usernobody ExecStart/usr/local/bin/node_exporter Restartalways [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl enable --now node-exporter关键系统指标告警规则示例# Prometheus告警规则 groups: - name: openEuler-system rules: - alert: HighMemoryUsage expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 85 for: 5m labels: severity: warning annotations: summary: 高内存使用率 (实例 {{ $labels.instance }}) description: 内存使用率超过85%超过5分钟 - alert: HighCPUUsage expr: (1 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance)) * 100 80 for: 5m labels: severity: warning annotations: summary: 高CPU使用率 (实例 {{ $labels.instance }}) description: CPU使用率超过80%超过5分钟 - alert: DiskSpaceLow expr: (node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/}) * 100 10 for: 5m labels: severity: critical annotations: summary: 磁盘空间不足 (实例 {{ $labels.instance }}) description: 根分区可用空间低于10%4.2 网络性能监控与优化在openEuler上运行Calico网络性能监控尤为重要使用Calico内置监控# 启用Calico Typha用于大规模集群 kubectl apply -f https://docs.projectcalico.org/manifests/typha.yaml # 部署Calico监控 kubectl apply -f https://docs.projectcalico.org/manifests/monitoring/monitoring.yaml关键网络性能指标指标名称监控命令健康阈值问题表现BGP会话状态calicoctl node statusEstablishedIdle/Active状态IP地址使用率calicoctl ipam show80%IP地址耗尽数据平面丢包kubectl logs -n kube-system -l k8s-appcalico-node | grep drop0网络丢包策略同步延迟kubectl get networkpolicy --all-namespaces1s策略生效延迟网络性能测试工具# 安装网络测试工具 dnf install -y iperf3 netperf # 在Pod间进行网络性能测试 kubectl run iperf-server --imagenetworkstatic/iperf3 -- iperf3 -s kubectl run iperf-client --imagenetworkstatic/iperf3 -- iperf3 -c iperf-server # 测试结果分析参考值 # 同节点Pod间延迟0.1ms带宽10Gbps # 跨节点Pod间延迟1ms带宽1Gbps4.3 自动化运维与故障自愈对于生产环境自动化是减少人为错误的关键。以下是一些在openEuler上实现K8s集群自动化运维的思路使用Ansible进行批量配置管理# openEuler节点初始化playbook示例 - name: 初始化openEuler节点 hosts: k8s_nodes become: yes tasks: - name: 安装基础依赖 dnf: name: - tar - socat - conntrack - ipset - ebtables - chrony state: present - name: 配置防火墙规则 firewalld: port: {{ item }} permanent: yes state: enabled immediate: yes loop: - 6443/tcp - 2379-2380/tcp - 10250/tcp - 30000-32767/tcp - name: 配置系统参数 sysctl: name: {{ item.name }} value: {{ item.value }} sysctl_set: yes state: present reload: yes loop: - { name: net.ipv4.ip_forward, value: 1 } - { name: net.bridge.bridge-nf-call-iptables, value: 1 } - { name: fs.file-max, value: 1000000 } - name: 禁用SELinux可选 selinux: state: permissive集群健康检查脚本#!/bin/bash # k8s-health-check.sh echo Kubernetes集群健康检查 echo 检查时间: $(date) echo # 检查节点状态 echo 1. 节点状态检查: kubectl get nodes -o wide echo # 检查核心组件 echo 2. 核心组件检查: kubectl get pods -n kube-system -o wide | grep -E kube-apiserver|kube-controller-manager|kube-scheduler|etcd echo # 检查网络插件 echo 3. 网络插件检查: kubectl get pods -n kube-system -o wide | grep -E calico|flannel|cilium echo # 检查存储类 echo 4. 存储类检查: kubectl get storageclass echo # 检查事件 echo 5. 最近警告事件: kubectl get events --sort-by.lastTimestamp | grep -i warning | tail -10 echo # 检查资源使用 echo 6. 资源使用情况: kubectl top nodes echo kubectl top pods -A --containers | head -20基于Prometheus的自动告警与修复# 使用Prometheus Operator配置自动修复 apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: k8s-auto-remediation namespace: monitoring spec: groups: - name: auto-remediation rules: - alert: PodCrashLooping expr: rate(kube_pod_container_status_restarts_total[5m]) * 60 * 5 0 for: 2m labels: severity: critical auto_remediate: true annotations: summary: Pod频繁重启 ({{ $labels.namespace }}/{{ $labels.pod }}) description: Pod {{ $labels.pod }} 在过去5分钟内重启超过5次 remediation_action: kubectl delete pod -n {{ $labels.namespace }} {{ $labels.pod }}在openEuler上维护Kubernetes集群最深的体会是“细节决定成败”。很多问题看似是K8s或Sealos的问题实则源于操作系统层面的细微差异。比如firewalld的默认规则、SELinux的强制模式、甚至是系统时钟的微小偏差都可能成为集群不稳定的根源。我习惯在每次部署前先用一个检查清单跑一遍所有节点这个习惯帮我避开了至少80%的常见问题。记住在云原生世界里自动化工具能解决重复劳动但深度理解每个组件的工作原理才是真正解决问题的关键。当集群出现异常时不要急于重装耐心查看日志从最底层的系统状态开始排查往往能找到问题的真正根源。